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 561261
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE: Too funny
by Lunitik on Sun 12th May 2013 16:41 UTC in reply to "Too funny"
Lunitik
Member since:
2005-08-07

this made my day

(Besides: you guys have systemd, which if I'm going to treat it the same way I treated NTFS, is an all-devouring octopus monster about crawl out of the sea and eat Tokyo and spit it out as a giant binary logfile.)


It is simply ignorant.

Systemd is SMALLER than init or any other such program.

It is not devouring anything, it is simply creating replacements for many prior projects. These are all separate binaries, and can be used or left out.

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.

It is certainly vastly different, but having used it for a while, I would never use another init mechanism.

Imagine, a single tool to initialize everything on the system, not one for bringing up the system, another for timed events, another for scheduling events, another for dealing with events on demand, another for acting on new hardware, all logs and tracked in a uniformed way, all managed in a uniform way. The sheer number of in-kernel mechanisms it makes easily available to admins is staggering. Systemd actually lets us take full advantage of the platform, rather than remaining confined to 30 year old mechanisms.

People dislike change, people like using shell scripts to do things, cool. Systemd can execute any type of script or binary, so actually it is more powerful than simple shell scripting in this regard too. As for change, there is always Slackware - the state of the art in the early 90's - or any of the BSD's. Everyone else except Debian is moving on, but they've never complied with standards anyway.

Edited 2013-05-12 16:49 UTC

Reply Parent Score: 5

RE[2]: Too funny
by djohnston on Sun 12th May 2013 19:09 in reply to "RE: Too funny"
djohnston Member since:
2006-04-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.

True, that. And there's the journalctl tool to display all the system logs, in one place, in human-readable format.

Everyone else except Debian is moving on, but they've never complied with standards anyway.

Never complied with standards? In what way? What supporting evidence can you show?

Reply Parent Score: 1

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

Run levels are a defined standard, Debian simply ignored them - many will say you can create similar functionality, but you can create similar via targets in systemd, this doesn't mean it follows the standard.

There is also the issue of using dash for /bin/sh which results in some oddities.

Reply Parent Score: 2

RE[2]: Too funny
by satsujinka on Sun 12th May 2013 19:34 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[2]: Too funny
by Soulbender on Mon 13th May 2013 02:27 in reply to "RE: Too funny"
Soulbender Member since:
2005-08-18

The logging is far superior to anything we've had before, the very fact that it is binary ensures more security.


Oh yeah, security through obscurity. That ALWAYS works out great. syslog can already log to a remote host and for your other log files you should already be using something like logstash or graylog2 if security and manageability is a concern.


Imagine, a single tool to initialize everything on the system, not one for bringing up the system, another for timed events, another for scheduling events, another for dealing with events on demand, another for acting on new hardware, all logs and tracked in a uniformed way, all managed in a uniform way.


See, this is what I *don't* like about systemd; it does too much. We already have cron and at for scheduling, we have udev for hotplugging and there are already many good solutions for managing logging. SystemD should stay the hell out of these areas and focus on the one area that does need solving: service management.

Personally I much prefer the Upstart approach of focusing on a small set of problems that need solving.

Reply Parent Score: 5

RE[3]: Too funny
by triangle on Mon 13th May 2013 02:49 in reply to "RE[2]: Too funny"
triangle Member since:
2013-05-13

Security through obscurity? Just because some firm does not base its operations upon the principles of the communist manifesto, it does not mean that the products it produces are insecure. Put another way, just because they choose to sell their product and you don't get to see their source code it does not mean that the product relies merely on obscurity for its security. Logic is your friend. Closed source software rely on good design and engineering for security as much as anything. They also receive bug reports. Thus, when a bug is found, they can fix it. You need not see the source code.

Reply Parent Score: -1

RE[3]: Too funny
by Lunitik on Mon 13th May 2013 09:39 in reply to "RE[2]: Too funny"
Lunitik Member since:
2005-08-07

See, this is what I *don't* like about systemd; it does too much. We already have cron and at for scheduling, we have udev for hotplugging and there are already many good solutions for managing logging.


There is no more udev, it is part of systemd - which is a good thing because the system management daemon should be managing the system. Why is it good to have at and cron around, as well as xinetd when all they're doing is managing services. The problem is that these are each using different methods, and are utterly incompatible so we are increasing the learning curve for no benefit at all.

Sure, systemd has a learning curve at first, but as you get used to it it just makes sense.

Personally I much prefer the Upstart approach of focusing on a small set of problems that need solving.


Upstart is crap, there is no real benefit to it over sysv at all. The main problem is it is still basically using scripting for everything, so there are still something like 3000 fs calls when bringing up the system. This, when compared to the about 700 of systemd, is simply too much - systemd needs to come down somemore too, but this includes everything up to a gnome desktop, when gnome-session starts to use systemd user sessions, this will come down drastically.

As others have said, fs access on linux is not great, so the less times we are accessing the disk, the better, and the faster the system will come up.

Honestly, I still don't even understand upstart, its language is just broken. I keep trying to look into it, but the more I do, the less I like it. Systemd uses the file system in a logical way for booting the system, and gives us more access in the /sys dir to many of the features of the system. Upstart gets us nowhere because fundamentally it is only a redesign of the init, it is not something substantially new.

You seem to think this is a good thing, but systemd simply results in a cleaner and easier to understand system. By removing many things like at and cron and syslog and logrotate and all these programs that do not communicate with each other, we end up with a more integrated base system. For me, this is a good thing, it is a miracle all these projects have managed to coexist for so long at all.

By moving all these into one project (with many binaries for each thing, because modularity is important for parallel booting) we now get a consistent API for all events on the system, whether hardware or software crashes or whatever, it all becomes predictable. Everything is handled in the same way system wide, and there are no more obscure config settings to learn depending on exactly what you're trying to achieve. This is a huge benefit to Linux, others moved to similar approaches a long time ago.

Couple this with the fact upstart has a CLA, and systemd becomes the only intelligent choice. Canonical does not have the Open Source communities best interests at heart, so their projects will not be touched by anyone outside Canonical. You essentially fall into the same trap as any proprietary company, you become utterly dependent on a single company for all issues that might arise.

Canonical will be replacing udev in UnityNext, and haven't been upgrading it in their repo's for a couple releases now. They are discussing replacements for NetworkManager, they want their own telepathy stack. They will be competing head on with not just Red Hat, but people like Intel and IBM, all these companies that are heavily invested in Free Software. Canonical are fooling themselves if they think they can compete by doing everything themselves. They simply lack the competency.

To date, the only things Ubuntu have actually done themselves is a Compiz plugin that was quite broken for most people, an init system whose initial developer left, and a few bloated APT frontends. Below this, they utterly depended on Novell and Red Hat for everything. Now they want to replace all this, they want to control everything themselves, everything good about Open Source simply is lost on Canonical.

For some reason, they are praised because everything "just works", but it works because of work done by others. It honestly makes me sad that the praise is so misplaced. In fact, Ubuntu are mostly reponsible for making things not work, for breaking others work because they don't actually understand the software they are shipping. To this day, Lennart gets a bad rap because Ubuntu devs didn't understand pulseaudio and so shipped a broken config.

Of course, Ubuntu is heavily used, so a broken config in their shipped release gave people a bad opinion of pulseaudio. Another example is the binary drivers constantly breaking on upgrades, it makes Linux look bad because users aren't really made aware of the issues before something breaks. Canonical just makes horrible decisions throughout the stack and this harms Open Source development because people just accept proprietary poorly maintained software instead of pressuring these companies to play nicer with Open Source.

This is my real problem with Ubuntu, they simply don't care about Free Software, they do not care about Open Source, they just want to benefit from it. They think they are being slandered in upstream projects because their code is rejected, but the code is rejected because it is bad code. Now they want to rewrite everything, they want the entire stack to simply comply with their tests, they cripple developers, they make it ok for poor code provided it meets the testing requirements. Open Source is innovative because of its dynamic nature, Canonical are ridding themselves of this benefit.

Edited 2013-05-13 09:57 UTC

Reply Parent Score: 3

RE[2]: Too funny
by Alfman on Mon 13th May 2013 03:05 in reply to "RE: Too funny"
Alfman Member since:
2011-01-28

Lunitik,

Personally I've always found sysV init scripts clumsy and I'm kind of glad they're being phased out. They lack any sort of automatic dependency analysis, there's no restart monitor for dead processes (like init+inittab), init scripts cannot be scheduled and cron jobs are inflexible, etc.

So I think we're in agreement here, but I also agree with the author that systemd is a bit of an octopus. I don't think it's a bad thing though, I think it's good to have consolidation around system task management and it makes sense to consolidate all the components under a unified system like systemd.

Reply Parent Score: 4

RE[2]: Too funny
by Darkmage on Thu 16th May 2013 01:43 in reply to "RE: Too funny"
Darkmage Member since:
2006-10-20

Debian has support for it to, you just have to tick a box and it installs.

Reply Parent Score: 2