Slashdot Mirror
Ask About Proprietary vs. Open Source Code Quality
Scott Trappe is CEO of Reasoning, a company that has gained a certain amount of noteriety (and a Slashdot mention) by running its Ilumna automated inspection service on several versions of TCP/IP -- and concluding that the Linux version has fewer bugs than most proprietary ones. Why is this? Let's ask Scott, and also ask him any other question you can think of about software quality and how to achieve it since, after all, that's his business. We'll send him 10 of the highest-moderated questions and post his answers when we get them back.
What kind of open source code do you prefer? GPL, BSD, or the "here, take it" license?
What is your opinion on this topic? In your experience, does having the source closed make it any harder to find bugs and security flaws?
reference to your research? Whose inclusion of your work most impressed? Most confused? Most disturbed? And was there anyone who referenced your work but totally misunderstood what you were saying/doing and their conclusions were way off?
Would a volunteer house builder make better houses? Would a volunteer Fireman put out fires better than a paid fireman? How about volunteer surgeons? I can see one certain contradiction - volunteer web editors choose mych dumber stories than their paid counter parts!
How can any conclusions about the relative virtues of two development methodologies with a universe in the millions of components be drawn from a single sample, and one as small and atypical as a TCP/IP stack?
Very popular slashdot journal for adul
"Reasoning declined to disclose which operating systems it compared with Linux, but said two of the three general-purpose operating systems were versions of Unix"
So did you go cherry picking to find OS's that had more bugs than linux, or was it random or what?
Too often the Open vs Closed argument turns into linux vs windows, and then criteria is arbitrarily picked. Since the two OS's are designed largely for very different purposes, the comparison is by definition never fair, no matter who conducts it.
Saying that one product is better doesnt necessarily mean that the way it was created is inherently superior.
Implementing properly documented standards is something the OS community is great at, since they're all on the same page. Creating from scratch is different.
Hence, TCP/IP is rock solid in linux, yet development on the desktop crawls along in 100 different directions at once, gaining little ground.
I don't need no instructions to know how to rock!!!!
What is the meaning of life anyway?
It's about doing your best, and doing it without harming others. This is the Open Source way. You collaborate with your "brothers" from all over the planet, all sharing a common goal -- The Destruction of Bad Software, specifically the code written in Redmond, Washington by Microsoft Corporation.
Reply or e-mail; don't vaguely moderate. Ex-O'Reilly/MIT employee, now a full-time Google employee.
Some proprietary products like Microsoft Office partially maintain there dominance by not disclosing the details of the file format, or modifying standard formats to reduce compatability. Do you think that competetive free products would be more widely accepted if the file formats were open/standardized, or would the dominance and familiarity of the current packages would maintain their market control?
That what was all this school was for... to teach us how to solve our own problems. -- janeowit
What is the best piece of code you've seen? What about the worst? Did the best and/or worst come from open source code, or proprietary? I'm just curious.
Ah am not a crook! (\(-__-)/)
Because there are obvious differences in the cultural enviroment of developing open source versus proprietary software, what is you opinion what factors affect the quality of code that is produced from these two enviroments and how?
Memories become legend, Legend fades to myth, and even myth is forgotten by the time that age comes again.-Robert Jordan
OK "Your TCP stack is cleaner than theirs" but what metrics are being used? How do we know bugs in their testing software doesn't skew the numbers?
Trolling is a art,
Don't you understand Open source?
Would it be fair to ask if you are an advocate of any particular type of software, or you merely promote use of the "right tool for the right job"?
Smokey, this is not 'Nam, this is bowling. There are rules.
Is a certain percentage of bugs that result from the interaction of two or more otherwise bug free components?
And the TCP/IP stack that has been re-written from the ground up some 3 times now.
Why didn't you choose to include the BSD stack, code that has been seen and corrected for some 15+ years to better prove your point about open source being better due to all the eyes looking it over?
If open source has such a direct correlation to better quality, why do you feel companies are still keeping their source proprietary? Do you think that we should try and convince them to open source their code in every case, and if so, what do you think needs to happen before they can be convinced to change their minds?
Overrated Moderation: This posts sucks... because.
In my book, quality is broken down as:
50% Stability, efficiency
33% Form, structure
17% Ease of build
Stability and efficiency, of course, is the most important thing. Does the code work? How well does it cover all cases? Does it do it efficiently? Does it make 10 copies of a string just to return a substring?
Form and structure are important too. This is key for maintainability. Is the code broken down unto logical modules? Or is the entire 50000 line code base contained all in one monster if/else function? Does the code itself follow sensible, consistent conventions? Or did the developer purposely obfuscate it to prove how smart he is? Or did the developer hack the whole thing due to a failure to understand the actual problem to be solved? How well documented is the code?
Ease of build - how many #define's (or their analogues in other langs) do I need to get the thing to compile? Does it come with a makefile or build script? Do I need to install a 100MB SDK because the author decided to use 1 small function he could have written himself?
These are the factors by which I use to measure the quality of source.
Do you believe the 'evolutionary' pressures that led the Linux tcp/ip implementation being better are in action in other areas of opens source activity? I can see the tcp/ip implementation getting a lot of attention from coders as linux is primarily a server platform but are less obviously important areas performing similarly?
If so, which areas do you think are benefitting and which need more community action / peer pressure to excel?
Are there any areas you think this phenomenon will never apply? (eg areas in which proprietary code will always be better)
Didn't the TCP/IP code originally come from the FreeBSD project? If so, let's give credit where it is due.
As I recall, the TCP/IP stack was so good that even Microsoft stole it for Windows NT.
Sometimes I think Linux takes more that its fair share of the limelight. Generally when I see some aspect of Linux compared to other OSes, I'm interested in seeing how BSD fares as well. Not so much to decide which is better, but it's interesting to see how the two do against each other, given that they're both open source projects. It seems to me that they both have many different and similar goals, and take different approaches at doing things. I'd like to see how it all adds up.
So did you take a look at the BSD tcp/ip implementation, if so, how did it compare to the rest?
If you didn't, why not?
-kidlinux.
Then will you post the source to your "checker" so that the world can see how you came to this conclusion?
Now your organization could have caught only the most obvious bugs (unless you guys have some special ability that no other programmer on earth has); isn't it possible that these obvious bugs are more easily caught by the many-eyes advantage of open source, while deeper bugs may in fact be better found by the more structured methods of proprietary, closed source software engineering?
The parallelizability of bug-fixing is quite clearly very effective for high-visibility projects such as the linux kernel and apache. However, considering that most open-source projects have only between 1 and 5 developers, how popular do you think a project needs to be for it to significantly benefit from people looking at the source code?
First, it's spelled "notoriety", and not "noteriety". Derives from the word "notorious."
And "notorious" isn't a kind word. Evil people are notorious, nice people aren't.
It sounds like your company focuses on analyzing the code bugs, and not necessarily the perceived bugs. What are your opinions on this? I know that locating and eliminating the bugs *is* a critical part of software QA, but do you feel that bug-free ensures true quality? A bug-free Open Source project may still be too difficult to use or confusing for the non-technically inclined.
My beliefs do not require that you agree with them.
Ironically, the reason most companies will opt for closed source solutions is because they have large companies behind them: Microsoft, Sun, IBM. Although this gives the illusion of having someone to hold responsible, the EULA usually contains a clause relinquishing the vendor of any real responsibility or culpability. Whereas with open source software, you have no legal recourse if the latest release of sendmail or bind has an exploit, but rest assured that within 24 hours a fix will be released. Compare that with response times from commercial closed source vendors...
It is natural to expect the number of bugs to go down when more people look at the source. However the downside to being open source from the security viewpoint is that possibly makes it easier for the bad guys to find bugs. Have you measured the effect of this? Is it actually easier for crackers to find bugs when they have access to the code? If so, do you think the smaller frequency of bugs adequately compensates for their increased exploitability?
The tcp/ip findings were interesting, but were they really relevant. Let's say that one of the tcp/ip stacks that had more "bugs" was Solaris. Now I assume that the Solaris tcp/ip stack has not had significant changes in a very long while, also, that if these "bugs" actually negatively impacted the working of the code, that they would have repaired. So my question is, how does your application mark a bug? And from the original /. article, it would appear that you treated all "bugs" the same. Is a failure to check for a null pointer "a bug". Having a more explicit rundown of the type and scope of bugs found would be much more meaningful.
$$$$exyGal is Eric Krout, aka ekrout. $$$$exyGal is a fan whore. Make $$$$exyGal a FOE today!
It says they found so many bugs per 1,000 lines, but did they submit the errors, or fixes, to CVS, or to the vendor?
Do you find that the quality of the programming depends upon the geographic location of the programmers? So, for instance, an open source program will be troubleshot and combed over by people from potentially a dozen different countries. Closed source software is checked by people where it is written. Since, as a general rule, education varies in quality and areas of emphasis around the world, does it help having people attacking a program from many different angles (i.e., open source, cheked world wide) rather than simply drawing from a set of people who may share many of the same abilities, backgrounds, etc.?
Let's see...
On one hand, we have the source, so security audits are easier than if we did not have the source.
On the other hand, we don't have the source, so security audits are quite difficult.
+1 Totally obvious answer.
--
the strongest word is still the word "free"
Fuckin' A. "You question my kernel? It's the gulag for you, and your children, and your neighbors, and the people who sold you your computer!"
-1 Flamebait? +5 Funny! -1 Offtopic...
Oh, go on, check out my job.
In Apple's latest numbers released in January for its fiscal first quarter of 2003, revenue fell from a year earlier and all of the company's major computer lines saw diminished numbers. PowerMac sales were down 20%, while iBook sales fell 8%.
At the same time Apple's sales were falling, PC sales rose, though just slightly, according to figures from IDC released last month.
The last time Apple was in this state, it brought back co-founder Steve Jobs to fix its issues. He fostered the development of the iMac and secured a US$150-million investment from Microsoft. But there aren't any new iMacs in Apple's future and Microsoft, bolstered by its victory over the U.S. Department of Justice, is clearly not going to help the beleaguered computer maker this time.
So what have you got left? Apple is a company that controls around 3% of the computer market, has recently undergone a restructuring and is slowly fading into nothingness. Software makers don't even have Mac users on their radar and it's not like Apple can bring Mr. Jobs back to right the ship this time -- he's already there.
Stick a fork in 'em -- this Apple is cooked.
Sheesh, evil *and* a jerk. -- Jade
What do you mean by "defect rate"? Is it a measure of bugs your group found for the first time or were you looking at already discovered and documented bugs? In either case how do you ensure that you have enumerated all the defects in the code?
Why did you choose to look at the TCP/IP code over any other particular subsystem? Do you have plans to review any other portions of the code? For instance, I think it would be very interesting to see a similar comparison which examined the code for file systems or virtual memory. Have you reported the bugs you found back to the authors of the code?
I assume some of this information may be "company secrets" but I'm very interested in learning what metrics are used to determine which source code is "buggier" than others. Is this something as simple as running lint + "gcc -Wall -ansi -pedantic" then piping the output to "wc -l" ?
Are there checks for use of unsafe functions like gets and the str* family of functions in C? Are there more complex data flow analysis algorithms at play here like those in the used in Stanford's Meta-level compilation techniques?
Inquiring minds want to know. A pronouncement like OS foo is has more/less bugs than OS bar is meaningless without a definition of what having more/less bugs means.
One of the bigger challenges facing open source projects as compared to their proprietary equivalents is how to manage confidentiality of test cases. With companies such as Red Hat and Ximian involved, it's certainly less of an issue for their core products and projects they over-see, but there will always be cases where there is friction when the best/only person who can fix a particular problem is on the outside, unable to work with the test cases in question.
What are your thoughts on this trade-off between test case management and confidentiality as it relates to proprietary v.s. open source code development?
--The more you know, the less you know.
Please compare and contrast the services your
company offers with those offered by Checker
or Smatch.
They seem pretty similar. In fact, do you
use Checker or Smatch internally? It would
seem logical.
- Dan Kegel (dank@kegel.com)
Since you are a small team rather than the entire open source community, don't your own conclusions imply that you are likely to be detecting only a small fraction of the defects, invalidating the study?
What this company Reasoning does sounds pretty much like what Rational's Purify product does. IMO, all software should be tested with a system like this before going through the QA cycle. I use Purify quite often, just to check that there are no such memory errors.
Follow me
CmdrTaco
John Carmack
hemos
Having worked with both Linux and BSD TCP/IP stacks, and at the kernel level in general (in both, BSD more so), I'd really like to know if he as addressed BSD at all, and if so, how it compares to other free operating systems.
You could've hired me.
If Open Source is defacto more bug free and secure than closed source, why is Red Hat apparently making a profit by offering bug fixes and security updates for a cost, when Microsoft gives their updates away? How can anyone see that and believe OSS has less bugs/security exploits? As a matter of fact, I have received over 20 updates to RedHat 8 this month for security exploits - many apply to other OSS platforms. I have received 3 from Microsoft.
Only thing I can see for sure is that statistics lie and liars use statistics.
People freely donating their time or not, as they see fit, is not communism. Communism is where you have to donate your time. All that needs to be said, the troll has gotten his snack.
Also, you'll be getting a letter and a possible lawsuit for your unlicensed use of "Code or I'll fucking murder you", I believe my company has trademarked that sentence, as well as "Code or I'll rape your dog, castrate your mother, and ram a lampshade up your ass".
PC moderators can suck my White pierced, tattooed dick. If you think pride == hate, s/dick/Aryan meat mallet/g.
last but not least:
least bugs? *grins*
SCO to Hell
How accurate are those bugs/lines of codes? They seem pretty useless without any sort of estimation of variance. How many bugs did you actually file (assuming what you found was actual bugs and not only heuristicly assumed areas of consern)?
Silly peon.
"open source" works because your owner needs something done and may realize that it makes more sense to spend labor on the problem rather than money. There also may be no compelling reason to maintain ownership over the results.
Software is a tool, not fools gold.
Software is valuable for what it can do for people who don't have any interest in selling it.
A Pirate and a Puritan look the same on a balance sheet.
Given that on more than one occasion "independent institutions" which conducted similar studies (and concluded that closed source is superior) were revealed to have been sponsored by the other side, how do you convince other people of your neutrality? Since you are selling a service, not a product, I would guess that the confidence of your customers in your independence is pretty important from a business perspective. How do you win and keep that confidence? The article notes that you agree with ESR's pro open-source reasoning. Wouldn't the perception of your having a OSS bias be something you'd want to avoid?
Every time Microsoft changes a system DLL, they take a chance on break THOUSANDS of other applications because the programmers write code that either exploits or works around known bugs ina given version of the DLL. These same app writers choose not to move to the "latest and greatest" because of the costs involved with changing, documentting and re-testing an entire application.
On the other hand, when an open-source change occurs that affects the kernel in Linux, or a critical and widely used driver, app writers don't have to worry about it because their apps can be changed/documented/changed by the end user.
In open source, bugs are far less prevalant because nobody has to actually commit any dollars to implement bug fixes.
The TCP code in the Linux kernel is probably one of the more studied parts of the kernel. So, it is not safe to assume that fewer defects are present because of source code availability. There are tons of poor quality Open Source software, just like there is tons of poor quality software without source.
Open source works for itself. I don't understand why people think it would rule the world. It's simple an alternative way to code and offer the work done to others.
I agree with : Still, I like the sound of Open Stalin. Can we kill people who decide to reinvent the wheel, to encourage OS developers to pull in the same direction? Stop the holy wars for once and for all..
People just wants to do what they like more.
Complaint mode on The only complain I'd like to make is that opensource developers don't report the development platform where they built their apps.
So often you download something - and the library depends are respected - but the app fails. Just writing: developed with Redhat 7.3, full install would suffice. Complaint mode off
in spite of sounding like a troll i agree with you. the whole open source thing is great while you're living in your folks basement, but once you've got a roof to keep over your head and mouths to feed it becomes a waste of time. i mean if you want to code in your spare time, then fine, use it to start your own company. you can try to right all of the "wrongs" you percieve in the industy. If technically superior code can kill the competition then a programmer (with business sense) at the head of a multinational corp would be a dangerous thing to those run by business men and bean counters.
i wrote a massive library from scratch in C that has been used to build a commercial-grade data transformation product. it is 100% component-oriented, the beginnings of a software assembly line. there have been 3 bugs found in 3 years. my method: i don't tolerate bugs in my code. period. i scour the code over and over, reading it line by line with my finger on the monitor. it's idiotic but man does it work. i dunno if it would work for other people, but this would be the ultimate closed-source environment. of course i'm taking my own advice and founding a company on it.
How much of a role do you think peer review plays in software quality?
In proprietary source systems, there is generally formal peer review, as per CMMI. But I have seen this done rarely (almost exclusively for CMMI level 3+ projects). There seems to be a disincentive to do formal peer review. There seem to be various reasons for this, cost, workplace environment, and group dynamics. Which do you think are most significant?
Whereas in open source projects, there is not the formal peer review, but rather seems like a mass informal peer review. This seems to foster an enviroment of besting each other, trying to find the most and most obscure bugs.
What do you say?
SCO to Hell
Do programming methodologies actually increase code quality, in your opinion?
What I mean is this: over the years there have been numerous methodologies that to some extent all claim to make programmers write better code in less time. eXtreme Programming is a recent and - imho - fairly impressive example. All of them boil down to a slightly different approach to the task of programming.
So if you find fewer programming defects in the Linux IP stack, would you think that this indicates that there is something that works well about the way open-source programmers approach programming? Or could it be simply that people willing to donate their time to a project tend to be talented?
Where can I get the source code to these automated inspection tools?
Is this really just a problem of the resources that can be brought to bear on producing the final product? Does the quality simply come from the shear number of people that plays on the law of averages/big numbers ? ie the open source got 10,000 hours of development time vs 2,000 hours in a closed source environment restricted by cost/budget/time etc. If the resources to producing the "product" were the same would the quality be any different ?
Crap code is crap code, it dosen't matter weither it's open source or not.
In my experience (more years than I'd care to say), it's been my experience proprietary code shops permit people whose skills aren't good (just "good enough" - which is why lots of software sucks) whereas in open source environments, people *know* others are going to see their code and it's a chance to put a special touch on it - they also tend to be better coders. It's like after-hours projects vs. daytime projects. Daytime (or day-job) projects fall into the realm of "don't worry about making it right, just get it to work. we'll fix it later." whereas at night, you take the time to make it right the first time, particularly knowing others *will* see it. And this type of thing is what PHB don't understand.
in a Turkish prison?
If brevity is the soul of wit, then how does one explain Twitter?
In your humble opinion, when dealing with large software vendors whose closed-source TCP/IP stack supposedly has more bugs than an open-source one, could too many cooks at the large vendor be spoiling the broth? In many large places, I notice that "teams" don't talk with one another.
Do you think that Linux, being "benevolent dictator" is a better model than having "teams" make every development decision by committee?
-- I am. Therefore, I think!
Something that interests me is the trend for code quality analysis tools to pick the Linux kernel or other well-known free program as an example. So researchers developing the tool get to boast 'we found 47 bugs in Linux', which is a statistic people can understand (even if it may not always be strictly true), while Linux benefits from some extra bug reports.
Strictly speaking, static analysis tools measure what is called kwalitee, a property which isn't the same as code quality but is usually closely correlated with it. In other words the tools do make mistakes, but most of the time they are on the right track.
It would also be possible to have a big online 'databank' of C source from many projects - the top thousand on Sourceforge plus the GNU programs, or something like that - and make this a standard 'corpus' for code analysis tools.
Hmm, I have to get a question out of this. Do you think that code analysis tools like Splint could improve free software quality further? What sort of infrastructure could be created for doing code kwalitee checks across a whole Linux or BSD distribution?
-- Ed Avis ed@membled.com
What errors are currently hard to detect automatically but which you would really like to be able to find?
What is the next category of errors that you're trying to detect with automatic code inspection?
To give you some ideas, what about:
When comparing implementations of TCP/IP, how did you define what constituted a bug? Was any attempt made to verify whether an actual problem could result? For example, one can read from unitialized memory w/o causing a problem as long as one doesn't then use that value later with the expectation that it is valid.
I have used several source code analysis tools, and they are very valuable for catching defects. However, they also tend to catch a lot of things that are fixes to the code that don't effect the output of the function (e.g. unreachable code, etc.).
Are you willing/able to post the actual details of the bugs found?
...Lesbian hermaphrodite pornographers kidnapped by teenage Nazi heroin addicts who cheat on their husbands, leading to an overweight illegitimate child who is in desperate need of a makeover by a recently outed homosexual who believes in crystal healing, as practiced by aliens, who abduct the teenage Nazi heroin addicts who, in turn, kidnap the lesbian hermaphrodite pornographers.
Does the choice of the implementation language affect the number and/or severity of bugs found? Obviously, the skill of the programmer will affect the quality of the code, but perhaps a study like this can lend credibility to the idea that the choice of a language can predict a certain level of quality in the code. ie, maybe it's easier to write bug free code in some languages. Any data that would suggest this?
Sure, because it's well known that commercial software vendors never fix serious vulnerabilities as fast as the open source community. Particularly ones like Apple, for example, who have fixed several vulnerabilities in MacOS X way before the equivalent Linux patches were released. Since you like sendmail so much, I suggest you check how fast the major commercial *nix vendors released their patches compared to the open source world, and get back to us.
Now please pick up your ill-informed pro-OS FUD and go away.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
In the same vein as the parent, but much more black and white: who paid for the study in question?
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
Were comments an important factor? Which had a better use of comments?
Any Comments?
Someone here has misunderstood open source.
If you think it means that any bug anyone ever sees will get fixed, it's you, though.
If you disagree, post your argument. (-1, Overrated) isn't your personal censorship tool for views you don't like.
What do you think about the new "test first" software development methodology? For those that haven't heard of it, it's a method wherein the test cases for a program are written, and no code is written that doesn't cause a failing test case to pass. All test cases are automated and run after every code change. Would you advocate this in an open-source project? This would mean every contributor would write test cases for each new feature, and add it to a project's common test case repository... What do you think?
Do you think part of the difference in resulting code quality is due to the developers' motivation for working on the project -- that perhaps closed-source programmers are more likely to be doing it just to earn a salary, while open-source programmers are more interested in the art of coding itself?
In a formal setting peer review of code is an expensive process. It takes a team of people, who aren't necessarily experts or have knowledge in the whats or whys the code is exists, to inspect code before reviewing. Management sees this time as empty or lost. Developers who have other deadlines would rather being their work than commenting on other work.
For formal peer review to work it must be scheduled in and implemented with the blessing of management. The surest way to fail at code reviews is to up and one day say that code reviews are mandated but never provide time or the framework to execute.
As mentioned in the parent, Open Source has more informal review structure. Before you implement new features you inspect the code and ask the author questions which can lead to improved and robust designs even without implementing new features. Either the author gets sick of answering questions or seeing comments about their weak design and implements a new one or a newcommer goes ahead and does it. Its a win-win.
I need to critisize myself for my previous comment because I forgot to mention one of the biggest disadvantages - the part that people don't like doing simply isn't done (why are so many manuals crap compared to the software itself?). And of course the development model is different since it's some tweaking here and there all the time whenever something is noticed - this does fit in with the carpenter analogy though. Flaws are discovered through usage and then fixed instead of rigourous testing and quality assurance (ok some software companies forget this though...) and then delivering (as would be the case with a house purchase, to continue my analogy). So even though there are "stable" versions they still quite frequently lack something (ie. the manual might be "please write it").
Karma. Moderation. Is my
It is possible to have a proprietary model and to have code reviews required (and documented) done by competent system architects and security experts. It is also possible for proprietary developers to do no reviews and to lack the skill and experience and coding standards and automation to produce reliable code.
It is possible to have an open source model and have the code reviewed by no one but the original coder. Or to have 15 reviewers of varying competence looking at ever line and debating it vigorously.
It is possible in the same OS to have source files or code fragments from various sources with various development and review methodologies. Some can be as extreme as using/requiring automated tools to find potential errors and requiring skilled reviewers. Some as lax as no review by anybody or anything.
Given this diversity, how can the terms open and proprietary be used to usefully describe software quality? Doesn't it depend not on the open/closed but on the amount of skill of the coder, automation of the review and experience of the reviewers. And isn't that independent of open/proprietary?
What opinion you have about this?
Do you study the makeup and practices of the development team as part of your analysis? Would you find it useful to know if a team favored one lifecycle methodology over another - and are there any correlations you have seen along these lines?
Lodragan Draoidh
The more you explain it, the more I don't understand it. - Mark Twain
Is code aware of its own open/closed source nature? Does this knowledge affect its performance? Does closed source code feel isolated? Is open source code kinda slutty?
The following are closed-source softwares, bug-free up to my knowledge, never crash, intuitive, nice interface, easy-to-install, easy-to-learn, easy-to-use and very nice to work with it:
e c Easy CD Creator
/s/b and a regexp or manually open all files from each sub-dir )
Borland C++ Builder 5.x
Vandyke Secure CRT (Doesn't have term bug) =P
Vandyke Secure FX
EditPlus
CuteFTP
CuteHTML
LViewPro (Much easier than Photoshop)
mIRC
Trillian
WinAmp
WinZip
Adapt
Bitware Fax
Visual ASM
HyperDX
WinICE
EAGLE Layout Editor
Toad for Oracle
What's your list?
Not mentionning all the great games on Windows!
Not mentionning Microsoft 'good' products:
MS Paint
MS Word
MS Excel
MS PowerPoint
MS Age of Empire II
MS Age of Methology
MS Visual C++ when you don't use MFC.
Let me know when those software WILL be as good, user-friendly, bug-free, usable like the one on Windows.
Got to admit KDE is getting there, but not yet.
Every stupid questions turns out like how yea Micro$oft sux, Windows sux, Linux Rulez, OpenOffice is so good and free.
For the *nix bashing part:
gdb is crapt
man pages are crapt
vi sux
emacs better than vi but really sux
nedit is freaking slow
OpenOffice Word, AbiWord don't equivalent MS Word
OpenOffice Calc IS FAR FROM USABLE compare to Excel
The good part:
KDE is pretty good
pico/nano is not bad.
Kate is probably ok.
After a long day of hacking in vi/emacs/pico/nano/gdb on a f*cking term, man you are happy when you get back to home hacking in some nice EditPlus or with MSVC full debugger!
For those who are so good at vi/emacs, how much time does it takes let say to open a GPL/LGPL/BSD source tree with directory, to remove the License
header notice from all files in all subdirectories
(Open all files recursively => easy with CuteHTML, with EditPlus create a project file
with a dir
(select, CTRL-C, CTRL-H, CTRL-V, replace by a token -LICENSE- ), and save it (Save all),
then send it to a line printer (Print all...) then undo the search and replace (CTRL-H...) and save it (Save all).
Tool used: CuteHTML or EditPlus
Good luck! =P
None of my vi/emacs friend where able to do it easilly and as fast as me, but my grandma can do it as fast as me.
Have fun freaks!
- Usability Hacker: Someone who don't waste time with stupid tools without religious faith to get the job done faster, easier and better than any other hacker.
There seems to be a lot of effort in automated testing which goes into trying to determine what the program is supposed to do. An automated tool can never find all of the bugs, since some of them will be that the program doesn't crash or anything, but fails to follow the specification, which isn't given to the automated tool.
How would you extend C/C++ to include information about the intended behavior of programs, so that programmers can tell the tool directly what is supposed to happen?
I would like to move my company towards creating s/w that will operate on Linux, both as a client and as embedded (target) s/w. Our clients are the large primes for militaries around the world.
Most primes and militaries are moving towards COTS products to reduce costs and improve reliability and support. If we were to port our product s/w to run on Linux, how on earth can we achieve similar value and benefits of COTS-like s/w, s/w like WinRiver's Tornado, that have great robustness, standard (purchasable) support, and carry the perception (remember: perception is reality here) of greater security?
For those of you who think support is not important, market data has shown that for larger organizations, the number one "care about" is support. And since Sept 11, security is moving to the top of the list of care abouts for the militaries and primes.
"Content's a bitch."
Please post source for "Ilumna" so I may verify it. If not, shut the fuck! up.
Bug-free software is obviously an ideal goal, but it's not the only thing that measures code quality, in my mind.
Do you forsee any metrics in the (near) future to measure other aspects of code quality? Performance is obviously important, but what about things like code style, modularity, and 'cleanliness?'
"People who do stupid things with hazardous materials often die." -- Jim Davidson on alt.folklore.urban
Nobody knows if it's possible to produce bug free code on a regular basis. (Pretty much everyone is sure it can't be done.) If new techniques change that, then this advantage of open source may no longer exist.
Open source addresses a trust issue. Buying closed source is the same as buying a "pig in a poke". There are many applications where security is a concern. In these cases, bugs are not as much an issue as the validity of the security measures. A method that fails because of a bug is one thing. A method that cannot work because the concept is flawed is quite another. Then there is assurance the producers are not up to anything-- no backdoors, timebombs, DRM portions writing to track 0, etc.
That leaves, as I see it, the original reasons for open^H^H^H^H free source: more people can go in more directions. This gives the world more uses (innovations, novel applications not originally envisioned), and enhancements (more features, faster execution, less use of resources, etc.) than a small group of people could ever hope to produce on their own.
Open source does not equal freedom of use, thanks to all kinds of legalities such as patents. A lot of companies, I feel, posture on this, trumpeting their virtue and vision in being open source while quietly moving to keep control. Source can be open but fair use nevertheless impeded.
More insidious is another idea, not limited to the IT industury. In general, professionals have an interest in having the products they know be used, but some may think the products should not be so easy that their services aren't needed. Whether it is or not, open source can be seen as a threat to the workability of such notions.
When exposed (with prejudice, usually) the first defensive scream is about the business model. To wit, how is money to be made? "Free speech" is effectively "free beer" some assert. With source code, users still need some tools (hardware and a compiler, for instance) and perhaps support or supplementary material to put the source to use. How many times have you bought a game to discover you can't even figure out how to play it until you've bought the separate instruction manual that has been fobbed off as a hint book? Then there are future versions and sequels to be milked. The source may be open, but can be so complicated, so gigantic, that in practice only a handful of people have the necessary familiarity to make changes.
Authors of books and musicians, however, produce "cooked" material, no end-user preparation or support needed. Do not forget editors-- they perform a valuable service when they filter crap, and turn diamonds in the rough into finished products. (Tho of course many are guilty of the opposite, Bowdlerizing and such. Still, I feel the net contribution is positive.) What are they to do? The simple fact is, transferring money is work. Most people don't volunteer to do objectionable work. Taxes are hated as much for the effort required to figure them out as for the direct hit to people's pocketbooks-- everyone feels the forms need not be so complicated. The Internet kills the means by which the publishing industry coaxes the money needed to live, and no other satisfactory way is apparent. Everyone agrees producers deserve compensation. Everyone objects to overbroad impositions that purport to achieve fair compensation and maybe do, but also line a very few pockets. And then is right to be offended when those attempting the impositions then turn around and use those very means they wish to deny to everyone else to save big on their costs while passing none of those savings on. They further compound the offense by making disingenuous arguments such as "cp == mv", that is, copying a CD is the same as stealing a CD from a store, and x CD's copied == x times list price revenue lost, which totally ignores the demand curve. Even the starving artists wheeze rings hollow. Buying a CD from a megastore for charitable reasons is about the same as sending food aid to Africa-- we never know how much if any gets to the hungry mouths. Nobody seems to have a satisfactory answer to all this. Currently, it doesn't make sense to view music and writing the same way as source. But, what if reverse engineering was so good that an executable would be as effective as the source code for studying, thus putting programs in the same boat as books and music?
Lastly, I wonder if there is an embarassment factor at work. Do developers want the world crawling over their crappy hacks with a microscope? Imagine how bad Microsoft would look if they released Windows source and then a bunch of teenage kids independently came up with a simple hack that significantly boosts the performance. Heck, not just how bad M$ would look, but how bad the proprietary source model that is M$'s bread and butter would look. The same thing really can't happen to Linux.
So where's the best place to stand in this spectrum of openess?
Intellectual Property is a monopolistic, selfish, and defective concept. It is "tyranny over the mind of man"
I've seen too many time poor code within Linux software.
You have to think about one thing : evolution.
When your software can't grow, your software is dead before releasing it.
Don't you think a software should be built with a good analyze and a good understanding of clients' needs? How do you make your needs research with a "community" ? Who "drives" most projects?
Of course, we can talk about Apache, Samba and few others, but generally speaking...
Most Linux software do not offer half features from the original one. How do you claim open-source development goes faster than closed-source?
Do not bullshit me on my poor english because you can't answer my questions. Just pass it if it's the case.
This is because, although being open makes it possible to involve many more people, it is not necessarily true that many people will look at your code. Coding is not an easy task, it takes time. In general, many open source projects are maintained by few people, which is actually worse than the commercial applications, since these commercial companies can hire the top people in their area, and they can hire as much as possible if that's needed to compete with any other product, including open source applications. So being "open" does not translate into anything. It is the number of people, their quality, their time to dedicate for the project, not the license of the product.
I am partially open source advocate, and I really appreciate people working for open source. But there are big problems associated with it, and I think instead of trying to cheat people to use open source, we need to focus on the problems of the open source itself. Otherwise it will be a hobby for people, geeks, but nothing more.
In short, can you explain your logic behind this conclusion, because it just seems to me either you or Slashdot is making it up.
If:
Closed Source = smaller audience
and:
Open Source = larger audience
How does this effect:
- focus?
- speed of working
+ quality
- useability
- depth of quality
- how have we furfilled the original goal?
With all this born in mind how does the license agreement fit in? If the license changes how does this effect development?
---
I'm happy for this to be edited but I'm not accountable for the result of course
A blog I run for the wealth
Hi Scott,
:-)
Isn't bad quality actually a case off miss-management or bad communication between developers and management ?
To my opinion it often happens that developers wouldn't agree to release a development, but management decides to release it anyways to make money.
On the other hand, you can develop something perfect but never get finished developing it. Therefore making no money or no success with the product.
Simply said, developing the best thing often doesn't match with sales schedules.
One positive thing about this : It keeps us all in business
regards,
marcel
You should have someone else do the same thing to the code. You're only going to catch logic errors and syntax errors this way. You won't catch errors with your coding style.
What kind of a nitwit compares the "linux desktop" to the TCP/IP stack?!!!
/bin/bash/. or startx
The TCP/IP stack is part of the KERNEL.. Got that you idiot? If someone really WANTED, they could implement a fucking win32 subsystem on linux... THEY COULD IMPLEMENT ANY ENVIRONMENT, Not necessarily Gnu/LINUX.
When I say linux, I mean the fucking kernel - NOT
Besides, who gives a flying fuck about loosers who are trying to get other dimwitted loosers to abandon Linux??
DO you REALLY want all the dcrappy dumbass programmers to code proggies that run on GNU/Linux?
Oh wait... there KDE... nvmd... lol Slower THAN windows.
Slackware all teh way. No bullshit, just GNU/Linux in its purest form.
I'm sorry... BUT LINUX ISN't FUCKING DESIGNED FOR the average (l)user. Its not for Sally Soccermoms and Joe Sixpacks. THe faster you realize it the better.
Number of connections with SPECweb99: 250,000/500,000.
If you read the posting he referenced, you can see the calculations, and how you can get useful work done. It all boils down to transmit buffer usage (mbufs).
Remember that for most HTTP traffic, you have very small requests, and it's the responses that are larger, so the mbuf usage is asymmetric between inbound and outbound data.
The product this was for was a reverse proxy cache, and so if you didn't care about a lot of content, just getting it out fast, you could compromise between connections and cache size, and operate with 500,000 simultaneous client connections.
This was back in the days when there was an mbuf required per connection for the tcp_template structure. The thing that let me push it to 1.6M was I shrunk the size of that from 256b to 64b. But as of FreeBSD 4.5, the structure went away; a FreeBSD 4.5 based port of the same changes could probably gain another 150,000 connections, which would move the number up to 1.75M. The number of useful connections would (based on cache size) moved up to 300,000 (or 600,000) as a result.
Practically, the cache was a special case, because it was possible to share mbuf chains containing cached content between connections.
-- Terry
Ironically, the reason most companies will opt for closed source solutions is because they have large companies behind them: Microsoft, Sun, IBM. Although this gives the illusion of having someone to hold responsible, the EULA usually contains a clause relinquishing the vendor of any real responsibility or culpability.
Aha! Has anyone taken these proprietary software companies to task for their making 'solid' software and then denying their 'solid' software in a EULA that says, 'We won't be responsible for anything!'?
A comment overheard in a corn field `If you have better ideas, lets hear them. I am all ears.'
Think about that.
If Stack A is 3 times as large (bloated code) but has only 2 times the bugs as stack B, then stack A (worse in all respects) gets a better grade!!!
You can halve your defect count by doubling the number of lines of code in your module. What a rip! How could so many people read and write about this and not see the problem.
I18N == Intergalacticization
I wonder if there were marked similarities in the bugs in Proprietary code compared?
Were these similarities found in FOSS code that was looked at, or did the dendritic peer review process handle that to some degree?
Were bugs found in the proprietary code that were already (verifiably) marked as things to be fixed, and if so, what was the average lag time (Bug turn over)? Do these companies keep track of their bug turn over periods, and what is the empirical comparison with that of FOSS?
Was there pro-active debugging done in the FOSS code that were results of known bugs in the proprietary code base, and if so, were these bugs addressed in the proprietary code?
Was there a verifiable process for maintenance in the proprietary companies that had changed in the 3-6 months prior to the testing?
I think that will do for now. Plenty more where that came from. :)
TaranI work on projects in the health and online government fields. In both cases, I encounter skepticism about the quality of free/open source software vs proprietary. I consider this skepticism illogical - because something is hidden doesn't make it more secure, it just means someone has to use a different technique than reading source code to discover flaws.
However, it would be very helpful to the cause of free/open source software to address this perception. How can this be done? Going forward with additional comparisons, for example, a comparison of browsers, web servers, or a package like Zope would seem to be one way.
OpenOffice and other OSS with M$ compatibility . How many commercial apps are a true replacement for Office? StarOffice, a fork of OpenOffice, doesn't count.
We just need a talking penguin that harrasses you while you're trying to work and the market will be ours!
You can't judge a book by the way it wears its hair.
Yes there are volunteer house builders, volunteer fireman(many have given there lives fighting bush fires), and Volunteer Surgeons. They all do very good jobs because they want to make a difference to the lives of the people they help.
However, they also tend to catch a lot of things that are fixes to the code that don't effect the output of the function (e.g. unreachable code, etc.).
I'm your boss. Why did you waste company time writing code that gets compiled, linked and shipped, but never gets used?
Quality is more than just "does it work?"
Before you jump in and define one aspect to code quality, you should consider your list. The least bugs is always a good indicator. The rest appear to be trade offs. For example, if you need speed, you are usually willing to sacrifice size, portability, readability. I have read some very optimized code written for specific hard that made just that trade off. Question is, for a particular application were the trade offs appropriate, and in some cases necessary? The best commented code is a rather nebulus quailty. Furthermore it don't matter how well you comment something, if it's buggy it is well commented crap. You missed usability -- that is, is the software able to used by the intended audience, with the intended training (usually none), in a clear and concise manner.
One thing I have noticed is that when the company/individual programmer uses a program that they develop in the capacity that they intend it to be used, they tend to develop a higher quailty product. Have you observed the same notion? Does this explain why open source tends to be better quailty than closed source?
easier to understand? (and how do you evaluate this)
more compact code? (i.e., fewer LOC)
more evidence of encapsulation and data hiding?
more comments (to better explain what the code is doing)
fewer comments (the code stands on its own)
rigorously standardized naming conventions?
choice of language?
All too often, one man's notion of quality is another's nightmare.