81–90 of 96 posts
I'm presumably missing something here. Why does tmux et al not work? Remotely? Ie you're logged in locally and remotely to the same machine, log out locally which kills everything running remotely, but then why would you log in twice like that? And that being the case can systemd not just only close everything when your logins reach 0?
Personally me I fail to see any scenario where this is genuinely useful.
I think it's just popular to dislike systemd, some sort of echo chamber effect or something.
Earlier quoted context omitted.
Yes, systemd not being a monolith is a myth. You can forward logs to rsyslog or something, but you really can't disable systemd-journald. Technically you don't need to run systemd-boot, you can use grub or something else, but then bootctl and systemd kexec stop working. You don't need to run dbus, but if you don't several systemd features break, and it's not even documented what needs it. The list goes on and on. Als…
Systemd is literally not a monolith because it's not one big piece of software. It's a collection of software. For example, systemd-boot has basically nothing to do with systemd-init. Yes, some software is more tightly coupled than others, naturally. systemd-init and systemd-journald work tightly together because logging is a core requirement of any init system.
Earlier quoted context omitted.
> Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either forked off some other skeleton or having been made on it's own at some point. > And then companies wanted to do the right thing and apply some capabilities restriction…
> IMHO, any competent sysadmin, when is installing the system, would edit all those templates into the exact shape the system and the user needs That, IMHO, is the other 90% of the problem (to riff on the ninety-ninety rule). Every competent sysadmin has their own particular style & preferences & opinions about what the exact shape should be. And will go rewrite the world, according to some particular set of tastes,…
That being said, I do understand the need for some standardization. But you missed this part:
> doesn't mean that this systemd that is fit for them is also fit for everybody else.
They practically forced everybody to use it, and not just the service manager, everything else too: init, logger, network, login, dbus, etc.
Earlier quoted context omitted.
talking "outside happy path" in defense of systemd is wild. because that's it's Achilles heel. systemd is awfully documented (volume is not quality), things are still changing and haven't even caught up in functionality with any init hack. the only saving grace of systemd is that it almost makes it easier to use namespace and other sandbox (but only because those are newer and init systems also didn't have their solu…
How are hacky init scripts written in shellscript well documented? Can you point me to this documentation? When are the init systems going to implement the basic security measures systemd has?
Earlier quoted context omitted.
We can argue about which has better docs, but, to me, systems offers a uniformity of practices and a consistency of service offerings that was never the case before. Ever company used to have to make its own decisions about what logging solution to use. Each one had its own configuration paradigms! Every single daemon had some kind of bespoke /etc/init.d/ script that had its own rules and practices, having either for…
the systemd init system is complicated but fine. the problem with systemd is how much it wants your computer to itself. e.g. it can only run as PID 1, you aren't allowed to use control groups if you use systemd, it overwrites resolv.conf with its own address, it renames all your network adapters to lennart's preference (he calls them stable names but anyone who actually uses a computer will tell you they change more…
Earlier quoted context omitted.
This is not a genuine improvement: > One of the features of systemd that is most controversial is the option to kill user processes when the user logs out. That initially killed screen/tmux/nohup processes too. Killing processes that the user clearly did not want killed is a regression. Reading the rest of article it seems that its fixed but made things a lot more complicated than "unless you deliberately start thing…
I don't think it's a regression at all. It's been standard advice for decades that logout-login wipes user processes for updates, therefore you don't need to restart. I'd argue the opposite is true: linger is surprising, and I turn it off.
If that process is killed when I logout then that is a regression.
I do not understand what this has to do with udaptes.
This is why i dislike systemd. Things not working the way I expect means I have to do more work to figure something out.
I, for one, appreciate the honesty. I wish more systemd haters would admit this is why they dislike it. We could finally throw away the tired arguments that have been disproven in the past ten years
Here's one you cannot disprove: the Jian Tan XZ backdoor did not affect Linux distro that weren't using systemd.
I know, I know, it's got absolutely nothing to do with systemd.
We're talking about something insane like upstream OpenSSH being modified to add systemd logs "log compression" to freaking OpenSSH (yay security, makes perfect sense!).
So disprove this: not a single Linux systemd-less distro was affected by an attempt to place a worldwide backdoor on Linux systems exposing a SSH port.
P.S: I moved all my infra to VMs that are systemd-free and containers, by default, do not run systemd as PID 1 (they don't run it at all). It works flawlessly. I'll now move my hypervisors to FreeBSD+bhyve and I'll be, at long last, totally systemd-free again (I was using Linux before "systemd-I-compress-logs-so-I-make-you-modify-OpenSSH-to-add-liblzma-dependency" came on the scene with it's its Windows-style .INI files and these were much better days).
Earlier quoted context omitted.
Just the PID 1 manager is multiple times larger in LoC than any alternative. There is no metric in which systemd is more lightweight that I could find.
I'm not sure this is true in practice, if we're counting init scripts themselves. Which we should, because init scripts are code and they often re-implement standard systemd features. Usually in wonky, broken ways.