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

61–70 of 189 posts

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

#61

Post by stephenr »

jcoffland wrote: post #29
ausjke wrote: post #16

Glad to see this coming out. https://www.devuan.org Downloading via torrent now, it's 10G via torrent? Anyways it seems the file server there is under pressure now. I for one don't want to deal with systemd from the start. Never liked its intrusive, all-in-one, hard to debug design approach.

Yeah, I dislike systemd but I'm not going to abandon the Debian Foundation over it.

This is the real point. I have my issues with systemd.

For example, I just had an interesting discussion on GH with Varnish packers about changing a daemon arg (in that case, the bind address/port).

The way systemd "recommends" to change the arguments passed to a daemon is to write a drop-in file (i.e. /etc/systemd/system/service-name.service.d/something.conf) that overwrites the ExecStart line. To do so, you have to do:

    [Service]
    ExecStart=
    ExecStart=
For Varnish, this isn't the end of the world - it only needs a few arguments - but it's still a lot less simple than the pre-systemd "standard" for Debian, which is to use a /etc/defaults/ file to allow changing daemon args via variables. This method can be still used (via either EnvironmentFile, or via built-in systemd "Environment=" statements) but the former is specifically mentioned as "not recommended" by Lennart, and the use of Environment= in service files seems very much like a feature that no one is keen to acknowledge or make use of, and it has it's own issues, as the way variables, white space, escaping etc are handled is specific to systemd and not immediately intuitive for someone used to a shell environment.

But as you said - those issues, are not enough to give up on the benefits of Debian stable. In theory, all packages in Debian stable that need an init script are supposed to still supply a sysvinit script (I was actually quite surprised by how many packages rely on systemd's ability to load sysvinit scripts and don't ship their own systemd service file) so you could choose to use sysvinit instead of systemd, for now at least.

I do appreciate the theoretical goal - you describe how your daemon should be started, and let pid1 handle the specifics of actually starting it - to me that makes it much easier for a lot more people to create reliable daemon packages.

I just wish the project wasn't taking such a "everything plus the kitchen sink" approach.

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

#63

Post by cfallin »

chris_wot wrote: post #51
cfallin wrote: post #48

Earlier quoted context omitted.

The thing is that the kernel, while large, has one defined purpose -- to provide abstractions of hardware resources and arbitrate those resources between programs -- and thus conceptual simplicity, even if the source tree is huge. The POSIX syscall API is simple and the rest is just implementation. In contrast, systemd is conceptually complex -- its scope continues to expand to manage every little nook and cranny and…

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 the tradeoffs), and I'm probably missing something.

Don't get me wrong -- I actually like some of the new thinking, appreciate parallelized bootups, and think service units are cleaner than the old /etc/rc.d mudball. I'd rather have things Just Work(tm) than play with wpa_supplicant and hibernate configurations on my laptop. But it's been a lot of new stuff to learn for someone used to the Old Ways, and it's kind of astonishing how fast systemd pieces have taken over different domains.

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

#64

Post by hiddennetwork »

chris_wot wrote: post #50
hiddennetwork wrote: post #40

Earlier quoted context omitted.

BSD handles all of this better than Linux. Text file. Easy. Linux has grown far too "complex". I like how OpenBSD adds modern touches yet keeps the OS free from binary blobs. systemd addresses some issues, but at the cost of complexity. I dislike binary blobs in my systems, hence, my servers run OpenBSD.

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.

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

#65

Post by microtonal »

tmptmp wrote: post #43
toast0 wrote: post #33

Earlier quoted context omitted.

It seems that GNOME had developed a strong dependency on systemd, which drove the whole process. I'm guessing "end-user" here means desktop user. I've used debian as a desktop and a server, and in the past it's been pretty easy to have it fill both roles; at this point though, systemd is basically forced onto a server system which involves a lot of changes and very little improvements for the server environment: the…

Thanks for clarifying "end-user" here means desktop user. I did mean desktop user. It's so sad that the Debian community chose to ignore server users to achieve the goal of pleasing desktop users. Servers and many other users do not need the gnome at all.

And I am a server user of Debian and happy with systemd. Finally an init system that can reliably detect failing daemons and that allows me to set restarting policies.

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

#66

Post by bitwize »

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…

Sysvinit scripts were shit. But as the AVGN might say, systemd took that shit sandwich and served it up with a side of buffalo vomit. It doesn't solve the "rat's nest of dependencies" problem, it makes it worse. Because now you have more moving parts which hard-depend on each other in various intricate ways and introduce unreliability into a formerly reliable startup process, combining the worst aspects of monolithic software with the worst aspects of modular software. Because development of components of systemd takes place in a bubble, there's not much room for feedback -- like is this a sane way to do system logging, network discovery, process group management, etc. That's easy to integrate with other pieces of software from the community? The systemd way to solve the integration issues is "pressure the major distros to adopt systemd. Then they'll HAVE to integrate with us!"

It's possible to run sysvinit sanely, by having a few startup scripts that source in the appropriate boilerplate. Slackware's startup for instance has always been manageable.

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

#67

Post by microtonal »

lottin wrote: post #42
GFK_of_xmaspast wrote: post #38

Earlier quoted context omitted.

I thought the Debian people had a vote and the choice was to go with systemd.

It was a technical committee who took the decision, if I recall correctly.

The was also a general resolution after that:

https://www.debian.org/vote/2014/vote_003

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

#68

Post by maaku »

rubiquity wrote: post #44
jcoffland wrote: post #28

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.

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.

Hurd was never a viable alternative for reasons that have nothing to do with the mono/micro distinction.

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

#69

Post by ferrari8608 »

jcoffland wrote: post #46
rubiquity wrote: post #44

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.

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 amongst Linux and the BSD's I think.

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

#70

Post by chris_wot »

cm3 wrote: post #17

One major problem with systemd is that beta software is released as stable and incorporated in distros. I've just realized that systemd-coredumpd is used to save crashes in the journal and write the files somewhere to /var. This has the problem that I have to vacuum or nuke the journal if I want to remove knowledge of past crashes because coredumpctl tool has no delete command. And coredumpctl hard-codes GDB as the d…

Try setting Storage=external in coredump.conf [1] - you seem to have it set to both, which I have to agree is probably less than ideal.

1. https://www.freedesktop.org/software/systemd/man/coredump.co...

Post reply on HN