Slashdot Mirror
Are All Bugs Shallow? Questioning Linus's Law
root777 writes to point out a provocative blog piece by a Microsoft program manager, questioning one of the almost unquestioned tenets of open source development: that given enough eyeballs, all bugs are shallow. Are they? Shawn Hernan looks at DARPA's Sardonix experiment and the Coverity static-analysis bug discovery program in open source projects to conclude that perhaps not enough eyeballs are in evidence. Is he wrong? Why? "Most members of the periphery [those outside the core developer group] do not have the necessary debugging skills ... the vast numbers of 'eyeballs' apparently do not exist. ... [C]ode review is hardly all that makes software more secure. Getting software right is very, very difficult. ... Code review alone is not sufficient. Testing is not sufficient. Tools are not sufficient. Features are not sufficient. None of the things we do in isolation are sufficient. To get software truly correct, especially to get it secure, you have to address all phases of the software development lifecycle, and integrate security into the day-to-day activities."
Bugs are an error in the process, not the code. If you find a bug, you need to find the process error that allowed that bug to occur.
is this the natural follow on?
They become a lot shallower when you can look at the source code.
As we can all see, this has gone famously for Microsoft.
...the proof is in the pudding?
What do they say?
Sounds like he's selling something.
Unless you're writing some insanely complex application like a launcher for thermonuclear missiles, you pretty much will have user error as a major instigator of bugs.
Until you get your code into the hands of users who - for example - will repeatedly hit the ENTER key wile waiting for a response, you don't have a clue what might happen.
The Kai's Semi-Updated Website Thingy
Ok, you win. Most open source software hasn't been reviewed very much. Some open source software has security holes, and should not be trusted.
But, all proprietary software should not be trusted, at all. Proprietary software, by definition, has not been reviewed by anyone who hasn't entered into an agreement with the seller. The risk of accidental holes may be less, but the risk of intentional back doors is much higher.
This is precisely the kind of argument you become susceptible to if you think that an attribute of software (security) is more important than your freedom. Shawn makes some good points about the technical quality of software and it's true there may not be enough eyeballs to find bugs in free software let alone hands to fix them. What Shawn would have us take from this article is that free software may not be technically superior. It's an attempt to frame the argument and shape what's people think is important in software. Unfortunately, if you care about software freedom, Microsoft's FXCop and PreFast-clean mean nothing. Their software disrespects you as a user and keeps pushing the limits in dividing and taking power away from their user base. Don't buy this line. Choose freedom first and interested parties will take care of attributes like security, ease-of-use, and compatibility over time.
Comment removed based on user account deletion
Since when does MS have the right to say "To get software truly correct..."? They KNOW how to make software secure?
One of my most difficult bugs was fixed by simply rescheduling the time a datamining job was to run (which was integrated in to a massive ERP system with other major components of which i had no insight). It took at least 24 hours to test everytime i created a new build. Essentially it was a scheduling ordering issue, where pre-processing of other processes wasn't done in time.. It took me a month to figure this one out. Some times the bugs are outside of the scope of your own system, and the bug will probably re-arise as data grows. I've also had some difficult threading issues where a wait is never notified caused by bad error handling, which was fixed by simply renaming a file (after 1 month of multi threaded debugging with the final session taking 3 days for one execution).
That's kinda funny.
I spent part of today working around problems with a closed source application.
The other part of the day has been working with an open source program, where I've already solved the problem, and am documenting my changes to pass back to the author for the next release.
I'm not a "core" developer for any public projects. I've never submitted a bug fix to someone like Microsoft (but have sent bug complaints that went unanswered). I have sent quite a few bug fixes for open source applications, most of which were used in future release. I'm just another guy, or as indicated, another pair of eyes.
Serious? Seriousness is well above my pay grade.
Many bugs are caused by the silent L in in the word USER.
his argument is also wrong. he's assuming that just because developers are *paid* they are more productive than unpaid developers. how do you know that paid developers are not surfing the web all day? i just don't buy this at all...
It's also why something is in the last place you look - because you stop looking !
All bugs are shallow because eventually someone smarter than you looks at it, and it's obvious to them. How often and how soon this happens in practice is an exercise for the reader :)
I want to delete my account but Slashdot doesn't allow it.
To find the non-shallow bugs you need someone with the right experience and the right way to look at the problem and you simply don't get that by simply throwing lots of eyeballs at random bugs.
If one qualified programmer can write a bug and it takes at least one qualified programmer to find that bug then how can it actually be damaging to have many look for the bug, once it is identified even by a "non qualified" programmer others can address the issue much quicker. He seems to try to relate literal depth in the code to the comment "bugs are shallow", while some bugs maybe subtle and complex like all software after QA, first release and further have been completed others maybe be found much later on in the development cycle but they have to be looked for. Most professional (paid to work on the software in question) programmers write the software, debug, submit to QA and hands are pretty much off until they hear back. Something may come to mind later on that he/she may go back and change but who's to say someone professional or not is sitting back and actually discovers a flaw on his own time? Is that necessarily a bad thing? The change still has to be submitted to and committed by the (qualified) team that wrote it in the first place to change their software release. So in short you can't really question "Linus's Law" in this regard because it's only adding to the project, either by feature requests or bug reports. This keeps the software relevant and popular which is a good thing ... right?
A loop, by its nature, continues. If that didn't make sense, start reading this sentence again.
Any technological endeavor human beings work towards will always be subject to "more eyeballs means improvement". If there's not enough eyeballs, then there simply isn't enough people working on the problem.
I haven't RTFA. but from the summary, most of what this program manager says is intuitively obvious.
SB
It's old. The more humans I meet, the more I like my cats. At least they are honest.
All of those steps? Those are pairs of eyeballs. Electronic ones. This author isn't very critical of his own writing.
...though perhaps not in the way he intends.
Look, software is *hard*. Building an OS kernel is like assembling a thousand watch movements by hand. You're going to screw up. It's not a matter of "if". There Are Always Mistakes.
Now, when he says "truly correct", I'm assuming he doesn't mean formal proving. That would be absurd, especially for an operating system as complex as Windows or Linux (or really anything with limited resources). Anything short of the formal proof and you just have empirical evidence that it works - but if there's a billion branches and trillions of code paths, nobody will hit all of them with all data.
Fact is, stuff is going to break. You can't prevent it.
So if we can't keep code from breaking - if all significant code is buggy - what's the answer? Well, with open-source code you can find a bug in your application and debug through the kernel itself, finding out why your syscall isn't returning the right information, and fix it yourself. Then everybody benefits from your work - keep in mind, you only did it (or needed to) because your application exposed a flaw. If you're using Linux 1.8 for some unholy reason, well you can fix it anyway (just nobody else will care).
But if you're using Windows, and you get bad return data from a method, your best shot is probably going to be to just coerce the data how you want it. This happens *all the time* in closed-source software - handle a buggy OS method with a special case.
So "many eyeballs" is correct, but not because there are thousands of expert code analysts poring over every git commit. It's correct because any piddly little application developer can debug the kernel itself, following his own method calls around to make sure they do the right thing. Even if he doesn't know how to fix it, he'll be able to say "doThis(*myData) isn't returning the right value" and lead the experts (writers/kernel hackers) straight to a fix.
This is the strength of open source, at least from a code quality standpoint.
I have developed a truly marvelous proof of this comment, which this signature is too narrow to contain.
The funny thing about this article is that he essentially never mentions (a) design flaws or (b) perverse economic incentives to sell defective software. IMO these are probably the two biggest reason why MS has such a terrible reputation on security.
As an example of a design flaw, there are lots and lots of things that MS designed for ease of use, while ignoring security. MS software is way too willing to execute code in an email or on a web page just because they wanted to do something flashy without putting any responsibility on the user to know what the heck was going on. This is a design flaw. No amount of debugging will ever fully succeed in working around it.
The economic incentives to ship buggy, insecure software are also huge. Companies gather revenue by putting out a new version of the software with a long list of features. Users who buy the new version of the software generally have no way of knowing that it's full of bugs. MS is of course infamous for this.
Of course the implication of the whole article is that MS pays people to fix bugs, while nothing like that is going on in the open source world. This is complete nonsense. Most well known open-source projects are written by paid coders. But let's not let facts get in the way of MS advertising.
Find free books.
From the article:
One cannot deny the logic. In fact, it is a tautology. If you assume that all individuals have a non-zero probability of finding and fixing a bug, then all you need is "enough" individuals.
Emphasis added by me to show where I think his argument goes off the rails. "Linus' law" does not assumed that each eyeball is a bug fixer--it simply states that bugs are made shallow. Often the hardest part of fixing a bug is knowing about it, and finding it. The open source process makes it easier to do both, even if there are only a small group of coders actually fixing things.
This is not about how many software engineers you have reviewing your code. It's about how your end users can interact with the software engineers.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
You're shifting the focus here: the freedom do modify the software is a completely orthogonal topic to improving the software development process. There is nothing that would prevent OpenSource from implementing a better development cycle. Then may be the bugs such as OpenSSL PRNG would not have happened. Dismising his (valid) points, replacing them with a different issue and leaving untouched the premise "may eyeballs produce better quality software (no matter what)" is not productive.
Ladies and gentleman, the article author is making a strawman argument. By transforming the "Linus' Law" into a badly written syllogism, and pointing out examples where _his invented syllogism_ fails, he's implying that closed source is _better_. Unfortunately, the vulnerabilities of closed source are often worse, by comparison and from experience.
This is a classic absolutist fallacy. The author has taken what is essentially a rhetorical way of stating a more precise claim (that bugs become more shallow with more eyes and that as you increase this number the shallowness increases). The author has then found that that statement in its most general form might not be correct or might not be the whole story. And therefore decides to throw out moderate versions of the claim. I am not impressed.
Newsflash "Microsoft Employee quotes another Microsoft Employee who says Open Source is crap".
I might give the blog some small amount of thought if Microsoft had ever produced any software of any quality whatsoever. Microsoft's area of expertize has always been in marketing and this is an example of it.
More specifically, if you're going to attack the logic of a statement please don't use an argument to authority to do so.
One of these things is not like the other...
Features are to software correctness as apples are to oranges.
Really, do not subscribe me to your newsletter, mr 'program manager'
I don't know the meaning of the word 'don't' - J
Let me rephrase this for him -
"For 25 years, we deliberately chose to ignore the bitter lessons that were learned by the big vendors, to take shortcuts
to ship shit software first and fix it later and to build up massive layers of cruft in the name of backward compatibility. Now we are caught in a nice pickle
as we've spent years trying fill the leaks in our crap - some of which is so insecure that, 8 years after the launch, we still have record numbers of bugs in
Windows XP almost every fucking Patch Tuesday -and restructure it into something rock solid.
However, until we can get this done, we need to play smoke and mirrors, convince you to toss Win XP - and your old PC, most likely, buy our latest
and greatest and spit out evermore FUD about how nobody else can get stuff done except us.
Ladies and gentlemen, I give you the M$ business plan and I'm pleased to say that it's working as well as ever and thank you all"
Pain is merely failure leaving the body
I'm all for open source software. I could give you a dozen reasons why it's a great thing.
But does anyone REALLY believe it's bug-free because there are lots of eyeballs on it?
From the first time I heard that argument I thought it was laughable and not backed by any solid evidence.
He's attacking that argument for a simple reason: Because he can. It's a stupid argument.
And he's getting people all worked up and distracted over it.
Meanwhile, in the next room, Microsoft salespeople are convincing your boss they need to switch all your licensing to a yearly subscription model, and that there's no reason why you should actually OWN the software that you're paying all this money for.
But at least with open source you can find and apply the proper eyes to software you did not write yourself instead of just trusting the vendor.
I'm not sure if you read my comment closely. I do see his point as valid and we do need more eyeballs and hands on free software(not open source). I just don't want people to miss the forest for the trees. The trees are so many technical, popularity, and quality arguments that are posed by proprietary software developers to obscure a more pressing issue: user freedom. Note, I'm not talking just software freedom here. We need software to live our lives but we also use many services that seek to lock us in, categorize us, track us and direct us to perpetuate ourselves as good little consumers.
You posted as AC possibly because you feel your point of view is not popular on Slashdot but I really wonder. Aren't you concerned about your future freedom when so few companies control not just your communications, your periodicals, but the very instruments(your computer and devices) you use to take in this digital world?
bla, bla, bla ,bla, bla
Got Code?
Ok, I've got some news for you. The quotation is not meant like an immutable law. There's a really good, important point there, but it's still just a meaningful aphorism. Let me help you with this -- when you see "given enough eyeballs, all bugs are shallow", read it as "given enough eyeballs, [almost all] bugs are shallow". Does that help? Can we move on now? This discussion is so stupid it's almost painful. Here are some other things to know: MS blog author wants attention; ESR is a self-important moron. Thank me later.
flamebait? - only if windows source code has achieved self awareness and is now capable of flaming.
And did you exchange a walk on part in the war for a lead role in a cage? - Pink Floyd.
Like they know anything about finding or fixing Bugs...Puuleeze. I take anything I hear from Redmond as complete BS, Except for news of Ballmers termination/resignation..at that point, I go ALL-IN on their stock.
Mathematically, the many-eyeballs argument, and the million-monkeys argument are equivalent.
Yes, but this is only true if N(eyeballs) = 2 million - N(one-eyed monkeys) - 2*N(zero-eyed monkeys). Of course, once we have humans and their eyeballs involved, we will need modify this recently discovered Microsoft monkey-eye theorem. We should inquire if Microsoft considers human and monkey eyes equivalent in order to determine the effective conversion factor between human and monkey eyes.
A Microsoft Creationist would set the conversion rate at infinite, since our eyes are in the image of God, and monkey eyes are not in God's image. I find this ironic, since God is invisible and therefore has no image.
A Microsoft geneticist might argue that the similarity in eyeballs is comparable to the similarity in the genetic code that encodes the eye. This might state the monkey eyes and human eyes have 90% of their genes in common. However, these genetic differences represent a vector in an N-dimensional space, where N is the number of genes required to express an eye. If we assume that human eyes are the reference, we can determine the 'gain' (presumably less than 1) of the monkey eyes of by finding 'eye-gain' vectors of the Monkey eyes. We can then use a standard inner product to determine the 'eye-gain' values for the various monkeys used in this "Microsoft Writes an OS with Monkeys at the Keyboards Experiment".
In either case, Microsoft will need a new Math to support this claim. When the blogging Microsofty proves this assertion mathematically, I will be only to happy to equate Microsoft with monkeys coding an operating system.
Think global, act loco
Of course, humans cannot think of everything, but with the right software model and the right tools, we will be able to. For the same reason that we use tools to perform complex calculations flawlessly, calculations that we use to have an extremely hard time doing reliably manually. We don't have the right software model in which to construct rock-solid applications because we are not thinking outside the box. We are addicted to our way of doing things.
I defend the hypothesis that the two major crises that afflict the computer industry (unreliability and low productivity) are due to our having adopted the Turing Machine as the de facto computing model in the last century. The thread concept (algorithm) is fundamentally flawed and the use of multithreading in multicore processors exacerbates the productivity and reliability problems by at least an order of magnitude. The only way to solve the crisis is to switch to a non-threaded, non-algorithmic, syncrhonous (deterministic), reactive and implicitly parallel model.
The big surprise in all this is that the solution to the crisis is not rocket science. It is based on a simple parallelizing concept that has been in use for decades. We already use it to simulate parallelism in video games, simulations and cellular automata. Use two buffers; while processing buffer A, fill buffer B with all the objects to be processed during next cycle. When buffer A is done, swap buffers and repeat the cycle. Two buffers are used to prevent racing conditions and ensure robust timing. No threads, no fuss and the resulting code is deterministic. We just need to take the concept down to the instruction level within the processor itself and adopt a synchronous reactive software model. It's not rocket science.
Folks, the days of Turing, Babbage and Lady Ada are soon coming to an end. It's time to wake up and abandon the flawed ideas of the baby-boomer generation and forge a new future. The boomers were wildly successful but this is a new age, the age of massive parallelism and super complex programs. The boomers need to retire and pass the baton to a new generation of computists. Sorry but that's the way I see it.
Rebel Science News
Open source bugs get fixed because people notice and are bothered by the bugs. This is the biggest motivator of open source contributions - everybody has an itch to scratch. The bugs that get fixed fastest are the bugs that are encountered the most. And this is why the Microsoft guy is absolutely correct in his analysis.
Bad security is not a user-facing bug. Unlike functionality bugs, there is little incentive for community members to identify and fix security bugs. Sure, the Linux kernel and other key packages will attract expert eyes, but the average random piece of open-source software will not.
Security analysis is both complicated and un-glamorous. There are not a lot of people attracted to that kind of work. There are even fewer people who would do it for free. The position of the linked article is that it's better to pay people to think about security than it is to rely on the principles of OSS. I agree 100%.
What is it you are trying to sell exactly? Microsoft Secure Development Lifecycle?
"Eyes" on the source code aren't just code reviewers... they also consist of the attackers. Ok.. attackers have to find vulnerabilities to exploit somehow. The same techniques used by would-be attackers against the source to find exploitable holes can be used by the community (with source code access as a pre-requisite) to more effectively and with greater number people searching for things they can take advantage of, the more likely any issue is quicky found.
The only way to find faster, would be perhaps for someone to offer a bounty for anyone finding verifiably exploitable privilege escalation or remote exploitable security bugs in a default build of a stock kernel :)
The funny thing is... even addressing "at all phases" of the software development lifecycle and "integrating security into the day-to-day activities" is not enough to be secure.
Observation: This is the closest thing I believe I have seen so far, to an admission, from a Microsoftian, that their software can be inherently insecure (by design).
Seeing as the initial design is one of the most important parts of the software "lifecycle" by some views of the situation.
But the above quotation didn't argue merely AGAINST more eyes. It argued that essentially you can't make software more secure by looking at it, having code reviewed, and testing it.
That's absurd.
While there can be security weaknesses that won't be detected by thorough testing or code review, very large classes of security weaknesses can be.
Also, the complexity of the software systems interacting comes into play here...
Applications with simple well-controlled interactions and stable API (E.g. not like Windows) are less likely to have security issues that can escape a good code review.
kernel debugger
One big piece of FUD here is the notion that Microsoft programmers are paid, while open source programmers are not. The open source projects I know of advance mostly because of paid programmers, and I suspect that that is the case in general. That gives them the usual capitalist incentives for finding and removing bugs.
I am intrigued by your ideas and wish to subscribe to your magazine.
In other news, tobacco companies claim that smoking isn't linked to lung cancer.
Actually, most bugs that survive initial testing are not shallow. If they were, they'd have been caught early.
A key point of the article is that almost nobody in the open source world is really looking hard at old code. An experiment was run to encourage code review, but nobody really wants to do that. This is related to the phenomenon that many open source projects stall out at version 0.x. The basic functionality is in, the fun part has been done, and the boring grind of making the last bits work isn't getting done.
Some bugs are so deep the open source process can't fix them. Search Google for "prune_one_dentry oops". The Linux kernel is known to crash when all free memory has been taken over as file cache, a process needs memory, and due to some lock being set, file cache space can't be released. Bugs of this type have been reported steadily since 2004, and it's still not fixed. It will probably take a redesign of some fragile code to fix that, and nobody wants to take that on.
The most important tool, in close to the 20 yrs experience I have had, to discovering flaws is experienced users. It is *their* software which *you* have built for them. *They* know when things are hosed.
In my experience, FOSS maintainers have take take criticism and released fixes far more rapidly than any software vendor I have ever worked with. And as developer the most important thing to do has been to talk to power users and get their feedback. MS does not do any of this. No matter how much money you pay them.
putting the 'B' in LGBTQ+
Air France went into the ocean. THERE WAS NOTHING WRONG WITH THE CODE!!!
What was in error was the philosophy the code was written by.
A philosophy that disallowed human intervention. Disallowed for human handling of exception.
A philosophy that put machine over man.
Don't bow down to the stone image of the beast of man, for this beast is error prone and the image of this beast can be no better, even in perfection of an image.
computers are made of stone, mineral, metals, etc.. and the image is of thought processes.
no need for religion in this realization.
Open source allows for human interaction in its fundamental philosophy, where we all can make or contribute to correction and refinement.
Another example of perfect code and failure was the newly installed 911 service in Atlanta, for the 1996 Olympics. A system that required an address to be entered before it would transmit the call to the field.
Were was the failure here? Failure to give the Bicentennial park an address? Or expecting all places of crime have been given an address?
There was nothing wrong with the code of the software but in the design philosophy of the software.
in other words there was no code to correct, without first realizing the philosophy the code was based on was what was in error.
Microsoft is by far, practicing a philosophy of being successful by entrapment of its customers, making people need Microsoft software.
And a large part of how it does this is by being Windows, where you can see where you want to go, but you can't get there by yourself.
That's not the way open source software works. And it is open source software pressure that gives MS motive to improve its products.
And MS is biting the hand that is keeping it from being consumer to much of a fat lazy corporate consumer entrapment marketing firm, of which it apparent wants to be.
And we have seen and continue to see legal courtroom proof of MS's intent.
One of the key arguments that people like to taunt regarding software security and specifically open source security is the fact that they compare say redhat enterprise 4 to Windows 2003. If you look at the Redhat Errata you may start to be alarmed. The question then comes around... 'who actually installs EVERY single redhat package when they install the whole system?'.. the answer from my experience is very few. However that is where many of the comparisons come from. If you segregate the overall number of comparable systems between linux and windows you will often find that the number of security vulnerabilities to be not wildly different. However if you compare the whole distribution's release to a windows install then your going to think.. 'dang windows is secure'. There are several other points in the argument that I tend to enjoy asking people who use these types of numbers.
1. if you have so few vulnerabilities what is your exposure footprint? e.g. how many people are trying to trojan you on windows vs linux?
2. how many of the vulnerabilities have been reported by the community that develop the software? If we look at Firefox for example most of their vulnerabilities are not actually reported by hackers or security experts but by their core developers who realise someone else in their team wrote some crap code or didn't properly do something. Here are some URL's to give some further evidence http://www.mozilla.org/security/announce/2009/mfsa2009-47.html http://www.mozilla.org/security/announce/2009/mfsa2009-63.html (although after actually going to find evidence I found that in 3.0 and 3.5 most vulnerabilities came from researchers and not the community like many earlier releases)
but nobody remembers who the critic is.
and this critic is far less known than Linus.
And obviously less experienced at actually dealing with software development.
This is precisely the kind of argument you become susceptible to if you think that an attribute of software (security) is more important than your freedom.
I'm a person with an @gnu.org email address, and I approve of this message! ;-)
I will go out and say that the quality aspects of software are important too.
But freedom helps that along. You're more secure against Linux Genuine Advantage, because free software doesn't have activation shenanigans going on (although I do have a perl script I'd like to give you if you like). If enough people want a feature that goes against corporate gatekeepers' interests, someone who's able to code it up might go do it. Hopefully (and likely?) the many eyeballs are a bigger benefit than they're a detriment; it does take time to weed out the amateurish---which is different from amateur---patches and bug reports, though.
And in our current software landscape where the dominant free OS is unix-like, the hackers (and power users) enjoy a different kind of freedom too: they're more free to tweak their computer so it performs the way they like it to. As I recall, when I was using proprietary (non-unix-like) OSes I couldn't as easily automate things and write small nifty shell scripts to help me make my computers run just right. I think this is a valuable (but different) form of empowerment that may be useful to illustrate to people the free software ideas: "now imagine that the software didn't have the knob you wanted to twist; why, you could add that yourself, or if enough people want it they might. [etc.]"
But to recap my first point: even if free software isn't automagically more secure and less crash-prone, we can make it so, and due to its nature it is secure from some of the annoyances seen in proprietary software. That alone is a big win; and I hear here on slashdot that the headaches had and salaries spent when ensuring license compliance make free software a good value proposition from the get-go.
Getting software right is very, very difficult. ... Code review alone is not sufficient. Testing is not sufficient. Tools are not sufficient. Features are not sufficient. None of the things we do in isolation are sufficient. To get software truly correct, especially to get it secure, you have to address all phases of the software development lifecycle, and integrate security into the day-to-day activities."
Well, maybe if you started out with a language that was properly designed to guarantee certain qualities (like Haskell), instead of the tar pit that is C/C++, you wouldn’t have to do all that magic to guarantee proper code.
But oh, it’s so much work to use QuickCheck to guarantee that the software will do what it should.
Yeah, so you rather take even more time to write the tests and do all that magic later, and still not have a 100% guarantee.
Way to go...
Any sufficiently advanced intelligence is indistinguishable from stupidity.
This seems to be no more than a M$ rep saying they have more "eyeballs" than linux because they pay for their "eyeballs".
I feel the need to explicitly call this guy a shill, rather than imply it. IF he honestly believes what he wrote, he's merely an idiot.
Shawn Hernan has deliberately misconstrued what Raymond wrote. Raymond explicitly said that the phrase "Given enough eyeballs, all bugs are shallow" was an informal phrasing of the lesson, in the very first sentence of the lesson. The actual phrasing was given as "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix obvious to someone." There's not even one sentence separating the two.
Trying to rip apart an informal phrasing, and ascribing hidden syllogisms to it, tells me this man is either an ideologue or an idiot. Given his position, he's a dangerous ideologue or idiot.
If opportunity came disguised as temptation, one knock would be enough.
3^2 * 67^1 * 977^1
And I don't appriciate beeing called shallow, you insensitive clod!
Reality unfortunately insists otherwise. We can't blame Microsoft for it but it is still the rule rather than the exception. There are plenty of idiot developers out there that still have the single user MSDOS mindset where security is not seen as a problem because from their viewpoint the user only has a computer so that they can run that developers application and nothing else. "Security" dongles are a major offender and other bits of crapware that insist on running services instead of just running like a normal application. You could run things like that as normal users but developers have admin so they write it so it MUST run admin.
That is more of the cause of the malware plague than Direct-X, old versions of IE and MS Outlook.
Oh yes, remember that a "power user" is an Administrator that just hasn't given themselves full permissions yet but they or the malware they bring in can do that without help.
Heisenbugs like race conditions (http://en.wikipedia.org/wiki/Heisenbug ) are rarely 'shallow', in that they usually require a lot of analysis, reasoning and testing, and dedicated time to form a mental (or otherwise) model of the code. The argument for 'shallow' here is the potential number of people willing to invest that kind of effort.
Having source code helps a lot, even more when you can instrument the code or use some sort of debugger (which itself can change timing etc and perturb the resulting behavior), but I've tracked down heisenbugs without it.
The previous comments that 'design counts' is certainly true, and there's often trades to be made in the kind of potential conditions you can get. For instance, some synchronization approaches can trade the chance of deadlock against the chance of race conditions.
I'll not comment on whether Microsoft code is "better", since I choose to avoid Microsoft products. (But I will note that many, if not most of the Microsoft desktop products started life outside Microsoft...)
To me the most appropriate word for Open Source compared to commercial software is *inexorable*. Open Source is the relentless glacier (ok, Borg for those of you who need to get out more) that grinds all in its path. Even worse than a static Borg, Open Source is snowballing through the network effect. Even the latest and greatest cellphones are Open Source and companies are scrambling to adopt it in devices and their corporate data centers. Microsoft can't defeat Open Source due to the different set of economics at work. It is simply a matter of time before Microsoft cannot offer enough new features to make paying for it more worthwhile than using a free equivalent.
The way I see it ..it's just a matter of point of view... if u want to see open source as better thing - u can find arguments, if u want to do the oposite - .... ...i can say that open source is way more secure ...i dont know if it is becouse of many eyes looking over the source or not ...but we all remember what happend when lsd-pl.net reported the DCOM bug in Windows ....what happend ? 5-6 patches 'till M$ fixed the issue .... what about the patches that stoped some services ? .... ask google ;) btw do u remember what M$ said when the .cn attaked google, adobe .. ? ? Update to IE8 ...dosnt matter that ..... :) YEAH :D NICE :] .... even super :] ...at least when i use opensource i can patch the source ...or I can pay someone /if i can't do it/ to do it for me .....but when using prop. software I have to w8 for M$ to patch it ? What .....one month later ? And 'till then ?! What ..?!? Don't use IE ? ...but i'm sure that from security point of view is the better choise!
But as a person who looks at the few bugtraqs every day
So after ~10y of work on it , XP is not bugs free yet..... not even close
it's vuln
p.s. i'm not sure if opensource is better or not
"You see old friend. I've brought more auditers than you did."
-- 'The' Lord and Master Bitman On High, Master Of All
Well, he makes some good points. Code review is indeed difficult, requires good skills, and is not done by many people in the free software community (the OpenBSD development team being a notable exception). Good software engineering methodology is crucial, certainly.
He concludes that Microsoft ends up shipping fewer vulnerabilities than anyone else. Is this true? Well, with the obvious exception of OpenBSD, it might be; but that's not the whole story. What developers do when a vulnerability is found is pretty important, too. Probably even more important.
Not long ago, a serious vulnerability was discovered in several versions of IE. Turns out Microsoft had known about it for several months. So, naturally, they had a patch all ready and tested before it became a problem - right? Well, no. Instead, they urged users to upgrade to IE8. The bug didn't get patched until almost a week after exploits were seen.
For all their professionalism and expertise, Microsoft developers labor under a severe handicap: they have to work on what Microsoft managers tell them to work on. They may think that a given bug is urgent and should be patched right away; but at the end of the day, the priorities are set by people who are focused on the bottom line, and those people know that nothing much is going to happen to Microsoft if a vulnerability is left open for a week or two. Every year, people in the Linux community confidently assert that this is the year of the Linux desktop; and every year, they're proven wrong. Too many people are locked into Microsoft's proprietary formats, and have too much time invested in learning to use Windows, to switch easily. And that's not going to change anytime soon.
A major factor in what makes open-source software more secure?
The kind of hacks that make people cringe don't survive for long, and are less likely to even make it into the wild.
Imagine you're coding on a closed product, your management demands a feature, and you're pressured into "just doing it". You're likely to just make an ugly kludge, build it, and ship it.
Now imagine you're required to release the source code as well, and you know that at least one coder you respect is going to be reading it.
Can this guy not even read? Or is he just too lazy to do the tiniest bit of research into Linus' Law actually is? From The Cathedral And The Bazaar:
Linus' Law says nothing about how many bugs are introduced into a system, or how well code is generally audited. All it says is that once someone finds a bug, if you have enough people looking at that bug, someone will figure out what the problem is, and someone will figure out a solution, pretty quickly.
That's it. And it is still true.
Why doesn't the gene pool have a life guard?
Let's see: [2]
Mr Microsoft Man: "Eyeballs alone won't make a kernel secure." :) DCOM dude ;]"
Mr FOSS Man: "Yeah , and less eyeballs make it more secure
Let me try this on for a couple of other common criticisms of some FOSS projects:
Mr Web Man: "Safari is way faster than Firefox on OS X and uses less resources."
Mr FOSS Man: "Just like IE ? btw ff runs on irix , does safari ?"
Mr Netbook Man: "The Gnome desktop is still kinda clunky, even after all these years." :)"
Mr FOSS Man: "And XP after so many years is so cool
Mr Graphic Designer Man: "Linux still doesn't do proper color management." ... for colors u must use MacOSX. :)"
Mr FOSS Man: "Well
Mr Gamer Man: "There aren't any decent games for Linux." ...their are few games ...but not much .... but more then what we had few years back ."
Mr FOSS Man: "Well
Who's derailing the conversation here, again?
Mr !FOSS Man: "NTFS is really stable and secure :)"
Mr FOSS Man: "i really don't need to say anything more."
Mr !FOSS Man: "MacOSX is super." :]"
Mr FOSS Man: "Yep. And the most unsecure OS
Mr !FOSS Man: "DirecX is better then OpenGL" ....belive them :}"
Mr FOSS Man: "Yep... if M$ said - it's true
Mr !FOSS Man: "Windows is easy to use." ...and reliable.... just tell your vista to compress C: and see the message after reboot."
Mr FOSS Man: "Hah
My point: OpenSource has his strengths and weaknesses, just like prop. source.
He reports Coverity's results on open source software
... but doesn't report Coverity's results on Microsoft's software.
He reports that Coverity scanned 280 open-source projects
...but doesn't report that only 180 of those have "active developer support".
He can't be bothered to present any data at all on the distribution of the reported or corrected defects — how many are in nethack or aalib or that long-abandoned "flash-based photo album generator"?
He doesn't, for instance, mention that Samba and several others have no defects Coverity can discover. None.
Vim has none. X.org has ... three. All of KDE, nearly five million lines of code, has ... ninety. glibc has none.
There have been MySQL and PostgreSQL and Berkeley DB versions with none. His bioblurb says he's "currently working to ensure that Microsoft SQL Server is secure". That's interesting. You mean it isn't, now? How many defects can Coverity find in SQL Server?
TFA is a nauseating pile of sneers and aspersions ("Hope is not a security strategy"?) built on a very carefully selected and very few facts. "No one is doing auditing" he quotes. "No one is doing auditing" and reporting it to some self-styled central authority almost no one ever heard of is what's true, but telling the truth isn't what he's doing here. He's a "Program Manager", and he works for Microsoft.
As always, all IMO. Insert "I think" everywhere grammatically possible.
I'm sure that this theory sounds really far out when you're high, but it has some major holes.
First, given the understanding that expression C(n) might depend on A(n-2) and B(n-1), we can easily see that a pipelined finite state machine can be optimized so that it uses circular buffers large enough to allow references to computations made in earlier pipeline stages.
However, suppose you want to recognize a context sensitive grammar? That's a PSPACE-complete problem, so the number of back references can equal or exceed the size of the input. In other words, we cannot statically compute the size of the circular buffer necessary to decide a given CSG, let alone an arbitrary CSG. That means we have to use garbage collection to manage the lifetime of each sub-expression.
But if we're using garbage collection, then we might as well even use lazy evaluation. And shoot we might as well even write the programs in Lisp.
Great Scott! I think you've reinvented the Lisp machine. Someone call Doc Brown so he can bring us back one of those computing dinosaurs from 1973! We could make millions!
I work in a completely unrelated field in which safety (the one that makes you go back home at night, not the software kind) is paramount. The main strategy for improving safety is the constant repetition of the old adages: "safety is everyone's responsibility", "safety is not a feature but a design philosophy", "safety must be central to all phases of the product's lifecycle", etc...
The reason management chooses to bombard employees of all levels with these semi-empty vague sentences is that they trully have no idea how to target safety directly, what causes unsafe conditions and how to prevent these. They are not entirely to blame since most unsafe events have a very low associated probability and are, thus, impossible to predict. The fallback position is that trying to keep safety constantly in the minds of people, albeit as an empty concept, would further reduce this probability
Mine is an old and antiquate industry. What scares me is that Microsoft, the supposed leader of a new and agile industry, resorts to the same techniques of force feeding a safety culture by exhaustive repetition of these empty statements. It just tells me that they, as my managers, have no fundamental idea of the origins of safety. Except that software safety should and must not be a probabilistic event if you trully know your software.
GPL is kind of like the paparazzi following you around saying "you're free to do anything you want, just as long as you don't mind that I share it with everybody". Hmmm, actually it's like if the paparazzi would force you to take your own pictures and publish them.
From the sound of your analogy, you clearly either don't understand the GPL or you are just trolling.
The only time you have to share your changes to GPL'd software is if you have modified it and choose to -distribute- it. If you don't distribute the modified version, you are free to keep the changes to yourself.
Merely using GPL software doesn't force any restrictions on you.
Your paparazzi analogy is pure FUD.
You know, the language of the GPL is pretty straightforward. Why don't you take a few minutes to actually read it before you start spouting more crap like this.
A house divided against itself cannot stand.
I defend the hypothesis that the two major crises that afflict the computer industry (unreliability and low productivity) are due to our having adopted the Turing Machine as the de facto computing model in the last century
You're hypothesis fails by being based on false assumptions. The Von Neumann architecture has been the de facto computing model, not the Turing Machine. Turing Machines suck at IO.
Furthermore you don't seem to understand that the reason computer programs are, as you call them, unreliable and low productivity, is mainly because programming is hard, and most of the time this has nothing to do with threads. Have you ever spent hours trying to get elements to line up perfectly on a web page in three different browsers? It is a problem that makes you want to pull your hair out, and yet it doesn't matter whether you are running with threads or with double-buffers, the problem will still be there. Programming is hard because controlling a computer is hard.
The boomers were wildly successful but this is a new age, the age of massive parallelism and super complex programs. The boomers need to retire and pass the baton to a new generation of computists. Sorry but that's the way I see it.
What the hell? When did this become a generational war?
Qxe4
I learned something about "Group intelligence" from the quiz show Who Wants to be a Millionaire in which contestants are given three lifelines to help them answer difficult questions.
The weakest lifeline by far is to appeal to the wisdom of the crowd and ask the audience. This only works for the simplest question.
Phone a friend works better IF you know the right friend.
However the most powerful lifeline. The one smart players keep till last is 50:50 - randomly removing two wrong answers.
So if open source debugging is equivalent to "Ask the Audience" then closed source debugging by the specialised team of developers is "Phone a Friend". Now all we have to do is figure out what is the debugging equivalent of 50:50 and all our problems are solved.
Breaking News! Neat one line slogan not completely accurate! More in our special feature at eleven.
"Hannibal's plans never work right. They just work." Amy/A-Team
Bugs are an error in the process, not the code. If you find a bug, you need to find the process error that allowed that bug to occur.
Not in the code?
Of course bugs are errors in the code. Duh! And sure, bugs may be errors in the process as well.
But why the false antithesis?
-wb-
questioning one of the tenents of open-source...
Well he would, wouldn't he ... how is this news ?
Unicode killed the ASCII-art *
You get it exactly and word it perfectly.
Linux IS its freedom, without it, it wouldn't be the same and might not even exist.
One of the most beautiful things I find about GNU/Linux is that I can get a working development AND/OR server environment all from a single package manager. That is because all the software is free, no endless license agreements to click through or setup programs that try to install all kinds of crap or require me to register. Just apt-get/pacman/emerge.
To me windows is the OS that never fails to have a major hickup. Silly stuff like suddenly deciding I got duplicate ethernet cards or freezing completely on a copy and don't even get me started on the long work of visiting every website for all the various apps that I use, downloading them manually, then installing them, clicking through all the decisions, organising them efficiently (why does everything go in the main menu?).
OSX is little better although its setup is easier you still got to go hunting yourself. And don't even get me started on when you want to configure basic things like the END and HOME key to behave as you would expect them. And neither OS has focus under mouse, a basic feature that linux/unix gui's have gotten right for decades.
But all of that exists, because of the vision of a free set of tools Stallman had. Same as there are still whales swimming thanks to the "extreme" views of Greenpeace. Sure sure, you might to want to wear fur, but then you can't have whales.
I think it is sad that having principles is today considered extreme. People who say opensource freedom don't matter say that because they don't vote, democracy does not matter. You might be right, if you ever been in a place like China (and there are far worse places to be as a westerner) then you might have a hard time figuring out why dictatorship is so bad, everything works and crime is low.
A paradise surely? Yup, right up to the point that it is YOU they are coming after.
We recently have had two stories about software products being bought and their future being in doubt. MySQL now being owned by Oracle, and its future is fairly safe because GPL is hard to kill off. But what about FAST search now owned by MS? Oops its unix/linux support is gone just like that and screw anyone who depends on it, no way out for them.
Freedom, it doesn't matter until you no longer have it.
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
Your entire argument can be brought down by the fact the IE is such a lousy browser. Or that Vista blew chunks. Where is this paid for quality?
I will grant you that documentation is hard to get written for free by a developer because dev's hate doing that, but if paid dev's are any better, then why is the documentation for Windows so piss poor (they got into a bit of trouble with that in the courts when they were ordered to hand over the documentation and it was found out just how bad it was).
If you knew a bit about human beings you would see how stupid your argument is.
Who produces the best quality, a person only doing their job for they money OR a passionate volunteer who does it for the love of the job. Gosh, that is a hard one. It would be like asking which is better, a Soviet era Yugo or a McClaren F1. And the beauty of opensource is that the Yugo costs a fortune but the F1 is free.
You do remember that software is a unique product? No real production costs. Only the salary of the coder and if he works for free because he WANTS to do it... then the sky is the limit.
It tooks years for MS to get its webserver even close to performing as well as Apache, despite countless paid dev's. Windows security and reliability was a joke, despite years of paid developers.
Where are the results of all those paid developers?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
As why it should be impossible to build a very complex software in open source that is better (or at least equal in quality) than closed source teams?
Do we even need to give proof to refute this?
BAIN http://www.devslashzero.com
Wasn't the windows source code leaked or something and when people tried to compile it, it turned out endless compiler errors just on the kernel? What do you mean get my facts out of here? This is a marketing only zone? I protest! I got my freedoms... oh, I don't have any freedoms, all my freedoms are belong to MS? Shoot, knew I should have paid more attention to that Stallman guy. Sure sure, I will bend over for the next windows update license agreement, will there be lube this time?
MMO Quests are like orgasms:
You may solo them, I prefer them in a group.
UAC was created to fix a problem that was there before by a design problem. If there was no problem UAC would not have been needed.
Mr Microsoft Man: "Eyeballs alone won't make a kernel secure."
Mr FOSS Man: You don't have enough eyeballs in your code, only MS employees, and you have a powerful marketing department pressing you. So you spread FUD... Security through Obscurity NEVER is a good security policy -Ancient Masters of Security (TM) said-.
"Let me try this on for a couple of other common criticisms of some FOSS projects:" Well, let's review it again.
Mr Web Man: "Safari is way faster than Firefox on OS X and uses less resources."
Mr FOSS Man: Safari only works well in OS-X, an OS with a little market share - as Linux/BSD/etc. , but all of them growing constantly -. And it's closed source too, because the car is more than only the engine...
Mr Netbook Man: "The Gnome desktop is still kinda clunky, even after all these years."
Mr FOSS Man: Use another desktop; you have KDE, XFCE, LXDE - this is very good for netbooks -. Afraid of Freedom/Choice? Lazy? Yo can use an overprized Mac with OS-X too.
Mr Graphic Designer Man: "Linux still doesn't do proper color management."
Mr FOSS Man: What area? Publishing? Desig? Image editing?... Do you know other things apart Photoshop, baby? If you must use PS, cry loud for your vendor locking and use Windows. I'm sorry for you, you can't use other alternatives.
Mr Gamer Man: "There aren't any decent games for Linux." ;-).
Mr FOSS Man: There are FEW comercial games for Linux, and plenty of other games; don't tell lies, God will punish you xD. If you don't like them, use a game console or a Windows gaming PC. Freedom again
Who's spreading FUD? Who's afraid of freedom? Who's de one who ignore alternatives by default? Make your choice, you are free... And "Just Works"(TM) software is becoming a legend, unless you have an "standard" configuration - like Macs & OS-X or the Wintel Core laptops -.
"Most members of the periphery [those outside the core developer group] do not have the necessary debugging skills" Well, yeah, but there's a shitload of possible candidates. It's just as easy to say that the members of the team on a closed source project do not have the necessary debugging skills.
And years later you can't use the HW any more because the windows driver doesn't work in your latest OS.
Yet that years old hardware will work in your spanky new Linux OS.
Today, a pithy aphorism was found to be not literally true. Film at 11.
You can see someone else's code in CSS? Oh, no you can't. So for the DEVELOPER there's no difference between FOSS and CSS. But you are not one of millions of potential readers of CSS code. You're one of a very few.
For EVERYONE ELSE, your code is harder to debug and becomes immeasurably easier to debug if you release the code under GPL.
Generally, two philosophies exist:
that open source is more secure because it is more rigorously reviewed;
and, that proprietary software is more secure because access to the source code is limited.
While seeming contradictory, both schools of thought have validity depending on circumstances. Open source philosophy states that open source software cannot rely on obscurity for security — because the source code is transparent, security must be implemented well at the source code level. Also, open collaboration is thought to result in the earlier discovery and correction of security flaws—an aspect of the thesis that “given enough eyeballs, all bugs are shallow.
The answer depends on the type of code, process used, and history of the people involved. I don't doubt that a PM at Microsoft believes that every bug is simple to find if just enough eyes look at it. No doubt at all.
I've worked on real-time space vehicle GN&C code where a slow answer is a wrong answer. We've had a few really complex bugs and a large number of "duh" bugs that the review team studied, but then were convinced it was fine. We've also had bugs where 20 seasoned professionals missed the bug and someone with less than a month on the job caught it because he (actually, it was me) didn't assume something operator order of the compiler that everyone else had assumed. I looked up what the order of operations was and found something very non-standard.
I've seen many array bounds bugs, string handling bugs, pointer miss management bugs, RTTC bugs and library bugs. Most common bugs can be avoided by how you write your code, IME.
1) Always set variables to known values at instantiation and when you are completed with them.
2) Always perform tests with the constant on the left side of the comparison operator.
3) Always set pointers to non-allocated memory to NULL before and after use. It is easy to continue using a pointer that happens to work even when it points to a freed memory block. Better to get a null pointer access error during development than for anyone to find it during runtime.
4) Run all code through an indentation tool to correct any user specific styles.
Oh, I've seen rendezvous code fail due to only using a single precision floating point variable in the calculations. The fix was to use double precision floats AND to initialize the variable to ZERO at the end of the calculation, so when another rendezvous 3 body problem calc http://www.scholarpedia.org/article/Three_body_problem was requested, errors didn't add up over time. Actually, this issue was discovered during a flight with many multiple rendezvous guidance calculations. Here's a mention of GN&C issues http://www.spaceref.com/news/viewsr.html?pid=26977 in a NASA release.
Did I mention - I am a rocket scientist.
a) This guy goes at length to explain that software is difficult and the whole world is worse at it than M$; well, I think that's what happens with "professional" folks: they see work as a thing to bear. Meanwhile, FOSS are doing it out of joy. You couldn't stop them even if necessary. No wonder M$ is NOT innovative at all.
b) I'm seeing M$ immitating everyone -- like always -- with one or two added features. Like showing cell phone images over "Google" maps. It's all PR and some guys, whom I had in greater respect, fall for it. Tsk.
c) I tried to post things and wasn't able because of that stupid timelimit (and probably being anonymous). That's a nice thing to prevent people who think fast from posting... Well done!
Yeah, I know, if you don't like here, don't come here...
since there are so many million more 747 hrs logged inside storms like
this, i think you need to have a source that gives an argument why
the airbus was in such a special situation that a 747 could not have
handled it.
the 747 has many things going for it in a situation like this, including
much faster wings.
Evidentally, its actually an attempt at subterfuge. That horrifying serif font that TFA uses is designed to make all of the "open source eyes" bleed simultaneously, thus ensuring his erroneous point becomes true eventually.
Other people have raised points of practicality wrt humans...i.e., that you're going to make things too cumbersome and the like. I'm sure your rebuttal is that that is simply evidence of an imperfect solution to the process problem. The flaw, of course, is that your contention is really only a truism. Humans are involved, and no quantity of process will eliminate all probability of a bug getting through. The only way to know a program is correct is to prove it, mathematically. Not all programs can be proven, so you're limited to writing programs in a style which lends them to proofs. However...even taking those measures isn't really sufficient. Because imperfect humans are still involved. Humans are involved either in doing the proof, or in writing the software that does the proof for you. No matter how many humans you put in that chain of proof, you can not eliminate entirely the probability they all miss something. Given enough time and enough code, eventually a bug will survive, with any process we can put in place.
Mr. Microsoft Program Manager, here's a piece of advice for you: Windows would be a lot more secure and a lot easier and more pleasant to use if you fixed your shallow bugs first. Trust me, there are so many of them, you'll be busy for years to come. Once you have those under control, they talk to us about deep bugs and program correctness and what Linux can do better, OK?
>>> "Given enough eyeballs, all bugs are shallow."... The open source community uses this argument to assert that open source software is more secure than proprietary software.
Shawn Herrnan starts off by making the above premise, then proves his own point by ripping his own premise apart...furthermore his own premise is guilty of massive overgeneralisation and incompleteness.
He's clearly trying to get readers to subconsciously associate that this is the ONLY reason why Linux is more secure than Windows, which is baloney. Linux starts out with a much better security model. From the get-go, UNIX (which Linux is based quite directly on) was intended to be a multi-user system. Windows has been a continual kludge of disjointed evolutionary decisions rooted ultimately in single-user DOS.
For real proof, lets just consider directly the actual relative security records of the software itself. Consider the number of Windows security holes compared to Linux. Or just about Opensurce projects generally, lets just start with IE and Firefox.
Clearly his own initial premise is so faulty so and is the only basis of his whole article so his whole article is invalid. Its actual purpose seems clear.... it is (not even very well done) misdirection to promote FUD in those who are not technically savvy, with the side benefit of allowing him to be seen kissing Microsoft butt in public.
The deepest bug of all is the idea that you can write trustworthy code. Look at how long the integer overflow lurked in the merge sort. Until we get rid of the need to trust code with everything, and build systems that only supply the minimum capabilities required to do a job to a given program, we're not going to have secure computing.
Of course not. It's total BS.
All you need for evidence is the readdir bug that began in BSD and was for around 25 years.
Microsoft Windows is the most unsecured operating system. What do they have to say about security matters...
So if I understand this correctly, Microsoft -- who can't seem to get the bugs shaken out of its products, who can't seem to release anything that doesn't require a security patch in the first few months of its life, who can't seem to stop the buffer overruns and associated "old" problems from crashing their software -- has an opinion of how some other OS is developed, and wants people to believe that the competitors' development model is wrong?
Wow. Just wow. I didn't realize clueless meters could go that high.
Up until recently, Microsoft's code vetting procedures were so bad that in the past, developers snuck in WHOLE GAMES into Excel. How the hell do you miss something like that in a code review? I'm of course assuming that this type of behavior would not be condoned at Microsoft -- maybe it was, and that's part of the problem.
That the company which has *never* shipped an exploit-free version of Internet Explorer has something to say about security.
It's hard not to troll. Honestly, providing constructive criticism is difficult to someone so lacking in prudent judgment. But here goes, in the hopes that someone reading this at Microsoft will actually pay attention:
The society for a thought-free internet welcomes you.
What you say is true. I have done some formal proving and can say that it is not easy. Also, like any endeavour, errors in the proving process can happen. The more complicated the program that you are trying to prove, the more likely that an error will be made somewhere.
This brings to mind a related incident that shows how an error can happen. In the 1800's two mathematicians tried to calculate PI as far as they could. They worked independently and at the end of every day they compared their work. If there was a difference, they would find the error and then continue from that point. This worked very well until they both made the same error. Of course, their work from that point was in error and they had no way of detecting that they were in error. My point is that formal proving is very useful but errors can happen in the formal proof and then the verification of the program is no good.
"Many eyeballs" comes from a coder who thinks even a fraction of his users are also coders. And of that fraction of coders it is quite possible that many of them are shit.
I don't need to see the source of some software to know it's crap when it breaks when used as intended/instructed. This goes for any software.
All the typical user can do is describe the bad behavior. The fact that they have source code (if they downloaded it at all) doesn't help.
You rarely see "moderate versions" of the claim, so he's no more guilty than proponents typically are.
Except for a really simple program, we can not produce "perfect" software and there is provably no way to validate the software is error free. So, we can't know if something is perfect if in fact it is. If it is perfect, we will likely have a % of users that will have perceived "bugs" (user error) as well as possibly a few developers who think it can be perfected further to address the complaints of those users (or imaginary ones or themselves) and soil an otherwise perfect program.
Vast numbers of "bugs" that are really just user error and misunderstanding - which one can subjectively blame on interface design - the perfect program would handle everything thrown at it according to specifications. The specifications would be extremely detailed and also would have to be perfect.
There are 3 sides:
human requirements (flawed; vague; not clear on specs)
human interaction (really flawed; larger group)
implementation "bugs" (most are shallow - come on, we all know programming is mostly debugging.)
Democracy Now! - uncensored, anti-establishment news
I'm sort of agnostic about the whole software choice thing - I use Linux, Mac, and Windows for various things. But the linked article is such self-serving bullshit it's hard to take it seriously.
Fail in the first paragraph. The million monkeys argument is speaking of random output. The many eyeballs argument is speaking of skilled actors. By calling them the same he is implicitly insulting each and every person who does any sort of security review on Free software.
Next point, he wants to reduce the problem to number of hours spent. I would argue that independent security review hours are worth a lot more than hours spent by people who "know how it's supposed to work" for the same reason you should always have someone else proof-read your paper. If you've already drunk the kool-aid, you won't see the flaws.
He is correct that Free software does not tend to get a compartmentalized review. That is, there are few if any who ONLY review code. Instead, developer A reviews developer B's code while understanding the changes so that he can continue to do his work. At some point, developer C will review A and B as he gets up to speed to do what he wants to do. A and B will end up reviewing that work should the patch be submitted. It is certainly a less formal process.
The biggest advantage to the Free software method is that there is no company line. Nobody can demand silence on a security problem that would screw up the release cycle with an empty promise to fix it later. Nobody can slip in an update to fix (or paper over) a horrific undetected flaw in a patch to add a printer driver. Anyone who wants to know about it will know about it.
Interestingly, he sort of touches on that at the end. When DHS decided to have Coventry do a 3rd party audit, there was no need to gain special permission or special access to anything. It was all there ready for them. Here we have proof that the ability of anybody at any time to do whatever analysis they want is not merely theoretical. It happens in the real world.
"The boomers need to retire and pass the baton to a new generation of computists."
Perhaps I can pass this along at the next boomer geek meeting.
Seriously, geeks in my age group have a lot of diversity of opinion and we aren't all thread-happy. As far as retirement goes, I'd Dig it as long as you Cats bring me enough Bread.
As we can all see, this has gone famously for Microsoft.
Ad hominem fallacy. Refute the point, not the person.
In practice, even difficult bugs are usually only second order. Plus disciplined programming using strongly typed languages helps a lot. So one could perhaps claim that "all bugs should be shallow" and that any failure to be shallow wis in fact a tools failure.
The other fly in this ointment is that a lot of bugs happen because of incomplete specifications. Before you can find the bug you have to first recognize that the spec is incomplete. For new code, there may be no person who can recognize that. Of course you can quibble the hard ones in this category away by relabelling them "feature requests" but some of them result from building in constraints that are inessential to solving the problem at hand, and those are really bugs.
Squirrel!
Let's see, the guy builds a tool (Sardonix) to help with code review. Nobody wants to use it. Clearly this means that Open Source enthusiasts aren't willing to do code review. It couldn't be something simpler, like, say, the Sardonix model not working or the tool sucking. It's clearly the fault of the users.
Yeesh, that's the kind of game-winning strategy that'll keep bringing in those DARPA grants (again, I only know what I read in the article; it may well be that the Sardonix folks *did* assume that they needed to change their approach and the author of this piece is just blowing smoke).
I use Drupal to build Web sites. I don't understand it well enough to actually submit bug fixes. But if I do experience a problem, I can view the code directly and try to identify where in the code the error originates. And, other people experiencing the same error can see my bug report, and vice versa.
"Typical" is way too vague a term. There's a huge range of capabilities between clueless noob user and expert coder, and an open source model eases collaboration across that full range.
Build a man a fire, he's warm for one night. Set him on fire, and he's warm for the rest of his life.
Systems are either provably correct or not.
The grandparent is either a subtle troll or an subtle joke. I'm not sure which. There's a third option: he genuinely believes that crap he typed. But that's too terrifying to contemplate.
Comment of the year
The correctness of a system is a boolean attribute. The correctness of software with no specification has no meaning. Most software is an approximation of its specification with lots of holes in it. An implementation's quality (with regards to its resemblance to its specification) is a function of the resources spent on it. I started playing with the excellent proof assistant Isabelle http://www.cl.cam.ac.uk/research/hvg/Isabelle/ before I realized how difficult it was to render even the simplest proof. I no longer write software because existing proof systems are too unwieldy and the impossibility of proving/disproving system behavior using general-purpose languages is just too depressing.
http://edge.technet.com/Media/Interview-with-Mark-Russinovich-the-future-of-Sysinternals-Security-Windows
http://mschnlnine.vo.llnwd.net/d1/edge/2/9/5/1/MarkRussinovichEdge_edge.wmv
Most of the video is basic market hype. But at 27:10
Why not scrap the entire Windows code base and start over?
Russinovich openly freely admit that it's simply too much work!
CONCLUSIONS
1. Vista/7/8 = Forever Unsafe.
2. Microsoft dont even want to try making a safe Windows.
http://mschnlnine.vo.llnwd.net/d1/ch9/9/1/1/5/3/4/RussinovichInsideWindows7_ch9.wmv
Most of the video is basic market hype. But at 41.50
Russinovich explain one of the reasons why Vista/7 will always be bloated.
CONCLUSION
Every Windows will be slower and slower and slower and slower.
Ubuntu 9.10 puts my 4 laptops into/out of Suspend/Hibernate perfectly. Has since 9.04. I have 3-D accelerated Desktop with Cube rotation, glassy effect, wobbily windows, snapping windows, etc, etc. Have had all of that for about 2 years now. Wireless (Wifi) works perfectly. VPN works perfectly. Networking works perfectly, also, CDMA Broadband through Verizon with a USB dongle. I can sleep/suspend/hibernate my laptop at work, come home, open it up, it automatically connects to my home Wi-Fi. I click the VPN and I pick up right where I left off without skipping a beat. I can even sleep/suspend/hibernate, go somewhere without Wifi, plug in my USB Dongle for Verizon, click my VPN button, and still pick up where I left off (though slightly slower). I have 64-Bit Firefox. 64-Bit Epiphany/Webkit with HTML5 video support (including h.264), 64-Bit Flash support, 64-Bit Java support (that I use extensively) for both Java 1.5 and Java 6. JBoss, Glassfish, Eclipse, etc, etc. Lots of highly useful programming languages, compilers, scripting environments, etc. Databases (PostgreSQL, FUCK YEAH!). All with a simple click in Synaptic. It beats Windows HANDS FUCKING DOWN! Anyone who can't get Linux to work for them is a Fuck-Tard! I don't even have to try.
Over-the-top Response Guy! Giving "Over-the-Top Responses" since 1970.
So if MS is so good at testing then why the need for anti-virus and spyware detectors.