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

201–210 of 221 posts

Re: Devuan – Debian Without Systemd

#201

Post by bandrami »

t43562 wrote: post #193
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...

e.g. Starting something in the background and having to stick sleep statements into the script to wait till it is ready to receive requests on whatever port it uses. The sleeps are fine on one machine and on another they aren't enough. Stashing the PID somewhere and writing code to use the PID to work out if the process is still running and hasn't crashed so you can report a status on it. It's just a waste of one's o…

Was I the only person that used inetd to bring up their services on demand? I could have sworn it was popular at the time.

Re: Devuan – Debian Without Systemd

#202

Post by bandrami »

bandrami wrote: post #200
direwolf20 wrote: post #198

Earlier quoted context omitted.

Device numbers are dynamically allocated. The main handle is the name. Network interfaces don't go in /dev anyway and are not files

This was almost 30 years ago so my memory is fading, but pre-devfs when they were just in the /proc tree you could tell the kernel to bring them up in a given order and so assign the name you wanted to a given card.

(Sorry, pre-sysfs. Though chronologically also pre-devfs)

Re: Devuan – Debian Without Systemd

#203

Post by cbolton »

teddyh wrote: post #154
cbolton wrote: post #94

Earlier quoted context omitted.

> inability to express "just shut the fucking system down, you won't have power in 5 minutes" for servers connected to UPS. What about "systemctl --force --force poweroff" ?

With two “--force” options, that is essentially equivalent to “echo o > /proc/sysrq-trigger”, isn’t it? I would think that one “--force” would have the actually desired effect.

Yes you're right.

Re: Devuan – Debian Without Systemd

#204

Post by IshKebab »

phendrenad2 wrote: post #6

I like Devuan because it matches the Linux I learned - people who learned with a Systemd distro might not like it as much.

Good for you, but I wish this attitude wasn't weaponised so frequently to prevent progress by people who actually want progress.

Re: Devuan – Debian Without Systemd

#205

Post by ndsipa_pomu »

Izkata wrote: post #195
mid-kid wrote: post #164

Earlier quoted context omitted.

The problem is mostly that programs started depending on aspects of systemd that are both very complex, and difficult/impossible to implement without ending up with systemd. Systemd's components don't play well with established standards (sometimes not running standalone at all), which contributes to the feeling of having to buy into the whole ecosystem just to use a small part of it, just for that one bit of a certa…

> Systemd's components don't play well with established standards Here's my favorite (quickly searched for, this links to other threads): https://www.reddit.com/r/programming/comments/4ldewx/systemd... As far as I know systemd never changed the default, people only stopped complaining because distros now override it.

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.

Re: Devuan – Debian Without Systemd

#206

Post by benterix »

Hikikomori wrote: post #194
benterix wrote: post #140

Earlier quoted context omitted.

OK you're missing the historical context here. To make this story extremely short, the author of Systemd was already known for another project that was causing problems to Linux users but was shipped early. And when Systemd was released, it has several issues, too, so some distros like Debian withheld the switch. But at some point the folks at Red Hat decided to tie Systemd to the login mechanism for Gnome. I don't b…

At the time desktop Linux projects like consolekit were an unmaintained mess, it needed replacements. Systemd also supported cgroups V2 and people really wanted to use that. No conspiracy or underhandedness required.

I don't think anyone would ever object against systemd as a project, it would make as much sense as objecting against, say, GNU Chess. All software has bugs, and they're gradually worked out. But the way it was introduced that made many people upset.

Re: Devuan – Debian Without Systemd

#207

Post by Hikikomori »

benterix wrote: post #206
Hikikomori wrote: post #194

Earlier quoted context omitted.

At the time desktop Linux projects like consolekit were an unmaintained mess, it needed replacements. Systemd also supported cgroups V2 and people really wanted to use that. No conspiracy or underhandedness required.

I don't think anyone would ever object against systemd as a project, it would make as much sense as objecting against, say, GNU Chess. All software has bugs, and they're gradually worked out. But the way it was introduced that made many people upset.

The way it was introduced was that many people could see the value in cgroups V2 and being able to drop unmaintained projects. Maintainers of distros and projects sometimes did this against some users wants, but in my opinion there was just lots of baseless complaining without creating an alternative.

Re: Devuan – Debian Without Systemd

#208

Post by Hikikomori »

blell wrote: post #47
embedding-shape wrote: post #26

Earlier quoted context omitted.

How is it someone's else's fault for that systemd has dependencies or that others depend on systemd? If I use and like Firefox, and others depend on Firefox, or Firefox depend on others, then it's Firefox fault for you choosing Firefox? I really don't understand the argument you're trying to make. You had choices before systemd, and you still have choices even though systemd is widespread, what's the problem? It isn'…

Red Hat created hard dependencies on systemd in all of the popular software they develop to ensure its adoption.

Did anything else support cgroups V2?

Re: Devuan – Debian Without Systemd

#209

Post by direwolf20 »

bandrami wrote: post #200
direwolf20 wrote: post #198

Earlier quoted context omitted.

Device numbers are dynamically allocated. The main handle is the name. Network interfaces don't go in /dev anyway and are not files

This was almost 30 years ago so my memory is fading, but pre-devfs when they were just in the /proc tree you could tell the kernel to bring them up in a given order and so assign the name you wanted to a given card.

Network interfaces always had names sequentially assigned by the kernel. systemd overrides them based on PCIe bus location, which changes when you install new hardware. Lennart insists that PCIe bus locations don't change when you install hardware, even though this is obviously wrong as proven by real–world evidence.

Re: Devuan – Debian Without Systemd

#210

Post by Izkata »

ndsipa_pomu wrote: post #205
Izkata wrote: post #195

Earlier quoted context omitted.

> Systemd's components don't play well with established standards Here's my favorite (quickly searched for, this links to other threads): https://www.reddit.com/r/programming/comments/4ldewx/systemd... As far as I know systemd never changed the default, people only stopped complaining because distros now override it.

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 for tmux to add systemd as a dependency (https://github.com/tmux/tmux/issues/428). Includes some back-and-forth about how all sorts of software would have to change in similar ways to accommodate systemd, instead of systemd just playing nicely with decades of established practice.

Post reply on HN