Yes it's the same people who retroactively changed the blockchain consensus rules in order to undo someone else's transaction that was financially damaging to them. (The DAO incident)
From observation, it seems Starbucks/High-end coffee chains attract easier looking staff. At the end of the day, you are going to get the higher paying job, and the higher paying job can afford to select the easier looking ones.
A Claude/OpenAI sub is still cheaper than DeepSeek API pricing though. Also, I suspect Claude and OpenAI models to be way larger (probably in the 2-3T range) than that of Deep Seek.
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.
Just remember that for however bad our code is (and I have no issues saying that most of our linux driver code is absolutely horrific, for now) it's better than Asahi code, because our code exists, and their code doesn't.
Wow man, "horrific code" can be worse than no code. Bad code can damage hardware, destroy data, allow exploits, etc. all manner of bad things.
Unless your meaning is that you already have work-in-progress code that you are working on to make much better whereas they have not even started, I don't see how your point makes sense.
But even then it debatable whether making bad code good is better than creating good code from the start.
Yes, being able to buy a hacked-together microwave that can explode in your face and one that is tested and certified is amazing! Especially if you’re clueless about how they’re made and you just want a microwave.
Mainline Linux doesn't run on the M4. So in your metaphor, it's more like being able to choose between a microwave of uncertain quality and not having a microwave.
Even good code is a liability. Admittedly "horrific" code is a 10x or 50x liability. Sometimes you accept that kind of technical debt because "it's really important" — e.g. the company will go bankrupt, or whatever.
(Historically, btw, this is why proprietary corporate code is often so much worse than even fairly incompetent open-source code. Because it's just not really that important to ship horrific slop when nobody's income depends on it.)
The idea that shipping "horrific" code now is somehow better than not shipping it until it is fit for human consumption works in some narrow business life-cycle scenarios, but not in any kind of user-facing scenario, and certainly absolutely fucking not any kind of user-facing OS implementation scenario... (T_T)
"Code is a liability" - is one of the fundamental tenets of programming.
So, "it's better because our code exists, and their code doesn't" isn't the brag you think it is. Yes, a quick thrown together utility is better than having to manually do something. But that's not the same for an OS, or god forbid, a filesystem.
Especially since the only reason your code exists in the first place is that they did the hard work and your project forked.
Unironically yes. I think it's great that you don't have to be as extraordinarily skilled as the Asahi developers in order to get Linux running on new hardware.
> however bad our code is (and I have no issues saying that most of our linux driver code is absolutely horrific
It's the operating system, mate. People don't just use operating systems to take screenshots and then post on social media.
> it's better than Asahi code, because our code exists, and their code doesn't
This is an especially horrific comment if you are really related to the project and this also adds to the perspective on why Asahi team might have wanted to have no nothing to do with this project and related people and their thought process. Anyway, good luck.
The models are very aggressive in finding the info they need. I had one find some API key somewhere so that it can make requests. Sloppy on my part of having API keys not related on the hard drive but was not expecting the model to burn my harddrive in a lookup for api keys.
> The most frustrating experience I had was booking a ticket online, only to get a message after confirmation: “You’ll need the physical credit card to retrieve your ticket at the station.”
Most (all?) airlines require this. In practice, it's only checked if your name differs from the name in the credit/debit card.
Other than that, the user fails to explain why booking a train is harder in Japan? They have multiple operators/lines but that's normal for a big/dense city like Tokyo.
I've taken hundreds of flights in and between the USA and EU and never once had to show anyone my credit card. In a number of cases, the ticket was booked with someone else's credit card.
For (non-Schengen) international flights, I usually have to show someone my passport.
This is for getting tickets printed on the spot, not for using the already printed tickets. People buy tickets online and have it printed later at the airport/station kiosks, which lets you prove your identity abusing the fact that customers realistically don't forge a credit card. It can be an ID/password login at the busy station using unresponsive touchscreen, or a membership card of the airline/train, or maybe even a driver's license, but CC is probably the most convenient(unless...).
I've seen swiping the CC used to buy the ticket be an option for things like printing the tags for checked bags on a flight, but it's definitely never been a requirement.
The fact that a ticket bought online must be printed on paper at all seems anachronistic in 2026. I would expect, or at least hope for a QR code saved to a smartphone as the default.
Add Oceania to that. As long as I've been able to produce the proper passport(s) and visas for my journey I've been let on the plane, throughout all kinds of complex journeys.
I have had a round trip flight recently that involved two passports, a work visa, and an ETA, and a total of 5 layovers across 3 airlines. As long as I produced the correct identity documents at any given check in desk, I was allowed to board, without ever producing a credit card.
No, if you read the fine print, you'll find that you getting on the plane might requiring showing the credit/debit card. Whether you'll be asked, it's another question. I have only been asked once for an expensive ticket, other than that, a friend told me that it's usually a red flag when the names differ.
Didn't happen to me for a domestic flight with JAL recently. I was actually surprised how little they checked; just a QR code was sufficient (although my memory might be fuzzy due to the international flight just before it).
I was never required to book a flight ticket with a physical card while booking online. And even if that's a policy, I feel like being told that before booking would be nice.
Not sure why they do this, anyone has an idea? Like, the Internet is just there, I can go and watch porn whenever I like. If I am watching your show, it's because I am interested in something that is not porn. Also, if your show has a lot of these scenes, I can't watch in many places (ie: cafe, plane, with other people, etc..)
>
Not sure why they do this, anyone has an idea? Like, the Internet is just there, I can go and watch porn whenever I like.
It's HBO. They are known for this. But they definitely went too far with Industry in my opinion.
The sex and drug scenes are much more toned down in the latter two seasons. Part of the reason why is the cast had more leverage and strong armed the writers / directors.
Great show but definitely would be better with 90% of the sex / drug scenes removed.
I am not sure why this get thrown randomly as the solution to every problem. Bitfinex major hack was due to regulation. Banks and Crypto companies don't have the same attack surface and the one for crypto is way more complex due to permissionlessness.
reply