Rhino Linux is a rolling release Ubuntu-based distribution | Hacker News Reader

Rhino Linux is a rolling release Ubuntu-based distribution

rhinolinux.org

73 pointssacrosanct86 comments

OpenSUSE Tumbleweed is also a great rolling release distro. For anyone that's never tried rolling release, the main benefit is that it keeps your tools/libs/kernel updated with the latest upstream.

If you use Ubuntu (for example) it ships with some python version (say 3.8), and then it will almost never update again unless you manually install a newer python version or update Ubuntu itself to the next release (which might not exist). With something like Tumbleweed (or Rhino in this case), updates come out every few days, and every time you do an update you'll find python is now on 3.10, then 3.11, etc.

It's really nice when every compiler/language is on the latest version by default.

> the main benefit is that it keeps your tools/libs updated with the latest.

For tools you want to be on the latest version of, why not use a package manager like homebrew that isn't tied to your distro?

I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority.

A distribution is a collection of software - if reduced to a certain point, the identity is lost!

It makes sense to me for a distribution to find commonly wanted software, package it up, and make it available.

There's tailoring to consider! Some go further and introduce patches. Not every distribution is as good at both contributing and being accepted upstream.

Now, if you want something newer, then you're obviously welcome to acquire that as you see fit.

The distribution will help with that, too -- providing build utils, headers, etc. Enabling third party repositories, ie: PPA/COPR

There are also runtimes to avoid building; Flatpak/Snap, Docker/Podman, etc. Though, these also lose some of the 'distribution spirit'

This is a really good answer, thank you.

For tooling I use something like nvm, Pyenv, or SDKMan.

I don't want Python to update from 3.10 to 3.11 silently, but I also don't want to be held back if they decide that they don't want to support Python 4 yet. I also want to be able to pin to particular versions if I want, or at least update in a structured way.

I dislike the way that distros purge older packages, so building containers requires me to build my own package repo cache to allow me to have repeatable builds.

It might make sense for the distro, but this is where the difference between the base operating systems requirements and mine differ.

Brew has some sketchy practices (re system folders, telemetry). Thankfully there are plenty of alternatives… containers, flatpak, ppa, nix, tgz, etc.

I settled on pkgsrc, very portable, configurable, sits cleanly alongside the OS or other packages managers and has a friendly community. Con: building from source, needs some massaging sometimes.

> I've never understood the Linux culture of tightly coupling OS and package management

The ABIs are quite tightly coupled though. There's e.g. a dependency to glibc, so either you make a compromise and use the oldest common glibc or ship packages for various glibc versions. So unless everything is built from source, this approach has its limits.

edit: of course it's possible to use static linking but even then there's a residue of calls that are dynamically linked at runtime. (That's why there's flatpak, snap, ... which bundle dependencies redundantly)

Where to draw the line is fuzzy and probably subjective, but to me it seems natural for "system" packages to be updated and managed entirely separately from user-installed packages of all kinds (not just things that get wrapped in flatpaks or shipped with their jungles in Docker), even if that means dependency redundancy. I think for most people trading off some storage for assurance that user packages can never ever influence or worse, break the environment would be worth it.

That makes a lot of sense to me. I find it useful to keep the two separate; I think most of my confusion stems from people trying hard to use 1 tool to do both.

IMO two tools is reasonable -- something like homebrew or guix plus the system package manager. The frustration sets in when you realize you actually use a dozen: pip, npm, go get, Docker (which has the same problem again, fractally), homebrew, tfenv, gem, rvm, the list goes on. If you are in an environment where there is even cursory review of your dependencies, it can become a nightmare. This is the origin of (also nightmarish) inflexible corporate policies like "we are a CentOS shop: don't use anything that isn't in those repos without a months-long review and sign off from the VP of infosec."

| but I seem to be in the minority.

Every time one of these threads comes around it's like the same thing on repeat: "I could either learn how to use a container or dist-upgrade my entire operating system to solve this."

If you peel off the layers that have accrued in some distros centralized package management is incredibly simple to implement and effective and met the performance,security, stability, and storage needs at the time of implementation. Think of it like manual transmissions. Consider the package management system of Arch or Void for instance.

As in all cases where one technology supplants another its not enough to be superior in one dimension it's a hard sell unless its not only better but substantially better for all concerns without substantial cost or downside or foisted on users from on high by someone that can't fire by switching brands.

