Hacker News Reader

Comment by boris | Hacker News Reader

Most of these focus on running containers. What I would like is a distribution that focuses on the reliability of upgrades, both configuration and data. To give a concrete example, I have a Debian server running Apache (with auto-certificate renewal), PostgreSQL, and Postfix. When it's time to upgrade to the next release, it's basically the "it should work, but who really knows, depends on your specific setup you may have to tweak a few things" kind of guarantee. What I want is a rigorous guarantee like we have for relational database schema/data migration.

View on HN

This _is_ Silverblue and other ostree-based repos.

This article is focused on containers because when the root OS is immutable, then mutable developer workflows/etc necessarily happen in containers (distrobox, toolbox, whatever). OSTree is/was commonly described as "git for filesystems". Every update is an entirely new system image which applies a 3-way diff. It's possibly to state in a single command "show me the drift in my config files/data versus the ref I'm running" and/or "show me the diff between my running system and an update I may apply".

I have switched to fedora Silverblue because I wanted my system to be as stable as possible between updates. But I think it's true that one has to delve into container technologies to fully use the OS, and that is a bit of an overhead.

These types of distros are currently suitable for users who are either very advanced OR non-technical (who’s needs are completely filled by an app store).

>It's possibly to state in a single command "show me the drift in my config files/data versus the ref I'm running" and/or "show me the diff between my running system and an update I may apply".

I can see how this can be usable for configuration. But I am having a hard time imagining how this would look for something like PostgreSQL's data files.

You run your DB inside a container as usual - volumes for data storage, read-only base container with non-root user.

/var is not immutable, /home is also relocated to /var/home on Fedora Silverblue for this reason (as far as I recall, it's been a while since I've checked up Silverblue)

I think Silverblue's approach is a good start, but for desktop usage I'd like to see userland "environment" things like DEs get their own layer with a similar treatment as the root OS, so you could e.g. roll back GNOME or KDE independent of the rest of the system if you so desire. This would also make it very difficult to inadvertently put the system in an unusable state through things like dependency conflicts — if your DE fails to start it can simply fall back and start the last known good version.

The lines for what counts as "environment" are fuzzy which might pose a challenge, but the fix for that could be as simple as offering sane defaults and letting the user decide what is/isn't included.

> I'd like to see userland "environment" things like DEs get their own layer with a similar treatment as the root OS, so you could e.g. roll back GNOME or KDE independent of the rest of the system if you so desire. This would also make it very difficult to inadvertently put the system in an unusable state through things like dependency conflicts — if your DE fails to start it can simply fall back and start the last known good version.

Yes! I've been thinking about the same thing as an accessibility feature for disabled users, as well. I recently learned that I'm going blind, and so I've been thinking about how this kind of mechanism could be used to ensure that a system always has, e.g., a working screen reader and fullscreen magnification software. I'd like to add something like this to NixOS, which is my favorite distro and daily driver.

Have you played with distrobox at all?

https://github.com/89luca89/distrobox/blob/main/docs/posts/r...

You would probably get a lot out of NixOS. Sans that, I wonder how Fedora Silverblue would do as a server.

Fedora IoT is essentially the server variant of Silverblue.

Fedora Silverblue is to workstation what Fedora CoreOS is to servers, so the underlying technology would fare very well.

It's what you get with opensuse MicroOS, you upgrade from snapshot to snapshot that are released regularly. I think silverblue works the same but opensuse is easier. I also use Tumbleweed on personal servers, never had issues.

What do you expect to happen when an upgrade to a daemon involves a policy choice?

For example, let's say that you have Postfix using a smarthost as a relay, and the new version of Postfix requires relays to have a shared secret for authentication with each of their trusted clients. That isn't something that can be handled by an automated config translator.

This sort of thing happens a lot. The best that can be done is putting the changes into a document for you to read, understand, and then make decisions.

> This sort of thing happens a lot. The best that can be done is putting the changes into a document for you to read, understand, and then make decisions.

A distro that has a simulate upgrade command, which generates a report on all these incompatibilties, would be one way.

Debian has a very complete upgrade doc, with gotchas, and workarounds.

It should be read completely, if you maintain a lot of boxes...

(It isn't the same as you want, but it absolutely does take "the unknown* away.)

> For example, let's say that you have Postfix using a smarthost as a relay, and the new version of Postfix requires relays to have a shared secret for authentication with each of their trusted clients. That isn't something that can be handled by an automated config translator.

This would be roughly equivalent to adding a new column or a table in a relational database with some non-NULL/empty data in it, right? Somehow we deal with this in that case, or at least we are forced to deal with it or the transaction gets aborted rather than what we have currently, which is, "oops, new postfix has been installed, you didn't read the documentation carefully, and none of your servers can send mail anymore".

As an example, Apache 2.2 to 2.4 changed configuration syntax such that as far as I know there is no configuration converter that will work for all configurations. So users of all distributions had a hard time.

How would your distribution make this better?

I’ve recently switched to fedora and I’m having a great time in this sense.

Reply on news.ycombinator.com