I think we can fix that! You're right that some things aren't amenable to a literal "Ctrl Z"---but I think Sacha's underlying point is spot on.
Many "irrevocable" actions could, with better design, be made made safe.
For example, Sacha's second story was where he accidentally deleted a production server instance. With a typical VPS, his configuration might be irrevocably gone, and he has to manually recreate everything under time pressure. But if next time he uses, for example, a Docker host, then such an error will be as simple to fix as deploying the same image again.
Another good example is Git. With most version control systems, "rebasing" is either unsupported or discouraged, and if you mess up, you can lose data permanently. Git's design is undo-friendly from the ground up: any commit hash encodes the exact state of your repo, including history all the way back to your first commit. So even if you rebase or force push and make a terrible mistake, you can nearly always use `git reflog` and get things back just as they were. Also, unlike some lesser VCSs, Git is transactional---so if you say "git pull" and then trip over the power cord while it's updating, your repo will still be in a good state afterward.
Technology that has a simple, explicit concept of state--such as Docker images or Git commits--is fundamentally nicer to work with. You can explore and experiment, and if things go wrong, you can roll back with confidence.
Well this is the thing, there are layers of software to recover (or "undo") from silly mistakes. Even with the phpMyAdmin example, he had backups. I don't think there's a lack of undo utilities, it's more a case that tools to undo sysadmin mistakes are often another layer of software lower down in the stack.
The docker example is a great one though. Lately I've been doing a lot of work with FreeBSD and using Jails (which, if you weren't already aware, are OS level containers for FreeBSD). And using ZFS to snapshot the Jail. I've worked with virtual machines before, but I just love the ability to take snapshots of an environment before making potentially dangerous changes.
It's probably also worth noting that some of authors examples also demonstrate why you should be using root access for every day operations.
The thing is, I do relate to the point he's making, but it also feels a little like he's blaming application developers for his own mistakes (using root access for general usage, not backing up config files nor snapshots, etc). So while I think it's great that tools are getting better and easier to use, we also need to be careful not to depend on these things to save us from our own laziness. Because that level of complacency will lead to more mistakes than if the tools required our greater concentration (as the adage goes: "the more idiot proof you make something, the bigger the idiot that comes along")
I think we can fix that! You're right that some things aren't amenable to a literal "Ctrl Z"---but I think Sacha's underlying point is spot on.
Many "irrevocable" actions could, with better design, be made made safe.
For example, Sacha's second story was where he accidentally deleted a production server instance. With a typical VPS, his configuration might be irrevocably gone, and he has to manually recreate everything under time pressure. But if next time he uses, for example, a Docker host, then such an error will be as simple to fix as deploying the same image again.
Another good example is Git. With most version control systems, "rebasing" is either unsupported or discouraged, and if you mess up, you can lose data permanently. Git's design is undo-friendly from the ground up: any commit hash encodes the exact state of your repo, including history all the way back to your first commit. So even if you rebase or force push and make a terrible mistake, you can nearly always use `git reflog` and get things back just as they were. Also, unlike some lesser VCSs, Git is transactional---so if you say "git pull" and then trip over the power cord while it's updating, your repo will still be in a good state afterward.
Technology that has a simple, explicit concept of state--such as Docker images or Git commits--is fundamentally nicer to work with. You can explore and experiment, and if things go wrong, you can roll back with confidence.