For instance app images have been a thing for a while but nobody formalized it with a store with standards, security, testing for actual not theoretical compatibility etc so its a tool you can pick up rather than an actual ecosystem a user can rely on.

Nix/guix are cool as heck but they are also complicated and difficult to understand. They can also have issues not present in the source software

VMs are of course unwieldy

App vms are restricted to Qubes

Snap relies on a proprietary backend and starts slow among many and varied flaws.

Flatpak still starts slower than native, doesn't have most software, isn't suitable for libraries or software that will be consumed by non flatpaks, doesn't have most software.

Homebrew is mostly used by expats from Apple land because its virtues are moreso leveraging existing know how and work flows.

Docker/Podman are more like developer tooling than user tools.

Bedrock Linux is for crazy people who wish arch and ubuntu were one distro

Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo

> Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo

It already has the exported .desktop files, right? I wonder why they didn't just (ab)use that mechanism and add it to the default path on install

It has desktop files. You could trivially add scripts named foo but you can't stick them somewhere global because the flatpaks actually exists in the users home dir but having a ~/bin is not standard either.

It doesn't exist because it doesn't aesthetically fit.

You can create it for yourself of course.

>Of these flatpak seems most likely to become the standard although I wish it would plunk an executable somewhere instead of the ridiculousness of flatpak run foo

Then you'd need to ensure that filenames from different flatpaks don't conflict.

Many package systems have ways to select different packages with conflicting names.

> I've never understood the Linux culture of tightly coupling OS and package management (and so I use brew even on Linux), but I seem to be in the minority.

It allows one side of your artificial divide to specify dependencies on the other. I can conceive of a packaging system that is designed with your split in mind and can cross that gap, but today no such system exists.

I've had Python code break a number of times when moving between 3.x minor releases. For a distro like CoreOS that is single purpose and intentionally kept minimal, I can see the value in a rolling release. For a traditional OS though, I do not want to be forced to spend my day fixing stuff because an update ran last night. Choosing when to change language and dependency versions is a feature.

Python made a deliberate choice to do that, thankfully not too common.

How often is common to you? I've seen it happen plenty, and not just with Python. Even Go, which has a reputation for maintaining backwards compatibility, had bugs that caused breakage on patch releases during the go.mod transition. Even if breakage happens rarely, when it does happen it causes unplanned work. I'd rather be deliberate in when I choose to upgrade so I can plan for issues.

As mentioned, they weren't bugs but multiple planned breakages.

IMHO, Python devs learned the wrong lesson from the 2 --> 3 transition. Should have been, "minimize big breaks." Instead they learned, "make lots of small breaks spread out evenly and avoid X.0 releases." The result is that planning around deprecation (always be breaking) is untenable for enterprise-style development.

> It's really nice when every compiler/language is on the latest version by default.

I've seen breaking changes in my dependencies from 3.7 -> 3.8 -> 3.9 -> 3.10, both at work and at home.

I've also had constant issues with both GCC and CUDA being too new.

The reverse is true too of course - I use a rolling release specifically because of a new CUDA version that no stable distro has (or will have for many months)

I found opensuse tumbleweed's swaywm pattern to be completely broken, and from what I saw in forum posts it has happened several times in the past few years.

I know opensuse is vaunted for its stability, but I have yet to find a setup that I liked better than sway-flavored Manjaro, given my proclivity for tinkering. Debian +kde also seem reasonably solid, even if kde still has odd occasional bugs or inconsistencies (last I tried, I had to reboot twice after installing to get the battery icon to work in the tray).

EndeavourOS sway edition (community) [1] has been a pretty great start for preconfigured wayland+sway+waybar and various integration. I added some more stuff to my ~/.config in my own repo [2], but it was a good place to start, and EndeavourOS is basically just rolling Arch Linux with some extra niceties. The included EnvyControl [3] switcher between nvidia to integrated is nice (yea you do have to reboot tho to switch), so I have used the regular i3 config with Xorg for playing some games (nvidia hardware graphics), but use sway for my day to day use (integrated graphics on wayland).

[1] https://github.com/EndeavourOS-Community-Editions/sway

[2] https://github.com/enigmacurry/sway-home

[3] https://discovery.endeavouros.com/hardware/envy-control/2023...

