> When we really should have been formally addressing problems from first principles. Because if our OS can't recover gracefully when the disk fills up, then we

> When we really should have been formally addressing problems from first principles. Because if our OS can't recover gracefully when the disk fills up, then we don't really have anything. And so many OSs (including our desktops) panic when the disk fills up, that we don't really have anything. At a low enough level, all of the tools we rely upon are trash. Unfortunately, the OS can't really "recover" most of the time because it is being constantly lied to by several(!!!) layers of uncooperative hardware/firmware. It's zebras all the way down: https://www.youtube.com/watch?v=fE2KDzZaxvE https://www.youtube.com/watch?v=fE2KDzZaxvE > In this case, by letting programs wait until the user has cleared off disk space If your system is really in a no-disk-space-left state you might not be able to login to fix it: https://unix.stackexchange.com/questions/165427/cant-login-due-disk-space-exhaustion https://unix.stackexchange.com/questions/165427/cant-login-d... And even assuming you can login, sometimes you can't delete files either; you need to free space in another way before being able to delete files. https://serverfault.com/questions/478733/rm-can-not-remove-xxx-no-space-left-on-device-on-btrfs https://serverfault.com/questions/478733/rm-can-not-remove-x... Filesystems and persistence are hard.