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

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.

It's worth noting that the benefits of Nix shell you mention can be enjoyed from the comfort of another distro with the Nix package manager.

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.

Yeah I should give Tumbleweed a try at some point.

It's hard to give up the Arch PKGBUILD system though, it's an even simpler ebuild which was originally why I loved Gentoo so much.

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.

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.

> 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.

This is exactly what a tech savvy user would do.

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"

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.

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.

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.

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.

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 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" ?

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 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.

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.

FYI, in case you missed that, Leap has been EOL since late 2022.

Leap 15.6 was released on the 12th of this month.

https://news.opensuse.org/2024/06/12/leap-unveils-choices-fo...

It might be the last OpenSUSE using the traditional release model, but it's not EOL.

I think they meant to say specifically Leap 15.3

Definitely possible, but there was considerable talk about the end of Leap. Thought it was still worth mentioning.

> 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"

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 just haven't found the motivation yet.

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.