![](/static/253f0d9b/assets/icons/icon-96x96.png)
![](https://lemmy.ml/pictrs/image/q98XK4sKtw.png)
This article reads like a press release from SUSE.
This article reads like a press release from SUSE.
Russia Today comes to mind
Sure, but for Russia it’s the actual doctrine: https://en.wikipedia.org/wiki/Russian_military_deception
you’re a rock star
I don’t know if this works in docker
(usually there is 1:1 equivalency between the two), but with podman
you can do something like:
podman stop --filter name=foo
man podman-stop
tells us:
--filter, -f=filter
Filter what containers are going to be stopped. Multiple filters can be given with multiple uses of the --filter flag. Filters with the same key work
inclusive with the only exception being label which is exclusive. Filters with different keys always work exclusive.
If you do a rollback, I assume your data remains? I assume you might need to reinstall apps which were not in the original? Or does it keep apps, data and settings across a restore?
In CoreOS (Silverblue), /etc
, /var
and /home
(which is in fact a symlink towards /var/home
) are regular writable partitions, so your data, configs and personal files are not touched by the upgrade/rollback procedure.
All the packages (and their dependencies) you’ve installed extra are also upgraded/rolledback when you do a system upgrade.
The immutable part (again, only speaking about Silverblue, I don’t know about others) refers to the inability to make changes online (i.e. without rebooting), but you can eventually change whatever file you want. The way it works is you would make your changes in a copy of the current filesystem and at boot simply mount and use the copy. If something goes wrong, you just mount the original at next boot and you have rolled back.
You make a lot of good points, but I have to disagree on the “don’t let the user see or touch anything”. That’s very much not the way immutable distros behave (and I speak mostly about Fedora Silverblue here, I don’t have experience with other immutable systems): you can touch and change anything and often times you have mechanisms put in place by the distro developers to do exactly that. It’s just that the way you make changes is very different from classical distros, that’s all, but you can definitely customize and change whatever you want. I feel the comparison between immutable distros and Apple is really far off: Apple actively prevents users from making changes, while immutable Linux is the opposite – while there may be some technical limitations, the devs try to empower the user as much as possible.
Maybe I don’t understand the question, but what prevents you from adapting your Ansible playbooks to Fedora Silverblue? I assume for Debian at some point you have a “install packages” section which you should rewrite to use rpm-ostree or flatpak instead of apt-get; your dotfiles section should remain the same etc etc.
In the FTPD logs, do you see the initrd file being pulled? Could it be a mismatch between the kernel and initrd you’re serving?
Well, I don’t know how fair they play now, but for sure that wasn’t always the case.
So the Linux kernel is shit software now? Just because it’s not written in the newest programming language? Kind of a hot take.