So throw out all software that depends on a API designed after 1970? No need for SQL-servers because SQL is not a fundamental Unix API, no need for REST/SOAP services because neither is a fundamental Unix API. Seriously now you are just being obtuse, I get that you don't like systemd and I'm fine with that but please don't go completely overboard now.
I've been referring to both the whole time. Monsanto have made a pledge to not sue for accidental contamination and only sue for deliberate violations. The anti-GMO lobbies however have always claimed that Monsanto someday will sue everybody for accidental contamination and did file court case against Monsanto prohibiting them from suing for accidental contamination (this is the case that you linked to several times on your article searches) a case that was thrown out by first the court and then the appeals court since the Monsanto pledge is valid as evidence if Monsanto ever would try that route.
Sorry to make such a small reply to your long wall of text but I just wanted to clarify that when I wrote "just another kernel" I meant from the viewpoint of the Linux userland. E.g WSL is not a Linux distribution running in a VM but a Linux distribution running 100% natively (e.g there are no hypervisor involved [sw or hw]) with another Kernel (e.g the Windows Kernel instead of the Linux Kernel).
No, the only thing that you have to clone is the D-BUS namespace, which of course is the exact same for any other situation where you can replace tools in the Unix-way. It's not like you could replace e.g sed with a tool that no longer listens to stdin and cannot understand space separated strings.
Yeah I'm sure that South Korea had nothing at all to do with the peace talks. Of course it was God Emperor Trump that scared Kim Jong-Un into submission.
Ok I take your word for it, but actually this sounds more to be a problem with the raspberry upgrade system. I manage hundreds of servers and desktops in the financial industry and have not had a single systemd related problem when upgrading any of them. And if the startup-order is wrong then that sounds like the unit file dependencies have an error somewhere, I guess that you use a network drive to store the nginx and mysql databases considering the problems that you see? And that could be one difference since I do not use any networked drives for such things.
But using start-stop-daemon on upstart would be a complete waste of time as well... Personally I found "man systemd.unit" to be quite good but then if people are using start-stop-daemon under upstart then I don't know if any documentation would save them.
If you don't see logs from early boot on RAID issues then check the unit files for the tools that set up your raid, there is a chance that they are set up in a stupid way that disables logging from these tools. Because anything that comes out of a tool when run under systemd regardless of if it's from stdout, stderr or syslog is captured and sent to the journal.
But unfortunately some maintainers create faulty unit files here. I have seen some where the daemon is invoked with arguments like "--quiet" which of course makes the daemon create no log output at all. Another example is mediatomb where the unit-file from debian makes it log to "/var/log/mediatomb" instead of just letting it log to stdout which means that "journalctl -u mediatom.service" only yields the logs from systemd when it starts and stops the deamon which looks like logs are dropped but instead they are stored differently.
But mounting root at that stage is not the work of any init so if I have to guess the problem that you experienced with the degraded btrfs has to do with the initramfs image on your distribution and not with systemd, but having not seen this myself I will of course not say that systemd had nothing to do with it but it sounds odd since / is mounted before init is called by the booting kernel. And I've read many storied about default initramfs:s having trouble with degraded raid1 btrfs so I think you blamed systemd too early there.
Gnome are not vendor locked-in, their dependency upon logind is #1 something that can be disabled with a compile-flag and #2 the dependency is on the logind DBUS namespace and thus anyone can implement something that speaks that namespace (which is how the BSDs implemented it on their end). And the logind thing solves a problem for Gnome which is why they choose to go with it.
In the long term, that's bad for Linux. There's no reason that everything systemd does couldn't have been done the Unix way with smaller interchangeable tools that could inter-operate.
Which accidentally is just how the various systemd are implemented, it's a bunch of smaller interchangeable applications that inter-operate via DBUS. The only dependecy each tool have is the DBUS namespace so as long as you implement that you can change each and every systemd tool.
On the other hand the networks where we in the financial industry use multicast is all over private lines anyways so address contention is not a problem there and thus IPv4 is no problem there either.
Sorry, but Slashdot gave me " No matches found. Try a different search or head back to the main stories. ". However I use BTRFS in a RAID1 configuration with Ubuntu+systemd on several of our servers without any issue so it seams to work for me, which of course is not the same thing that it works for you. Should I also write down every single time sysv init failed me on various configurations?
Since you pay a fixed price for the Red Hat support (with their subscription model). Wouldn't it be in RH:s best interest to keep the number of calls down in order to keep the profits up? Now if they would have charged per case then it would have been a completely different situation but they don't.
Except of course that you pay a fixed price for the Red Hat support so the more calls you have to make to them the less Red Hats profits from said subscription.
They are talking about "systemctl start XXX" returning 0 when XXX fails to start. This is always due to XXX failing after it forks so systemctl does not see the failure before it has already done it's thing.
Lot's of the older sysv init scripts contains lots of pre-flight tests on daemons where the script writes knew that the daemon would fork first and look for configuration files etc later and then when the unit files where created these pre-flight checks where removed (but there is nothing that prevents a unit file from having pre-flight checks) by maintainers that didn't fully understand why these checks where there.
But there is no evidence, just anonymous anecdotes from people who claim to have switched to BSD for ages ago but still seam to comment on every Linux article they find.
Except of course that none of this is true. If "systemctl start XXX" returns 0 when the XXX fails then that is because XXX failed after systemd did it's thing, often this can be traced back to the old start script performing pre-launch checks that the new unit file does not have (i.e the people who wrote the unit file didn't do a proper job).
Slashdot Mirror
So throw out all software that depends on a API designed after 1970? No need for SQL-servers because SQL is not a fundamental Unix API, no need for REST/SOAP services because neither is a fundamental Unix API. Seriously now you are just being obtuse, I get that you don't like systemd and I'm fine with that but please don't go completely overboard now.
I've been referring to both the whole time. Monsanto have made a pledge to not sue for accidental contamination and only sue for deliberate violations. The anti-GMO lobbies however have always claimed that Monsanto someday will sue everybody for accidental contamination and did file court case against Monsanto prohibiting them from suing for accidental contamination (this is the case that you linked to several times on your article searches) a case that was thrown out by first the court and then the appeals court since the Monsanto pledge is valid as evidence if Monsanto ever would try that route.
Sorry to make such a small reply to your long wall of text but I just wanted to clarify that when I wrote "just another kernel" I meant from the viewpoint of the Linux userland. E.g WSL is not a Linux distribution running in a VM but a Linux distribution running 100% natively (e.g there are no hypervisor involved [sw or hw]) with another Kernel (e.g the Windows Kernel instead of the Linux Kernel).
No, the only thing that you have to clone is the D-BUS namespace, which of course is the exact same for any other situation where you can replace tools in the Unix-way. It's not like you could replace e.g sed with a tool that no longer listens to stdin and cannot understand space separated strings.
When I made that post these where the only post to the article:
https://apple.slashdot.org/com...
https://apple.slashdot.org/com...
https://apple.slashdot.org/com...
https://apple.slashdot.org/com...
And a few others that where replies to them but that is how it looked when I made the post, now there have of course been added quite a few others.
Yeah I'm sure that South Korea had nothing at all to do with the peace talks. Of course it was God Emperor Trump that scared Kim Jong-Un into submission.
Ok I take your word for it, but actually this sounds more to be a problem with the raspberry upgrade system. I manage hundreds of servers and desktops in the financial industry and have not had a single systemd related problem when upgrading any of them. And if the startup-order is wrong then that sounds like the unit file dependencies have an error somewhere, I guess that you use a network drive to store the nginx and mysql databases considering the problems that you see? And that could be one difference since I do not use any networked drives for such things.
But using start-stop-daemon on upstart would be a complete waste of time as well... Personally I found "man systemd.unit" to be quite good but then if people are using start-stop-daemon under upstart then I don't know if any documentation would save them.
If you don't see logs from early boot on RAID issues then check the unit files for the tools that set up your raid, there is a chance that they are set up in a stupid way that disables logging from these tools. Because anything that comes out of a tool when run under systemd regardless of if it's from stdout, stderr or syslog is captured and sent to the journal.
But unfortunately some maintainers create faulty unit files here. I have seen some where the daemon is invoked with arguments like "--quiet" which of course makes the daemon create no log output at all. Another example is mediatomb where the unit-file from debian makes it log to "/var/log/mediatomb" instead of just letting it log to stdout which means that "journalctl -u mediatom.service" only yields the logs from systemd when it starts and stops the deamon which looks like logs are dropped but instead they are stored differently.
Now yes but of course I meant how it looked when I posted, is that so hard to fathom?
But mounting root at that stage is not the work of any init so if I have to guess the problem that you experienced with the degraded btrfs has to do with the initramfs image on your distribution and not with systemd, but having not seen this myself I will of course not say that systemd had nothing to do with it but it sounds odd since / is mounted before init is called by the booting kernel. And I've read many storied about default initramfs:s having trouble with degraded raid1 btrfs so I think you blamed systemd too early there.
Gnome are not vendor locked-in, their dependency upon logind is #1 something that can be disabled with a compile-flag and #2 the dependency is on the logind DBUS namespace and thus anyone can implement something that speaks that namespace (which is how the BSDs implemented it on their end). And the logind thing solves a problem for Gnome which is why they choose to go with it.
In the long term, that's bad for Linux. There's no reason that everything systemd does couldn't have been done the Unix way with smaller interchangeable tools that could inter-operate.
Which accidentally is just how the various systemd are implemented, it's a bunch of smaller interchangeable applications that inter-operate via DBUS. The only dependecy each tool have is the DBUS namespace so as long as you implement that you can change each and every systemd tool.
And exactly where in my post did I write that OS x was better than OS y? Try again.
On the other hand the networks where we in the financial industry use multicast is all over private lines anyways so address contention is not a problem there and thus IPv4 is no problem there either.
WSL is not a VM, it is bare-metal just with another kernel.
So that is why all the posts so far have been from butthurt appleboys... Fail to see your logic there.
Sorry, but Slashdot gave me " No matches found. Try a different search or head back to the main stories. ". However I use BTRFS in a RAID1 configuration with Ubuntu+systemd on several of our servers without any issue so it seams to work for me, which of course is not the same thing that it works for you. Should I also write down every single time sysv init failed me on various configurations?
Wait, they used start-stop-daemon in a unit file, WTF?
You mean like dropping logs and not providing a proper exit status? Both of which are false btw.
So if we find another guy who have had just a single problem with systemd then that will immediately change your mind and you will switch to systemd?
Since you pay a fixed price for the Red Hat support (with their subscription model). Wouldn't it be in RH:s best interest to keep the number of calls down in order to keep the profits up? Now if they would have charged per case then it would have been a completely different situation but they don't.
Except of course that you pay a fixed price for the Red Hat support so the more calls you have to make to them the less Red Hats profits from said subscription.
And which secret sauce in BSD protects a third party daemon like say apache or sendmail from bugs as compare with when they execute on another OS?
They are talking about "systemctl start XXX" returning 0 when XXX fails to start. This is always due to XXX failing after it forks so systemctl does not see the failure before it has already done it's thing.
Lot's of the older sysv init scripts contains lots of pre-flight tests on daemons where the script writes knew that the daemon would fork first and look for configuration files etc later and then when the unit files where created these pre-flight checks where removed (but there is nothing that prevents a unit file from having pre-flight checks) by maintainers that didn't fully understand why these checks where there.
But there is no evidence, just anonymous anecdotes from people who claim to have switched to BSD for ages ago but still seam to comment on every Linux article they find.
Except of course that none of this is true. If "systemctl start XXX" returns 0 when the XXX fails then that is because XXX failed after systemd did it's thing, often this can be traced back to the old start script performing pre-launch checks that the new unit file does not have (i.e the people who wrote the unit file didn't do a proper job).