This is old news, obviously. It's worth pointing out that as good as the code appeared to these reviewers in 2004, between then and now, Microsoft underwent a sea change in code-level quality control. Windows is now likely to be the best reviewed, most rigidly compliant code shipping on the market:
* Virtually every Microsoft senior developer has been trained on software security
* All shipping code is checked in-house, including some homegrown static analysis tools
* Most shipping products have had line-by-line source code reviews done by at least two different firms (we did some of this work for Vista).
During the Summer of Worms in '03, when Microsoft security lapses were front-page material on CNN, Bill Gates told the press that Microsoft was going to totally overhaul security and code quality. They weren't kidding. Microsoft now outspends everybody on that.
Amazing how people can only say anything favorable about Microsoft if they hide behind the guise of a competing company. God forbid a PC guy had this opinion.
In any topic that arouses people's passions, I find that if I want to say something nice about hated group X, then if I don't identify myself as a non-X, then people dismiss what I say as another one of those "damn X-ers".
It's irrational, yes. But that's human nature for you.
What's surprising, and perhaps sad, is that operating systems have aroused people's passions so intensely that it has become one of those volatile topics, like the canonical religion and politics, that one must treat very carefully, and certainly not bring up at dinner.
If I don't say I'm a Mac person, people say I'm a shill. It's also just the truth --- I don't want to imply I like using Windows (although I like Vista more than I like XP).
To me it wasn't the "Mac person" comment that convinced me of the point. Just the thoughtfulness that was apparent in the post. There was mention of facts, and it obviously wasn't a rant.
Kneejerk "Microsoft rules" or the opposite should be downvoted, even if followed by "I'm a Mac person". I'd like to think that's what would happen as well.
If someone ever writes a proposal for you priced by the lines of code, run in the other direction. It's one of the big scams in our industry, the "oh, we'll just scope the project directly off your estimated line count" thing.
Our practice focus is on code-assisted penetration testing; in other words, we'll read your code, but mostly to get a sense of what it does and how it's articulated. Then we'll write software to beat the shit out of it.
The nice thing about this is, projects are scoped by what the code does, and how exposed it is to attack, not by some arbitrary number.
I'd love to talk about the specifics of what we did for this customer, but I'm only able to say "Vista" because Microsoft publicly said we worked on it.
I think you could make that argument but you'd lose. To an extent not well covered in the trade press, a lot of the pain in Vista --- an epic flop --- was due to tradeoffs Microsoft made for security and against end-user happiness.
1) Pissing off users with no choice is one thing. Promoting open source is another.
2) None of the examples I gave go against user happiness, quite the opposite really. If you think something should be painful, you're less likely to notice when you're doing it wrong.
I don't know what you're trying to say here. I'm saying, if your argument is that there's a limit to how far Microsoft will go to ensure system security, and that limit is lower than the limit mainstream Linux will go to, you're likely to lose the argument. I can point to places where Microsoft has surrendered tens of millions of dollars to combat individual C code security flaws.
So let's stipulate that neither of us want to piss off users, neither of us are vouching for Microsoft's long term strategy, and neither of us are arguing against open source. We're not talking about whether you should use Linux or you should use Microsoft.
We're talking about, this is what it looks like when a company redlines security and code quality. Many of us have companies that ship code. It's worth knowing what the ends of the spectrum look like.
But if Microsoft will go to such huge lengths... are they actually more secure than Linux? Or are there lengths that they won't go to, no matter how much they spend?
I'm just going to say that when you slip a major release date for a multi-billion-dollar product by several weeks just to go back through all your code to see if there were any integer overflows that you might have missed, after somebody points out a new code pattern that might lead to them, you've firmly established yourself at one end of the spectrum.
I simply don't believe that any other team, open source or commercial, would do something like this. I've seen too many of both kinds of teams blow off actual documented vulnerabilities to think that they'd hurt their own progress to chase down hypothetical ones.
The rest of the discussion is academic to me. By all means, use Linux. We do for our Rails app. Hooray for open source.
And the process where developers submit their patches to a mailing list and they are reviewed by people above them is what?
A code review.
You can't measure Microsoft's expenses against the expense of developing Linux. Linux was not cheap to make either - just the time is distributed across a lot of books instead of one set.
I'm not even a little bit interested in getting into a religious argument with you, but I will take a moment to point out that the "code review" that a Linux kernel driver patch receives is nothing remotely like a security code review.
You missed my meaning. I was saying there are things microsoft won't do for security. For example adding a repository would get people out of the habit of downloading random software.
But it might be interesting to find out how much companies spend on security in the linux kernel. IBM, for example, is supposed to have spent billions on linux.
Adding a repository wouldn't alter security even a little. If as many people used Linux as use Windows today, we'd have just as much of a problem with Linux malware as we do with Windows malware.
"If as many people used Linux as use Windows today, we'd have just as much of a problem with Linux malware as we do with Windows malware."
I often hear that argument made and yet in the time I've been using Linux (since 1994) the total number of Linux users has increased by many orders of magnitude but I have seen no corresponding increase in the number of security issues. I think that it's because Linux is (much) more secure by design and process but I guess I'll just have to wait until the apocalyptic Xth user moves to Linux and I start having to worry about viruses, malware etc. to see if I'm right or wrong.
I don't understand why this is so hard for people to understand. There's virtually no Mac malware, either! But it is demonstrably trivial to create Mac malware; in fact, it's far easier to do that than to come up with a new Microsoft vulnerability.
The issue here is simple. People will target Linux when it stops being so overwhelmingly profitable to target Windows. We're nowhere near "peak oil" for Windows malware. It is, as Joel Spolsky points out, just economically irrational to target anything other than Windows.
This is the difference between safety and security. You are indeed safer on a Mac, just like you're safer living out in the country, even if your city house has a serious alarm system and bars on the basement windows.
I can't refute your argument any more than you can prove it to be true which is why I said I'll have to wait for the apocalyptic user to arrive. But if you can demonstrate some Linux malware (trivial or otherwise) it would add a lot of weight to your argument :)
What's your point? Malware is enabled by vulnerabilities. Nobody is arguing that Linux has lots of malware. Linux is safer than Windows. But it's not more secure.
I'm not so sure about that. Some malware installs itself by exploiting vulnerabilities. (Not all of it, though - there's plenty of Windows malware that gets installed by social-engineering the user.) But, in order to stay installed, most malware depends on other properties of the OS to conceal itself and stay installed. Windows makes this much easier for a programmer than Linux does.
I know that a lot of people say this, but I don't know a single professional security practitioner who --- when push comes to shove --- actually believes it. I'm not being glib or dismissive, but I'm also not going to argue the point anymore.
It's not a well-worded sentence, but what he means is that if you have to call out an ugly hack, the REST of the code is probably pretty decent. If the code is full of ugly hacks, they wouldn't be worth mentioning.
I think an important point is that the programmer recognized that what he/she was doing was an ugly hack, (presumably under some serious constraint, like time) and felt compelled to point this out.
A mediocre programmer might come up with the same fix, but not recognize that the fix was an ugly hack, and not comment as such.
I agree with the OP that this is a positive sign. The only thing that surprises me it that it seems to be a free-format arrangement of a word that can be used in a positive way. We have a magic comment word ("kludge", if you must know) that we use for code that we wish we had time to write better; that in principle allows us to go back and find things to fix after the fact, or helps troubleshooting since kludges are more likely to break.
I'm not terribly creative with code I write for others. Since I've been doing a lot of Java recently, using Eclipse, I stick with
// TODO:
Which has the added benefit (in Eclipse) of creating a tiny blue box in the vertical source error/warning/status bar (I'm not sure what it's official name is) so I have a visual cue to see where I have unfinished business (Kludges are unfinished business that you might get to next day or never, but even if it's a glorious hack, if you think its a hack and not a "proper" way to do it, its still unfinished business. In a prior project we used to use "glorious hack" as a special comment to use as the first places to investigate when something broke.
I agree with his assessment. Sometimes ugly terrible hacks are the best solution given the external constraints (time, 3rd party code beyond your control, whatever). And if you have an ugly terrible hack, you should definitely comment it.
Yes, but then you should go back and fix it. One can only hope that there were more "ugly hacks" that have since been fixed.
The measure of a good programmer is not whether he or she recognizes when they're writing bad code, but whether the final result is free of bad code, and thus more maintainable.
I would argue that someone commenting known bad code, but leaving it there in perpetuity is no better than someone unknowingly writing bad code (although the comments could serve as signposts to help someone else find and fix your bad code - but how often has that ever actually happened?).
I don't agree. I think all code of any size, bad or good, has these words in it. The problem with his statement is that "UGLY TERRIBLE HACK" is relative. One man's terrible hack is another man's normal day-to-day style. In bad code, there are just more ugly hacks that aren't commented as such.
What's interesting to me is the comments. I worked in a corporate environment that seemed to me at the time to be overly-paranoid about open source (any use of open source software had to be run past a legal team). After seeing people argue that Microsoft's millions of lines of code is in violation of the GPL due to a single Makefile, I have more sympathy for their concerns.
And even that claim was baseless as it was made based on a filename: GNUMakefile is a filename that GNU Make looks for before "Makefile". This allows the same directory to have a Makefile for traditional make and one used for GNU Make.
Good heavens. You mean that people really are claiming copyright violation on a makefile? Egads.
Now, i never really got the idea of source pollution if the source is never grabbed to begin with. All projects that rely purely on the GPLv2 have the same 'legal requirement', unless that code generates more code. Then, well, let the lawyers decide that one. I'm thinking of the license from gcc and like.
Considering the size of the codebase and the amount of developers that have contributed to it over time, I find the comments to be very mild.
Every commercial codebase has hacks and special cases. Limited developer resources, deadlines and idiotic external constraints (hello third party libs/apps!) simply force that.
There is an art to capturing stupid stuff that is beyond your control at the integrating level (with checks, logging and exceptions at that level) without allowing this to contaminate the deeper levels of your system. That's another story entirely.
If you want to read some highly amusing comments in source, read http://www.jwz.org/doc/censorzilla.html - the list jwz published of the stuff that had to be removed from the Netscape source code before it was open-sourced.
it's hard to see Microsoft's operating system competitors taking advantage of it.
Wine.
If I was them, I wouldn't be interested in copying it, but I would be interested in seeing how things were actually done (to confirm inferences as well as resolving puzzles.) But I believe that even seeing code leaves you open to a copyright infringement suit, which is why people do clean room reverse engineering. So, I wouldn't even look at it if I was them - despite my interest :-(.
* Virtually every Microsoft senior developer has been trained on software security
* All shipping code is checked in-house, including some homegrown static analysis tools
* Most shipping products have had line-by-line source code reviews done by at least two different firms (we did some of this work for Vista).
During the Summer of Worms in '03, when Microsoft security lapses were front-page material on CNN, Bill Gates told the press that Microsoft was going to totally overhaul security and code quality. They weren't kidding. Microsoft now outspends everybody on that.
Note: I'm a Mac person.