Originally posted by asdfblah
View Post
Announcement
Collapse
No announcement yet.
Systemd Continues Getting Bigger, Almost At 550k Lines Of Code
Collapse
X
-
Originally posted by asdfblah View PostFor me, as a user, Linux is about diversity. If I don't like something, I use an alternative. It's not a "choice" but a real choice. Now, if you are telling me that I will be forced to use systemd, because the applications I like depend on it and won't work without it, then THAT is a "choice", an illusion of choice from those who defend something. That's what prodigy_ meant with "Windowisation", I think: you have "alternatives", but they are not real alternatives.
Comment
-
Originally posted by asdfblah View PostHave you ever heard the concept of "Attack Surface"? here you can read about it: http://en.wikipedia.org/wiki/Attack_surface
A system deamon that has lots of features, runs as system process, and has its own built-in network services is a intruder's wet dream.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by Gusar View PostBy making it all about boot times, as if that's all systemd has to offer, your argument loses a lot of merit. It loses even more merit by your attack on Lennart.
Making cheap pot shots will not stop distros and DEs from adopting systemd.
Well, it's good then that systemd does not have built-in network services. networkd is a separate daemon, it's not in PID1. PID1 basically just contains the service manager, which includes cgroup handling. The rest is outside PID1.
Another priviledged process is udev (systemd-udevd
Comment
-
Originally posted by asdfblah View Post[Mega post]
Originally posted by Jonathon CorbortThis announcement caused a bit of surprise and concern for those who didn't know it was coming. Lennart's work with PulseAudio remains a bit of a difficult memory for some users (though it seems to be working well for most people now), and some people had thought that the initialization problem was solved with the growing adoption of upstart.
Originally posted by Jonathon CorbortBeyond that, though, some people have concerns about the use of cgroups in the first place. Peter Zijlstra worries about adding yet another feature which must be built into the kernel for the system to even boot. The Debian community does not like the use of the "debug" group, which is not currently configured into its kernels. Systemd may eventually get a more appropriately-named cgroup subsystem for its use, but it is not going to work without the cgroup feature at all. So people wanting to boot systems with systemd will need to have cgroups built in. Lennart has this message for people who don't like that:
Originally posted by LennartNext time something is added to the kernel please mark it as "Hey, please don't use it, this is only here so that you don't use it. Thanks!" Maybe then dumb-ass folks like me will notice and refrain from using it.All opinions are my own not those of my employer if you know who they are.
Comment
-
Originally posted by Gusar View PostBy making it all about boot times, as if that's all systemd has to offer, your argument loses a lot of merit. It loses even more merit by your attack on Lennart.
Making cheap pot shots will not stop distros and DEs from adopting systemd.
Well, it's good then that systemd does not have built-in network services. networkd is a separate daemon, it's not in PID1. PID1 basically just contains the service manager, which includes cgroup handling. The rest is outside PID1.
Another priviledged process is udev (systemd-udevd), and that's a whopping 1.5KB.
Linux is in lucky to have such a nicely architected process managment system.
Comment
-
Originally posted by Ericg View PostI have heard of attack surface... do you know how to read? How many times has it been said on here, on blogs, on mailing lists, and god knows where else, that the only thing that runs as pid 1 is the service manager? Everything else is its own binary with its own permissions.
Can you be anymore snarky? Having the service manager in PID 1 is still too much. Ugh this is the hard part to explain - PID 1 should only contain the init binary and the role of killing process zombies. Having anything else on there, it's like putting up an rlogin server against the web with no kerberos and allowing root to login remotely. Init should start up the system, setup the core processes and then in a separate binary and process ID should be the service manager.
Let me give you a real world example. I had a desktop running Arch. I was running a lot of programs at once at high load to my system, this included KDE, Tomahawk, Xnp2, Firefox with about 20 tabs htop and Thunderbird. I had recently upgraded to systemd after months of holding off and boy was I in for a surprise. After running all of this for a bit, my system hung, X died then I was back at my TTY I had logged into. Except I couldn't do ANYTHING. That's when I learned systemd had crashed. Seriously, I had been running stuff like this for months then all of the sudden my machine became unstable at high load. I rebooted with a hard reset, and all went back to normal, except it happened again and again at random. Systemd just decided to lock up and make me reboot. So I began moving my resources away from Linux distros that either committed to or had already switched to systemd. FreeBSD has been great since and since then I ditched KDE for Enlightenment so overall I had a net gain as E17 is BSD licensed.
Comment
-
Originally posted by interested View Postsystemd is in fact very modular, besides the well documented compile time options, there is even info on how to reduce it even further in size by removing features:
Systemd is the best thing that have happened to Linux for a very long time. It is really good stuff, with good code, good documentation, good leadership, great many developers.
Systemd? Remains to be seen IMO. My computers are not doing anything today that they weren't doing 4 years ago. Are they doing anything *better*? i'm not sure about that. At least systemd is free and open source, I'll say that for it.
Comment
-
Originally posted by pingufunkybeat View PostThank you all for detailed responses.
I understand why systemd is useful for login managers and starting the environment. I still think they should be soft dependency, but here the integration makes perfect sense.
The previous poster strongly suggested that classic GNOME apps would refuse to run without systemd, and that seems ridiculous.
Originally posted by Delgarde View PostAn *application* shouldn't, in most cases, and I think it unlikely that Gnome apps will start depending on systemd
Comment
-
Comment