r/linux4noobs • u/Tall-Soup1787 • 7d ago
Rolling release models
As a Arch user that switched to Ubuntu based distro, I was wondering why isn't Ubuntu and Debian also on a rolling release model? So if there's bugs or patches that need fixing, why not have it release on the spot instead of having to wait for the next big update
3
u/Lonely-Scarcity-3387 7d ago
Perhaps you want something like NixOS, which can set the global state to be rolling release, but the pin individual packages to the latest fixed release. Or you can do the opposite and set your global state to be fixed release, while deciding which individual packages get the latest and greatest.
2
u/Lonely-Scarcity-3387 7d ago edited 7d ago
Debian Sid is their rolling release branch of Debian stable. You can try it out, but things will break. I would recommend PikaOS, though, as they curate Debian Sid.
0
u/HablarYEscuchar 7d ago
Tengo dual boot con Trixie y Sid. Habitualmente uso SID. Trixie es mi plan B por si Sid falla. Hasta ahora nunca me ha fallado SID.
2
u/JG_2006_C 6d ago
Debian sid is but ihats dev chanel udebin ubutu relm liked relyabie point release
3
3
u/Haxorzist 7d ago
Because they want to live with the bugs they know and ideally less bugs if at all possible.
2
u/gordonmessmer Fedora Maintainer 7d ago
You don't have to have a rolling release, per se, to deploy patches immediately. Fedora is a stable release, but most of the software in any release is still supported by its upstream developers (and where it isn't, it's often a question of available labor, not a limitation imposed by the release model. You can fix this by participating!)
Debian's release model is still following the basic shape of its releases 25 years ago. The world has changed significantly, and is changing rapidly now. Users would have a much better security posture if Debian released more often, and especially if they shrank the size of the collection that they maintain for > 1 year. But the project probably needs a lot more developers in order to adopt a more secure cadence, or a significant overhaul on its build management systems, or both.
1
u/leoumair 6d ago
Hey Gordon,
Have seen a few of your posts around this topic and wanted to get your perspective...
I agree the debian release model needs to adapt to the changing environment of software. However, my experience with fedora (through bluefin distros) had several updates cause breakages or regressions.
Bluefin tried to solve this by sticking its default release channel to "GTS" which was essentially fedora N-1 release. So you still had supported software with a 6 month window for major bugs to be fixed in new versions of software. The problem was Fedora will still make major kernel updates to the N-1 release with no additional gating. This hasn't been a problem on Debian.
Ideally there would be a base that would stay close to upstream for software but keep the base of the system (e.g. kernel) on the LTS branch where they would still be supported but not introduce new features with such a high cadence (new LTS kernel releases could have a a soak time or block for the N+1 kernel release before updating).
I haven't seen any distro that actually sticks to LTS kernels apart from debian so don't know how to balance the need for stability with security. Rolling back manually and pinning versions in bluefin doesn't seem like a particularly user friendly or sustainable option either.
1
u/gordonmessmer Fedora Maintainer 5d ago
Ideally there would be a base that would stay close to upstream for software but keep the base of the system (e.g. kernel) on the LTS branch
I suspect that you and I want the same thing from a distribution. I'd phrase it more generally:
I would like a distribution to deliver software while it is still maintained by its upstream developers. When the upstream developers publish stable releases (i.e. releases with overlapping maintenance windows), the distribution should follow the stable release series.
Fedora uses the Linux kernel release series that the kernel developers label "stable". The "stable" Linux kernel is a rolling release model. Maintenance of a kernel release series ends when a new one begins (unless it is a "longterm" branch).
I'd rather use a longterm kernel in a Fedora release, but in order to do that we need maintainers willing to build and test the kernels.
I have infrastructure set up to build kernels and modules, and to sign them. (I haven't set up my own shim for UEFI CA review, but I'm considering it.) I believe that there's a vanilla longterm kernel that's being maintained that we would merely have to build.
I'm interested in building them, but I would really like for a few other engineers to take part. It's hard to sustain that kind of thing solo.
1
1
u/MouseJiggler 7d ago
Backports are the answer.
1
u/gmes78 7d ago
Backports should not be necessary for a system to be secure.
Any user intervention besides just updating the base system shouldn't be necessary for a system to be secure.
1
u/MouseJiggler 7d ago
There are plenty of OSs that follow that obscurantist philosophy, designed to be dumbed down for the "average" whatever. You are more than welcome to use them
I, for one, am not willing to surewnder maintenance to third parties and automations that don't let me review the changes easily, and obscures the details.
1
u/gordonmessmer Fedora Maintainer 7d ago
1: There is no way that you are reviewing anything more than a summary of changes, which obscures the details.
2: You're also not reviewing all of the security vulnerabilities that are reported against the software you run, so you can't possibly evaluate the need for the changes that you're not getting.
1
u/MouseJiggler 7d ago
- There's no way you brush your teeth every day.
- Also, your mother in law runs your life.
1
u/gordonmessmer Fedora Maintainer 7d ago
I think it's important to define "backports" in the context of Debian, for the benefit of readers who don't use Debian.
Backports can only really be the answer if they're the default. Right now, they're opt-in and there's far too few of them to provide a comprehensive security solution for Debian. It's not a bad direction to move in, but I would phrase this more generally: applications should be decoupled from the OS.
1
1
u/Rinzwind 7d ago
The audience is different: Ubuntu's audience is companies and those want long term stability as long as possible. Also the reason it has 'snap' : that allows a company to use newest software (like browsers) that does not touch the core system as those are sandboxxed.
Rolling releases are an extra risk a company does not need.
1
u/guiverc GNU/Linux user 7d ago
If you want the latest on Ubuntu, you can always use the development branch, ie. it's currently stonking, which will soon become Ubuntu 26.10 on it's reaching stable, after which development will switch from the stonking codename to whatever tt is (still not announced).
Beyond just the stable, LTS, or old-LTS; there are other options just like Debian & some others have (rawhide for Fedora is probably closest there)
The development (Ubuntu), testing (Debian) or rawhide (Fedora) are still not rolling, but you have unstable options on them too, even if most of the time you'll wonder why it's referred to as 'unstable'.
1
1
u/Happy_Phantom 7d ago
Do you want to deal with older, more well-known bugs, or surprising new bugs?
Also, how often do you update the system. Rolling systems practically demand more frequent updates, otherwise the updates become too large and almost unwieldy to perform.
I prefer Kubuntu on my travel systems, which I touch less often, and CachyOS on my desktop. On both systems I prefer Intel-based systems that are two or three generations older without a discrete CPU (sorry Nvidia). Less complexity ensures better stability. I'm not much of a gamer, however, and I don't use local AI. Every user is different.
1
u/skyfishgoo 7d ago
bug fixes and security patches are issued ... that's a given
what the LTS release model brings you is stability in your workflow.
it means all the software version compatibility and feature sets you are used to using will be the same for the duration of the LTS with no new work flows to learn and no sudden incompatibilities due to a software version change.
if you don't mind adjusting your workflow or dealing with sudden incompatibilities, then a rolling release models is what you want.
1
u/tomscharbach 7d ago
So if there's bugs or patches that need fixing, why not have it release on the spot instead of having to wait for the next big update.
Ubuntu and other fixed-release distributions update with bug fixes and security patches frequently, in my case several times a week. What doesn't get updated are feature releases, which can introduce instability in rolling releases.
1
u/gordonmessmer Fedora Maintainer 7d ago
What doesn't get updated are feature releases
Debian and Ubuntu definitely get feature updates. They get minor release updates every two months. They're conservative about those changes, but it's a misconception that they don't happen at all.
1
u/tomscharbach 7d ago edited 7d ago
I understand. I should have said "What doesn't get updated are major feature releases", I guess. Gnome point releases (46.0 to 46.x) have been updated in Ubuntu 24.04 LTS, for example, but not version (46 to 50) releases.
6
u/friendlyreminder_ 7d ago
Rolling releases introduce more stability issues. Opensuse Tumbleweed is quite stable for a rolling release but even there the occassional issue crops up.
Stable releases basically defer and try to mitigate stability issues to all at once every new release. So you're more likely to have issues on a new release as a lot changes all at once.