Users/Developers Threatening Fork Of Debian GNU/Linux

[Ericg]

Yes, because for an init system this is f*cking unacceptable: systemd segfaults, crashes and freezes.

Oh, maybe because Linux developers have lost their minds completely.

People and ISVs beg them for a stable platform, they make it even more unstable.

All pointless examples given that the kernel itself suffer from those very things... Hell I had a very consistent kernel crash just a week ago that would happen anytime i plugged in a USB to my USB 3.0 port. KDE 5.1 would crash everytime I closed out Dolphin. All software has problems. All Software has bugs. A google search is a HORRIBLE way to judge the quality of a project given that they could be from any point in time and yo have no idea if they've already been fixed or not.

Troll argument is troll.

[birdie]

First, can't they have an installation option?
At installation time you can choose which init system you want.
Or can't we have two Debian flavors (sysvinit and systemd) if the differences are too far apart (I don't think so)?
History will decree what is the most favorite (which is not the same as "the best") solution.

1. Some applications have grown to depend on systemd - for instance Gnome/GDM - so it's not that easy.
2. Having N init systems means you have to create N init units for every daemon. Debian developers don't want to waste their time keeping N sets of init scripts.
3. Many projects started to abandon SysV init scripts, which means old scripts must be revived/rewritten/created from scratch.

[birdie]

All pointless examples given that the kernel itself suffer from those very things... Hell I had a very consistent kernel crash just a week ago that would happen anytime i plugged in a USB to my USB 3.0 port. KDE 5.1 would crash everytime I closed out Dolphin. All software has problems. All Software has bugs. A google search is a HORRIBLE way to judge the quality of a project given that they could be from any point in time and yo have no idea if they've already been fixed or not.

Troll argument is troll.

When a user space application crashes - that's one thing. When your system is unable to boot or totally crashes, that's another. Kernel panics at least have a greater visibility/publicity, so they usually get resolved pretty fast.

And I'm f*cking tired of open source fanatics calling everyone who doesn't love and totally support everything open sourced 'a troll'. By doing that you make yourself look childish, stupid and arrogant. Instead of giving arguments you call names. That's pathetic.

[RSpliet]

My point (provided that it makes sense) is "choices".
We need choices, not forks.
More or less as we do with desktop environments, text editors, Java runtimes, web browsers, ...
IMHO.

For stand-alone end-user programs like web-browsers, e-mail clients and even WMs I think you are quite right. However, for system-level components I have not completely decided upon this. Package managers are a good example.
To the best of my knowledge, there's quite a few package managers around: yum, apt, opkg, pacman etc. This is fine, generally distro pick their poison and stick to it. However, projects like PackageKit, aimed at making life easier for users, suffer from this fragmentation because now such a project needs a whole lot of back-ends. For a long time PackageKit suffered from bugs and feature-incompleteness of certain back-ends, resulting in a different user-experience for their front-end on different distros. Differences in back-end APIs sometimes make that a project like PackageKit has to settle with just the features supported by *all* of the back-ends, losing out on some interesting other features if they cannot be hidden from the user.
A similar situation might arise when the init-systems start fragmenting. When there's choice between 3 (sub-)init systems (say sysv, systemd, xinitd) , every package that wants to start a daemon by default will now have to provide 3 different scripts and config files. They potentially have to support several different methods of forking, logging etc. This means there's more burden on software developers (keeping all these scripts up to date), if they even care to look beyond their own favourite distribution and init system.

Now don't get me wrong, this problem in no way favours one init system over the other, but... maybe we do need some (freedesktop?) standards to contain the effects of fragmentation and minimise burden for developers, so they can focus on what they do best rather than wrestling with init systems.

[Uqbar]

1. Some applications have grown to depend on systemd - for instance Gnome/GDM - so it's not that easy.

This sounds more like a con than a pro. But this could be just me.

2. Having N init systems means you have to create N init units for every daemon. Debian developers don't want to waste their time keeping N sets of init scripts.

With N=2 this is not more complex than handling N different desktop environments. With N >= 5 (Gnome, Mate, Cinnamon, KDE, XFCE, LXDE, ...)

3. Many projects started to abandon SysV init scripts, which means old scripts must be revived/rewritten/created from scratch.

How many? Do you mean "upstart" and "launchd"? I don't know of "many" distributions already using systemd. Maybe just one?

[pal666]

Yes, because for an init system this is f*cking unacceptable: systemd segfaults, crashes and freezes.

Oh, maybe because Linux developers have lost their minds completely.

People and ISVs beg them for a stable platform, they make it even more unstable.

https://www.google.com/search?q=systemd+segfault#q=sysv+init+segfault

two orders of magnitude more hits
main problem of linux is bullshitspreaders like you

[birdie]

How many? Do you mean "upstart" and "launchd"? I don't know of "many" distributions already using systemd. Maybe just one?

Mandriva, Arch, Fedora, (next release) Suse.

[pal666]

I certainly hope these dependencies are limited to the format of the start-up scripts and nothing that'll tie in deeper. If so, there should be fairly little humps when using uselessd, a stripped down fork of systemd that gets rid of much of the disputed features in favour of a more modular approach.

you certainly live on a tree because systemd accepts sysv init startup scripts

[birdie]

https://www.google.com/search?q=syst...+init+segfault
two orders of magnitude more hits
main problem of linux is bullshitspreaders like you

Have you seen any of those segfaults? BS'er is you 'cause SysVinit basically has no way of crashing. It runs bash/sh /etc/rc.d/rc.sysinit and then waits for certain signals. That's all.

But you personally developed SysVinit and systemd so you know better.

LOL, more links in Google. Without actually following a single link. Wow, a new level of idiocy.

[pal666]

An init system must be rock f*cking solid and equally simple.

that means no fucking shell scripts executing binaries from all of fucking /usr/bin

There was a proposal to create a very simple, very basic init 1 process which spawns all other crazy systemd features as sub-processes so the whole system has no chance of crashing but no, Lennart doesn't think it's worth it.

it is hard to argue with crazy people living in their own fantasy world. systemd already is very basic init 1 process which spawns all other crazy systemd features as sub-processes