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 561306
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[2]: Too funny
by Soulbender on Mon 13th May 2013 02:27 UTC 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[4]: Too funny
by Soulbender on Mon 13th May 2013 03:11 in reply to "RE[3]: Too funny"
Soulbender Member since:
2005-08-18

What the heck are you talking about?
We are talking about systemd's binary logging and the (lack of) security it provides, not about closed-source software.

Reply Parent Score: 3

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[4]: Too funny
by Soulbender on Mon 13th May 2013 10:01 in reply to "RE[3]: Too funny"
Soulbender Member since:
2005-08-18

There is no more udev, it is part of systemd


Wow, how horrible. I'm guessing it's not only Ubuntu that will look at alternatives to systemd and udev then. Not everyone is happy about being at the mercy of RH and Lennart.

By removing many things like at and cron and syslog and logrotate and all these programs that do not communicate with each other


These programs have no need to communicate with eachother. at/cron performs completely different functions from syslog and logrotate. Putting all these disparate functions into the same daemon is pointless and doesn't solve any real-world problem.

Upstart is crap, there is no real benefit to it over sysv at all.


It's pretty obvious that you never worked with upstart. It solves all of the problems with sysv (PID files, backgrounding daemons, no automatic restarts etc) and it does so without completely taking over your system.
You know, like the old Unix philosophy: do one thing and do it well.

The main problem is it is still basically using scripting for everything


Uh, no it doesn't. It CAN use scripting if needed but most upstart config files are just configuration statements and one exec statement for the binary.

Honestly, I still don't even understand upstart, its language is just broken


I don't see what's so hard about it. it's a simple config file format. Here, i'll show you a very simple Upstart config for an imaginary service:

description "myservice"
start on runlevel [2345]
stop on runlevel [016]
respawn
console log
exec /usr/bin/myservice_executable

Canonical does not have the Open Source communities best interests at heart


Right, because Redhat, IBM, Novell etc has the community's best at heart...

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.


Considering that they all do different things and at no point need to communicate with eachother it's really no miracle at all.

Canonical are fooling themselves if they think they can compete by doing everything themselves. They simply lack the competency.


Well, I for one welcomes competition and diversity.

Reply Parent Score: 3