Debian To Seek A General Resolution Over Their Init System Policy

[pal666]

You are going to be hearing a LOT about MX, I can assure you, and not just from the DW fanboys. Move aside, Mint.

mint? what's that?

[pal666]

The opposite is true: The kernel maintainers invest a lot of effort to keep up a dependable, stable, predictable ABI for userspace software. And they succeeded very well in that.

you've got it backwars, kernel abi is not kernel's dependencies

Totally unlike systemd, whose maintainers could not care less about long term compatibility.

1) systemd maintainers care about it's compatibility, they'll support it in their respective distros
2) kernel has to be compatible with every program ever written because every program interfaces with kernel. systemd doesn't interface with most of programs, it only interfaces with system level stuff which can be fixed, unlike some proprietary blob with sources lost 20 years ago(which kernel has to still run)

Maybe, but if I have to choose between free open source software from the GNU or FreeBSD projects versus the self-proclaimed-god-given elaborates from the systemd maintainers, I choose the former any day.

well, your post wasn't very promising from the beginning, but now it's full imbecil mode. freebsd is more system than systemd. all of freebsd is written by one team in one repo like systemd and obviously it's never compatible between versions

[pal666]

No. For the vast majority of services, it has always been totally sufficient to create one symbolic link from the installed executable into some directory dedicated to the purpose of starting everything that is linked in there.

for systemd it's totally sufficient to put one line with path to service to unit file. but outside of your sandbox people want to give it proper description and maybe set some process attributes, so usually files are slightly larger. nobody implemented handling of symlink to executable as such one-line service file, probably because writing such file is no harder than making symlink anyway

[pal666]

Well i don't care what you think, i don't want systemd.

why should we care what you want?

Is Wayland wonderful? But i like X11, it works, period. I don't care, do not want.

time to become x11 maintainer then asap, nobody is going to maintain such beast just for few clueless people with loud mouths

Devuan a small group of ex-debian, and they have done what the mainstream distros with their legions of volunteers (and even employees) don't bother doing: Restore CHOICE.

liar, they've taken away our CHOICE to use systemd

[audir8]

And how is this in any way evidence for a "rat's nest of dependencies" and "you have to run the whole bloated mess" when this is just a utility (journald) using the cgroups functionality when being launched under systemd.

Did you even look at the patch you linked to? All it does is:

s->cgroup_root = strdup("");

When detecting that it's running without cgroups. You guys aren't even trying!

If you didn't think much of that patch, go up one directory to see what the 10 patches are to get a standalone journald-242 for Chrome OS: https://chromium.googlesource.com/ch...ournald/files/

The point is, someone at Google thought it was easier to maintain these OOT patches and get a standalone journald than to switch completely to systemd for Chrome OS. Chrome OS uses upstart still, and I doubt a single board/laptop maker ships Chrome OS with anything else. It also uses the original udev fork and has it's own session manager. Here are the updates made to upstart for Chome OS: https://chromium.googlesource.com/ch...s-apps/upstart

Contrary to other opinions in this thread, you can use a number of combinations of eudev, elogind, openrc, runit, and a few others to get a full-fleged Linux desktop still, and Chrome OS (with upstart) is regularly updated. We have seen systemd copy from udev in Chrome OS, and seen successfully maintained forks of elogind, eudev and journald. I think the ecosystem outside systemd is doing quite fine. Any and all of the friction would be gone if systemd made an attempt to re-integrate with these forks, because they aren't going anywhere.

The cloud developers love systemd, I get it, but reintegrating these forks would mean maybe 2-3 daemons talking over dbus (or something else) instead of 1 or 2 daemons, everyone still gets their unit files and can keep using whatever init/service/session/cgroup managers they want, and this forking of systemd stops along with the friction. Would it be that bad? I'm sure if systemd-homed is any good, it will be forked too if it doesn't work out of the box with elogind/openrc/etc...

[jason.oliveira]

Wow, have you noticed that it's always the pro-systemD astroturfers that try to get the last word on every thread about Lennart?

[L_A_G]

in case of wise men producing systemd, imbeciles cluelessly blame implementation, which they fail to understand "on purpose", just like write its name properly
rat nests, creep and legitimateness exist only in imagination of imbeciles
no, you have to prove your imbecilic claims
i already pointed out your imbecility, did it stop you?

