[ralferoo]

> Wrong. By default, the journals aren’t even saved to disk. And if you do configure them to be saved to disk, they are limited by default to 10% of the file system size, and at the most 4GiB.

I mean this probably depends on your distro. On Debian, it very much is saved to disk by default. And plenty of my 5GB VMs have in the past filled to 100% such that everything fails with write errors because the log files have consumed about 3GB.

> Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual page for that setting.

Again, fine if you know of the existence of that man page (I didn't) and know what option you're even looking for. Systemd always calls it journal as far as I knew, and doesn't use the syslog, so I didn't even think to google for syslog to change what I wanted.

> The world is changing. Mounts aren’t static anymore; you must treat a mount just as a running service

Thing is, it's all very well to say that, but 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 "hey, we know you just asked for this to be unmounted, but we might just randomly remount it whenever because whatever you are doing is unimportant".

And this points to the root of the issue - UNIX has been following the UNIX way for over 3 decades. Suddenly, everything is changing, without any indication of things being different until stuff just doesn't work. This is exactly why people don't like systemd.

> > I had to learn the new systemd way of doing it. > This, I strongly suspect, is your real problem.

Absolutely.

I've got a zillion other things to do, without spending hours every time I upgrade to discover all the new ways systemd has come up with to ruin my life.

When I am forced to interact with systemd, it always slows me down unnecessarily, because the only reason I'm looking at it at all is because it's because something has changed and it's causing me pain.

[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”.