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

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.


Most contributers to systemd are from outside Red Hat.

Udev was already a Red Hat project.

Basically every distro that matters except Ubuntu is likely to move to systemd. Debian are looking at it quite heavily, and the only competent developer at Canical is even a heavy contributor to systemd so perhaps they will finally switch too at some stage.

What is clear is that systemd is the way forward, whether you like it or not. I think if you actually use it, you will see why people like me find arguments against it to be absurd.

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.


You don't think that it is absurd to have 4 binaries essentially doing the same thing in different ways, rather than a single uniform method? It is just duplication of effort, and what is hilarious is each is about the size of systemd. There is no necessity when a single binary can accomplish the task each is trying to fulfil in a cleaner way.

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.


Its "PID files" is not nearly as good as cgroups. All daemons are backgrounded, that is sorta the point. Have you actually worked with upstart though? It seems to me you haven't, you just know that your Ubuntu desktop uses it and seems to do fine. Try to configure one of its event files, you will understand why people dislike it.

Systemd does do one thing, and it does to it will. It manages services, but it is no longer just a replacement for init. I don't think you are grasping the fact that systemd does not only consist of one binary. There are a few to do different things, and these are actually more Unix like than the prior alternatives. Things like hostnamectl or datetimectl are tiny binaries that do exactly what you think they do.

The fact that you want to limit that one thing to just bringing up the userland is where we will not agree. A modern system is more dynamic than this, the central process on the system should be dynamic too. Upstart tried to address this, but its fundamental design is stupid. Instead of focusing on the end result, it just runs every daemon that could depend on something lower down. Want to start NetworkManager? Cool, you're going to get bluez and avahi and whatever else could possibly use dbus that is installed because NetworkManager brought that up. This is broken and simply retarded.

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.


Try looking at the actual event files, those hooks work with the event file which is still just a series of scripts. Browse around /etc/events.d or whatever, you will notice they are scripts doing the same sorts of things as old init files. The fact this is abstracted to a simple config format is besides the point.

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


Yes, they do, because without a strong community, these companies understand they would limit their capabilities. The whole point of Intel and IBM investment is that they don't want a single software vender to control their destiny. They each understand the benefit of Open Source deeply, they each understand they need each other, that their future depends on collaboration.

Canonical seem to think quite the opposite, that just throwing code over a wall is fine, that community is irrelevant. This is not how Open Source projects succeed, you need a strong community around the software, innovation comes by many contributors pulling the code in their own directions. Canonical seem to have gone out of their way to ensure developers are not interested in contributing, thus making it safe to throw the code over the wall.

Couple this with the inclusions of things like the Amazon scope, and you see that Canonical are only interested in money. Red Hat must make money, they are a publicly traded company, but they are adamant about Free Software at the same time. This is why people trust them, as much as Canonical is harping on about being the leading guest in the cloud, those clouds are running Red Hat as the host OS for a reason.

People use Ubuntu because it is free, companies use Red Hat because they are competent.

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


They don't though, they all manage services. If you don't think logrotate should communicate with rsyslog, if you don't think rsyslog needs to communicate with each daemon to ensure correct information, you are fooling yourself. We have tried to standardize these things so they can better talk to each other, but it has just been a failure. If you had any real experience maintaining a Linux network, you would understand the frustration of the unpredictability of logs - everything seems to decide arbitrarily what method they will use to log things. This all goes away with the journal, it supports all these methods and keeps them sane, then offers a new API which is far cleaner and better defined. All of this with the intent of at least offering something as good as Solaris and Apple have had for over a decade. Instead we are basically in the same situation we were in the 80's on many Linux distros.

Well, I for one welcomes competition and diversity.


There are not enough developers in the Open Source ecosystem to justify such lack of teamwork. The app story on Linux is bad enough, but now Canonical are defining their own developer environment.

Personally, I am glad everyone else is just moving their apps to the web, the native Linux story for client stuff is embarrassing. Please do not bring up how Canonical are standardizing on Qt/QML either, while KDE/RIM/Sailfish are technically each using this technology, the very nature of QML is causing a lot of problems. Each developer environment will be fundamentally different, API's will not translate. It is not standardization, it is even more proliferation.

Qt is another project that uses a CLA, so that is not an option for a company that cares about Free Software, about user advocacy. Perhaps it would be better to drop GTK and have the big guns all move to EFL(Intel and Samsung are both heavily invested there), at least it seems to be gaining momentum with a clean stack. Then we have to rewrite a lot of apps all over again though. It is really quite sad what is happening today in Linux clients.

There are a lot of Linux developers, but those are all working on web platforms, cloud platforms, everyone can clearly see the client platform outside of Android is a joke and it is getting far worse. I blame Canonical for this, they gave people permission to fork Gnome Shell by creating Unity - the most ironic name ever for a software project. If they hadn't done this, Cinnamon and the other forks wouldn't have happened, there would be less proliferation. Instead everything is a mess, and it is getting worse.

Edited 2013-05-13 14:27 UTC

Reply Parent Score: 2

RE[6]: Too funny
by Soulbender on Tue 14th May 2013 08:53 in reply to "RE[5]: Too funny"
Soulbender Member since:
2005-08-18

You don't think that it is absurd to have 4 binaries essentially doing the same thing in different ways, rather than a single uniform method?


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's absurd is combining these 4 (or 3) apps that does completely different things into one.

Browse around /etc/events.d or whatever, you will notice they are scripts doing the same sorts of things as old init files.


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

Yes, they do, because without a strong community, these companies understand they would limit their capabilities.


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

They don't though, they all manage services.


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.

if you don't think rsyslog needs to communicate with each daemon to ensure correct information, you are fooling yourself.


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

If you had any real experience maintaining a Linux network, you would understand the frustration of the unpredictability of logs


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".

Reply Parent Score: 3

RE[7]: Too funny
by Lunitik on Tue 14th May 2013 14:56 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