This box has been stable enough to make money. But not as stable as my backup (also Gentoo) which runs stable and updates weekly.
Edit: my biggest source of stability issues are Nvidia drivers mis-matched from kernel. Takes a whole reboot to fix.
Also, I use ext4 since like forever, ext3 before that and have never had issues.
To be clear, my point is that these open source devs (I'm one too) are very careful to not regress. I think the software quality is very high.
The context was the sweeping generalisation that Linux devs and that they don't care about regressions, see up thread by @imiric. In that context I've not had regressions. More explicitly, for this narrower context, I've not had regression bugs in ext3/ext4.
I'm not making a claim that I've not had never had ANY issues or never have to fsck my drives; nor am I making claims that nothing has ever appeared in 'lost+found', nor am I claiming that ext3/ext4 are perfect. Nor that Linux is perfect.
Just claiming that the software quality in the Linux ecosystem is very high. I'd say better than many closed-source solutions -- which couldn't be proved anyway.
I've only been at this since 1994 and still have a lot to learn. However, I don't learn much from the "you're wrong and not good" type of conversation.
Unless you were routinely running mtree or something similar, you’d honestly have no idea.
My point here is that software can appear to be fine when it’s actually shit because most people won’t notice any kind of corner case. All you’re saying is that you’ve very likely missed the corner cases.
The combination is not perfect unfortunately. The other day, I had a CPU cache parity check failure hang vim when I was trying to close it. I had to reboot to get rid of the hung kernel thread. It would be really nice if all CPU cache levels had full ECC protection, but only some of them do.
That's exactly the point, though. Linux will "never be ready for the desktop" because of the problems that this causes. Developers of software for Linux, not to mention kernel developers themselves, do not have the kind of funding that Microsoft has to test on a truly staggering number of hardware configurations. And on the opposite side of the spectrum, they don't have the luxury of supporting a comparatively small set of hardware combinations like Apple has.
https://www.forbes.com/sites/jasonevangelho/2020/02/15/micro...
Also, Microsoft does not do internal testing of various hardware configurations anymore:
https://www.linkedin.com/pulse/20140806183208-12100070-why-d...
They rely on end users to find problems for them:
https://www.forbes.com/sites/jasonevangelho/2018/12/12/micro...
This doesn't mean Windows doesn't have hardware dependent bugs of course.
These problems can be mitigated, though. All it takes is a company willing to lead the effort and maintain a stable, limited and tested ecosystem of software built on top of a stable, limited and tested version of Linux. And/or maintain a secure runtime environment like Google has done with Android.
The problem with this is that it invariably takes away some of the freedoms Linux users expect. Personally, if I'm not allowed to run any software I want, how I want to, and terms like "sideloading" and "jailbreaking" are thrown around, it's not Linux and I don't want it. At that point you're no longer using a general purpose machine, but a machine that someone else decided how it must be used.
Besides, like a sibling comment mentioned, bugs do happen even on Windows and macOS. This is an inescapable fact of software development. I was simply pointing out how harder it is to manage this on Linux, and yet it remains usable for many people despite of it.
And even then, Apple has never been able to promise that you can keep the software features your computer shipped with across system updates. If a feature is removed, your only path of recourse is to treat your current patch like an LTS release.
However, it’s very possible for a company to build an Apple like company by creating their own Linux distro that is well tested and guaranteed to run at least as well on their hardware as Apple’s software does on Apple’s hardware.
This is the System76 approach.
Alternatively, you could create a distro that is restricted and sell it to hardware vendors who then have the responsibility to test your distro against their hardware. This is the MS approach. There’s no reason such an approach would necessarily have any more issues than MS does.
In fact, because of the open source nature of Linux development, it’s likely that the Linux versions should do better than their proprietary counterparts, because downstream companies, teams and users can test before the product is released and point out problems before the product has even hit alpha. Heck, they can even share patches.
The real problem with Linux on the desktop is that it doesn’t have enough market power to make the kind of testing MS and Apple and their downstream clients do financially worth it.
There is no reason why the server space shouldn’t have the same issues. But the Linux server space has enough money that downstream vendors clients and users are able to invest money in testing, which has meant the advantages of open source have pretty much wiped out all the competitors in the space.
In a previous job, 20 years ago, we found that the Linux USB stack was so bad that it was full of deadlocks and unprotected shared memory on 2.6. Just atrocious. And subsequent releases broke it again and again.
About 5 years after that, working for a different company, I had a well-known kernel developer tell me point blank that as long as we release our code to the kernel, they will "keep it working." When I probed what that meant, he genuinely saw no difference between "compiling" and "working."
There are various efforts to add testing/tests. Those are good. But we lost a lot when Solaris, Irix, etc. all died, and Linux has never quite gotten there, and I doubt it ever will.
If we are being honest though, in the terms that this article is arguing, "Linux" as an ecosystem is the wrong label. When it comes to stability and support, we need to think of each Linux distro as an Operating System. In that sense, things like RHEL are certainly well supported--including on the desktop. If your app targets RHEL, you pretty much have none of the problems discussed in this article. You still have a smaller universe of applications than Windows of course which is to be expected.
So, the problem boils down to "nobody is making sufficient money off desktop Linux to steward a desktop Linux distro". That is not careless devs or bad design decisions though--no matter how chicken-and-egg you try to paint it. It is simply the network effect.
Decent desktop operating systems exist and they already have large application universes and large, monetizable user bases. They appeared into a vacuum that lacked such operating systems but that vacuum no longer exists. That makes it almost impossible to economically introduce a new desktop platform. Certainly none of the commercial attempts have succeeded in the last few decades. In fact, the system that has been the MOST successful is Linux. By that metric, saying that Linux is doing it all wrong does not ring very true.
Valve is doing a lot to make Linux gaming a reality because, when it comes to the network effect, it is largely true that Steam ( not just Windows ) is the true platform. So, if you can bring Steam to Linux, you can move the users there too. It is still early days for that but it appears to be working.
On the mobile side, the network effect is very much alive as well. This is why Windows, using of course all of Microsoft's tricks, strengths, and knowledge, completely failed while the Linux kernel ( in the form of Android ) has totally dominated. And that is not for any of the reasons cited in the article. Do you think an Android app from 2008 will run on Android today unmodified? An iOS app from 2008 on iOS today? I don't think so.
I wasn't arguing that it was entirely false, but that the generalizations of "regressions are introduced all the time" and "Linux developers spend little to no time" can't be applied to the entire Linux ecosystem.
I wouldn't discredit your experience, but speaking of Linux kernel development specifically, my understanding as a user is that it's held to a very high standard of scrutiny. Rants from Linus are famous for drilling into people that "WE DON'T BREAK USERSPACE". If you consider how many thousands of lines of code are changed on a regular basis, it's an engineering wonder that it works as well as it does. In many ways Linux is a victim of its success.
The sweeping changes in Linux are amazing, but they also break a lot, frequently, and the testing approach leaves a lot to be desired. I am old and a former embedded coder, I understand how the 90s developers feel about unit testing, and I am sympathetic to the idea that test-driven-development and heavy UT in modern teams is often completely out of control, but Linux is distinctly lacking in real testing of independent units in isolation. I am aware of kunit, kselftest, etc.
But you’re just reiterating that the kernel development itself lacks sufficient testing which necessitates this. Everyone is a volunteer; the result is as you’d expect.
Look, there’s nothing wrong with this. In reality all the people who are electing to run Linux without it actually having sufficient quality for their purposes are the actual problem, who’d which there are hundreds of companies that just don’t care. We created this situation by undervaluing quality vs cost.
But it’s also the reason it won’t be a success on the desktop. The only way that happens is if windows takes an even more substantial nosedive. Things are going to have to get pretty bad for that to happen.
Looking back on how things panned out, going all in on illumos a bit over ten years ago is something I wish I had done.
addendum: by "all in" I mean as an operating systems developer.
It can be a miracle, and yet still not be good enough. Even as a business user, knowing that if I build an app and it probably won’t work in 5 years, is all I need to know about this hobbyist toy. Linux is fundamentally not ready for anyone who has needs more than a Chromebook (which also runs Steam, by the way).
It’s like pointing to a skyscraper made out of sand. Sure, it collapses every time the tide comes in, but your robots can rebuild it in 5 minutes flat, so it’s clearly ready for tenants.
Wow, piss right off you to you, too.
Linux is ready for me, and has been for decades. By your logic, I need nothing but a Chromebook.
Linux is imperfect, like you, but it's never been an ass.
For my part, I’m back on Windows and Mac. Screw the community’s arrogance more than the project. The community, as even the comments here show, does not deserve a victory.
Android is perhaps the closest to what you seem to want, although even it is much more aggressive about deprecating APIs, ABIs, and features than Windows.
The is no Linux distribution today that even attempts to deliver the interface stability you appear to want. And given the development model and business structures involved, I think it’s unlikely there ever will be.
You, and the many computer users like you, will probably never have a suitable Linux distribution. That’s an unfortunate reality. It’s not your fault: what you want is reasonable, but Linux isn’t set up to deliver it.
if one’s “criticism” is snarky or just plain needlessly rude, one shouldn’t be surprised when they receive the same in return, this is extremely basic human behavior. very very basic.
we all learn this in like elementary school, if you’re rude, people will treat you like a rude person. it’s not shocking and it’s not unexpected. its extremely basic social shit learned by even small children.
I Certainly admit that some Linux users are heavily in denial about linux's flaws, and don't take criticisms healthily, but this is a trait in humanity, not just in Linux users.
If your version of diplomacy is starting off a meeting with urinating on their flag, don't say diplomacy never works because no other countries can take criticism.
"Good enough" is highly subjective. You're entitled to your opinion, of course, but millions of people also think otherwise.
> Even as a business user, knowing that if I build an app and it probably won’t work in 5 years, is all I need to know about this hobbyist toy.
That ultimately depends on your tech stack and app features, much more than your OS. If you build a statically linked ELF binary that runs on the command line, chances are it will continue to work decades from now. If, OTOH, your app depends on a specific version of a GUI toolkit or some esoteric libraries, you might run into issues in the future. This is the same on any other OS. Microsoft does a commendable job at maintaining backwards compatibility for apps written in their supported stacks, but step outside of this and you'll experience problems. Same for macOS to a lesser extent (Carbon -> Cocoa, etc.).
Ironically, I might as well point out that billions of people think otherwise of Linux. In some countries, a few trees is “good enough” as a bridge. The IRS, of course, says COBOL is “good enough” to use as a web backend for the moment.
The weirdest thing is how people complain that engineering is a race of the bottom. Scarcely a thread goes by here without a tragedy of the commons reference. Yet inexplicably, business executives are terrified cowards when it involves free software. This of course makes no sense; you can’t have both. Either the complaints are wrong, or Linux is in fact unsuitable for purpose.
> Microsoft does a commendable job at maintaining backwards compatibility for apps written in their supported stacks, but step outside of this and you'll experience problems
Oregon Trail, a game made for Windows 95, still runs on Windows 11. (Edit for below complaint, as I’m posting too fast: You need all the DLLs that came with it on the original CD in the same folder as the EXE.)
Try installing and running any Linux app, be it even GNOME Chess, from four years ago. See how it goes. Consider my allegory of the sand skyscraper.
On that note, the Carbon to Cocoa transition mostly wrapped up a decade ago, and was completed by the majority of apps two decades ago. Try installing a Linux program from 2005 with a UI made in any toolkit of your choice.
The Linux community chases trends and kills APIs more often than Google.
These same billions, sans a very small fraction, don't even have "operating system" in their vocabulary. And as far as they are concerned, Chrome browser on one operating system is just as good as Chrome/Chromium on another operating system.
> Try installing a Linux program from 2005 with a UI made in any toolkit of your choice.
Personally I would not have difficulty doing this with containers. But there is no reason to do this at all. No sane and sober person wants this.
Fatal error: MSVCRT70.DLL could not be found.
But that's easy enough to fix, right? Just dig through Windows's package manager (sorry, I meant MSDN) trying to guess the right vcredist, and try a few and hope for the best.
To be fair, I've seen plenty of commercial Windows software ship over the years without runtime components required on the original supported OS (or with required redistributable components that had to be separately installed from the distribution CD-ROM for no well-explained reason).
For those unable to tell, I am using sarcasm in that last part.
Would you say MacOS, Android, and iPhone are also hobbyist toys then?
And by the way, if you statically compile your app for Linux it will basically work forever. Linus's mantra: We Do Not Break Userspace. These are userland problems and can all be avoided with a linker flag if it's a priority for you.
And then one day the underlying libraries will have security problems. Your statically linked application has just become a gaping hole.
And finally, you don't want your statically compiled binary to be hundreds of megabytes and take forever to launch, do you? But seeing how many people here are advocating Snap/Flat/AppImage, I guess it's not a problem? But why would you need a Linux userspace or OS in the first place when all you are doing is running virtual containers? You can run them on Windows or MacOS as well.
That said, you can just copy the .so files if you want to run the old binary.
Furthermore, binaries are mmapped, so even if it is very large, it will still launch relatively quickly since only the parts needed to launch are read into memory.
Can you stop for a second and realize your "solutions" are absolute unmitigated crap and 99.999% of people of the world wouldn't bother even if they could?
In Windows you don't have to do that. You can compile an application in Windows 11 and run it in Windows XP for Christ's sake (if you don't use new Windows APIs).
Show me a way to compile anything in Ubuntu 24 using only its own libraries and have it run in Ubuntu 6, huh? Without virtualizating/chrooting/crap like that. No, you can't? Fine.
> Not many libraries use the GPL
Let me start: Qt. Before your spew "GTK", who is going to pay for porting the code to GTK/GTKMM (since GTK is C only)?
End of your wonderful story. You really want to bend reality to make Linux look "OK". It's not. It's bad.
That of course requires updating the application when a vulnerability is found in a library, but this is no different from Windows where you have to update many applications to fix vulnerabilities in third party libraries. The number of vendor updates to fix the same libjpeg of libpng issues on Windows is truly staggering.
The Qt libraries do not use the GPL. They use the same LGPL that GTK does. You are making stuff up to bash open source UNIX machines (which is what Linux machines are).
Can you stop with anecdotal evidence? I don't care that you can make old software works. I can do as well, you know. Been there long before you even knew Linux existed. Had a nice little trip with GCC 2.96 by RedHat if you even remember that fiasco of epic proportions.
Where did I?
Or something that's available to 0.0001% of its users has become an OS "feature"?
Who are you kidding, man? What else, you gonna claim Linux is "fine" because people can write assembler code for it? It can even run on your PC?
That's not what a desktop OS is about. That's not how it's used.
> In Linux nothing even close is possible.
This is a feature of Linux. Linus Torvalds is very adamant about supporting old binaries with new kernels, even if it is not commonly done.
Nowadays all software is built on libraries and frameworks, and they have security issues and even just bugs, and you want to get those fixes. If you want to run 5+ year old software, you can now do it natively in a VM in almost any computer; so why does my shiny new OS have to run ancient binaries again?
Security is is a real issue for a subset of computing tasks. To further your point, for those tasks you can argue that constant vigilance and patching are a necessity of the modern world (an alternative and arguably better approach would be that formal verification and not updating, as often applied in safety critical control systems.) However, security is often used as a pernicious ruse for forcing obsolesence: want the latest security patches? update to the latest OS version. Oh look, the latest OS version no longer runs on your perfectly good hardware. Or similarly, oh look, your perfectly good software no longer runs on the latest OS version.
But now consider the subset of computing that does not need to involve security either because it has literally no security implications, or because it can be sandboxed by the OS (e.g. games, music and video production, architectural design, scientific simulation, mathematical research, ...) There is a large body of this kind of software that works perfectly well for any number of years (modulo forced obsolesce initiatives like "modernising" the UI or moving to the cloud). I would argue that the primary function of the OS should be to provide a stable platform for running such software securely. Yes, the user could learn how run it under emulation, in a container or VM, but then what is the purpose of the OS?
The alternative is a high software maintenance burden/cost to everyone (for applications to just keep the lights on, or users to stay current in a churning software landscape) and/or the destruction of a massive amount value in developed but no longer easily able to be run software: this value destruction here is twofold: (1) the licensee can no longer run the software that they pay for, and (2) the effort expended to develop said software is discarded.
Most businesses just want things to work; their software/hardware costs are often rounding errors when amortized over their lifetime. I'm sympathetic to users who have paid for programs wanting to run them forever, but software businesses have to make money and sell new versions, so they add new features and follow the OS upgrades. It's hard for businesses to support older software or a big diversity of versions; it's why companies mandate a standard and try to enforce it.
With Microsoft, they are making millions on OS and related basic programs, and so can afford to support things for a long time. With OSS like Linux, there is less funding and less people who are interested in running old versions. As someone who has had to keep some software up to date on Linux, it can sometimes be more of a pain to update a package (because of dependencies) them to just recompile the thing from source. The 5 years that LTS releases get are good for 2 average commercial update cycles, which I think is reasonable. Beyond that, people's skills are going to be out of date.
A statically compiled app that used Jack for audio might have problems running on PipeWire.
A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit.
The meme is wrong, don’t regurgitate nonsense. I can guarantee you my Windows app compiled in 2007 still has the UAC prompt and the audio system working correctly.
Not a single major distribution doesn't ship Xwayland by default. The entire gaming community relies on X11 continuing to work, just like they rely on x86 libraries to stick around.
> A statically compiled app that used Jack for audio might have problems running on PipeWire.
A statically compiled app that uses Jack for audio might have problems running on Pulseaudio/ALSA/OSS. Jack's never a thing that's generally available, so claiming it's a backwards compatibility issue is nonsense. If your application requires Jack, then you need to ship it.
Note that you'll also have issues on Windows and Mac because Jack - unsurprisingly - is not installed by default on those platforms either.
> A statically compiled app from 2012 that used PolicyKit for authorization might not work today when asking for sudo. Everyone’s moved on to polkit.
If you used policykit correctly you should have either used the dbus protocol, or the command line utilities. These are the APIs for userspace and they haven't changed since 2012.
Build a Flatpak, you're done. Your application can depend on a stable runtime and work on any Linux distribution.
> Linux is fundamentally not ready for anyone who has needs more than a Chromebook (which also runs Steam, by the way).
Chromebooks now cover 85% of the U.S. education market, that's most workloads. The Steam Deck is also Linux (SteamOS).
What's left in the world of Win32 apps? Specialty commercial applications like Photoshop, first person shooter games that require an anticheat kernel driver. If you don't need those, a system like Bazzite is much less user hostile than what Windows has become in the era of Windows 11.
Flatpak weakens but does not entirely remove the dependence on the underlying Linux distributon. Flatpak relies on a system service called xdg-desktop-portal to bridge apps inside the flatpak sandbox with the host OS. Applications distributed using flatpak may not work as expected if the distribution ships too old a version of xdg-desktop-portal.
Containers have been around for over a decade now. This "no backwards compatibility" meme is utter horse shit.
But, it seems that FUD about what it is capable of is still actively here, which is good to know. With frameworks and libraries, there is a 0% chance you don't have SOME update for your Windows app in a couple years, forget 5.
Now, there are lots of headwinds against Linux -- Windows is a known quantity, everyone knows the MS Office suite, people hate change and don't want to learn new stuff.
But to pretend that Linux is a house of cards because there are sometimes issues that cause troubles is not being honest. Even Windows can have big issues, or have we forgotten the CrowdStrike outage earlier this year?
All OSes have always had issues; that's why all of them have patches and updates.
Apple on the other hand got them to switch to userspace:
https://www.crowdstrike.com/en-us/blog/crowdstrike-supports-...
How many people are running a locally-installed office suite at this point? Mailing files around seems archaic for most purposes. At my prior (open source) employer, even we had mostly given up on running local office productivity apps.
Your entire post begins with a weak "no that's not true", and then the entre rest of the post is explaining why it is true and will never change.
Just check this bug tracker. Just this one. Bug report on top of bug report caused by a fix which was caused by another fix.
Sadly it's not just one bug tracker, I keep an eye on many of them.
Of course in the magical Linux land if "It works for me", then the author is lying.
Never mind that the author of this "click-bait" article is a ... Linux kernel bugzilla maintainer. Yeah. I can vouch for every letter in the article. It's written with my blood.
On the desktop, Linux is an afterthought for the vast majority of consumer hardware vendors. Many Linux desktop users run configurations which could generously be called “alpha”.
With MS windows, this burden is shouldered by every hardware manufacturer. It’s nonsensical to release a peripheral which doesn’t work on windows. Laptop/desktop makers then qualify common applications to make sure everything works as expected.
If any of the above doesn’t work out, then MS will get a call, or the hardware vendor.
How many Microsoft or Apple bug trackers do you have access to? The fact is that we have to consider that open-source work is largely done by volunteers and commercial developers with their own use cases in mind, and we only know about the drama because it's out in public. The drama inside big tech firms could be worse and on a larger scale and we would likely not know about it. Even if an insider told you something, it would be only a small part of a bigger picture you can't see.
> Linux is not an operating system
> While Linux is unrivaled on servers and has been the world's most popular operating system for over two decades, the situation on the desktop is quite bleak.
It either is or is not. It is illogical to claim both true and false to be true at the same time, yet that is what he did.
Wow. Such sweeping generalizations make me not want to pay attention to anything this article has to say.
But let's entertain the possibility that parts of that statement are true. It's practically impossible for "Linux developers"—whatever that means—to ensure that a change they make doesn't break something downstream. Unlike proprietary operating systems, the Linux ecosystem is not maintained by a single company, so it's impossible to know and account for all the environments a piece of software will run in. Distro maintainers work tirelessly to ensure bugs don't make it to users, but it's simply impractical to test every single combination of hardware and software that exists. This is extremely difficult even for proprietary operating systems where development is centralized, let alone for a distributed environment like most software for Linux, and Linux itself, is developed in.
When you think about it, it's a miracle of modern software engineering and a testament of the power of collaboration and the free software movement that the Linux ecosystem works as well as it does, and in many areas matches or exceeds the functionality of other operating systems, all the while preserving important user freedoms. GNU/Linux is a stronghold for user-friendly computing among alternatives from companies that want to control how you use your computers, or profit from your data or attention. It's not perfect, but it's one of the few options we have (besides the BSDs, but I wouldn't consider them to be as user-friendly).