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 561526
To view parent comment, click here.
To read all comments associated with this story, please click here.
RE[8]: Too funny
by phoenix on Tue 14th May 2013 17:27 UTC in reply to "RE[7]: Too funny"
phoenix
Member since:
2005-07-11

"They don't do the same thing. Really. They do 4 different things, well 3 if you combine cron and at.
corn/at and syslog has NOTHING in common. They do NOTHING that is the same. Really, I find it odd that you'd think they do.


What is the purpose of syslog without something to monitor?
"

syslog doesn't "monitor" anything. It receives log messages from other processes and either writes them to a log file, or sends them across a network to another syslog.

What is the purpose of at, cron, init, or xinetd without something to start and stop?


at/cron runs processes at specific times.

xinetd listens on sockets and forks processes as needed.

Not even close to the same thing.

"There's no events.d that is part of upstart.


Now you just look ignorant.

$ cd /etc/events.d

Look at the files in there.
"

Kubuntu 12.10:
$ ls /etc/events.d
ls: cannot access /etc/events.d: No such file or directory

Huh, so if Canonical is using upstart, and events.d doesn't exist on a Canonical system, wouldn't that imply that events.d is not part of upstart?

Reply Parent Score: 2

RE[9]: Too funny
by Lunitik on Tue 14th May 2013 19:19 in reply to "RE[8]: Too funny"
Lunitik Member since:
2005-08-07

syslog doesn't "monitor" anything. It receives log messages from other processes and either writes them to a log file, or sends them across a network to another syslog.


Inaccurate, nothing ever sends anything to syslog, thus to say it receives something is erroneous. The correct word is monitor, it monitors stdout and stderr and throws that into a text file when appropriate.

This the fundamental problem with syslog and init/upstart, there is no defined API for this, nothing is happening on purpose. The purpose of syslog more than anything is to try to decide what actually needs to go to a text file.

at/cron runs processes at specific times.


at() starts processes after a certain amount of time
crom() starts processes based on a specific schedule

Neither even attempt to monitor the processes after they are executed.

xinetd listens on sockets and forks processes as needed.


It does not fork at all, it starts processes based on sockets being requested and stops the process when it becomes idle.

This is a good example of something the current mechanisms fall short at. Why aren't at/cron/init also monitoring those things they've executed? Why are they simply left to their own devices once they are executed? Why are they executing anything which isn't actually necessary at this time?

xinetd() is great, it should never have been kept outside init itself.

Not even close to the same thing.


How so?

Again, they are starting and stopping programs, is it valid to have a whole other mechanism because you want execution based on a schedule, or periodically, or simply when they're needed? Should these not all be part of the init system since they are fundamentally just initializing programs? What exactly is so different about them that they merit being separate?

Kubuntu 12.10:
$ ls /etc/events.d
ls: cannot access /etc/events.d: No such file or directory


Meh, I guess it is /etc/init now.

Huh, so if Canonical is using upstart, and events.d doesn't exist on a Canonical system, wouldn't that imply that events.d is not part of upstart?


I am not even sure what point you think you're making here. Sorry for my error, it is still that event files are scripts, which create huge amounts of IO. It is why the boot and shutdown processes are so slow on Ubuntu, it is irrelevant what benefits they've made because they still depend on filesystem speed.

By using executables, as systemd units are, this is no longer an issue. Instead we depend only on the speed of RAM.

Reply Parent Score: 2

RE[10]: Too funny
by Soulbender on Tue 14th May 2013 20:28 in reply to "RE[9]: Too funny"
Soulbender Member since:
2005-08-18

Inaccurate, nothing ever sends anything to syslog, thus to say it receives something is erroneous. The correct word is monitor, it monitors stdout and stderr and throws that into a text file when appropriate.


That's not how syslog works. Syslog listens on a socket, unix or inet, for log messages. Anything written to those sockets that is in the correct format will be handled by syslog. Syslog does not monitor any processes.

It does not fork at all, it starts processes based on sockets being requested and stops the process when it becomes idle.


Yes, that's what he said. (x)inetd forks processes to handle network requests.

This the fundamental problem with syslog and init/upstart, there is no defined API for this, nothing is happening on purpose


The API and message format of syslog is defined in an RFC (can't remember which one, it's late...).

at() starts processes after a certain amount of time
crom() starts processes based on a specific schedule

Neither even attempt to monitor the processes after they are executed.


Cron monitors the processes it runs and will send a notification if anything is written on stdout or stderr. Granted, standard cron can certainly be improved in this respect (you can use cronic for better control, for example) but merging it into the systemd process is not the best solution.
Note that I don't have a very strong opinion on this, integrating cron in systemd makes some kind of sense.
syslog and logrotate doesn't, though.

xinetd() is great, it should never have been kept outside init itself.


xinetd doesn't scale. It's usable for very light work but the fork-model suffers when you scale up.

Meh, I guess it is /etc/init now.


/etc/init contains the config files in the format I already showed an example of. They're not scripts but they can, if the situation requires, use simple scripting to launch the process.

Sorry for my error, it is still that event files are scripts, which create huge amounts of IO.


No, they're still not scripts.

Edited 2013-05-14 20:33 UTC

Reply Parent Score: 2

RE[10]: Too funny
by Gullible Jones on Wed 15th May 2013 02:46 in reply to "RE[9]: Too funny"
Gullible Jones Member since:
2006-05-23

Wait a minute. If systemd is so damn fast, why do Fedora 18 and OpenSUSE 12.3 take twice as long to boot as Debian Wheezy, no matter how many services and crap I disable? And why does my computer's hard drive grind throughout the boot process on distros using systemd, but not those with sysvinit?

Mind, I don't have anything in particular against systemd. However, I keep hearing "it enables OMG fast boots" when distros that use it in fact seem remarkably slow to get off the ground. If systemd makes logs easier to search and is more maintainable, good... But let's not be overoptimistic about the effect on boot speed.

Reply Parent Score: 2