The high school diploma was at one time seen as quite optional. At that time, it was also seen as a stepping stone to living better. College was for the rich kids to get some social cred so they wouldn't have to resort to useful work in the future.
Unfortunately, the HS diploma means almost nothing and we expect 18 year olds to somehow buy in to having even a half decent job and the buy in gets bigger every year. Soon it will reach the point where it will never pay off.
As someone who has written entire init systems, I'll tell you how it's done:
Create a program (any language you like) that connects to the service and requests status. Make it keep trying until the status is good. Call it in the start stanza of the dependent service's init script.
For example, you can use wget to see if apache has come up. It can even see if apache on another machine has come up. Now, how would you go about having systemd do that for you?
Perhaps you missed the article earlier in the week about a fork of Debian?
It is, however a bunch of work that shouldn't need doing since it is easier to drop systemd into a system that uses sysvinit (since sysv doesn't attract dependencies) than going the other way around.
So far, what I have seen is that 4 people in the Debian project voted to go with systemd. Four whole people and clearly others who weren't consulted are a bit ticked off about it.
E restarts due to the loop. The dependents either re-connect if well written or if not then they crash and get restarted. In such a case you'd want to insert a test for availability of dependencies in the loop.
In the most extreme case, you could even do something like make runlevel 2 the default and have/etc/rc2.d/S99gothree run telinit 3. In runlevel3 your services start in the dependent order like:
Start_servivce; telinit 2
So, server comes up in runlevel 2, then transitions to three starting the production services. Should one of the production services fail, the server tramnsitions to runlevel 2, shutting down all of the production services, then transitions back to runlevel 3 to bring them all back up in order.
More broadly, there are any number of solutions to the problem that are far less intrusive on the rest of the system.
I can't imagine it would be all that hard to add AF_UNIX sockets to xinetd.
I'm not so sure the whole idea is actually all that helpful on a modern system. If the daemon runs standalone but isn't active, it will be paged out (well, the data segment gets paged out, the rest is already backed by the bin and library files) to make room for things actually being used. At that point it doesn't really hold significant resources. If something actually connects to it, it will page in already initialized and ready to go.
OTOH, if xinetd or systemd holds the socket, still no significant resources, but if something contacts it, you have to wait for both the page-in AND initialization.
That whole scheme made more sense back when Unix systems typically had less sophisticated memory management.
TCP/IP DID end up replacing DECnet, but not through political tricks. It was simply preferred. The DECnat fans were in no way prevented from running DECnet.
Likewise, X was made available but it wasn't crammed into VMS with no option to skip it.
That's what they did. Distributions are willing adopting it. People are switching over to their side.
If by willingly, you mean bent over a barrel, a tie vote in one committee, a pending general resolution to ban dependencies on systemd and a threat to fork the distro, then I suppose so.
All those pages written and still nothing coherent and useful to someone who hasn't already drunk the cool aid.
Perhaps that's the problem. I tend to stop reading when a document claims the new thing is a zillion times better than the old thing because it can (insert description of what the old thing already does).
The rebuttals read like Ronald Reagan at a press conference. Question asked, he answers a different question, nobody seems to notice he never answered the question.
I didtinctly remember not trying to piss in their well. They had their ecosystem and we had ours. We made no efforts at all to co-opt anything they had such that they no longer had it. Nothing that worked on vax quit working because someone was trying to cram a new system paradigm down their throats on their own OS.
They didn't suddenly find that when they attempted to install VMS, they got Linux instead.
If systemd's proponents are so sure their way is right, they should create a nice systemd fork of something and play with it all they want.
Or offer systemd as a true option and make sure it doesn't become "would you like systemd or do you want everything to fail?"
There are several cases where the systemd team refuses to accept that a bug is a bug. For example, their persistent refusal to accept that debug on the kernel command line is meant to apply to the kernel ONLY. They could easily go with systemd.debug but they refuse even when all but ordered to do it.
Only if they have been added to the systemd dependency hairball. If they are normal daemons, they will report nothing back to systemd.
rc scripts offer the opportunity to either make the script wait until the service is responsive OR to have the dependent script wait.
In many cases, daemons only detach once they are up and running exactly so the init process won't screw up dependencies. Unless the init system tries to get clever...
I do use ECC in servers and I definitely do not see 40 bit flips in a day.
If you see that many, it's worth making sure the power supply is stable and the power quality is good.
Power supply ratings are total crap these days. To get actually stable power, you may need to go with one rated for double the power that will actually be needed.
NO, read it again. I asked YOU in what way is systemd the right way to do it. You don't seem to have any idea whatsoever why the architecture of systemd might be the right thing. You managed to name some features that I agree are good, but those could be implemented in many different ways, some of which would not raise any objections.
So the question remains, in the absence of any special value to systemd's approach to providing those great features, why choose it rather than a far less objectionable approach that offers those same great capabilities AND greater flexibility and hackability?
That's the problem. A CA signed cert doesn't help much for that. The basic cert can be had in pretty much any name just by photoshopping a fake letterhead. Even the 'advanced' signed certs can be forged (and have been) under orders from NSA and similar shady criminal organizations. Really, only casual forgeries are prevented, but casual forgeries are unlikely to take the steps necessary to subvert DNS or routing required for any MITM attack Note too that if I attack your PC to subvert DNS or routing, I can as easily drop my Snakeoil LTD CA cert into your browser while I'm at it..
The one way to be really sure is to use an independent communication channel to ask the fingerprint of the cert in use. At that point, self-signed and CA signed are of the same value.
But note that in other cases, the question that matters is actually is this entity 'A' the same entity 'A' that I successfully did business with last month? In this case, knowing that the name is 'A' isn't necessarily all that useful unless 'A' is famous. That case is well served by the browser remembering what cert was used last time. In that case, self-signed is fine.
By far, the most common problem that actually affects people is attacks involving very similar names or typo domain names that are easily overlooked.
While I do see the point in warning about the security level, most certs provide practically no actual identification beyond someone said they were X and now they're saying it again.
In truth, I would place greater trust in a self-signed cert that has the same signature as it did the last tome I visited the site than I would in a basic cert for a site I am visiting for the first time.
I have been quite clear on that and now you wish to re-assert what I challenged you on already as if that somehow answers the question. That's not a very good showing.
Slashdot Mirror
So you truly can't think of a single reason. I thought so.
Did you stay at a Holiday Inn Express or something? You know those commercials were just being silly, right?
The high school diploma was at one time seen as quite optional. At that time, it was also seen as a stepping stone to living better. College was for the rich kids to get some social cred so they wouldn't have to resort to useful work in the future.
Unfortunately, the HS diploma means almost nothing and we expect 18 year olds to somehow buy in to having even a half decent job and the buy in gets bigger every year. Soon it will reach the point where it will never pay off.
As someone who has written entire init systems, I'll tell you how it's done:
Create a program (any language you like) that connects to the service and requests status. Make it keep trying until the status is good. Call it in the start stanza of the dependent service's init script.
For example, you can use wget to see if apache has come up. It can even see if apache on another machine has come up. Now, how would you go about having systemd do that for you?
Uselessd has fixed it in their fork.
Perhaps you missed the article earlier in the week about a fork of Debian?
It is, however a bunch of work that shouldn't need doing since it is easier to drop systemd into a system that uses sysvinit (since sysv doesn't attract dependencies) than going the other way around.
So far, what I have seen is that 4 people in the Debian project voted to go with systemd. Four whole people and clearly others who weren't consulted are a bit ticked off about it.
E restarts due to the loop. The dependents either re-connect if well written or if not then they crash and get restarted. In such a case you'd want to insert a test for availability of dependencies in the loop.
In the most extreme case, you could even do something like make runlevel 2 the default and have /etc/rc2.d/S99gothree run telinit 3. In runlevel3 your services start in the dependent order like:
Start_servivce; telinit 2
So, server comes up in runlevel 2, then transitions to three starting the production services. Should one of the production services fail, the server tramnsitions to runlevel 2, shutting down all of the production services, then transitions back to runlevel 3 to bring them all back up in order.
More broadly, there are any number of solutions to the problem that are far less intrusive on the rest of the system.
I can't imagine it would be all that hard to add AF_UNIX sockets to xinetd.
I'm not so sure the whole idea is actually all that helpful on a modern system. If the daemon runs standalone but isn't active, it will be paged out (well, the data segment gets paged out, the rest is already backed by the bin and library files) to make room for things actually being used. At that point it doesn't really hold significant resources. If something actually connects to it, it will page in already initialized and ready to go.
OTOH, if xinetd or systemd holds the socket, still no significant resources, but if something contacts it, you have to wait for both the page-in AND initialization.
That whole scheme made more sense back when Unix systems typically had less sophisticated memory management.
TCP/IP DID end up replacing DECnet, but not through political tricks. It was simply preferred. The DECnat fans were in no way prevented from running DECnet.
Likewise, X was made available but it wasn't crammed into VMS with no option to skip it.
That's what they did. Distributions are willing adopting it. People are switching over to their side.
If by willingly, you mean bent over a barrel, a tie vote in one committee, a pending general resolution to ban dependencies on systemd and a threat to fork the distro, then I suppose so.
Have you ever tried to overhaul a horse? They disassemble just fine but you can never get them put back together right.
The problem is that he didn't want a debate, he wanted a love-in.
This is not woodstock.org.
man xinetd
The work isn't hard though. What is hard about while true; do run service; echo "damnit"|mail -s 'crashed again'; sleep 30; done?
Monitoring and restart in one line!
All those pages written and still nothing coherent and useful to someone who hasn't already drunk the cool aid.
Perhaps that's the problem. I tend to stop reading when a document claims the new thing is a zillion times better than the old thing because it can (insert description of what the old thing already does).
The rebuttals read like Ronald Reagan at a press conference. Question asked, he answers a different question, nobody seems to notice he never answered the question.
Implicit in your statement is that the problem was already solved for the people who needed it solved without pestering the rest of us.
I didtinctly remember not trying to piss in their well. They had their ecosystem and we had ours. We made no efforts at all to co-opt anything they had such that they no longer had it. Nothing that worked on vax quit working because someone was trying to cram a new system paradigm down their throats on their own OS.
They didn't suddenly find that when they attempted to install VMS, they got Linux instead.
If systemd's proponents are so sure their way is right, they should create a nice systemd fork of something and play with it all they want.
Or offer systemd as a true option and make sure it doesn't become "would you like systemd or do you want everything to fail?"
There are several cases where the systemd team refuses to accept that a bug is a bug. For example, their persistent refusal to accept that debug on the kernel command line is meant to apply to the kernel ONLY. They could easily go with systemd.debug but they refuse even when all but ordered to do it.
It remains a big fat WONTFIX, NOTABUG.
Only if they have been added to the systemd dependency hairball. If they are normal daemons, they will report nothing back to systemd.
rc scripts offer the opportunity to either make the script wait until the service is responsive OR to have the dependent script wait.
In many cases, daemons only detach once they are up and running exactly so the init process won't screw up dependencies. Unless the init system tries to get clever...
I do use ECC in servers and I definitely do not see 40 bit flips in a day.
If you see that many, it's worth making sure the power supply is stable and the power quality is good.
Power supply ratings are total crap these days. To get actually stable power, you may need to go with one rated for double the power that will actually be needed.
And if it goes down on a hardware failure, restarting the process isn't likely to fix it.
NO, read it again. I asked YOU in what way is systemd the right way to do it. You don't seem to have any idea whatsoever why the architecture of systemd might be the right thing. You managed to name some features that I agree are good, but those could be implemented in many different ways, some of which would not raise any objections.
So the question remains, in the absence of any special value to systemd's approach to providing those great features, why choose it rather than a far less objectionable approach that offers those same great capabilities AND greater flexibility and hackability?
That's the problem. A CA signed cert doesn't help much for that. The basic cert can be had in pretty much any name just by photoshopping a fake letterhead. Even the 'advanced' signed certs can be forged (and have been) under orders from NSA and similar shady criminal organizations. Really, only casual forgeries are prevented, but casual forgeries are unlikely to take the steps necessary to subvert DNS or routing required for any MITM attack Note too that if I attack your PC to subvert DNS or routing, I can as easily drop my Snakeoil LTD CA cert into your browser while I'm at it..
The one way to be really sure is to use an independent communication channel to ask the fingerprint of the cert in use. At that point, self-signed and CA signed are of the same value.
But note that in other cases, the question that matters is actually is this entity 'A' the same entity 'A' that I successfully did business with last month? In this case, knowing that the name is 'A' isn't necessarily all that useful unless 'A' is famous. That case is well served by the browser remembering what cert was used last time. In that case, self-signed is fine.
By far, the most common problem that actually affects people is attacks involving very similar names or typo domain names that are easily overlooked.
While I do see the point in warning about the security level, most certs provide practically no actual identification beyond someone said they were X and now they're saying it again.
In truth, I would place greater trust in a self-signed cert that has the same signature as it did the last tome I visited the site than I would in a basic cert for a site I am visiting for the first time.
Winding wasn't that much fuss either but people wanted it gone. In part because forgetting to wind was also quite easy, as is forgetting to charge.
Of course when traveling with a watch, winding doesn't require you to pack a winder.
I have been quite clear on that and now you wish to re-assert what I challenged you on already as if that somehow answers the question. That's not a very good showing.
In what way? It seems more like it respects the nature of Windows frankly.
I'm guessing you have no actual idea here?