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

141–150 of 189 posts

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

#141

Post by welterde »

vidarh wrote: post #106
pdkl95 wrote: post #57

Earlier quoted context omitted.

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

> The larger problem is that init is only a tiny part of systemd. That's because you can't reasonably fix the many problems with sysvinit (or OpenRC) without also providing a proper process manager, and dependency system that does far more than just trigger scripts in the right order. The biggest problem with init is that it's just init. > Do you enjoy depending on a moving target that changes at the whim of the syst…

> The biggest problem with init is that it's just init.

Why does init have to service supervision? What's wrong with having init just launch the service supervision process and afterwards just reap dead processes (which allows init to be a very simple program indeed [1]).

As for the requirements to the init+rc system.. mine look a bit different: it should be reliable and predictable first.. performance not so much.

OpenRC works pretty well for me, the only thing I would change right now is to replace that start-stop-daemon rubbish with runit (and there is work under way to allow that if I am not mistaken).

Now you will probably say that anything still using start-stop-daemon is strictly worse than whatever systemd does, because it won't restart the daemon at all if it crashes (and is ugly in some other ways too). I would agree with that in theory, however in my case this happens rarely enough that it is the smaller evil versus the systemd system sometimes not booting properly at all.

[1] https://github.com/rxse/lyrica/blob/master/lyrica.ml

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

#142

Post by chris_wot »

cm3 wrote: post #132
chris_wot wrote: post #131

Earlier quoted context omitted.

Yeah, frustrating. But not really something you can pin solely on systemd...

I didn't, it's a totally different part and fallout from a major change.

In that case I misunderstood you and owe you an apology. Sorry about that. I appreciate your viewpoint, even if I disagree with you. I think systemd is a bit of a sore spot for me so I'm probably a bit too insistent and forceful on this issue so if I overstepped the mark I apologise for that also.

Peace :-)

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

#143

Post by itomato »

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…

Lean unit syntax is not the defining feature of "System 500".

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

#144

Post by forgotpwtomain »

makomk wrote: post #113
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…

Same thing with Lennart's previous project PulseAudio which also has no real stable releases and basically relies on distros to try and take the beta-quality upstream releases and turn them into something that actually works reliably. (My favorite was the PulseAudio release that shipped with a change that was literally incomplete, changing the interal resampling API without changing all the resamplers affected. Crash…

It's 2016 and I still have issues with pulseaudio, frankly I was somewhat surprised they let him replace init with systemd - given the terrible mess that pulseaudio has been historically.

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

#145

Post by SwellJoe »

chronid wrote: post #140
chris_wot wrote: post #105

Earlier quoted context omitted.

I can't see how that is the case. Why is this any less clear? I don't think following the Fedora debug guide is any less difficult than troubleshooting a SysV-init script. https://fedoraproject.org/wiki/How_to_debug_Systemd_problems It's curious that he says "Binary anything is bad when alternatives exist. Linux has given itself over to binary blobs in the name of being more attractive to corporate users. Device driv…

You seem to forget that the bash scripts are the entire rc system. In systemd, the init binary and utilities are the entire rc system. Those commands will not help you if you have to find a bug into systemd code to find something like a constant on the maximum size of a core dump and work around it. Then open a bug and hope it does not get ignored for ~3 years. But who needs core dumps anyway, right?

What happens when there's a bug in bash? Same thing. init is not the only component or source of complexity in the old way. Sometimes the problem will be in the script, sometimes it'll be in the thing that runs the script. Initscripts are vastly more complex than systemd service definition files (and the latter is declarative rather than procedural). Systemd pushes some of the complexity down the stack, and that is a reasonable choice. There will be more bugs in systemd than init and bash (or ash or dash), simply based on age and maturity of the respective projects.

There's complaints to be made about systemd, but I don't find this complaint compelling, at all. I think moving from procedural programs that are sometimes hundreds of lines long to declarative config files that are never more than a couple dozen is an overwhelmingly positive thing.

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

#146

Post by SwellJoe »

Don't fork in anger.

