Hm... the key is defining such "sensible way to ignore the specifics of other scripts". Stated that way, it would seem that operators can choose what they want to ignore and what they want to deal with. Those who operate static systems are badly affected by the arbitrary changes that parallel start introduces in the order that init scripts are run, so not everything is reliable when incompatible changes come through. Couldn't it have been done smoothly?
I recall MySQL having a wrapper that used to take care of this
Did they name it "daemontools"?
It's called mysqld_safe. You may consider it a hack, but it has some features, such as checking for corrupted storage, that would be completely useless for, say, a read-only web server.
There is a "respawn" option, which one can use in inittab.
You would never use inittab to start services, and inittab doesn't even exist anymore.
inittab is an integral part of SysV, AFAIK. I hope they'll both continue to exist.
Writing a second cron-job to respawn your service is a laborious mess, with unnecessary overhead. SNMP or other monitoring is what we've been reduced to, but who the hell wants to pay for around-the-clock employees, or get paged in the middle of the night, just because a few services might need to be restarted? And let's not forget, CROND CRASHES, TOO. What's monitoring cron and keeping it running?
Of course, one builds on the groundwork that has been laid before. Unless you're modifying crond itself, you have a pretty reliable, fully debugged daemon that you can depend upon. Reusing stuff that works well has proved to be a winning *nix philosophy.
I admit that writing a daemon has its nuisances, such as becoming session leader, or detaching from terminal, which may sound esoteric. But they are just initialization trivia. By comparison, a Windows service needs a dedicated thread for the sole purpose of keeping a conversation with the service manager, so that the latter can pass the buck to the former for estimating how long is the service taking to start or stop. All that complication and additional failure points are not aimed at increasing the system reliability, but at providing a uniform graphical interface. Such interface can presumably fool unexperienced users into thinking that the system is overall more sound.
As a matter of fact, Windows is more unstable and requires many more reboots than Linux. I don't think Debian should strive to resemble Windows NT more closely. The area where Windows definitely beats Linux is marketing, not software development. That is the reason why Windows boxes are many more than any other server or desktop system. If you really think Windows is technically better, you should use that instead of Linux until you are sure that your opinion was wrong.
I recall MySQL having a wrapper that used to take care of this. I agree respawning is critical, but so is debugging and fixing. There is a "respawn" option, which one can use in inittab. Normally, it is only used to fire up console terminals, as that affects the system accessibility itself. For other critical services, one can choose among wrappers, cron jobs, monitoring via syslog or SNMP, inter-process communication, and more. Do you argue we should stop using such techniques and go for a one-size-fits-all, infallible system? It sounds rather chimerical...
Debian has a habit of not using things until they work. I expect they would fix most of the issues or they wouldn't ship it.
You mean they used to have such habit. IME, upgrading to wheezy broke so much stuff that it took weeks to recover (partially). Most failures originated because the dependencies implied by the renumbering of rc.d scripts were wrong. That renumbering is non-working, non-maintainable, non-adjustable, non-human. The time saved by parallel start, if any, is dwarfed by the time needed to figure out what went on during boot.
Those SysV difficulties and obtusity are due to the fact that it does as it's told, without trying to interpret or guess. That's what makes it reliable.
I agree that is not ideal for users who do not want to know how their system works under the hood. They need some sort of automated sysadmin that solves issues correctly most of the times, and will have to relay on a repair shop for the remaining cases. How came those two different things have been conflated and considered as alternatives to one another?
systemd is the one of the worst thing Ive seen on Linux but it did get me back to my old friend Slackware after many years.
Would you consider Slackware a good alternative even if it weren't an old friend of yours? I mean, do you recommend it? Won't it switch to systemd in turn?
With udev being phased out in favor of systemd performing those tasks we'll have to make the decision at some point between whether we want to try to maintain udev ourselves, have systemd replace just udev's functions, or if we want the whole kit and caboodle.
SysV initscripts have had their day and it's time to move on.
What is nice of SysV (I hope I shouldn't have said was) is its modularity. It can be minimal, and I like to type "startx" with my fingers, after the bootstrap has completed and I know all the important daemons are up and running.
I don't see the need to break SysV by forcibly throwing in something else, which is less reliable. We could have wrapped any bunch of init scripts into some event-based, super-duper, concurrent daemon running on top of init. That would have left users a choice, making laptops boot faster while not disrupting servers.
And this is their opportunity to become the next big energy suppliers as oil runs out.
Relying on a few large providers is a trait nukes share with oil, indeed. Carrying around electricity implies some inefficiency, while carrying oil implies pollution. The reason why I don't like this model, however, is that it doesn't promote autonomy.
The other thing is nuclear waste. As it lasts thousands of years, I cannot believe that the ultimate cost of storing it has been evaluated, not even to an approximation of three orders of magnitude. We don't even know what language people will speak 5000 years from now, so how can we explain them that they have to pay the debt we took out?
It is great news that people opt to steal code rather than money, even from banks. I look forward to replacing conservation laws with suitable information-based statements, for a coherent vision of the universe.
People don't hide from their lovers. Privacy is needed against exploiters who trace your habits in order to tailor an environment where you have to satisfy your needs according to their convenience rather than yours.
Very cute observations! But then we need to preserve the Internet we just produced. If running a server is not a human right as well, accessing the Internet might become similar to getting wired to The Matrix.
Besides the fact that we all sometimes engage in psychoanalytical games, in the rest of the time we concede people their own freedom. For software, there are different schools of thought. One says that your property ends at your fingertips, everything else belongs to someone else. In particular, your PC, your phone, and any other electronic appliances you use belong to their vendors, who deserve the right to observe, guide, and censor whatever you do with them. Another school says that when you buy an appliance it becomes your own property. Since PCs are not believed to have free will, you don't feel a slave driver when you want them to do exactly as you say. You may consider them an extension of yourself.
Thats kind of where the end goal of programming languages needs to be
No end goal is defined. There is no such a thing as the ultimate programming language paradigm.
Actually, there is no need to distinguish between program data and instruction data. We do so as long as it's useful. However, the point of computing and communication is just to let data interact. I'd be tented to say that's the point of the Universe as well. Goals, if any, might state what the eventual global entropy is going to be, but that seems to be too far to make guesses.
RFC 5676: Definitions of Managed Objects for Mapping SYSLOG Messages to Simple Network Management Protocol (SNMP) Notifications
RFC 5848: Signed Syslog Messages
I'm not sure why the design proposed by Lennart Poettering and Kay Sievers would be better than upgrading syslog() so as to cover those standardizations. Proposers of an enhancement should take the trouble to standardize it, beside coding, experimenting, and evangelizing it.
The consent, and the proof that it was given, need to be made workable. In that case, it would be a useful law.
To be clear, the current Data Protection Directive disregards the Internet as a viable medium to obtain a subject's consent. EU businesses need to keep a signed piece of paper or a taped conversation, as evidence. That may make sense for data acquired off-line, but such principle is plainly unusable for data obtained on the web. I'm thinking email addresses: what we don't have is a consent-exchange Internet protocol for email users. Consider how easy it is to fake a double opt-in. Can you guess how a triple opt-in could solve that? If not, see here for an attempt.
An interesting exercise, aimed at sticking to the OP's concern, is to search for the word "government" in the links you mention. I only quote RMS':
If Microsoft, or the US government, does not like what you said in a document you wrote, they could post new instructions telling all computers to refuse to let anyone read that document. Each computer would obey when it downloads the new instructions. Your writing would be subject to 1984-style retroactive erasure.
However, this key-sharing conspiracy has not yet been committed by any specific government, has it?
Slashdot Mirror
Hm... the key is defining such "sensible way to ignore the specifics of other scripts". Stated that way, it would seem that operators can choose what they want to ignore and what they want to deal with. Those who operate static systems are badly affected by the arbitrary changes that parallel start introduces in the order that init scripts are run, so not everything is reliable when incompatible changes come through. Couldn't it have been done smoothly?
Did they name it "daemontools"?
It's called mysqld_safe. You may consider it a hack, but it has some features, such as checking for corrupted storage, that would be completely useless for, say, a read-only web server.
You would never use inittab to start services, and inittab doesn't even exist anymore.
inittab is an integral part of SysV, AFAIK. I hope they'll both continue to exist.
Writing a second cron-job to respawn your service is a laborious mess, with unnecessary overhead. SNMP or other monitoring is what we've been reduced to, but who the hell wants to pay for around-the-clock employees, or get paged in the middle of the night, just because a few services might need to be restarted? And let's not forget, CROND CRASHES, TOO. What's monitoring cron and keeping it running?
Of course, one builds on the groundwork that has been laid before. Unless you're modifying crond itself, you have a pretty reliable, fully debugged daemon that you can depend upon. Reusing stuff that works well has proved to be a winning *nix philosophy.
I admit that writing a daemon has its nuisances, such as becoming session leader, or detaching from terminal, which may sound esoteric. But they are just initialization trivia. By comparison, a Windows service needs a dedicated thread for the sole purpose of keeping a conversation with the service manager, so that the latter can pass the buck to the former for estimating how long is the service taking to start or stop. All that complication and additional failure points are not aimed at increasing the system reliability, but at providing a uniform graphical interface. Such interface can presumably fool unexperienced users into thinking that the system is overall more sound.
As a matter of fact, Windows is more unstable and requires many more reboots than Linux. I don't think Debian should strive to resemble Windows NT more closely. The area where Windows definitely beats Linux is marketing, not software development. That is the reason why Windows boxes are many more than any other server or desktop system. If you really think Windows is technically better, you should use that instead of Linux until you are sure that your opinion was wrong.
I recall MySQL having a wrapper that used to take care of this. I agree respawning is critical, but so is debugging and fixing. There is a "respawn" option, which one can use in inittab. Normally, it is only used to fire up console terminals, as that affects the system accessibility itself. For other critical services, one can choose among wrappers, cron jobs, monitoring via syslog or SNMP, inter-process communication, and more. Do you argue we should stop using such techniques and go for a one-size-fits-all, infallible system? It sounds rather chimerical...
Debian has a habit of not using things until they work. I expect they would fix most of the issues or they wouldn't ship it.
You mean they used to have such habit. IME, upgrading to wheezy broke so much stuff that it took weeks to recover (partially). Most failures originated because the dependencies implied by the renumbering of rc.d scripts were wrong. That renumbering is non-working, non-maintainable, non-adjustable, non-human. The time saved by parallel start, if any, is dwarfed by the time needed to figure out what went on during boot.
Those SysV difficulties and obtusity are due to the fact that it does as it's told, without trying to interpret or guess. That's what makes it reliable.
I agree that is not ideal for users who do not want to know how their system works under the hood. They need some sort of automated sysadmin that solves issues correctly most of the times, and will have to relay on a repair shop for the remaining cases. How came those two different things have been conflated and considered as alternatives to one another?
SysV needs to be replaced because it's too simple to be able to respawn crashed services.
Fixing the services which crash would seem to be a better option than busting SysV.
systemd is the one of the worst thing Ive seen on Linux but it did get me back to my old friend Slackware after many years.
Would you consider Slackware a good alternative even if it weren't an old friend of yours? I mean, do you recommend it? Won't it switch to systemd in turn?
Thus spoke Patrick Volkerding in a July 2012 interview:
SysV initscripts have had their day and it's time to move on.
What is nice of SysV (I hope I shouldn't have said was) is its modularity. It can be minimal, and I like to type "startx" with my fingers, after the bootstrap has completed and I know all the important daemons are up and running.
I don't see the need to break SysV by forcibly throwing in something else, which is less reliable. We could have wrapped any bunch of init scripts into some event-based, super-duper, concurrent daemon running on top of init. That would have left users a choice, making laptops boot faster while not disrupting servers.
Relying on a few large providers is a trait nukes share with oil, indeed. Carrying around electricity implies some inefficiency, while carrying oil implies pollution. The reason why I don't like this model, however, is that it doesn't promote autonomy.
The other thing is nuclear waste. As it lasts thousands of years, I cannot believe that the ultimate cost of storing it has been evaluated, not even to an approximation of three orders of magnitude. We don't even know what language people will speak 5000 years from now, so how can we explain them that they have to pay the debt we took out?
It took five centuries to pardon Galileo. How much smarter do we expect the UK government to be?
It is great news that people opt to steal code rather than money, even from banks. I look forward to replacing conservation laws with suitable information-based statements, for a coherent vision of the universe.
People don't hide from their lovers. Privacy is needed against exploiters who trace your habits in order to tailor an environment where you have to satisfy your needs according to their convenience rather than yours.
Very cute observations! But then we need to preserve the Internet we just produced. If running a server is not a human right as well, accessing the Internet might become similar to getting wired to The Matrix.
Besides the fact that we all sometimes engage in psychoanalytical games, in the rest of the time we concede people their own freedom. For software, there are different schools of thought. One says that your property ends at your fingertips, everything else belongs to someone else. In particular, your PC, your phone, and any other electronic appliances you use belong to their vendors, who deserve the right to observe, guide, and censor whatever you do with them. Another school says that when you buy an appliance it becomes your own property. Since PCs are not believed to have free will, you don't feel a slave driver when you want them to do exactly as you say. You may consider them an extension of yourself.
Thats kind of where the end goal of programming languages needs to be
No end goal is defined. There is no such a thing as the ultimate programming language paradigm.
Actually, there is no need to distinguish between program data and instruction data. We do so as long as it's useful. However, the point of computing and communication is just to let data interact. I'd be tented to say that's the point of the Universe as well. Goals, if any, might state what the eventual global entropy is going to be, but that seems to be too far to make guesses.
Yes, besides RFC 5424..5427, there are also
I'm not sure why the design proposed by Lennart Poettering and Kay Sievers would be better than upgrading syslog() so as to cover those standardizations. Proposers of an enhancement should take the trouble to standardize it, beside coding, experimenting, and evangelizing it.
The consent, and the proof that it was given, need to be made workable. In that case, it would be a useful law. To be clear, the current Data Protection Directive disregards the Internet as a viable medium to obtain a subject's consent. EU businesses need to keep a signed piece of paper or a taped conversation, as evidence. That may make sense for data acquired off-line, but such principle is plainly unusable for data obtained on the web. I'm thinking email addresses: what we don't have is a consent-exchange Internet protocol for email users. Consider how easy it is to fake a double opt-in. Can you guess how a triple opt-in could solve that? If not, see here for an attempt.
An interesting exercise, aimed at sticking to the OP's concern, is to search for the word "government" in the links you mention. I only quote RMS':
However, this key-sharing conspiracy has not yet been committed by any specific government, has it?