What exactly is the point of rolling release? My pc (well, the cpu) is 15 years old, I dont need bleeding edge updates. Or is it for security ?
What exactly is the point of rolling release? My pc (well, the cpu) is 15 years old, I dont need bleeding edge updates. Or is it for security ?
What exactly is the point of stable release? I don’t need everything pinned to specific versions—I’m not running a major corporate web service that needs a 99.9999% uptime guarantee—and Internet security is a moving target that requires constant updates.
Security and bug fixes—especially bug fixes, in my experience—are a good enough reason to go rolling-release even if you don’t usually need bleeding-edge features in your software.
To be able to predict when something you depend on breaks.
This “something” could be as “insignificant” as a UI change that breaks your workflow.
For instance, GNOME desktop threw out X11 session support with the latest release (good riddance!) but you might for example depend on GNOME’s X11 session for a workflow you’ve used for many years.
With rolling, those breaking changes happen unpredictably at any time.
It is absolutely possible for that update to come out while you’re in a stressful phase of the year where you need to finish some work to hit a deadline. Needing to re-adjust your workflow during that time would be awful and could potentially have you miss the deadline. You could simply not update but that would also make you miss out on security/bug fixes.
With stable, you accumulate all those breaking changes and have them applied at a pre-determined time, while still receiving security/bug fixes in the mean time.
In our example that could mean that the update might even be in a newer point release immediately but, because your point release is still supported for some time, you can hold on on changing any workflows and focus on hitting your deadline.
You need to adjust your workflow in either case (change is inevitable) but with stable/point releases, you have more options to choose when you need to do that and not every point in time is equally convenient as any other.
I’d just roll back the problem package to the last acceptable version until I have the time to address whatever the issue is (or block the new version of just that package if I have advance notification). That way, I get the fixes for everything else without breaking my workflow. If a rolling-release distro has a package manager that doesn’t allow that, I’d contend that said package manager is broken.
Stable will still get security patches and bug updates, just no new major kernel jumps or new features.
Many smaller projects not explicitly supported by the vendor only make new releases and don’t also maintain a stable version.
. . . until something in the stack requires a significant kernel upgrade, and then you’re stuck.
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.
That’s a very odd example to choose given how trivially interchangable kernels are.
At NixOS, we ship the same set of kernels on stable and rolling; the only potential difference being the default choice.
I’m pretty sure most other stable distros optionally ship newer kernels too. There isn’t really a technical reason why they couldn’t.
Yep, it is helpful for corporate applications, where nothing can introduce possible behavioural changes, that affect users, program function or the application development.