Alas, it appears they are drinking the cool-aid. They USED to use only the init scripts, log only to syslog, and in-general paper over it every way they could so you don't have to notice it.
But most of the tools are using GTK and gnome as well. Especially if it's a project from freedesktop. They certailny won't be using fltk.
Of course, if you think you might ever have to work on it from a crashcart (for example, if you want to see why networking isn't coming up), you'll need X too. That will also apply if you want to do it remotely and use a KVM through IPMI if you can get it to actually work. Serial over lan through the BMC is a much better bet but that's text only (curses at best).
I have checked it out in Debian. It's really kind of amusing. They lobotomized it down to the brainstem in Jessie. IMHO, short of tossing it and Gnome 3 out the window, it's the right thing.
All the starting of/bin/sh isn't really all that costly since it is already in memory. It just has to be mapped into place
The big time waster in a boot is the BIOS. After it farts around for 2 minutes, a fast boot is already out the window. An extra minute for init and the scripts hardly matters.
The big potential killers like a forced fs check of a daemon that takes a long time to come up isn't fixed by systemd.
More amusing, there are several rc systems that drop in to SysV init to parallellize init scripts already. There is no need to re-invent the world just for that and the other drop-ins that manage it are proof.
Personally, I think something based on make would be interesting, but I don't have a big enough ego to try to cram it down people's throats and frankly, it's not sufficiently interesting to get me to work on it beyond idle thoughts.
1: If it *ISN'T* monolithic, why won't Gnome work wiothout it and why aren't the pieces available seperately?
2: If it isn't about speed, why is that all people talk about? What is so 'right' about the way systemd does things?
3: Servers start fast enough without systemd. In the cases where they need to start faster than is typical, they also tend to run ONLY the critical sevrice (ans so already start fast) OR they start the critical service first (and so it's also not a problem). The argument about VMs is entirely specious. The same services must be started either way, so the same I/O and CPU load has to happen one way or another.
And as for 'socket activated containers', it's called (x)inetd and we've had it for decades now.
4: The problem is that often server admins just need to make a small change to the standard shell script that starts a daemon in init.d. Except with systemd, there may not be one unless the distro was smart enough to effectively sidestep systemd by making it start rcS only and sticks with the scripts.
5: Are you freaking kidding me? Where's the howto? Where's the overview? Where's the freaking manual? Most of it is of the nature of 'absolutely true thing isn't REALLY true because OHH look, a bunny! (run away)".
6: I'd rather not recompile every time I want to re-configure my system, thank you very much. The modularity we're after happens at runtime, not compile time. Kinda like in the kernel, I don't have to load the modules I don't want.
7: It all kinda falls apart once 1-6 are dispelled. It adds unwanted complexity and dependencies to the server. A perfect recipe for disaster when things are going badly and the server is hours away by car.
8: Nothing systemd does couldn't have been done using a few helper apps. Had it been done that way, nobody would have a single objection to it. So why wasn't it done that way? That's right, NIH.
9:Well, let's see. It's hosted there, it's developers talk the same talk, and it's all been snarled together into a single dependency ball......
10: Only someone who never grasped that Unix is about small parts that do one thing well tied together through scripts and file-like objects could have written that.
11: A few big honking packages is certainly not simpler than a series of small and largely independent packages. It's a question of how much you have to know in order to do a simple thing. Small packages always win that question.
12: How big is init? Because in Unix, that's the part that has to be loaded. All the rc scripts do their thing they go away. They don't stick around after they do their job. In systemd, most of it insists on staying for some reason.
13: The problem is that it creates a moral hazard. It invites other unrelated things to become dependent on it (like gnome of all things) and so, not compatible with BSD. And BTW, a lot of us Linux folks don't want it either and don't appreciate the dependency trap being used in an attempt to cram it down our throats.
14: You're ACTUALLY arguing that since they worked so hard, what's a bit more? REALLY?!?
15: So there's so many dependencies it's even trapped itself? That doesn't sound like a feature to me... I thought you said it was modular, not complex and not difficult!And didn't you claim it was Unix? BSD is Unix and you're telling me it is intrinsically incompatible? You say there are far too many dependencies and it is all too complex to port? Do YOU even believe what you write?
16-17, no comment
18: So in other words, it IS feature creep!
19:Heh Heh. It's not like you HAVE to breath or anything. You could always hold your breath forever if you don't like my farts. I'm sure it is pure coincidence that other freedesktop projects have developed a hard dependency on systemd when they clearly never needed it befiore.
21: Yeah, it's all perfectly compatible as long as you do it our way rather than the way you did it before.
There's this thing called a quotation mark. We use it when we're repeating something someone else said. For example, in the summary, it is quoting TFA. If you had READ TFA, you might have known that.
So you may direct your complaints to Mr. Venezia or his editors.
He's looking for a replacement to 'tail -f/var/log/messages | grep "something"' and you offer a half-baked API and a link to a python module that WRITES but doesn't read log entries (it says so ruingt in the synopsis).
Debian's approach is the best short of tossing systemd and gnome out on their ears. They lobotomized systemd and chained it's still breathing shell to the wall.
The damned thing insists on being PID 1. The more crap it kitchen sinks into itself, the more often and likely it will need a security update. That's a reboot. If I wanted to reboot every day, I'd run Windows 95.
The dsame services runninmg seperately and not as pid 1 can easily be updated/upgraded at will and restarted without messing with the whole system.
The 'old' init is a very simple program. It does what it must do and no more. It doesn't see a lot of change at all. As a result, it doesn't cause any problems It just stays out of the way quietly listening for a command to change runlevels, respawning the occasional getty and dealing with child processes that lose their parent.
Systemd COULD have been implemented as pid2, spawned from init. Of course that wouldn't have supported the hidden agenda to take over everything. Surely you don't think it's a coincidence that the gnome desktop suddenly developed a hard dependency on systemd when it has been running without it for years.
That still requires a metric assload of libraries to be installed on the server. The bandwidth and latency requirements work OK enough for routine operation, but it really sucks when the problem you're trying to solve involves poor connectivity.
And it absolutely won't work over a serial console.
“A further check of Maryland State Police databases also proved to be negative as to any weapons registered to him. McLaw was suspended by the Dorchester County Board of Education pending an investigation and is no longer in the area. He is currently at a location known to law enforcement and does not currently have the ability to travel anywhere.”
But what will really happen is that resources will be yanked from the 'normal' internet to provision the fast lane. If that doesn't get enough sign-ups, they'll further cripple the 'normal' service until the pain is sufficioent to get large content providers to pay for the 'fast lane' which will be about as fast as the old internet while the 'normal' internet will resemble dial-up.
If he was suspended with pay, I could possibly buy that their hand was somehow forced. But whisking him off for a 'medical evaluation' and holding him in an undisclosed location? No. Nothing forced them to do that but their own diseased minds.
Decommissioning costs are driven up by politics. For example by treating things that are mildly radioactive for a few years post shutdown as if they are still nuclear waste years after the last decay.
Slashdot Mirror
Alas, it appears they are drinking the cool-aid. They USED to use only the init scripts, log only to syslog, and in-general paper over it every way they could so you don't have to notice it.
If you want it much faster than they start already, you'll need coreboot.
A trigger for what? Perhaps I'm just watching the console.
I doubt it. Then you just have the old init call the rc scripts as normal and tell systemd to start/stop/watch/ nothing and if it crashes, who cares.
Now the real question is can I then remove journald since I have no use for it?
So you're saying the non-smartass actually helpful answer is 'yes'?
You should submit a patch. I'm sure the systemd guys will love it.
Only init itself has to run as pid1. Everything else that systemd does including startup could be done when called by init.
Does systemctl have a -f mode? That is, it outputs anything appended to the file as it happens?
But most of the tools are using GTK and gnome as well. Especially if it's a project from freedesktop. They certailny won't be using fltk.
Of course, if you think you might ever have to work on it from a crashcart (for example, if you want to see why networking isn't coming up), you'll need X too. That will also apply if you want to do it remotely and use a KVM through IPMI if you can get it to actually work. Serial over lan through the BMC is a much better bet but that's text only (curses at best).
I have checked it out in Debian. It's really kind of amusing. They lobotomized it down to the brainstem in Jessie. IMHO, short of tossing it and Gnome 3 out the window, it's the right thing.
Fully agreed and more!
All the starting of /bin/sh isn't really all that costly since it is already in memory. It just has to be mapped into place
The big time waster in a boot is the BIOS. After it farts around for 2 minutes, a fast boot is already out the window. An extra minute for init and the scripts hardly matters. The big potential killers like a forced fs check of a daemon that takes a long time to come up isn't fixed by systemd.
More amusing, there are several rc systems that drop in to SysV init to parallellize init scripts already. There is no need to re-invent the world just for that and the other drop-ins that manage it are proof.
Personally, I think something based on make would be interesting, but I don't have a big enough ego to try to cram it down people's throats and frankly, it's not sufficiently interesting to get me to work on it beyond idle thoughts.
Here we go:
1: If it *ISN'T* monolithic, why won't Gnome work wiothout it and why aren't the pieces available seperately?
2: If it isn't about speed, why is that all people talk about? What is so 'right' about the way systemd does things?
3: Servers start fast enough without systemd. In the cases where they need to start faster than is typical, they also tend to run ONLY the critical sevrice (ans so already start fast) OR they start the critical service first (and so it's also not a problem). The argument about VMs is entirely specious. The same services must be started either way, so the same I/O and CPU load has to happen one way or another.
And as for 'socket activated containers', it's called (x)inetd and we've had it for decades now.
4: The problem is that often server admins just need to make a small change to the standard shell script that starts a daemon in init.d. Except with systemd, there may not be one unless the distro was smart enough to effectively sidestep systemd by making it start rcS only and sticks with the scripts.
5: Are you freaking kidding me? Where's the howto? Where's the overview? Where's the freaking manual? Most of it is of the nature of 'absolutely true thing isn't REALLY true because OHH look, a bunny! (run away)".
6: I'd rather not recompile every time I want to re-configure my system, thank you very much. The modularity we're after happens at runtime, not compile time. Kinda like in the kernel, I don't have to load the modules I don't want.
7: It all kinda falls apart once 1-6 are dispelled. It adds unwanted complexity and dependencies to the server. A perfect recipe for disaster when things are going badly and the server is hours away by car.
8: Nothing systemd does couldn't have been done using a few helper apps. Had it been done that way, nobody would have a single objection to it. So why wasn't it done that way? That's right, NIH.
9:Well, let's see. It's hosted there, it's developers talk the same talk, and it's all been snarled together into a single dependency ball......
10: Only someone who never grasped that Unix is about small parts that do one thing well tied together through scripts and file-like objects could have written that.
11: A few big honking packages is certainly not simpler than a series of small and largely independent packages. It's a question of how much you have to know in order to do a simple thing. Small packages always win that question.
12: How big is init? Because in Unix, that's the part that has to be loaded. All the rc scripts do their thing they go away. They don't stick around after they do their job. In systemd, most of it insists on staying for some reason.
13: The problem is that it creates a moral hazard. It invites other unrelated things to become dependent on it (like gnome of all things) and so, not compatible with BSD. And BTW, a lot of us Linux folks don't want it either and don't appreciate the dependency trap being used in an attempt to cram it down our throats.
14: You're ACTUALLY arguing that since they worked so hard, what's a bit more? REALLY?!?
15: So there's so many dependencies it's even trapped itself? That doesn't sound like a feature to me... I thought you said it was modular, not complex and not difficult!And didn't you claim it was Unix? BSD is Unix and you're telling me it is intrinsically incompatible? You say there are far too many dependencies and it is all too complex to port? Do YOU even believe what you write?
16-17, no comment
18: So in other words, it IS feature creep!
19:Heh Heh. It's not like you HAVE to breath or anything. You could always hold your breath forever if you don't like my farts. I'm sure it is pure coincidence that other freedesktop projects have developed a hard dependency on systemd when they clearly never needed it befiore.
21: Yeah, it's all perfectly compatible as long as you do it our way rather than the way you did it before.
24: Compared to init, that IS buggy and unstable
Yes, it's so confusing deciding if it's going to be 'apt-get install foo' or 'yum install foo'.
There's this thing called a quotation mark. We use it when we're repeating something someone else said. For example, in the summary, it is quoting TFA. If you had READ TFA, you might have known that.
So you may direct your complaints to Mr. Venezia or his editors.
Until systemd pissed in the soup, /etc/init.d/servicename (start|stop) worked in every linux distro. Now, who the hell knows.
FAIL!
He's looking for a replacement to 'tail -f /var/log/messages | grep "something"' and you offer a half-baked API and a link to a python module that WRITES but doesn't read log entries (it says so ruingt in the synopsis).
Debian's approach is the best short of tossing systemd and gnome out on their ears. They lobotomized systemd and chained it's still breathing shell to the wall.
The damned thing insists on being PID 1. The more crap it kitchen sinks into itself, the more often and likely it will need a security update. That's a reboot. If I wanted to reboot every day, I'd run Windows 95.
The dsame services runninmg seperately and not as pid 1 can easily be updated/upgraded at will and restarted without messing with the whole system.
The 'old' init is a very simple program. It does what it must do and no more. It doesn't see a lot of change at all. As a result, it doesn't cause any problems It just stays out of the way quietly listening for a command to change runlevels, respawning the occasional getty and dealing with child processes that lose their parent.
Systemd COULD have been implemented as pid2, spawned from init. Of course that wouldn't have supported the hidden agenda to take over everything. Surely you don't think it's a coincidence that the gnome desktop suddenly developed a hard dependency on systemd when it has been running without it for years.
That still requires a metric assload of libraries to be installed on the server. The bandwidth and latency requirements work OK enough for routine operation, but it really sucks when the problem you're trying to solve involves poor connectivity.
And it absolutely won't work over a serial console.
Sheriff Phillips was quoted:
“A further check of Maryland State Police databases also proved to be negative as to any weapons registered to him. McLaw was suspended by the Dorchester County Board of Education pending an investigation and is no longer in the area. He is currently at a location known to law enforcement and does not currently have the ability to travel anywhere.”
But what will really happen is that resources will be yanked from the 'normal' internet to provision the fast lane. If that doesn't get enough sign-ups, they'll further cripple the 'normal' service until the pain is sufficioent to get large content providers to pay for the 'fast lane' which will be about as fast as the old internet while the 'normal' internet will resemble dial-up.
Have you never gone grocery shopping?
They did say he was taken for an evaluation. They then said police know where he is and that he has no ability to leave. Gee, what could that be?
If he was suspended with pay, I could possibly buy that their hand was somehow forced. But whisking him off for a 'medical evaluation' and holding him in an undisclosed location? No. Nothing forced them to do that but their own diseased minds.
AKA when done in some other country, "He's being held incommunicado".
Decommissioning costs are driven up by politics. For example by treating things that are mildly radioactive for a few years post shutdown as if they are still nuclear waste years after the last decay.