Looks like that really hit home with the way you keep repeating a very low-effort insult after I threw it back at you.

Seriously thou, you're only making the quote more and more apt as you fail to actually address the criticisms that I brought forward and have just resorted repeating the same insult over and over again. You post 4 sentences and none of them contain anything more substantial than repeating the same insult.

But that is not examples, that is just you making wide claims akin to people watching a 10h presentation and just yelling "you are wrong!" before running out the door.

As I said before, I've presented you personally with the examples and at least once and you still act like there's nothing substantial there. You'd have a point if you were new to this forum and we hadn't had this discussion before, but we have had this discussion before and I have explained my criticisms to you personally. For you to continuing to insist I've never voiced those criticisms is even more farcical when I've explained the core of those criticisms in this very thread!

A more apt analogy would be a panel discussion where someone first makes a series of arguments, isn't disputed and when given the turn to speak again begins to build upon what they previously said only to be cut off by someone like you claiming that they never made their previous arguments. As if this is the first time they're speaking up when the person cutting them off was the person who the previous speaking term was directed at.

And how is logind an example of this cross-dependencies hypothesis of yours when systemd have exactly zero dependencies on logind?

The issues Gnome3 has had with supporting both loginD and alternatives go very much counter to this claim. Whey they integrated loginD it just became a huge hassle just to support eloginD, i.e a standalone fork of loginD. If there weren't any cross-dependency issues then eloginD would have been a drop-in replacement for loginD and a no-brainer for those who didn't want to use the rest of systemD, but it just turned into a huge maintenance hassle.

Once again wide sweeping allegations without any form of substantiation, point to a feature creep and how it created an attack surface and we can talk about it. Just arguing that because the systemd project gained another binary/utility the attack surface grew is disingenuous at best.

I may not have gone into detail on that, but it's basic knowledge that the more code you have doing more things, the more room there's going to be for mistakes in implementation and design. It's not just software, it's engineering in general where the unavoidable truth is that the larger and more complex a system is, the more room there's going to be for mistakes and the more likely it's going to be that mistakes will be made.

In other words you're denying basic engineering theory here. But hey, it's your Stalingrad...

So now pointing to some nasty replies to bug-reports is an analogue for "the implementation is botched". I'm sorry to be a Slashdot-asshole here but i don't think the word means what you think it means.

Do I really need to spell this out again like I'm talking to a very young child? Well alright then;

Making mistakes - Bad; Not listening to people trying to point them out so you can fix them - Worse!

Now do you get it? I hope this finally got the point trough because this is about as simply as I can put it.

[L_A_G]

There is no back and forth between systemd-logind and the layer below it nor the one above it. It's one layer in a stack that can be cleanly replaced, as repeatedly proven by now by alternative implementations.

The fact that it can be done doesn't actually prove anything other than just that; That it can be done. Never claimed that it couldn't be done, my issue is that the way systemD is implemented has made it unnecessarily difficult and time consuming to do so. The size of the additional additional maintenance burden is after all the reason why the Debian developers are talking about scrapping their efforts to support alternatives.

If it was as simple as you try to make it out to be then this discussion between Debian developers over the required effort being worth it just wouldn't be happening. Instead continued support would simply be a no-brainer. However because of the additional issues stemming from how systemD's roots all over the place are causing issues with alternatives they're having serious discussions over whether it's worth the large amount of hassle or not.

You are allowed to criticize for as long as you want. Be my guest. But for things to change somebody needs to put in the work. Neither of us here on Phoronix is going to do that, so no harm done in venting your frustration here:-)

As I told you already, this "Well you make something better then"-counter is just a completely non-productive attempt at trying to shut down criticism. It does absolutely nothing to disprove the criticism and merely tries to stop that criticism being potentially channeled into productive suggestions and improvements. Most people just don't have the time or energy to develop something as substantial as this in their free time on top of work, kids, hobbies and home life in general. However that doesn't mean that only the minority who do have the energy and spare time to do something as substantial as this in their spare time without the rest of their life suffering as a consequence.

