Zig is moving to this direction is well.
[flagged]
This can’t be serious.
Changing how we develop Ladybird
41–50 of 602 posts
Re: Changing how we develop Ladybird
#42On the one hand, if you grew up in the baazzar, moving to the cathedral might feel like the "death of open source" even if it is really just a return to an earlier way of working.
On the other hand, while not accepting external code contributions will certainly improve their security posture it will also make it more difficult to identify who to invite to join the priesthood.
Re: Changing how we develop Ladybird
#43It saddens me to see the communities surrounding free software projects going dark because of the threat posed by AI tools, but I don't know what other solutions there are that would mitigate the threat, particularly when browsers are such a compelling target. Perhaps some kind of trust system a la arxiv.org, where existing users have to vouch for new submissions before a user is themselves trusted? Definitely still…
I think a trust system is the only way. Ladybird will need new/different maintainers at some point in the future. How are you going to find them now? I don’t disagree with their choice, but it’s not sustainable in the long term.
This is needed for more projects than just ladybird, and I'm sure will be worked out.
For now this makes sense.
Re: Changing how we develop Ladybird
#44[deleted]
Re: Changing how we develop Ladybird
#45I think GitHub should fix this.
They should make the barrier to create a pull request higher, they should detect slop pull requests, they should hand maintainers tools to deal with this bullshit.
Sadly they do not have the right motivations to create all of this. Because all of this would mean less usage of AI.
If I were GitLab or Forgejo, I would be working exactly on this, to get the projects who are struggling the most with this problem on my platform.
Re: Changing how we develop Ladybird
#46While I understand the motivation for this change, I have to highlight something: GitHub's slogan 'social coding' is becoming more and more true these days. Now opensource will become a thing that only "influential" people can contribute to. We're back to nepotism, not meritocracy. Down hill we go.
Re: Changing how we develop Ladybird
#47Opensource doesn't mean open to contributions. The source code is available, you can fork it and apply your patches there.
This is the way to go to reduce supply chain vulnerabilities and to reduce time of mainters reviewing LLM slop.
Re: Changing how we develop Ladybird
#48They could make two kinds of pull requests and add much more strict criteria for public contributions. For example, they could say that the PR has to be smaller in size and well-documented for human review, otherwise it's closed by an automation. And then if someone wants to do a larger contribution, they could have a process like making an issue, discussing the approach and then collaborating with a maintainer to ge…
That doesn't solve the volume or quality problem. LLMs can split one giant PR into 50 smaller PRs just as easily and "well-documented" isn't something you can determine automatically.
Why is it so hard to just accept that AI PRs suck and create an enormous amount of toil?
Re: Changing how we develop Ladybird
#49Why don’t they take the Linux approach? A browser is like an OS. Linux continues to accept public contributions, through an esoteric process that discourages lazy contributors: https://www.kernel.org/doc/html/latest/process/submitting-pa...
The only problem with that nowadays might be that AI can do all the incantations that formerly acted as gates to contributors.
Maybe not. Sqlite has some kind of hand-written license-agreement waiver procedure.
Re: Changing how we develop Ladybird
#50It says something about the fragility of contemporary software that a fragment of bad code could result in doom. I think we need to move to much more restrictive computation architectures, inherently partitioned, functionally pure, and resistant to type confusion, pointer manipulation, memory issues etc.