Until the incoming administration declares that safely storing nuclear waste is woke and allows their close friends or maybe even their own companies to just dump it in a desert at a premium because the bible never mentions the associated hazards.
Or it says facility inspections cause autism and transgenderism so they have to deregulate for their pals.
Or that nuclear safety itself is a symptom of low testosterone and turns the frogs gay.
Hmmm, a radioactive desert vs an entire polluted atmosphere, I wonder which is worse...
No, storing a few cans of solid waste is decidedly NOT a real problem. However, undoing the damage we've done to the global ecosystem instead, now that's gonna be fun.
Why have you linked a bug report for a niche userland application that may be causing disk corruption as evidence against linux reliability? That seems like a pretty uninformed conclusion.
This supports my initial reply. This was an f2fs bug in a bleeding edge kernel released only seven days earlier. The thread suggests perfectly reasonable mitigations, especially for an arch user: use the lts kernel or downgrade to 6.8.9.
If you're not familiar with linux and/or don't want to deal with trivial issues periodically, don't hang out at the bleeding edge. There are plenty of boring and/or beginner friendly choices out there.
I'm not saying linux is perfect, but your conclusions in this instance appear to be uninformed rather than supported by the facts.
Ok fair point, here's plenty more of the same on stable. My point is Linux is always fine right until it isn't. Then you're back to a day of debugging your update.
Most of these links weaken your claim rather than support it. The lkml links are patch submissions in a _development_ discussion, not ordinary users running a stable distro. The f2fs bugzilla links are the same issue we already discussed, a regression in the brand-new 6.9 kernel released only days earlier, with the fix landing in 6.9.3. The suse bug is an upstream e2fsprogs issue. This is precisely the kind of issue distro package maintainers can catch, patch, or avoid before it reaches ordinary users on a stable release. The launchpad link is another development discussion, not an example of ordinary users experiencing a bug in a stable release.
Linux does experience regressions, but your argument conflates upstream development, bleeding edge releases, and stable distro releases. Those distinctions are fundamental to how linux distributions work, and these links don't support the claim you're making.
>Most of these links weaken your claim rather than support it.
Yep. Good catch, I think you win the argument. These are all distros that are under development and their underlying issues should never be called-out as handing the user frustration as they willingly chose to become a victim of the kernel.
While I don't disagree with some of the pain you describe, you conveniently gloss over the fact that gnu developed a system that worked, and then made it free to everyone to consult and use.
BSD also did it. They did it better. Maybe more modern but AOSP also did it but at a different level of binary: instead of ELF, using compiled Java bytecode archives.
The root cause is alternative libc implementations. Are BSD syscalls considered stable? I remember Go moving to use libc on OpenBSD. Solaris also has the libc as the stable interface. Linux kernel is an outlier here guaranteeing stable syscalls but you wanting to use another libc is not Glibc's problem.
Except the other UNIX systems, starting with the original one, evolved from only having static linking to various ways to connect libraries and applications.
I last used MASM back in about 1989 (with MS C on OS/2 1.0). Do you have any hints on how it has changed since then? What is nice about it, and why does the debugger not match up to CodeView?
How dare those nasty, dirty, unemployed live their lives under likely desperate circumstance. They are so much worse than corrupt oligarchs pumping and dumping their way into the greed hall of fame.
I'm getting pretty good with Emacs, but I find its Treesitter handling a bit obtuse, and the auto-installation package I found slowed the editor down a lot for reasons I can't determine. (I mean, everything slowed down, and it all sped up again when I uninstalled the package.) I'm looking forward to revisiting this when Emacs 31 comes out, though.
I also don't think I'd ever call configuring Emacs "trivial" compared to more modern editors. Matching the out-of-box experience of something like VS Code or Panic Nova requires some work. This isn't really a knock against Emacs, but I think Emacs fans -- myself included -- need to be honest about that. It's quite possible I would have picked up Emacs years earlier if I hadn't been given the impression that it was just super duper easy, especially once you picked a starter pack. It is not, it probably never will be, and I've come to believe that starter packs are actually a bad idea for most new users. If you don't understand just what it is you're putting in your init.el file and why, then if you run into problems, it's going to be way harder to figure out how to fix them.
reply