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.
Permalink for comment 561551
To read all comments associated with this story, please click here.
RE[9]: Too funny
by Lunitik on Tue 14th May 2013 19:19 UTC in reply to "RE[8]: Too funny"
Member since:

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