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

91–100 of 189 posts

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

#91

Post by bpchaps »

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…

You must have a machine built for it, since I've had tons and tons of niggling little issues with systemd. Random, unnamed services sometimes fail to start or shutdown. One of systemd's big claim to awesomeness is that the start scripts run simultaneously, yet that's all thrown out the window when "Attempting to start, attempt 55 1m30s remaining" bullshit happens constantly and randomly, without enough information to debug properly.

The troubleshooting is ridiculous, too, because of the ridiculousness that comes with journald. Why does it feel the need to make me run an awfully formatted, and potentially complex set of parameters to print that? Especially considering that 9/10 times, the error message from journald is vague, ungreppable without -A or -B, and is often significantly shorter than the "use journald to print the error" output. So frustrating. I don't know how people deal with it.

That said, I'm not a fan of sysvinit, either, but I don't have to deal with as much smoke and mirror behavior with it.

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

#92

Post by chris_wot »

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

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

I notice you have added an aside :-)

> 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

I can and have made that case :-) I guess we'll agree to disagree.

> The way systemd is structured it's next to impossible to use any parts of it outside of systemd

Well that's not true. If you want to swap out a systemd daemon with another one, then you just have to write another service configuration file - see here: https://www.freedesktop.org/software/systemd/man/systemd.ser...

