kwozyman

The top level management: CEO, CFO, CTO etc. Basically, the big bosses.

What mistakes? They got rich with No Mans Sky.

I would say polenta (mămăligă in Romanian) is the easiest to prepare - https://www.chefspencil.com/traditional-romanian-polenta-mamaliga/

It's not a meal by itself, but it's delicious with telemea cheese (you won't find any outside of Romania, can probably be substituted by feta cheese best), sour cream and a fried egg on top. Add a smoked sausage and you got a feast :)

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.

Although from a purely scientific stand point you are correct and there is no truly random number generator, I would argue that simulating a dice in a video game can be considered random for all intents and purposes.

Well, I don't know how fair they play now, but for sure that wasn't always the case.

Let's not forget Oracle! While Rocky bit the bullet with this poorly written announcement, I believe Red Hat's target was in fact Oracle, not some 20 employees startup with no customers.