counterpoint: Let's assume you develop a software written in Python for $dayjob and you're targeting Python 3.8 because that's where your deployment target is. It's Monday morning, you fire up your work machine and the code that was working fine on Friday doesn't run anymore. Now you're scrambling to get some version of Python 3.8 installed to /opt.

TLDR: There are a million circumstances where you don't want things to auto-update (even if auto-update means: "I run `apt/yum/foo upgrade" every morning". It's a story as old as time, if you're not only a user, upgrades are (and should be) often a deliberate choice, more important the more you go from patch level towards major version.

(waiting for the people to chime in that this broken anyway and you should never work without Docker, etc.pp - I know, I know. It's just a real example why I run Arch on my personal machine but am more than happy with Ubuntu LTS on my work machine. I change minor/major version when I want.)

How does one make a point-release distro into a rolling one? A distro is a repo and configuration (and, of course, the community that grows around it, but that’s sort of ephemeral). So, if they are doing rolling release, they must not be using Ubuntu’s repos… what do they use?

Anyway, this is not to poo-poo a new rolling release distro; the more the merrier. I think people are waking up to the fact that rolling, with fewer moving parts per update, is the best way to get stability. Debugging effort grows like O(2^n) where n is the number of packages updated.

Vanilla OS is great too: https://vanillaos.org/

The unique selling point is its immutability as described here:

https://documentation.vanillaos.org/docs/almost/

> Immutability is meant to be used as a safety measure to prevent accidental changes to the system, so it should be kept enabled most of the time.

It seems easier to just fix my system instead of trying to prevent breaking it :p

I don't know what an accidental change is, but if I want to change something I'm going to change it and likely tear through immutability anyway. I can go back to Windows if I want to be limited in what I can change :p

just go with it, this is what we do in linux distro land, it doesn't have to make sense. It just has to sound cool when i tell someone what distro i've moved to for the 3rd time this week

All linux users go through distro-hopping phase at some point after passing the first intro phase, I did back in 2007 too, but then you realize that whatever get the job done it will be your daily driver. In the past 6 years my main one is Mint, and it’s stable and overall good and let me focus on the stuff I do on the OS not the OS itself, so I’m sticking with that.

Amen to that! I did my distro since the late 90s. Eventually I also have settled for Linux Mint. Years ago, I was very happy thinkering here and there: Used Gentoo and also Arch. But as I grow older that tinkering stops being fun and becomes a chore.

LinuxMint has had the best balance of stability, out-of-the-box experience and user friendliness (I hate snaps). I only wish they supported a KDE version, as I used to love using a KDE desktop back in the day (btw, remember how broken was KDE4 when it just came out? KDE3 had A LOT of stuff and KDE4 was just... so barebones).

Happy to see another Mint user!

Seems like a good project, but I'm not sure why I would choose this over something like Debian Sid though?

How does the stability of Sid compare to an actual rolling release type distro like Arch?

I've used sid on my machines for decades, as have many other people. Works great. It's not an official "release" in that it's not all tested together, but neither is Arch, really.

i'd imagine sid is far more stable than arch, but that is just my anecdotal experience.

plus ... ubuntu is debian. can't rly imagine why you'd want to base a new distro that is debian-based on something other than debian.

arch is a cool distro that I definitely respect, but I don't think it is appropriate to use for a workstation that you need unless you are on a filesystem that will do snapshots before package updates such that you can easily rollback. ie btrfs/zypper.

From my experience, its much more stable. Sid is "unstable" by Debian's definition, but Debian's definition of Stable is a lot more intense than most other distros.

If you want a little more stability but still rolling release, do Debian Testing. Packages are only really delayed by 2-10 days (except during release windows where they do branching). The only criteria for something getting into Testing is that it passes all tests while in Sid for multiple or all supported platforms.

But overall, Sid is fairly rock solid. If anything I think Rhino Linux should have taken Debian Sid or Testing as a source, adding all the niceties/desktop/sane defaults of Ubuntu that they like. and released that.

The next version of Vanilla OS[1] will offer immutable point releases based off of Debian Sid with some extra tools like an integrated distrobox and "sane defaults" without foregoing choices, moving away from Ubuntu after the latter announced ending support for Flatpaks in favor of pushing snaps.

[1] https://vanillaos.org/

Yes, I'm eagerly following VanillaOS. I am excited for some of their tools and design.

But it would be also nice to have a standard mutable variant too.

I've been running sid aka unstable for years now with very little to no breakage (well, the recent transition to pipewire was a bit fun but seems to have settled now and was never critically broken)

I tried using testing first but did experience more breakage there for some reason. I wonder if that was just bad timing, but like I said, "unstable" has been rock solid for me so I've never looked back.

Sid is not, contrary to what others replied to you, a proper rolling distro. Particularly during the times when there are freezes for a new stable release, the repositories can become broken in a way that you may not be able to install software you want because its dependency chain is not fulfilled correctly. People who almost never install new software might not notice the issue, as it's not like sid will break what you already have installed -- as long as you don't say yes to a full-upgrade that shows a concerning amount of removals.

I've had experience with it and Arch in my rolling days (I am now a debian stable user, and use flatpaks and pet containers when I need newer software and feel much more at peace with my systems now), and Arch would, in my experience, never be the source of breakage. Things do break at times on a rolling release distro, but in the case of Arch, that would be because something upstream changed in their software, not because of the packaging of the distro itself.

Debian testing is not the answer either. When there are bugs that make it to testing, they can linger for an incredibly long time. At least, on sid, or Arch, it's more likely to happen, but also will get fixed quickly.

IMHO, the current landscape has solved the whole reason that made rolling desirable. With flatpaks and pet containers, there's nothing you could possibly miss, while you run a stable, unchanging system underneath. If you need support for hardware so bleeding edge that there isn't a backported kernel yet, I'd still find it less effort to package my own ( https://www.debian.org/doc/manuals/debian-kernel-handbook/ch... describes how to do this succintly. It's not as much work as it sounds ) from upstream until backport repositories support my hardware, than have a fully rolling distro on my computer.

