You should take a look in/usr/share/doc/ same day, just saying. Kudos btw for complaining on Slashdot of all places that there might be rude people on forums;-)
It's because they have no freeze periods during the Alpha stages, the 'Final' prefix is there to mark that it's the Final Beta Freeze and Final Release Freeze.
Well if you only care about deamons that you write your self then yes this is a no problem as you write but as a distribution one have to think about all those strange and different daemons out there.
Of course, systemd isn't a perfect solution either. For example, if a daemon forks and exits and then the child process gets stuck but doesn't terminate, systemd won't know about it. A custom restarter could check for that condition as needed.
For the random daemon out there yes but it the daemon supports systemd it can send heartbeats to systemd with "sd_notify (0, "WATCHDOG=1");" in order to catch a stalled deamon. systemd itself can also send heartbeats upwards to a harware watchdog so your whole server gets a reboot if the whole system stalls.
pid-matching is needed in the situation where the underlying deamon forks and thus the daemon is running as a grandchild to your monitoring process. Then the only way that your process can see if the grandchild is running is to check if the pid that it stored in a pid-file is running, however due to the limited space of pids (they are only 16 bits) there can spawn a different process that gets the same pid as your grandchild between the moment the grandchild crashes and your process detects that it's down which would make your monitoring process erroneously believe that the grandchild is still running.
This all becomes moot of course if you are init since you then have complete control over grandchildren, even more so if you also are the cgroups master.
And if it never got the SIGCHLD since signals does not have a delivery guarantee under any OS how well does your 10-line fork+execve+waitpid program work then?
And what if the daemon in question does a fork of it's own then your 10-liner gets the SIGCHLD while the daemon is running just fine and you will never get the SIGCHLD from the grandchild so you now have to add several lines more to read in a pid file and also hope that the daemon in question stores the running pid in such a file and further you have to hope that of the grandchild dies then another process that is spawned in between does not get the same pid as your grandchild. At the same time something like systemd handles all these corner cases and more due to it actually being init and not a separate process/script.
In short, the reason to implement functionality such as this into either systemd or upstart is for the distro maintainers to be able to support respawning for all different kinds of strange daemons. I get that you #1 don't want respawning to begin with and #2 only have to support a handful of such daemons but I do hope that you understand that there are others with complete different needs than yours?
Otherwise we end up with horrendous examples like the mysqld_safe script which was Oracle/SUNs try at doing this distro agnostic with sysvinit. They didn't exactly succeed to put it mildly.
Of course you can, but you also have to write quite a bit of shell script in order to do that and not just alter a simple setting. And you would still fall through all manners of possible problems with pid-matching and so on that have plagued any such prior attempt via inittab.
For this particular little feature of something like systemd and upstart yes, but then you have to make your solution distro agnostic, work with daemons that fork or not fork, that crashes in such a way that it brings the shell down with it and all of a sudden that small and simple program is not so small and simple any more.
However handing respawning via inittab is like wielding a sledgehammer in a glass shop. With systemd you can enable/disable this with a easy setting on a per daemon basis and also define "only respawn X number of times during Y number of seconds" among other things.
Regarding your second opinion I tend to agree, however there exists plenty of daemons/services where a pure restart does no real harm (say a webserver, dns server and so on) and one does not exclude the other, i.e just because your daemons respawn automatically does not mean that you also dos not look into why they did.
AFAIK the new major of Munich boasts that he was the one responsible for Microsoft relocating their German HQ from Frankfurt to Munich so this is most definitely political and not technical.
That is that the people from India say when they call and tell me that I apparantly have a problem with my computer that needs to be fixed by installing some trojan of theirs: "Hello I'm calling from Windows".
If you think that journald resembles the Event Viewer design then you have not used or developer for either one. Just because journald happens to use a binary storage format does not make it anywhere like the mess that is Event Viewer. EW is designed to handle 1-2 logs per minute with a huge dose of NIH syndrome regarding GNU gettext.
Well to be honest this only happened in Stockholm and was not called Feminist Snow Plowing but Equal Snow Plowing in which walking- and bike-lanes as well as roads used by the public transport where prioritized over car roads. And the blog that you link to is kind of fake news because the snow chaos that happened in Stockholm was not due to this new prioritizing but that there came more snow than anticipated so the people in charge of the plowing where slow to start.
It's even sidestepped far earlier since no terrorist worth their name would go through customs with a "secret evil terrorist mode" on their phone in the first place, these people know that they can be searched and forced to give up their pin and thus plan accordingly.
Also the content might be owned by different entities depending upon country. For example Pt1 of Friday the 13th (the original from 1980) is owned by Warner in Europe and by Paramount in the US (which is why we got the uncut version on DVD/BluRay in Europe).
I don't think that the EU even in theory can demand that a US citizen have access to the US content while travelling in the EU, they might somehow be able to demand that said customer should have access to the EU content but not the US one unless the US data is stored on servers located within the EU.
Netflix content is currently based on the location of the connection since that is what the content owners have forced them to do, now the EU is talking about implementing new laws that says that Netflix (among others) have to base it on the location of the account instead.
The sine sinc is not a low pass filter, it's the reverse of the sampling. With it you can recreate 100% every sound wave that you sampled as long as the source is within the ranges I described. The quantization noise for music is so low that no human can distinguish between the raw source and the CD version as long as volume levels are properly adjusted for. So while the signal might not be 100% identical it is 100% identical as far as the human ears are concerned.
By your own links the number of reported rapes have gone from 4208 in 2005 to 5918 in 2015, that is in increase by 41% and not 1500%.
Your second link for the "reported gang rapes" says that this was a measurement up to 2006 which is long before the current migration that you are talking about. Also it talks about alcohol being the main culprit, that the legal definition change that GP talked about explains some of the increases and so on.
The main problem with SACD is that the idiotic design that it uses (DSD) means that it has extremely high resolution where it does not matter (in the lower frequencies) while the resolution deteriorates as the frequency gets higher while a PCM format have equal resolution throughout the entire frequency range. The 16-bits, 44.2Khz sampling rate of the CD is enough to reproduce with 100% accuracy any source signal that is in the 0-22.1Khz range. The only thing that SACD gives you here is that it can reproduce higher frequencies (up to roughly 50Khz before the limits of the DSD kicks in) and that the dynamic range is increased from 96dB to 120dB, I have a really hard time understanding the need for that though in regards to music play back.
This is also why there to this date have yet not been a single Double Blinded ABX Test where people could distinguish between a SACD/DVD-A source and the same source sampled to 16-bits 44.2Khz and played back again.
Slashdot Mirror
You should try out Might Number 9 on the Wii U some day.
You should take a look in /usr/share/doc/ same day, just saying. Kudos btw for complaining on Slashdot of all places that there might be rude people on forums ;-)
Hey, you forgot about the Keyboard Warriors! Surely they must be the fiercest of them all.
It's because they have no freeze periods during the Alpha stages, the 'Final' prefix is there to mark that it's the Final Beta Freeze and Final Release Freeze.
Why would that be so hard to understand?
The Ubuntu release schedule is and have always been:
Well if you only care about deamons that you write your self then yes this is a no problem as you write but as a distribution one have to think about all those strange and different daemons out there.
Of course, systemd isn't a perfect solution either. For example, if a daemon forks and exits and then the child process gets stuck but doesn't terminate, systemd won't know about it. A custom restarter could check for that condition as needed.
For the random daemon out there yes but it the daemon supports systemd it can send heartbeats to systemd with "sd_notify (0, "WATCHDOG=1");" in order to catch a stalled deamon. systemd itself can also send heartbeats upwards to a harware watchdog so your whole server gets a reboot if the whole system stalls.
pid-matching is needed in the situation where the underlying deamon forks and thus the daemon is running as a grandchild to your monitoring process. Then the only way that your process can see if the grandchild is running is to check if the pid that it stored in a pid-file is running, however due to the limited space of pids (they are only 16 bits) there can spawn a different process that gets the same pid as your grandchild between the moment the grandchild crashes and your process detects that it's down which would make your monitoring process erroneously believe that the grandchild is still running.
This all becomes moot of course if you are init since you then have complete control over grandchildren, even more so if you also are the cgroups master.
And if it never got the SIGCHLD since signals does not have a delivery guarantee under any OS how well does your 10-line fork+execve+waitpid program work then?
And what if the daemon in question does a fork of it's own then your 10-liner gets the SIGCHLD while the daemon is running just fine and you will never get the SIGCHLD from the grandchild so you now have to add several lines more to read in a pid file and also hope that the daemon in question stores the running pid in such a file and further you have to hope that of the grandchild dies then another process that is spawned in between does not get the same pid as your grandchild. At the same time something like systemd handles all these corner cases and more due to it actually being init and not a separate process/script.
In short, the reason to implement functionality such as this into either systemd or upstart is for the distro maintainers to be able to support respawning for all different kinds of strange daemons. I get that you #1 don't want respawning to begin with and #2 only have to support a handful of such daemons but I do hope that you understand that there are others with complete different needs than yours?
Otherwise we end up with horrendous examples like the mysqld_safe script which was Oracle/SUNs try at doing this distro agnostic with sysvinit. They didn't exactly succeed to put it mildly.
Of course you can, but you also have to write quite a bit of shell script in order to do that and not just alter a simple setting. And you would still fall through all manners of possible problems with pid-matching and so on that have plagued any such prior attempt via inittab.
Well some of that 172 bucks was spent locally for transportation, payment, shipping and so on. So 100% is not lost.
For this particular little feature of something like systemd and upstart yes, but then you have to make your solution distro agnostic, work with daemons that fork or not fork, that crashes in such a way that it brings the shell down with it and all of a sudden that small and simple program is not so small and simple any more.
Well just for fun is how I would describe the "just restart it!" crowd that AC was talking about so I don't see your problem.
Which have nothing to do with the issue at hand, this is about respawning crashed/downed services and not respawning just for fun.
However handing respawning via inittab is like wielding a sledgehammer in a glass shop. With systemd you can enable/disable this with a easy setting on a per daemon basis and also define "only respawn X number of times during Y number of seconds" among other things.
Regarding your second opinion I tend to agree, however there exists plenty of daemons/services where a pure restart does no real harm (say a webserver, dns server and so on) and one does not exclude the other, i.e just because your daemons respawn automatically does not mean that you also dos not look into why they did.
AFAIK the new major of Munich boasts that he was the one responsible for Microsoft relocating their German HQ from Frankfurt to Munich so this is most definitely political and not technical.
That is that the people from India say when they call and tell me that I apparantly have a problem with my computer that needs to be fixed by installing some trojan of theirs: "Hello I'm calling from Windows".
If you think that journald resembles the Event Viewer design then you have not used or developer for either one. Just because journald happens to use a binary storage format does not make it anywhere like the mess that is Event Viewer. EW is designed to handle 1-2 logs per minute with a huge dose of NIH syndrome regarding GNU gettext.
Well to be honest this only happened in Stockholm and was not called Feminist Snow Plowing but Equal Snow Plowing in which walking- and bike-lanes as well as roads used by the public transport where prioritized over car roads. And the blog that you link to is kind of fake news because the snow chaos that happened in Stockholm was not due to this new prioritizing but that there came more snow than anticipated so the people in charge of the plowing where slow to start.
It's even sidestepped far earlier since no terrorist worth their name would go through customs with a "secret evil terrorist mode" on their phone in the first place, these people know that they can be searched and forced to give up their pin and thus plan accordingly.
Also the content might be owned by different entities depending upon country. For example Pt1 of Friday the 13th (the original from 1980) is owned by Warner in Europe and by Paramount in the US (which is why we got the uncut version on DVD/BluRay in Europe).
I don't think that the EU even in theory can demand that a US citizen have access to the US content while travelling in the EU, they might somehow be able to demand that said customer should have access to the EU content but not the US one unless the US data is stored on servers located within the EU.
Netflix content is currently based on the location of the connection since that is what the content owners have forced them to do, now the EU is talking about implementing new laws that says that Netflix (among others) have to base it on the location of the account instead.
The sine sinc is not a low pass filter, it's the reverse of the sampling. With it you can recreate 100% every sound wave that you sampled as long as the source is within the ranges I described. The quantization noise for music is so low that no human can distinguish between the raw source and the CD version as long as volume levels are properly adjusted for. So while the signal might not be 100% identical it is 100% identical as far as the human ears are concerned.
By your own links the number of reported rapes have gone from 4208 in 2005 to 5918 in 2015, that is in increase by 41% and not 1500%.
Your second link for the "reported gang rapes" says that this was a measurement up to 2006 which is long before the current migration that you are talking about. Also it talks about alcohol being the main culprit, that the legal definition change that GP talked about explains some of the increases and so on.
The main problem with SACD is that the idiotic design that it uses (DSD) means that it has extremely high resolution where it does not matter (in the lower frequencies) while the resolution deteriorates as the frequency gets higher while a PCM format have equal resolution throughout the entire frequency range. The 16-bits, 44.2Khz sampling rate of the CD is enough to reproduce with 100% accuracy any source signal that is in the 0-22.1Khz range. The only thing that SACD gives you here is that it can reproduce higher frequencies (up to roughly 50Khz before the limits of the DSD kicks in) and that the dynamic range is increased from 96dB to 120dB, I have a really hard time understanding the need for that though in regards to music play back.
This is also why there to this date have yet not been a single Double Blinded ABX Test where people could distinguish between a SACD/DVD-A source and the same source sampled to 16-bits 44.2Khz and played back again.