There was a social movement aspect to Linux in its earliest days, as in, the days before kernel 1.0. Hell, before he got the big bux to finally unshackle himself from Finland (and his communist father) to heartland of fascism, paedophilia, and capital itself.

Linux is still tiny versus Windows on desktop. Steam still shows it around 3% - a big improvement, but even Firefox is more popular. Perhaps that will change more as governments seek to leave Windows following the shitshows of migrating from XP, 7, and 10, but right now the market is undoutably locked down by Windows.

No doubt steam isn't the best metric but it's not likely to be far off that number. The kernel is only dominant due to servers (license free and its early adopters being UNIX sysadmins) and embedded/mobile (configurability letting it run on anything capable of conducting electricity) - the rest have never been central to Linux's success, nor the reason why massive datacenter stakeholders pay inordinate sums of money to the Linux foundation.

the most nieche youtube rec i will ever make with confidence you will love it: writing a forth-style language compiler in python by a russian programming nerd

The capital is behind Linux, and as long as it fills their use cases theyll keep putting their engineers on it no matter the slop. Though the same was once said of Unix and Windows, and one day Linux plopped up and got big because it solved the problems that they couldn't.

It could end up being BSD, or some ABI-compatible kernel like Asternias. My money is on something that lets users and devs run their software and drivers without complex setup - like what WINE & Proton did for Linux desktop, but even more impactful because the server software that runs the backbone of the internet is where the money is.

In twenty seven, What once was old is now new, And the people cry

Or idk maybe haiku is also sloppified. *BSDs are cool. I used to drive OpenBSD, maybe I'll try netbsd like is mentioned.

Or...

HexbearOS when?

If the code is good enough you wouldn't know, but then it's likely the LLM code was audited and fixed by a skilled human so 🤷‍♂️.

In my experience there are smells:

• Comments are oddly explanatory of basic concepts.
• Making an unusually large number of changes in a single commit (specifically, changes that arent related to the goal of the commit)
• Writing new infrastructure code that duplicates the work of old code for no reason.
• Using old library or language conventions unexpectedly.

Most importantly:

• A contributor who has no idea what their code does.

A lot of it you learn from using AI yourself. I use it for inline hints, and i see what goes wrong in that and from testing agentic crap - the stuff that stinks of bad AI use that you can then see in the work of colleagues.

If you ever had the (dis)pleasure of reviewing code from lowest-bidder outsourced developers in the early 00s, you will understand the garbage LLMs try to shovel into your face with the same exact confidence. It's not just the code that's sloppy; the commits, communication, and even the original author's intent^[that is, if there even is an author under the Simulacrum], can be just as sloppy. This makes review harder because you can't reliably understand the thread of changes because the LLM is hallucinating^[Yes, LLMs hallucinate everything. Some of those hallucinations are useful.] the whole thing. I have to not only check if libraries are made up, but if those libraries are hallucinated and typo squatted by hackers. I have to check if they are using other helper functions I've already written or if they just make up more! Oh the LLM split up a function into several others that are useless on their own and called it refactoring. Or just spinning and spinning and spinning and spinning...

But the thing most frustrating is how much Roguelike development has become. Is Claude going to fix my problem or TPK my repo? Do I just "need another run" to get to my goal? Better CLAUDE.md? Skills? All this yapping from a RNGesus is turning me into a digital Roman.

Well the latest models tend to overengineer things and leave a lot of superfluous docs and comments. This can be mitigated if you give the slightest bit of a fuck and actually somewhat read what was generated, I think the best telltale sign is if it's a new contributor with a large and complex change that would be generally completely out of character for a new unknown contributor.

The Linux kernel gets a ton of PRs constantly. My big issue with LLM code is that it is really good at appearing to be thought out, but actually reverse engineering it can reveal major mistakes.

A good reviewer should still catch them, but it takes longer since the "code smell" is different. Humans will usually make consistent simple mistakes while LLMs will sometimes use advanced patterns to make the same mistake.

The fact that these take longer to review, are usually much longer in general, and are appearing at an incredible pace (1hr to generate, 1 day to review) creates a backlog that becomes unbearable to review.

A lot of open source projects have banned them for this reason, but the ones that do allow them tend to use LLM reviewers to help clear the backlog which is a whole different ouroboros of an issue.

It occurs eventually once the slop enjoying programmer is de-skilled where they only glance at AI output and start losing track of the bigger picture.

The most obvious one for code is the "comment above a line of code that describes exactly what the code does"

# This does A with B as an input
DoA(B)

afaik LLM code is usually unnecessarily verbose and tries to include libraries that typically wouldn’t be necessary.