Sid has always been pretty good for me. I run a mix of Sid and Stable machines. It really depends on what you're looking to use the device for, but I've never found severe breakages or anything on Sid. I probably wouldn't run Sid on a server though.

I'm very excited for this, but I find it odd that an OS that focuses on the bleeding edge uses a non-wayland desktop framework as its default. The most anticipated software I'm waiting to have drop in 24.04 is kde+wayland.

I'm so happy that XFCE is still a thing. I remember using Xubuntu as my daily driver through the nightmare years of Windows 8 Metro and it was a dream come true.

Ubuntu is already a derivative distribution tracking Debian, and there seem to be obvious disadvantages to having the extra level of indirection, is there reasoning written up somewhere about why they don't base on Debian?

Especially since Debian has a testing release, which is a rolling release.

Maybe this distro is based on Debian testing, but has some of the Ubuntu defaults?

I don't get what's "Ubuntu-based" about Rhino?

It uses XFCE, and Pacstall for package management, which to me makes it utterly unlike Ubuntu.

It uses the Ubuntu package Repos. That’s generally what <distro>-based means in the Linux world.

Hard disagree. Distro based is normally based on foo being a fork of bar either once or periodically rebasing on parent. Merely consuming the same packages is insufficient.

That's... interesting. I avoid Ubuntu largely due to the age of things -- I'm someone who prefers Fedora/Arch, closer to the 'edge'.

Apt is another part of it, but honestly Debian seems to 'feel' better. Perhaps due to the packaging?

Anyway, I'll probably try this out. Say I wanted to take Canonical out, does anyone here have anything to say for Debian Unstable?

I used to be a RPM based distro user back in the day before `yum` existed. The RPM dependency hell left me PTSD and using `apt` was a breath of fresh air. Nowadays I only use `yum` in Amazon based instances and for the normal day to day stuff I don't see any difference.

Totally understandable. I used up2date, too.

It's pretty subtle. Ubuntu packages, maybe not all DEBs, like to prompt for input on how to proceed with new configs.

For servers at scale with varying packages, levels, and requirements - this gets painful. Some config hackery can help, but creates a bit of a circular problem.

RPM systems (by default) will trust the administrator. They don't prompt, and provide the new config file as a reference - without messing with what's already been deployed.

Apt also likes to get hamstrung on previous transactions. If they broke for the reason I just mentioned [or any other], installing new/completely unrelated things is blocked.

I can pretty much trust my RPM systems to do what they want/have been told... but not the DEB.

Granted, my experience with DEB has mostly been limited to Ubuntu - so it could be that/Canonical.

