Many Eyes, Many Heads

One of the advantages of FLOSS (Free/Libre Open Source Software) is that it’s not created and distributed in the vacuum of a heavily EULAed/binary/closed environment and anyone can examine the code. This has the obvious effects that,

  • programmers know their code will be visible and take care to produce better code,
  • people with more expertise than particular programmers can see how the code works and recommend improvements,
  • end users can also examine the code if they wish to help debug it, and
  • larger numbers of people can tweak the code and test it in parallel making change more rapid.

Still there are people who scoff at these advantages as in this comment on news that some bugs were found in openSSL, an important encryption package in FLOSS:

[sarcasm]
Sorry, but this can’t possibly be true. As many here proclaim, Open Source software has been vetted by “many eyes” and thus is always free of bugs and vulnerabilities
[/sarcasm]

“Many eyes” does not mean FLOSS is perfect but that it can be made more perfect more rapidly and with greater certainty than closed software. “Many eyes” permitted the bugs to be found and corrections proposed. Otherwise, those bugs would have been found eventually by evildoers and we would have been victimized. This is one of the main reasons FLOSS is less targeted by malware. Many more bugs exist in closed software and few are motivated or able to fix them. That’s why the world wastes tens of $billions fighting malware in closed source software. An ounce of prevention is worth a pound of cure and it’s certainly less expensive.

I recommend people use Debian GNU/Linux. It’s FLOSS, the right way to do IT.

About Robert Pogson

I am a retired teacher in Canada. I taught in the subject areas where I have worked for almost forty years: maths, physics, chemistry and computers. I love hunting, fishing, picking berries and mushrooms, too.
This entry was posted in technology. Bookmark the permalink.

