Linux greybeards release beta of systemd-free Debian fork • Hacker News Board

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

#111

Post by chris_wot » Sat, Apr 30, 2016, 8:47 PM UTC

bpchaps wrote: post #91

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…

Try installing syslogd then in journald.conf you just change storage to 1 and ForwardToSyslog to 1. That should hopefully get your old text based logs back.

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

#112

Post by j3097736 » Sat, Apr 30, 2016, 9:07 PM UTC

chris_wot wrote: post #82

michael_h wrote: post #79

Earlier quoted context omitted.

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…

Scripts are just a simple abstraction that allows to manage all kinds of daemons, which allows SysV to happily work with anything it finds in the init directories.

We give you this thing that replaces half the system with utilities (re)written by us, but hey don't complain you're free use something else!

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

#113

Post by makomk » Sat, Apr 30, 2016, 9:09 PM UTC

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. Crashing ensued. Was rolled back in the next release, but that came with a whole new set of feature patches with the same level of QA applied.)

It probably doesn't help that they're both heavily developed by Red Hat, who see taking open source software and turning it into something stable and end-user viable as their secret sauce that justifies paying them lots of money.

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

#114

Post by chris_wot » Sat, Apr 30, 2016, 9:18 PM UTC

j3097736 wrote: post #112

chris_wot wrote: post #82

Earlier quoted context omitted.

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…

Scripts are just a simple abstraction that allows to manage all kinds of daemons, which allows SysV to happily work with anything it finds in the init directories. We give you this thing that replaces half the system with utilities (re)written by us, but hey don't complain you're free use something else!

So that's your argument? That it's different?

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

#115

Post by woodman » Sat, Apr 30, 2016, 9:20 PM UTC

INTPenis wrote: post #99

Sanddancer wrote: post #41

Earlier quoted context omitted.

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

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

#116

Post by gkya » Sat, Apr 30, 2016, 9:27 PM UTC

chris_wot wrote: post #110

gkya wrote: post #109

Earlier quoted context omitted.

Udev (AFAIK a program that recognises and mounts plug-in devices, but I'm not sure) is developped by systemd guys and they recently told that they won't care about the case where it is used w/o systemd. It is an important part of GNU/Linux distros. Tho I used Arch for about two-three years I guess (since just before it switched to systemd as default til two monts ago), and I never had to fiddle with it, so I don't kn…

Yeah, that's precisely what it does - it's a daemon that interacts with the kernel for hotplug devices, etc. Is udevd used by anything other than the kernel though? If not, then I don't think it's a huge issue if those who want to use a different init system maintain their own version!

Why waste all that effort of maintaining forks when it can be avoided? Systemd folks are being hostile to the wider community of Linux users with that.

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

#117

Post by cm3 » Sat, Apr 30, 2016, 9:28 PM UTC

chris_wot wrote: post #70

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

Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview.

If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of quality, is accepted as the new way while discarding existing ways as obsolete.

I should add to my startup hangup remark that I never before had a startup problem that was intermittent with plain old stupid init from 1994 up until systemd became the distro default.

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

#118

Post by chris_wot » Sat, Apr 30, 2016, 9:30 PM UTC

cm3 wrote: post #117

chris_wot wrote: post #70

Earlier quoted context omitted.

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

Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview. If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of…

Odd. Must be a bug, did you report it yourself?

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

#119

Post by cm3 » Sat, Apr 30, 2016, 9:37 PM UTC

chris_wot wrote: post #118

cm3 wrote: post #117

Earlier quoted context omitted.

Nope. I've scoured previous bug report and discussions and the only sure way was to prevent systemd from swallowing core dumps. It had the nice side effect that I learned the format string and configured it to my personal needs. But having to reverse engineer in order to remove crashes is not stable software and just a tech preview. If I wanted to be cynical, I'd believe anything coming out of systemd, regardless of…

Odd. Must be a bug, did you report it yourself?

No, I didn't because I didn't want systemd-coredump to handle (and grab) core dumps in the first place and existing discussions and bug reports didn't appear to miss public awareness of the issue. Also previous experience with the maintainers left a bad taste in my mouth. I should be more professional, but the mental barrier to engage with the systemd community is rather high. I cannot say the same about other freedesktop teams with which I regularly communicate in bugzilla.

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

#120

Post by chris_wot » Sat, Apr 30, 2016, 9:38 PM UTC

gkya wrote: post #116

chris_wot wrote: post #110

Earlier quoted context omitted.

Yeah, that's precisely what it does - it's a daemon that interacts with the kernel for hotplug devices, etc. Is udevd used by anything other than the kernel though? If not, then I don't think it's a huge issue if those who want to use a different init system maintain their own version!

Why waste all that effort of maintaining forks when it can be avoided? Systemd folks are being hostile to the wider community of Linux users with that.

You don't need to - there shouldn't be anything that stops other init systems from using it.