> Granted, my experience with DEB has mostly been limited to Ubuntu - so it could be that/Canonical.

It is not a Canonical specificity, but it is overridable behavior.

For the dpkg prompting on configuration file changes:

https://raphaelhertzog.com/2010/09/21/debian-conffile-config...

> You can also make those options permanent by creating /etc/apt/apt.conf.d/local:

> Dpkg::Options { > "--force-confdef"; > "--force-confold"; > }

Along with invoking apt with -y (assume yes) will get you close to the behavior you seek. Or as a permanent setting:

APT::Get::Assume-Yes "true";

Indeed, thanks for getting into that - I was rambling a bit and saved the space

I really liked the ZFS approach to rolling updates that we had in the Sun Storage Appliance: updates are `zfs send`s, and applying an update is `zfs recv`ing an update, then you reboot into the new snapshot.

That requires:

  - making / read-only (so there's
    nothing to save from / on upgrade)
  - having all configuration state move
    out of /
  - having all upgrade actions relating
    to config files and so on be applied
    to a clone of the dataset that has
    that content

This way backing out an upgrade is trivial, and you can be very confident in the ability to back out.

This approach happens to be a very good idea for other things as well. Such as if you wanted to seal TPM keys to PCR values that bind all of /, well, you'd need a secure hash of all of / for that, and a Merkle hash tree filesystem (but not quite ZFS) can give you that.

I wonder - why isn't Arch the one distro to rule them all - especially if we talk about rolling release? I was distro hoping since 2008 - Ubuntu, Xubuntu, Centos, Fedora, Mint, Slack - you name it. When I found Arch, after a couple of months I knew it was over. It really "just works" in the best sence.

Because in most enterprise environments it's a welcome property to keep security updates separate from feature updates, which is not something rolling distro's provide, as they just follow upstream as fast as possible.

Say my enterprise application is built upon the API (in an abstract sense, if you will) of package xyz, version 1.0. And then xyz, version 2.0 comes out.

I would have to rebuild my enterprise application to be compatible with API 2 and I don't have the resources nor the incentive for that because I don't need API 2. Then a vulnerability gets reported in both xyz version 1.0 and 2.0 but xyz's maintainers only patch 2.0 (as 2.0.1).

In that case I am very happy that non-rolling (enterprisey) distro's like Ubuntu, CentOS, Redhat etc backport that security patch so I can keep running xyz version 1 (or rather 1.0.0-1 or something like that). Where most rolling distro's would just 'force' you to upgrade to 2.0.1.

Hope my explanation makes sense.

First of all, many rolling release distros don’t follow upstream as fast as possible—there’s often some testing window.

People go on and on about backported security patches and stability, but I’ve had to handle so many buggy patches or issues that never got a backported fix that I now think this is basically a fantasy. The distro maintainers just don’t have the time (or experience with all the software they ship!) to backport patches for every single issue. I’d really rather get a fix by the actual software maintainer than a year-old mystery meat version that still has a bunch of known non security bugs fixed in upstream that the distro maintainers don’t care about.

Even worse, being able to stay on essentially outdated software puts a lot of organizations into a tough spot when their LTS version finally becomes unsupported. Practice makes perfect, and I think lots of small, regular updates result in a lot less pain than a mega-update every few years (really: I’ve had to manage one of these more than once, and it’s a total nightmare figuring out which of 1000 changes in the new LTS version caused a performance regression or something).

> distros don’t follow upstream as fast as possible

Well yes, the testing is of course part of the 'as fast as possible' part. But I could've made that more clear indeed.

> many buggy patches or issues that never got a backported

I have yet to see those in CentOS. But I guess we won't be seeing a lot of CentOS at all in the foreseeable future :p

> many buggy patches or issues that never got a backported

I feel like thats mostly on them. There is a huge temporal overlap between LTS versions and you should have plenty of time to test. I think I'd rather dedicate one month every year to fully test and then roll out a new LTS version than be interupted by unexpected updates at random intervals.

That being said: What a boring job it must be to backport security patches all day.

Arch is a very popular rolling release distro with a great community, which has (I think) really kicked off interest in the (superior, IMO) rolling release paradigm.

But, just like point release distros, people are going to want to try new things, and for some things they want to try, it’ll be easier to start a new project rather than somehow convincing the whole Arch community to try their thing. Arch is pretty conservative and sticks fairly close to upstream.