60 Responses to Many Eyes, Many Heads

  1. John wrote, “For example updating a program to the latest version, which is supposed to be so easy in Linux”.

    Of course, it’s easy. Look:
    apt-get update;apt-get upgrade
    ...
    Fetched 4,133 kB in 5s (691 kB/s)
    Reading package lists... Done
    Reading package lists... Done
    Building dependency tree
    Reading state information... Done
    The following packages will be upgraded:
    dnsmasq-base ffmpeg gimp gzip libav-tools libavcodec53 libavdevice53 libavfilter2 libavformat53 libavutil51
    libgimp2.0 libphp-simplepie libpostproc52 libssl-dev libssl1.0.0 libswscale2 openssl printer-driver-foo2zjs
    tinymce wdiff
    20 upgraded, 0 newly installed, 0 to remove and 0 not upgraded.
    Need to get 17.1 MB of archives.
    After this operation, 530 kB disk space will be freed.
    Do you want to continue [Y/n]? y

    Isn’t that cool? I can update the OS and all my applications and libraries with a few clicks. I can automate it with a cron job but I like to see what’s happening. I had a lot of updates because I am running beta software, Debian Wheezy. Debian Stable usually has many fewer. My Beast has 2000 packages installed, not just desktop stuff but databases, web servers, virtual machines, language processors, multimedia creators and viewers etc.

    I have only a couple of packages not in Debian’s repository but they are nicely integrated into APT so I don’t care about your objections. With that other OS, I would have to separately update each application not from M$ and worry about licences and authentication codes and re-re-reboots etc. Life is too short to be working for M$ and “partners” for free.

  2. John says:

    Funny blog post. What’s funny about it, is that I’ve spent much less time fighting malware on my Windows box, then I’ve spent typing arcane commands into terminal windows on Linux in order to get it to do something that’s already a solved problem in Windows. For example updating a program to the latest version, which is supposed to be so easy in Linux, but actually isn’t unless you’re prepared to wait for half a year or more until the program in question gets packaged for the distro you’re using (because the Linux folks can’t even manage to be compatible within their own OS).

    The problem with free software, is that you get what you pay for. That’s why >98% of computer users don’t want Linux even if it’s free.

    I’m not saying Linux is a bad idea. But let’s face it, it’s made by geeks for geeks and will thus only be used by geeks.

  3. oldman says:

    “Really oldman you are so use to the excuses you can no longer see them.”

    Assuming that what you say is true, why does that make your excuses any better?

    “Yes a lot of cases what I have todo it dictated by the event at hand oldman. I don’t have personal preference options as much as I would like.”

    You keep shifting the conversation sir. I am not talking about the realities of business. One does what ones customers require. That is why you an obvious linux bigot are also a microsoft VAR.

    I am talking about the reality of what you post, which is the contention that I have to except less excuses with linux. I say again. I do not have to accept any excuses with the software that I personally use right now because

    a) IT DOES WHAT I WANT IT TO DO!!!!

    and

    B) NONE of the linux based desktop solutions DO WHAT I WANT THEM TO DO!!!

    Fran

  4. oiaohm says:

    Cost of doing business oldman that is the funny thing. That is the most common excuse I see for malfunctioning systems.

    Its just a cost of business that windows machines will fail to update. It is just a cost of business that Windows machines will get infected.

    Mostly its a excuse. There the true cost of doing business that is the true cost todo what is required then there is the cost most businesses pay.

    Oldman you have proven that you point of view that places are underfunded. But really its not underfunding completely it also you are not making the most out the funding you are getting either.

    Really oldman you are so use to the excuses you can no longer see them.

    Linux Desktop is getting better at a rate of knots. Systemd and ulatency address both of the worst complaints about the Linux desktop. Performance and slow startup.

    But for thin-clients this stuff was not a issue. Systemd does improve performance of a thin-client server. There are many areas where FOSS wins the business process management in alfresco is great.

    Sharepoint vs Alfresco. Alfresco takes it for what it brings to the business without business requiring todo much effort.

    “I do not try to so heavy duty work on undersized or old hardware.” If I have to I will oldman. No my preference to be in that location. So would you have 200+ workers standing around doing nothing just because you are not prepared to bring the 5 year+ old server back on-line. Of course doing that you have to take require safety measures.

    Yes a lot of cases what I have todo it dictated by the event at hand oldman. I don’t have personal preference options as much as I would like.

  5. oiaohm says:

    I wonder if this fixs it tag filter required.

  6. Dr Loser says:

    Let’s see: this is a FOSS blog (or whatever), and it uses FOSS software on a FOSS stack. And it is mostly, if not entirely, textual.

    Would you care to explain, Robert, the wonders of how this particular thread came to be stuck in italics for the foreseeable future?

    I mean, I think it’s very funny. You, on the other hand, might consider it a small failing thingie.

  7. oldman says:

    “Across everything server desktop…. If running FOSS completely You have to make less excuses why you cannot do things. Yes you might have a case that todo them is harder. But you are not making the excuse they cannot be done most of the time.”

    So in the end all f your great and elaborate technical pronouncements come down to two arguments:

    1) “FOSS sucks less and needs less excuses”
    2) FOSS sucks now but it’s getting better…

    :-()

    ROFLMAO!!!!!

    They’re huge, Mr. oiaohm…
    They’re huge.

  8. oldman says:

    “So you never had to explain that you are out of licenses. 30 years and you never had todo that I don’t kinda believe you.”

    On a personal level, Nope. ON a professional level, I have always been attached with institutions that understand that they have to keep their licensing straight, and who understand that there is a cost of doing business. licenses have not run out.

    Besides the software I am talked about not having to make excuses for is the personal software that I currently use personally at work and at home. in my composing, Finale plus the in memory samplers from garritan, EastWest and VSL meet my composing needs without issue. I have sized my hardware to support that software. I do not try to so heavy duty work on undersized or old hardware. I can just concentrate on composing. No excuses are needed.

  9. oiaohm says:

    oldman look at what Dr Loser and other put up. They are just myths on how FOSS or Linux operates. Does not help debate or anything.

    Windows users and admin I find making excuses like for the wrong audio loaded by windows update it was not the makers driver we will just disable windows from auto updating drivers. Not the fact that the hardware is giving a generic id so OS cannot be sure to load the right driver so leading to defect.

    I make less excuses. If hardware is defective design I will blame it. I will not blame a OS for hardware makers producing defective crap hardware.

    Yes they also blame windows update. What is a incorrect thing todo as well.

    oldman
    “I dont have to make for My Software”
    So you never had to explain that you are out of licenses. 30 years and you never had todo that I don’t kinda believe you.

    Just you have got so use to the excuses you no longer see them as excuses oldman. FOSS is less excuses if you count them all. Why are you use Linux in server roles. As anyone has to truly admit Linux does lots of those roles better.

    Across everything server desktop…. If running FOSS completely You have to make less excuses why you cannot do things. Yes you might have a case that todo them is harder. But you are not making the excuse they cannot be done most of the time.

    About time you pull you head out the sand and start taking note of how many excuses you are making for MS products and hardware makers and everyone else oldman. Basically I don’t believe your statement on not making excuses it not possible to work in IT and not make excuses about something at sometime.

  10. Kozmcrae says:

    Robert Pogson Wrote:
    “Yes, there is. A human being is an error-prone coding machine.”

    I’m not talking about errors alone when I say “better” code. I’m talking better as in doing the same thing with fewer lines of code. I could have said, less clumsy code. Or using Microsoft as an example, not spaghetti code. (http://www.visualcomplexity.com/vc/project_details.cfm?index=392&id=392&domain)

    I love that graphic. One picture can say a 1,000 Blue Screens Of Death.

  11. oldman says:

    “Wait what was I thinking. Without Microsoft you would not have a scape goat so would have to take responsibility for all your screw-ups oldman.”

    You mean like the one that almost got you put in jail Mr. oiaohm? I have to admit that in 30+ yeats in IT I haven’t had the talent to pull that one off 😉

    “The point here is my issues with Windows are not based on Myth oldman.”
    I agree, they are based on informed bias, but whatever.

    “So why should I accept excuse for something that is reality.”

    But you also said:

    “I think you will accept excuses with Linux is that accepting FOSS is accepting less excuses.”

    So less excuses from FOSS/Linux is better than excuses (which I dont have to make for My Software BTW) than from windows.

    DO I have that right?

  12. oiaohm says:

    Also oldman some areas we should be 100 percent unified. Audio devices without unique ID on them to identify them so the right driver gets loaded.

    Windows Linux and OS X users this should all be equally pissed it kicks us in the teeth. Windows users make excuses like the wrong makers driver was loaded. Not that the OS should have never been able to make the mistake if the hardware was designed right.

  13. oiaohm says:

    oldman for the simple fact Windows architecture internally is worse.

    Lot of MS internal architecture is in need of major overhauls. Main reason why I think you will accept excuses with Linux is that accepting FOSS is accepting less excuses.

    Wait what was I thinking. Without Microsoft you would not have a scape goat so would have to take responsibility for all your screw-ups oldman.

    Most of why you guys don’t use Linux based on myths.

    If you don’t talk nonsense what do you have. Audio processing and Image processing Linux is fairly equal.

    ulatency address the performance issue everyone complained about. It was that the Linux kernel was way to fair handing out cpu time.

    Lack of drivers under closer inspection this is not the case. Most hardware makers these days release there drivers open source into upstream Linux. This is why you don’t need to install drivers into Linux for a lot of stuff. There are a few odd balls that don’t release for Linux just like there are a few odd balls that don’t release for Windows.

    Basically only reason I can think up that is anywhere near valid is a dependance on MS Office and other Windows only applications.

    The point here is my issues with Windows are not based on Myth oldman. So why should I accept excuse for something that is reality.

    So far you are not pointing to anything that makes Windows that much better than Linux. Instead you want to point to defects that don’t truly exist.

    I would love to hear defects in Linux that truly exist.

    Real-time on Linux is better than Windows as a audio person this is important. Heck its better on OS X as well. Basically for audio work I would be choosing between OS X or Linux. Windows only if a application gave me no other choice.

  14. oldman says:

    “Linux kernel is becoming quite good architecture.”

    Fine. When it finally gets to being a good architecture, then talk to us. Otherwise spare us all of the “its getting better” excuse making.

    You dont accept excuses where windows is concerned, why do you think that we are going to accept it with Linux and FOSS?

  15. oiaohm says:

    Dr Loser
    “absent even simple things like ABI and API stability”
    Completely not true.

    Let me make a clear point. Linux kernel usermode ABI is stable. Linux internal kernel mode ABI is not. But this is the big but. Usermode ABI is usable in kernel space. Yep can wrap a standard Linux program to appear to the kernel to be kernel module and it will run as long as it obeys a few basic rules that don’t change and have not changed since Linux 2.0 over 15 years ago. Particular registers are off limits that is it.

    The wrapper requirement has not changed in 15 years. The last major upset was the change of kernel memory blocksize. This also effected usermode applications that were build dependent on the block size being fixed. Even that the Linux API documentation clearly stated this could be changed in future. So it was bad coding of the drivers that failed at fault. ie Nvidia drivers went splat. ATI drivers kept on a working.

    So its a flat out lie. If you wanted to make universal Linux drivers that needs just a small wrapper build you can. Linux kernels will not load drivers not built for them these days. This is part secuirty.

    kml patch just removes the need to wrap. It does nothing special that the wrapped application can use the Usermode ABI.

    You can almost create any driver for Linux using the Usermode ABI. Why manage two stable ABI’s when one will do the job. The Usermode ABI is more tested so any gitch hopefully will happen in a userspace program instead of a kernel mode driver so not resulting in a crashed system.

    Remember Linux was the first OS to support Universal Unix drivers that died because no closed source maker would use them. Hand in the cookie jar problem. The closed source driver makers can see the faster internal kernel API. They wish to use this. The internal kernel API on Windows is off limits what the drivers use under windows is the same as using the Linux usermode ABI in kernel space. Then you have the LSB above that.

    ABI and API stability stuff is a complete pack of nonsense. Can you build the kernel to except drivers that were not built for it yes.

    If closed source makers would agree on a tag and release drivers restricted to the Usermode ABI in kernel space Linux could basically have closed source binary drivers in under a year. Of course those drivers are going to sux in performance compare to the in kernel drivers that are using the internal kernel API. Wrapping to produce a stable ABI comes at a cost.

    Before you say this does not exist. Nvidia and ATI binary kernel modules do use the Usermode ABI. So two driver makers have been able to do it. The wrapper is bugger all. Even better Nvidia version of the wrapper is open source.

    DKMS Dynamic Kernel Module Support from dell you driver with wrapper can be placed in a particular directory and when ever the Linux system updates its kernel so does your driver.

    There is nothing in the way of releasing closed source drivers for Linux other than companies lack of will todo so.

    Linux kernel is becoming quite good architecture.

    Dr Loser can you tell me how to solve the hand in cookie jar problem we have with closed source driver makers without slowing the performance of the kernel down. Lot of the closed source drivers want the open source drivers forced to use the same ABI as them.

    Sorry there is no need to force the open source drivers traveling with kernel to play by the same rules. Since those can be secuirty audited and altered when ever a API change happens. I would suspect some Microsoft made drivers for windows get special treatment as well. Linux world is just truthful about it and the closed source driver makes complain about it.

    Simple fact here Dr Loser you don’t know Linux you have heard myths so know nothing.

    Even in the Linux kernel there is serous consideration to push some of the older drivers to the usermode ABI since they are at risk of bitrotting.

    LSB provides a stable user-mode ABI for application development.

    Kid in candy store problem. Closed source developers that get into trouble are the kid who steals lollies from the candy store they should not touch then wonders why they get themselves into trouble.

  16. Kozmcrae wrote, “You can argue that less code does not necessarily mean better code. There is no direct connection that one leads to the other.”

    Yes, there is. A human being is an error-prone coding machine. Even after debugging there will be some rate of erroneous lines per thousand (a small number but definitely not zero). The more lines in the code, the more errors. Some errors may be perfectly harmless and that lack of harm is what causes them not to be found in debugging but others may cause random failures (BSODs etc.) when the right rare combination of circumstances arises and others my be vulnerabilities exposing the system to intrusion or denial of service. Less is definitely better IT. That other OS fills a DVD with crap and it only provides a few applications… The bulk of that is unnecessary code riddled with errors no one wants or needs.

  17. Kozmcrae says:

    “Explain to me the Magic Pixie Dust advantage of producing an OS with a mere 4 million lines of code, please.”

    Doing more with less is always better. There is more duplication in the Windows code, more layers. Less code means faster code and Linux is faster than Windows. That’s one reason it’s the OS of choice for super computers.

    You can argue that less code does not necessarily mean better code. There is no direct connection that one leads to the other. But in the case of Linux, it does. To proclaim otherwise in the state of IT today would be to ignore the obvious.

  18. Dr Loser wrote, “It just never happens, does it?”

    Of course it does. In my own experience, I have several times filed bug reports and usually within a day or so had some useful progress. One time the developer got back to me with a test he wanted me to make and we identified the problem pretty well. In another case the developer showed me that the bug was not a bug but a feature and there was a workaround that should have been simple except on the particular hardware I had. The bug was also not mission-critical.

    With that other OS, I am pretty sure “it never happens”. At least I have never heard of it happening. It can’t really because of the EULA. Users are forbidden to look too closely.

  19. Dr Loser says:

    If only I could turn the italics off. Oh well.

    @Koz:

    Nope, we’re not a tag team. I just recognise Bushwah when I see it. It’s also a jolly good word. But, to your “point”:

    “What would you attribute the svelte opens source code to?”

    Never having considered having enthusiastic and sweaty sex with a bit of source code, I really couldn’t say. There is no obvious reason to aim for “svelte” code that I can imagine.

    However, in this context, the quantity of eyeballs are utterly irrelevant. Is it a good design/architecture, or not?

    If it is, then I really don’t care how many lines of code are required to implement it.

    If it is a home-brew monolithic piece of crap like Linux, and absent even simple things like ABI and API stability, and hopefully a driver environment that is as far outside the kernel as possible (and hence does not interfere with the rest of the kernel), then I still don’t care.

    Explain to me the Magic Pixie Dust advantage of producing an OS with a mere 4 million lines of code, please.

  20. Dr Loser says:

    @Robert:

    OK then. Here’s an experiment you can try at home.

    Pick absolutely any bit of FOSS software. If you want to get serious, look at Bugzilla. Pick a bit you think needs improving (say, supports MP3 or something, although it could be as trivial as adding a help option to the menu).

    Submit that issue.

    Sit back and wait for the many code reviews, not noisy, honestly, to make the relevant patches, documentation (you’re wishing on a cloud here), installations, etc.

    It just never happens, does it?

  21. Phenom wrote, “many code reviews only make noise.”

    Nonsense. They also make patches, documentation, installations etc.

  22. Phenom says:

    Where I come from, there is a saying: many grannies, sickly child.

    The same goes for many code reviewers. As Dr Loser apty put it, many code reviews only make noise.

  23. FBM wrote, “being FOSS doesn’t make a software more reviewed than not being FOSS. “

    From my years of experience of life and statistics I can state there are more good than bad people in the world. Opening the FLOSS to all eyes puts the good people on a level playing-field.

    There are other ways that FLOSS is more reviewed. The best and brightest human beings are not the old guys like me but the youngsters who are hungry to learn. Some of them are programming by the time they are 12. They cannot afford to go to college yet but they can download source code that is relevant to their interests and they will pour over it for hours to learn how it works. They will figure out the logic and test things to death. They are the most sceptical people on Earth. They will not take anything on faith but it must be proven to them. They will find flaws and new ways to use code. They will learn what works and what doesn’t. I was young once. In the old days we could find abandoned printouts of code on chairs and in garbage bins. I had the printout of a lisp compiler for years. I never did “get” lisp but I admired the loops in assembler code. Now, young people can zero in like hawks on code that interests them: the linux kernel, drivers, every kind of app, all neatly catalogued with diffs and changelogs. They can find a programmer they admire and study his work. FLOSS is an amazing ecosystem for those who want to be self-taught. Non-free software hidden away in corporations has nothing like that.

    Anyone who believes paying people to review code is more effective should explain why M$ ships an OS with 50K bugs. They have enough people to assign one bug to each and take care of matters in a few days yet they pay them to mess with competition or twist arms instead.

  24. oiaohm says:

    Dr Loser 40 was a rip old age for Mozart people were lucky to get to 30 in that time frame. Ripe old age changes with time period. In 100 years living to 200 might be require to live to a ripe old age so all of us are dieing young.

    “And somewhere back there, I seem to recall you arguing that all FLOSS needs is a million eyeballs.”

    This still correct because the Million eyeballs causes pressure. Its the pressure from all the people reviewing that causes the QA systems to appear to manage it. When as the QA system starts appearing the means to sort out good and bad people appears. Its a chain effect.

    I have watched this chain effect happen. I have watched Linux kernel, Wine and Reactos all grow from nothing. Watched the pressures build and watched in response the QA systems grow.

    With time and reviewers all FOSS projects will take the same basic structures or die.

    Hard part to get Dr Loser noise is a driving factor.

    I am not kidding on the 15 to 20 years for good QA to appear. This is even true inside commercial software development. Its just not possible to know that you have good QA control methods for that long that you have staff in the right places. Most of the projects for the Linux desktop are fairly young or got abandoned in the Unix world for long enough that the QA systems died.

    Linux world talks of a thing called bit rot where the QA around something starts dieing and the code slowly gets worse and worse. X11 by the time Linux got it was in a bad state of bit rot. Long time ago X11 was revolutionary by the time Linux got it the thing was historic junk.

    Really Linux world has done a great job of performing cpr on what was basically a already dead items. 10 years of cpr down the track you are starting to see the require ecology around FOSS software development coming to life around the key projects. Big thing is when the ecology dies is you lose the coders who know there way around the code base. Repairing the code base becomes many times harder. Like it took an intel developer looking at X11 to learn enough to call the core of the DRI1 X11 server not repairable a few years. Simply it was dead no one knew how it really worked any more other than the fact it was working. That is 2000 to 2003.

    Years before that people had been trying to get rid of X11 without video card maker support because no one knew how the open source X11 worked internally properly. 1990-2000 many project appeared attempt to kill X11.

    Remember without Linux where would a lot of the Unix Desktop be completely dead. Basically long since dead. Core part dead really would have killed anything other than FOSS.

    Backwards compatibility to X11 any replacement has to have too many applications exist that depend on X11 for Linux to walk away from X11. Was 1991-2008.

    Linux is only now getting to the point its developed far enough that it can break out of the corpse that let it have some life on the desktop.

    Really most people complaining about the Linux desktop have no clues to the level of road block that have been defeated to get this far.

    Most of the hard cpr work is complete. Now can move on to doing more than life support in many key areas.

    Noise complaint is a closed source fear. Open source world does not fear it because it understood that the Noise is a driving force. Noise is what makes open source development naturally evolving with QA. Where with closed you have to apply more force to get it to happen. Smaller the development teams and community interacting with the development teams the more pressure management have to apply to get QA.

    Yes small closed source development teams will resist the idea of doing QA because its not fun.

    Small FOSS teams with a huge community of people looking at what they are doing the Noise will force QA to form just to manage the Noise. There using community in FOSS does the roll of management for pressuring QA.

    This is the complete problem the two models closed and open source have a lot in common. The way things happen is different. Including the less modular a program is the more likely you will fail.

    There is big miss understanding how FOSS works. So people start presuming stuff is impossible for FOSS todo.

    Nothing is technically impossible for FOSS todo if there is a big enough community of people wanting it.

    Highly specialized items are an area FOSS will always be weak without some company cracking whip on some developers. More general items like image processing and audio processing FOSS can get strong.

  25. FBM says:

    “Many eyes” permitted the bugs to be found and corrections proposed. Otherwise, those bugs would have been found eventually by evildoers and we would have been victimized.

    Robert, I don’t follow you here. How can you tell that some evildoers didn’t find those bugs before they were found by white hats?

    FOSS doesn’t prevent black hats to find bugs.

    It’s actually easier to find bugs when the source code is available. The consequences depend on whether people who find bugs are white or black hats, period.

    Being FOSS or not doesn’t make people look for bugs in a program. The only reason people will look for bugs is if the program is popular.

    And whether it’s FOSS or not, both black hats and white hats will look for bugs in a popular program.

    Just look at the ZDI: the vast majority of vulnerabilities reported are for closed source, popular software. And they’re always reported by researchers who don’t have access to the source.

    So, being FOSS doesn’t make a software more reviewed than not being FOSS. Period.

  26. Kozmcrae says:

    “I don’t have to accept that hard thing.

    FLOSS does.

    And somewhere back there, I seem to recall you arguing that all FLOSS needs is a million eyeballs.

    Bushwah!”

    Dr. Loser and @ldman are a tag team. When one gets hammered the other one will come in and take the heat. Just FYI you all.

  27. Kozmcrae says:

    “There’s a power series going on here.”

    Sounds a bit esoteric, but okay, whatever.

    Okay, let’s just look at examples. Linux, 13 million lines of code vs Windows Vista (not sure if 7 is more or less), 40 million lines of code. Windows doesn’t do 3 times more than Linux especially when you consider that Linux contains all the drivers including a helping of legacy ones.

    Maybe that has nothing to do with many eyes but with any eyes, as in anybody can see your code so you’re more careful about it. I don’t know but that’s a hell of a lot of difference between open source and proprietary operating systems. Open source is doing something right and many eyes would be a likely factor.

    What would you attribute the svelte opens source code to?

  28. Dr Loser says:

    @oiaohm:

    “Dr Loser the hard thing to accept is how long good QA takes to develop. You can try to short cut it but you have to find that 10 percent quality staff.”

    I don’t have to accept that hard thing.

    FLOSS does.

    And somewhere back there, I seem to recall you arguing that all FLOSS needs is a million eyeballs.

    Bushwah!

  29. Dr Loser says:

    @oiaohm:

    Fair ‘nough, other than the SimpleFact(TM) that Mozart died before he was forty.

    JS Bach was a genius, sui generis. If you want more evidence of this, listen to Berg’s Violin Concerto.

    After that, try Shostakovich’s Cello Concerto, mediated by Mtyslav Rostropovich.

    For fun, try anything at all by Carl Nielsen.

    After that, you can come back to me. We can talk about “fun.”

  30. oiaohm says:

    Proper composition doesn’t involve fun. To be correct there are just as many composes who saw it as fun as the ones that did not.

    Mozart and Bach. Both enjoyed it. Both lived out to a ripe old age. Thank you I will model myself after composers who lived to a old age not those to took there life early. If I cannot have fun doing it I will quit doing it. I know what the result will be.

  31. oiaohm says:

    “Can you show me a single instance where the Many More Eyes failed to “isolate to a suspect?””

    There have been a few cases the IE crash complete computer. It was a chain of events that had to happen in a particular order. This was workable out after the bug disappear.

    There are a lot of intermittent bugs that fall into this camp. The detail to trigger the bug can be the exact combination of software you have installed. This is not been sent up stream in bug reports.

    This level of detail requires to find the bug effectively the source to be in the end users hand and they able to run a local regression test.

    This is also why FOSS projects don’t like accepting large patches.

    “Indeed. And this is a good thing?” Yes the more complex method is looking from more different directions more likely to find a flaw.

    Dr Loser the hard thing to accept is how long good QA takes to develop. You can try to short cut it but you have to find that 10 percent quality staff.

  32. oiaohm says:

    well setup FOSS project. Linux kernel is a major one. KDE have had well setup systems.

    Dr Loser as project grow they get to a point they have to develop systems or the noise will kill them. Automated testing. Bugzilla mailing lists source code management. Old the project the more complete its QA systems are.

    Bugzilla design did not come from no where Dr Loser. Why can you pull ever bug a particular person submitted to it. What is there ways to locate to a particular patch in revision control systems. Why do projects insist on person real names to submit code.

    Nature of open source force quality control on you or progression gets harder and harder.

    Dr Loser
    “FLOSS quality control, if it exists at all, does not deliver the goods. Visibly. As judged by the poor fools who, for the last ten years, have been duped into using something else, more expensive.”
    Really it has deliver goods to the most dominate users over the last 10 years.

    Lot of issue is not a large enough community.

    Issue is also how long does it take quality control systems to grow fully in FOSS about 15 to 20 years. Dr Loser this is why it the older projects that have good QA.

    FOSS has to mature. The OpenBSD one of the oldest has one of the most strict QA processes.

    Next 10 years a lot of the core projects will be going into mature QA systems.

  33. Dr Loser says:

    @oiaohm:

    “Some are reading the patches like I did over the idea to add a third file system notify system and I end up talking to the developer resulting in the patch changed completely. To placing a new notify system under the lot so everything worked proper.”

    That’s where the Nodding Duck comes in, young man. A third one? Gee, a good idea, but have you considered …

    “The testing stage is far more complex in the Linux world than the windows one.”

    Indeed. And this is a good thing?

    “Windows has many more eyes yes but those eyes cannot isolate to a suspect to hunt down for causing there misery.”

    Cannot is something of an absolute, isn’t it?

    Let me cut through the illiteracy and ask you one simple question:

    Can you show me a single instance where the Many More Eyes failed to “isolate to a suspect?”

    If not, what’s all this bitching about?

  34. oiaohm says:

    Dr Loser really all FOSS project have layers.

    Different people trusted to different levels based on there track record. This does control noise.

    Over 90 percent can report a bug and close a bug they reported. Less than 10 percent get the means to close a bug they did not report.

    Not all people are coders. Some are pretty good at sorting out what is a duplicate report even that they cannot fix it. Each skill has it place.

    90 Nodding Duck around 10 real ducks does not stop a proper duck hunter kill the 10 real ducks and leaving the 90 Nodding Ducks untouched.

    This is one of the problems to companies that attempt to setup open source projects they don’t create levels of authorization and sorting. So those 1000 open source coders if 10 percent are good that still gives you 100 compared to 10 your company would have had that might or might not been good.

    Mixture of formal and non formal is what FOSS is using. You also find the old Pragmatic Programming thing happens on patch mailing list were person submits patch and people ask why how and lots of questions the coder might not even considered.

    Linux kernel has noise but not above what it can manage.

  35. Dr Loser says:

    @oiaohm:

    “Systems around well setup FOSS projects exist to find that 10 percent Dr Loser. That 10 percent could come from anywhere.”

    It could, but it doesn’t. Read my heartfelt description of a proper reviewing process again, goddamnit. I’m not saying it can’t apply to FOSS: I’m just saying that I see no evidence of it applying.

    Seriously: Dave Thomas’ concept of a Nodding Duck is far, far more valuable than this Million Eyes nonsense.

    Having said which, and with no expectation of a concise answer that is not surrounded by a wall of pointless text, could you point me to a well setup FOSS project? Or do these things exist merely in your own head?

    “Simple failure to understand why the FOSS support systems are designed the way they are. DR Loser.”

    I accept gleefully the “failure to understand” bit.

    I am entirely unconvinced by the “design” bit.

    Now, are you going to join Robert in his admirably consistent crusade to forget everything he ever learned at college, or are you actually prepared to face the truth for once?

    FLOSS quality control, if it exists at all, does not deliver the goods. Visibly. As judged by the poor fools who, for the last ten years, have been duped into using something else, more expensive.

    And, specifically, is there anything wrong with my thesis that FLOSS would do a whole lot better with a Nodding Duck sort of code review, rather than the low SnR that it currently “achieves” through this stupid and wholly discredited “Bazaar vs Cathedral” nonsense?

  36. Dr Loser says:

    @oiaohm:

    “Really what is the point of being a composer if you cannot have some fun.”

    Off on a tangent, I know, but:

    (1) I hardly think that composing a “Miserere” can be considered “fun.”

    (2) Robert Schumann: Yes, let’s all go for a manic-depressive swim in the Rhine.

    (3) Petr Tchaikovsky: Well, all those sentimental symphonies were a bit of a waste of time. I think I’ll just commit suicide, rather than be accused of an inappropriate relationship with a Russian Prince of the Blood.

    (4) Mahler. Need I say more? OK: Alma Mahler.

    “Fun” don’t enter into it. Proper composition doesn’t involve fun. In the case of Shostakovich, to take another and rather different example, it involves a hideous life-long compromise with reality and fighting The Man just so’s you can get those little ditties out of your head and into the concert hall.

    Now, that’s what I call genius. Not some half-baked and incomprehensible and outdated drivel like X, pace Pog.

  37. oiaohm says:

    Dr Loser
    “Are they in the 10% of “elite” programmers who are — and studies repeatedly show this — about five times as effective as the other 90%? (I’m not. I think I’m in the next decile, but I’m not sure.)”

    There are elite programmers and elite beta testers. If they have access to a svn/git the elite beta testers are fairly straight forward to locate they are the ones that give you the exact patch of the issue repeatedly.

    Self selecting yes. Can you give people different levels of access in FOSS yes. Difference here FOSS people reporting from outside you can see the quality of there workman ship before you are paying them.

    Finding the 10 percent is hard. The more people you can test the more people you will find that is in 10 percent.

    bugzilla and bug reporting system and svn/git systems all have history tracking for a reason. So you can extract the history of each person in the project what they have been doing and the quality or lack there of.

    Systems around well setup FOSS projects exist to find that 10 percent Dr Loser. That 10 percent could come from anywhere.

    Simple failure to understand why the FOSS support systems are designed the way they are. DR Loser.

    Yes same systems are run inside commercial companies to try to weed out bad staff.

  38. Dr Loser says:

    @Koz:

    I appreciate the invective-free response, btw.

    “I still don’t understand how 1,000 coders viewing your code are no better than 10 coders viewing your code. The individual constraints are the same whether it’s you, 10 proprietary coders or 1,000 open source coders.”

    SimpleFact(TM): Noise.

    There’s a power series going on here. “Pair programming” makes some sense to me, but not as practised. There are huge advantages to having even a single (different) pair of eyes focused on your code, preferably a pair of eyes parked next to your own pair of eyes, as it were. (Note that this “parking” business is an immediate weakness of FLOSS, in the general case.)

    For that second pair of eyes, you don’t even necessarily need experience or deep knowledge. The primary advantage of the second pair of eyes is what my old boss, Dave Thomas (he of the Pragmatic Programming movement) rather splendidly called the “nodding duck” approach, after those capillary-action toys of the 1990s.

    What a “nodding duck” does is to sit on the outside and say, “H’mmm … is that really what you were trying to do?” Or “Aaah … I see. Great! But why not …” Or occasionally, “Let’s move on. This is pretty fine stuff.”

    All sorts of useful human interactions occur when you have a Nodding Duck.

    Now add two or three more reviewers on, perhaps, a more formal basis (Microsoft recently introduced an app for this called CodeView or some such thing, which is essentially a workflow system for code review). This will probably yield one or two more interesting bugs and possibly ten or so general observations.

    Now add the rest of your theoretical 10-person IT shop. You might get one useful comment out of them. You will probably get ten or twenty useless and distorted bits of gibberish, because they’re not really concentrating on this thing that you have spent the last month polishing up.

    Now add ten thousand more pairs of eyes.

    See what I mean? Noise.

  39. oiaohm says:

    Clarence Moon the testers don’t just run tests. Lot do read the patches. Git and the package management enable the testers to isolate and remove offending patch or patches. Then report those patches for deeper code review.

    Phoronix is one of the groups who do this with performance issues. Converity runs static Analysis against coder errors again this does isolate down to who added. Different groups hunt different issues. Some are fully auditing the code some are selectively auditing the code.

    Some are reading the patches like I did over the idea to add a third file system notify system and I end up talking to the developer resulting in the patch changed completely. To placing a new notify system under the lot so everything worked proper.

    The testing stage is far more complex in the Linux world than the windows one.

    Windows has many more eyes yes but those eyes cannot isolate to a suspect to hunt down for causing there misery. Bad coders on windows get to hide behind a cloud of protection since the making company has to take the bug report and track down to what code add really stuffed things. That is if from the bug report there is enough detail to locate where the problem started. The closer to the user you can place the bug trace to patch the better you find the fault.

    Yes 20 000 angry people wanting your hide over causing them trouble cause more care than risk of being fired. Because even if you get fired the 20 000 angry people still know who you are. This is what you risk in the FOSS world submitting code the end user might find out that it was you would caused them hell. Worst part is you don’t have a clue what any of that 20 000 people look like so they are a bit hard to avoid. This is why coders who cause a bug more often than not take it very serous to fix it with FOSS projects.

    Closed source the coder gets protected from the mob. Open Source the mob is free to punish them. Yes open source is a double sided sword.

    Who said FOSS is not run like commercial companies. That is how most major FOSS project run Clarence Moon. You have been the one who has been putting up a idea that is somehow run differently. Reality tells you the difference between a FOSS group of coders and a company is bugger all other than the fact the FOSS coders could be under payment from different companies.

    This is the big problem closed source is not magically different. Just the resources have not been focused on particular things.

  40. Dr Loser says:

    @DimiS:

    “As anyone who has worked in open source can attest: there are no sticks or flogging involved.”

    Good to hear, but it isn’t clear that there is any other discipline involved. The (not so theoretical, in a small IT shop) possibility that your company will disappear if you get it wrong is a powerful incentive to do something you really don’t enjoy, like a thorough code review.

    “People do review your code. A lot. And you get more feedback and patches than you can handle.”

    And there we hit the nub of the problem. Are these people selected by a rational criterion? That is, have they a proven track record using the bits and bobs on which the code depends? Are they in the 10% of “elite” programmers who are — and studies repeatedly show this — about five times as effective as the other 90%? (I’m not. I think I’m in the next decile, but I’m not sure.)

    Nope, they’re self-selected because they are noisy. That is not a sensible criterion on which you pick a code reviewer.

    “It is just good business sense to review the code of any package or library before using it in a project.”

    Yes, but (see above) it depends upon the quality of the reviewers.

    “No serious developer should ever use any third party software without having reviewed the code.”

    Utter gibberish.

    Total hogwash.

    Insane.

    Look, this is so self-evidently wrong that I am going to use an example, presumably close to your heart, that disproves it instantly.

    Have you reviewed the current scheduling code in whichever Linux kernel you happen to be using?

  41. oiaohm says:

    Conzo
    “Have you moaned about not being able to see the source of the commercial apps you use?”
    Mostly over the few too many SFZ engines and the horrid opcode mess where you have to be working how what engine a SFZ file requires so you get good sound not a horrid noise from hell. Give the the source code so I can merge them so I don’t have this evil even if had to add extra tagging so the right one is used.

    Also items like the Linuxsampler and fluidsynth allows me to still use older sample collections without using out of date software. That the program to run them are not updated that much.

    Really to me FOSS and Closed source add to each other. If I am working fully closed I find myself missing particular FOSS features. If I am working fully FOSS I find myself missing particular Closed source features.

    My simple point is neither is really that good. If I want to do something strange on stage where a person gets up from the crowd and you get them to basically play air guitar and it really plays. Some people take really convincing that I am not using a backstage person. Note I have not had them put on anything. Or a ghost set of drums/mix table and other fun things. The real air guitar stunt really is a good crowd warmer at times. Of course it will be better when I can super impose a guitar and other items in on the video feed.

    Yes just for fun ones using special marked cards I played song by dealing cards. Yes I love the art of synth and how it control can be twisted in strange and new ways.

    FOSS allows me to have a lot of fun. Closed source is more the boring grind. Yes Linus saying just for fun apply to my FOSS audio usage a lot.

    Really what is the point of being a composer if you cannot have some fun.

    puredata.info is mega fun when combined with other motion capture gear and open source software to drive it. Mix the art of real-time video altering with real-time audio editing with real-time motion capture triggering events and you have a recipe for one hell of a party or one hell of a din if you get it wrong. I am looking forward to blenders means to real-time 3d overlays that is under development. Now that also could get warped when the music changes with face expressions and other strange things. Yes what I want to pull off is the human body as the full controller and otherwise inert object on stage doing stuff.

    I think my goals well exceed yours Conzo. You might call what I do pushing the limits. That is the fun part.

  42. Clarence Moon says:

    Oiaohm Really all your baloney is just what I say about how QA works and makes many eyes just stupid notion. Yes you say developers toe the line for Linus and a couple of others and he is the boss, just like in real company.

    Many eyes testers are not reviewing code like people like to think. Many eyes testers are just users who are finding bugs in the code and saying Linus please fix. If many eyes is making Linux better product then Windows is best product because it has a hundred times many eyes looking.

  43. Conzo says:

    I fail to see what this has to do with my points that _FLOSS_ is not going to come up with something remotely as good as the stuff I mentioned.

    I haven’t been keeping up to date with proprietary audio software running on Linux, due to having no need for it (I don’t run Linux), so my knowledge about what commercial software runs on *nix might very well be outdated, to some extent.

    Have you moaned about not being able to see the source of the commercial apps you use?

    I also fail to see where I discussed print/video (except for the Gimp vs. Photoshop analogy). I never did video, and I’m not a graphics person, so you can tell me anything and I’ll happily believe it.

  44. oiaohm says:

    Conzo remember my linux audio stuff is not just the FOSS stuff. So there is a problem by your statement I cannot exist. I know I exist so someone is telling some huge lie.

    “The pro stuff is all both proprietary and Win and/or Mac only.” This is a straight face lie.

    Lot that are vst interface for Windows in fact work even without wine on Linux.

    I guess never ever used a indamixx.com device so not aware that particular applications closed source do work with the Linux audio stack in fact better on the Linux audio stack then windows or OS X. Indamixx is entry level commercial Linux stuff. If you have never touched one you really cannot comment on Linux.

    NI’s audio interfaces can do all the effects the NI software can but with less computer panic load. Lets basically spend the proper amount of money and do the job proper in hardware. Really do you think I would bother with half assed software when I can have solid hardware do the lifting.

    There is something you are not aware of. Blender 3d integrates into into the Linux audio work-flow. This can get particularly interesting when using puppet controls in blender to control model on screen and audio effects at the same time based on object collision detection.

    This is the thing Linux audio stack connects to a lot broader range of items.

    Gimp is great for web site level work. Conzo.
    But when you are talking against photoshop for print level work the program you should be saying is a gimp relation CinePaint its 32 bit per color channel with full CIE*Lab and CMYK.

    Yes CinePaint is opensource. Guess what there is no Windows version only major defect really. Its OS X and Linux and other Unix like OS’s only.

    Of course for the features with CinePaint is weak to photoshop you have vips and digikam to fill those in.

    Yes digikam and CinePaint are the perfect pair to match up to everything photoshop can do. digikam manages the photos does noise removal and lens correct. CinePaint does everything else photoshop does.

    Vips is commonalty said to be what you would have if excel and photoshop cross breed. Vips can handle image sizes that cause photoshop to die. http://www.vips.ecs.soton.ac.uk yes Vips is one of those odd tools to have in your bag of tricks when a photo or image is damaged in a really strange way.

    CinePaint and vips are full 32 bit floating point color work-flows.

    Compare to gimp 8 bit workflow. Yep no wonder photoshop wins. We want to kick open source so we will vs photoshop against gimp. So we can make fun of opensource. We don’t what to face of against the serous competitors.

    We also want to brush over the fact there are many great high end closed source image editors on Linux as well.

    Yes it pisses me off as well when people compare gimp to photoshop. Lets take the almost worst application for print work and compare it to a print work application of course it will lose. About the only thing worse that is still activelly maintained is tuxpaint but you are not game to say that because you would simply be laugh out of town for daring to compare photoshop to tuxpaint. Yet people somehow avoid being laugh out of town comparing gimp to photoshop??? It really gets me.

    digikam and CinePaint are both designed with printwork in mind.

    Print work is serous-ally one area were there is no reason to use commercial programs other than wanting to waste money or run on windows. Movie industry has seen to that. Movie industry is behind CinePaint.

    Gimp gegl when fully functional will lift digikam even higher. Also bring Gimp up to what is relation CinePaint can do and past. Gimp is a future threat to photoshop. CinePaint is the here and now.

    You have never worked in a 3d movie work flow and it shows. Conzo.

    Yes the common arguments against Linux print work and audio work are mostly bogus by people who don’t know what they are doing or have been listening to people who don’t know what they are doing so use the wrong programs. So have poor results.

    Come lets say I set up something equally bias in the reverse. CinePaint vs Microsoft Photo Editor. Now can I truly claim Linux kicks MS Windows for image work. I really should be able with the crap people like Conzo pull.

  45. Conzo says:

    @Observer: Except that it doesn’t. Wwell, not for my hardware, and even if it did, we can discuss software till the cows come home, but every time I read an article on Linux audio – or try one out in person – it’s light years behind. It’s not even funny. I mean, Audacity, Ardour, QSynth … please, that’s the same hilarity as offering Gimp as a serious alternative for Photoshop with a straight face 😉 The pro stuff is all both proprietary and Win and/or Mac only.

    @oiaohm: Funny that again drivers that (apparently) get it right are written by the manufacturers themselves. I fully agree with you, that you should used what gets the job done – which to the day FLOSS hasn’t been able to do for my needs. Note that you are talking about NI’s audio interfaces, which is cool and all, but I was talking about their software, which afaik has no Linux versions anywhere in the pipeline.

  46. oiaohm says:

    Audio is one area Linux does rock. Reaper is working on a Linux port but it already works great in the wrappers.

    http://www.native-instruments.com/en/support/compatibility/linux/ Nice hardware. Very Linux friendly. Hardware is hardware. Nice bit no drivers required under most of the Linux systems out there for those. Just plug and play in the full sense.

    Linux people will spend good money on good hardware and software. But we are picky. If what you are offering is not that great we are not going to spend.

    Really you are in the business of making music so you should use what ever closed or opensource to get the job done.

    FLOSS vs Closed is not reality. Most FLOSS developers are also closed source developers.

  47. Observer says:

    Conzo wrote:
    “As an aside (I was working on some music the last couple of days), I fail to see how FLOSS is ever going to come up with something even remotely as good as the products from Native Instruments, or Reaper (developed by Cockos, and probably the best bang for the buck I’ve ever encountered in software).”
    ———————————–

    L have a separate install of UbuntuStudio which
    provides a low latency environment for music creation and editing.
    Uses open source software and combined with an Edirol usb audio interface(works out of the box)and has all that you need for recording, creating and editing music.

  48. Clarence Moon says:

    “As anyone who has worked in open source can attest…”

    An insipid try at techno motherhood and apple pie, Mr Dimis. You do not seem to have a grasp on what “code review” means either.

  49. Clarence Moon says:

    “Not me, if it’s in a decent language like Pascal”

    I thought that you claimed to be a techer, Mr. Pogson. I don’t think that you are asked to review much code in that line of work. It may sound like a fun thing to do in that case, but my own experience with software engineers has provided a very different view of the matter.

    They do not use Pascal as a language, though. All of our product stuff is C++ or C#. From what little I remember from my Turbo Pascal/Delphi days when I did product coding, that isn’t going to inspire me to do much code reviewing.

  50. oiaohm says:

    Clarence Moon Really Linus is the last in a long chain of review. Linus himself will be reviewed.

    When a long term stable kernel gets branched. The maintain-ship is transfer from Linus to another maintainer. At that point the quality of Linus work is checked. Linus does have serous reasons to perform because his mistakes will be reviewed.

    Linus is the last because his employment is the Linux foundation he has no boss telling him that he should accept something.

    “Around our shop, there is a serious requirement for exact code review of changes that are being made as we get very close to the release date, and I hear the engineers bitching and moaning in the break room about having to do code reviews. The rest of the year they are developing new stuff and are much happier about it.”

    Linus runs a 3 month pattern. Before the 7 to 14 day merge window opens the code should have had time being tested and basically be bug free. This is why you hear Linus blow into guys. Basically Linus is one of the appointed bosses. If Linus is seeing a bug someone has not done there QA control properly.

    So yes if Linus does not like a patch is instructions are to reject it. This can be that its sent back to QA for another 3 months until the next merge window. Yes Linus does get really peeved when after it been sent back for 3 months it still suspect. After 3 months they should have done enough QA to prove that Linus fears were base-less or confirmed the fears and altered the patch.

    Stephen Rothwell runs the Linux-next tree. Yes a patch can be dropped by Stephen Rothwell before Linus even sees it.

    Then before Stephen Rothwell and the Linux next tree you have the subsystem maintainers. These can also reject patches out right. Under them you have driver maintainers who can also reject patch out right. Then anyone running anyone of the development trees of the maintainers or drivers can submit a bug about your patch seeing it rejected from mainline as well. This is where the many eyes come in. The hidden huge team of testers.

    Getting a patch into mainline Linux kernel is not simple. You can be looking at for a major change over 3 years investment.

    http://kisskb.ellerman.id.au/kisskb/branch/9/ Something people don’t see the automated testing behind the Linux kernel.

    Yes Linus is the big stick that beats them into doing the doing serous reviews. This is why past particular points in the release window you hear Linux blowing into people. Past that point its only fixing bugs not adding more code. His job is basically lead manager and maker sure the processes are followed. That code reviews are happening and untested patches don’t get submitted.

    Yes you hear a lot of developers complaining about having todo code reviews in the Linux world. But its all year long. As soon as they want to take something main line its like bugger we have to review this have testers run it pass test suite. Past static check for bugs. Some are massive explosions like CK over BFS Linus is sitting there wanting some test cases to prove that the item works. So not accepting the patch.

    Please note a single compiler warning is grounds to have your patch rejected from the Linux kernel. Linus most likely will never see a patch like that.

    There is other automated testing suites run against the Linux kernel as well. Any failure is patch rejection until the failure is addressed. If it a test suite error the test suite has to be fixed first.

    There is very limited paths to submit code to the Linux kernel. If you want you patch include you have no option bar to follow the QA processes. “their whimsey and personal muses.” Only exists in working copies of developers in the Linux kernel. Once they want the patch mainline what does become important. whimsy and personal muses go out the window.

    Linux kernel is always searching for new ways to make its QA even harder to get past.

  51. DimiS says:

    > What I think is wrong with the whole idea of many eyes is that you have to beat developers with a stick to get them to seriously review someone else’s code.

    As anyone who has worked in open source can attest: there are no sticks or flogging involved. People do review your code. A lot. And you get more feedback and patches than you can handle.

    It is just good business sense to review the code of any package or library before using it in a project. No serious developer should ever use any third party software without having reviewed the code.

  52. Clarence Moon wrote, “you have to beat developers with a stick to get them to seriously review someone else’s code.”

    Not me, if it’s in a decent language like Pascal.

  53. Clarence Moon says:

    “Linus looks at the submissions and chucks what he doesn’t like.”

    Which makes it pretty much of a one man show, eh? I would think that a few more people have some authority to accept proposed changes than just Linus Torvalds, but perhaps I am wrong.

    What I think is wrong with the whole idea of many eyes is that you have to beat developers with a stick to get them to seriously review someone else’s code. That works if you are paying them some obscene wage and can occasionally demand obesiance, but you are never going to get that to happen amongst people who are just following their whimsey and personal muses.

    Around our shop, there is a serious requirement for exact code review of changes that are being made as we get very close to the release date, and I hear the engineers bitching and moaning in the break room about having to do code reviews. The rest of the year they are developing new stuff and are much happier about it.

    If I were in that mix, I don’t think that I would want a 5 year old looking at my code at all, or even one of the real developers who might be mistaken on occasion for one.

  54. Conzo says:

    Hence the beauty that is the average PHP webapp.

  55. Dr Loser wrote, of coding, “This stuff is really hard, just for one person. It’s even hard for a well-organized small team.

    It’s not remotely possible for a Million Eyes, even if such a thing should exist.”

    OMG and I thought the Linux kernel actually existed. It’s existence would clearly disprove this assertion. The kernel was written by a few dozen people over the web. No well-organized small team ever worked on it. Now thousands currently work on it with about the same archaic system. Linus looks at the submissions and chucks what he doesn’t like. Lather, rinse, and repeat. It’s an absolutely chaotic system but it works because everyone knows that the world can see their code so they do a better job. People don’t write bad code and they don’t beat their wives in public. Kernel.org is one of the busiest sites on the web. That’s a lot of eyes, probably around a million.

  56. Conzo says:

    ^^That’s where experience and aptitude in hiring staff comes in … you know, those people who are paid not to have to pay 1000 eyes and rely on the odds.

    As an aside (I was working on some music the last couple of days), I fail to see how FLOSS is ever going to come up with something even remotely as good as the products from Native Instruments, or Reaper (developed by Cockos, and probably the best bang for the buck I’ve ever encountered in software).

    Both companies are staffed by talented people, who love to do what they’re doing, get paid for doing it, and are highly appreciated by their customers.

    I doubt there’s a single customer who’s ever moaned about not being able to see the source code of Reaktor (competitors aside 🙂 ) …

  57. Amen. When I was a teacher I had one lesson that went something like this: Living things grow, reproduce, consume resources, and produce wastes. Is a fire alive? For high-school kids this can take an hour, discussing all the characteristics of living things. I proposed this to a class of Grade 5 kids and within minutes one observed that living things are firm but soft and a fire is not firm… Essentially, this kid knew cells exist because of what he experienced. I would want that kid looking at my code if it were important that it be done right. There’s no recipe for finding the right kid to look at your code. The odds are better with more kids…

  58. Kozmcrae says:

    “May I be permitted a pertinent observation?”

    That was an interesting observation. No doubt though there will be coders in the open source method that will have powers of observation much better than your own. I still don’t understand how 1,000 coders viewing your code are no better than 10 coders viewing your code. The individual constraints are the same whether it’s you, 10 proprietary coders or 1,000 open source coders.

    If I was coding for a potentially lethal radiation treatment machine I would much rather have 1000 coders reviewing my code than just 10.

  59. Dr Loser says:

    @Robert:

    “it’s not created and distributed in the vacuum of a heavily EULAed/binary/closed environment.”

    Not content with having ignored your university education, and therefore having no clue about statistics, asymptotes, Kilowatt-Hours and the like, you’re now going to tell me that you don’t even understand a vacuum?

    Sorry, Robert, but that’s a piss-poor analogy that probably means the reverse of what you mean.

    So, do tell. How does one distribute anything in a (presumably hard) vacuum?

    I can actually see possibilities for entropy here. It’s not an angle you have yet used.

    I hereby give it to you of my own free will.

  60. Dr Loser says:

    @Robert:

    Thanks for the sarcasm. May I be permitted a pertinent observation? HTML sadly lacks a “pertinent” tag.

    Here is my observation, as a programmer of roughly thirty years:

    I am very lucky if I write a thousand line program (say, in C, for the sake of metrics) on the first of the month, and can come back to it on the first of the next month and remember how and why it does what it does, let alone all those weird little doubts that I had while I was writing it (90% of which are commented, sometimes with a TODO for purposes of grep, sometimes with a more verbose apology for some lapse or other, or more usually a constraint that I didn’t have time to enforce in the code).

    I’m not even talking about cross-platform, cross-GUI or cross-domain programming (with, in this hypothetical example, #ifdefs all over the place).

    This stuff is really hard, just for one person. It’s even hard for a well-organized small team.

    It’s not remotely possible for a Million Eyes, even if such a thing should exist.

    FLOSS is no Silver Bullet for fixing bugs. But let’s assume it were. Show me a professional-standard bug-tracking system used in the world of Free Software that generates better results than the proprietary alternative.

    Go on, just one. And I wouldn’t start with Debian if I were you.

Leave a Reply