I feel like most of these systems tradeoff too much simplicity.
I've been using ArchLinux for ~14 years now, previous to that I used Slackware and Gentoo. IMO it's better to be simple, yes there aren't any guarantees but worst case scenario I can rebuild, run my install script (which might require a few tweaks if it's been a while since I setup a new system), push new keys etc and then I'm up and running again in ~15 mins. i.e I think it's easier to repair or replace a simple system than it is to try work out how to do novel things on a complicated but safe system.
I intend to try NixOS at some point as a foray into these more complicated but "safer"/transactional/immutable/deterministic systems but I just haven't found the motivation yet.
Personally I went from Arch to NixOS and now back to Arch. Whilst I can appreciate the power of NixOS it felt like such a huge amount of abstraction and secret sauce it made it impossible to fit in my head. In addition, the documentation and debugging experience of the Nix language were very poor. Nix shell was useful for trying out programs temporarily, however I found it a poor substitute for native Python and Julia package managers, especially for scientific work where a requirements.txt is useful to a lot more people than a flake.nix
Going back to Arch has felt like a breath of fresh air. Everything is simple, easy to understand and incredibility well documented. Using a snapper pacman hook I can now revert my system to undo updates, which was the main functionality I found useful in NixOS.
Nixos is pretty slick for servers. Everything from users to nginx to system services to firewall is defined declaratively in 1-5 files, and deployment is as simple as `nixos-rebuild switch -—target-host deploy@host`.
For me that’s pretty wild. It makes it trivial to have both staging and prod in sync by just pushing to a repo. That means you get a better overview of the system state, and can experiment more freely knowing the machine won’t end up in a weird state. And while Nixos is hard to debug and occasionally hard to write, I find the format very easy to read.
However for my personal computer, I found that it’s overkill and now I just use a dotfile manager and save my installed program names in a list. I do think nix really lacks documentation for very basic things, and for that guix is better (but I found guix harder to write and read).
I was in similar situation. Arch user that bought the sell from NixOS. It worked great after a painstaking setup (everything you think you know about Linux systems in general is wrong!) and was a joy to use but when it broke, it was a complete mess due to how quirky the whole OS is. P.S There's nothing simple about NixOS and the documentation could use some work.
I use opensuse leap 15.3 and it just works. No fiddling around and install takes 15 minutes.
Then I have a home cooked backup script that runs daily to a remote server, so in a worst case situation, I reinstall, 15 minutes, and then copy my dot files and other stuff which might take another 5-15 minutes.
So for single person use, or small environments of 20-30 servers or so, the traditional old model works well.
To be fair, Tumbleweed has had snapshot/rollback built in and generally triggered at important points for years. There are exceedingly few scenarios where you can't just move to the prior snapshot to get a working system again - talking a minute after failure. Aeon takes it further, but that's where it started. Hard to argue the speed of repairing by rollback vs reinstall.
Also, Aeon has first party support for running cli and gui things in distrobox. You can pull down an OCI container of virtually any distro and do whatever you want in it. Distrobox lets you expose applications from the container environment to the Aeon desktop.
Hypothetically, you could use Aeon as your rock solid core and tinker in distroboxes, including refining the install script to making a custom OCI container. Not trying to convince you - just saying there is a lot of easy to access flexibility there.
I never understood the point of rollback. Suppose you run some upgrade and hit a bug that prevents boot. Okey, you revert, so you can keep running your outdated system. Now what?
It's not like whichever broke your upgrade is going to disappear if you simply try again.
You report the bug and wait for it to be fixed, and meanwhile you have a working computer and can get on with what you originally wanted to use your computer for.
How are you even going to diagnose it? You just rolled back .
And what was the reason you were even upgrading in the first place? Likely precisely because you needed the upgrade in order to "get on with what you originally wanted to use your computer for" ?
I don't know how familiar you are with opensuse tumbleweed, but it is a continuously rolling distribution with a decent amount of automated testing of each release. At times, there can be 2-3 new releases per week. Sometimes only a few packages are updated in a release, sometimes everything is updated. But figure a couple of times a week, there is a new tumbleweed version.
One of the most common scenarios of breakage happens when a user adds a 3rd party repo that at times lags behind the Tumbleweed release cycle. Libraries and application versions suddenly conflict and the user could have a partially or fully borked system. A rollback to the last good snapshot makes a lot of sense - the 3rd party repo will usually catch up in a day or two, and the update that previously broke the system can be safely applied.
To understand rollbacks it's better to assume the user has itself borked something rather than the system. You don't necessarily rollback to previous package versions, just to the last state everything was working.
Sure you can fix whatever you did wrong, but that might imply quite a few things and take time. If you go to the snapshot prior to your changes, it takes a lot less time (just a reboot), less guess work, and you can continue working from a blank slate.
I'm always puzzled how folks praise PKGBUILDs when it's mostly irrelevant for a regular user. Unless by 'PKGBUILD system' you mean AUR, a place where random people push random build scripts and other folks are happy to execute said build scripts locally, quite often without any real sandboxing or even a quick glance at the actual code.
They're not more "random" than developers of a lot of software you run. Package quality tends to be pretty good, I've only seen doubtful things once or twice in about a decade, and nothing malicious. Definitely haven't seen anything like the famous `rm -rf /*` in the official non-"random" nvidia package that was prepared and then shat into the world by nvidia's non-"random" developers.
They're the most accessable packaging building system, is why. If you're ever actually trying to install something (properly, i.e. not making a mess by just splattering files across the filesystem with 'make install') that isn't already packaged, you're going to have the easiest time with PKGBUILDs (basically, if you can figure out how to compile the software using the instructions for that, you can make a PKGBUILD. The same is not true for other package managers). So they're praised by power users who can manage that and by developers who don't want to learn a harder to use packaging system.
Well, just because it's not relevant to a regular user doesn't mean it's not relevant to me and people like me.
The regular user only installs software others have packaged.
I end up packaging software sometimes (maintain a few AUR packages) but my main use-case is being able to modify the packaging myself for private use, generally to apply custom patches or alter compiler flags etc.
Being able to do all of this easily without ending up with a pile of goop everywhere from `git clone thing && cd thing && make && sudo make install` is nice.
I'll take AUR over random blog articles telling me to add some obscure deb repository to my Debian/Ubuntu sources. At least AUR gives an accepted process to submitting and maintaining these third party packages. You can leave comments and read comments by others on a particular package. You can check the PKGBUILD which exists for every package and can be accessed in the same way for every package. And I do check every single PKGBUILD before installing some random package. AUR provides infrastructure and processes. It centralises the whole idea of "third party packages". Not having AUR just means everybody has their own repos for particular programs and no way for users to communicate in an easy and accessible way, which I think is pure insanity.
Honestly, I think AUR is one of the best things to ever come out of Linux, because it's not just a repository.
You act like the choice is either having a small official repo plus PPAs or a small official repo plus AUR, when the context of this thread is a comparison is with OpenSUSE Tumbleweed which has a large official repo (plus PPAs in the form of other OBS repositories if you really need them, but you almost certainly don't). A large amount of software that an Arch user has to use the AUR for is in the OpenSUSE oss repo that is supported officially and "tested" when snapshots are released (though the amount of testing varies with the software, of course).
Because it is. When using OpenSuse, I still had to go looking for packages that weren't in the official repos.
> plus PPAs in the form of other OBS repositories if you really need them, but you almost certainly don't
This is extremely presumptive and wrong. I find it very frustrating that any issues with these official repos is dismissed as "oh but you don't need extra PPAs ever". My guy, yes, I do. It happens way too often and it's very frustrating when it does, because the options for handling it in non-Arch based distros are completely insufficient and terrible.
But then again, what do I expect. Any complaints about Linux are pretty much always dismissed out of hand.
I actually prefer using Windows because Windows users generally aren't such arrogant pricks when there are issues.
what do you think "a regular user" of ubuntu/suse/fedora/arch/etc. looks like?
back when I was using arch I wrote pkgbuilds instead of configure/make/installing to my home folder. kept my ./local/(bin|lib|share) clean and meant I could update it easier or uninstall it with pacman.
As to runnning random build scripts, well I already do that anyway. Any software that isn't provided by my package manager requires me to run random build scripts from random people. I sure as hell am not reading through every line of code in say... trealla prolog before make-ing it.
An immutable rootfs distro should be a bit more resilient than the average Linux install. Not having to add any random repos to your base system is a great feature. When I run random build scripts I mostly use containers or VMs, that also works for the odd unmaintained but useful software that requires vintage Ubuntu LTS libraries.
> back when I was using arch I wrote pkgbuilds instead of configure/make/installing to my home folder. kept my ./local/(bin|lib|share) clean and meant I could update it easier or uninstall it with pacman.
yeah, and the number of people who use a non-android linux and aren't "tech savvy" rounds to zero. It is very weird to ask "what's in it for the regular user" with the assumption that "the regular user of e.g. SUSE" is the same as "the regular user of a computer"
With Tumbleweed (and probably Aeon) you can use factory/open build service to build your own packages. You could even fork Aeon or MicroOS and turn to that into something like a customized Arch Install that also benefits from whatever automated tests Tumbleweed comes with.
I moved from Arch to NixOS. In case it helps these are my main motivations:
* In Arch, very rarely, I'd apply an update that would break things. Going back to a stable system was a pain. I ended up with some snapper setups and a list of commands to convert the latest snapshot to a r/w 'root' that worked well enough. With NixOS I just reboot to the previous generation on any issue.
* For development I'd often use third-party tools to manage multiple language versions. For example I used pyenv. With Nix it's much easier to just use python39, or nodejs-18_x, or whatever as Nix makes this really simple.
If you do decide to try it out I'll recommend using the github query 'path:*.nix ___' to copy off others, as the main complaints about Nix seem to center around the language.
i think it's possible to have both. we just haven't decided how to implement these improvements, that's why we see so many different immutable/snapshot/… distros with lacking ux — for now
> i.e I think it's easier to repair or replace a simple system than it is to try work out how to do novel things on a complicated but safe system.
I mean, that's the point. If the configuration of the machine is declarative it's easier to replace it with a duplicate that works. Declarative in this context literally just means "the entire state is declared in a way that you can roll it back"
I run it for the base system, and then use gnu Guix for the rest. I don't have time to deal with a system that changes under my feet. Being able to rollback both the base system and userland has saved me twice. It also means I can use one tool for userland things instead of both distrobox and flatpak.
Until I am smart enough to run guixSD completely this feels like a decent compromise.
I mean the song is funny but it's hilarious that they still mispronounce it.. he constantly sings susAH instead of susEH .. how it should be pronounced, at least if you pronounce it as a German word.
the only guy I've ever known to correctly pronounce SUSE was an older fellow who was, towards the end of the 00s, pronouncing "Ethernet" with a short e, as though it were to rhyme with "meth"
anyway, that's why I'll always call it Soos even if I know I'm wrong
that guy probably also pronounced it "GIF" but it's been too long to say for sure
Second, getting everything from flatpak would be a good idea, if the software I need would be available as certified flatpaks. Downloading random flatpaks is IMHO the same as downloading random executables.
Third, the AARCH64 version is not distributed anymore (this was the version I tried/used), AFAIK because the initial install script could not download the non-existent Firefox for AARCH64 flatpak (thanks Mozilla).
In the end I still like the idea of Aeon and hope they change their positions concerning firewalls. Points two and three are obviously not Aeons to fix, so I hope we as a community (and Mozilla) get there in time.
I use a MicroOS + wayland + sway and friends setup, since I don’t like big DEs. I completely agree with you about needing a firewall, but it was an easy fix to continue taking advantage of all the good parts:
sudo transactional-update shell
zypper in firewalld
[setup as you like]
exit
sudo reboot
Now you have MicroOS or Aeon as you like it. It’s a discouraged practice, but if you stick to the default repos and well-used packages, you can definitely tweak the opinionated defaults without compromising the vision.
I understand what you're saying, and I understand the maintainer's POV. But, nothing prevents you from installing firewalld, right? It should just work.
i agree with the flatpak, sadly this will probably not change.
BUT! if you are a developer, you could run with distrobox graphically applications from the distrobox from OpenSUSE!
I am starting to use this on tumbleweed and there are even "exporters" so the app in the distrobox will be exported to your application menu on the metal!
Does that app have access to a full terminal ? Like if I install vs code inside distrobox, will it have access to the systems or the container terminal?
the firewall question is interesting. I guess I understand their perspective: If nothing is listening/running then what’s the point of the firewall? The system is immutable so the security posture is a known quantity and cannot change at runtime.
You could argue that running an additional firewall service would actually be increasing the attack surface, in the sense that more code is worse than the absence of code.
Not sure I agree with their stance, but good on them for having the courage to revisit some our default assumptions. Some decisions will work out and others they’ll have to finetune.
The base system does not need a Firewall, according to them, and they might be correct about that or not.
IMHO the point of having a firewall which simply denies all incoming connections is, that once a user starts installing a few programs, sooner or later some of them might open ports, even w/o malicious intent.
If they want to provide an easy to use and secure system, IMHO there should be a firewall and each port has to be opened explicitly.
In the end, this is really down to opinion and there is no objective true answer, so I'd rather use Fedora-Atomic if I need immutability.
I can see where the no firewall argument is coming from and definitely on my own Linux laptop, I try and keep the number of ports listening down as much as possible, but it is tricky and it requires a lot of vigilance as sometimes applications you wouldn't expect to, will start services. Things like Spotify and Steam can open ports.
So having a firewall running can provide a bit of extra protection in case you don't always check to see what ports you have open/listening.
What's the benefit to a traditional consumer application of opening ports these days, besides maybe for local network data exchange (which, I assume, is what Steam does since I know it will sync game updates between machines on the same subnet). I would hazard that the global number of laptops and desktops with public IPv4 addresses in 2024 is probably in the triple digits, given that basically every provider I'm aware of hands off with a "Wi-Fi modem" that converts whatever weird delivery medium (fiber, DSL, cable, etc.), gets its own maybe-public IP, and does NAT for clients. Hell, I don't even have my own IPv4 address since Starlink does CGNAT.
does "getting stuff done" include having the Gnome password prompt consistently lose focus and send your password into background applications because it does that a lot
openSuse haven't made it easy. Turns out both are an option of the MicroOS installer. I'd not call that a separate distro, but it seems to have product pages like that.
COSMIC is the new rust-based DE that's still in alpha right? I wasn't using that.
I'm pretty sure it's a window manager issue. gksudo (?) requests focus, and then while you're typing something happens and your keyboard loses focus on the password field and keystrokes go to an app behind that window.
there were also other fun things like running an app in a debugger, then setting a breakpoint in that app triggered by a UI event, would then immediately cause the entire desktop environment to lockup to mouse events. you'd have to use the keyboard to trigger the "application unresponsive" window and then tab to "close".
> COSMIC is the new rust-based DE that's still in alpha right? I wasn't using that.
I'm not referring to that, I'm referring to the "COSMIC" extensions to GNOME that PopOS adds to reshape GNOME into their vision of a desktop environment (the vision is what they call COSMIC). Those COSMIC extensions are the predecessor to the COSMIC DE, which is a standalone instantiation and elaboration of that vision, and have been part of PopOS and enabled by default for a very long time. The COSMIC extensions are extremely extensive, substantially changing several huge aspects of gnome, as well as being written in typescript, then compiled to JavaScript and then translated into GJS with a — I kid you not — a sed script. So I think it's entirely possible that your problems could have been caused by those extensive extensions, and not the gnome window manager itself. Especially since other users of gnome haven't shared your experiences.
There's also the fact that pop OS's version of gnome is now more than 2 years behind and they still haven't updated it, since they are holding back waiting for cosmic de to be ready instead, so you may have been experiencing a bug that has long been fixed for everyone else. System 76 seems to try to do their best to update a lot of the packages in pop os's repos, but they can't keep everything artificially up to date since they aren't tracking Upstream Ubuntu updates anymore, either, since all of their resources are going to Cosmic de, so a whole bunch of packages including for instance node are two years out of date on PopOS, not just gnome, incidentally.
Looks like it uses btrfs for everything. Btrfs performs notoriously poorly for VMs and databases without the "nocow" hack, which is a no-no for raid1 setups. What should I do if I'm an Android developer who frequently tests code in Android VMs?
Separate root and home partitions brother. As in, keep root on BTRFS for rollbacks and keep home on extf4 where you keep.all your dbs and VMs. This way you get best if both worlds, no need to mess with nocow parameters.
I've been using (what eventually evolved into) Aeon for about a year now on my primary desktop and it's been absolutely perfect as a daily driver, especially with some choice GNOME extensions like PaperWM.
Unfortunately, the switch to the new Tik-based installer resulted in a loss of full-disk encryption support, so until that gets re-added I'm in a bit of a pickle when it comes to installing it on any future machines (including my shiny new Framework 16).
Tumbleweed is a very solid distro, one could also use it as an "immutable" distro by installing the software from Flatpaks and distrobox. Been using it for more than a year after a decade on Ubuntu.
The fact that I can go months without updating a rolling distro and things very rarely break is incredible. Tumbleweed is rock solid. (Personally, I've never experienced a break, but I know one just happened for a lot of people. Granted, I believe it was Nvidia or Mesa drivers at fault.)
I'm not the person you're replying to, but what annoys me about this on Fedora is that I use full disk encryption in my notebook, so I need to type the password after the reboot for the updates and then one more time to get it running again. I wish it could deactivate all services and somewhat return to a state similar to early boot in order to apply the updates, rebooting only once afterward. This would be especially useful for shutdown updates, in which case no password would be necessary.
I was hoping that systemd's soft reboot function would help a lot here. It would make it unnecessary to request password when using full disk encryption and would require less downtime. Last I checked it didn't work in Silverblue though.
if kernel is updated the OS would have to be rebooted anyway unless live patching is configured. Rebooting after an update is probably more common & less annoying than one would think.
I use OpenSUSE Leap with transactional server, which is another immutable distribution by SUSE. I run it on my storage node primarily serving a ZFS pool over the network. This means the server is more like an appliance (NAS) and this immutable setup is a perfect fit IMO.
I suppose I could have use Aeon instead? But I like having OpenSUSE Leap across the fleet too which others doing more heavy lifting.
Has anybody tried Spiral and Gecko? Same developer adapted Debian Sid and Suse Tumbleweed with btrfs snapshot after each install. How did they/similar systems work in practice for you?
I use tumbleweed. It's like Arch but without the blood. I need a bleeding edge distro that's preconfigured for sanity out of the box and just works. If you do too give it a go.
Same. I got annoyed with Canonical's user-unfriendly changed, tried Debian and found that packages were out of date. Tried Tumbleweed and never looked back. Actually it was their KDE Plasma that won me over, but the rolling release and built in snapshot features have been amazing.
I've also used Tumbleweed after I had some problems with Arch. It's a very good distro but I ultimately switched to kubuntu she xubuntu because it was easier to install software.
I open Discover in KDE Tumbleweed, search for the SW I'm looking for, click Install, and then type my admin password to confirm. Don't even need to open the command line.
What I mean is that, when trying to find software for Linux, nearly everyone has an option available for Ubuntu and apt. The same isn't true for Tumbleweed unfortunately. You can fuck around with Fedora rpms when SUSE doesn't have an option but I had some issues with some software I use regularly. I still think Tumbleweed is an excellent distribution, I just find that installing the software I need is most frictionless on Ubuntu distributions.
Packages that aren't native to Tumbleweed are available in Discover as Flatpacks.
You're probably trying to look for software "the Windows way" of downloading the sw from a website in which case you mostly see .debs and .rpms but that doesn't mean it's not available in the tumbleweed repos or Flatpacks if you search Discover.
Niche stuff not available in the official repos or Flatpacks can be found in the OPI(similar to Arch AUR) where the proprietary codecs also are.
Can you stop dodging the question and changing the topic? You still haven't mentioned what software you haven't found on Tumbleweed but exists on Kubuntu.
I use tumbleweed. In my line of work I need the official Nvidia divers and I 'prefer' to leave secure boot enabled. Tumbleweed makes that a huge pain in the ass... which is much better than most distros, where it's often impossible. Pop OS is the smoothest official Nvidia experience, but they don't support secure boot.
I use it for similar reasons! But I do not have the pain point?
For me secure boot just worked out of the box with Tumbleweed? Maybe old information?
Nvidia official driver installation is a bit annoying. You need to add the nvidia repo. It is the same problem for other linux distros, like debian.
The process for using MOKutils to re-enroll the module key, requiring yet another password that I can't easily get from my password manager with every single driver update is a PITA. Maybe it's just that fragile on my system.
The repo is official, but it's not installed by default. It's very easy to add as there's a package that adds it using the new services system, and zypper can auto-detect the correct packages for the hardware:
I am not 100% certain because I did not pay that much attention but I am fairly confident that the nVidia repo was set up without me entering any command when I installed Tumbleweed on a new desktop 3 weeks ago.
Yeah, I'm sure it's braindead simple if you regularly do systems stuff on Linux, like I used to. But not having done that for a while, I needed to a) find the info for the different ways to install the driver on this distro and figure out which one applies, b) figure out which specific driver version you need, c) install it and then figure out which of the few dozen other packages in that repository you need to install, d) manually blacklist the nouveau driver which it inexplicably still tries to load, e) reboot which automatically bookts into MOK utils which asks you for a password and seemingly doesn't accept anything you enter, f) figure out how to re-run MOK Utils on boot to enroll the module, g) futz around setting the MOK Utils password until you're about to throw your computer out the window, h) figure out that the utility doesn't work with non-querty keyboard layouts, i) have to re-enroll every time the driver updates.
Sure, it might be simple as far as Linux administration tasks go, but I'm not using Linux because I like dickering around with Linux-- I need a POSIX system that supports my hardware to use as a professional tool. Regardless of whether or not it's a fair comparison, my comparison is to the experience with Windows and MacOS. It's not a judgement of the competence of the people that made it or the overall product quality-- it's apples to oranges. Unfortunately, it's Apples-to-Oranges for a lot of UX and QoL factors as well.
SUSE did $0.67B in 2022. It's a live and vibrant company that focuses on traditional Linux and its management. Though it has cloud & container offerings of course, I think SUSE's greatest strength is for people that want to use multiple Linux distros (Debian and Debian-likes, RH and RH-likes) and get support for all of them under one roof.
I don't know which particular customers are using it, but given the revenue, there must be _a lot_ of SUSE systems in the corporate world.
I use it for (non-German) computational physics and various sciency stuff. It strikes a nice balance between stability and updates. It just gets out of the way and does not need babysitting. It’s great.
It works fine with the nVidia drivers without messing around too much, which is not something I can say about most distributions I tried.
> I use it for (non-German) computational physics and various sciency stuff. It strikes a nice balance between stability and updates. It just gets out of the way and does not need babysitting. It’s great.
This is true for most distros though, so when I people see that as the reasoning for using a niche distro, I always think the reason is more because they like using a niche distro.
Not with secure boot (which I forgot to mention but I have to enable). AFAIK today there is OpenSuse, Ubuntu and RHEL. Last time I checked (about a year ago) there was OpenSuse and that was it.
> I always think the reason is more because they like using a niche distro.
Not at all. First, OpenSuse is not really niche. I don’t care about being edgy (or I would run something like Arch or Gentoo). It just is solid and works well. Again, it’s the robustness-updates balance.
> Not with secure boot (which I forgot to mention but I have to enable). AFAIK today there is OpenSuse, Ubuntu and RHEL. Last time I checked (about a year ago) there was OpenSuse and that was it.
They're all just using the same MS signed loader are they not? And even if not, you certainly can on any distro. Secure boot and linux isn't a problem that ties you to a specific distro.
> Not at all. First, OpenSuse is not really niche.
It sure is, especially if you're not German or even European.
> It just is solid and works well.
Right, but so do most distros. Computing has advanced a lot so stability is the norm, there isn't anything special about OpenSuse.
Europe is a big place. Either way, it's the most rock solid distro in my personal experience.
YaST, their system configuration tool, is the best there is. It has a GUI, TUI, and sets of commands that let you configure everything without having to guess much of anything.
I am often tinkering too much with my system, and have been burned a lot in other distros, but somehow openSUSE always has my back. Not to mention the great docs, great community and their open build system.
I run Leap, but those that want something more "up to date" can choose Tumbleweed. If you want a rolling distro but are more cautious about it, you can run Tumbleweed Slowroll.
Their NVIDIA support is great as well, as others have pointed out. It's not just the fact that you can secure boot, it also allows you to easily add an official NVIDIA repo for anything CUDA, profilling, container and video game development related (NVIDIA's texture tools).
Sure there is Ubuntu and Redhat, but the former is quite opinionated, and the latter's community version is a bit too flaky for my taste given it runs the latest and "greatest" of everything.
Relative to the rest of the world, Europe is pretty small. And even then, OpenSUSE being used more often in Europe doesn't mean it's more popular than the other big distros in Europe.
Besides all that though, my point was non europeneans runnin it outside of europe are doing so liekly because it's niche.
You've given some good points about OpenSUSE, but my point is there is nothing special about those points and OpenSUSE.
All the main distros are stable and handle whatever issues you think they might not. Dependency hells are no longer a thing, hardware not working, software not being available or being buggy etc. These are all solved issues on every main distro.
> but somehow openSUSE always has my back
This has to be nothing more than confirmation bias.
There's nothing really different about OpenSUSE over Ubuntu or Debian except preference. There is certainly no objective advantage outside of happiness that comes from a user using something they are familiar with.
> but the former is quite opinionated, and the latter's community version is a bit too flaky for my taste given it runs the latest and "greatest" of everything.
Just like openSUSE has variants so do these, and you can certainly find one that matches your preferences for stability and bleeding edge, or whatever else balance.
One issue that always burned me with Fedora is a little configuration file. Wacom tablet support is basically gimped due to it. Everytime I use it I have to fix that, and no, it's not the wayland issue but one due to poor scroll handling. It's hard to find the fix and I tried looking into it right now. Last time I tried it was on Fedora 39, it has been there since 34. Maybe not in 40 though.
I've tried plenty of distros, and sure some of it is personal preference. But still, I have often seen little issues like these be quite difficult to find solutions for. And many distros still ship insane defaults in some more niche circumstances that aren't properly tested. And many a times, those make up preferences in peoples' minds. And, arguably, they are objective reasons for doing so.
Be it due to sharing many common parts with its enterprise solution, or simply because a particular guy didn't bork my drawing tablet with some config meant to circumvent GTK scroll behaviour, or because they have a platform that you can use to build and distribute packages for theirs and other(!!!) package managers (so they have good experience automating these kinds of processes)... I don't know the reason, but I've had a better time with this distribution. I just wanted to share that it is a good one.
> One issue that always burned me with Fedora is a little configuration file. Wacom tablet support is basically gimped due to it. Everytime I use it I have to fix that, and no, it's not the wayland issue but one due to poor scroll handling. It's hard to find the fix and I tried looking into it right now. Last time I tried it was on Fedora 39, it has been there since 34. Maybe not in 40 though.
Isn't Fedora the 'testing' or bleeding edge distro/project for Red Hat? Did you on RHEL Desktop? That's the only RHAT based product that should have defaults that work with those tablets, IMO.
Don't you think it's likely there is some hardware out there where an OpenSUSE default causes an issue that doesn't happen in other distros?
> I don't know the reason, but I've had a better time with this distribution. I just wanted to share that it is a good one.
That's more than fair. I'm just so skeptical when people say $distro is so much better or more stable than all the others. Most of the time someone just had a better experience with it, rather than it being objectively better in some way. All the main distros are pretty damn stable and solved all the frustration causing issues a long, long time ago IMO.
> I'm just so skeptical when people say $distro is so much better or more stable than all the others.
openSUSE has a more sophisticated (and more expensive, computationally and financially) automated QA process (Open Build Service + OpenQA) than many distros, which is what has earned its rolling releases the stability that has garnered this reputation. It's perhaps also affected by the predominance of Arch in the rolling release space; it's easy to look stable compared to a distro that sees it as the user's routine duty to watch for and fix certain kinds of incompatibility problems with updates.
It's true that nowadays all distros are pretty good, but there are real technical differences between openSUSE and other distros which matter. The only distro with a distinct lineage that has a package manager much like openSUSE's is Fedora, and that's because dnf has copied key zypper features. dnf and zypper handle collections of multiple package sources (repository) much better than anything available in the Debian-based world does thanks to the notion of vendor change.
It's of course true that there are good technical reasons to prefer other distros, as well.
> All the main distros are pretty damn stable and solved all the frustration causing issues a long, long time ago IMO.
> openSUSE has a more sophisticated (and more expensive, computationally and financially) automated QA process (Open Build Service + OpenQA) than many distros,
Than which distros, though?
More so than Debian? Debian's seems pretty thorough. More so than Red Hat's, with the amount of important customers that depend on their distro? I'm skeptical. The rest are generally offshoots or geared towards a specific purpose or audience.
> It's true that nowadays all distros are pretty good, but there are real technical differences between openSUSE and other distros which matter.
So let's get into some details and examples! I'm interested and prepared to learn something here, hoping I might be enlightened - I haven't had a moment like that in a real long time, if that makes sense.
> The only distro with a distinct lineage that has a package manager much like openSUSE's is Fedora,
So, what makes the openSUSE package manager so much better than apk, apt or xbps?
Hoping I'm not coming off as too combative, just interested in the convo.
> More so than Debian? Debian's seems pretty thorough. More so than Red Hat's, with the amount of important customers that depend on their distro?
Yes and yes. openSUSE's automated testing builds each package not just in a chroot but a new barebones VM, to ensure that depdndency definitions are complete. I've seen Fedora devs remark about how they don't have that kind of budget to throw as, e.g., COPR builds, the implication being that they have to put more engineering into their testing infrastructure. (Sorry, it was years ago and I don't have the energy or time to source it.)
Those VMs are accompanied with screen scrapers that perform OCR in order to automatically test the pre-boot environment, before a display server comes up.
It is possible that other distros are catching up here (I know nixos-tests can include virtualized, multi-machine, networked integration tests, for some packages, for instance). But this testing infrastructure for openSUSE is quite mature. See, e.g., this presentation from nearly a decade ago: https://www.youtube.com/watch?v=2K6ZmvIOtPw
As for Debian, the greater centralization of openSUSE's package sources is perhaps worth emphasizing as a major difference here. For openSUSE, package sources are all checked into special VCS system that is part of the Open Build Service (which is capable of tracking and building external packages, including packages from other distros as well). With Debian, package sources are uploaded as binary artifacts by maintainers who can all have their own standards for style/conventions, testing, and other policies. It's not as easy to get a. God's-eye-view of Debian. This blog post provides some general insight into quirks of Debian's non-standardized processes, perhaps a few years out of date now (I don't know), but I hope it makes clear how it might be plausible for a smaller distro to have more mature centralized, automated testing: https://michael.stapelberg.ch/posts/2019-03-10-debian-windin...
> Debian generally seems to prefer decentralized approaches over centralized ones. For example, individual packages are maintained in separate repositories (as opposed to in one repository), each repository can use any SCM (git and svn are common ones) or no SCM at all, and each repository can be hosted on a different site. Of course, what you do in such a repository also varies subtly from team to team, and even within teams.
> [...]
> When you want to make a package available in Debian, you upload GPG-signed files via anonymous FTP. There are several batch jobs (the queue daemon, unchecked, dinstall, possibly others) which run on fixed schedules (e.g. dinstall runs at 01:52 UTC, 07:52 UTC, 13:52 UTC and 19:52 UTC).
> Depending on timing, I estimated that you might wait for over 7 hours (!!) before your package is actually installable.
Debian is an amazing project and it's no happenstance that it has served as the base for many successful distros as well as thrived in its own right for many years. But there's some social and technical cruft there that leaves room for some competition, isn't there?
(It looks like nowadays Debian has actually adopted SUSE's openQA as part of its automated testing stack: https://openqa.debian.net/)
I have a fuzzier picture of how OBS/openQA compares to Red Hat and Fedora's package building and testing tools! You've reminded me that I'd like to learn more about that. But do dig into OBS to get a sense of how SUSE is built. It may even be useful to you: their build cluster offers lots of free compute and it'll let you build and host repos for free— even of other distros like Debian and Red Hat.
None of the tooling questions are the real stuff, though— the real stuff is the predictability and freshness of openSUSE Tumbleweed, which users of other rolling release distros tend to speak favorably about once they've tried it.
Tumbleweed is substantially more up-to-date than Fedora Rawhide, but is also markedly more stable and more committed to stability— the expectation is generally that Tumbleweed should be highly usable by and reliable for non-experts, but the expectation for Rawhide is that it exists primarily for Fedora developers and any breakage is on you.
I'd be happy to compare zypper (and dnf) to apt and all (I admit I've not used Void Linux). I've gotta go for now!
> openSUSE's automated testing builds each package not just in a chroot but a new barebones VM, to ensure that depdndency definitions are complete.
How are you sure other distros don't do that? I'm also not convinced that building in a vm instead of a chroot is any kind of advantage.
> Sorry, it was years ago
So isn't it possible they've changed things now?
> Those VMs are accompanied with screen scrapers that perform OCR in order to automatically test the pre-boot environment, before a display server comes up.
So to me, all that sounds is nifty, but not especially impressive. Any devops team could write something to do the same in a couple of hours. If other distros don't have that, it could simply be because they don't need it.
> It is possible that other distros are catching up here
This is the crux of your position, though, that all these other distros are that much more behind openSUSE. You start your reply with "yes and yes", very confident, but now here in the meat of the discussion you say you don't actually know.
I'm not trying to be combative or adversarial here, but it really seems like a lot of assumptions are being made.
> With Debian, package sources are uploaded as binary artifacts by maintainers who can all have their own standards for style/conventions, testing, and other policies.
I mean, Debian as a system has a standard for its packages, standardizing what they felt they needed to, and all packages adhere to that and the system has been working well, possibly longer than suse has even existed.
> but I hope it makes clear how it might be plausible for a smaller distro to have more mature centralized, automated testing
Well, I never doubted that was possible. I'm just skeptical OpenSuse's testing setup is/has leading/led to a system that is more stable or whatever other supposed advantages it has over say Debian and Red Hat.
> But there's some social and technical cruft there that leaves room for some competition, isn't there?
Is that cruft not just project preferences, of which each distro has it's own version?
> But do dig into OBS to get a sense of how SUSE is built. It may even be useful to you
My days of installing a distro for fun have been over for a long, long time. Now I only really like Alpine, Devuan if I need something chunkier. I appreciate the suggestions and conversation though, thanks!
> So to me, all that sounds is nifty, but not especially impressive. Any devops team could write something to do the same in a couple of hours. If other distros don't have that, it could simply be because they don't need it.
This isn't a complete description of openQA, but an illustrative snapshot. Btw, it looks like Fedora has adopted this tool as well (several years ago, hehe): https://openqa.fedoraproject.org/
And yet there is no one anywhere who claims that Fedora Rawhide is more stable than openSUSE Tumbleweed. This is in part because of a real difference of purpose and outlook; Tumbleweed is somewhat exceptional as a rolling release which explicitly emphasizes stability through automated testing as a value and goal.
> > It is possible that other distros are catching up here
> This is the crux of your position, though, that all these other distros are that much more behind openSUSE. You start your reply with "yes and yes", very confident, but now here in the meat of the discussion you say you don't actually know.
> I'm not trying to be combative or adversarial here, but it really seems like a lot of assumptions are being made.
Sure. I'm not an active contributor to openSUSE or Debian or RHEL, and I'm not currently working on a study of their production pipelines. I'm just trying to give you a clearer picture of some differentiators that I've picked up as a Linux user, developer, and ops professional with the incidental experience I've had with those distros in the past ~20 years.
But I think some of these 'assumptions' are pretty fair, e.g., the distro that created and chiefly maintains openQA has a more mature automated testing infrastructure than a distro that only adopted it a few years ago.
> My days of installing a distro for fun have been over for a long, long time. Now I only really like Alpine, Devuan if I need something chunkier. I appreciate the suggestions and conversation though, thanks!
You don't need to install (or use) openSUSE to play with OBS. Just make a free account on build.opensuse.org and start building packages for any DEB-based, RPM-based, or PKGBUILD-based distro (as well as container images incl. for Docker, AppImage, Snap, and Flatpak). No Alpine/apk support yet, sadly. Idk whether Devuan is supported as a base distro or not, but there are some repositories intended for use with Devuan hosted on build.opensuse.org, e.g.: https://build.opensuse.org/project/show/home:bgstack15
> Well, I never doubted that was possible. I'm just skeptical OpenSuse's testing setup is/has leading/led to a system that is more stable or whatever other supposed advantages it has over say Debian and Red Hat.
The only way you can really compare the stability of two distros is by actually running them. What I can offer you short of that experiential knowledge is that openSUSE has a sophisticated, mature testing infrastructure of which major components have been adopted by the other distros you cite as examples.
You will be hard pressed to find someone who can compare the testing infrastructure of even just two distros in great detail and totally current. This guy probably can, he's a major NixOS/nixpkgs contributor, a Fedora developer, and an Alpine contributor: https://github.com/fabaff . I can't personally think of anyone else, but I'm sure there are some.
I can tell you that still fairly recently, one Debian developer gave a talk about the Open Build Service with the subtitle 'fix the mess': https://www.youtube.com/watch?v=Nh0FoS_J_Gs
> Is that cruft not just project preferences, of which each distro has it's own version?
Yes? But preferences can be literally anything with widely varying impacts on social and technical processes... so to say 'everyone has them' doesn't really say anything at all.
Anyway, about the actual package managers I can be much more concrete because I've used them all much more recently.
> So, what makes the openSUSE package manager so much better than apk, apt or xbps?
Like I said, I won't speak to xbps because I've not used it. Additionally, this comes with the caveat that you may prefer package managers that make different tradeoffs than zypper and dnf do. But here are the things that openSUSE's package manager (and nowadays also Fedora's) get really right imo that apk and apt are lagging on.
This means that resolving dependencies in a way that is guaranteed to be both correct and complete requires is hard (indeed, it's NP-hard). Dependency managers that take this seriously employ SAT solvers, openSUSE's now lives in this library: https://github.com/openSUSE/libsolv. apt lagged behind zypper in this area for many, many years, and just finally got a SAT solver for dependency resolution a couple months ago: https://blog.jak-linux.org/2024/05/14/solver3/ . Apk doesn't have a backtracking dependency solver and thus will sometimes fail to identify possible solutions to dependency resolution problems, even when they exist. But for that, it gets to be fast. I believe pacman and xbps also make that same tradeoff (completeness for speed).
Apt has similarly lagged in establishing a modern command-line interface. Zypper provided a modern, unified subcommand interface for managing all packages and repositories when it came out nearly two decades ago, whereas apt has only offered a modern subcommand interface for less than a year ( https://9to5linux.com/ubuntu-24-10-and-debian-13-trixie-to-f... ), and last I used it (within a year or two) it also still lacked facilities for key management (apt-key was deprecated but there is no integrated replacement). APT is making some very nice advances, but they're still playing catch-up.
The single thing I miss the most with APT, though, is entirely missing, and it's the notion of 'vendor'. openSUSE's package manager introduced me to the concept of 'vendor stickiness' (https://en.opensuse.org/SDB:Vendor_change_update), which allows you to upgrade without changing who is providing what package for you in a natural way. (This idea has also since been adopted by Fedora in their `dnf` package manager, as well.) Zypper's facilities for creating a hierarchy of repositories, prioritizing them, and marking some equivalent to others with respect to 'vendor', are just way more flexible and powerful than anything available in APT.
> I mean, Debian as a system has a standard for its packages, standardizing what they felt they needed to, and all packages adhere to that and the system has been working well
From a packager's perspective, the tooling situation for openSUSE is also way more uniform than for Debian or downstream distros, which can make it easier to get your head around. Even a small amount of packaging experience for Debian is enough to reveal a marked enough difference here to justify a preference for some other distro.
> possibly longer than suse has even existed.
Debian is something like 6 months older than SUSE. SUSE, like Debian, is one of the oldest surviving Linux distributions.
Yes, quite a few of the big SK and Japanese automotive companies do, Hyundai, Toyota, Honda among others from talking to a friend who works in that sector a year or two ago. Pretty certain Walmart and Lenovo work with SUSE as well.
While I am a German and started out with SuSE many years ago, I then left for Gentoo and Fedora / CentOS / RockyLinux and didn't look back for more than 15 years. Recently I gave Tumbleweed a shot and was surprised how good it was. I have since started switching some of my machines over and have been recommending it to friends.
Rackable, which was the company wearing SGI skin for few years and which was acquired by HPE, shipped SLES as their standard solution, with RHEL as second option.
Me. 25 years on Debian, but couldn't get it to cooperate for my VFIO passthrough multi-workstation. Arch worked great until one day, a few days before I had to leave home for a couple months, I unwisely performed updates which broke everything so comprehensively that I couldn't get them fixed in time and ended up having to rely on cloud compute rather than my GPU. (This actually happened twice, but only once before travel.) I've been on Tumbleweed since. The one time it broke something, I rolled back the snapshot and continued what I was doing. The machine is an appliance which is exactly what I need: the VMs are where the action is, and I don't want to have to wonder if I will find out I can't use my CAD package or AI sandbox because the host broke again.
That was my thinking too, until I started looking into them again more recently. They're now basically distributing variant alternatives of Fedora that usually have far better implementation and design choices, but mostly use the same underlying technologies. They only have a few in-house tools, unlike Fedora that decides to spin new undocumented ones with questionable design each week it seems, and focus hard on rock solid performance.
And they've been jumping in to fill the gaps RedHat leaves, while also pursuing the more modern edge compute/cluster corporations are very interested in.
As an individual user's daily driver, the documentation is severely lacking for their immutable distros, but if you're experienced enough you can often find Fedora Atomic documentation to get you close. There are still some major hurdles though, like not all Fedora RPMs can be directly installed on OpenSUSE (e.g. CrowdSec) when there is no OpenSUSE version, and some corrected idiocies of Fedora Atomic cause problems (e.g. nix install for ostree only works on immutable distros with ephemerally writeable rootfs, which also eliminates 80% of the benefit of immutables but is the Fedora default and not the default for OpenSUSE).
I am although I am on the fence. As a developer tumbleweed provides me with everything I need - new releases, new kernels, new packages, etc. Mind you I use Leap at work and I gotta say I am really disappointed. There are some new packages which I can only get running inside docker containers which is a huge pita. I might end up going back to fedora 10+ years after I decided I had had enough of it.
I think the key idea is that this system is meant to require zero maintenance; it automates updates, it provides rollbacks if anything goes wrong, it prevents most ways of modifying the OS and sticks applications in containers/sandboxes.
> Every Linux distro promises they are the ”works out of the box” one
Well not every - Arch, Gentoo, Alpine, Slackware, NixOS...
Funny that you mentioned these distro but I've never installed them, perhaps installed Slackware once, more than 20 years ago then just used Red Hat 7 (the original 7 not the later 7 version). After that Ubuntu and its derivatives.
What people don't realized that most of the Windows and MacOS users never installed their desktop OS, it come pre-installed. The main problem with these "works out the box" distro, there's no "box" to start with. Tried to installed Gentoo when it's initially released but it's a death by thousand cuts if you know what I meant, conflict after conflict resolution, and painfully slow installation process due to it's a source based distro.
If Aeon can work as promised, I think it will be a huge success provided that they solve the installation nightmare of many Linux OS and install seamlessly on mainstream laptop hardware.
> The main problem with these "works out the box" distro, there's no "box" to start with.
You know, I realized this recently, as I was updating the HW in my desktop PC. After days of trying to figure out why an AMD GPU is power throttling (and thus giving me ~20% of the performance I paid for), I just gave up and installed Windows.
It pains me (and honestly, it's a huge pain to set up Windows from scratch as well), but at least the proprietary driver blobs that you can download work as advertised.
This really showed me that in my free time, I don't want to futz around with setting up my HW on Linux. I just want to use it. And even though I bought a computer that officially supports Linux (intel nuc extreme), the experience of setting it up is pretty bad even for me, a software engineer who's been using and administering Linux for the past ~15 years at work.
I tried it, in my mind it lacks customizable options that many devs would like to have. Bluefin DX (Fedora Silverblue remix) is slightly better option if you develop for cloud services.
I've been using ArchLinux for ~14 years now, previous to that I used Slackware and Gentoo. IMO it's better to be simple, yes there aren't any guarantees but worst case scenario I can rebuild, run my install script (which might require a few tweaks if it's been a while since I setup a new system), push new keys etc and then I'm up and running again in ~15 mins. i.e I think it's easier to repair or replace a simple system than it is to try work out how to do novel things on a complicated but safe system.
I intend to try NixOS at some point as a foray into these more complicated but "safer"/transactional/immutable/deterministic systems but I just haven't found the motivation yet.