That can be a double-edged sword, especially if the distro has been around a long time. What the user finds can be out of date and now just plain wrong. Ubuntu definitely suffers with this.
Excellent point! Thank you for mentioning this! I feel this is often overlooked for reasons I don’t understand. Thankfully, we can teach (new) users how they can navigate around this: e.g. by mentioning the version of the distro within the search query OR by simply being wary of old(er) info.
Hmm…, would you so kind to explain what the end goal is? I feel like we’re dealing with the classic XY problem. But hopefully I’m wrong.
OP is still a very new Linux user (if at all) that hammers on stability in every one of their posts. My comment was written with that in mind. But, even in its current version, it isn’t absolute and leaves room for nuance/exceptions by using terms like “(almost)” etc.
Veteran users with awareness of the Linux landscape are somewhat able to discern the upcoming serious projects with a future from the to-be abandonware. FWIW, I’ve championed distros like Bazzite (and its uBlue siblings), CachyOS, Nobara, PikaOS and secureblue far before they had any serious recognition (if at all). So I’m definitely with you that promising projects deserve adoption, support and more.
And let’s be honest, if a distro is a one man or small team project, mass adoption is no guarantee of longevity.
Agreed. I believe the “somewhat” I used alludes to that. One might argue that the concept of absolute guarantee doesn’t exist. Even with Arch and Debian*; though I’d argue they come closest IMO. Nevertheless, there are definitely gradations between Arch/Debian and a student-owned hobby project that was created just today.
Mass adoption is a relatively easy metric to gauge. And (often) comes with tons of support/discussion across the internet that will prove to be useful for the new user.
Please feel free to provide other metrics that OP or others might appeal to.
Some looking around suggests that the distro is just over 6 months old or so.
Even if it does literally everything right, longevity is only tested with the passing of time. To exemplify this, let’s go back in time… Relatively short after I made the switch to Linux, there was a lot of buzz around risiOS. Unfortunately, it didn’t take long until this exciting new project stopped receiving any further development. And, as far as I can tell, its creator has literally moved on to their next project.
The above example ain’t unique, though. Heck, I’d argue that the coming and passing of projects is the expected pattern. The projects that remain relevant and continue to receive development are the actual anomalies.
All of which is just to say that it’s (almost) ill-advised to prefer a new project over a well-established one. Only after a (relatively) new project receives mass adoption, like what we currently see with Bazzite and CachyOS, does it become somewhat of a safe bet. Even if only for the foreseeable future*. Until then, you’re at the mercy of the whims and continued interest of a single developer (or a very small team).
Going back to Lingmo OS itself, I suppose its main appeal lies within its unique aesthetics. I’m especially fond of their macOS-like global menu found within its top bar. The now-defunct CutefishOS also had something similar going on… Which brings us back to our earlier point on longevity. Aight, verdict: honestly, I don’t think it’s necessarily more aesthetically pleasing than say GNOME or KDE Plasma. At least to me*. As such, I understand that I’m not the target audience. Nor do I think that you or anyone else should be swayed by this (or similar projects) on aesthetics alone.
during the process I discovered that their kernel parameters were being reset with every kernel update
That’s pretty horrid. They ought to have fixed that since. Right?
Suse
Tumbleweed? Slowroll? Leap? Aeon? Kalpa? Which one?
Based on their post history, I strongly suspect the OP has English as a non-primary language.
While I believe your intent and attempt is noble, in OP’s comment history we find their admittance to being American.
Furthermore, I’d argue their history actually suggests that they’re very much capable of writing perfectly sound English. In fact, this isn’t my first interaction with OP. So I know they can do better. But, for whatever reason, they haven’t demonstrably shown the same diligence when writing up this particular post.
They are doing fine, their posts are perfectly understandable.
The bold part is probably directly targeting the “proofreading your writings before posting them”-part of my original comment. And I’ll admit that I should have done a better job at conveying that this doesn’t intend to allude to a structural problem. So, to be clear, it was meant as general advice after being bothered by (only) this post.
Outwardly suspecting ESL for native speakers ain’t nice either, but I digress…
Makes sense. Thanks for enlightening your stance. FWIW, it has definitely been better since. But of course; however good it may have become right now, it does not take away your experience. Thankfully, you found your refuge in Arch 😜.
Alright, but you seem to be a (relatively) early adapter then. Do you still use it? Or have you pivoted since?
Fam, I loathe saying this, but -please- if you desire engagement, then at least put some honest effort into proofreading your writings before posting them. I’m just assuming stuff at this point because I can barely grasp your intent/writing. *sigh*
Why do atomic distros which are supposed to me more stable, superior to some degree immutable environments lack good backup options? You can hack things together and there are somewhat installable tools. Like timeshift or etc etc.
Which distros even come by default -so installed OOTB- with “good backup options”? Which atomic distros is this statement even based on?
But it seems they place a lot more emphasis on rolling back poor updates in the event than total system backups.
Because their atomicity barely goes beyond updates. The ‘atomic’ in “atomic distros” mostly describes how its updates are atomic; i.e. the system either updates successfully or doesn’t update at all. Thus, by design, we have two possible states after an update: a ‘successfully’ updated system or a ‘failed’ update resulting in the same state as the previous. Atomic distros aren’t smart enough to catch all ‘breakage’ occurred by ‘successful’ updates. As such, most of these breakages will only show them after trying to boot into updated system. Deleting/erasing the previous known good state without verifying that the new/upcoming state works well is foolish. Especially on a distro that’s got robust updates otherwise. Hence, the functionality of rollbacks on updates is almost trivially done/applied to atomic distros, as it (almost) follows by design.
So, what I’m interested in is the following:
By default it you should have true backups then layer in rollbacks. Not the other way around. Am I missing something?
I think my previous paragraph should be enlightening in this regard. If you disagree (or something/otherwise), then please feel free to elaborate why you think so. Btw, what do you even mean with "true backups?
Thanks for clarifying!
One of the breakages was caused by an expired signature or something from Universal Blue, which hit all users. I’m surprised that one doesn’t get talked about more.
Yeah, this was a big one. Though, I have to give them credit for how they handled the situation. I believe a lot of other projects got a lot to learn from them in that aspect.
One of them was caused by Bazzite changing how Steam itself is handled and not transitioning my system over properly.
Was this caused by layering?
What distro did this happen on?
How long ago did you install it?
One was it being immutable, meaning for any software that wasn’t in the flatpak store, I have to spin up a container running a mutable version and use that.
Sorry for being that guy, but please allow me to nitpick the above:
my only real point is that looking problems up on a small distro is harder
While I agree that Aurora definitely is a small ‘distro’[2], I’m not comfortable to refer to Bazzite as a small project. Both Steam’s own metrics as well as ProtonDB’s suggest that it holds a moderate chunk. Sure, with just over 25k users it isn’t quite comparable to (say) Fedora’s 300k+ user base. But it definitely ain’t a slouch either.
As for the looking problems up part, honestly, if a quick search doesn’t help ya, you should just go over to their Discord or Discourse and ask the friendly maintainers and community for help/support. Heck, even their subreddit seems to be doing a commendable job.
I’d argue it’s their legit resistance against the common notion/understanding of immutability that doesn’t apply to Bazzite. ↩︎
The uBlue team doesn’t refer to their images as such 😅. Frankly, I agree that the daily pipeline their images go through to deliver system updates screams everything but the traditional model. To be clear, in uBlue’s model, the daily-delivered base system is rebuilt from source every single time. So, my base system of Bazzite is identical to yours (unless either one of us created their own image). ↩︎
but I guess its a rather small distro that not many people know?
It’s true that it’s not as well-established as many of the other distros discussed here; it probably has like 1k users or so. Which is quite literally just a small fraction of Fedora KDE’s over a 120k user base. Granted, it’s a relatively new distro built on Fedora’s latest/‘future’ tech. Usage numbers should follow eventually[1].
Thankfully, that same tech enables Aurora (and other projects like it) to be very robust and reliable; tangibly more so than the more popular ‘traditional’ alternatives. I assume you’ll come to cherish and value this reliability, especially as stability seems to be a concern of yours.
This was originally intended as a longer comment, but the previous draft unfortunately blinked out of existence… Though, I’m more than willing to shed some light on the distros discussed below if you’re interested.
Or any other Good KDE Distros out there.
I’m surprised that no one else has mentioned them yet. Thus, for the sake of completeness, consider Aurora and Bazzite. It’s what I would personally install/recommend for/to relatives/friends that would like to make the switch to Linux.
Thank you for the quick response!
I don’t know if raw package counts is the best comparison.
You’re probably right. Do you think we got anything better to go by?
Unlike say Fedora, Arch bundles everything related to a project in the same file. If you want Qt6-base on Arch, that is one package. If you want it on Fedora, it is going to have a lib, header, docs, and maybe a few other packages.
Can’t comment on this. Though, the list of packages with qt6 in their name is considerably longer in Fedora. However, I wonder if this simply reflects that Fedora, by virtue of having a larger repository, also has more stuff related to qt6. Or, as you posited it, chooses to package the same content over multiple packages instead of bundling them like it’s supposedly happening on Arch.
Just from personal experience, I do not have issues with finding packages in the main repos, with only a handful of my packages coming from the AUR. This is not the case with others, like Fedora where extra repos need to be added, like EPEL and RPM Fusion.
Hmm…, I feel you might be conflating stuff. Please allow me to elaborate on what I mean.
Fedora is not able to include some packages in its own repository due to legal reasons. As such, these are relayed to RPM Fusion instead. Which means that a well-functioning Fedora installation (almost necessarily) desires to install some packages from RPM Fusion. So, RPM Fusion exists as a ‘hack’ of sorts to protect Fedora from legal charges and NOT because they’re too lazy (or something) to ship those packages themselves. To be clear, RPM Fusion is accepted as a trusted third-party repository.
Arch, on the other hand, is rather lenient on what they can include in their repositories. Basically enabling them to package within their repositories all codecs and whatnot without them being visibly worried about the legal consequences of this ordeal.
To be honest, I don’t know exactly where this discrepancy comes from. But I wouldn’t be surprised if it’s related to how Arch is basically a genuine community distro while Fedora has official ties to Red Hat.
Btw, small correction, AFAIK you’re not supposed to install packages from the EPEL on Fedora. Perhaps you meant COPR (basically Fedora’s AUR) or Terra instead?
The arch maintainers package more software than most other distributions.
Sorry, but I fail to see this.
I suppose if you’re accounting literally all independent distros, then you’re probably right. However, if we’d be more realistic and compare it to other well-established independent distros[1], then we notice that the vastness of the packages found in Arch’s repository is rather lackluster at the very least. Heck, by virtually all metrics, Arch together with its derivatives undoubtedly belong in the upper echelons of usage stats; only being second to the Debian-family of distros. IMO, however, the size of its repository absolutely doesn’t reflect this; as it’s only bigger than Slackware, Solus and Void. The inclusion of these smaller projects is arguably charitable on my side*. But to drive the point home very clearly: Arch’s repository is smaller than Alpine’s, Debian’s, Fedora’s, openSUSE’s and Gentoo’s with a ratio of (about) two to one (except for openSUSE).
I’m basically counting Alpine, Debian, Fedora, Gentoo, openSUSE, Slackware, Solus and Void. I didn’t count Guix System and NixOS for how their ‘repositories’ are built different and therefore not easily comparable to the others. ↩︎
Because, and I quote:
“Warning: AUR packages are user-produced content. These
PKGBUILDs are completely unofficial and have not been thoroughly vetted. Any use of the provided files is at your own risk.”
Thankfully, there’s a mailing list that covers issues like these. Heck, OP’s PSA was probably originally propagated from there.
Honestly, we’ve been eating pretty good fam. See https://www.protondb.com/ for game compatibility on Linux.
The only remaining pain points are (see the provided links for databases on what does and doesn’t work):