Still answering the wrong question. I asked in what ways is systemd doing it right? I have already acknowledged (and never argued otherwise) that sysvinit has warts.
The rsyslog vs. journald links tend to support my assertion that journald is inferior to syslog.
The last link explained the differences, but never managed to explain why the systemd approach is necessary at all, much less better.
As PID 1 it is the parent process of all services, therefore it can observe them all. No PID file hackery needed.
With cgroups in use, any PID can watch the services.
So again, the question is what is so right about systemd's design? Why can you not imagine that there is a better design that respects the nature of Unix and achieves the same objectives?
It is at least a trademark violation. It might also run afoul of libel laws (as it could damage the good name of the Seattle Times). Fraud makes an appearance there somewhere as well.
Try phishing using a well known brand name without permission and see what happens to you.
You should never fail to train your replacements. For example "We are in a multi year revamp of programming languages. So any updatyes should be coded in brainfuck or MUMPS. If you need to modify a module it will first need a rewite into one of those languages. The company is a little embarrassed by it's old choice, so use this password to erase the history on the module in source control once you have checked the new version in. I'm sure you'll do fine!
TRhose are good characterists, but that's not my question. In what way is systemd achieving those things in a proper manner. In whjat way is systemd's architecture correct?
Startpar (an add-in to systemV) with xinetd and rsyslogd, etc provide those things. I can envision what may be a cleaner way of providing all of that.
So I ask again, in what way is systemd doing it right?
Those are good questions. Whatever it was, it wasn't enough.
A good followup question is what reason did they have to believe what they did was enough. I am not aware of a significant body of knowledge as to what is necessary to successfully take a 40 year old single use engine out of mothballs.
Yes you can, and at those prices you factor the insurance cost into the launch cost. The more times a payl;oad has been lost on a platform, the more expensive it becomes to insure a payload on that platform. So this explosion has increased the actual cost to customers of future launches by orbital.
The design is great, no problem with using it today, why screw with what works.
OTOH, the engines themselves are 40 years old. That is a different story. They were made and have just been sitting in storage. 40 years is a long time for things to go wrong bad. Apparently they were not sufficiently re-conditioned before use.
The problem then is perception. Network utilization isn't obvious to the end user, so when they're throttled, it just appears that their carrier is slow for no reason. An hour later, it could be fine, so the average self-centered user will blame their carrier for having service that just gets really slow all of a sudden.
But those perceptions are accurate. They're supposed to limit overselling so that congestion is infrequent. The carrier is to blame for the problem.
Since it clearly CAN run without the dependency, only an idiot would add it gratuitously unless it' for political reasons (like making not adopting systemd a pain in the ass).
You ignore that I HAVE thought about it and came up with something that didn't look at all like systemd. Too bad systemd is trying to freeze such a solution out.
Even the systemd project has admitted that the replacement would have to be pretty much a clone of systemd in order to work. Sounds a bit like "you can have any color you want as long as it's black".
The shim only came about as a patch against logind. It was intended to be a dependency and they refuse to promise that it won't go back to a hard dependency in the next update. Meanwhile, guess what dbus is being tied in to...
Ahh, here we are. I have actually imagined such a thing that does it the Unix way. That alone puts the lie to your Luddite claim. I don't object at all to an improved init system, I just want it to not have a brain damaged design.
I can easily test it from inside sysvinit (replace a bit at a time), but systemd would be a real showstopper. It will not tolerate not being PID1 and it demands all of it's dependencies be met. That is another part of the Unix design philosophy, you don't have to move the world to do something new. You can replace small bits at a time with little disruption and you don't need a large team and months of effort just to get the old parts out of the way.
I don't agree that the scripts need to go away, but do think it's a win if the complexity can be reduced by using cgroups. It is the historical lack of that capability that has created the complexity in some of the init scripts. A per-instance standalone helper program is probably the way to go. Let the admin decide case by case (if desired) what runs under it and what doesn't. Technically in those cases, the script starts the manager and the manager handles the daemon (including cgroups)
I can/could support an init system that keeps udevd and dbusd as separate projects. I don't much care for or about logind, but I have no objection if the gnome project wants to adopt it as part of their project or if they want to make it an separate standalone for GUI systems to use or not as they see fit. It should be renamed though, it sounds like a replacement for/bin/login which it is not.
The systemd team's attempt to get cgroups modified to be useless to all but systemd is very telling as far as their design and intentions goes. Frankly, it makes me not trust them.
I object strenuously to systemd on technical grounds. Please do not insult me by claiming it can only mean I am a Luddite. It's not only impolite, it make you look like an ass.
I don't recommend starting a panic, but if you want to get away with it, apply the nitromethane to the seat of your own pants and contaminate the airport seats that way.
So the unmit files act all on their own? They don't need a complex anything to make their magic happen? I can rip that complex binary out and they still work? If not, then you have to count the complexity of the thing that actually acts on the unit file.
Just imagine the creeping horrors hiding in systemd that haven't been found out yet.
Of course, if you were actually qualified here and trying to have a reasoned argument you would realize that 1) many systems use dash (not bash) to run the init scripts, and 2) the bash bug wouldn't affect anything in the context of starting the system.
A bazillion little APIs that odd things are expected to depend on later. For example, gnome mysteriously caring what init system was used. Perhaps you should actually read the systemd documents where the dependency hairball is a stated goal of the project as is the takeover of the whole system. The documents where they admit themselves that there are pieces that will be hard to extract and replace.
Imagine if while developing systemd, they couldn't just try out a partial implementation because the rc scripts would throw a fit and not bring the system up if PID1 wasn't the old sysv init.
Imagine if various unrelated other parts of the system refused to come up unless/until you fully duplicated every last API presented by the old system.
Slashdot Mirror
Still answering the wrong question. I asked in what ways is systemd doing it right? I have already acknowledged (and never argued otherwise) that sysvinit has warts.
The rsyslog vs. journald links tend to support my assertion that journald is inferior to syslog.
The last link explained the differences, but never managed to explain why the systemd approach is necessary at all, much less better.
As PID 1 it is the parent process of all services, therefore it can observe them all. No PID file hackery needed.
With cgroups in use, any PID can watch the services.
So again, the question is what is so right about systemd's design? Why can you not imagine that there is a better design that respects the nature of Unix and achieves the same objectives?
It is at least a trademark violation. It might also run afoul of libel laws (as it could damage the good name of the Seattle Times). Fraud makes an appearance there somewhere as well.
Try phishing using a well known brand name without permission and see what happens to you.
Just remember you said that when you see no food in your hipster grocery store. Good luck getting that wheat crop going in the park...
You should never fail to train your replacements. For example "We are in a multi year revamp of programming languages. So any updatyes should be coded in brainfuck or MUMPS. If you need to modify a module it will first need a rewite into one of those languages. The company is a little embarrassed by it's old choice, so use this password to erase the history on the module in source control once you have checked the new version in. I'm sure you'll do fine!
Sure, but some are called professional societies and other names. For example, the ABA, the AMA, etc.
Well, there's not much else to cause a loss of thrust at that point in the flight.
TRhose are good characterists, but that's not my question. In what way is systemd achieving those things in a proper manner. In whjat way is systemd's architecture correct?
Startpar (an add-in to systemV) with xinetd and rsyslogd, etc provide those things. I can envision what may be a cleaner way of providing all of that.
So I ask again, in what way is systemd doing it right?
Those are good questions. Whatever it was, it wasn't enough.
A good followup question is what reason did they have to believe what they did was enough. I am not aware of a significant body of knowledge as to what is necessary to successfully take a 40 year old single use engine out of mothballs.
In what bizarre way is systemd doing the right thing?
Yes you can, and at those prices you factor the insurance cost into the launch cost. The more times a payl;oad has been lost on a platform, the more expensive it becomes to insure a payload on that platform. So this explosion has increased the actual cost to customers of future launches by orbital.
The design is great, no problem with using it today, why screw with what works.
OTOH, the engines themselves are 40 years old. That is a different story. They were made and have just been sitting in storage. 40 years is a long time for things to go wrong bad. Apparently they were not sufficiently re-conditioned before use.
The problem then is perception. Network utilization isn't obvious to the end user, so when they're throttled, it just appears that their carrier is slow for no reason. An hour later, it could be fine, so the average self-centered user will blame their carrier for having service that just gets really slow all of a sudden.
But those perceptions are accurate. They're supposed to limit overselling so that congestion is infrequent. The carrier is to blame for the problem.
Except that it was patched to run without systemd when it became apparent that Ubuntu would sooner drop Gnome at that time.
So why do people keep claiming it's impossible whenever someone suggests something like let the old init call systemd?
Or that systemd should split out a very simple stub to be pid1 and move the complexity to something called by the stub?
Since it clearly CAN run without the dependency, only an idiot would add it gratuitously unless it' for political reasons (like making not adopting systemd a pain in the ass).
You ignore that I HAVE thought about it and came up with something that didn't look at all like systemd. Too bad systemd is trying to freeze such a solution out.
Quite the opposite.. My solution to configuration changes is keep them.
Even the systemd project has admitted that the replacement would have to be pretty much a clone of systemd in order to work. Sounds a bit like "you can have any color you want as long as it's black".
The shim only came about as a patch against logind. It was intended to be a dependency and they refuse to promise that it won't go back to a hard dependency in the next update. Meanwhile, guess what dbus is being tied in to...
If someone sneezes blood and has a fever, feel free to quarantine them and whoever they sneezed on.
Ahh, here we are. I have actually imagined such a thing that does it the Unix way. That alone puts the lie to your Luddite claim. I don't object at all to an improved init system, I just want it to not have a brain damaged design.
I can easily test it from inside sysvinit (replace a bit at a time), but systemd would be a real showstopper. It will not tolerate not being PID1 and it demands all of it's dependencies be met. That is another part of the Unix design philosophy, you don't have to move the world to do something new. You can replace small bits at a time with little disruption and you don't need a large team and months of effort just to get the old parts out of the way.
I don't agree that the scripts need to go away, but do think it's a win if the complexity can be reduced by using cgroups. It is the historical lack of that capability that has created the complexity in some of the init scripts. A per-instance standalone helper program is probably the way to go. Let the admin decide case by case (if desired) what runs under it and what doesn't. Technically in those cases, the script starts the manager and the manager handles the daemon (including cgroups)
I can/could support an init system that keeps udevd and dbusd as separate projects. I don't much care for or about logind, but I have no objection if the gnome project wants to adopt it as part of their project or if they want to make it an separate standalone for GUI systems to use or not as they see fit. It should be renamed though, it sounds like a replacement for /bin/login which it is not.
The systemd team's attempt to get cgroups modified to be useless to all but systemd is very telling as far as their design and intentions goes. Frankly, it makes me not trust them.
I object strenuously to systemd on technical grounds. Please do not insult me by claiming it can only mean I am a Luddite. It's not only impolite, it make you look like an ass.
I don't recommend starting a panic, but if you want to get away with it, apply the nitromethane to the seat of your own pants and contaminate the airport seats that way.
So the unmit files act all on their own? They don't need a complex anything to make their magic happen? I can rip that complex binary out and they still work? If not, then you have to count the complexity of the thing that actually acts on the unit file.
Just imagine the creeping horrors hiding in systemd that haven't been found out yet.
Of course, if you were actually qualified here and trying to have a reasoned argument you would realize that 1) many systems use dash (not bash) to run the init scripts, and 2) the bash bug wouldn't affect anything in the context of starting the system.
So, have you actually eaten dog shit or are you a luddite?
A bazillion little APIs that odd things are expected to depend on later. For example, gnome mysteriously caring what init system was used. Perhaps you should actually read the systemd documents where the dependency hairball is a stated goal of the project as is the takeover of the whole system. The documents where they admit themselves that there are pieces that will be hard to extract and replace.
Imagine if while developing systemd, they couldn't just try out a partial implementation because the rc scripts would throw a fit and not bring the system up if PID1 wasn't the old sysv init.
Imagine if various unrelated other parts of the system refused to come up unless/until you fully duplicated every last API presented by the old system.