So, we’ll keep seeing new rolling release distros, and some of them will have good ideas, so they’ll stick around. Which is great, diversity is a sign of a strong ecosystem.

Because it doesn't "just work" in the actual sense: namely, installing is an involved process. That's great for people who are into Linux, but that's not your audience if you're talking about growth.

Manjaro may have some hope: it's received a lot of criticism for the odd way the maintainers have set up some aspects of the distro, especially from Arch users. I've seen HN threads full of comments saying things like "why on earth would anyone use Manjaro when you can use Arch?". Those commenters miss the selling point of Manjaro: it's a rolling release for Ubuntu's target audience, and that target audience want one important thing Arch does not offer:

- an officially supported, opinionated installer of a fully configured Desktop environment

I would say OpenSUSE is the best rolling release by far: since they actually test packages instead of rawdogging it and putting bug notices in each package’s release notes.

installing it is truthfully the easiest part. the hard part is dealing with breakages due to incompatibilities, particularly when you consider aur.

lolwut?

Unless something major changed, you're dropped to a terminal as soon as you boot the install image, and have to either have advanced knowledge on what to do from there, or have the wiki side-by-side on another device. And unless you're taking incredible notes at the same time, good luck replicating the set-up if you need to reinstall.

Ubuntu, openSUSE, Fedora, and most other mainstream distros at least boot you into a GUI to install.

Replicating the setup when you need to reinstall? What?

I once had my computer crash during a kernel update and this left the system unbootable. All you have to do is use the arch iso and arch-chroot into your system to rerun/undo the kernel update or whatever other update broke your system. The thing is, even a "reinstall" is merely about deleting packages and then rerunning pacman and reinstalling your bootloader. Your /home and /etc stay untouched. You can take the list of installed packages and then install those. I mostly needed that when moving from an old laptop to a new one.

Cruft is left around from caches and old program data all the time. A clean install handles that, and lets me verify my configs are still good and think about way to change them. Clean installs also let me do full-drive SSD trims. I do OS reinstalls maybe 1-2 times a month unless I'm testing something, and can re-deploy my personalized set-up in less than an hour.

