Way too many times I have had a service that didn't start and there was no way of figuring out WHY, nothing in/var/log/messages or dmesg. (The normal places to look for problems)
As provided by some elsewhere in the comments systemd has a binary log that has a completely different command to access, which means that it's hard to look up related events in that log compared to/var/log/messages.
No advantage as far as I can see compared to syslog and the ordinary text tools. Just a way to force the use of binary file processing tools and as soon as something pukes in the binary file it may be completely unreadable. A text file might not look good after a puke but it's still mostly readable.
Then you haven't had problems trying to figure out WTF systemd is doing on a box. No logs means that it's taking hours to figure out what the problem is - and the problem can be a missing option in a config file that's needed for systemd operation where the error message is thrown away by systemd.
No, you are the one that's out of touch with some of the more powerful tools for managing text information.
Instead of complaining as an AC and downmodding then I say that you instead should provide us with good information about how to handle the problem of non-existing text logs and missing stderr outputs. The non-existence of them means that problem solving has become a lot harder.
If I had modpoints I would have modded up this. Those tools are one of the core tools that every decent admin and *nix user shall know. They are way more powerful than most GUI softwares that have been written ever. Only 'vim' may be a contender there.
Systemd makes server administration a lot harder - almost a nightmare. There's no way to see how stuff is related anymore, while with init you could see it with a quick glance using ls.
And if you add your own stuff it's not easier, it's darn hard.
It's probably better to have only sensitive stuff encrypted and hidden, that way it will be harder to determine if it contains interesting stuff. You may feed cops with some information, but only information that they essentially can figure out anyway.
The deal is that when it comes to Government it's a Budget concern. They need to follow The Budget at any price, no matter what, and if they need to buy it back with money then they need to have An Account.
A lot of other action can be absorbed into the daily work, but as soon as you purchase something it must be on The Budget and there nut be An Account for said purchase.
You discount the possibility that the junk yard owner actually could make a great PR event of it, good reputation is often way better in the long run than just the money involved.
Considering that junkyards today are pretty detailed about separation of items depending on metal type and sometimes even alloys they need to identify what they are working with to put stuff in the right bucket. Unusual devices requires extra consideration not only from the perspective of metals but also from hazardous material.
Junkyards are no longer a local hobo operation but actually pretty detailed in what they do - and regulated. So if stuff ends up from someone that do have some unusual labeling like NASA or so then they will at least take a second look. They usually want to make sure that they avoid the Cobalt-60 incident from December 1983 in Ciudad Juárez, Mexico and similar.
The same goes for a lot of software - clog your computer with bloatware like Chrome and whatever that I never use.
And at every upgrade the software package asks me to confirm that I agree to the current license version instead of just installing the update in the background silently to ensure that I get the latest security updates.
In addition to that Windows also enforces the UAC to make you confirm that the update installation is permitted. But in many cases this is problematic since it won't help many users that are out there, especially those with limited computer knowledge who either clicks "No" on everything or "Yes" on everything. In both cases it leads to bad results.
Well, it works for the main switch in a computer hall, but often power is only cut off on a circuit breaker for the circuits where the work is done, not the whole data center.
Unfortunately way too common. Often because the installation shall be cheap.
Turn it off, then do a short circuit to ground at the work position as well so if someone turns on the power then the fuse will blow. If they are unlucky then the main fuse will blow and that's going to make a mark in someone's report.
If it's really bad the UPS will die - and that will definitely make a mark in the budget for that year.
The five nine uptime is not counting planned stops. So you can at a datacenter have a planned stop for a month and still conform to the contract. But it wouldn't make sense.
There is a reason why clustered systems are used - one node goes down another takes over. That's good enough to provide decent uptimes in most cases.
But today with virtual servers it's often one huge single server, and that's a single point of failure system even if the server itself may have built in redundancy there are always something that can fail.
The lack of active maintenance is primarily caused by a small detail like a prison sentence.
Way too many times I have had a service that didn't start and there was no way of figuring out WHY, nothing in /var/log/messages or dmesg. (The normal places to look for problems)
As provided by some elsewhere in the comments systemd has a binary log that has a completely different command to access, which means that it's hard to look up related events in that log compared to /var/log/messages.
So essentially it's just a mess with systemd.
No advantage as far as I can see compared to syslog and the ordinary text tools. Just a way to force the use of binary file processing tools and as soon as something pukes in the binary file it may be completely unreadable. A text file might not look good after a puke but it's still mostly readable.
It's only by looking at them one at a time and drawing the relations in some external tool that I can figure out how they are related.
It's like going back to stone and chisel to do filing.
What works - and has worked for decades is the init system.
It's not always the best, but it's easy to manage for a system administrator and it's easy to understand and debug startup problems.
For stuff that takes time in an init script the historical way to solve that was to run that part in the background.
Then you haven't had problems trying to figure out WTF systemd is doing on a box. No logs means that it's taking hours to figure out what the problem is - and the problem can be a missing option in a config file that's needed for systemd operation where the error message is thrown away by systemd.
One fine example of catch-22 by systemd.
But you can't do a 'tail -f' on it to see progress.
No, you are the one that's out of touch with some of the more powerful tools for managing text information.
Instead of complaining as an AC and downmodding then I say that you instead should provide us with good information about how to handle the problem of non-existing text logs and missing stderr outputs. The non-existence of them means that problem solving has become a lot harder.
If I had modpoints I would have modded up this. Those tools are one of the core tools that every decent admin and *nix user shall know. They are way more powerful than most GUI softwares that have been written ever. Only 'vim' may be a contender there.
Well - I can always install games on it and give it away to some kids.
If NSA installed spyware on it then they will be busy with that for a while.
Systemd makes server administration a lot harder - almost a nightmare. There's no way to see how stuff is related anymore, while with init you could see it with a quick glance using ls.
And if you add your own stuff it's not easier, it's darn hard.
Better to have a specially designed clothing or coat buttons to store the microSD in.
Seems to be overkill.
It's probably better to have only sensitive stuff encrypted and hidden, that way it will be harder to determine if it contains interesting stuff. You may feed cops with some information, but only information that they essentially can figure out anyway.
Yet another that didn't understand that Chrome was the bloatware added to another software.
Chrome is bloatware added to some software packages.
The deal is that when it comes to Government it's a Budget concern. They need to follow The Budget at any price, no matter what, and if they need to buy it back with money then they need to have An Account.
A lot of other action can be absorbed into the daily work, but as soon as you purchase something it must be on The Budget and there nut be An Account for said purchase.
You discount the possibility that the junk yard owner actually could make a great PR event of it, good reputation is often way better in the long run than just the money involved.
Considering that junkyards today are pretty detailed about separation of items depending on metal type and sometimes even alloys they need to identify what they are working with to put stuff in the right bucket. Unusual devices requires extra consideration not only from the perspective of metals but also from hazardous material.
Junkyards are no longer a local hobo operation but actually pretty detailed in what they do - and regulated. So if stuff ends up from someone that do have some unusual labeling like NASA or so then they will at least take a second look. They usually want to make sure that they avoid the Cobalt-60 incident from December 1983 in Ciudad Juárez, Mexico and similar.
At least some recycling center people are smart enough to figure out when they have something that has a value beyond the scrap value on their hands.
The same goes for a lot of software - clog your computer with bloatware like Chrome and whatever that I never use.
And at every upgrade the software package asks me to confirm that I agree to the current license version instead of just installing the update in the background silently to ensure that I get the latest security updates.
In addition to that Windows also enforces the UAC to make you confirm that the update installation is permitted. But in many cases this is problematic since it won't help many users that are out there, especially those with limited computer knowledge who either clicks "No" on everything or "Yes" on everything. In both cases it leads to bad results.
Well, it works for the main switch in a computer hall, but often power is only cut off on a circuit breaker for the circuits where the work is done, not the whole data center.
Unfortunately way too common. Often because the installation shall be cheap.
To paraphrase what happens when programs do something bad: "The company has executed an illegal operation and will be terminated".
Assuming that there's no asshat turning on the power while you are working because they needed the power NOW.
Turn it off, then do a short circuit to ground at the work position as well so if someone turns on the power then the fuse will blow. If they are unlucky then the main fuse will blow and that's going to make a mark in someone's report.
If it's really bad the UPS will die - and that will definitely make a mark in the budget for that year.
The five nine uptime is not counting planned stops. So you can at a datacenter have a planned stop for a month and still conform to the contract. But it wouldn't make sense.
There is a reason why clustered systems are used - one node goes down another takes over. That's good enough to provide decent uptimes in most cases.
But today with virtual servers it's often one huge single server, and that's a single point of failure system even if the server itself may have built in redundancy there are always something that can fail.