Originally posted by profoundWHALE
View Post
Announcement
Collapse
No announcement yet.
New Group Calls For Boycotting Systemd
Collapse
This topic is closed.
X
X
-
Originally posted by Ibidem View PostFirst, check out what runit can do before you thumb your nose at busybox too much.
Originally posted by Ibidem View PostSecond, capability bounding sets can prevent any descendents of a process from gaining a capability...but that's not really where the main problem is. Usually, someone triggers a bug in a process that's already running with the privileges they want.
"Linux capabilities" isn't a magic wand (see link here: http://0pointer.de/blog/projects/security.html ) . But it is useful nevertheless. The problem with Capabilities are they weren't used by eg. upstream projects. systemd have changed that; even though upstream projects haven't heard of the concept, distro maintainers can use it by simply editing the service files. So instead of relying on systemd administrators to harden each individual running process, a basic form of security comes bundled for free with the distro.
Originally posted by Ibidem View PostNonetheless, I might write a CLI tool to exec with bounding sets ("withcaps"), just because it seems interesting.
Originally posted by Ibidem View PostAnyhow, I tried building it...
Delete the configure test for ln --relative that autoconf insisted on sneaking in despite there being absolutely no use of it. I'm using Alpine Linux, so ln is the busybox implementation.
Install libcap-dev and gperf (why must I install gperf to compile this?)
Pass just about every disable option there is; it still checks for Python...
Try to build.
Disable a CFLAG that gcc doesn't like.
Now, try to build again.
# error: neither secure_getenv nor __secure_getenv are available.
That will be trivial to fix, if I just patch my libc:
Code:#include "libc.h" char * secure_getenv(const char *name) { return libc.secure ? 0 : getenv(name); }
There is also some difference when building systemd from git or from the tarball. The requirements can be found here: https://github.com/systemd/systemd
AFAIK, gperf generate uses the kernel headers to generate a keyboard list, but it shouldn't be a runtime requirement, only a build requirement.
Originally posted by Ibidem View PostAuto config of hot plugged devices?
eudev, mdev, nldev, hotplug2...
Launching of appropriate services when needed...isn't that what inetd does?
What you just described is systemd reimplementing a large number of features of other daemons as new daemons.
This link further explains the advantages of the systemd approach: http://0pointer.de/blog/projects/socket-activation.html
like:
"If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continously responsive. Not a single connection is lost during the upgrade."
Comment
-
Originally posted by psychoticmeow View PostI'm sorry, but what's wrong with writing like a normal person? Your posts are like some kind of brain virus, if I read to many of them I get a headache.
well.. if they are hard for you to read, it is not because of formatting
the only difference between my and regular formatting are, as pointed out, dots and capital letters
just subtract 32 from the first letter in a line and replace \n with ". " (hint: you can just XOR 32 to make a capital from lowercase)
reason are that i write as i speak, calmly (as tone is hard to read from letters)
as a bonus it exposes those who value formatting over substance (some of whom write and/or speak very... clearly(most of the time), but miss the point)
also shift sometimes gets stuck
do you want me to write simple english ?
tough luck, i actually like to use advanced features of a language (like double commas)
if there is something you do not understand, please do ask instead of being an asshat (and if you just don't like me for whatever reason, just note it if it burns you so much)
Comment
-
Okay, Lennart haters! What did you use when Ulrich Drepper was the maintainer of glibc? You could not use glibc, because maintainer was a dick. It probably was a lot of work to port all software to use a different libc. You should now start contribute to your favorite init. That way your $favoriteinitsystem might stay afloat.
Comment
-
Originally posted by interested View Post(x)inetd and systemd aren't completely overlapping. LP has a good discussion and comparison about both in these links, especially the second.
This link further explains the advantages of the systemd approach: http://0pointer.de/blog/projects/socket-activation.html
like:
"If a service is upgraded we can restart the service while keeping around its sockets, thus ensuring the service is continuously responsive. Not a single connection is lost during the upgrade."
Systemd does not actually know when or if a service needs another service, but it requires us to start services anyway and to hard-code their relationships into its configuration.
The added sugar of keeping sockets around is also questionable. Firstly, because any application using sockets needs to deal with broken sockets due to the nature of networks. It gives them a fault tolerance and systemd's feature is not something these would suddenly need. Secondly, it may not always be a good idea to keep a socket open during an upgrade, because systemd cannot know what is being upgraded and why, and so the feature can confuse the applications when it would have been better to close the socket. The feature can be a bonus, but only when it is being used knowingly. It cannot be used in general and is more likely to lead to worse implementations of services when these start to rely on this feature instead of keeping a degree of fault tolerance.
Comment
-
Originally posted by sdack View PostThe added sugar of keeping sockets around is also questionable. [snip]
Anyway, widespread industrial adoption of systemd exactly because of systemd's use of sockets to enable instantiated services says otherwise. With Systemd you can pack many more services into the same rackspace, saving money on both hardware, cooling and electricity.
Massive, rapid parallel deployment of services on demand is what systemd does so well. You can even use it for instantiated OS containers.
Like Linux, systemd is all about solving real world problems in a ever changing technological environment, as fast and easy as possible. This is why both projects are successful.
Comment
-
Originally posted by sdack View PostIf you like to admit it or not, but we are in the middle of it. You do take part in the discussion and this thread is only one of many. It shows people care even when trying not to
Originally posted by sdack View Postlike robclark above who is making an attempt at alienating users to resolve his problems.
I'm not entirely sure what libelous statements like that are hoping to achive.
To be clear here: I do not work on systemd or any project which directly uses it. I am simply a satisfied customer. I have used upstart, sysv init, and many years ago the old-school /etc/rc bsd stuff, and have had the opportinity to tinker w/ using each to start up random stuff at boot. And I've debugged 'em all too. I may even have a small patch in systemd to fix a bug I was hitting a year or two back with some rather odd hw (although technically, that was udev).
As an x/graphics/drm dev, I am thrilled that the "systemd cabal" is tackling some of the problems w/ VT and handover from login/dm to user X session (or wayland). If people really knew how that stuff worked originally, they surely wouldn't be saying "everything is peachy, why do we need to change".
What I'm less thrilled about is a vocal minority who wants to hold back development on fixing these and other issues simply becaues they do not understand them. Fortunately, it seems that decisions made by (at least the mainstream distros) are taken by people who actually understand some of these issues.
But, that said, if you really don't want to use systemd, then don't. It won't offend me. No one is holding a gun to your head. If your $distro_of_choice switches to systemd, stay on an older version.. or fork it.. or switch to a different distro. This isn't windows here.. you have all the src code you need. No one is stopping you.
Comment
-
Originally posted by interested View PostJeeze, now the use of sockets is being condemned because systemd uses it.
Anyway, widespread industrial adoption of systemd exactly because of systemd's use of sockets to enable instantiated services says otherwise. With Systemd you can pack many more services into the same rackspace, saving money on both hardware, cooling and electricity.
Massive, rapid parallel deployment of services on demand is what systemd does so well. You can even use it for instantiated OS containers.
Like Linux, systemd is all about solving real world problems in a ever changing technological environment, as fast and easy as possible. This is why both projects are successful.
The problem you fail to see is that while inetd was designed to break the relationships of services open, to force these into using fault tolerant designs and so that we can have flexible systems with few points of failures and without fail cascades, is systemd now going into the opposite direction and weaves the services together again and tries to fix what does not need fixing. What it leads to, if we let it, is to daemon processes, where we allow each to have their own design philosophy including opposing designs, designs with large dependencies and with no fault tolerance, because systemd is not actually helping here, but makes an attempt at "herding cats". Or only take yourself as an example. You already think we could use systemd to bloat the OS with more processes. And you are just one of the many more "cats" to come.
I do not think you have understood much of what is systemd is trying to fix and what it is failing at.Last edited by sdack; 06 September 2014, 08:56 AM.
Comment
-
Originally posted by sdack View PostNo. Sockets have been used for a long time and systemd does not make room for more services suddenly. All it does is to speed up the boot and shutdown times a little bit.
Comment
Comment