Hacker News Board Hacker News, browsed like a classic message board
Live data from Hacker News

Devuan – Debian Without Systemd

devuan.org

Post reply on HN
Print view View original

211–220 of 221 posts

Re: Devuan – Debian Without Systemd

#211

Post by ndsipa_pomu »

Izkata wrote: post #210
ndsipa_pomu wrote: post #205

Earlier quoted context omitted.

Is that "logout" referring to a user explicitly logging out from a desktop environment? I can't imagine it would apply to a closed SSH session, or at least it wouldn't make sense if it did.

According to the Bugzilla case it links to ( https://bugs.debian.org/cgi-bin/bugreport.cgi?bug=825394 ): > It is now indeed the case that any background processes that were still running are killed automatically when the user logs out of a session, whether it was a desktop session, a VT session, or when you SSHed into a machine. And the reddit comments include a link to a tmux issue where the suggested solution is fo…

I had no idea about that. Does seem a bizarre choice for systemd to do that.

I admin a whole bunch of headless servers and so am often SSHing to them and running long running jobs. Some of them run VNC sessions, and I certainly wouldn't want a VNC session to kill of other SSH sessions by the same user. At least with VNC, I almost never "logout" - they're often autostarted (by systemd) and just get killed when the machine gets rebooted.

Re: Devuan – Debian Without Systemd

#212

Post by 112233 »

propmaster wrote: post #77

In my job, I often release Linux services integrated with systemd and I like it more than the old init system. My problems with systemd is the bloatware, not init related, that comes with it in modern Linux distributions. In my perception systemd people doesn't respect the freedom of choice of the users, the right to simply switch off features they find useless, annoying or simply they don't want in their workflow fo…

But why is there no such pushback agains linux kernel? What makes that monolith you cannot customize different enough from systemd? What if I don't want to use in-kernel usb stack, or audit, or key management, or LSM modules, or ELF binfmt support, or filesystems — you are forced by the distro to use all those features. Yet with systemd it's somehow different. I'm genuinely curious

Re: Devuan – Debian Without Systemd

#213

Post by Izkata »

bandrami wrote: post #46
IshKebab wrote: post #44

Earlier quoted context omitted.

I remember the time before systemd and there wasn't any innovation happening - everyone was content with hacky bash scripts.

Legible, discoverable, debuggable. They listed the commands the computer needed to run, in the order it needed to run them, to get the system running. It was absolutely beautiful. And then LSB came along and broke it, and as a result of that systemd now manages my home directory and cron tables. Shame, really.

> Legible, discoverable, debuggable.

When I first tried linux on the late 2000s, this was a major selling point. Something not working right? Oh neat I can actually investigate and fix or replace it instead of just having to live with it. Nowadays I'm not sure I'd see the advantage as a new user and may not bother even trying it out.

I could actually see systemd killing the whole year-of-linux-on-the-desktop thing not even because it's worse in any way, but because as time goes on the major distinguishing factors from other OSes are disappearing, so there's no longer reason for people to try it out.

Re: Devuan – Debian Without Systemd

#214

Post by hiciu »

blueflow wrote: post #162
hiciu wrote: post #159

Earlier quoted context omitted.

Could you please expand bit more about those processes that systemd spawns without units? Cgroups in Linux kernel, and systemd-cgls tool should let you trace every process to a source

ibus and goa both run under dbus.service. I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.

OK so those processes are launched not by systemd, but by dbus itself.

There's probably a /usr/share/dbus-1/services/org.freedesktop.IBus.service file in your system and if dbus sees something that tries to talk to IBus, and IBus is not running yet, dbus will launch it for you as directed in that file. In it's own namespace unless directed otherwise.

There's an optional integration between dbus and systemd, look for SystemdService in man dbus-daemon. IBus does not set it. Perhaps it should. I don't know.

> I ran into this problem because ibus runs later than setxkbmap and undoes the keyboard settings.

that must've been pain to debug :). I can see on my system that there's a systemd user service that I could launch with `systemctl --user start org.freedesktop.IBus.session.generic.service`, maybe that would work better than on-demand via dbus in your case.

Re: Devuan – Debian Without Systemd

#215

Post by bandrami »

belorn wrote: post #192
bandrami wrote: post #161

Earlier quoted context omitted.

I still would love somebody to explain to me what's "dodgy" about a shell script that runs the commands you want run...

I mentioned it in the comment above. Commands that you run in a shell script do not always block execution until the underlying resources is fully available. If we take the network as an example, the script to open a vpn tunnel and providing the tap0 device may not be available for the next command to use just because you first run the network script, then start the vpn daemon, and then start the next daemon. What pe…

I'm curious about this world people seem to have lived in where inetd didn't exist.

Re: Devuan – Debian Without Systemd

#216

Post by teddyh »

direwolf20 wrote: post #187
teddyh wrote: post #127

Earlier quoted context omitted.

Systemd seemd to be moving away from D-Bus and adopting varlink instead.

Which is like, D-Bus from Temu, if Temu was systemd. Is there anything they haven't NIH'd?

Varlink is everything that the usual systemd detractors should want; no binary formats, simpler mechanisms, based on stdout/stdin of processes.

Also, systemd did not create varlink, nor did they create D-Bus. They simply adopted them as the most suitable and established methods for IPC at the time.

Re: Devuan – Debian Without Systemd

#217

Post by teddyh »

ralferoo wrote: post #175
teddyh wrote: post #125

Earlier quoted context omitted.

> The journal grows massively and is unbounded by default. 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. > It took me about 30 minutes of googling Just read the manual. Start with systemd.directives(7) and search for what you want, which will direct you to the correct manual…

> 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…

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

Re: Devuan – Debian Without Systemd

#218

Post by ralferoo »

teddyh wrote: post #217
ralferoo wrote: post #175

Earlier quoted context omitted.

> 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…

> 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.…

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.

Re: Devuan – Debian Without Systemd

#219

Post by zx8080 »

112233 wrote: post #212
propmaster wrote: post #77

In my job, I often release Linux services integrated with systemd and I like it more than the old init system. My problems with systemd is the bloatware, not init related, that comes with it in modern Linux distributions. In my perception systemd people doesn't respect the freedom of choice of the users, the right to simply switch off features they find useless, annoying or simply they don't want in their workflow fo…

But why is there no such pushback agains linux kernel? What makes that monolith you cannot customize different enough from systemd? What if I don't want to use in-kernel usb stack, or audit, or key management, or LSM modules, or ELF binfmt support, or filesystems — you are forced by the distro to use all those features. Yet with systemd it's somehow different. I'm genuinely curious

For kernel, anyone is able to change flags and recompile and run it in a few mins. It is possible and well documented.

It's very much not the same situation for systemd.

Re: Devuan – Debian Without Systemd

#220

Post by 112233 »

zx8080 wrote: post #219
112233 wrote: post #212

Earlier quoted context omitted.

But why is there no such pushback agains linux kernel? What makes that monolith you cannot customize different enough from systemd? What if I don't want to use in-kernel usb stack, or audit, or key management, or LSM modules, or ELF binfmt support, or filesystems — you are forced by the distro to use all those features. Yet with systemd it's somehow different. I'm genuinely curious

For kernel, anyone is able to change flags and recompile and run it in a few mins. It is possible and well documented. It's very much not the same situation for systemd.

So your point is distros provide dedicated tooling for simple recompiling of kernel (that is different from other distro packages), but do not have dedicated tooling for systemd? Fair point, but does not address the kernel being orders of magnitude bigger monolith than systemd.

Say you disabled LSM, rebuilt, now all stuff that requires Selinux does not work. Now what?

Post reply on HN