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

161–170 of 189 posts

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

#161

Post by cm3 »

forgotpwtomain wrote: post #144
makomk wrote: post #113

Earlier quoted context omitted.

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.

And audio professionals working on JACK don't seem to have any interest in pushing it while Lennart has been selling PulseAudio as the low-power alternative to JACK. Maybe he would have been a better fit within Android.

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

#162

Post by JdeBP »

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!

> Have a look at Devuan, I think you'll find that they use the same udev as Ubuntu and Debian.

Yes, in amongst all of this systemd discussion, please do look at the notional actual topic of this page. And discover vdev. It's explicitly mentioned in the release notes.

* https://github.com/jcnelson/vdev

* http://judecnelson.blogspot.co.uk/2015/01/introducing-vdev.h...

* http://www.linuxquestions.org/questions/debian-26/devuan-417...

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

#163

Post by JdeBP »

d02 wrote: post #93

It is amusing and unsurprising that, in 91 comments, the word Devuan is used a total of 2 times.

I've just mentioned it. So it's 3 now. (-:

What you observe is emblematic of the problem with Devuan, and a few of the Devuan people themselves acknowledge it. So much of the discussion centres upon "how to remove evil libsystemd0" and suchlike that what is lost is the supposedly intentional focus of the Devuan project on init freedom. That surely means the freedom to run systemd as well as to not run it.

* https://lists.dyne.org/lurker/message/20150208.110824.579d17...

And as you can see, that bleeds over into the press coverage seeking headline material.

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

#164

Post by JdeBP »

afarrell wrote: post #128
microtonal wrote: post #65

Earlier quoted context omitted.

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.

Could you recommend a good tutorial on writing init scripts with systemd? I'm moving over from using upstart.

Remember the first rule for migrating to systemd.

* http://askubuntu.com/a/626858/43344

* http://homepage.ntlworld.com./jonathan.deboynepollard/FGA/sy...

* http://askubuntu.com/a/613814/43344

And read the doco that comes with your operating system (presumed to be Ubuntu, given that you say that you use upstart).

* https://wiki.ubuntu.com/SystemdForUpstartUsers

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

#165

Post by rwmj »

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…

I agree with the rest of your post but I can assure you it's not the policy of Red Hat to release unstable upstream software. I am a Red Hat employee and I'm as annoyed as anyone that systemd doesn't have separate upstream development and stable releases.

Also what's with the stupid versioning of systemd/udev? Having a single version number is simply a dumb idea.

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

#166

Post by JdeBP »

woodman wrote: post #115
INTPenis wrote: post #99

Earlier quoted context omitted.

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

> scripting is still left up to This is commonly provided by the port maintainer - I haven't conducted a survey but I'm pretty confident that service scripts in FreeBSD ports rarely make it into rc.d without a deliberate freebsdization.

I have read all of the rc scripts that come with base FreeBSD and PC-BSD, and some of the NetBSD ones too. Coding style with Mewburn rc is nowhere near as divergent as it is with van Smoorenburg rc.

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

#167

Post by lobster_johnson »

cyphar wrote: post #150
lobster_johnson wrote: post #78

Earlier quoted context omitted.

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). Hybri…

Debugging would be easier in user mode, surely. You could attach with gdb or whatever.

Last I checked, IPC overhead was not a barrier to performance in modern microkernels. QNX and XNU (used by OS X) both use microkernel-type IPC and are fast. XNU is even able to survive with an old Mach kernel.

If a kernel driver ends up in a faulty state (accesses invalid memory, does the wrong interrupt thing) then surely the whole kernel will panic?

NT is frequently referred to as "hybrid", but it's a frequently misunderstood design. First, while it uses IPC internally, it's not really comparable to microkernels since there's no context switch; every participant in the IPC communication is in the kernel. This is done purely as a way to isolate internals behind a rigorous, message-oriented API. Secondly, almost all of NT's services run in the kernel. A fairly small number of services run in userland: There's the user-mode driver system (UMDF, available since Vista), and graphics drivers also have the option of running partly in usermode.

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

#168

Post by criddell »

fmoralesc wrote: post #26
lottin wrote: post #22

Earlier quoted context omitted.

Exactly, I use Debian because it has a large user base and community. But that's precisely why it's important than the mainstream distributions continue to support the traditional Unix init. People don't want to have to switch to some obscure distribution simply to avoid systemd.

There isn't much reason for a mainstream user to touch a system with a traditional init nowadays either.

There isn't much reason for a mainstream user to care what the initialization sequence looks like. Can they run the applications that they need to? That's about all a mainstream user cares about. Linux is just boring infrastructure that needs to be there. All the interesting stuff happens in user land.

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

#169

Post by digi_owl »

welterde wrote: post #141
vidarh wrote: post #106

Earlier quoted context omitted.

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

Don't bother, the guy is dyed in the wool devops.

And to them systemd is mana from heaven, as it allows them to bring up and shut down any number of nodes in their cattle farm swiftly.

Where before admins fretted about making sure a server stayed up when booted (and if it went down, make damn sure to figure out why so it didn't happen again), devops seems to adopt what i consider uptime by machinegun.

That server won't stay up for some reason? No problem. Lets just throw thousands more just like it at the task, like a machinegun throws bullets at a target.

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

#170

Post by chris_wot »

JdeBP wrote: post #162
chris_wot wrote: post #127

Earlier quoted context omitted.

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!

> Have a look at Devuan, I think you'll find that they use the same udev as Ubuntu and Debian. Yes, in amongst all of this systemd discussion, please do look at the notional actual topic of this page. And discover vdev. It's explicitly mentioned in the release notes. * https://github.com/jcnelson/vdev * http://judecnelson.blogspot.co.uk/2015/01/introducing-vdev.h... * http://www.linuxquestions.org/questions/debian-26…

Ah! Thanks - I didn't see this! Appreciate the info :-)
Post reply on HN