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

Linux greybeards release beta of systemd-free Debian fork

theregister.co.uk

Post reply on HN
Print view View original

81–90 of 189 posts

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

#81

Post by chris_wot »

pdkl95 wrote: post #75
chris_wot wrote: post #47

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…

Really? How do you figure that? It shouldn't be that hard to replace most of the components that come with systemd with replacements.

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.

Um, yes - you can.

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.

There is no factual basis to this claim. There is only really one component that can't be easily replaced, and that's journald.

I challenge you to tell me which component of systemd other than journald can't be swapped out if you so desired.

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

#82

Post by chris_wot »

michael_h wrote: post #79
chris_wot wrote: post #55

Earlier quoted context omitted.

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.

Really? System V init, which is what it replaced, did all of those things. It handles daemons and starts login, depending on the runlevel, and the startup scripts turn on logging, network services - and you use those same scripts to stop and start services.

So what in particular, other than Lennart's supposed abrasive nature, do you have an issue with? I'm genuinely not following some of this reasoning, at least from a purely technical level.

Incidentally, really need to speak to some of the BSD guys about what they think of SysV-style init. Now that could prove to be an interesting flame war :-)

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

#83

Post by themartorana »

CaptSpify wrote: post #27
INTPenis wrote: post #18

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…

If all systemd did was sysvinit-script replacement, I'd be 100% behind it. I agree with you, sysvinit-scripts are terrible. It's all the other stuff, and the lack of modularity, that makes me dislike it.

Agreed. And upstart didn't suck for that.

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

#84

Post by chris_wot »

marcosdumay wrote: post #56
witty_username wrote: post #19

Earlier quoted context omitted.

> functionality That is, actually doing the work of init i.e. spawning daemons and services.

Well, it makes sense that whatever spawns the daemons also keeps track of them, restarts them on failure, controls containers, disposes of zombie processes, and helps debugging init scripts. It makes no sense for such tool to control network interfaces, logging, device sync, power mode changes, and well... I'm certainly forgetting one or two dozen systemd modules.

Sure it does. Letting systemd handle startup dependencies is a very good thing, IMO. You configure some unit files to allow for one unit to start after another, otherwise they run in parallel. Not sure what the issue is with that?

As for those other tools... well, the systemd init process doesn't manage those either. The anciliary modules do, and quite well too really. I'm not entirely sure why people think that this is much different to running a SysV script to execute start a daemon!

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

#85

Post by schmichael »

ferrari8608 wrote: post #69
jcoffland wrote: post #46

Earlier quoted context omitted.

Hurd has failed after many years to produce a kernel even nearly as complete as Linux.

That's because there are only a couple of guys working on it. Linux has had hundreds of contributors over the years, many of which work for large tech companies like Intel and get paid by their company for their contributions. I would be fascinated if Hurd could get the same sort of developer momentum to be comparable to Linux. A completely new (as in 1.0 released) and usable FOSS Unix-alike would be quite welcome am…

GNU's kernel efforts had an entire team debating, discussing, prototyping, and eventually working on Hurd before Linux even existed.

Linux was initially written and released by one guy.

Linux obviously gained a wider team while Hurd languished, but it's still interesting that GNU's kernel efforts started with far more initial human resources and were still quickly overshadowed by Linux.

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

#86

Post by khedoros »

chris_wot wrote: post #55
cisstrd wrote: 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?

"Systemd" isn't really a single program, it's a collection of 69 binaries, that together handle a number of functions that were traditionally handled by separately-developed pieces of software. It handles init, user logins, the console, system event logging, network interface configuration, time+date settings, and device management (udev was merged into Systemd in 2012, apparently).

A lot of those components have interdependencies (so they can't all be replaced piecemeal), and some userspace things like Gnome have come to have dependencies on things provided by parts of Systemd.

This has benefits: Things tied tighter together know more about the states of other parts, and that enables various optimizations. This has issues: Replacing individual components (if you don't like their behavior) becomes more difficult. Whether it's worth it or not seems like a philosophical debate.

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

#87

Post by chris_wot »

eb0la wrote: post #39

I understand this because I can't get used to systemd. The learning curve should be better than rc.local for my taste. Problem is systemd helps you booting fast and this is important both in the cloud (where every minute is a billed), and in telecom (where you have a stringent SLA to cover).

I would have thought a fast boot would be important to pretty much everyone...

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

#88

Post by chris_wot »

tmptmp wrote: post #13
mwfunk wrote: post #11

Earlier quoted context omitted.

How dare they consider end users! What is the world coming to?!?

I am not against them considering the end users. But getting pushed around by "end-user" (please read desktop-user) focus is way too unacceptable behavior, especially for a community like Debian. edit: added clarification for end-user.

Except they weren't.

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

#89

Post by cisstrd »

chris_wot wrote: post #55
cisstrd wrote: 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?

The way systemd is structured it's next to impossible to use any parts of it outside of systemd, nomenclature is ridiculous (system daemon, what's that even supposed to mean?), it suffers greatly from feature creep, took over logging using a binary format, gained basic firewall controls , assimilated udev, incorporated a bootloader, ... and some additional things people took/take offence with: introduced to quickly, criticism was shut out instead of being debated, promises were broken, main developers behind it are quite arrogant and often ignorant when dealing with complaints/bugs... et cetera

there is a reason why Lennart is good in stirring up controversy, and it's not because everyone is just against him for no reason.

some further reading/links that might interest you:

https://lkml.org/lkml/2014/8/12/459

http://without-systemd.org/wiki/index.php/Arguments_against_...

http://www.infoworld.com/article/2608798/data-center/systemd...

http://www.infoworld.com/article/2608864/data-center/choose-...

http://www.infoworld.com/article/2608870/linux/you-have-your...

http://blog.darknedgy.net/technology/2015/10/11/0//

http://suckless.org/sucks/systemd

edit: systemd might be perfect for you or other people, I don't doubt that, it might make things easier for some, in some respects in might do some things better, but if the debate (as it is now) is whether it follows the unix philosophy or not, I don't think one can reasonably make the case that it does

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

#90

Post by pdkl95 »

chris_wot wrote: post #81
pdkl95 wrote: post #75

Earlier quoted context omitted.

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…

Really? How do you figure that? It shouldn't be that hard to replace most of the components that come with systemd with replacements. 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 c…

> Um, yes - you can.

Systemd's own documentation[1] disagrees. Several important interfaces - which are used by other parts of systemd- are marked as not being independently reimplementable. Another way to say that is that systemd considers those to be tightly coupled.

> There is only really one component that can't be easily replaced, and that's journald.

You're contradicting yourself. If I remove all of systemd, existing daemons will need to be recompiled because libsystemd-journald.so is missing. You don't just to pretend that isn't a dependency.

The common response that we should just keep the library file is an attempt to pretend this problem does not exist. Klaus Knopper even gave a talk recently[1] about this very problem, which is causing problems (some of which have workarounds) for the next version of Knoppix.

[1] https://www.freedesktop.org/wiki/Software/systemd/InterfaceP...

[2] https://www.youtube.com/watch?v=lDXsw2ijRkw

Post reply on HN