Linked by Thom Holwerda on Sat 11th May 2013 21:41 UTC
Windows "Windows is indeed slower than other operating systems in many scenarios, and the gap is worsening." That's one way to start an insider explanation of why Windows' performance isn't up to snuff. Written by someone who actually contributes code to the Windows NT kernel, the comment on Hacker News, later deleted but reposted with permission on Marc Bevand's blog, paints a very dreary picture of the state of Windows development. The root issue? Think of how Linux is developed, and you'll know the answer.
Thread beginning with comment 561273
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Too funny
by satsujinka on Sun 12th May 2013 19:34 UTC in reply to "RE: Too funny"
satsujinka
Member since:
2010-03-11

The logging is far superior to anything we've had before, the very fact that it is binary ensures more security. Before, it was relatively easy for a hacker to just edit the logs and the admin wouldn't know he was there. Now there are mechanisms in place to ensure the log really comes from where it is intended, and it is much harder to change that information.


This is bullshit. You can just as easily generate a checksum from text and be just as secure. There's no reason to not have plain text logs; especially considering that binary logs require special tools to read and filter.

Reply Parent Score: 5

RE[3]: Too funny
by Lunitik on Sun 12th May 2013 22:22 in reply to "RE[2]: Too funny"
Lunitik Member since:
2005-08-07

This is bullshit. You can just as easily generate a checksum from text and be just as secure. There's no reason to not have plain text logs; especially considering that binary logs require special tools to read and filter.


If you're creating a checksum from a text file that is already compromised, it doesn't get you very far.

The systemd journal comes from such a tool, and others can be easily created. Another added bonus though is that logs can be handled in one place from the entire network remotely and in a secure manner, and still the information is retained as to where it came from. People have done similar with syslog but it is a mess, this comes by default with systemd and makes sense considering most Linux deployments are cluster-based.

I do not understand what the problem is with binary log files, with journalctl they are just as accessible as using cat but it is more logical, each cgroup keeps its logs together in an orderly way, rather than each process randomly farting info to the file. Further, all the logging systems used around Linux are all read by journald, rather than having the possibility of what you need being in any of 10 files at times.

If you really want though, there is no problem with using journal and syslog on the same system if you absolutely need logs in text files. The journal is not a good enough reason to not use systemd. You gain far more in a far cleaner way by utilizing systemd.

Reply Parent Score: 4

RE[4]: Too funny
by satsujinka on Mon 13th May 2013 01:33 in reply to "RE[3]: Too funny"
satsujinka Member since:
2010-03-11

How would the text be compromised? You generate the checksum at the same time as the text. By the time a hacker could even see the text the checksum already exists.

My entire argument is this: Binary formats buy you nothing and only force you to do more work (creating journalctl to do the tasks that could formerly be done using standard tools.) There is no security advantage that can't be easily gained by adding checksums, which has the additional advantage of not requiring a brand new tool.

The issue of what can be done with syslog is different. If you say syslog can't do checksums (easily) then I'll believe you. However, the solution should not involve switching to binary (for the above reasons and a few additional that are specific to me; I'd be happy to share, but they're really only important to my use case.)

On an entirely different note: systemd doesn't give me any benefits. The old init system that Arch Linux used worked just fine for me. I had zero issues with it (in point of fact, I used Arch specifically for its init system.) However, I don't care enough to avoid it. In that regard it's exactly like pulseaudio. It gives me no benefit, but it more or less works; so whatever.

Reply Parent Score: 2