Most “stable” distros offer kernel version that update more frequently to accommodate new hardware.
Most “rolling” distros offer LTS kernels that remain essentially unchanged for long periods.
The kernel is one of the smallest differences between the two models.
Agreed. That is why I think Linux Mint Debian Edition (LMDE) is a better desktop than Debian Stable. The DE and everyday GUI tools stay fresh even if most of the distro is a time capsule.
It is funny. You and I landed in different places but for almost the same reasons.
I use a rolling release because I want my system to work. “Tinkering with my tech stuff” is an activity I want to do when I want and not something I want thrust upon me.
On “stable” distros, I was always working around gaps in the repo or dealing with issues that others had already fixed. And everything I did myself was something I had to maintain and, since I did not really, my systems became less and less stable and more bloated over time.
With a rolling distro, I leave everything to the package manager. When I run my software, most of the issues I read other people complaining about have already been fixed.
And updates on “stable” distros are stressful because they are fragile. On my rolling distro, I can update every day and never have to tinker with anything beyond the update command itself. On the rare occasion that something additional needs to be done, it is localized to a few packages at most and easy to understand.
Anyway, there is no right or wrong as long as it works for you.
Where did the idea come from that rolling releases are about hardware?
Hardware support is almost entirely about the kernel.
Many distros, even non-rolling ones like Mint and Ubuntu, offer alternative kernels with support for newer hardware. These are often updated frequently. Even incredibly “stable” distros like Red Hat Enterprise Linux regularly release kernels with updated hardware support.
And you can compile the kernel yourself to whatever version you want or even use a kernel from a different distro.
Rolling releases are more about the other 80,000 packages that are not the kernel.
I would say
Is this based on experience? Or are you guessing?
I ask because my lived experience is that rolling releases break less in practice
Before I used rolling releases, I spent more time dealing with bugs in old versions than I do fixing breakages in my rolling disto.
And non-rolling “upgrades” were always fraught with peril whereas I update my rolling release without any concern at all.
I use ancient hardware (as old as 2008 iMacs) and I greatly prefer rolling releases.
Open Source software is always improving and I like to have the best available as it makes my life easier.
In my experience, things just work better. I have spent years now reading complaints online about how Wayland does not work, the bugs in certain software, and features that are missing. Almost always I wonder what versions they are running because I have none of those problems. Lots of Wayland complaints from people using systems that freeze software versions for years. They have no idea what they are missing. This is just an example of software that is rapidly evolving. There are many more.
Next is performance. Performance improvements can really be felt on old hardware. Improvements in scheduling, network, and memory handling really stand out. It is surprising how often improvements appear for even very old hardware. Old Intel GPUs get updates for example. Webcams get better support, etc.
Some kinds of software see dramatic improvements. I work with the AV1 video codec. New releases can bring 20% speed improvements that translate to saving many minutes or even hours on certain jobs. I want those on the next job I run.
I work on my computer every day and, on any given day, I may want or enjoy a feature that was just added. This has happened to me many times with software like GIMP where a job is dramatically easier (for example text improvements tag appeared in GIMP 3).
If you do software development, it is common to need or want some recently developed component. It is common for these to require support from fairly recent libraries. Doing dev on distros like Debian or RHEL was always a nightmare of the installed versions being too old.
And that brings me to stability.
On systems that update infrequently, I find myself working against the software repos. I may install third-party repos. I may build things myself. I may use Flatpak or AppImage. And all of that makes my system a house of cards that is LESS stable. Over time, stuff my distro does not maintain gets strewn everywhere. Eventually, it makes sense to just wipe it all and start fresh. From what I see online, a lot of people have this experience.
On of the biggest reasons I prefer rolling releases with large repos is because, in my experience, they result in much more stable systems in practice. And if everything comes from the repo, everything stays much more manageable and sustainable.
I use Debian Stable on servers and in containers all the time. But, to single it out, I find that actually using it as a desktop is a disaster for all of the above reasons but especially that it becomes an unstable mess of software cobbled together from dozens of sources. Rolling releases are easier to manage. This is the opposite of what some others say, I realize.
In fact, if I do have to use a “more stable” distro, I usually install an Arch Linux Distrobox and use that to get access to a larger repo of more frequently updated packages.
Awesome to see APK 3 finally ship. I have been using it on Chimera Linux for a couple years and love it.
I use EndeavourOS on Mac hardware for very similar years.
Wifi (Broadcom-wl on the older stuff and brcmfmac_wcc on the newest) works well on all of them.
Webcams work well on all of them as well. Most are just USB cams but some use the FaceTimeHD module that builds with DKMS but works very well for me.
I cannot remember if I had to install the FaceTimeHD driver or if it was auto-installed by EOS. Even if not, it is in the repos and one line to install the package.
I highly recommend EndeavourOS for old MacBooks.
I have a 2008 iMac, 2015 iMac, 2012 MacBook Pro, 2016 MacBook Pro, 2013 MacBook Air, 2017 MacBook Air, and 2020 MacBook Air all running EOS (last one uses a special kernel because of the T2 chip).
They all run flawlessly including the Broadcom WiFi. The Arch kernel is the only one I have found where these drivers work well and EOS sets them up automatically during install.
CachyOS is also an option but the video is wonky on my older MacBooks. EOS is flawless.
Cool. Me too. And?
100%.
There is a reason even the purists fall back on “hardware is out of scope”.
But calling firmware software drives worse outcomes. Will they do the same thing with RISC-V?
Is a RISC-V board better than an ARM board even if both have proprietary schematics and/or divers. In my view, clearly yes.
Every step towards open is positive.
The hypocrisy irks me somewhat as well. The FSF rather famously did not start by writing a kernel. It is why we have the GNU/Linux nonsense. The GNU utilities were first written to run on proprietary UNIX. And this made sense pragmatically as you have to start somewhere. But that was actually real “software” and yet RMS was ok with that. And today he tells people they cannot update the microcode in their Intel CPU.
According to his own definitions, the FSF should not have run a line of code on proprietary operating systems until the FSF had written its own kernel and drivers. But they enthusiastically did. Ok, so they did not write a kernel. How about the C library? Surely, they did not link to propriety C libraries. Or how about the compiler? Did they start with that? No, the first thing they wrote was a text editor (Emacs) and it was built with proprietary compilers, using proprietary C libraries, on proprietary operating systems. The C library came years later. Before that, all GNU software was linked with binary blobs (C library).
Fast-forward to today and you are supposed to condemn Debian for allowing binary blobs.
Not only dumb but massive hypocrisy.
“Where they say that?”
You have a hardware device that is fully proprietary and closed. The firmware cannot be programmed or upgraded.
The FSF is fine with this hardware. Stop me if you disagree.
Version two of the hardware above is released. The firmware can now be upgraded. The initial firmware available is closed source. It is actually the exact same firmware used in version one but it now ships as a binary blob. Since the hardware is programable, open source firmware could be written but none yet exists.
The FSF says that this hardware must be avoided. The binary blob cannot be handled or distributed. Version one of the hardware is still fine and is preferred. Again, stop me if I am wrong. Note, the firmware is the exact same.
Ok, now answer “where they say that?” for yourself.
If hardware is out of the scope of the FSF (totally reasonable) then firmware should also be outside of the scope of the FSF.
Because their stance today is that hardware that is more open is worse. Hardware can be as proprietary and closed as you like as long as you do not make it programmable. If you do, the FSF may have a problem. Insanity.
Free software is better than non-free software. The FSF and I agree.
Open firmware is better than closed firmware. This is my view but the FSF only has an opinion when the firmware is upgradable (as you state above). Silly.
Programmable hardware is always better than non-programmable hardware. That is my view, but the FSF disagrees when no open firmware exists. Dumb.
Exactly. It is about programmability. And that is dumb.
Imagine you have a piece of hardware that is not programmable. The FSF says that hardware is fine. Buy the shit out it and “be free” apparently.
Version 2 of that hardware is released with the new feature that the firmware is upgradable. Of course, only closed firmware updates are available initially. According to the FSF, this programmable hardware must now be avoided. Keep buying the original “more free” version that cannot be programmed.
And if you do have hardware version 2, the FSF says you should at least never update your firmware. Nevermind new features. Security fixes are to be avoided. Because the baked in firmware is more free than the firmware update. It is not that you are not using closed firmware. Of course you are. But you did not change it. So that is better?
It is total nonsense.
If there was a Free Hardware Foundation, a device whose hardware was programmable and whose firmware could be upgraded would clearly be seen as superior to one that was completely closed. It is definitely more open, “more free” hardware even if only closed firmware is available. The hardware is obviously more free. Self-evidently.
But the FSF position is that this “more free” hardware is less free than fully closed options when only closed firmware exists. There is no way for that to make sense unless you move “firmware” into the software bucket and completely ignore the concept of hardware all together. Sorry, but that is dumb.
It is also a good way to roadblock progress towards open hardware. Please stop.
Keep up the good fight Scoopia.
It is clear from the responses you get that people just do not understand what you are saying. But keep trying.
Imagine the FSF argument at the level of the whole computer. If the computer lets you run software, it has to be free software. But if the computer has all its software in hardware that cannot be programmed or updated, then it is not only totally fine but superior to a Windows computer because Windows is closed software even though the Windows computer let’s you run free software and the non-programmable one does not.
Running on Windows is evil because it is software. But running on closed non-updatable firmware baked into your closed, proprietary hardware is good. That is what the FSF has to say. Programmability bad.
There are two ways to fix the FSF position:
1 - they demand that everything be free including all hardware and all hardware running on it. But that means the purists have to stop using all the closed hardware they enjoy today.
2 - the FSF continues with the position that they are ok with closed hardware and defines “free software” to exclude firmware.
There are three words for a a reason, they are three different things: hardware, firmware, and software.
Defining firmware as software makes no more sense than defining it as hardware. In fact, the latter makes more sense to me and would fix the FSF silliness. But what makes the most sense is to acknowledge that they are all different.
Now that I type this, we need a Free Software Foundation, a Free Hardware Foundation, and Free Firmware Foundation.
The FSF mission makes sense if you exclude firmware. The FFF could preach that free firmware is superior to closed firmware. No argument there. The FHF can push for free hardware. That would be great and we could all push for it. But the FHF could also acknowledge that programmable hardware is superior to non-programmable hardware even when only closed firmware exists. The hardware itself is more open and more free. Basically both the FSF and the FHF could be more relaxed about the other. The FHF could be ok with closed software on open hardware just like the FSF is ok with running free software on closed hardware (their stance today).
Honestly, the above is maybe the only sane solution.
That would allow all of us to:
I bet every one of us would agree to the above. Or at least we could choose which of the three missions to endorse. At least they would all be sane and consistent.
Instead, we get the FSF telling us to ignore the closed hardware behind the curtain while choosing hardware that is more restrictive and less free in the name of avoiding binary blobs. We are being forced to fight a religious war and nobody ever wins those.
They’re not saying devices shouldn’t be programmable
That may not be their goal but that is what they are saying. The position of the FSF is that a device whose closed source firmware cannot be upgraded is superior to one that can be upgraded but for which only closed firmware exists. So, if you are buying proprietary hardware (and you are in 2025), you should prefer the closed hardware which is not programmable.
It is a stance that only makes sense if you care more about the simplicity of your message than the implications of your position.
They are directly creating demand for less open systems that provide less freedom. It is dumb.
The solution is simply to have a sane definition of “free software” that does not include firmware.
There should be a Free Hardware Foundation that calls for hardware to be free. They can demand that everything be completely open which most of us would support and may even be possible now that we have RISC-V. Their list of “approved” hardware could be essentially blank. That said they could participate in creating some. Of course, it would likely be worse at first. You know, like Free Software was bootstrapped.
The FHF could object to all non-free hardware while still acknowledging that programmability is a positive step that at least has the potential to be more open. The FHF could sponsor or endorse free firmware efforts.
That clarity would allow the rest of us, even the FSF fundamentalists, to make sane choices.
“I didn’t betray the client and get killed”
Betrayed the client and lived? /s
Except Debian packages do get very old. Which people often have to work around, leading to a less stable system. And Arch is quite stable.
Stable meaning “works without crashing or glitching” not “version numbers never change” (which is what stable means in Debian Stable).
Based on tone, I doubt this is a real question but others may have the same one.
Moving to Linux can be difficult if Linux provides no viable alternative for software that you rely on.
Despite the availability of things like GIMP and Krita, Photoshop and other Adobe products are perhaps the most often cited software preventing user migration to Linux.
Affinity is the software most often cited as being a viable replacement for Adobe (on any platform). Currently, Affinity does not support Linux.
Therefore, the thesis here is that Affinity becoming available on Linux would make Linux a viable option for a material number of potential new users.
This would have implications for both the popularity of Linux as a desktop and Affinity as an alternative, weakening the hold Adobe has on professional media.
I think the significance is overstated. I do not believe the impact would be as spectacular as predicted here. But the basic argument is valid. It would be a positive development and everything that gets the ball rolling contributes to the eventual snowball.
KDE:
“The Unix philosophy favors composability as opposed to monolithic design”
Xorg is a monolith with essentially one implementation. Wayland is a modular system with almost every component available from multiple sources.
Saying adopting Wayland means you “hate UNIX” is one of the least thoughtful arguments I can imagine.
Turn them into a Kebernetes or a Proxmox cluster.