kwozyman

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.

Este momentul să-ți învingi teama :)

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.

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.

I really can't comment on the legality aspect, but again, I would assume they asked real law experts before the move. On the morality of it, I can put my 2 cents forward. The way I understand it, companies buy Red Hat for the support, testing and the guarantee that what they buy is stable. And I think that's the product, not the source code. In simpler terms, RH is not selling Apache (for example), they are selling this specific version of Apache, compiled in this specific way, running on this specific version of the kernel etc etc. If someone else comes and sells the exact same thing, but without putting the work towards testing, bugfixing, backporting and whatever else RH does is what we call in the industry a "dick move" :) In the end, why does Oracle/Rocky/Alma want to sell the same exact thing when they could build their own? I think it's because it's extremely expensive to do all that and they just want to do the easy part which is providing support.

And as I was saying in a reply towards someone else: I think all of this is targeting Oracle, not some startup with no customers. But Oracle knows when to shut up, we didn't hear a pip from them in all of this.

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.