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

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? What is the purpose of at, cron, init, or xinetd without something to start and stop?

What's absurd is combining these 4 (or 3) apps that does completely different things into one.


As opposed to having 4 utterly different codebases, and all the reproduction of efforts that implies?

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.

If you think they do you're seriously deluded. They're looking out for their own interests, nothing else.


It is in their best interests to work with the community, this is what you're missing.

uh, no they don't NONE of them is managing services. Cron schedules *jobs*, syslog writes logs messages, logrotate rotates log files. They do not manage services.


What is a job if not a service? You seem to have a very strange definition of what a service is.

If you don't think logging is a part of service management, I don't even know what to tell you. If I cannot keep track of services, management itself is simply impossible.

That's what API's are for and there already is one for syslog.


You'd think so, right?

You'd be mistaken, there are attempts to standardize the format but there is no API definition. Essentially, things are just farting text out of std[out,err] and syslog is throwing that raw into a file. It simply doesn't care what that info is, how it is formatted, nothing.

I do and logs is a problem to which there are many good existing solutions, most of them better than the proposed systemd solution. Which you would have known if you had "real experience managing a Linux network".


Please show me a solution which is as seamless as journald over the network. They are all hacks which try to address the shortcomings of syslog.

Reply Parent Score: 3

RE[8]: Too funny
by phoenix on Tue 14th May 2013 17:27 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