SpaceCadet

I don't think "substitute user" is the original meaning, and it's more like a retroactively applied acronym.

Looking at various old Unix manpages, it said various things in the past. In the HP-UX documentation it even lists three different variants in the same man page: "switch user", "set user" and "superuser".

"superuser" is probably the original meaning, because that's what it says in the Unix Manual 1st edition (1971): http://man.cat-v.org/unix-1st/1/su

NAME	su -- become privileged user
SYNOPSIS	su password
DESCRIPTION	su allows one to become the super--user, who has all sortsof marvelous powers. In order for su to do its magic, the user must pass as an argument a password. If the passwordis correct, su will execute the shell with the UID set to that of the super--user. To restore normal UID privileges,type an end--of--file to the super--user shell

I love Unix archeology :)

I'm blaming it for making it a pain in the ass to debug dependency problems and for having the confusing, non-intuitive, overly verbose and redundant syntax that probably caused the problem in the first place.

Like, who the hell can memorize all the subtle differences in behavior between After=, Requires=, Wants=, Requisite=, BindsTo=, PartOf=, UpHolds= and then all their "reverse" equivalents?

Everybody gangsta until A start job is running for ... (10s / 1min 30s)

Thanks for summarizing my feelings on systemd in a less inflammatory way than if I had written it myself.

I've found that most distributions have implemented it properly and for the most part it works quite well and stays out of my way, it's only when for some reason you have to dive into the minutiae of a unit file and getting into all the dependencies and stuff that it gets annoying quickly.

As a general rule, you should always keep in mind that you're not really looking for a backup solution but rather a restore solution. So think about what you would like to be able to restore, and how you would accomplish that.

For my own use for example, I see very little value in backing up docker containers itself. They're supposed to be ephemeral and easily recreated with build scripts, so I don't use docker save or anything, I just make sure that the build code is safely tucked away in a git repository, which itself is backed up of course. In fact I have a weekly job that tears down and rebuilds all my containers, so my build code is tested and my containers are always up-to-date.

The actual data is in the volumes, so it just lives on a filesystem somewhere. I make sure to have a filesystem backup of that. For data that's in use and which may give inconsistency issues, there are several solutions:

• docker stop your containers, create simple filesystem backup, docker start your containers.
• Do an LVM level snapshot of the filesystem where your volumes live, and back up the snapshot.
• The same but with a btrfs snapshot (I have no experience with this, all my servers just use ext4)
• If it's something like a database, you can often export with database specific tools that ensure consistency (e.g. pg_dump, mongodump, mysqldump, ... ), and then backup the resulting dump file.
• Most virtualization software have functionality that lets you to take snapshots of whole virtual disk images

As for the OS itself, I guess it depends on how much configuration and tweaking you have done to it and how easy it would be to recreate the whole thing. In case of a complete disaster, I intend to just spin up a new VM, reinstall docker, restore my volumes and then build and spin up my containers. Nevertheless, I still do a full filesystem backup of / and /home as well. I don't intend to use this to recover from a complete disaster, but it can be useful to recover specific files from accidental file deletions.

Pretty much yeah

SSDs are way more reliable than spinning disks

That's true, with one caveat: if an SSD fails, it's usually catastrophically and without warning. HDDs usually give some warning signs before they fail completely (bad sectors, read/write errors, strange noises).

The pain with Fedora is the short support cycle, so you have to reinstall/upgrade it every year.

That and dnf/yum stinks.

It just means that whatever is in the video or post pissed off the Russians enough that they brigade it with downvotes.

In other words, it's good news.

That doesn't mean it won't ever happen again. I just have less trust in an IAP model. It's inherently more fragile because it does a license status check with Google every time you launch it, whereas a one time purchased app doesn't need to ask permission.

Honestly I would prefer to be able to buy a separate "Pro" version from the Play Store, without an in-app purchase. There have been issued in the past where in-app purchases didn't get recognized or when ads suddenly started appearing for people who bought the ad removal option.

That probably has to do with the software. It's a wireless keyboard, so it doesn't support VIA and uses its own proprietary software instead, which probably won't work in Linux or MacOS.