Yes, I use Mint at work, and have 2 additional monitors plugged into my laptop, but don't know about 3 monitors into a desktop system. Don't see why it wouldn't work.

On the desktop I use Linux Mint (MATE desktop), and it's great. No snaps.

On servers, I run Ubuntu. I purge snapd (there are actually no snaps installed on a bare Ubuntu server install, unlike their desktop offering..!) and lately, I purge cloud-init (too noisy). This will run well for many years. Ubuntu is really good at servers at this point.

Indeed! Looking at you, ASUS TUF F17... No PageUp/PageDown keys, while there are even 2 empty spaces on the top-left&right of the arrow keys..!

Luckily I mostly use an external keyboard.

Be kind, remember, their kids' school is still on Windows...

SRPM spec files are good examples of "dependent" software, there is no reason for them to exist, other than the sources they govern. The GPL specifies that these must also be GPL licensed.

They can't "close their sources", because it's all built on GPL'd sources. What they are trying to do is explicitly against the GPL.

What I'm afraid of, is that they are ready to test the GPL in court, and keep their marbles, so to speak.

Everyone is using Postfix on Debian, are you serious??

I wasn't aware that CentOS was struggling at that point. All the more nefarious of RedHat to take them over, inducing ScienticLinux to buy into the project and abandoning their own clone, and then to change course in a so obvious undesirable direction for all current users...

That's not how CentOS ended... It got "bought" by Redhat, and I'm sure a number of the people who were working on it are quite comfortable because of it.

I tried this on one of my systems, and indeed, it dropped me to a root busybox shell in initrd. Since my grub is not password protected, this kind of access (and worse) was already trivial on that system. But, LUKS is still encrypted.

Nowadays grub supports what I call total encryption. (It has support for a LUKS encrypted partition, no need for a separate unencrypted /boot directory.) Now a similar vulnerability was present on one of my total-encrypted systems, but in this case it dropped me to a grub rescue environment.

I would be interested to hear what the possibilities are for evil maid attacts in the grub rescue shell scenario, but I don't believe it's possible, because the kernel and the initrd are still encrypted.

It has been said, but the vulnerability is not in cryptsetup, but in initramfs.

So you have a JTAG or EEPROM programmer -- would you know how to fix it if the efivars had just gotten wiped?? I would love to have access to resources and instructions on what needs to happen..!

Number 4 (>/dev/sda) doesn't really do anything, as /dev/sda is a block device. On a regular file it would get truncated to length zero.

THIS! Can this be modded up?? (On the other hand, systems are getting hacked, so just using bash works...)
Also, it needs reiterating that all those Androids and routers commonly don't have any bash on board.

I think you got that backwards. Canonical started using systemd because Debian picked it. Also, Canonical doesn't do Gnome3 shell on their main offering, so how do you see any strongarming in this decision?