I'd rather nuke from orbit and rebuild than duct-tape holes :p If my system became unbootable for some reason, I'd fix it and ideally find out what happened, backup stuff, and reinstall. Best-case, everything is fine (although I'd change distros if it ever broke because of a clearly untested updated). Worst-case, the system becomes unbootable again because of the same issue and I can report it upstream with more confidence.

Comments like these remind of me of how disconnected devs are from the real world noobs like me. Which means more real world problems to be potentially solved by startups who can deliver, even if there's a solution that "really just works".

I use OpenSUSE (Tumbleweed, the rolling release version) over Arch because Arch has very little useful software outside the AUR whereas OpenSUSE has that in its official repo ("oss"). Anyone can upload anything they want to the AUR and there's no review or even any guarantee that it builds. It's basically equivalent to how Ubuntu users solve all their problems by adding random users' PPAs. But of course if you are okay with the AUR, then Arch has the benefit that the AUR has a lot more software than OpenSUSE's official repo, and there's a lot less bureaucracy involved with adding new software.

Regardless, I solve all my OpenSUSE problems using the Arch wiki since they're both rolling-release, modern software stacks, systemd, etc distros, so I'm always grateful that Arch exists.

Personally prefer Void's runit and xbps to Arch's systemd and pacman. Although I mostly use packages from Nix too. Reckon my dream distro would be something barebones that uses s6 and Nix.

Heck no; I reinstalled distros multiple times a week while I was distro hopping and Arch got reinstalled once before I quickly realized it didn't offer anything to make that install process worthwhile.

I use Fedora primarily because of SELinux, and apparently Arch doesn't even use a MAC by-default and expects manual-setup.

openSUSE Tumbleweed is a better rolling-release implementation imo and has even been more up-to-date than Arch when it came to some major GNOME, KDE and kernel updates.

Every linux distribution, IMO, has a sweet spot niche.

You run Arch if you want that critical mass of bleeding edge community support/maintenance. Fedora for a pre release RHEL. Clear Linux for absolute x86 performance. Immutable distros like Kionite or SteamOS for focused tasks and stability. Gentoo for embedded stuff or weird patches. Mint for an old (but stable) base.

And you run Ubuntu because it is default linux. Its what you have to deal with on your cloud instance or work server or whatever. It is possibly the only thing some specific software you want is packaged/tested on.

So Rhino linux is... Ubuntu, but rolling? If it actually works with Ubuntu targeted packages, thats pretty cool, as it would take tons pain out of Ubuntu.

openSUSE Tumbleweed makes more sense for rolling imo and was even more up-to-date than Arch at times with major DE versions and kernels. And openSUSE like most other mainstream distros doesn't require an encyclopedia to install :p

Fedora is probably the most secure server OS you can get; can't beat SELinux, and nobody else implements it besides Fedora and RHEL.

I personally see no point to Mint since Ubuntu exists, and Mint has had their own share of specific issues one being that Wine didn't work for some months. The rep I got from them in the past was that they mixed their own, Debian, and Ubuntu packages in their default repos that occasionally caused dependency issues. Maybe it's not that bad, but Ubuntu is still around and a lot more supported.

Ubuntu is the distro. It's popular, it looks good (not the boring grey/white Adwaita theme), and can handle multimedia without having to involve any 3rd-party repos. I'd recommend it to beginners today, and I'd probably be using it as a desktop OS still but I like consistency and my home lab is Fedora :p

I have zero interest in Rhino Linux. I don't have issue with Ubuntu's update procedures and trust them to make sure package and distro updates go smoothly for the largest user-base, and I trust openSUSE TW more for rolling since they've been doing it longer. I also don't like the idea of running a fork of a distro that's a fork of another distro :p

Yeah, that sound right, I have just never personally used SUSE. Its high on my distro hopping list if Arch fails.

And I too am skeptical of Mint. Again, immutable (and not so old) sounds better if you really dont want your system to break.

Personally I am partial to CachyOS. Its Arch, but Clear Linux, with an auto installer and as many optimizations/patches ported over to the stock Arch packages as possible (but not to the point of incompatibility like Manjaro).

Pretty sure opensuse microOS and Aeon/Kalpa default to SELinux.

Thats very interesting, thanks.

Immutable + SELinux means Kalpa could be my "linux for friend/family" recommendation. I need to check it out.

Kalpa has more rough edges than Aeon, but I've been test driving Kalpa on an old Chromebook for the last few weeks. Definitely worth a spin.

Yes, it is a rolling distribution with some nice features. https://linuxlifehacks.com/rhino-linux-ubuntu-based-rolling-... It is also lightweight because it uses Xfce.

Point releases for android and linux is really a pita. Even windows is a rolling release, win11 keeps getting updates without a reinstall.

I've never done a reinstall to upgrade Ubuntu for point releases and even major releases, I just run do-release-upgrade when I want to upgrade.

I haven't used Ubuntu in a few years now, but anecdotally, do-release-upgrade has failed on me more times than I can count (in both server and desktop environments).

Indeed, I no longer use do-release-upgrade and instead find it "easier" to install the new release from scratch and copy my ~user and other backups over.

It's a PITA (have to install all the packages I had on old version), but I have scripts that mostly do it all for me now.

If you've ever lived through a do-release-upgrade for mysql, you'll probably never do it again.

I did that only yesterday to upgrade from 22.04 LTS to 22.10, and now my laptop doesn’t boot.

So it doesn’t always work.

I am strongly considering trying Arch instead.

Our experiences are different. Before I switched away to a rolling release distro (Manjaro) a couple years ago, I used Ubuntu and would perform the upgrades from one Ubuntu point release to the next. My success rate (something either moderately or critically not working after the upgrade) over those last couple years was probably about 25%. Always needed to wipe clean and reinstall, restore from backup. Tons of lost productivity. All that stopped when I went to the rolling release.

I've heard too many horror-stories of major OS upgrades and even service packs back in XP and Vista days.

New distro versions for me equals a clean state to make sure everything goes smoothly :p I have commands and notes that let me re-deploy within an hour on most distros, like these for Fedora: https://wiki.realmofespionage.xyz/distros:fedora_workstation...

This! I've needed a rolling Ubuntu for so many things. Ubuntu is basically the "default" distro in many places, and pushing out upgrades via a new image or some big bang upgrade was a lot more painful than having a rolling updates.

Reply on news.ycombinator.com