Live data from Hacker News

Linux greybeards release beta of systemd-free Debian fork

theregister.co.uk

71–80 of 189 posts

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

#71

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…

I am with you. I think it was long time for sysvinit scrips to die. But that doesn't mean that it should be replaced by systemd.

Systemd, like a lot of things coming out of redhat these days (firewalld), feels like bloatware to me.

Systemd, Firewalld, D-Bus, etc.. have no place in a server IMHO.

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

#72
post #63

Earlier quoted context omitted.

Really? How is it complex conceptually? The main concepts you really need to understand is that of units, and for that I found a very well written piece by Digital Ocean on the topic: https://www.digitalocean.com/community/tutorials/understandi... Aside from that, there are a number of services and utilities, but I'm not sure how they are conceptually harder to understand that any other similar program or utility on…

The core of systemd revolves around units, but the "systemd ecosystem" has expanded to logging (journalctl), bus management, a new way to set the hostname (hostnamectl), a login manager, fstab parsing and disk management, a new session/login management framework, networking (systemd-netword, or is it netctl now, or do people use NetworkManager? I'm on Arch and ended up choosing netctl but I still don't understand all…

Yeah, it can make my head spin too sometimes. But I just don't think that rapid change makes things more inherently complex for a system per se, it just means folks like us have to do more reading (and more grousing, I quite enjoy doing that on occasion, I must admit).

Oh boy, I've just realised - I'm growing older! Eep.

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

#73
Everybody mentions the Unix philosophy and that is a very valid point, but I would like to mention the freedom philosophy that open-source/Linux gives (or used to).

These guys who wanted systemd muscled their way in to get this software into the Debian system. They also adopted an "all or nothing" approach, depriving the greater community of something bigger than "do 1 thing and do it well", which is "freedom to do as you wish and choose".

Debian wouldn't have split had they maintained they made systemd opt-in or Poettering and co. maintained their own Debian-systemd version. That didn't gel well with Redhats version of what Open Source is, and so many were deprived of their freedom to NOT CHOOSE systemd BUT still use Debian.

For all the talk of how good/bad systemd is, the proponents for systemd should remember how they deprived others with the freedom to choose, no matter how "ignorant" or "backwards" the detractors are (or how "shit" sysvinit is).

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

#74
post #57

I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. I love bash, I love nitpicking about how to use bash along with the other bash nazis in #bash@freenode. But I would never put myself through sysvinit again. I thoroughly enjoy using distros like CentOS 7, Fedora 23, RHEL7. They're a joy to manage and work with, in part thanks to Systemd. I never want to debug, troubleshoot, or even look a…

> sysvinit-script OpenRC fixes a lot of that, without adding the giant pile of dependencies that systemd imposes. As someone who is already comfortable with bash, OpenRC scripts should be easy. > I can't believe anyone would like to keep using sysvinit-scripts or RC-scripts. There are more options than sticking with Debian's ancient scripts. The larger problem is that init is only a tiny part of systemd. Systemd's ma…

"Systemd's mandatory link-time dependencies and tightly-coupled (monolithic) features are trying to be an entire wrapper around important parts of the kernel."

What parts of the kernel are you referring to? Genuinely interested...

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

#75

One giant program to rule them all was never the Unix way. System's monolithic architecture will be its downfall. Rather than stabilize I predict that systemd will get more and more complicated and eventualy fall due to unwieldy maintenance problems at which point someone will come up with a better more modular system.

systemd has neither a monolithic architecture, nor does the systemd process itself do anything other than the following: "[systemd] provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control…

Systemd is the very definition of monolithic.

> It comes with a set of utilities that do a lot of things

"monolithic" vs "modular" has isn't about the number of binaries you build. This is about coupling. Replacing systemd itself is the modularity we're talking about, which becomes harder to replace (less modular) every time systemd annexes another set of features.

Do those utilities use only well-defined, simple interfaces both to the system and between utilities? Can I replace one or more of those utilities with something else that implements those simple, stable, and well-defined interfaces? This what we mean by modularity; each piece of the complex system can be considered in isolation, with only minimal dependencies.

When I can remove systemd-PID-1, OR keep using systemd-PID-1 but replace those utilities with other tools, only then will systemd be a "modular" set of tools. If I have to recompile daemons to remove systemd dependencies (libsystemd-journal0, libsystemd-login0), those daemons are now part of the systemd monolith.

> needs to stop

The only things that should stop are these attempts at changing word definitions.

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

#76

Earlier quoted context omitted.

What binary blobs are you referring to? Aside from the, uh, binaries that run systemd, systemd services, and systemd utilities, the only other thing that is binary that I'm aware of is the binary log file, which can be reconfigured to revert to text if you so desire.

systemd is itself a series of something like 70-odd binaries. Why? Why not keep it text-based? It works for others.

What text-based things do you think it has replaced?

I'm still very curious as to what binary blobs you are referring to though.

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

#77
post #36

Earlier quoted context omitted.

Systemds molecularity is 'we'll write a systemd module to handle that.'

What's wrong with that? I think I quite like this "molecularity", I'd like to see more of it!

Ok that's it, enough internet for me today.

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

#78
post #49

Earlier quoted context omitted.

The Linux kernel itself is a a monolithic kernel and it beat out Hurd which was a micro kernel. I would say Linux has a history of certain programs being monolithic being a good thing.

Linux is a kernel. Monolithic and micro kernel architectures are a different problem to the Unix philosophy which specifically concerns design of userspace programs. I don't see how having pipes between kernel components would be a useful feature for a user. Also, the userspace of GNU/Linux isn't called Linux. Linux isn't an operating system.

I think you're post-rationalizing. The kernel is an exception today, true, but that doesn't mean it needs to be special.

The established Unix philosophy of everything being "one program that does one thing" would be hugely beneficial if applied to an OS kernel. Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel?

Not to mention that it could be much easier to develop them if they could just run as processes and die if they failed, as opposed to inducing a kernel panic.

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

#79
post #30

No point in discussing systemd anymore quite frankly, it won, doubt that it's good it did, doubt the methods by which it won - I do both - but it won. Many of the major distributions are not really following the Unix philosophy anymore, heck, some stopped quite a long time ago to do so. I run sever operating systems because I like to have the control, the minimalism, the elegance, the security. By trying to be more o…

I'm a tad confused... you cite that famous Unix philosophy quote "This is the Unix philosophy: Write programs that do one thing and do it well. Write programs to work together"... but I don't see how that doesn't apply to systemd? Could you clarify?

I would imagine people have a hard time lumping: service management, logging, login, network management, etc together as 'one thing'. As a CentOS 7 user, I certainly wouldn't describe it as 'doing it well'.

I think people initially were pretty stoked for the revamped init process, and then it started heaping on a lot more stuff. Poettering's communication style and other history didn't help either.

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

#80
post #75

Earlier quoted context omitted.

systemd has neither a monolithic architecture, nor does the systemd process itself do anything other than the following: "[systemd] provides a system and service manager that runs as PID 1 and starts the rest of the system. systemd provides aggressive parallelization capabilities, uses socket and D-Bus activation for starting services, offers on-demand starting of daemons, keeps track of processes using Linux control…

Systemd is the very definition of monolithic. > It comes with a set of utilities that do a lot of things "monolithic" vs "modular" has isn't about the number of binaries you build. This is about coupling. Replacing systemd itself is the modularity we're talking about, which becomes harder to replace (less modular) every time systemd annexes another set of features. Do those utilities use only well-defined, simple int…

That's like claiming binutils collections is monolithic..
Post reply on HN