Live data from Hacker News

Linux greybeards release beta of systemd-free Debian fork

theregister.co.uk

1–10 of 189 posts

Re: Linux greybeards release beta of systemd-free Debian fork

#2
Init should be just this: http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

Re: Linux greybeards release beta of systemd-free Debian fork

#5
post #2

Init should be just this: http://git.suckless.org/sinit/tree/sinit.c , systemd incorparates too much funcitonality IMO, I cant get used to it. Well, but its a free world, I have even written a Go init, some guy did Rust based, and upstart is still being used by Ubuntu 14.04, I like choices, and happy to see this alternative as well.

1. If the only thing you needed from init was to reap reparented zombie processes and manage to not die, why have init at all? Why not tell the kernel to skip reparenting processes (and just reap them internally if their parent is dead) and not treat pid 1 as special, allowing it to exit? That's less userspace code and less kernel code.

2. Speaking of kernel code, have you looked at how much stuff is going on in the kernel? Why does pid 1 get this much scrutiny, but the kernel, which definitely can't die, gets a free pass? On my system there are 77 kernel threads. Seventy-seven! What are they all doing??

And there are plenty of alternative kernels you can use. Multiple ones even have Linux binary compatibility.

3. Is the argument for suckless init the same as that for EWONTFIX init (on which it is based)? If so, would a fork of systemd that split it into two processes, PID 1 that reaps reparented zombies and tells PID 2 about it (over a one-way pipe, so PID 1 has no increased attack surface), be an acceptable option?

Re: Linux greybeards release beta of systemd-free Debian fork

#7
post #4
post #3

Nice, but from the users' standpoint it would've been better if they had worked with Debian rather than rolling out their own distro.

The problem sort of is that (the rest of) Debian wouldn't work with them on this.

You are quite right, as the overall Debian's stance on systemd was far from praiseworthy. They allowed themselves to be pushed around too far by the "end-user" (desktop-users) mentality of the gnome and few such other upstreams.

This is a very good news. Indeed it would have better if the Debian had been a little bit more flexible and sensible on this issue.

Congrats Devuan folks! My heartfelt thanks too.

Edit: added my thanks and clarification for desktop-user.

Re: Linux greybeards release beta of systemd-free Debian fork

#8

Counterpoint from a former systemd skeptic who now likes it: http://changelog.complete.org/archives/9655-count-me-as-a-sy...

It's a reasonable counterpoint, but limited to the part of systemd that manages starting and stopping services.

It also takes over virtual terminals, syslog services, login management, network interface configuration, dhcp, system time, udev device management, containers (machined, dbus, cgroups).

That, to me, is where more of the concern lies.

Re: Linux greybeards release beta of systemd-free Debian fork

#9
post #3

Nice, but from the users' standpoint it would've been better if they had worked with Debian rather than rolling out their own distro.

Do users care though? I don't. I select a Linux distro based on how popular it is because frankly they are all pretty excellent these days.

I go for popular distros because it's more likely that bugs are found and community help is available.

I also do very little customization. If the default window system is Gnome, that's what I use. If it's KDE or something else, that's fine too. Again, they are all good enough.

I use Linux, I'm a huge fan of it, but I'm not dogmatic. Using Linux is a way for me to get work done, but it isn't the goal itself.

Re: Linux greybeards release beta of systemd-free Debian fork

#10
I like systemd from the perspective of a service-writer/maintainer, the service files are nice and simple and don't have the repeated boilerplate of old init scripts.

However I still dislike its monolithic nature, its folding in of journaling and udev, and all the rest of the creep.

Post reply on HN