Originally posted by elatllat
View Post
Announcement
Collapse
No announcement yet.
Systemd In Ten Years Has Redefined The Linux Landscape
Collapse
X
-
Originally posted by Spam View Postsystemd is no saviour. For those that claim that is just a collection of separate applications that work together should take another look how difficult it was to get logind to work stand-alone from systemd in order to use Gnome with OpenRC.
On the topic of systemd is also a post here https://forums.gentoo.org/viewtopic-...ighlight-.html
Code:---------------------------------------------------------------------------------------------------------------- | |systemd |s6/s6-rc | |--------------------------------------------------------------------------------------------------------------| |Simple service definition |Perhaps yes, but with lots of gotchas [b] |Yes, by chainloading [a] | |Support for cgroups |Yes, hardcoded in init |Doable, in better ways [d] | |"Socket activation" |Yes |Yes, by fd holding [a] | |Service logging [c] |Inefficient, SPOF, binary logs |Efficient, reliable, textual logs | |Separate /usr |Unsupported, for questionable reasons [1] |Supported | |Portability |Only Linux with glibc |Linux (with glibc, musl, ...), BSD, ... | |--------------------------------------------------------------------------------------------------------------| |Speed ([b] for all below) |Hangs that are hard to predict |Consistently fast | |Simplicity |Big, very complex due to tight coupling |Tiny, loosely coupled | |Reliability |Easy to begin, but with lots of gotchas |Easy to learn and predictable | |Maintainability |Number of unresolved bugs growing quickly |Very few bugs, resolved quickly | |Flexibility |Hardly extensible, components unreusable |Easily extensible, components reusable | |Security |Many vulnerabilities |Few (if any) vulnerabilities | |--------------------------------------------------------------------------------------------------------------| |[a-d] See the "Basic background", "Quality", "Logging" and "Linux cgroups" parts below, respectively. | |[1] <https://forums.gentoo.org/viewtopic-p-8354032.html#8354032>. | ----------------------------------------------------------------------------------------------------------------
- Likes 1
Leave a comment:
-
Originally posted by Spam View Postsystemd is no saviour. For those that claim that is just a collection of separate applications that work together should take another look how difficult it was to get logind to work stand-alone from systemd in order to use Gnome with OpenRC.
Originally posted by Spam View PostOn the topic of systemd is also a post here
Originally posted by Spam View PostService logging [c] |Inefficient, SPOF, binary logs |Efficient, reliable, textual logs
This is from 2016 when someone decide to see how much of a diet systemd can be put on if you are serous about it.
Funny enough journald is a optional part if you are building up from source. So if systemd got a few patches to add a runtime option to disable journald it could run without it on normal distributions as well.
Also 2016 people also worked out that it was possible to turn journald off when it was built in. You had to setup replacement right so everything was collected as it need to be instead of disappearing into the never to be seen again void or triggering journald to socket activate..
To collect from all the logging sockets and get to textual logs be it s6/s6-rc sysvinit or systemd you have to run something that is a SPOF be it a program like rsyslog or systemd journald. Yet here in 2019 referencing that this is a difference. It was documented in 2016 that this is not in fact a difference. Documentation to setup replacement to journald is kind of not well known.
So the logging difference is myth. Systemd gets little upset if you have not set your logging right where s6/s6-rc will ignore the problem and losing your logging information to the void of no return.
Yes that write up referenced 2013 bug to make point things do change over time. Basically it was 2016 when embedded developer look close and found out the journald requirement of systemd was basically myth. Lot of ways the way Logging has been done on Unix and Linux these days really need to go completely back to the drawing board to reduce the SPOF risk.
Originally posted by Spam View PostSupport for cgroups |Yes, hardcoded in init |Doable, in better ways
A more important use of cgroups in systemd is to track the process trees of services, in order to deal with orphan processes of badly written service programs after the main service process exits, and to deal with services that do not support non-fork()ing execution.
To handle unruly services, a cgroup-based babysitter program can be written to fork()/exec() the given service process in the specified cgroup. If the service supports non-fork()ing execution, the babysitter then waits for its child (the main service process) to exit, kills processes remaining in the cgroup, and then exits; if not, the babysitter then waits for the cgroup to be empty, and then exits. As far as I know such a program is not yet implemented, but I believe that I have outlined enough above for a practical implementation of the requirement, and that such a program will be available soon if enough people seriously demand it.
cgroup started of with one idea and with cgroupv2 and its adding features it being expand to-do the unruly services stuff better. Including apply bpf filter over a cgroup so everything inside cannot get out even if it has root privilege. Cgroups did not start designed as an item to handle unruly services but is very quickly coming the best tool for the job.
Originally posted by Spam View PostSimple service definition |Perhaps yes, but with lots of gotchas [b] |Yes, by chainloading [a]
Originally posted by Spam View PostSeparate /usr |Unsupported, for questionable reasons [1] |Supported
Originally posted by Spam View PostPortability |Only Linux with glibc |Linux (with glibc, musl, ...), BSD, ...
Originally posted by Spam View PostSpeed ([b] for all below) |Hangs that are hard to predict |Consistently fast
Originally posted by Spam View PostSimplicity |Big, very complex due to tight coupling |Tiny, loosely coupled
Originally posted by Spam View PostReliability |Easy to begin, but with lots of gotchas |Easy to learn and predictable
Originally posted by Spam View PostMaintainability |Number of unresolved bugs growing quickly |Very few bugs, resolved quickly
Security |Many vulnerabilities |Few (if any) vulnerabilities
Originally posted by Spam View PostFlexibility |Hardly extensible, components unreusable |Easily extensible, components reusable
Notice out of all those point only 2 turned out to be somewhat true.
I would like to see decent competitor to systemd but s6 at this stage absolutely is not it. Yes we have a big problem of people not understanding that cgroup usage is basically not an optional feature if you want everything to work the best it can with the Linux kernel.
- Likes 1
Leave a comment:
-
systemd is no saviour. For those that claim that is just a collection of separate applications that work together should take another look how difficult it was to get logind to work stand-alone from systemd in order to use Gnome with OpenRC.
On the topic of systemd is also a post here https://forums.gentoo.org/viewtopic-...ighlight-.html
Code:---------------------------------------------------------------------------------------------------------------- | |systemd |s6/s6-rc | |--------------------------------------------------------------------------------------------------------------| |Simple service definition |Perhaps yes, but with lots of gotchas [b] |Yes, by chainloading [a] | |Support for cgroups |Yes, hardcoded in init |Doable, in better ways [d] | |"Socket activation" |Yes |Yes, by fd holding [a] | |Service logging [c] |Inefficient, SPOF, binary logs |Efficient, reliable, textual logs | |Separate /usr |Unsupported, for questionable reasons [1] |Supported | |Portability |Only Linux with glibc |Linux (with glibc, musl, ...), BSD, ... | |--------------------------------------------------------------------------------------------------------------| |Speed ([b] for all below) |Hangs that are hard to predict |Consistently fast | |Simplicity |Big, very complex due to tight coupling |Tiny, loosely coupled | |Reliability |Easy to begin, but with lots of gotchas |Easy to learn and predictable | |Maintainability |Number of unresolved bugs growing quickly |Very few bugs, resolved quickly | |Flexibility |Hardly extensible, components unreusable |Easily extensible, components reusable | |Security |Many vulnerabilities |Few (if any) vulnerabilities | |--------------------------------------------------------------------------------------------------------------| |[a-d] See the "Basic background", "Quality", "Logging" and "Linux cgroups" parts below, respectively. | |[1] <https://forums.gentoo.org/viewtopic-p-8354032.html#8354032>. | ----------------------------------------------------------------------------------------------------------------
- Likes 1
Leave a comment:
-
Originally posted by fsfhfc2018 View PostYou also accused me of not caring about such things before systemd existed, when we didn't know each other at the time. So on top of calling your post twaddle I'm going to say it's dishonest twaddle, and my respect for you has evaporated entirely. Of course I don't expect you to care. I've more or less said you're full of crap, and if not for shills like yourself, systemd wouldn't have come along this far.
I have been around the Linux online world from 2000 before systemd basically no one really talked about the problem or if they did really did not understand the problem.
I might be wrong about you but most people who bring up that arguement are not aware of the realities.
There were people before systemd who did argue against the sysvinit related projects being put under 1 project on the false believe this would give redhat more corporate control than they already had.
Originally posted by yoshi314 View Posti am not a fan of systemd being a kitchen sink project that it is nowadays, but they introduced some improvements that straightened out issues that nearly every distro swept under the rug:
Reality here is systemd being kitchen sink has cleaned up that by in fact making the kitchen sink nicely clearly visible. Reality here is sysvinit was really like a kitchen sink over filled with plates what are projects random-ally stacked and the kitchen sink barely visable to the outside observer who is not the kitchen sink redhat but appears perfectly ordered to the redhat side and 100 percent in the kitchen sink.
Basically systemd single project move in fact gets everyone on a level footing.
Originally posted by yoshi314 View Post- how does one provide an universal distro-agnostic init script for a software project?
So its not how do we provide universal distro-agnostic init scripts as this was in fact kind of worked out before systemd it was more how do we stop distributions adding unique one off bugs to their init and service management process. Yes distributions having their maintainers having to reverse what was the right mix of parts to put together was the biggest cause of unique one off distributions bugs in the init and service management process. Fixing this in fact freed up resources to go after some other problems.
The systemd kitchen sink is in fact one of the true big improvements. Systemd kitchen sink makes it clear where the kitchensink is. This also shows how much you really need to implement to make a init/service management solution that work correctly of course this is a lot larger than a lot of people before systemd attempt to implement to replace sysvinit and failed.
Yes this is another one of the biggest complaint about systemd as well that to make a replacement init/service management solution is going to be harder since systemd is now a kitchen sink instead of the prior multi plates. Reality is no harder now if you want working. There were a lot of attempts that just produced not practically usable init and service management options because they were not implementing anywhere near enough.
Leave a comment:
-
Originally posted by fsfhfc2018 View Post
Not wanting a corporate monoculture to take over has nothing to do with "spite."
i am not a fan of systemd being a kitchen sink project that it is nowadays, but they introduced some improvements that straightened out issues that nearly every distro swept under the rug:
- where do we keep volatile files?
- how does one provide an universal distro-agnostic init script for a software project?
- how to manage resources for services?
- how to check service status along with its most recent logs (if you have no idea where it is logging to)?
there are many better and lesser known issues that systemd inspired others to solve in the meantime. and not just that project benefited from it. i still think the authors pushed their weight around a bit too much (especially with kdbus attempt), but i think - all things considered - it turned out for the best.Last edited by yoshi314; 27 December 2019, 09:47 AM.
- Likes 1
Leave a comment:
-
Originally posted by oiaohm View PostFinally being spiteful over the fact we have a corporate monoculture problem does not help anything. Its not good grounds to be anti-systemd as it really not offering anything better/more useful.
You also accused me of not caring about such things before systemd existed, when we didn't know each other at the time. So on top of calling your post twaddle I'm going to say it's dishonest twaddle, and my respect for you has evaporated entirely. Of course I don't expect you to care. I've more or less said you're full of crap, and if not for shills like yourself, systemd wouldn't have come along this far.
Maybe you think it's reasonable to use something based on some touted (circular) technical merit despite being a complete horror supported by shills, but for me-- that's the exact opposite of what I signed up for.
I bid you and the other sophists on this horrifically designed forum adieu. There are some good posters here, I can't stand the lying and drivel and won't abide the trolling from people like yourself. Even someone who sculpts Disney characters out of turds for a living has got better things to do.
Leave a comment:
-
Originally posted by fsfhfc2018 View PostNot wanting a corporate monoculture to take over has nothing to do with "spite."
It could be ignored while they appear to be a stack of independent projects that were really not independent when you would find consolekit would need udev of a particular version and that would depend on something sysvinit setup with selinux... and so on. Yes the mess before systemd even that they appeared independent projects were quite highly bound to each other so did not really operate independent because the development was basically done in house at redhat.
Corporate monoculture was done before 2001. For some reason you only get upset now.
That right Redhat decide to merge all the parts they had under their absolute control under one project called systemd. So corporate monoculture take over was complete before systemd exists.
You have spite a corporate has so much control now that you can see it. It really spiteful because you don't really understand the facts of where we are. You don't want to have to admit we had lost the corporate monoculture arguement before systemd came into existence and yes it was lost well and truly before the year 2000 and nothing since then appeared to change that fact.
Now if you really want to break this monoculture some how a group has to make something more useful than the combination systemd is. Running back to sysvinit and other old and broken will not help this.
Also making up false claims about systemd does not help.
Finally being spiteful over the fact we have a corporate monoculture problem does not help anything. Its not good grounds to be anti-systemd as it really not offering anything better/more useful.
Failing to see the stuff that needs to happen for future init systems is not helping either.
Like recently we finally got work so you can directly start a process in a cgroup. We have pidfd and other things. The frameworks at kernel level are starting come along to be able to make a really good service management solution.
- Likes 1
Leave a comment:
-
Originally posted by yoshi314 View Postout of spite.
- Likes 1
Leave a comment:
Leave a comment: