You want longterm support, not a set of pit of tree patches for 7.3 kernel that will stop working or misbehave in 7.4 or 7.10, with no one understanding why.
Besides not wanting hallucinations on my OS level code?
Or not feeling good for the intellectual theft involved in the training of AI to begin with?
Or not caring for the de-skilling of of human brains who are delegating coding to AI, and increasingly even the architectural and decision part?
Or the training material being AI degradation that awaits most code being written by AI?
Or the baragge of slop PRs that overwhelms my favorite FOSS projects?
Or deeping of big AI dependency, in times of climate and economic crisis that it worsens, but that it also risks not having the luxury of it forever?
Or the ease with which any stupid direction can be followed via AI, and the resulting always changing projects, already a problem with short attention span project leads even for big projects like Gnome?
Or the lack of deeper understanding to control all this in future generations of programmers reduced to "AI operators"?
>Are you saying "vibe-coded slop" because of the quality of the end result? Who cares if it gives you the features with good-enough performance?
There are a few significant reasons worth considering when getting down to the level of OS and hardware drivers. Long term maintainability is one. But another big one is that such software is capable of physically and permanently destroying the hardware it's operating on, with the textbook example for Macs being the speakers found in Macbooks. The only way to get the kind of performance they offer out of that physically light/thin package is to give them the power to destroy themselves if run at full force continuously but then run it from software so that they aren't run at full force continuously, but rather take advantage of the headroom that offers for very brief audio spikes whose overall integrated power still falls below safe limits. This all needs to be done from software since response of real world analog isn't instant. That enables much more range then if they were hardware capped at the maximum level they could run constantly, but it also means that if they're driven wrong, poof. The drivers have to never go to certain bad states, purely from software.
LLMs can't offer those kinds of guarantees, they don't really "know" how things work and then produce something deterministic off of that. It's even worse if, as-is the case with this sort of vibecoding effort, the LLM operator is in fact depending on the LLM for that part because they don't know how it really works either (vs someone who is just using it for boiler plate and knows exactly where the critical paths are).
Obviously everyone is welcome to roll the dice with their own hardware as they wish, and it may be ok. Or if using really old hardware one might just not care. And not all hardware is as sensitive as modern notebooks of course. Just be aware the analog world can be messy and you might not actually have the guardrails to screw up that you're used to in a higher level software environment.
>Otherwise one can also say Asahi is compiler-generated slop compared to hand written assembler code.
No, one cannot say that. Or at least not without looking really stupid.
If that issue with the speakers is documented, the LLMs of today would handle it correctly. That wasn’t true very recently. Also, assuming documentation exists is a big crutch that helps them more than us.
I prefer reliable software for the Operating System. Like, I can tolerate slop for a game or a one-time-thing of converting a doc or something. But for running the base software (your OS), I think you need better standards.
Agreed on the product. I can't make Gemini read my emails on GMail. One day it says it doesn't have access, the other day it says Query unsuccessful.
Claude Desktop has no problem reaching to GMail, on the other hand :)
> Apple does a decent job of keeping my data safe...
How do you know? Why do you believe that they're competent on writing security code but not competent enough to write a general purpose app? Is there a different company culture applied to the latter?
My father, a Turk, has a couple of close Armenian friends from Arapkir, a county of Malatya, from his childhood right after WWII. Going back 30-40 years before that period, Armenians were the majority ethnic population in many counties of eastern Turkish cities. Not sure about Persians, but having an Armenian connection in a big chunk of your DNA if you're from the area shouldn't be that surprising.
Fun fact. Yerevan, the capital of Armenia, has Malatya and Arabkir districts.
Otherwise one can also say Asahi is compiler-generated slop compared to hand written assembler code.
reply