E.g. logind provides a way to securely manage access to device nodes. Write a piece of software that does that by printing tokens in the printer that the user has to scan to actually access a device node, it does not matter. Any robust and workable solution will be picked up by developers, even those currently requiring systemd. They have no other options, so they must use systemd.

Again, the argument was never about what systemD and its modules are trying to achieve, but how they're trying to achieve their goals. Much of the reason why there are so few actively developed alternatives to various systemD components is the effort required to maintain them and anything that relies on them. This headache is in turn largely caused by how systemD has been implemented.

In essence this is the open source equivalent of "Embrace; Extend; Extinguish". First you make something useful, then you make it so that it's a huge headache to support any alternatives to achieve the same job, then everyone drops those alternatives because of how much additional work it is to support them. Right now the Debian developers are going discussing the "extinguish" step of the process.

[F.Ultra]

As I said before, I've presented you personally with the examples and at least once and you still act like there's nothing substantial there. You'd have a point if you were new to this forum and we hadn't had this discussion before, but we have had this discussion before and I have explained my criticisms to you personally. For you to continuing to insist I've never voiced those criticisms is even more farcical when I've explained the core of those criticisms in this very thread!

A more apt analogy would be a panel discussion where someone first makes a series of arguments, isn't disputed and when given the turn to speak again begins to build upon what they previously said only to be cut off by someone like you claiming that they never made their previous arguments. As if this is the first time they're speaking up when the person cutting them off was the person who the previous speaking term was directed at.

Could you provide a link to that discussion? I've gone over my posts for over one year back (huge thanks for having me waste a portion of my weekend) and the only ones that I could find from you to me is your constant "there is a rat's nest of dependencies" without any further explanation or detail. Your recent post about logind was the only example that I could find.

The issues Gnome3 has had with supporting both loginD and alternatives go very much counter to this claim. Whey they integrated loginD it just became a huge hassle just to support eloginD, i.e a standalone fork of loginD. If there weren't any cross-dependency issues then eloginD would have been a drop-in replacement for loginD and a no-brainer for those who didn't want to use the rest of systemD, but it just turned into a huge maintenance hassle.

You cannot redefine the word "cross-dependency" and then make claims about it! Point to a single instance in systemd where the pid 1 binary of systemd have any dependency on logind what so ever.

In fact I just now booted up a copy of CentOS7 in Virtualbox, removed /lib/systemd/systemd-logind, rebooted and it booted up just fine to a console. So the only way that your idea can work is if you redefine cross-dependency to be something else than what it is.

I may not have gone into detail on that, but it's basic knowledge that the more code you have doing more things, the more room there's going to be for mistakes in implementation and design. It's not just software, it's engineering in general where the unavoidable truth is that the larger and more complex a system is, the more room there's going to be for mistakes and the more likely it's going to be that mistakes will be made.

In other words you're denying basic engineering theory here. But hey, it's your Stalingrad...

More code leads to higher chances of bugs yes, but you are arguing that the systemd project bringing in more utilities to their repository somehow increases the security of systemd running as pid 1. Now that might not be what you are trying to argue but that is how you comes across.

Do I really need to spell this out again like I'm talking to a very young child? Well alright then;

Making mistakes - Bad; Not listening to people trying to point them out so you can fix them - Worse!

Now do you get it? I hope this finally got the point trough because this is about as simply as I can put it.

Still not an analogue to "the implementation is botched". The (claimed) behaviour when replying to bug-reports is not and can not be seen as comparable to the implementation of a piece of software.

Ignoring your ad hominem yet again, every one understood from day one that you mean that the behaviour of the replies to the bug reports reflect badly upon the software project. And no one is arguing against you there, however it is still have nothing, as an analogue or not, to do with "the implementation is botched" which was what we where discussing. You specifically pointed to the implementation, and I asked you specifically regarding the implementation.

[F.Ultra]

Wow, have you noticed that it's always the pro-systemD astroturfers that try to get the last word on every thread about Lennart?

Astroturfer? Have words lost their meaning completely nowadays?

So if we don't reply then it's because we cannot provide any arguments and if we do reply then we are trying to get the last word. Yeah that isn't disingenuous in any way or form...