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 561235
To read all comments associated with this story, please click here.
Is it really Microsoft specific?
by malxau on Sun 12th May 2013 10:00 UTC
Member since:

For clarity, I work at Microsoft, on some of the components the OP is referring to. Prior to Microsoft, I contributed to open source projects. And right from the start, note that these open source projects can't really be described collectively, since each project has its own culture, process and style.

Have there been things at Microsoft that I'd like to have been able to do and couldn't? Sure. I don't think it's nearly as bad as the poster describes - I've been well rewarded for getting things done, and I do things I'm not asked to, including refactoring, all the time. Since each team owns its own code, modifying another team's code is a social problem, and that doesn't always go the way I want. But in open source, it's still not all my code, and the social problem is still there.

Back in the day, I contributed to Gaim (now Pidgin). My experience working with them was fantastic, but it's since been forked because people can't agree on the behavior of the size of the input box (!).

I wrote a patch to the linux kernel for my own benefit, and submitted it to lkml for glory. That list is huge, and the patch attracts plenty of review, including valid and constructive feedback for how to improve it. But since it's my first patch, the feedback requires learning a lot more of the system and building a much bigger feature. This is not a bad process - it results in good code - but it's not encouraging for new contributors. My patch never merged.

I wrote a patch for Mozilla. This one saddens me more than anything. Specifically, I took an abandoned patch, revived it to current code, polished, finished, and submitted it. It gets reviewed, rejected, there are unrelated flaws found because people are testing the code, it languishes, and some part of it gets merged. The UI part was against the SeaMonkey UI, and FireFox has never had UI support for it (about:config only). The bug I addressed is still active due to unfinished work, people still work on related bugs, and the most frequent outcome is more incomplete, abandoned patches just like the one I started from. I still get bugzilla emails from complaining users over things there, and am no longer in a position to just step in and fix them. If I were to compare this to Microsoft, at Microsoft you need to convince a team of the need to do something, but at Mozilla you have to do it yourself, including every potential tangent to it, and do it perfectly. Again, this is not necessarily a criticism - it's always good to have features that are complete rather than "it works in case X but not case Y" - but it's not welcoming.

I agree with the OP that fixing an existing technology is often better than writing a new one to add to the side. And Microsoft does that. But so do open source projects - if X can't be fixed, have Wayland. If UFS can't be fixed, have ZFS. If NFSv3 can't be fixed, have NFSv4 (which shares little except a name.) Again, this is not a criticism - whether Microsoft or Linux, this is done because it ensures great compatibility with existing deployments, who don't need to embrace a disruptive change immediately; the two can coexist while migration occurs. The unfortunate part is it means the installed base, running the older thing, will not be as good as it could be. Open source has an advantage in the nature of its users and deployments which allow the older thing to go away faster than in the Microsoft world, but even there, my systems still have gtk 1.2 installed.

It's great to hear the OP care so passionately about Microsoft. We do face valid challenges, and I'll always be open to anyone who is trying to improve the state of my area, but it's important to note that the engineering issues are shared by everybody. If the OP has great ideas for how to improve performance of filesystems and storage, come talk to me.

Reply Score: 11

Why ZFS was actually written
by saso on Sun 12th May 2013 10:47 in reply to "Is it really Microsoft specific?"
saso Member since:

If UFS can't be fixed, have ZFS.

Minor side note: ZFS wasn't written because UFS couldn't be "fixed". It was written because fundamentally the classical storage stacks simply did not scale. The project's scope was much larger than just writing a new filesystem.

Reply Parent Score: 6

malxau Member since:

Its about "Get The F***K away from my code", when person who want changes is from oustide.

Well, I've never heard that statement or anything remotely resembling it at Microsoft. Most conversations focus on tradeoffs, priorities, consequences of a change, and resource constraints. These are not always obvious to the person proposing a change, who is only concerned with one specific thing.

...Which is another way of saying, it's not unlike my experience with Linux or Mozilla. All have a similar discourse with people sincerely focused on building the best product possible.

Personally when presented with a good change on one of my components, I'll gladly just take it - easier that than reinventing it myself.

Reply Parent Score: 5