> nomenclature is ridiculous (system daemon, what's that even supposed to mean?)

It's the daemon that runs the system. init, you realise, is a daemon process? As in, it's a process that runs in the background that is not under direct user control?

> it suffers greatly from feature creep

A lot of folks quite like the features it has introduced, but that's subjective

> took over logging using a binary format

journald can be configured to do text logging...

> gained basic firewall controls

It's a component of the system, which doesn't have to be used.

> assimilated udev

I just cannot understand why this is such a big deal. udev is a userspace daemon that interacts with the kernel, it has had zero negative effect on anyone and it makes total sense for the ones maintaining the init system to integrate it into their tree and maintain it going forward!

> incorporated a bootloader

You can swap it out. Why is this a concern?

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

I'll stick with technical issues, not personalities.

Just reviewing your links:

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

No technical reasons given as to the concern over systemd, only some personality clashes ("Kick these fucking carpetbaggers to the curb!" - now there's a convincing argument!)

---

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

Yeah, I've read most of these, I'm really not convinced by any of the arguments

---

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

The guy rehashes the same arguments you are making, and I've already addressed each of them - I disagree!

---

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

Same author, same arguments - but with a side-dish of "what would the grey-beards think?" and concocted outrage over an apparent schism within the Linux community.

---

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

Same author again, and this time the argument is:

You have your Windows in my Linux

Ultimately, the schism over systemd could lead to a separation of desktop and server distros, or Linux server admins moving to FreeBSD

---

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

Yeah, that article was largely prompted by myself I think. I promised vezzny-ford I'd read this, and I never got around to it. I'll eventually do so :-)

---

http://suckless.org/sucks/systemd

I'll have a read - looks interesting.

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

#94

Post by alwaysdownvoted »

Sanddancer wrote: post #41
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…

I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the po…

You nailed it.

I rarely make use of the BSD scripts provided but I like them as simple examples of how various services are intended to be run.

I find there is a certain amount of uniformity and consistency and arguably coherence to the rc.d system.

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

#95

Post by chris_wot »

pdkl95 wrote: post #90
chris_wot wrote: post #81

Earlier quoted context omitted.

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

> Systemd's own documentation[1] disagrees.

Interestingly, most of it is reimplementable independently elsewhere. But I think it's instructive to quote why they say what they say:

"A number of systemd's APIs expose Linux or systemd-specific features that cannot sensibly be implemented elsewhere. Please consult the table below for information about which ones these are.

Note that not all of these interfaces are our invention (but most), we just adopted them in systemd to make them more prominently implemented. For example, we adopted many Debian facilities in systemd to push it into the other distributions as well."

So yes, there are some interfaces that are tightly coupled to Linux interfaces, and there are a few things like unit configurations, generators, system updates and presets that are very specific to systemd and, like they say, don't make any sense being implemented outside of systemd!

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

I don't believe I have contradicted myself. That component is a sticking point, and is a problematic dependency. I'm curious what the devuan guys did to sort this out. I assume they recompiled everything.

Edit: I'm watching the talk by Klaus, thanks for the link - very interesting! I think I'm a bit confused about his point about the kernel taking an extra 15 seconds to load... does that have anything to do with systemd? I would have thought that's something else.

I'm also not following his point about systemctl being a "GUI"... that's a command line utility, not a GUI based tool?

OK, he's not happy about journald's binary format. I get it, I'm not keen on it either. But I guess he didn't realise that in journald.conf you just change storage to 1 and ForwardToSyslog to 1 also...

He's concerned about parallelization on slower hardware. Fair enough... in that case, setup the unit files to set the order?

OK, and now he's concerned about Ubuntu's packaging... ?? I'm not entirely sure how that is a problem for systemd... and seems to be concerned about a sysvinit package that's not a standard part of Ubuntu any more? That seems a bit of a strawman...

Yup, that's what I thought! It takes 15 seconds when he replaces systemd - so not an issue with systemd in terms of bootup speed.

And now he's saying he doesn't like the fact that his system now requires multi-user session management. What? Oh come on, that's silly. He also doesn't know why the error is occuring...

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

#96

Post by liveoneggs »

geofft wrote: post #35
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…

The "Unix philosophy" of text streams hasn't worked, and arguably never worked. BSD sockets aren't quite text streams. Terminals aren't quite text streams. Shellshock existed because someone decided that serializing functions via text streams was a good idea. And if you look at the things you care about when running a daemon process -- sessions, controlling terminals, reliable restarts (without killing the wrong proc…

that's funny since mountcritremote and friends have been around sine, at least, 2000.

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

#97

Post by chris_wot »

khedoros wrote: post #86
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?

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

I was genuinely not aware that the components are that intertwined that they rely on each other. Which components are problematic?

In terms of Gnome - well, Gnome is Gnome. I'm not going to start defending their decisions, I disagree with quite a few of them myself.

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

#98

Post by felixgallo »

afarrell wrote: post #20
tmptmp wrote: post #13

Earlier quoted context omitted.

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.

> getting pushed around by end-user focus is way too unacceptable behavior why?

because there are several thousand desktop linux users, and hundreds of millions of linux servers, embedded and mobile devices.

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

#99

Post by INTPenis »

Sanddancer wrote: post #41
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…

I'd argue that one of the biggest things that made sysvinit so ugly was that distro maintainers didn't enforce any type of startup script hygiene. Take a look at BSD-style init scripts some time. They're beautiful in their simplicity and readability. They source a common set of functions, have well-defined variables to control execution, and end up with a length about that of systemd units, without sacrificing the po…

I actually came from FreeBSD to Debian 8 years ago and the funny thing is that I don't remember editing rc scripts anywhere near as often as I edited sysvinit scripts on Debian.

But that could easily be explained by the average complexity of services increasing along with my career path into Linux and Devops.

I don't remember any clear differences between sysvinit and rc, the scripting is still left up to the user which means code style can diverge from whatever the maintainers had in mind.

Systemd, albeit a binary blob, at least eliminates that from the equation and breaks down services into a limited number of types that it handles equally every time.

I actually liked upstart too. :) I might sound mad for saying that but as a user of Linux upstart gave me just what I wanted.

Bottom line is that I think discussions about scripting style have no place in the context of service management. Services should be dealt with in a simple way like upstart or systemd. If you want to add more complexity you can write a start script for the service but that should not be the norm.

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

#100

Post by bitwize »

cfallin wrote: post #63
chris_wot wrote: post #51

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…

wpa_supplicant Just Works. NetworkManager is more like NightmareManager.
Post reply on HN