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

121–130 of 189 posts

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

#121

Post by gkya »

chris_wot wrote: post #87
eb0la wrote: post #39

I understand this because I can't get used to systemd. The learning curve should be better than rc.local for my taste. Problem is systemd helps you booting fast and this is important both in the cloud (where every minute is a billed), and in telecom (where you have a stringent SLA to cover).

I would have thought a fast boot would be important to pretty much everyone...

Why? When I used Arch Linux I did not ever turn off my laptop, but hibernate it. I only ever booted it when I stupidly forgot to plug it in before the battery runs out. And 10-20 seconds spend on a sequential boot every 10-20 days is just no time. We spend at least 100x that time in the toilet every day.

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

#122

Post by chris_wot »

gkya wrote: post #121
chris_wot wrote: post #87

Earlier quoted context omitted.

I would have thought a fast boot would be important to pretty much everyone...

Why? When I used Arch Linux I did not ever turn off my laptop, but hibernate it. I only ever booted it when I stupidly forgot to plug it in before the battery runs out. And 10-20 seconds spend on a sequential boot every 10-20 days is just no time. We spend at least 100x that time in the toilet every day.

I stand corrected.

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

#123

Post by chris_wot »

cm3 wrote: post #119
chris_wot wrote: post #118

Earlier quoted context omitted.

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

Sorry to hear that.

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

#124

Post by gkya »

chris_wot wrote: post #120
gkya wrote: post #116

Earlier quoted context omitted.

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.

But there is, and that's why people forked it.

https://wiki.gentoo.org/wiki/Project:Eudev

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

#125

Post by cm3 »

chris_wot wrote: post #123
cm3 wrote: post #119

Earlier quoted context omitted.

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

Sorry to hear that.

You don't have to be sorry, it's just that systemd as integrated in distros asks for regular QA work by the users, which I don't want to spend my time on. I'm happy to QA certain applications I follow closely, but in the past a Linux system once configured just worked even across major release upgrades. The patch OpenSUSE integrated to work around coredumpd was funny and quite all encompassing, all the while looking like they're trying very hard to close all possible avenues for it to creep back in. It's somewhere linked in an ArchLinux forum thread as a link to an opensuse github commit. Considering OpenSUSE distro devs as informed and capable that commit convinced me that at some point the workaround of overriding kernel.core_pattern in /etc/sysctl.d/50-coredumpd.conf might stop working. I don't look forward to that day and might switch to another distro before that.

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

#126

Post by chris_wot »

cm3 wrote: post #125
chris_wot wrote: post #123

Earlier quoted context omitted.

Sorry to hear that.

You don't have to be sorry, it's just that systemd as integrated in distros asks for regular QA work by the users, which I don't want to spend my time on. I'm happy to QA certain applications I follow closely, but in the past a Linux system once configured just worked even across major release upgrades. The patch OpenSUSE integrated to work around coredumpd was funny and quite all encompassing, all the while looking…

Actually, that's not true. I've had situations where my configurations broke between major releases of Ubuntu. I reported the issue and eventually it got resolved (no idea how I'm afraid), but whatever the issue for me it must have been an edge case as it wasn't widely reported.

That seems to be the case for you as well. You have my sympathies, it's most frustrating when it occurs.

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

#127

Post by chris_wot »

gkya wrote: post #124
chris_wot wrote: post #120

Earlier quoted context omitted.

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

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!

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

#128

Post by afarrell »

microtonal wrote: post #65
tmptmp wrote: post #43

Earlier quoted context omitted.

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.

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

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

#129

Post by chris_wot »

chris_wot wrote: post #105
stephenr wrote: post #102

Earlier quoted context omitted.

I guess he means systemd being a compiled binary so how exactly a service file is processed is less clear as say with a sysvinit script

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…

Funny how nobody can answer this question!

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

#130

Post by cm3 »

chris_wot wrote: post #126
cm3 wrote: post #125

Earlier quoted context omitted.

You don't have to be sorry, it's just that systemd as integrated in distros asks for regular QA work by the users, which I don't want to spend my time on. I'm happy to QA certain applications I follow closely, but in the past a Linux system once configured just worked even across major release upgrades. The patch OpenSUSE integrated to work around coredumpd was funny and quite all encompassing, all the while looking…

Actually, that's not true. I've had situations where my configurations broke between major releases of Ubuntu. I reported the issue and eventually it got resolved (no idea how I'm afraid), but whatever the issue for me it must have been an edge case as it wasn't widely reported. That seems to be the case for you as well. You have my sympathies, it's most frustrating when it occurs.

> I reported the issue and eventually it got resolved (no idea how I'm afraid), but whatever the issue for me it must have been an edge case as it wasn't widely reported.

Recently there have been major regressions in the kernel due to DRM atomic modesetting with bug reports with many confirmations and zero action from the maintainers while not being able to go past kernel 4.1 which is fortunately one of the long-term branches. 4.2 is also okay but there's no 4.2 lts branch.

I never used Ubuntu as my workstation OS, so I cannot talk about their QA standards or how well it would have worked for me, but I've observed sloppiness in their packaging and integration work on others' systems. I mean, it's also important to remember that the advertised number of Ubuntu packages is not truthful if you're honest, because it's a snapshot of Debian's repositories and thus anything in Universe is probably unmaintained when compared to the repository in Debian. That means, the curated set of packages is quite small in comparison. I hope the situation improved in the last years.

Post reply on HN