Hacker News Reader

Comment by leetnewb | Hacker News Reader

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.

View on HN

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.

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.

Reply on news.ycombinator.com