You seem to have zero experience with actual enterprise IT. What you say is straight from a "cloud services" ad, but it has no resemblance to what is going on in the real world, where an application has to work or 10'000 people can go for coffee. And yes, servers may still run many months at a time without reboot. For enterprise applications on server-side it is often a requirement that they can run for an unlimited time.
You also seem to have no actual system administration experience. If you install a new server, you still have to configure it and the configuration part is the major part of the work. Nobody brings up "10'000 new" servers unless they all follow a very carefully created pattern (and hence sysv-init is an advantage because of higher reliability).
As for log compression, you don't want the actively written log to be compressed. If there's a problem, even as small as a single bit error, then the log will be unrecoverable. That's the tradeoff you make with compression. logrotate compromises by only compressing older logfiles. If there are any minor errors in the active log then you can still read it just fine.
Excellent point and one that, again, requires just a bit of the respective real experience and understanding the systemd developers seem to be so sorely missing.
As to log-deletion on corruption, that is the most bone-headed stupid design. Flag it as corrupt, but let people read them! And keep them! My guess here is that the systemd developers are too inexperiences to come up with a robust binary log format, but are unwilling to go back to the sane choice, because they are too much in love with their creation. As to insecure, what is insecure is if you suddenly have a part of your of logs missing, but you have no clue whether an attacker deleted them, or whether systemd decided to have its 5 minutes of insanity. _That_ is insecurity.
Integrity checking is utterly worthless if availability is not ensured. An attacker on a systemd-binary-log box can just corrupt the logs or throw them away himself, no need even to fake a credible one. As systemd is known to do that from time to time by itself, this does not raise suspicion. On the other hand, credibly faking or completely excising traces of an attack from a text-log is quite a bit of work with a real risk of screwing up.
The level of non-understanding exhibited by this design is scary.
I have only modest experience working with *nix flavor boxes, and I fully understand the need for text based logs.
It is not a difficult insight to have. That is why somebody asking the question is either trolling or really has no experience with situations where you need the logs. In the second case it is very hard to enlighten them. You had to be there. In the case first they do not want to find out.
That said, you list some of the most important reasons to avoid binary logs. In particular the "easily damaged" aspect seems to be a real problem with systemd and it is an invitation to any attacker to just corrupt the logs instead of having to try to manually excise the traces of their break in. That makes binary logs with no resilience against corruption an exceptionally stupid design.
Let me just add one more problem (there are several more I can think of), because one of the bogus arguments for systemd is enterprise-readiness: Binary logs are not enterprise-compatible. In enterprise IT you need to process (read: add triggers for certain patterns), store and aggregate logs from a lot of different sources. The only way this can be made to work in practice is if you have line-oriented plain-text logs on which you can work with pattern-matching. Other things have been tried and universally failed. One reason is that the platform processing the logs is usually completely different from the multitude of platforms generating the logs. If you need some special tool to decode binary logs, you are usually screwed, because it may not even be possible to get that to run on the log analysis platform. Another reason is that binary file formats change and hence the are not robust. As soon as the log format changes a bit, you have to update all your analysis tools to be able to read them. With line-oriented plain-text logs you can usually just ignore the changes.
That said, on a meta-layer, binary logs in systemd are just one of the things that show that the systemd developers may be quite intelligent, but are inexperienced and have no appreciation for mistakes made long before by others and what the solutions to them were. Kind of like what Microsoft does. Making the same mistakes others did decades before is not good engineering. It is just arrogance coupled with incompetence. What the systemd developers lack is _wisdom_.
No. Seriously, if you need to ask then you do not even remotely have the level of understanding and experience this needs. I cannot fix your deficient education and experience.
If you had any actual intelligence, you would have noticed that I commented on SJWs and not on the case at hand. But I guess that distinction flies right over your head, despite being glaringly obvious.
Seriously, VR, even if it eventually will work well (not in 2016, that is certain), is just a gradual change, and for many things not even an improvement. The thing is, VR takes a lot out of you with regards to concentration. Some "realistic" games have people tired out after 5 minutes. The other thing is that VR does not mitigate bad writing, boring content and non-engaging characters at all. Hailing it as the the second coming is just unmitigatedly stupid. Also, like for example 3D content, VR has failed several times before. It will do so again.
Completely bogus argument. Linux has been "enterprise ready" 10 years ago. You probably also think Solaris was not "enterprise ready" before it got SMF, (the "systemd" of Solaris) yet most enterprise sysadmins hate its guts and Solaris did run a lot of mission-critical things long, long before SMF ever made an appearance.
Incidentally, in actual enterprise-setups, you do fail-over via network elements, not on the machine itself. But I guess you do not know that because you actually have no clue what you are talking about.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
I completely agree. If I could just easily ignore systemd, because whenever I install a new Linux machine, I get offered both alternatives by default, I would not care at all. This way, I have the thing forced on me (or nearly so), which is just not acceptable.
False positives are not a problem if you deal with them rationally. If a woman is murdered, and the DNA matches one in a million, then in a country of 300 million, there will be 300 matches, and 299 false positives. But if only one lives in the same city, and it happens to be her ex-boyfriend, then the DNA match is useful information.
Actually, it is not. You wasted the resources to do 300 million DNA tests, when simply looking for the ex-boyfriend would have helped you to narrow it down. With those 300 million DNA tests, you would have spent, say, the effort for 10'000 of them for locating and questioning the ex-boyfriend and administering a DNA test just to him. Hence you come out the effort for about 299.99 million DNA tests short and you still have to investigate the ex-boyfriend. That wasted effort is going to have massive negative effects elsewhere.
That is what trawling large databases with large numbers of false positives in the result do: They waste incredible amounts of resources for no gain. That is also why mass-surveillance makes us all very much less safe. If the French had done old-fashioned police work on the hints they had, the two last terrorist attacks would not have happened. Instead they let themselves be blinded by the masses of data. (That is if they were not intentionally looking the other way.)
Actually, as Paris showed (and then showed again), they cannot do so having all those capabilities and knowing who these people were beforehand. I think they simply cannot do it in the first place, no matter what outrageous capabilities these cretins will be given next.
Actually, it would not. Large false positive probabilities drive a detection method quickly to negative worth, because they then waste resources that could have spent better. Well known to experts, but something non-experts routinely do not comprehend.
No. You only have to get the message to somebody that is not affiliated with the company (so under no legal threat) and have them explain the meaning of the canary.
They can make them illegal, but that is very, very hard to do in a way to make a difference. What are you going to do? Put the one doing the signature in jail until he complies? Or even forcing a company to stay in business? Right.
People making laws are among the most disconnected from reality on the planet. Enforcement of such laws still has to have some dealings with reality so may well fall short.
Well, the problem with a surveillance state is that it neutralizes control instances. It usually devolves into a police-state pretty fast and then more slowly into fascism. Fascism is however inherently unstable, as it kill productivity and prosperity. Usually the start wars because that is a temporarily effective means of deviating attention from how bad things are. And in the end, at some point, these regimes collapse. It can take quite a while though. If the Germans had been a bit less greedy and a bit more well-managed, they could have gotten quite a bit into the "1000 Year Reich" for example.
So, no actual end game, just greed, fear of a free population, arrogance and stupidity. The usual.
Everybody has problems. Everybody deserves consideration form them. SJWs are just the ultimate in racism, sexism, etc. and are at heart fascists that want to humiliate and destroy everybody except their chosen group "victims". A force of evil and destruction to be sure.
There is toxic and then there is toxic. No chemical toxin is a problem after 100'000 years. Not so Plutonium (which was not accidentally named as it is), it has not even begun to decay noticeably after that time. There are quite a few other deadly things in nuclear waste that will be extremely dangerous for > 100'000 years, although none quite as deadly.
Fascinating level of ignorance you display there. People like you are truly blessed they live far, far too short to have to suffer the consequences of their deeds.
Selective ignorance is one of the main characteristics of the nuclear-apologists. In the end they want it for the military power thy think it gives them.
Nobody fixes nobody phones. They get thrown away when they are broken. Seriously. They are not even designed to be repairable. Sure, there are some very few exceptions to this, but not enough to matter or give your argument any validity.
But that is not actually a problem. Automation makes a society as a whole richer. The problem is that the old way of distributing that riches (which never worked well anyways) breaks down and needs to be replaced by a different mechanism. Of course, that also means that quite a few people that defined their own worth h by the job they do will have to look for another fake measure. For many of them it turns out that they were not that useful after all. That looks to me to be the real reason why so many defend the classical capitalist model, even if it screwed them over repeatedly.
Well, you seem to feel threatened by my ideas, which you sum up incorrectly. Apparently you have not understood a single word I said. What you do is not criticism, it is propaganda. Pathetic. This reaction is however entirely typical for somebody that sees his beliefs challenged and knows he has no good answers.
Slashdot Mirror
You seem to have zero experience with actual enterprise IT. What you say is straight from a "cloud services" ad, but it has no resemblance to what is going on in the real world, where an application has to work or 10'000 people can go for coffee. And yes, servers may still run many months at a time without reboot. For enterprise applications on server-side it is often a requirement that they can run for an unlimited time.
You also seem to have no actual system administration experience. If you install a new server, you still have to configure it and the configuration part is the major part of the work. Nobody brings up "10'000 new" servers unless they all follow a very carefully created pattern (and hence sysv-init is an advantage because of higher reliability).
As for log compression, you don't want the actively written log to be compressed. If there's a problem, even as small as a single bit error, then the log will be unrecoverable. That's the tradeoff you make with compression. logrotate compromises by only compressing older logfiles. If there are any minor errors in the active log then you can still read it just fine.
Excellent point and one that, again, requires just a bit of the respective real experience and understanding the systemd developers seem to be so sorely missing.
As to log-deletion on corruption, that is the most bone-headed stupid design. Flag it as corrupt, but let people read them! And keep them! My guess here is that the systemd developers are too inexperiences to come up with a robust binary log format, but are unwilling to go back to the sane choice, because they are too much in love with their creation. As to insecure, what is insecure is if you suddenly have a part of your of logs missing, but you have no clue whether an attacker deleted them, or whether systemd decided to have its 5 minutes of insanity. _That_ is insecurity.
Integrity checking is utterly worthless if availability is not ensured. An attacker on a systemd-binary-log box can just corrupt the logs or throw them away himself, no need even to fake a credible one. As systemd is known to do that from time to time by itself, this does not raise suspicion. On the other hand, credibly faking or completely excising traces of an attack from a text-log is quite a bit of work with a real risk of screwing up.
The level of non-understanding exhibited by this design is scary.
I have only modest experience working with *nix flavor boxes, and I fully understand the need for text based logs.
It is not a difficult insight to have. That is why somebody asking the question is either trolling or really has no experience with situations where you need the logs. In the second case it is very hard to enlighten them. You had to be there. In the case first they do not want to find out.
That said, you list some of the most important reasons to avoid binary logs. In particular the "easily damaged" aspect seems to be a real problem with systemd and it is an invitation to any attacker to just corrupt the logs instead of having to try to manually excise the traces of their break in. That makes binary logs with no resilience against corruption an exceptionally stupid design.
Let me just add one more problem (there are several more I can think of), because one of the bogus arguments for systemd is enterprise-readiness: Binary logs are not enterprise-compatible. In enterprise IT you need to process (read: add triggers for certain patterns), store and aggregate logs from a lot of different sources. The only way this can be made to work in practice is if you have line-oriented plain-text logs on which you can work with pattern-matching. Other things have been tried and universally failed. One reason is that the platform processing the logs is usually completely different from the multitude of platforms generating the logs. If you need some special tool to decode binary logs, you are usually screwed, because it may not even be possible to get that to run on the log analysis platform. Another reason is that binary file formats change and hence the are not robust. As soon as the log format changes a bit, you have to update all your analysis tools to be able to read them. With line-oriented plain-text logs you can usually just ignore the changes.
That said, on a meta-layer, binary logs in systemd are just one of the things that show that the systemd developers may be quite intelligent, but are inexperienced and have no appreciation for mistakes made long before by others and what the solutions to them were. Kind of like what Microsoft does. Making the same mistakes others did decades before is not good engineering. It is just arrogance coupled with incompetence. What the systemd developers lack is _wisdom_.
No. Seriously, if you need to ask then you do not even remotely have the level of understanding and experience this needs. I cannot fix your deficient education and experience.
If you had any actual intelligence, you would have noticed that I commented on SJWs and not on the case at hand. But I guess that distinction flies right over your head, despite being glaringly obvious.
Not in the same class, even remotely. You can reliably cause lung cancer with just 1 gram of Plutonium in 1'000'000 people.
Seriously, VR, even if it eventually will work well (not in 2016, that is certain), is just a gradual change, and for many things not even an improvement. The thing is, VR takes a lot out of you with regards to concentration. Some "realistic" games have people tired out after 5 minutes. The other thing is that VR does not mitigate bad writing, boring content and non-engaging characters at all. Hailing it as the the second coming is just unmitigatedly stupid. Also, like for example 3D content, VR has failed several times before. It will do so again.
Completely bogus argument. Linux has been "enterprise ready" 10 years ago. You probably also think Solaris was not "enterprise ready" before it got SMF, (the
"systemd" of Solaris) yet most enterprise sysadmins hate its guts and Solaris did run a lot of mission-critical things long, long before SMF ever made an appearance.
Incidentally, in actual enterprise-setups, you do fail-over via network elements, not on the machine itself. But I guess you do not know that because you actually have no clue what you are talking about.
The real sin here is not heresey by either group.
The real sin is the decision of the foss community to pick a side, and in so doing, remove that choice from other people, by choosing to make systemd a hard requirement, solely for their own convenience.
I completely agree. If I could just easily ignore systemd, because whenever I install a new Linux machine, I get offered both alternatives by default, I would not care at all. This way, I have the thing forced on me (or nearly so), which is just not acceptable.
Nice propaganda piece, full of lies and slander. My guess is you still work for that marketing company and got paid to write that.
If you have to ask then you do not understand the issue. It is glaringly obvious though.
In particularly one that is trying to destroy all that is good and proper like systemd? Making peace with it would be stupid!
False positives are not a problem if you deal with them rationally. If a woman is murdered, and the DNA matches one in a million, then in a country of 300 million, there will be 300 matches, and 299 false positives. But if only one lives in the same city, and it happens to be her ex-boyfriend, then the DNA match is useful information.
Actually, it is not. You wasted the resources to do 300 million DNA tests, when simply looking for the ex-boyfriend would have helped you to narrow it down. With those 300 million DNA tests, you would have spent, say, the effort for 10'000 of them for locating and questioning the ex-boyfriend and administering a DNA test just to him. Hence you come out the effort for about 299.99 million DNA tests short and you still have to investigate the ex-boyfriend. That wasted effort is going to have massive negative effects elsewhere.
That is what trawling large databases with large numbers of false positives in the result do: They waste incredible amounts of resources for no gain. That is also why mass-surveillance makes us all very much less safe. If the French had done old-fashioned police work on the hints they had, the two last terrorist attacks would not have happened. Instead they let themselves be blinded by the masses of data. (That is if they were not intentionally looking the other way.)
Actually, as Paris showed (and then showed again), they cannot do so having all those capabilities and knowing who these people were beforehand. I think they simply cannot do it in the first place, no matter what outrageous capabilities these cretins will be given next.
Actually, it would not. Large false positive probabilities drive a detection method quickly to negative worth, because they then waste resources that could have spent better. Well known to experts, but something non-experts routinely do not comprehend.
No. You only have to get the message to somebody that is not affiliated with the company (so under no legal threat) and have them explain the meaning of the canary.
They can make them illegal, but that is very, very hard to do in a way to make a difference. What are you going to do? Put the one doing the signature in jail until he complies? Or even forcing a company to stay in business? Right.
People making laws are among the most disconnected from reality on the planet. Enforcement of such laws still has to have some dealings with reality so may well fall short.
Well, the problem with a surveillance state is that it neutralizes control instances. It usually devolves into a police-state pretty fast and then more slowly into fascism. Fascism is however inherently unstable, as it kill productivity and prosperity. Usually the start wars because that is a temporarily effective means of deviating attention from how bad things are. And in the end, at some point, these regimes collapse. It can take quite a while though. If the Germans had been a bit less greedy and a bit more well-managed, they could have gotten quite a bit into the "1000 Year Reich" for example.
So, no actual end game, just greed, fear of a free population, arrogance and stupidity. The usual.
Everybody has problems. Everybody deserves consideration form them. SJWs are just the ultimate in racism, sexism, etc. and are at heart fascists that want to humiliate and destroy everybody except their chosen group "victims". A force of evil and destruction to be sure.
There is toxic and then there is toxic. No chemical toxin is a problem after 100'000 years. Not so Plutonium (which was not accidentally named as it is), it has not even begun to decay noticeably after that time. There are quite a few other deadly things in nuclear waste that will be extremely dangerous for > 100'000 years, although none quite as deadly.
Fascinating level of ignorance you display there. People like you are truly blessed they live far, far too short to have to suffer the consequences of their deeds.
Selective ignorance is one of the main characteristics of the nuclear-apologists. In the end they want it for the military power thy think it gives them.
Nobody fixes nobody phones. They get thrown away when they are broken. Seriously. They are not even designed to be repairable.
Sure, there are some very few exceptions to this, but not enough to matter or give your argument any validity.
But that is not actually a problem. Automation makes a society as a whole richer. The problem is that the old way of distributing that riches (which never worked well anyways) breaks down and needs to be replaced by a different mechanism. Of course, that also means that quite a few people that defined their own worth h by the job they do will have to look for another fake measure. For many of them it turns out that they were not that useful after all. That looks to me to be the real reason why so many defend the classical capitalist model, even if it screwed them over repeatedly.
Well, you seem to feel threatened by my ideas, which you sum up incorrectly. Apparently you have not understood a single word I said. What you do is not criticism, it is propaganda. Pathetic. This reaction is however entirely typical for somebody that sees his beliefs challenged and knows he has no good answers.