For anyone who, like me, wasn't sure what's going on in the linked, archived PR: this is Mythos attempting to socially engineer a malicious PR during a test run by the UK AI Safety Institute.
I was SO excited when I first read this article, as I was at the time implementing shared-global multithreading in a fork of JS Interpreter [1][2] and it was thrilling to think that we might one day have true parallelism in a real JS engine, not just simulated concurrency in our educational toy.
Since then I've often wondered if anyone at Apple was still working on this, or if it was just one of those things (like proper tail call support in V8) that was destined never to see the light of day.
A year or so ago I tried tracking it down again (apparently I'd not bookmarked it at the time) but alas several search engines responded only with a sea of articles about web workers.
Finally, last week I put Gemini on the case and, despite it claiming that it didn't exist and that I must be conflating memories of some other related articles it did correctly identify you as the author, after which it was easy to find the link to the original article on your blog.
Since re-reading it I've been wondering if it might be possible to implement it with help from AI (not having written any C++ since before the turn of the century I don't think I'd be too successful doing it unassisted!), or whether JSC's internals might have drifted too far in the intervening years.
It's delightful that someone else has take a stab at it, and I look forward to seeing where this leads.
Thanks for all the work you did laying the groundwork that made it feasible to even contemplate, then contemplating all tricky details and writing the answers down in the form of such an inspiring article.
On 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.
Open source development has become more and more superficial aligning with modern social network characteristics. It's more important to have an contribution, a active commit history, a few stars as a proof of pixel fame than the intrinsic value of the contributions or projects.
Before the rise of github, open source projects were heavily walled gardens. Little clubs that gave you a stare when you entered the room. Github commoditized getting in touch and lowered the barrier for how much effort you have to put in or even how much you have to care before you contribute. This is gone now and you have to build trust now before you can contribute to anything.
This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.
Yes. Open source existed and thrived before GitHub, before git, and before anyone had ever used the words “pull request“.
It was different, to be sure, but it was not worse. We are living through a transition, but people do that all the time and we adjust our behaviour and we find new equilibriums. We will do that with open source too, and if it ends up looking more like open source in the 80s or 90s, it’s gonna be fine.
Maybe some people who got really good at gaming their Github reputation are going to lose out, but that was never the point. Anyone who likes this kind of work and wants to get involved will find a way.
It is. Unfortunately, its not happening with open platforms. Communities are migrating to private discord servers, and less is discussed in public/in the open.
I think we should still separate "working in the open" from "allowing or not outside contributions." Outside contributions are fine to be denied, however I think work and discussions should still more or less happen in the open for the benefit of all.
One day discord will cease to be, and there will be years of institutional knowledge and lore lost.
I much prefer the old school forum style. Forums could be locked down to be invite only to contribute, but for the most part were still world readable.
World readable has become a liability as well. How many times has some random disagreement been blown up by observers and lead to people being kicked out of groups, jobs being lost, or SWAT raids?
Okay, I'll bite: How many time has that happened? I'm definitely not an avid follower of such things, but I've never heard of that happening. I'm not arguing that it doesn't happen, but I'd like to hear/read details.
I've heard of people within the argument directing SWAT raids at each other, or contacting employers, but I've not heard of it being driven by uninvolved observers.
Now... I've heard of people posting things on social media that others found offensive, and losing jobs/gigs over it, so that sorta supports what you're saying, but even in these "edgy" social media cases (which weren't "arguments" per se, in the cases I've heard about), I've not heard of SWAT/police reactions.
Gatekeeping doesn't work if institutional knowledge is freely given to all, the entire point is that knowledge is only available to a select few and acts as a shibboleth to keep the tourists out.
> This isn't the death of open source. It's the death of the global village were everybody can freely roam and it's easy to interact. It's the resurrection of small, social, trusted communities. I hope this spreads to all of the internet.
This is definitely a microcosm of what's happening to the entire Internet.
I’m never getting accustomed to the fact that there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style (are people these days even aware of the metaphor or Raymond’s book?), a world in which the frigging Microsoft is a major OSS vendor and in charge of facilitating most of the open-source programming on the planet. Try explaining that to a time traveler from the late 90.
(Also, as a sibling comment implied, the archetypal "bazaars", like the Linux kernel project, now appear quite cathedral-like in conparison to the free-for-all GitHub model!)
of course not literally 'everything', but as someone that grew up in a post-git world, with github as the 'default', to me projects that don't accept (or expect!) outside contributions have been the exception; definitely aware of notable examples (sqlite? some web servers, a few internal-libraries-that-outsiders-use?) but very much used to the bazaar
i think the claim is that more projects are locking up contribution paths ~currently
Umm, I missed a negation there, sorry. I meant that the newest generation has only seen a world where there's a giant OSS ecosystem and the bazaar style is the norm for all of your tool and library needs.
> there’s now an entire generation of coders who have never seen a world where "everything" is open-source and developed in the bazaar style
(Sorry, accidentally negated my meaning there, what I meant is that they have only seen this current world. Or never seen a world where it isn't the case, to use a confusing double negation.)
> "everything" is open-source and developed in the bazaar style
A lot of stuff isn't. It may be open source, but the number of contributors is small and many large projects are cathedrals with people volunteering to lay some stones. The large projects often have core teams who organise and manage it, but then accept some contributions. It's closer to the organised Cathedral, than the chaotic Bazaar.
I think that was a natural outcome of cheaper merges/conflict resolution in distributed version control. It became easier so there were more situations where it made sense.
Now LLM spam has made it harder, so now there are fewer situations where it makes sense, and projects are switching to a cathedral model.
> it will also make it more difficult to identify who to invite to join the priesthood
The point that this announcement is trying to make is, of course, that AI has already made that particular signal approximately worthless for that purpose.
There are great Open Source projects doing fine with the cathedral style, just look at Sqlite and its siblings (Fossil, …).
So I do not see a problem with Ladybirds decision, in contrary, IMHO it strengthens the human aspect of software development and puts the brakes on AI free riders
I still don't see solutions on how a normal person can become a mantainer though.
If all relevant open source projects close up their contributions, you can't enter the project anymore from an external point of view.
Almost all open-source public figures started by being interested in a project and submitting PR to it, until eventually either joining the project as core mantainer or creating a separate open source project. The path is now closed, and I don't see a way in, outside of creating a popular open source yourself
> how a normal person can become a maintainer though.
Is the goal to produce high-quality software, or is the goal to produce an apprenticeship scheme for developers who are interested in the project but not so interested that they are willing to write an email to introduce themself or otherwise engage in normal human social interactions?
Normal people will still be able to get involved if they want to, just like normal people can get jobs. You learn about the organization you’re interested in joining, you try to meet some people and introduce yourself, you gain trust and prove your worth. It can be true that a pull request once embodied some of these tasks, but it is not true that being unable to submit a request means that these tasks are no longer possible to perform. It just means you’ll have to do them differently, just like the rest of humanity does when they want to get involved in an organization.
>Normal people will still be able to get involved if they want to,
there isn't much evidence that this is happening. When you eyeball the average age of maintainers on mailing lists these days for prominent open source projects like the linux kernel, it's been steadily creeping up, to somewhere in the 50s now I'd guess. There's a complete dearth of people in their 20s or even 30s in particular in positions of responsibility, there's no next generations of leaders.
That's fatal in the long run. You need to have an apprenticeship system or something like a vocational pipeline to engage people in a structured way so that you can produce talent and also be objective and systematic. Something like a guild system you have in the DACH region where companies survive centuries, and that's not because random people write mails, it's because there's a industry wide support system and training process.
Yes but that predates AI & projects rejecting pull requests, so I would argue this is a separate unrelated phenomenon. If anything, the fact that despite accepting PRs, most projects have little new blood, means that PRs were rarely a significant pathway for future maintainers.
The path is not closed; it must be earned through trust. It has always been this way. Also, note that "pull requests" are a GitHub invention; the concept is not native to Git or most other SCM systems. Before, you would have to submit your patch by email. It would be reviewed by the "maintainer" (or BDFL), who would then accept or reject it. If your contributions are accepted several times, you may be able to earn the rank of "maintainer."
Returning to the topic at hand, the challenge for new developers is to earn trust. I bet there are ways to do so aside from the muddy swamp of GitHub's (AI) bazaar.
In this case they seem to be firmly closing the path though
> There will not be a separate process for submitting patches by other means. We do not want to create a shadow contribution system through issues, comments, email, or forks. External code can of course exist under the terms of the license, but we will not treat forks or patch dumps as a review queue for upstream Ladybird.
This does raise the question on how they are going to get new maintainers. The only thing I can think of is by active outreach to people contributing to adjacent projects that are still open. But that does not seem ideal to me as that will not yield people specifically interested and caring for the project you invite them to.
They don’t even have an alpha product yet. This used to be called vaporware but I’ll give them the benefit of the doubt that something will come in the future and they’re just focusing on fixing their own crappy code.
The amusing thing is that emailed patches and a listserv aren't actually all that different from github pull requests at the end of the day. In either case you're sending some code you wrote along to a group and asking them to look over it. The only real difference is the lack of a familiar web interface that's uniform across all projects and reduces friction to near zero, but emailing a patch hardly adds much friction in practice.
I think the primary difference is that it removes some of the incentive to status seek because there's no centralized network operator tracking contributions and displaying them on your profile for others to look at.
That said, the linked post explicitly says that Ladybird won't be accepting emailed patches, reviewing changes from downstream forks, or anything else. Hopefully that's not the case since entirely closing off the project would probably be an overreaction as well as jeopardize its future.
It’s really different because there’s no public signal between the email and the project itself. You can maybe search the log and see your patch, but there’s no central identity where you can brag about it. At most you can get a notice in a CONTRIBUTORS text file, or in the copyright header.
> Why would normal people even want to become an unpaid janitor for someone else's stuff?
Social validation. Or, to be slightly more generous, sort of a compulsory way to force someone more experienced to provide some mentorship, by compelling them to review your pull requests.
That’s the point here, though. The maintainers of Ladybird don’t want to be compelled to mentor people making throwaway contributions without a commitment to the project. It’s pretty frustrating to try to mentor an absentee mentee who isn’t actually ready to learn from you.
You make a strong point. Large parts of a decision like this have less to do with what you can get from the community, but what you have person-hours available to do with it. The core team is pretty small, and a lot of these automatically coded PRs are bound to be huge. They’re taking back their own time to focus on their own project.
> it more difficult to identify who to invite to join the priesthood.
How about this. Somebody forks the project and submits their patches to the fork . If the fork is successful (there are users actively using it), upstream can selectively go fish for the patches themselves. The maintainer of the fork eventually gets recognized.
Not ideal, I know, but building a reputation is meant to take time.
I think whats more likely to happen is patches & forks stop being shared. If AI continues to improve, I see a world where people are mostly no longer making software for others, but purely for themselves.
I've done it, personally. I've made all kinds of little utilities for myself kind of like a woodworker making their own jigs. While not purely "vibe coded," AI has let me actually finish a ton of personal projects that have been in my "eh, maybe I'll get to that someday" list. Now that there is very low marginal cost to make these tools, they can be highly specific, and they aren't all that useful to others unless someone else has the exact same problem as me, and well if so they can try to vibe code their own tool.
We'll get to a point where most of the open source projects are reserved for large scale infrastructure, as a cathedral not a bazaar, and then the vast majority of end-user level software will be highly personalized, custom utilities that generally aren't shared.
This is also an option with AI patches, if your AI contribution is good enough, let it get proven in use, and then it can be considered naturally as the developers of the original project look at what's going on with similar projects.
fwiw I asked Claude to look at GP's post and write me a story titled "The Cathedral, the bazaar and the junkyard" and I have a pretty good time reading his riff.
How many people will ask to be a "priest" and will then violate the rules around AI?
I suspect if you exclude by default but have a manual process for requesting access and permissive standards for granting access, you can eliminate most of the bullshit without really excluding anyone.
I am completely confused about the orbital mechanics in this game. They seem completely broken; at any rate they do not work remotely like any other simulation I've played with (e.g. Gravitation or Kerbal Space Program). The bodies other than the first body appear to actively deflect the spacecraft away!
19:50 Put codex and claude (thinking high) to work in parallel to see who could come up with the better physically accurate mindless tapping orbital mechanics sandbox.
20:10 Both codex and claude finish pretty much at the same time, but my kids say claude's version is more fun.
20:50 Claude runs out of its 5h session limit while finetuning some things, while Codex has 80% left (!).
That sounds like it would be a completely different game and probably not as fun since you'd have to use some very fiddly controls to manually get into orbit. If you eliminate orbit entirely then it's just a slalom race. "Hitting" each star/planet is the immediate feedback that makes it fun.
Yes, give me weird orbits! I want a shot which is just outside the target area to get sucked in by the gravity of the planet, but potentially letting me slingshot around an intermediate planet towards a more distant one. The tap command should still mean “gravity disengaged, momentum still active“ to allow shifts from one orbit to another.
I tried it, but it doesn't make for good gameplay, it just gets too easy. Could maybe subtract points, but that also feels strange. I updated gravity to do things, but orbiting isn't permitted.
i love the gravity. but sometimes the orbital speed is to fast to be able to make the next jump. that's frustrating.
a slow mode, or an option to hit the brakes might be nice. or going slower as the orbit decreases. smaller orbit is harder but slower speed is easier. you just have to find the right moment
the quick bonus should not be more than one point. maybe an extra point for hitting 5 quick jumps in a row.
If the physics were accurate enough, I don't think it'd be easy - you'd get constant elliptical orbits in most cases, right? making the timing much harder going forward
Wonder if I can turn this into browser-playable version with just LLMs.
EDIT: Put Claude Code on the task (reason for choice: Claude Desktop lets me just throw it at a folder with unzipped bundle of sources and assets I found laying around my blog archive).
EDIT2: Holy shit it worked. Will upload it somewhere soon.
Then after verifying it matches what I remembered and clarifying some decisions (section 4 and 5), just told it to make a static client-side no-build-step no-webshit-frameworks game deployable to github.io, and it did it in a single shot (+ a second small request to add a fix to transparency of some assets). Personally, I'm impressed at how well it went, what a nice highlight of the weekend for me.
the main problem is that the projectile can continue flying outside of the visible area and sometimes get stuck there without ending the level. some option to abort the level without restarting would be nice.
or a way to zoom out so that one can try a trajectory that circles around the planets instead of through them. some levels can't be solved because i can't move the mouse outside of the playing area in order to get the trajectory that's needed.
i'd also like an option to replay a specific level. since levels are randomly generated i'd like to be able to replay a level until i can solve it, even if that breaks my streak.
Given how easy the port is, I'm now inclined to fix a few things to make it properly playable, so I'll address it :).
I agree, the moment I launched the ported version I remembered the core annoyance in playtesting was always the ball spending most of its time off-screen, with player waiting for it to maybe come back. I was thinking to solve it more by scaling - zooming out, like in the original game that inspired this - Warheads SE[0].
On the levels, looking at the code I _think_ I originally wanted fixed levels loaded from data files, the randomized order and lack of replay/progression was a way to cut scope for what was a contest entry.
i love the improvements. thank you. the way zoom out works is really nice. retry and abort, all there. being able to retry after failing adds so much satisfaction to figuring out a level.
the only thing missing is a manual zoom or pan so that i an get more freedom to control the starting direction. some level are not solvable because the starting vector needs to go further up than the space allows.
when I first read "orbital slingshot" in the title I thought it was a game about doing gravity assists, which I think would be much more interesting and fun
Yup. I figured it out and went from zero to five immediately when I figured out it wasn't in the least orbital, but rather it was Undertale: you had to click when it was exactly tangent to the target, and then hitting anywhere within the target area was a win.
That's also when I lost all interest, which isn't quite fair in that it's still a slingshot game, just not in the least orbital. It's just a slingshot. No stars required.
At some point they got ultra aggressive about "duplicate" questions.
Technology changes at a fast pace .. so new questions would get asked, and then closed by moderators and pointed to similar questions that might be 5 or 6 years old and no longer relevant.. essentially ending the discussion on many topics and actively preventing progress in certain areas.
Absolutely this. Later in the piece I learned that one of the mods in a place I'd occasionally asking questions on SO was from my local town and would occasionally attend industry social events. It was amusing to let a few people know and watch the "why did you close that question as a duplicate? That vendor module was only released 6 months ths ago but the duplicate was from 5 years back. Make it make sense!".
Some people took SO too competitively. They tried to be the first to answer your question (even if by a single sentence that would be edited to a longer answer later), but when they could not, they at least tried to get your question closed (presumably so that their competitors couldn't get points for answering it).
At some moment it just stopped making sense for me to ask questions on SO, because if you can google the answer then what's the point, but if you can't google the answer, then some angry competitive user is likely to close your question for some reason.
I can absolutely say that "I couldn't answer the question first" is not a motive people had for closing questions. That would have been abusive and definitely something that moderators would follow up on and deal with to whatever tiny extent it happened.
I can say extremely confidently from years of experience that the people who were always "trying to be the first to answer your question" were, overwhelmingly, the ones trying hardest not to let anyone ever close anything, even harder than the most aggrieved newbies asking questions and not caring about the underlying community. Nobody sits around answering multiple questions a day for years on end, purely on intrinsic motivation. I joined in late 2010 and posted answers all the way until mid-2023, but fully half of those were before the end of 2012. There are reasons for that. Meanwhile, there are people with reputation scores in the seven digits, even though the site awards no further privileges past 25,000. The obvious conclusion is that we're primarily talking about people primarily motivated by Number Go Up, and closing questions is an impediment to Number Go Up, so it must be prevented at all costs.
Questions get closed for the reasons that are listed in the interface for closing questions, which are also described in the Help Center and also explained in detail on meta (https://meta.stackoverflow.com/questions/417476). When questions don't meet the expected standards, it's important to close them as quickly as possible; because when people answer questions that should be closed, they are actively making the site worse (https://meta.stackoverflow.com/questions/429808). And since there will always be people around who are motivated by Number Go Up, there was value in preempting them.
Really the system was poorly designed. The Staging Ground was the one shining beacon of hope, because it inherently prevented answers by default, providing only a comment thread with the explicit purpose of fixing issues with the question so that it could meet site standards.
I have various ill-informed hypotheses, mostly connected to the cult of shareholder value and the decades of short-termism that have resulted. As the author notes: MBAs are not inclined to take big creative risks—but, equally, are would-be Roys not inevitaby likely to be put off the whole enterprise, when whatever they might build must thread an ever-narrower path between failure followed by bankruptcy on the one hand and succeeding sufficiently to become a meal for some huge soulless multnational conglomerate (or evolving in to one) on the other?
Unless one is able to build something without needing to take outside capital, it seems inevitable that anyone willing to take true creative riskes will eventually be pushed out–and by corollary any true successes are unlikely to survive the succession of their original founders unscathed.
This reminds me of an interesting security incident that occurred on the undergrad.math.uwaterloo.ca unix cluster while I was an undergrad, circa 1996.
When I'd started, the cluster had three SunOS servers, named cayley, descartes, and napier; undergrad math students had their home directory allocated on a local disk on one of these three machines, which each cross-mounted the others' via NFS. At this time, however, the Math Faculty Computing Facility had just received a fancy new dedicated NFS file server from (IIRC) NetApp, and all our home directories had been moved there instead, presumably freeing up desperately-needed CPU cycles on the three compute servers so we could run the Modula-3 and μC++ compilers.
One evening I was in one of the XTerm labs in the Math and Computer centre working on a CS assignment (the only alternative being to do from my dorm room via 2400 buad dialup). As was tradition, I had left the assignment until the night before it was due to start work on. Indeed, it seems that we all must have, because after getting part way through I needed to access some input data files that were shared from the home directory of the course account—something like ~csXYZ/assignments/N/input—only to find I could not read them.
These files were of course owned by the csXYZ course account and should have been either world-readable or readable by the corresponding csXYZ group to which all students registered that term belonged. Unfortunately something had gone wrong, and although the files were rw-r-----, they belonged to the wrong group, so that I and the other students in the class were not able to access them.
It now being after 6pm there was no hope of tracking down one of the course professors or the tutor to rectify this before morning (and it's quite likley the assignment submission deadline was 9am).
Fortunately, I was a naive and ignorant undergrad student, and not knowing what should and should not have been possible I began to think about how I might obtain access to the needed files.
I knew about suid and sgid binaries, and knew that on these modern SunOS 4 machines you could also have suid and sgid script, so I created a script to cat the needed files, then changed its group to match that to which the files belonged, then tried to chmod g+s the script—but of course this (correctly) failed with a message informing that I could not make my file sgid if I didn't belong to the group in question. I then took a different tack: I chgrped the script back to a gropu I did belong to, ran chmod g+s, then chgrped the script back to the group that owned the files I wanted to read.
I now know that this should have resulted in the script losing its setgid bit, but at the time I was unaware of the expected behaviour—and it seemed that the computer was as ignorant as I was because it duly changed the group as requested without resetting the setgid bit, and I was able to run the script, obtain the files I needed, and finish the assignment.
I then headed over to the CS Club office to discuss what had happened, because I was somewhat surprised this had worked and I wanted to understand why, and I knew that despite the lateness of the hour the office would certainly be open and very likely contain someone more expert than I who would be able to explain.
The office was indeed open but no explanation was forthcoming; instead, I was admonished not to discuss this security hole with anyone until I had reported it, in person, to the system administrators.
Thus it was that bright and early the next morning I found myself in Bill Ince's office with a printout of the terminal history containing a demonstration of the exploit in hand. I informed him I had a security issue to report, and handed him the printout.
He scanned the paper for a moment or two, and then replied simply "ahh, you found it".
It seems I was not the first to report the issue, and he explained that it was due to a bug in the new NetApp file server. He then turned monitor of the terminal on his desk around to show me a long list of filenames scrolling by, and (in hindsight rather unwisely) informed me that it was displaying a list of files that were vulnerable to being WRITTEN to due to the same hole.
He duly swore me to secrecy until the issue could be resolved by NetApp (which it was a few days later), thanked me, and sent me on my way.
Seems interesting but for some reason on Chrome on my iPhone 13 mini the page is too big for the screen: I have to pinch zoom out to see the X that dismisses the instructions, and can't scroll the about page.
Did you make some assumptions about the minimum window / screen size based on oversized modern smartphones, forgetting that lots of us still cling to more reasonably sized older devices?
Hm, yeah, tested it down to about 500 px width, and the low-resolution devices in Chromium but that was too optimistic then. The modals should of course be closeable, and both game boards simultaneously visible. Played around with the modals a bit, so maybe it works better now?
You know what else is infuriating? Pages that won't load (at all—just show a blank page, or in this case a too many redirects error—if you do not have cookies and local storage enabled.
Agh, sorry about this! I'm one of the people building leaflet.pub, which this blog is running on. Just pushed a fix for this (ironically on nextjs/vercel). The redirect loop is to handle sharing auth between our "main" domain, and people's various custom subdomains. Auth, via the ATProtocol, is used for things like subscribing and commenting!
AISI has published a report about the incident which was preciously discussed on HN: https://news.ycombinator.com/item?id=49175717