[teddyh]

> On Debian, it very much is saved to disk by default.

Only relatively modern Debian versions. And even then, blame Debian, not systemd.

> It's downright dangerous to change the expectations that have held true for 30+ years without even a warning somewhere - e.g. running unmount popping warning

Firstly, umount “popping a warning” would break so many things, and then you really would have something to complain about. And if we really are talking about 30+ years ago, things have changed a lot since then, too. You used to stop and uninstall a service by finding its PID by running ”ps”, killing its process, and ”rm”-ing its files (and editing /etc/rc.local to remove the service’s startup line) But even before systemd, you would not dream of doing that anymore; you would run “invoke-rc.d thing stop”, or at least ”/etc/init.d/thing stop”, and use your package system to uninstall it. Those are new things since 30+ years ago.

> something has changed and it's causing me pain.

Consider quitting the technology business.

[ralferoo]

No, I'll blame systemd. I've been using Debian for 25 years and we've only had systemd forced on us in the last maybe 5. OK, yeah, you're right. I'll blame Debian for forcing systemd on us, which is exactly the problem that Devuan is fixing.

Actually, I've been using SunOS and Solaris even longer than Debian. Putting scripts in /etc/init.d / /etc/rc.d isn't "new". It's been standard for at least 30 years. Actually, maybe making /etc/rc.d symlink to the /etc/init.d is early 2000s, I can't remember, but it's certainly not new.

But also, I've written many startup scripts in my time. And no, I absolutely wouldn't find its PID using ps and killing it. In my startup script, I'd save $! in a file, standardised in /var/lock for at least 20 years, and kill that.

And no, I wouldn't manually edit /etc/rc.local - because for decades it's run everything in /etc/rc*.d specifically to prevent the need to manually edit /etc/rc.local. None of this is new.

> umount “popping a warning” would break so many things

I mean, would it really? They've modified mount to pop up a warning to tell you that you manually changed /etc/fstab and what extra steps you need to do to placate systemd just to be able to mount your filesystem. Why can't unmount also do the same, e.g. gated on being run from an interactive tty? Having filesystems randomly mount themselves after you have deliberately unmounted them is actually dangerous.

> Consider quitting the technology business.

How about you consider having some manners?

Somebody responding to a question about why people don't like X with an explanation of how exactly X has changed their workflow for the worse doesn't mean that they should leave the technology business.

I'm sorry for you that your self-worth is so tied up in systemd that you can't bear to hear any criticism of it.

[teddyh]

> Why can't unmount also do the same, e.g. gated on being run from an interactive tty?

Well, maybe. But what constitutes an “interactive tty”? Stdout or stdin? I’ve had problems where most things, including tty(1), tests stdin for TTY-ness, but if I’ve redirected stdout to a file I get all interactive questions to a file, and a pausing system waiting for input for a question not visible on screen.

> Having filesystems randomly mount themselves after you have deliberately unmounted them is actually dangerous.

The automounter, present in SunOS with NIS and NFS for 30 years, also does that, no?

> How about you consider having some manners?

Technology is constantly changing. Since your complaint was simply that technology has changed and is forcing you to learn something new, I think that’s an appropriate response. If you have more detailed complaints, those might be deserving of more respectful responses, but a “my 30 year old UNIX™ is changing and forcing me to learn new things, oh noes!” gets, and deserves, nothing better than a “git gud”.