But also it seems that after writing work emails, writing code seems to be the thing LLMs do best.

i feel like ARM desktop computing improved somewhat

I actually think we're at the tail end of the current decade long dark age. The barrier to "can't use photoshop on linux because adobe is an asshole and also costs $200/year" could be gone next year. There is a vibe coded multi-platform rust clone that you might say is 50% done and already has optimistic reviews from real photoshop users. many walled gardens and enshitified apps are at risk now.

silicon valley style tech companies want to use LLMs to ship you walled garden ball and chain slop as fast as possible, paying as few workers as possible, to steal the highest margins from the working class as possible.

the open source community wants to use LLMs to ship the safest, most privacy respecting, and otherwise highest quality software possible.

the LLMs themselves do not force you to ship low quality code. it's your choice to engage in solid engineering principles or not.

In high profile projects like the Linux kernel, probably yeah but I think people are vastly overstating the quality of the code the average developer writes and also their overall knowledge and skill level, I've seen some shit early in my career where looking back on it now I wish I was reading AI slop, and this was software that earned millions a year.

Fact is a lot of important code that a lot of people depended on has always been kinda shit and yet it worked because there was enough manpower to keep it clanking on.

Are you saying the article author is just being ungenerous,or misquoting him entirely? Because it seems from the quotes presented like he did not say that new contributors are likely to be LLM slop, just that if their contributions are of "low quality" (subjectively) they should receive low priority. Amid the mountains of AI slop this means humans attempting to learn will likely be ignored and receive no (human) review. For the Linux kernel on its vaunted high horse, that may be acceptable or even desirable, but for open source in general it's not, and for open source projects trying to be free of corporate capture, a more pro-social approach is needed.

I feel like you've either misread Linus' orientation towards LLMs or the author's usage of the word slop if you think there's any chance of a moratorium on LLM patches at this stage, when they are not only already happening en masse, but removing the requirement that they even be disclosed.

The author is certainly not looking favorably on Linus' statements, and they say a few things which give me pause about their accuracy and knowledge level, but overall I find myself agreeing

I found this bit interesting:

Torvalds added that he does not want to scare off people who want to write code; his message is that you have to either put in the effort to learn, or put a lot of money into an LLM to participate.

… Torvalds and others repeatedly said low-quality contributions from new developers should receive low priority, and that the community should stop trying to make contribution easy.

All the corporate contributors are the primary ones coming in with a wave of LLM slop code, breaking the social structures that made the patch review process function, not just the random people from the internet who are more easily ignored. Ive seen it in reality, the author is correct at least about the breakdown of processes precipitated by slop just leading to more LLM usage. No human has an inherent desire to write thoughtful or helpful reviews for and teach a machine that cannot learn and does not think. Interacting with such is a very degrading experience, IMO.

Turning away randos coming in with poorly written patches was always part of the gig, but the influx of those was also a lot lower when it was just humans submitting them.

Sounds like the right policy for after the bubble pops, not before.

important tools like rsync no longer work because they're also vibe-coded now

The causal relationship between these two things are not so clear. rsync is mainly maintained by a single main volunteer and regressions in software releases are common enough that LTS and rolling release are two separate categories for a while now. I think it's more accurate to say that tools like rsync are so chronically underfunded that the gap is being filled with corporate products rather than real labor. I generally don't think that framing "AI" as harmful by appealing to a sense of software quality is often not the real issue and gets debate-bro'd to hell and back by boosters anyway.

GTK4 and QML apps use more system resources than electron apps

In my anecdotal experience this isn't true at all, every electron app regularly pages more than a gigabyte of memory on startup and I've never experienced this with with GNOME or KDE applications. This is genuinely the first time I'm hearing about this.

that's all anyone seems to want to develop with for some godforsaken reason, etc. etc. etc

Theyre the big names, integrate into an ecosystem, and most of all, writing raw x11 code (or raw Wayland protocols? I'm not sure how things work over there, I'm still in X land, running motif-ass lookin software, and loving it) is a gigantic horrifying minefield of footguns.

The frameworks are fairly frustrating, but tbh I understand not wanting to write raw x11 very very well.

1. Reviewing slop code is boring as fuck and strips any joy out of the work
2. Nobody reviews slop code
3. Slop code is produced by the most insufferable talentless hacks ever who cant take a crumb of feedback

All its going to do is burn out the maintainers and theyre gonna quit. Same as is happening in any corporate job where knowledgeable seniors are being pushes out by naive juniors and all ai code is implicitly trusted. All work is produced by prompt monkeys who pray it doesnt break and like all programming decisions the consequences won’t be seen until a few years down the line