5 ms·

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

by boris 4y ago

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.

znpy 4y ago
I’ve recently switched to fedora and I’m having a great time in this sense.
ajdude 4y ago
You would probably get a lot out of NixOS. Sans that, I wonder how Fedora Silverblue would do as a server.
- itsmartapuntocm 4y ago
  Fedora IoT is essentially the server variant of Silverblue.
- bonzini 4y ago
  Fedora Silverblue is to workstation what Fedora CoreOS is to servers, so the underlying technology would fare very well.
evol262 4y ago
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".
- zvmaz 4y ago
  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.
  - thinkmassive 4y ago
    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).
- boris 4y ago
  >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.
  - ElectricalUnion 4y ago
    You run your DB inside a container as usual - volumes for data storage, read-only base container with non-root user.
  - mhitza 4y ago
    /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)
- deleted 4y ago
  [deleted]
- kitsunesoba 4y ago
  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.
awoimbee 4y ago
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.
dsr_ 4y ago
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.
- mhitza 4y ago
  > 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.
  - b112 4y ago
    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.)
- boris 4y ago
  > 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".
rlpb 4y ago
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?

by boris 4y ago

znpy 4y ago

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

ajdude 4y ago

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

itsmartapuntocm 4y ago
Fedora IoT is essentially the server variant of Silverblue.
bonzini 4y ago
Fedora Silverblue is to workstation what Fedora CoreOS is to servers, so the underlying technology would fare very well.

evol262 4y ago

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

zvmaz 4y ago
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.
- thinkmassive 4y ago
  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).
boris 4y ago
>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.
- ElectricalUnion 4y ago
  You run your DB inside a container as usual - volumes for data storage, read-only base container with non-root user.
- mhitza 4y ago
  /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)
deleted 4y ago
[deleted]
kitsunesoba 4y ago
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.

awoimbee 4y ago

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.

dsr_ 4y ago

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.

mhitza 4y ago
> 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.
- b112 4y ago
  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.)
boris 4y ago
> 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".

rlpb 4y ago

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?