Systemd Continues Getting Bigger, Almost At 550k Lines Of Code

[prodigy_]

Fuck off troll. How have you not been banned because of your constant shit posting?

Because I'm the voice of truth and reason. But don't you worry it's a quiet voice that you can easily suppress mindlessly chanting "go systemd!" or something like that.

[psychoticmeow]

Because I'm the voice of truth and reason. But don't you worry it's a quiet voice that you can easily suppress mindlessly chanting "go systemd!" or something like that.

Are you familiar with the idea of a logical fallacy? Almost every argument you make, on any subject is one, so it's impossible to take you seriously.

[prodigy_]

so it's impossible to take you seriously.

Oh, this doesn't overly bother me. I abandoned all hope of ever having a serious and productive discussion with systemd proponents long ago. You don't want to hear our arguments, you don't want to admit that any point of view can exist other than "systemd is great" and your overall approach usually exposes you as either ignorant kids or paid Red Hat shills right away. You, my friend, are the former.

[psychoticmeow]

Oh, this doesn't overly bother me. I abandoned all hope of ever having a serious and productive discussion with systemd proponents long ago. You don't want to hear our arguments, you don't want to admit that any point of view can exist other than "systemd is great" and your overall approach usually exposes you as either ignorant kids or paid Red Hat shills right away. You, my friend, are the former.

See: logical fallacy.

[chrisb]

Highly *unlikely*, in my opinion. There's certainly interest in doing an app-based model, a lot of talk about it, but as far as I can see, it's all at the "wouldn't this be cool?" stage... no actual work, or clear ideas of how to implement.

Why is it highly unlikely to happen? You think Poettering does not know what he is talking about, that he will fail? Or change his mind? Or that the Gnome Foundation will reject his work?

Sandboxed applications for GNOME

Currently, shipping applications for GNOME is hard. You have to deal with a multitude of distributions, with numerous different library versions and patch levels. API stability is weak, and getting things tested sufficiently against this all is difficult. To get your application into the hands of the users you have to convince the distributions to package it.

Currently, downloading and running applications for GNOME is cumbersome and potentially dangerous. You have to find the application pre-built for your distribution and architecture in the right version, and when you run it you need to trust the author or distributor that the code is safe and doesn't contain backdoors or trojan horses, as applications run at full privileges of your user.

Other Operating Systems feature app sandboxes that isolate the applications from the OS and provide greater security, manageability and API stability this way. We want the same for Linux and GNOME, to make it easier both to ship and consume GNOME applications. This talk will introduce you to our plans to implement this for Linux and GNOME, within the systemd project. We'll talk about the steps required to get there, ranging from kernel and plumbing layer issues, to GNOME platform changes all the way to what this means for GNOME applications.

Poettering knows how to implement it, and has a clear multi-stage plan that he is already working on. That's the exact opposite of "no actual work, or clear ideas of how to implement".

[prodigy_]

I heard Windows 8.1 is great. You should try it since it has all figured out for the user and it's generally a great PnP experience, no coding or compiling required.

Oh it's really funny how you sarcastically suggest that a Gentoo user should move to Windows when Gentoo is about the only major distro not yet completely overwhelmed by the windowisation trend.

[JX8p]

It does do the bare minimum in PID 1, just because you think it should do less does not mean that it can do less in PID 1.

I maintain a branch of the Runit process supervision system, to which I've been enhancing it to allow it to act as a complete service manager that can replace rc.d/init.d. PID 1 is 350 lines of code. It has few functions: it must handle signals, reap zombies, start the service scanner (which itself starts supervisers for services, who start the services - see how we avoid putting too much functionality in one process?), and poweroff the system on request. Anything else is extraneous.

[prodigy_]

Poettering knows

Yeah. He'll code them good.

[BeardedGNUFreak]

Thank god I've long since dumped Linux and switched my personal and work machines to FreeBSD.

The systemd clusterf*ck is something I am enjoying watching from a safe distance.

The Linux 'community' is nothing more than an entity that maximizes idiotic decisions. The only reason systemd exists is that the Linux community is unable to come up with anything worse.

The best part of the Linux systemd fiasco is knowing just how hilarious the cries of pain are going to be when it comes time to rip it out. And listening to the shouts of 'who is responsible for this mess???'

Congrats to the systemd developers, they've managed to come up with something that rivals one of the all time greatest operating system software engineering disasters of all time. The Windows Registry.

[Gusar]

That's how it was marketed in the first place: "fast boot times!"

No, it wasn't. Fast boot times are just a consequence of its design, the systemd devs did not create it with the explicit goal of bringing down boot times. Maybe "fast boot times" is all you ever saw, because all the technical stuff about init systems in general, and systemd in particular, went over your head. Which you demonstrated quite well by saying that networking is supposedly in systemd itself, rather than in a separate daemon.

by the gigantic ego of its creator.

And again with the personal attacks. Why do you think this will somehow make you more credible?

Who will maintain each and every little program and library used by systemd? Who will make sure there are no vulnerabilities?

Who maintains all the other libraries used on a typical Linux distro? Who makes sure there are no vulnerabilities in the kernel, in X, in web browsers, in web servers? Developers of these libraries and apps of course, and the wider community, and companies using these libraries/apps. No different with systemd.

How do those processes communicate?

Via dbus or via API calls. Like many other apps too.

Does the network service talk directly to a critical process that is running as root?

Networking *always* involves root, whether it's handled by networkd, NetworkManager, Connman or something else. That's because changing network settings is a privileged operation.

MANY things can go wrong, and you would be surprised at how advanced are the techniques used to exploit software these days... have in mind that a 0day exploit in the black market for, say, flash, sells for $50k++. Imagine how much would a linux/systemd root exploit cost...

Many things can go wrong with the kernel or a web browser, or a web server. The kernel is big and complex. As are web browsers (the on-disk footprint of Firefox has tripled in the last few years, Chromium has an even larger footprint), as are some web servers (there are lightweight web servers, but then there's monsters like Apache). And yet the world hasn't ended yet. Taking as if it'll be exactly systemd that causes an end of the world is ridiculous.

Systemd fanboys [...] their fantasies

Because I'm the voice of truth and reason.

Wow! Just... wow!

I abandoned all hope of ever having a serious and productive discussion with systemd proponents long ago.

Going by the above, it's doubtful you ever even attempted a serious and productive discussion.

You don't want to hear our arguments

If you had good technical arguments and presented them in a good manner, I'm sure people would be open to them. But as can be seen extremely well in this thread, all you and many other systemd detractors have is cheap pot shots and personal attacks.