There's such a long history of projects starting out of a desire to not change, and so many of them (most, I would wager) fizzle out soon after. Being against some specific feature or architectural change is not the same as having a future vision that can drive a person to work on something, for no pay, for years or decades. Anger fades...the people you're angry at ignore the new project, making it unsatisfying in terms of vengeance. And, again, it just doesn't stick with you the way a desire to do something new and better does.

I'm not even saying systemd is great (it's good and bad in all sorts of novel ways), I'm just saying that the people who are just reacting against it, when the industry and community has been so clear about it being the future they are passionate about, are unlikely to do anything more than spin their wheels for a few months, and then fade away (as a project, I hope they all stick around as contributors to OSS things).

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

#147

Post by chris_wot »

chris_wot wrote: post #127
gkya wrote: post #124

Earlier quoted context omitted.

But there is, and that's why people forked it. https://wiki.gentoo.org/wiki/Project:Eudev

Uh, that wasn't forked because udev can't work, it was forked because it fit the needs of Gentoo... Have a look at Devuan, I think you'll find that they use the same udev as Ubuntu and Debian. It's not hostile if someone forks a project to meet their requirements but the old software is used by everyone else!

Can the person down voting please explain why? I'm going to assume you believe I've been factually inaccurate. If that's the case, I don't mind the downvotes as much as you not explaining where I'm wrong or making any attempt to engage in discourse.

If I'm not wrong, then perhaps you should reconsider your actions, because I'll still say what I believe even though you may not like it, karma be damned!

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

#148

Post by stephenr »

SwellJoe wrote: post #145
chronid wrote: post #140

Earlier quoted context omitted.

You seem to forget that the bash scripts are the entire rc system. In systemd, the init binary and utilities are the entire rc system. Those commands will not help you if you have to find a bug into systemd code to find something like a constant on the maximum size of a core dump and work around it. Then open a bug and hope it does not get ignored for ~3 years. But who needs core dumps anyway, right?

What happens when there's a bug in bash? Same thing. init is not the only component or source of complexity in the old way. Sometimes the problem will be in the script, sometimes it'll be in the thing that runs the script. Initscripts are vastly more complex than systemd service definition files (and the latter is declarative rather than procedural). Systemd pushes some of the complexity down the stack, and that is a…

To both of you: s/bash/shell/

On Debian they're specifically not bash scripts, they're posix shell scripts and /bin/sh is provided by dash which is much lighter than bash.

I like the declarative nature of service files I'm just not a fan of the hoops it makes us jump through to achieve the same results (see my other comment about changing daemon args)

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

#149

Post by SwellJoe »

stephenr wrote: post #148
SwellJoe wrote: post #145

Earlier quoted context omitted.

What happens when there's a bug in bash? Same thing. init is not the only component or source of complexity in the old way. Sometimes the problem will be in the script, sometimes it'll be in the thing that runs the script. Initscripts are vastly more complex than systemd service definition files (and the latter is declarative rather than procedural). Systemd pushes some of the complexity down the stack, and that is a…

To both of you: s/bash/shell/ On Debian they're specifically not bash scripts, they're posix shell scripts and /bin/sh is provided by dash which is much lighter than bash. I like the declarative nature of service files I'm just not a fan of the hoops it makes us jump through to achieve the same results (see my other comment about changing daemon args)

I mentioned dash and ash. I'm aware of the difference across distros.

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

#150

Post by cyphar »

lobster_johnson wrote: post #78
cyphar wrote: post #49

Earlier quoted context omitted.

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

> Wouldn't it be great you could just run different drivers and file system in userspace rather than having to compile a big kernel?

Except that it makes debugging almost impossible and the overhead of IPC is very large. I'd argue that most popular kernels today (k{Free,Open,Net}BSD, illumos, Linux) are monolithic because that model makes development much simpler than a microkernel (not for historical reasons). Hybrid kernels like NT are a compromise for efficiency against the benefits of having a microkernel.

The panic argument is a good point, until you realise that kernel drivers don't panic --they oops. And a kernel oops just kills the thread it was running in. Linux has kernel threads that can be killed, but they're all playing in the same address space. So you can think of that as having the advantages of a microkernel without the debugging issues.

Post reply on HN