Users/Developers Threatening Fork Of Debian GNU/Linux

[TheBlackCat]

Seems like wikipedia has caught on as well:

possible impending vandalism

There is a website debianfork.org which expresses hostile sentiments towards systemd. Under the "How can I help?" section it suggests: Also it can be helpful to monitor and update the Wikipedia page about SystemD. --77.12.0.101 (talk) 10:26, 19 October 2014 (UTC)

[aigarius]

it is a bug in some people's brains what makes them think that some software depends on being started by any particular init system. in reality software depends on some runtime interfaces which it uses. any init system can provide them.

True, however, considering that systemd is not the only init system in wide use and that freedom of choice between init systems is an important value for Debian, it is a bug to fully rely on presence of such interface. Every software must check if this interface is available or not and provide a fallback path to run correctly when the interface is not available. Only one init system may be active on an installation at the same time, that is why applications must continue working in situations where the init system is different. It is fine to provided limited functionality when there is no systemd support, it is however not fine not to work at all.

This is the same for examples of window managers or start menus. Some cool new window manager or start menu might provide some new interface (like startup animation) and apps and libraries might want to use those new interfaces. However, they must do it in such a way that they would still remain functional using any other window manager or start menu, even if they do not provide these new interfaces.

When you use a system service with multiple viable alternative implementations, you may only rely on the minimum common API to be there. For anything extra you must check if the functionality is available and handle failure correctly. Otherwise it is a bug.

[pal666]

it is a bug to fully rely on presence of such interface.

no it is not. if your lovely init does not provide this interface then it is bug in your init

Only one init system may be active on an installation at the same time

but we already agreed that active init system does not matter. interface can be provided on top of any init system.
btw, do all debian packages support installation by alternative package managers like rpm ?

[jrch2k8]

If I hadn't experienced all of this firsthand, I wouldn't have posted these links here. I tried Fedora 20 just recently and I saw with my own eyes how systemd segfaulted. OK, that was a bug, yum update fixed it. Then it froze on boot trying to run two bad services over and over again - not even trying to realize that they cannot be launched.

Systemd is an abomination. An init system must be rock f*cking solid and equally simple. Systemd is anything but. 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.

seems made up to me unless is a fedora specific booboo(or early selinux conflict, there was a bug like that some months ago) or your RAM is failing in low area sectors because i have 250(VPS, LXC containers, big iron dense virtualisation servers, 50 workstations,etc.) Arch installations with systemd and i have never seen a sigsegv or systemd looping a service start. Additionally i bought 50 RHEL7 license for a client at release and 0 failures so far and those servers run pretty critical intense stuff too. <-- btw i don't use the vanilla .services provided by arch/redhat, i use them as template to harden all services in those machines(RBAC + slices + ondemand) since i'm very very very picky about security, point is i heavily modify 90% of the .service files and obviously made many mistakes along the way and even so never was able to break systemd boot beyond the specific service including systemd internal service(i modified those too)

Additionally, i'm actually developing a project that i hope to reach upstream systemd in the future and while learning the API and internal quirks of my dev systemd tree, i have done very horribly stupid mistakes(the kind that generates SigSegv all the way to a kernel panic) and even then systemd booted fine(did fill 2G of logs tho) because CGroups jailed my process before any harm were done to base init process, sure is possible i didn't stress the right path right to trigger your failure

btw, sysV/upstart were never easy nor rock solid ever, in fact were very easy to break completely(add an extra ; near a loop in your init script and enjoy chroot from an external device or try to harden a service and by mistake add it to runlevel 2 and enjoy or by mistake change the owner of touch and enjoy utter destruction, etc.)

so, post a crash dump if you have one to be able to tell what happened, this kind of failures are extremely rare and not so easily triggered

[stevenc]

Well, Debian GNU/kFreeBSD still can use sysvinit...

[Hohlraum]

Well, Debian GNU/kFreeBSD still can use sysvinit...

Yeah, and it's gained such wide usage!

[aigarius]

no it is not. if your lovely init does not provide this interface then it is bug in your init

but we already agreed that active init system does not matter. interface can be provided on top of any init system.
btw, do all debian packages support installation by alternative package managers like rpm ?

Not providing an interface that did not exist a year ago can not be a bug higher than wishlist.

Also, please look at logind. It was exactly the *active* init system that did matter there. logind did not work unless systemd was PID 1. Either logind is an independent interface and should be able to work with other init systems or logind is a part of systemd in which case it is an unique feature of systemd and others may not depend on it being available.

All Debian packages were supported being run by all init systems before this year. All Debian packages are supported being started by all shells. All Debian packages are supported to being run under all window managers. All Debian packages are supported by being run from any start menu manager. Debian has always supported choice in these areas. Dropping support for alternatives in some area is a big decision, that must be made explicitly.

Debian has never supported package installation with rpm. It is possible with the packaged rpm or alien package, but that has never been a supported way of installing packages.

[erendorn]

Not providing an interface that did not exist a year ago can not be a bug higher than wishlist.

Also, please look at logind. It was exactly the *active* init system that did matter there. logind did not work unless systemd was PID 1. Either logind is an independent interface and should be able to work with other init systems or logind is a part of systemd in which case it is an unique feature of systemd and others may not depend on it being available.

All Debian packages were supported being run by all init systems before this year. All Debian packages are supported being started by all shells. All Debian packages are supported to being run under all window managers. All Debian packages are supported by being run from any start menu manager. Debian has always supported choice in these areas. Dropping support for alternatives in some area is a big decision, that must be made explicitly.

Debian has never supported package installation with rpm. It is possible with the packaged rpm or alien package, but that has never been a supported way of installing packages.

Managing user sessions is simply not easy. Check what both KDE and Gnome maintainers say on the subject.
Consolekit does it, but is unmaintained, and apparently already starting to break.
logind does it, is maintained, does it securely, and easily.
It is perfectly understandable for a DE to depend on such tools to launch and manage user sessions. Any fallback would probably be either mono user, or just displaying a poput saying "sorry, no user session without logind".

Now, if some other project would have provided decent user session management before logind, they would surely use this project interface, and logind would have to provide the same. As it happened, it's the other way around.

There are no other viable user session managers, so it's not a bug to depend on the only one available.
Once some other show up, I'm sure Gnome will accept patches to support it. If it supports the logind API, even better, patches not even required.

[Aeder]

Lately it seems as if all of these anti-systemd groups are behaving like astroturfer campaigns. They repeat the same misinformation, they always cite vague reasons instead of going into detail, they all show a complete lack of deep understanding of how systemd works, a lot of times they are not that involved in the technical side of things, etc.

[GreatEmerald]

So yea, I'm back to working on those Debian cases, currently updating the end of case 3 (the cross-examination where Ian talks about policy):

http://aceattorney.sparklin.org/V6_Test/player.html?trial_id=58428

And the entirety of case 4:

http://aceattorney.sparklin.org/V6_Test/player.html?trial_id=60363