| View previous topic :: View next topic |
| Do you want systemd as default on Gentoo? |
| I <3 systemd!! I want Gentoo to switch!! |
|
12% |
[ 26 ] |
| Get that horse-crap away from Gentoo as far as possible! |
|
87% |
[ 186 ] |
|
| Total Votes : 212 |
|
| Author |
Message |
Dorsai!
Apprentice
Joined: 27 Jul 2008
Posts: 285
Location: Bavaria
|
 Posted: Wed Oct 08, 2014 5:54 am Post subject: |
 |
|
| 10w.st wrote: | | creaker wrote: | | just front-man for real decision-makers |
I agree. This is why I compare him to a train driver, and not a cab driver. |
I don't think that is entirely correct.
I think Poettering is making many design decisions by himself. Conspiracy theories aside, Red Hat is probably just telling him to "Do whatever it takes to make Linux userspace subsystems more robust and easy", which he is interpreting in his own special LP way.
They said "Linux", so fuck BSD and Solaris by interlocking it as tightly with the Linux kernel as possible.
They said "robust" so make it as solid a blob as possible and make every modularization impossible.
They said "easy" so let it do exactly what we (Red Hat) need and nothing more, all further bugreports and feature requests being closed, distros can either do what we (Red Hat) do or fend for themselves.
Sadly this is not Unix's "Do one thing well" anymore but "Do a thousand things well enough for Red Hat". |
|
| Back to top |
|
 |
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Oct 08, 2014 5:58 am Post subject: |
|
|
| Dorsai! wrote: | | Sadly this is not Unix's "Do one thing well" anymore but "Do a thousand things well enough for Red Hat". |
I am not convinced whether Redhat is really so happy with his work. After all, the software is just bad (how could it be different, if the underlying concept is completely broken?) |
|
| Back to top |
|
|
Dorsai!
Apprentice
Joined: 27 Jul 2008
Posts: 285
Location: Bavaria
|
| Posted: Wed Oct 08, 2014 6:05 am Post subject: |
|
|
From the standpoint of the major mainstream binary distributions the quality must seem well enough. Debian switched after all (with some teeth grinding though but that had other reasons).
If it just were bad Software most independent Distros wouldn't have switched. It's much more dangerous than just being bad software. Its good enough software with a dangerous philosophy behind it. Like Microsoft or Apple, but just right in the heart of the Linux ecosystem.
The problems and Instabilities a Gentoo user might experience may be due to systemd never having been meant as an optional system. |
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Wed Oct 08, 2014 6:21 am Post subject: |
|
|
| mv wrote: |
I am not convinced whether Redhat is really so happy with his work. After all, the software is just bad (how could it be different, if the underlying concept is completely broken?) |
this software is bad from your and my point of view. But from RH (and contributors) point this software just fine. Because their goals do not coincide with our goals. |
|
| Back to top |
|
|
happosai
n00b
Joined: 17 Aug 2005
Posts: 43
|
| Posted: Wed Oct 08, 2014 6:26 am Post subject: |
|
|
| creaker wrote: | | mv wrote: |
I am not convinced whether Redhat is really so happy with his work. After all, the software is just bad (how could it be different, if the underlying concept is completely broken?) |
this software is bad from your and my point of view. But from RH (and contributors) point this software just fine. Because their goals do not coincide with our goals. |
Right, all that Red Hat does really care about is
a) we have control about the dev, so we have control about the code and he does what we want,
b) it works and does not produce too much support calls from disgruntled customers.
That's all that Red Hat does care about. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Oct 08, 2014 6:26 am Post subject: |
|
|
| creaker wrote: | | this software is bad from your and my point of view. But from RH (and contributors) point this software just fine. Because their goals do not coincide with our. |
Of course, nobody knows for sure. However, I cannot imagine that they really consider it great to provide broken software: It will hurt them in the long run if people prefer to switch to more reliable and more secure systems; even windows is more reliable then systemd+*kit. Maybe not everybody does see this know, but people will, and system administrators will switch. |
|
| Back to top |
|
|
10w.st
n00b
Joined: 03 Jul 2014
Posts: 12
|
| Posted: Wed Oct 08, 2014 6:30 am Post subject: |
|
|
| mv wrote: |
Your picture couldn't be more wrong: It's not that systemd built organized tracks which, if you follow the "rules", make everything work well, quite the opposite.
The opposite picture is right: There were well-working tracks which caused no problem. Occassionally, they need some small repairing, but that's it.
What systemd did was to destroy all the tracks and let all trains go whenever they want in the direction they want, completely unorganized: You have a complete chaos which nobody can fully understand and which on some days works without accident and on other doesn't. Whenever some accidents have happened they build some signs "be careful here", but there are so many places accidents can happen that this is a never-ending job.
|
My point is that his tracks are built right next to my house. (I had used suse base to build my systems for a long time)
Even though I prefer walking or driving motocross, the train company now insist that I must use the train, or get squashed.
This is something I will not accept, that's why I post here. Because you guys don't insist on anything of the sort.
And you do make a good description of the chaos it caused, by removing the tracks and letting the trains float around aimlessly.
I just thought of multiple trains (daemons) using the same tracks at the same time, which defies the laws of physics.
This bothers me to no end, because daemon1 sometimes starts before daemon0 and sometimes starts after.
Why systemd cannot run as PID-128 instead of PID-1 is beyond me. It would make this mess much easier to handle. |
|
| Back to top |
|
|
happosai
n00b
Joined: 17 Aug 2005
Posts: 43
|
| Posted: Wed Oct 08, 2014 6:54 am Post subject: |
|
|
We've got some Debian news, even comes with some nice conspiracy theory! Source: https://lkml.org/lkml/2014/10/7/254
| Code: | > A few days ago the Debian administration ruled out any use of a systemd "substitute"
>(cancelling its own systemd-shim project for desktop users) and now requires systemd whole
>hog.
We knew that would happen. Accommodations are only a temporary
stratagem with the systemd people. They are out to conquer. They need
to be stopped, halted.
There has been no General Resolution amongst debian package maintainers.
Red Hat has instituted a regulatory capture of the "bug squashing" committee
within debian (the "Technical Committee") by having current or former (but
stock holding) employees moonlight in debian and gradually gain membership
in that comittie.
Once their numbers were sufficient they proceeded to file a bug report on
the fact that systemd was not standard in debian.
This is illicit abuse of process and they need to be prosecuted.
Debian is an unincorporated association. It has bylaws, trade
practices, and dealings
by which it was governed. The RedHat associated members of the
Technical Committee have illegally and in bad faith abused their
positions in-order to
realize financial and strategic gain for their employer. |
|
|
| Back to top |
|
|
creaker
l33t
Joined: 14 Jul 2012
Posts: 651
|
| Posted: Wed Oct 08, 2014 7:05 am Post subject: |
|
|
| happosai wrote: |
a) we have control about the dev, so we have control about the code and he does what we want,
b) it works and does not produce too much support calls from disgruntled customers.
That's all that Red Hat does care about. |
If it isn't an irony then seems you are looking into the same distorting mirror that RH looks.
| mv wrote: | | However, I cannot imagine that they really consider it great to provide broken software: It will hurt them in the long run if people prefer to switch to more reliable and more secure systems; even windows is more reliable then systemd+*kit |
This software is bad not due to programming errors and even not due to conceptual mistakes. Eventually code errors will be fixed. Conception will be smoothed so as not to annoy the traditional unix user. But goals will not be changed. Eventually RH will become a new Windows. And I do not see crowds of migratory from systemded distros. Most of the people thinks that it's so funny, cool and modern to look into distorting mirror and glad to get into bondage. |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Oct 08, 2014 10:30 am Post subject: |
|
|
| creaker wrote: | | This software is bad not due to programming errors and even not due to conceptual mistakes. |
It is full of programming errors. And the conceptual mistakes are so obvious and in principle cannot be fixed that we need not even discuss about.
| Quote: | | Eventually code errors will be fixed. |
It's practically impossible. Maybe eventually some basic functionality will be roughly working due to heavy testing. Security will never be reached, since this cannot arranged by testing.
| Quote: | | Conception will be smoothed |
It's impossible. Essentially, you would have to remove the whole functionality.
| Quote: | | And I do not see crowds of migratory from systemded distros |
Wait until its usage is heavily spread and people begin to suffer under the rootkits which were installed by thousands of exploits.
Although there is a certain danger that administrators who are not competent enough to understand the risks of systemd in the beginning and flee from it will also not realize that they have been rooted. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Oct 08, 2014 12:15 pm Post subject: |
|
|
| mv wrote: | | conceptual mistakes |
I'll wade in with a tiny bit of controversy - at least for here. There were actually a few things I liked about systemd when I first tried it - two or three years ago. Actually I can encapsulate much of it in one word :
Sleep
From a slightly odd conceptual point there are two good ways to sleep, infinitesimally and forever. Anything else is a kludge. By infinitesimally, I basically mean using sleep() as a yield() call, to allow someone else to get scheduled. By forever I mean waiting for an interrupt from an event.
If you're sleeping for any other amount of time, chance are it's a best guess of enough time, and usually enough means just a smidge too much. You want to stage two events, one after the other, and don't know exactly how long the first event is going to take, but you have a pretty good guess, and add a little margin.
That's the nice thing about socket activation - it gives you events instead of sleeping.
The next aspect of sleep is daemon management. A package called "monit" has been mentioned as a services manager. But monit is not PID1, so works in a sleep/poll loop. PID1 doesn't have to sleep/poll, it receives a signal if the daemon dies, it can be event driven. There is another service manager I've seen where the daemon runs and doesn't return until it exits or dies. This is certainly good and event-based, but it isn't the way most services are written today. Personally I'd like to see something that could be hooked into start-stop-daemon.
Unfortunately, though it seemed to be on the right track two or three years ago, systemd has gone so far wrong (IMHO) that it's giving these few good underlying concepts a bad name. There has been quite a bit of PID1 discussion in the past few months, and I've followed much of it with interest. But I think even most of what has been proposed is a bit too heavy, yet strips too much functionality. So here's a stab:
PID1 does two things - starts its helpers and receives death signals. Maybe it finally stops the system, maybe not. PID1 doesn't even need to start the system, it can start a helper, and let the helper start the system. It doesn't need to process the death signals of children, it can just pass them off to another helper. It might need to make the final calls to halt/reboot/poweroff the system, but it can use yet another helper to do everything up to that final syscall. One other minor nit - the helpers are likely daemons in their own right, and PID1 would need to know it's helpers and how to restart them if they crash, but it doesn't need to know how to manage every blasted daemon in the system.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
mv
Watchman
Joined: 20 Apr 2005
Posts: 6747
|
| Posted: Wed Oct 08, 2014 3:09 pm Post subject: |
|
|
| depontius wrote: | | That's the nice thing about socket activation - it gives you events instead of sleeping. |
This event you do get if you start a daemon the normal way: A sane daemon does not sleep() but gets active once an even occurs. This has nothing to do with systemd.
What systemd does only is to introduce an unnecessary task: Instead of the daemon waiting for the socket event, a systemd task is waiting for the socket event and then needs to start the daemon which is again waiting for the socket event.
Thus, the great "advantage" of all this: If the daemon should happen to need a lot of startup time, you have moved this startup time from the starting of the machine to the first usage of the service. However, if the daemon is up rather quickly (and most daemons are), you just have doubled the startup time: You lose it now during booting (for setting up the socket and the systemd daemon for listening) and then loose it again for actually starting the daemon,
Analysis: Typically you get a pointless loss of resources -> typically it's a bad idea. Daemons which take ages to start might form an exception of this rule, but for these daemons, one could easily write a "wrapper" in the style of systemd: A tiny program would exist for this and satisfy all services.
In particular, there is no need to practically exchange the operating system for a rarely needed task.
| Quote: | | The next aspect of sleep is daemon management. |
That's the only thing which systemd really promised to do. But there are daemon managers out there, and for most systems they are not needed. In fact, I can hardly imagine a use care where it might be needed. It is certainly not a good idea to waste permanent resources on it if you do not need it.
| Quote: | | A package called "monit" has been mentioned as a services manager. But monit is not PID1, so works in a sleep/poll loop. |
If monit really works in sleep/poll, it is not a good daemon manager: The point of a daemon manager is of course to avoid that sort of thing - otherwise you could work as well with PID files. However, it seems you are aware of that and even write it: If daemons do not go to the background or at least does not reparentize, you do not need PID1: normal child process management works perfectly. Most daemons can run in foreground mode, and for the others a daemon controller does not make much sense, anyway.
But I agree with you that a daemon controller is one of the very few tasks which make sense to run in PID1. In fact, it is the only task which makes sense to run in PID1. If systemd would be just a daemon controller, we would not discuss here about broken concepts. But systemd wants to be so much more and does so much more, even with PID1. Just one example: No program would contain code which depends on a daemon controller, so all the artificial dependencies of other programs on systemd which are created artificially would not exist. systemd would not be intrusive, and nobody would complain: Use it, if it works for you, use another daemon conrtoller (or none) if it does not or if you don't need one. |
|
| Back to top |
|
|
229566
Tux's lil' helper
Joined: 16 Aug 2010
Posts: 127
|
| Posted: Wed Oct 08, 2014 4:47 pm Post subject: |
|
|
| mv wrote: | | Quote: | | A package called "monit" has been mentioned as a services manager. But monit is not PID1, so works in a sleep/poll loop. |
If monit really works in sleep/poll, it is not a good daemon manager |
I'm trying to understand what the problem is here. Isn't that solved with something like supervisord? Until now I never looked at monit and from the first glance it appears to be everything + kitchen sink as well. Supervisord is basically a single daemonized process that does nothing else but (re)spawn other processes and watches over them, and having them as children it doesn't have to sleep/loop on anything. |
|
| Back to top |
|
|
depontius
Advocate
Joined: 05 May 2004
Posts: 3509
|
| Posted: Wed Oct 08, 2014 5:05 pm Post subject: |
|
|
| mv wrote: | | depontius wrote: | | That's the nice thing about socket activation - it gives you events instead of sleeping. |
This event you do get if you start a daemon the normal way: A sane daemon does not sleep() |
Perhaps I'm betraying an incorrect understanding of socket activation. I'm still thinking of sleep() calls buried in initscripts and the fact that with OpenRC, parallel startup is generally frowned on. I was interpreting socket activation as a way for the system to know when required services are really up so that dependent services will wait properly, need no sleeps, and not need to serialize the whole process the way OpenRC does by default.
| mv wrote: | | But I agree with you that a daemon controller is one of the very few tasks which make sense to run in PID1. In fact, it is the only task which makes sense to run in PID1. If systemd would be just a daemon controller, we would not discuss here about broken concepts. But systemd wants to be so much more and does so much more, even with PID1. Just one example: No program would contain code which depends on a daemon controller, so all the artificial dependencies of other programs on systemd which are created artificially would not exist. systemd would not be intrusive, and nobody would complain: Use it, if it works for you, use another daemon conrtoller (or none) if it does not or if you don't need one. |
The change I was suggesting was to make PID1 a bit less than it appears to be in SysVinit, in a way, in that it would be responsible for neither system startup nor shutdown, only for receiving and passing on "death notices". There's no reason I can see why PID1 can't have helpers, push complexity there, and be prepared to restart its helpers if necessary.
_________________
.sigs waste space and bandwidth |
|
| Back to top |
|
|
happosai
n00b
Joined: 17 Aug 2005
Posts: 43
|
| Posted: Wed Oct 08, 2014 7:01 pm Post subject: |
|
|
Systemd is going to get experimental console code in its next version that could eventually succeed the VT-code in the kernel. First implementation is going to show up in 217 and it is being considered experimental.
http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Oct 08, 2014 7:43 pm Post subject: |
|
|
| depontius wrote: | | Perhaps I'm betraying an incorrect understanding of socket activation. |
AFAIK socket activation simply opens a socket and keeps it for whoever needs it.
It's supposed to save time by the daemon not having to open it's own socket,
but the socket has to be opened by someone whether sysd or the daemon.
It's one of those things which sounds "oh ah" but really isn't much of anything.
| Quote: | | parallel startup is generally frowned on |
Well, not exactly frowned on, but it's not as useful as many suppose.
You certainly can't start anything depending on the network before the network is started.
Bind and Apache could be started together after the network except that Apache likes to use dns when it can.
Only a handful really fall into the realm of being able to be started in parallel.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Oct 08, 2014 8:20 pm Post subject: |
|
|
| avx wrote: | | https://gfycat.com/ConcernedShowyKentrosaurus |
 LoL, that pretty much says it all, and when it's done eating everything we have *tada* windows (badly done of course)
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
i92guboj
Bodhisattva
Joined: 30 Nov 2004
Posts: 10315
Location: Córdoba (Spain)
|
| Posted: Wed Oct 08, 2014 8:23 pm Post subject: |
|
|
| Best movie I've seen in a long time |
|
| Back to top |
|
|
tld
Veteran
Joined: 09 Dec 2003
Posts: 1816
|
| Posted: Wed Oct 08, 2014 8:47 pm Post subject: |
|
|
| happosai wrote: | Systemd is going to get experimental console code in its next version that could eventually succeed the VT-code in the kernel. First implementation is going to show up in 217 and it is being considered experimental.
http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ |
I recall hearing some crap about potentially removing VTs from the kernel. Pure f***ing madness. I find it very hard to believe any such thing will happen. If it does I'll know that even the kernel devs have lost it. |
|
| Back to top |
|
|
Sulman
n00b
Joined: 15 Feb 2014
Posts: 63
|
| Posted: Wed Oct 08, 2014 8:51 pm Post subject: |
|
|
I thought Lennart's opening statement was curious.
Nobody, and I mean nobody you asked on the street would favour abuse or harrassment; and yet, it happens. Stating that is occurs and that it is bad is redundant; this is already known. Secondly, the remarks from social justice warrior lexicon were strange and seemed designed to allude some some righteousness on LP's part.
Unfortunately it all came undone on the completely unjustified attacks on Gentoo.
Of course it's political. |
|
| Back to top |
|
|
RazielFMX
l33t
Joined: 23 Apr 2005
Posts: 835
Location: NY, USA
|
| Posted: Wed Oct 08, 2014 8:58 pm Post subject: |
|
|
| tld wrote: | | happosai wrote: | Systemd is going to get experimental console code in its next version that could eventually succeed the VT-code in the kernel. First implementation is going to show up in 217 and it is being considered experimental.
http://www.phoronix.com/scan.php?page=news_item&px=MTgwNzQ |
I recall hearing some crap about potentially removing VTs from the kernel. Pure f***ing madness. I find it very hard to believe any such thing will happen. If it does I'll know that even the kernel devs have lost it. |
I imagine the conversation about removing VT support from the kernel would go something like this (*):
| Code: |
LP: Linus, I've submitted a bug report and patch to remove VTs from the kernel. This functionality will now be supplied by systemd-consoled. It's awesome.
Linus: Does it break userspace?
LP: Well, since systemd is the only viable init system for Linux, no users that matter will be affected.
Linus: So for those not using systemd, it will break userspace?
LP: Stop attacking me! How dare you insult me? I know what users want! You are an out of touch Luddite!
Linus: NOTABUG. WONTFIX.
|
(*) DISCLAIMER: I couldn't resist a little tongue in cheek humor. The fictional conversation depicted above is strictly for entertainment purposes and should not be construed as the views of the posting user, the Gentoo organization, or the Gentoo user community.
Last edited by RazielFMX on Wed Oct 08, 2014 9:00 pm; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Oct 08, 2014 9:00 pm Post subject: |
|
|
| tld wrote: | | I recall hearing some crap about potentially removing VTs from the kernel. Pure f***ing madness. I find it very hard to believe any such thing will happen. |
I'm not sure how you could remove them anyway. Too many things are designed to talk to a console.
Sure you could remove them and have only one (hard coded) console (which will be needed), but I don't see that happening.
Edit to add: Did a quick google search and ran across KMSCON where someone wanted to supplement the in-kernel vt console with a better one.
Not sure what the use of that would be, sounds like reimplementing an X11 term for a console.
Might be useful to 1-2% of the people that use linux.
I know that sysd wants to replace/supplement the regular console, but I can't see Linus giving the go ahead to remove it from the kernel completely. It just doesn't make sense.
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland
Last edited by Anon-E-moose on Wed Oct 08, 2014 9:07 pm; edited 1 time in total |
|
| Back to top |
|
|
Anon-E-moose
Watchman
Joined: 23 May 2008
Posts: 6098
Location: Dallas area
|
| Posted: Wed Oct 08, 2014 9:00 pm Post subject: |
|
|
| RazielFMX wrote: | I imagine the conversation about removing VT support from the kernel would go something like this (*):
| Code: |
LP: Linus, I've submitted a bug report and patch to remove VTs from the kernel. This functionality will now be supplied by systemd-consoled. It's awesome.
Linus: Does it break userspace?
LP: Well, since systemd is the only viable init system for Linux, no users that matter will be affected.
Linus: So for those not using systemd, it will break userspace?
LP: Stop attacking me! How dare you insult me? I know what users want! You are an out of touch Luddite!
Linus: NOTABUG. WONTFIX.
|
(*) DISCLAIMER: I couldn't resist a little tongue in cheek humor. The fictional conversation depicted above is strictly for entertainment purposes and should not be construed as the views of the posting user, the Gentoo organization, or the Gentoo user community. |
LoL
_________________
PRIME x570-pro, 3700x, 6.1 zen kernel
gcc 13, profile 17.0 (custom bare multilib), openrc, wayland |
|
| Back to top |
|
|
avx
Advocate
Joined: 21 Jun 2004
Posts: 2152
|
| Posted: Wed Oct 08, 2014 9:21 pm Post subject: |
|
|
| Anon-E-moose wrote: | | Edit to add: Did a quick google search and ran across KMSCON where someone wanted to supplement the in-kernel vt console with a better one. |
KMSCON and the systemd-console are actually by the same person. Now if that's good or bad, I don't know, yet, but it surely has a little stink of a future "it's too hard to maintain both, let's just maintain one...systemd" on it already.
_________________
++++++++++[>+++++++>++++++++++>+++>+<<<<-]>++.>+.+++++++..+++.>++.<<+++++++++++++++.>.+++.------.--------.>+.>.
Last edited by avx on Wed Oct 08, 2014 9:39 pm; edited 1 time in total |
|
| Back to top |
|
|
|
|
You cannot post new topics in this forum
You cannot reply to topics in this forum
You cannot edit your posts in this forum
You cannot delete your posts in this forum
You cannot vote in polls in this forum
|
|
Gentoo Chat
