Slashdot Mirror
Open Source == Faster bug fixes
solar writes "SecurityPortal.com is running a comparsion between RedHat, Microsoft, and Sun Microsystems on the response time between software bugs being found and patch releases. Find out if open-source is the champion bug squasher we all believe it to be. " Interesting bit.
I think I'd like to point Slashdot readers to a wonderful book: The UNIX Philosophy by Mike Gancarz. This book explains the tenets and values that traditional UNIX programmers have held. It goes on to list the 9 most primary tenets:
As you probably guessed, Open Source _pushes_ Tenet 6 to the forefront. Let others use your code!
Along with those primary, religiously-followed tenets, 10 lesser tenets are typically followed:
The book also mentions something very important: The Three Systems of Man. Software goes through the First system, the "innovative" cycle where one or only a few develop something revolutionary, to the Second system, where committees are formed for the software so more people can feel they're worth something contributing to the idea, and the Third system, where experts who left the scene during the 2nd stage come back to implement the idea, now that the obvious solution for it is well-known and has been walked many times.
CREDITS: This posting contains lots of quotations from, of course, the book: The UNIX Philosophy by Mike Gancarz, Copyright 1995 Butterworth-Heinemann. ISBN 1-55558-123-4 ... about $19.95
Sometimes I wonder how many closed source bugs have been known before the bulletin/news went public, with the fix withheld until there was a known "problem". Which can make the response time seem really nice if you're just holding onto the bugfix and releasing at the right moment.
I work on a closed source product. I have been involved in a number of the decisions as to whether to release fixes for quite a few bugs. Certainly, releasing fixes as soon as anyone notices would make us look good. Instead, we publish a list of known deficiencies with every release. Most of them are annoying little things that were caught too late in the test cycle to get a fix in. And in most of those cases, we are specifically avoiding churning the release. Of course, by publishing the list of deficiencies, we are not hiding the problems.
I thought the rest of the message was stupid, but that one line made up for it. I thought it was strange that CmdrTaco would post a story with the headline OpenSource == Faster Bug Fixes, but yet won't release the most recent version of the slash code. I thought his interview answer from the other week, in which he says they're working on bugfixes and documentation, was rude and I want to call him on it. He says he's gonna delay 24 hours every time someone complains, and that he doesn't want to release because he doesn't have time to help people compile mod_perl. Rob, with answers like that I seriously question whether you get OpenSource or not. What happened to "Release Early, and Release Often?" and "With enough eyes, all bugs are shallow?" If you're going to be on the advisory board of Linux.com I hope you believe in those statements.
Releasing the Slash code would be the fastest way to fix bugs. The community that has grown up around your site is unparallelled, and I think you'd see some remarkable things come out of it. People are willing to cut Open Source software some slack if a feature sucks. So what if your code is a mess - Mozilla didn't do shit when it was first released, and the SMP support in Linux sucked so hard that I'm suprised that anyone even bothered to stick around and work on it.
Release the source - we get a great system, even if we have to work on it a bit, and you get bug fixes, and new features (I'd be willing to bet that someone is going to add Moderation of stories, and if it works, then hey, you can use it to) That's what makes Free software great,
I would agree, with additional qualifiers.. "anyone with the ability" , time, inclination, NDA free.
I've had several of my posts relegated to flamebait in the past. Even though, if you ask me, they obviously weren't. I've also seen some of my posts moderated down twice as flamebait and then back up as interesting or insiteful... I don't preach about Linux. In fact, I'm pretty critical of the whole Slashdot community. Blah Blah Blah. You have to be careful around here - if you want people to be able to read your posts (not be moderated down) you have to tip toe around certain issues, such as anything partially negative about linux, defending apple, etc...
That's the truth.
How many lines of code do you think are on these 5 SUSE CD's I have? 100 Mill? 200 Mill? 300 Mill!?!?!
So what were you saying again? More code = more bugs? It would seem by your logic Linux is the buggiset OS ever.
Actually, the article went through that. OSS wasn't what took 11 days, Redhat was. Pure OSS dealt with the problem report set on average of half the time that Redhat itself did.
OSS ~6 vs. 11.23 vs. 16.10.
Uh dude, it didn't come out of nowhere, they bought the package "off the shelf."
Moderators, please mark the above post down from 5. It is clearly off-topic and a troll!
Talking of which: If you grep the MSDN for "Linux", you end up with some wonderful flamebait :-)
That's just not true. There are a number of early benchmarks showing it 30% faster. Why do you guys feel the need to lie so much?
Those tasks require as many programmers under Windows. It's just that the hardware vendor has already chosen to do that work for you with Win98 vs. Linux, MacOS or even WinNT.
Mr. Raymond tunnel visioned? He's analyized the times and situations where it's most profitable to be open sourced and those where it's most profitable to be closed source. He often recommneds closed sourcing for particular projects.
I'm sorry, I just don't see the tunnel vision here. Perhaps you should go browse his writtings for a bit to find out what he's actually about?
Oh, wait, do you have Raymond confused with Stallman?
Unless he's distributing binaries, he's under no obligation to release source even under our most 'stringent' OpenSource 'policy', the GPL.
I would be nice if he did but, it wouldn't be hypocritical if he didn't.
Red Hat is generally considered least secure distribution of Linux available
I didn't know that. Could you please supply a pointer to comparative tests or any other information that substantiates this statement ?
See the worlds shittiest website, complete with cartoons for avatars at
http://openverse.org
Hell, call 'em "Service Packs" so the PHB's will understand what you're talking about.
WARNING!
Service Pack©®(TM)$£¥ is the Exclusive Intellectual Property©®(TM)$£¥ Of MicroSoft©®(TM)$£¥ Coporation And Cannot Be Used Without Express Written Consent of Us.
Thank You For Your Cooperation "Duke" Neukom, Attorney MicroSoft CorporationP.S. We're in the process of registering Micro$oft and M$, too, so each time one of you little snots uses it in a post you'll have to pay us a royalty! BWA HA HA HA HA!
Got that right. If I ever get around to making an account, my .sig'll probably be "But I'm sure you zealots will probably moderate me down for saying this..." just to see how fast I can get that default score 2.
Oh really... since when is the Linux file system journaled?
So many people need to understand these tenets! Many people wonder why Unix is so good and then write software that diverges away from this stuff... and then wonder why their software is so buggy.
first time post on slash, so go ahead and make the jokes
;)
As you wish... How dare you invent a new contest? the first post stuff is already bad enough, and now you've started first time post... You should be punished.
what i wanted to know [...] is if corel's linux os is really better than windows
The only way to find out for sure if it's better for you is to try. My personal opinion is "yes, definitely", although I don't really agree with your choice of distributions. Corel Linux looks quite nice, but compared to the others, it's just a bit too buggy and non-standard. You might want to have a look at Red Hat, Mandrake and Debian before making the final decision on which version to try.
You've seen the "getting bugs fixed" argument - other arguments include speed, stability and lower hardware requirements.
What platform is it running on?? Imagine the howls if it was running on a Microsoft platform. Funny how non-microsoft platforms getting slashdotted never gets mentioned on here. :)
Anyone who really needs "foo" might make their own version of "foo". If that someone is not in a good position to economically exploit that product, they just may well release it source and all for others to use.
All OSS 'requires' is that someone with the right interest and expertise tackles the problem. The process may or may not be ultimately slower, however the end result will be a bit more permanent.
follow
Yeah, I saw it above too. I can't afford a second house yet though.
Studies have shown that once Natalie Portman has been convereted into a petrified, open-sourced form, with anyone allowed to freely access and modify her.... heh heh, she's nekkid. And stone. Heh heh.......
SO: what is the world's record for the biggest combination of negative values given out to a single comment???? Inquiring minds want to know......
I spend a good part of each day on this site. It would be great to see how it works behind the scenes. Such a lesson would further my technical expertise better than any link to "foo said linux isn't perfect" ever could.
5 days is a long time for a production system. Assuming that the probability of a successful attack is directly proportional (a bit of a simplification, I admit) to the length of the 'recess' period and that all sysadmins will install patches as soon as they become available (a big stretch, but sysadmin attentiveness is a seperate issue), an MS-based system is around 40% more likely to be compromised during such a period.
I don't understand. Didn't Malda once say he was going to release the source code? Or is he a liar? Maybe he wants to do a rewrite in Python.
........and lick her petrified buttocks.
........and lick her petrified feet.
When I see lists like this, it makes me think that in order to create, develop, and maintain a successful OSS project, you need some big money/big corporations backing you. Can you also supply a list of who funded these projects, total investments to date, whether or not developers got paid. For example, I know that Python grew of of CNRI and still remains there. With the new OSS projects coming along, for example, the Apache XML projects, I don't think it'd be viable without the big guns like Lotus and IBM willing to donate their staff. Or is everyone just playing the game of making simple projects look like they take months to complete and then behind the scenes they're working on the OSS stuff?
I'm afraid your anecdote is worthless for the issue at hand. What's under discussion is the number of security flaws and the speed with which they are repaired. While you and the other Win2K users/testers are in a position to talk about the system's speed and stability, until the system is adopted on a scale similar to NT4's current levels, we can't really judge how it is security-wise.
sh_mmer, you and your professor really disappoint me. I know you don't care, due to your uncaring attitude towards human life as outlined in your argumentation. I wish you could try to be a little more human.
--another person
........and lick her petrified toes.
........and lick her petrified legs.
<yawn> And why is this supposed to be interesting to me? I just want to listen to MP3s and play Quake with sound.
........and lick her petrified arms.
Wow. The guy shows that all our discussion so far is totally moot, and all he gets is a score of *1*? I'dve thought this show-stopper would have gotten a 6. I mean, it renders SecurityPortal's article totally worthless. Geez.
........and lick her petrified breasts.
So how often have you audited the source code of a package you were considering installing on your machine? How often have you actually decided not to install a package based on this audit? How many of the people who trumpet this advantage of open-source actually make use of it?
........and lick her petrified shoulders.
This seems to be in direct contention with your subject.
Are you illiterate? The subject is that open source doesn't always lead to faster bug fixes, not that it never does. Naming a single case where it does lead to faster bug fixes does not contradict this claim.
[...]or was this just a clever way to repeat the tired "open source cannot make money" monologue?
Once again, did you even bother to read what you were responding to? The guy wasn't claiming that open source couldn't make money. He was claiming that some types of software just weren't going to get developed under an OSS model, because they weren't sexy enough to draw volunteer developers.
That's not fucking insightful, that's FUD!
........and lick her petrified ears.
There is no peer review inherent in open source development. OSS makes a higher degree of peer review possible, and it is inherent in highly-active OSS projects like Linux or Apache. But if nobody is interested enough to take the time to review the code, no review happens.
I'm in a hurry, somebody else take it from here.
Wow. That's an impressive list. So which of these programs is a WYSIWYG word processor?
10 minutes after the code is released, Slashdot will be abused worse than a crack-whore at the hands of an angry pimp. Security through obscurity.
My understanding of the issue is that people were mistakenly forgetting about the square:cube ratio when trying to analyze the flight of bumblebees. They found that if a bumblebee were the size of a person, or even a bird, it wouldn't work.
But that's just because as the whole organism gets bigger, the body mass increases by the ^3, while the wing area only increase by the ^2. So for larger organisms, you need _disproportionately_ larger wings.
That's the same reason that all of those charming Renaissance sketches of guys with wooden wings strapped to their arms aren't feasible. For something the size of a human to fly, we'd need a 30-40 foot wingspan, and arms strong enough to flap that.
Win9x is not a fully protected memory operating system (for compatibility reasons, mainly). Linux is. Win2000 is. Comparing Win9x to Linux in terms of memory protection is not an apples to apples comparison.
This has already been posted once, and it's already got a "5" score. There's no need for this second posting.
The URL came back with a 404.. Are they down or is there a mistake in the URL?
Gee and gnome is bug free??? uptime of win2k, 3 months, no reboots, my gnome on the other hand.. well i change a date in its POS linuxconf crap and it crashes/restarts gnome. (RH6.1)
I hate all these people that go, "Windows is sooo buggy" yet grow up dudez, gnome is even more hellish/incomplete and buggy. Even its gnome-help-browser which says accepts http:// doesnt, and fails. Where is RH now with 30 engineers working on gnome 100% of the time, not 2hrs/week.
Ok, and how big is REDHAT? addup all the RPMS onthe CD and count all of its lines of code for each rpm including kernel.... im sure that will approach 40m easily. Windows2000 is more than just the OS, its all the drivers/IE/servers etc... sure it adds up to 40m, but its clearly just 100 little apps in reality.
Kernel by itself is pretty useless
well if u install as root it can happein
You should be used to that around here, every day you see "my Linux system never crashs Win9x always crashs so Linux is rulz". No one here belives any proof that NT or W2K is better than Linux anyway so why not use anecdotes?
It is the buggest OS ever, so what's your point? You saw the article, they have to fix bugs at nearly 3 times the rate that MS/Sun do so Linux must be far buggier.
Since at least Oct 19th 1999, 06:32 http://www.freshmeat.net/appindex/1999/10/19/94032 9133.html You wanker.
but is it open source?
I agree, but it doesn't work that way in real life. Most of the people hear in slashdot seem to want to think that Microsoft is guilting of INTENTIONALLY breaking competitetors applications. In fact they ROUTINELY have to put ugly hacks into the OS to make sure that the top 100 applications continue to work on updated versions of the OS REGARDLESS. The old adage "Dos isn't done 'til lotus won't run" is not only inaccurate (Steve Balmer never said it). I happen to know for a fact that Microsoft had to put hacks into DOS5 & DOS6 to make sure that Lotus DID run despite their bugs and misuse of API's.
Note that these are products with extremely large markets. Many here also require, conform, or gave built standards to be successful.
Products such as MiniVend and OpenCart rely on the fact that those using it are in a completely different market (selling stuff). This is very good application of open source as it isn't really possible to increase market competition through it (Unless you consider a couple hundred dollars in effort or commercial software is a significant barrier to entry).
already
You'd be wrong. But then again, I imagine that you are used to that.
It's been 5 years since win95, and that's still got a sh*t load of bugs in it which will *never* be fixed.
...
Since MS's horde of ravenous attorney's claimed that Win 98 is not an upgrade to Win95, that cannot be considered as a bug fix (besides all the new bugs it introduced and this dang web browser mega-bug I can't turn off).
You know, maybe people are taking the time to inform themselves *before* they attempt to comment.
If Sun GPL'd the fucking Java language I would not have to put up with a million Swing, threading and network IO bugs. Sun, get with the times - give me a language that I can actually use and does not suck memory like a sewer or hang unexpectedly in socket IO. All my problems have associated bug numbers in your bug ho-down or parade or whatever. Either fix the damn things or let the community do it!
Oh my god. There is a lot of propaganda in that post.
Actually, it's even more subtle than you think. When a developer DOES have access
// do usual stuff.
to source for an API. It's true that (s)he can figure out why the API doesn't work
they way they think it should.
Sometimes this is a bug in the API, and they can report a fix and then work with the
fixed code. BUT.. if the API is in some shipping componant that a user may already
have on his or her machine, then you can't be sure if by fixing the bug, you don't
introduce a regression in some OTHER software package that depends on this bug.
(Usually inadvertantly, but also possibly by choice).
Lets say that developer A decides that this bug is something he can work around,
so he writes code that DEPENDS on the bug to work correctly. Then developer B
decides that the right thing to do is to fix the bug and ship the fix.
Now you have a situation where one or the other, but never BOTH packages will
work on a certain user's machine without requiring the user to patch and rebuild
one of the packages.
It has been my experience over the last 20 years of software development, that
the majority of programmers aren't capable of having information about the internal
behavior of an API without making use of that information. Over and over again
I have seen code that COULD have been written clean, instead depend on undocumented
internals of an API and then have to be re-written when the implementation of the API
was changed.
Microsoft has run up against this many times when trying to make Windows 9x compatible
with Win3x. API's that the SHOULD have been able to change or bug fix, had to be left
broken because Adobe, or Lotus or some other developer of a large package had built
an accidental dependancy into their software.
Believe what you like about this, but I'm convinced that if Microsoft were to publish source,
all it would do would be to make it even easier for every lazy or sloppy programmer in the world
to write code that won't work on the next version of Windows. Eventually it would be impossible
for Microsoft to ship a new version because every single change they made would break some
application or other.
A bit off topic, but I'm reminded of a story a friend of mine who worked on Windows95 once told me.
Some 3rd party package was being tested for compatibility with Win95 and it was discovered that
this package occasionally freed memory that was owned by a driver. It turns out that this package
had a bug whereby it would trash its own stack, then GlobalFree() some pseudo-random handle.
It turned out that the value that was erronously passed into GlobalFree() was always the letter 'R'.
Microsoft management decided that this package MUST work with Win95 so the developer went in
an put a test at the top of GlobalFree():
GlobalFree(int handle)
{
if (handle == 'R')
return;
}
This is just one of many THOUSANDS of stupid hacks that Win9x contains for no other reason than
to mantain backward compatiblity with older applications.
In this case we are talking about a bug. But I have other stories about the incredibly heinous hacks
that Adobe did do make ATM work. (They actually patch entry points to some GDI functions, so Microsoft
had to leave the entry points with the EXACT SAME ADDRESSES AND BYTE CODE VALUES).
Mark my words, when Linux has been in use by non-geeks for as long as Windows has, it will have just as
much crud hanging off of it in the name of backward compatibility.
AC's rule.
I went to report a redhat packaging bug in ispell (files aren't installed and rpm's are "empty") and found out someone had already reported it 2 months ago. Still not fixed - should be fixed - involves hacking the *.spec file likely best left to redhat experts. They have billions of dollars now but no time to repackage ispell for international customers I guess ...
My Pentium runs linux and X where I have Netscape, Mozilla, and Emacs running. I admin the FreeBSD server with webmin and do CGI and PHP development with Emacs.
It's served well for years and still does.
My Pentium runs linux and X where I have Netscape, Mozilla, and Emacs running. I admin the FreeBSD server with webmin and do CGI and PHP development on it with Emacs remote file editing features.
It's served well for years and still does.
Ok Malda, you know the score. Put it out there, We Triple Dog Dare You!
it really does. if you're a coder, you are putting your balls on the line. out there raw and naked for the coding world to review and nitpick at.
open sourcing annihilates bugs, increases knowledge and experience to coders, and practically nullifies the opportunity for there to be a trojan embedded in the code.
BUT the downside is that the code is all out in the open and people with black hats may see loopholes and leave it be so they can exploit the fuck out of it and feel ereet.
Isn't it obvious?
uh, dude, they are still fixing bugs in IE. Take a look at the latest set of bug fixes at windowsupdate.com.
% ping securityportal.com
no answer from securityportal.com
The bumblebee problem is simply this:
According to fixed-wing flight models, a bumblebee is far too large and massive with wings which have too little surface area for it to fly.
The problem with this statement is that bumblebees aren't fixed-wing 'aircraft'. They operate under principles more similar to VTOL aircraft.
- Theo
Out dated reference sources lead to continued restatment of errors, recent studies have gained insight as to how bumblebees achieve flight.
Look here.
You are a threat to free speech and must be SILENCED!
What really scares me is that this guy might not have intended this as irony.
A few years ago Cisco was updating the software on AT&T's frame relay switches. When the first switch was upgraded, it caused a cascade failure breaking every other switch on the network, taking down AT&T's entire frame relay network for several days. It turned out that the software on the frame relay switches contained a bug that Cisco had known about for a long time but had decided that the chance that the bug could cause a failure was low enough that it didn't warrant fixing.
ah!!!!! it's the borg!!!!!!
It's also much slower than 9x, I'll leave out Linux because that would be embarrasing for Microsoft...
the developers write bad software. Although E.R. and company will dispute this, open software != good software. No matter how many people are working on it, if they are bad programmers or follow bad design principles, bugs and problems will continue to appear.
Consider this, although millions of people can look at open source software, there are usually a small group of people who are doing nearly all the actual development. In closed software, there is a small group working also.
The ONLY benefit open source software gets is the off-chance that a programming guru happens to have absolutely nothing to do that day and fixes the bug before the core developers get to it. And if components aren't separated well, he is just as likely to mess something up as fix the problem.
I acknolwedge there is a small benefit to open source software. My point is that if the software is good and the designers are good, bugs will get fixed just as quickly either way.
Remember, though, that Red Hat makes their money servicing and supporting their product. So the more bugs that they give away for free, the more money they make.
There's a tricky forumla that balances out the credibility of the company against the profitability of the company's main cash cow (fixing bugs in the product.) It's still being fine tuned, of course, so the ratio of acceptable bugs is still being determined by market researchers.
I always laugh my ass off when CmdrClosedSource posts something about open source - at least the article could be anything else than dead boring.
Free Slash !
You can turn Netscape off. Simple as that.
MS coders have a legitimate excuse - millions (billions?) of lines of code. What's *slashdot's* excuse?
I dunno... Linux is really, really, really slow at a lot of multimedia tasks. Things that just require you to pop in a CD and install the app with Windows, require you to hire a whole team of programmers in Linux.
And Linux is taking forever to find my USB speakers.
that are inherent in an html/perl combination. When is he going to move to nntp already?
they say that when you doubble the lines of code, you may quadruple the number of bugs. not promising for M$ if you ask me... (perhaps they stole source from the linux kernel and modified it 20% to get arround the GPL ) If not, they should, NT would be muxh more stable ;)
uhhh, news flash for you ... Natalie Portman isn't THAT hot.
Nope, Eric Allman is the 'queen' bee.
Ouch, did I really say that?
Not to argue with every statement but as for successes, you only have to look as far as webservers. Apache still holds the majority. (See http://www.netcraft.com/survey/)
Prove it. Where is your site or study showing that it's slower than 9x? Put up or shut up.
You moderators really have to get your heads out of your asses. Is it a flamebait or a troll? IF it is both, don't I get some kind of extra pointage for stating the obvious, that this guy's website sux and I'm gonna crack that bastard and spew MY inane verbiage all over HIS little cabbage patch like he does /.??? good greif. "The flaming troller"
I reboot my W2K system when the power goes out, otherwise it has longer uptimes than the Linux box under the desk next to it.
You need to evaluate it for yourself to determine if Corel Linux is right for your use. Linux is more stable than Windows and runs better on less expensive hardware and can be had for free or for purchase. Examine the licensing on Corel's Linux carefully. You will be able to buy one copy of the base OS and load it on all of your giveaway hardware for free. However, there may be add-ons that must be individually purchased (especially Corel's office package). You can run many Windows applications under Wine. Though it is not complete, it is advancing quickly. You really need to download Corel Linux and give it a try.
It really has been an un acceptably (by in-use open source *standards*) long time since the source was released.
Maybe Andover.net has him in a contract which binds him from releasing due to the perceived threat of competition?
He has said he *will* release it. It's just been a f*cking long time since he first last said he would.
OpenVerse looks cool too, but that's a separate topic.
If CmdrTaco did release the latest source, mayhaps we could fix all these pesky bugs, too. Someday... sigh.
I would love to use Linux in a different manor than I use Windows in.
Yet Another Site Slashdotted
:(
I can't get to this site
Be insightful. If you can't be insightful, be informative.
If you can't be informative, use my name
Ok, ok all yeah first time post on slash, so go ahead and make the jokes..:-) Anyways, by no means am i a 'puter geek...I'm worse.. i'm a econ geek that is starting a comp. what i wanted to know from ya'll "gods of bytes" is if corel's linux os is really better than windows, and if when corels office suite might be launched. Reason? well if it as good as window's and it is less expensive than "uncle billies" then i just might use it on the systems we will be giving away. Also, is there any "conversion" programs that allow a window prog run on linux? that's it mike lawson ceo/pres 2kwel.com
You've pushed us back another 72hrs with your ranting. Oh the inhumanity! We'll never see the source if people like you keep speaking their minds ;-).
Using a one-way ANOVA (or a t-test) at even 0.05% significance, the difference in the means between Microsoft's response time and Linux's response time is far below the threshold for statistical significance. In other words, there is a fair probability that Microsoft is has as good or better response than Linux. The results show a statistically insignificant difference.
Statistics lesson #1: if a site does a comparison with just a few samples or without providing variances and t-test results, chances are high that their "results" aren't results at all.
Also, it doesn't help that with their popularity, Microsoft draws the fire of every scriptkiddie, security wannabe, etc, who all want to be the first to find a new bug and either exploit it or publish the fix.
::$DATA hack, ActiveX. It's completely non-standard and very unsecure. Don't you think MSFT could have at least designed their products with security in mind? ActiveX is horrible, they designed it with no real security feature in mind. Sure Access and IE integrate well with eachother but at what price? Also, look at PPTP, it's a sham my friend.
Yes that is a factor but an even bigger factor is Microsoft's inability to secure their products. Look at Melissa, the stupid
Slashdot is a complete waste because the comments near the top always get more pageviews as it were.
The system really needs to randomize the posts (and their responses) so everyone gets a fair view. I mean, after a page or two of comments who reads it?
If you read this and agree, and you are a moderator, push me up a point. Perhaps the folks at Slashdot will get a clue and change their system.
I signed in as Anonymous becuase I did not want to increase my "Karma" if I get moderated up.
I would expect OSS would do a lot better than 11.23 vs 16.10 days. Considering the number of products MS has to maintain, the time differential is not that significant. I use Linux, by the way..
In reality, scientists didn't know how bumblebees fly until recently. This is very different from concluding that they can't.
was this just a clever way to repeat the tired "open source cannot make money" monologue?
nah, it wasn't clever at all.
Well, what about the possibility of a very clever open-source developer actually adding a subtle security vulnerability intentionally while helping out on a feature or two of linux?
Yup, that's happened too. Believe it was TCP wrappers that had a backdoor that sent uid, or gid, or similiar, + hostname/ip to a hotmail account... was found on a cracked server, so not exactly the same as you say, but I think it proves the source audit deal, at least for some programs.
Memory is a little foggy on this one, anyone have a better description than I?
bash: ispell: command not found
This sig left intentionally blank.
Open source, closed source... Blah!
Isn't it up to people and their skills and abilities to be able to fix (properly!) bugs?
The issue is not the difference in programmers, it's the effect open/closedness has on development. I have no doubt that M$ engineers working on an open source project could fix bugs quite quickly. On the other hand, there's a whole lot more closed-source software produced for public consumption (take games, for example.)
Open source has several advantages. Releases can be early and often, there's little financial incentive to group feature enhancement into a single upgrade. Users who are experiencing the problem may come up with the fix themselves, as opposed to closed-sourcers who may not even have the hardware/software setup that causes problems. Open source programs usually try to do a limited set of things and do it well, so the problems are usually more localized. Programming tends to be a meritocracy, not orders from on-high, so better designs tend to take prominence, especially since the cost of switching to a better version is lower and there's no file-format lock-in and the like. Source code is the most accurate documentation, so working with available source libraries is better than closed ones.
Against all this, closed source has the huge advantage of a reasonable expectation of earnings, and thus programmers working on the code full-time or more.
It's an interesting battle. Right now I'd give closed source the upper hand, but open source is making a major play...
Ooh, a sarcasm detector. Oh, that's a real useful invention.
You want the speed when it comes to security fixes, all that regression testing is not going to help you a whole lot if someone else now has root/admin on your box.
That is why Glint (which was the graphical pagkage manager software people used to use to install RPM packages, including updates and bugfixes) was broken on the Red Hat 5.0 CD-ROMs, right?
:)
If you had to dig back to 5.0 to find an example of poor QA, I'd say they're doing pretty well.
Also, security fixes are just a little bit more important than a touchy feely GUI on top of a touchy feely package installer... so I'd imagine that they put more effort into that.
(Although I don't know what was broken about Glint - it didn't format your drives, did it?)
----
I think that its just that when BigCom releases a fix they usually do it with one big shebang, vs. Open source its available as soon as the author decides to publish it.
They made it easy on MSFT. Windows systems tend to run more 3rd party software, in which Microsoft would not be expected to fix bugs. Whereas RedHat packages and distributes as many open source programs as it can. The comparison would have been fairer if they had included bugs in popular Windows programs from companies other than Microsoft (as well as stuff like Oracle for Linux, which would not be as much).
Also, they could consider that Debian systems can be configured to apply fixes automatically through cron and apt-get.
If the comparison is Red Hat versus Microsoft security, you're right. But the tone of the article suggests that they are comparing open source versus closed source, and the fact that open source systems tend to use software from one distributor is relevant.
I won't call it a success until it actually puts a dent in Microsoft's huge majority.
Eh, I hope you aren't measuring quality by comparing market share? Or do you think McDonalds taste better than a restaurant rated in the Guide Michelin (since there are so many McDs and so few star-awarded restaurants)?
Personally, I couldn't care less for market share - as long as it does its job in a stable, efficient manner, I'll use it.
I don't think that there are any hugely successful pieces of open source software (sendmail? but then it basically started off with a monopoly)
fetchmail, the gcc, gzip, lynx, emacs and a slew of the other GNU tools... I fear the number of installed emacses out there! These are programs that do their job well - some are even popular among typical "users".
I don't work for free, I have to pay bills. Infact, I'm quite happy to be paid a lot of money for what I do.
I bet the programmers at, for instance, RedHat are happy getting paid, too. Many a healthy business gain most/all of their income by offering support (Linux distributors), add-ons (Sendmail Pro), courses and documentation to open-source software.
Well, Linux seldom just hangs the way Win9x does due to an error in an application. You can say what you want about reliability - recoverability is where Linux truly triumphs.
Wouldn't the introduction of new code cancel the effect of the bugfixes? Code maturity, anyone?
Well.. probably the Open Sources community reflects quicker response to bugs, but it can lost its direction. Look at the The XFree86 X server and its window managers or desktop managers. The behaviour or the response of the UI is not as good as that of Mac OS or Windows. But there is no Window Managers. etc to solve the problem. And there are lots of people to make different patches, different version. Well, diversity in nature is good, and probably it would be good in computer industry. But don't you think that there should be some agreement among people, at least? How about the Mozilla? When could it be released? I changed my browser to the IE5.01. At least the IE 5.01 doesn't reload html files when I resize the windows. With mozilla, it's possible. But the whole mozilla is not ready yet. I think all things has its own strength and weakness. We should maintain balanced view on them.
no worries, most people get this wrong. industry is like that.
Windows File Protection - Who cares if it breaks installs of tons of applications?
... wait, don't bother.
;)
Driver certification - Safe as long as you ONLY load drivers you trust. Oooooo.
Full 32-bit OS - Better late than never
Windows logo program - Pay MS money, get stickers.
Dramaticall Reduced Reboot Scenarios - Or so the theory goes.
I could go on and on and on. But essentially Win2000 is the OS of yesterday, here today!
Mod this up or ELSE!
Bad Mojo
Bad Mojo
"If you can't win by reason, go for volume." -- Calvin
My new monkey has less ticks and fleas than my old monkey. I havn't had the new monkey as long as the old monkey, but it SEEMS to be much less flea and tick ridden. My new monkey also has no fur, which the pet shop owner said was a feature and not a mistake. He sure is ugly. Oh well, at least he has less fleas and ticks, right?
;)
The moral of this response? Monkeys post responses that are full of wht SEEMS to be FUD. That and "Monkey hate clean!"
Bad Mojo
Bad Mojo
"If you can't win by reason, go for volume." -- Calvin
As per your request, hugely successful pieces of Open Source software, one list of:
...
For what definition of success? There is no question that these are all widely used pieces of software... then again, so are Windows 95 and DOS. You could also argue that they are "successful" because they function as intended (ie, they're non-trivially useful).
By other criteria - profit made from sale of software, or from sale of support for the software - there has never been an open source project that even approaches the success of the larger closed-source software releases. In time, perhaps, but not yet.
"Great men are not always wise: neither do the aged understand judgement." Job 32:9
I'm looking at that graph and I don't see that indication yet. I also don't see anything that would leade me to believe that IIS would suddenly become more favorable over Apache. IIS is developed much slower, bugs and security holes are fixed slower (if at all) and the underlying OS it is forced to run over has it's own share of problems. Apache on the other hand perfectly demostrates how open source can (perhaps not always) provide a much faster devlopment model, with quicker turnaround on bugs and security proglems. Combine that with the many operating systems it supports and you've got a server that I think will probably wipe IIS off the map in a several years. The only thing IIS has is a GUI for dummies. Now that is great for end users, but if your web server admin needs graphics and buttons, then he just might not be trained enough in server configurations.
NT cam be stable, you just really have to know what you are doing to make it that way. I've seen time and again MSCE's set up a system with all the defaults enabled and watch it crash like Ted Kennedy on a bridge.
BTW: I use Slackware too
Bill Gates: "Innovation"
I'm not jumping on board in defending W2K or anything, but in your saying that you haven't used it since RC2, you're also saying you haven't used the most current builds. RC2 was pulled back and replaced with RC3... And then they went gold with it. Lot's of things could have changed... Maybe not much in terms of API's at that late point in development, but bug fixes... Microsoft went through a huge public beta process and i have to believe that a significant percentage of testers did indeed report their bugs back to Microsoft.
Just as when people say bad about Mozilla, they're reminded that it's barely alpha. What everyone to date (not under an NDA) has seen has been beta. For all the slipups in terms of security, privacy, and reliablity, you have to think that Microsoft did indeed realize that if their new OS was even half as bad as NT4 they'ed take a beating in the press and from the users.
I won't be first in line to buy Win2000 when it arrives but I will buy it as soon as i've got an extra computer for it to live on. And I definetly think this is Microsofts last real stand in terms of can they lead the market or forever follow...
Actually very often as I enjoy security as a hobby. Why do you depend soley on vendors for security?
Microsoft aggravates my tourettes syndrome.
You would have to be very crafty to trick the eyes of all those who scour source code for holes.
Microsoft aggravates my tourettes syndrome.
Windows 2000 has LESS bugs than its predecessors. I run Win2K, and I have yet to have problems. True, I haven't run this as long as I had run Win NT or 95 or 98, but this seems to be *much* better.
I did not intend that. Unfortunately I can't find the numbers, but I meant "Win2K has less bugs AND I have less problems."
Apologies.
Reread what I wrote. I said that I didn't conclude it had less bugs because I didn't find a bug...
I'll probably get flamed and moderated down for this (there seems to be a rather vocal fundamentalist open source community here on /.)
Okay, is there any basis for this? Please, can somebody point out an example, any example, where someone was moderated down simply for expressing an unpopular opinion? For expressing an unpopular opinion in a rude, off-topic, or incomprehensible way, maybe. More often, however, posts like this seem to get moderated up, possibly because someone is determined to show how open-minded they are.
On the other hand, I've been tempted to make "I'm gonna get moderated down" posts self-fulfilling. Haven't yet.
Weblogging Considered Harmful:
I'd mod you up :)
It dose seem like the most.. creative abuse of moderation I've seen...
I'm in compleate agreement with you...
I don't actually exist.
An example of this...
I compiled a biff [e-mail monitoring program to inform me I had new e-mail] it had a defect.. no IT ran perfictly but a program it called reported information diffrently on my system than it should and that created a bug...
I fixed the bug... but the bug was unique to my system alone and would accually cause problems for ANYONE ELSE... It was easyer to fix in the non-buggy code than to track down why the other program was behaving the way it did and figure out how to make IT behave... Worse yet I could break a whole bunch of other programs if I fixed that bug..
It's the wrong way to fix the code but it got the job done... sence then I have been able to make everything "play nice" but I'm not even using that program anymore...
I don't actually exist.
That is your interpretation, and I choose to disagree with it. Do you really believe that either of these companies could fix an unknown bug in just one day ? Really ? These are the bugs that the vendor knew about and had a fix ready when they announced the bug.
Even a "simple" bug must be tested, and that takes longer than one day. Average statistics tell nothing, that is true. If we don't take those vendor-announced bugs into account, the statistics actually show RedHat in better, not worse light, as the new numbers show how fast the vendor responds to unknown bugs.
The fact is, if you analyze a bumblebee according to the aerodynamics of fixed-wing vehicles, they can't fly worth a darn. This is correct -- when was the last time you saw a bumblebee glide?
The error of course is in the assumption that fixed-wing aerodynamics applies, and it doesn't. Analyze them by the aerodynamics of moving wing vehicles (which amounts to using helicopter aerodynamics, there being damn few ornithopters), and things work much better. (Still not strictly accurate, of course, insect wing flapping is pretty complex.)
Helicopters glide about as well as bumblebees when you stop the wings (blades).
-- Alastair
It's interesting, isn't it, how slow these are.
...).
The _vast_ majority of bugs reported to me only take one or two days, at most, to fix; a lot can be done in a couple of hours. (Once in a while, there are major architectural bugs that take days to fix, but even those i've never had take longer than a week
There tend to be two problems, tho. (1) In the case of major architectural bugs, I am not willing to release my 'fixes' until it's been determined that they didn't actually make the problem worse; this can often take upwards of a month. (2) It isn't uncommon for a bug to take several weeks before I even look at it, because I'm looking at something else right now and only have so much time. This is where open source projects have an advantage: there are more eyes, so things get looked at sooner.
Fixes occur at the speed to which a project manager finds the need for the patch. All software engineers know that inorder for the fix to occur the managers of the project must allocate the time, and resources (grunt /. readers).
A perfect example of this would be the Microsoft IE browser. This package came out of nowhere while Microsoft threw unlimited resources at the project. All bugs where nailed fairly quickly in the begining.
This concept applies to all software packages too. If people want the fix, and it's a benifitial economicly the software companies can/will come up will new-releases/fixes.
Justen Stepka
I think his point was that OSS has never really had a success on the desktop. Linux and Apache may be successful on the server and workstation arena where you have a million or so generally experienced computer users, but many closed source products are being used by tens (if not hundreds) of millions of average users.
Who am I? Subscribe and find out
I was pretty shocked by next article that an OpenBSD-user showed me. (I'm a Linux user, thank you). You can read it here.
From: Theo de Raadt
comp.unix.bsd.openbsd.misc
...
> I'm just
> curious to know if anyone has broken into an open source system because it
> was open source.
Linux is the best example of this, there are many examples. As the ;-)
system being attacked, that is -- even if their source was not being
analyzed earlier. Funny thing is, (especially around two years ago)
it was a case of _us_ finding the holes, fixing them in OpenBSD,
telling the BUGTRAQ mailing list, and then crackers writing exploits
and using them on _other_ operating systems. (I guess that is
distributed and applied
Sometimes, as in the case of the recent RedHat lpd security report,
years elapse. Let's look closer at what happened:
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947550717304 74&w=2 5 60&w=2 5 70&w=2
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=94731014106
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=94755201131
And then read
http://www.pr ogressive-comp.com/Lists/?l=bugtraq&m=947699382089 89&w=2
And pay special attention to the original bug report. That's October
of '97.
http://www.nai.com/ nai_labs/asp_set/advisory/20_bsd_lpd_adv.asp
As a case in point, where I worked previously, we used OpenBSD and we had security patches installed in the order of hours generally after they were identified and fixes released. In some cases we were capable of making the changes directly to the source based on the bug report.
I would say that scenario is probably rare, and we (the Penguinista) don't really want to imply that to effectively use Open Source you need a bunch of trained uber-hackers who can modify the source faster than a spinning shuriken. We need to show that, even if you have NO additional resources the Open Source model is a big win because there are all these other people out there who can identify fixes and make them available for you.
So, I felt that the use of Red Hat was a great example of an Open Source system because it's how the majority of the target audience (new Penguinista) will use, or be introduced to Open Source.
If you happen to have, or to be, an uber-hacker then you just win more.
Cheers,
Remeber the first release of staroffice 5.0? It shipped with its very own version of glibc.
See you, space cowboy...
I think that you will find that the effective elasticity of air changes as you decrease the size of the wing. When you get down to the scale of a bumble bee wierd stuff happens. Ohter wierd stuff: spiders flying on a single line of silk, butterflys not flat spining.
The Wright bros kind of found this out. They made a tiny wind tunnel to test areofoils. They predicted that a very thin foil would be most effective. For a 35 mph craft it most certainly is not.
Most of the above info is taken liberaly from:'scientific american's great paper areoplane book.' a right riviting read.
Strange but true: more bees have stung me on the feet (when trodden on) than any other part of my body. Maybe they really don't fly.
--
E_NOSIG
If we're the bee...
;)
does that make ESR RMS and Linus the queen bees?
Colleen:Its a black-hole.
Hunter:Is that a good thing?
C:It is if you want to be compressed into oblivion.
H:Oh.. coooool.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
I believe good code has an average of 1 bug for every 1000 lines. Windows 2000 has how many lines? 30-40 Million (I'm guessing here) So we're looking at 30-40 thousands bugs. And that's if it's good code and not rushed out the door, sort of tested stuff.
Sure there will be bugs. Sure, there may be that many. But you're trying to tell me that a fully-loaded Linux system with all the apps won't have the same number of bugs? Gimme a break.
Simon
Coming soon - pyrogyra
IE, like Netscape was based on Mosiac. If you look in IE's about box you'll see Microsoft still credit Mosiac, "Based on NCSA Mosaic. NCSA Mosaic(TM); was developed at the National Center for Supercomputing Applications at the University of Illinois at Urbana-Champaign. Distributed under a licensing agreement with Spyglass, Inc."
Note that it's now only based on, I'd doubt there's much code left over from IE2.
Personally, it amuses me that Microsoft still credits Mosaic, but Netscape dropped the credit quickly.
What I found interesting is that Microsoft has more bugs to be fixed.
Microsoft has more features. More features equals more code. More code equals more bugs. Fact of life. When MS's competition has the same feature set, they will most likely have a similar number and severity of bugs.
I discuss this very point in another post in this thread.
Re:Open Source will always be the quickest -- why?
Most people learn at a fairly young age that "I want it" doesn't always equate to "I'll get it." For some open-source "advocates", it takes a little longer, and they only hurt the cause until then.
If you want something to be open source, get off your ass and write something that's open source. Criticizing other people for what they choose to do with their own software does nothing but annoy people.
If you think that you can write a better slashdot, then go out and do it. I wish you well. The folks that run this site are under no obligation to release anything that they do. The author is the one who ultimately has the rights to the software that he writes, no matter how much you demand otherwise.
Forward, retransmit, or republish anything I say here. Just don't misquote me.
Why the hell did this get moderated up to a 5? I can't wait to meta-moderate this one, as this has got to be one of the worst moderating jobs in history. This is an off-topic flamebait. Oh wait! The key to moderation is to just moderate posts you agree with up and posts you disagree with down. Sigh...
.sigs.
Yes I know this is off-topic too, but I'm getting tired of the poor moderation jobs around here, and more than glad to take any karma hit this will give me.
I don't do
Yeah - your average good coder introduces what - 4 4 errors per hour or something along those lines...
;-)
then think how log they are awake doing this with a big mean ol' bill holding a whip behind them... sleep deprivation, fear, and severe blood loss all lead to numbers well above 4/hr. This is our problem:
We must take down the signs: Please Do NOT Feed the Coders!!!
mmmmmmmm.... 1,000,000 time faster...
"It's tough to be bilingual when you get hit in the head."
Ah yes... heard about that, but I didn't use it back then... glad they managed to get that 'straightened out'.
"It's tough to be bilingual when you get hit in the head."
Oh, people, please...
;-)
We're talking like suits (or even worse - politicians) here.
Open source, closed source... Blah!
Isn't it up to people and their skills and abilities to be able to fix (properly!) bugs?
What you think? If one puts a bunch of your average M$ "engineers" on open source project will it shine just because it's open source?
And at the same time there're (still) a number of companies who can (among other things) make good S/W and quickly fix theire bugs.
It's up to induhviduals, not capitalism/communism/open source
"If you want something to be open source, get off your ass and write something that's open source. Criticizing other people for what they choose to do with their own software does nothing but annoy people."
Isn't the point of open source that you shouldn't have to duplicate other peoples work? Why even have open source if every tom, dick and jane has to start from scratch and write their own slashdot? The original poster was right the ideal is to relase early and release often.
War is necrophilia.
The time they mention is the time between when the security hole is generally known and when it's fixed- not between when it's first discovered and fixed.
You are correct here and I wasn't disputing the point. I think what article was trying to say though was that there was a smaller time of "real danger" with Red Hat vs Microsoft or Sun. I'm saying that their analysis of statistics by simply looking at averages is flawed.
From their raw data you could also read that Microsoft is by far the worst with 700 odd days of vulnerability (which is quite impressive in the 365 days of last year).
The average time for Microsoft could also be brought down considerably by counting security related bugs in Service Packs that never actually hit the mailing lists - some of the bugs that cause a BSOD could probably be turned into exploits. These bugs (and there are generally several hundred "Q" articles relating to each service pack) would rate a '0' on the scale and bring the average down to somewhere around one or two days for Microsoft.
All I meant to say was that the statistics don't mean a lot without analysis of what the real implication of the bug meant. My take from the raw data was simply that Microsoft had a faster time from announcement to release for simple bugs (including internally discovered ones) which was probably related to their distribution channels while Red Hat had a better record in fixing bugs in an overall sense.
If someone wants to go through all the bugs in the list and figure which ones actually were a serious threat, which related to internet server, which related to clients etc. then the stats would be a lot more meaningful.
Take for example that there are no Netscape bugs listed against Red Hat. Would this skew the stats any? The list goes on.
John Wiltshire
Fear: When you see B8 00 4C CD 21 and know what it means
Do you really believe that either of these companies could fix an unknown bug in just one day?
Actually, I do. As an example, the "ping of death" bug was fixed in about 4 hours for Linux (IIRC) and about 24 hours for Microsoft (from the announcement on BugTraq). None of these fixes were 'regression tested' and not many of the fixes mentioned are fully tested. In Microsoft-speak that's the difference between 'hotfixes' and 'service packs'.
It is not my interpretation. That was just another interpretation. All I'm saying is that statistics lie and generally the whole thing doesn't come down to a single number (Mindcraft was a great example of that).
If we don't take those vendor-announced bugs into account...
Why shouldn't we take those into account? Is it valid to penalise a vendor for finding bugs themselves? What this set of data was trying to show was the amount of time a cracker was likely to have from discovering the existance of a bug to when the vendor effectively closed the hole. In that context, vendor announced bugs are a good thing - it means the cracker gets no time to penetrate a well managed system.
As I mentioned elsewhere, this is only half the case as non-announced bugs fixed in version upgrades are not taken into account, nor is the severity of the bug taken into account. Overall I think my conclusions were quite valid. MS has better distribution channels and RH has more programming resources.
John Wiltshire
Fear: When you see B8 00 4C CD 21 and know what it means
Yea, if Rob had started with Python everyone wouldn't be pounding their head on the wall quite as bad right now, but then, if Slashdot were in python it wouldn't be as featurefull as it is now. Python code is just slower to write than Perl code.
And remember... there's nothing that *prevents* you from wrighting good, maintainable code in Perl.
-- The act of censorship is always worse than whatever is being censored. Always.
Human life is important, but judgment calls must be made, and, for a car maker, a "We will do everything we possibly can to protect human life reguardless of cost." judgement is just as bad as a "We will cut every corner to save money reguardless of loss of human life." judgement.
-- The act of censorship is always worse than whatever is being censored. Always.
My theory is that most of the people here on Slashdot that are so "Microsoft is the best thing since computers" eithor
A. Have never tried to do a significant programming project under Windows. or
B. Have so much time and money invested in Microsoft knowledge and products that they are resisting anything else.
-- The act of censorship is always worse than whatever is being censored. Always.
Hey, if someone doesn't follow the API as documented, it's their own damn fault when their App doesn't work with the next version. The should pretty much expect it to fail.
-- The act of censorship is always worse than whatever is being censored. Always.
Say something good about Microsoft and bad about Linux (true thing of course) and you will get moderated down. I once made an offtopic post on some slashdotted article about what server it was running. I noticed that a post before mine had said "Site seems to be Slashdotted, must have been running Windows NT : )" It's score was +3 Funny. So, the cynical bastard I am, decided to make a post that said "Site seems to be Slashdotted, must have been running Linux : )" Score: -1 Flamebait. I would post a link, but I forgot what article it was on.
Everybody knows about the response time of different people.. I mean.. look how long it took microsoft to fix that one piece of really buggy software that they released... you know.. windows? It doesn't suprise me that Unix is right where it is. Hell this whole this is the most unsuprising thing I've ever seen! Do not mess with the chupacabra, lest ye be sucked.
~Jester
"I have great faith in fools: Self confidence my friends call it." ~Edgar Allan Poe
These are, quite arguably, some of the most successful pieces of Open-Source(tm) software out today. Rebuttals?
-Chris
In the Closed source model the figures work out like this
At time of coding one error per ten lines of code
after the coders initial debug this decreases by a factor of ten.
After initial QA work this goes down by a further factor of ten.
With beta testing this goes down by a further factor of Ten.
so all in all there should be roughly one error per ten thousand lines of code in production code.
Beyond this level it is not considered cost efective to make any further checks. It is also considered that any extra rounds through the checking process both makes the software increasingly out of date, and pushes up its market price. the calculations lead to the idea of Win 98 having 6000 errors. this is only a rough estimate, no one knows how many there actually are. (if microsoft new what they were they would have taken them out.)
With Open source having a much improved fault finding and repair model (cost of bugfixes isn't a consideration) it seems to me that it might be possible that the perfect piece of software could be written. but for now it should probably be considered as just having another factor of ten in bug reduction.
* Once we invested time, effort and money to write this software,
how can we avoid having someone larger than us profit from our
labors at our expense?
You can't prevent other people from making a profit out of what you do. When you sell something to another company, they're making a profit out of your work, when you buy something from another company, they're making a profit too. So obviously that can't be what you REALLY wanted to ask (and if you were a smart businessman I'm sure you wouldn't make that kind of mistake).
What you really want is to make sure that YOU PROFIT from your investment. It doesn't really matter if someone else is making money, so long as you get yours. The way to ensure this is by using a license like the GNU GPL which prevents other companies from making a proprietary derivative of your product.
* What is the economic model that allows me to profit from my
knowledge and skills, since you insist I am to give away the
fruits of my labor for free?
Do not give things away for free! It's obvious to me that you're starting to troll at this point, practically every post to this thread has pointed out that libre != gratis. If you're a profit-making company you need to get a return on your investment, so don't give anything away free.
Someone wants your software? Well, they sure COULD try to find someone else with it and take a copy, but YOU will sell them a nice box, a professionally produced manual (with the most up-to-date documentation) and a full year's support contract for only a trifle more than you charged last year. Now it has source included for that added peace of mind. Who could resist?
Of course, they COULD go to your competitor, but why buy from him when he doesn't know anything about the product? You employ the experts, you have the best people for the job, and from here on you go straight into the usual marketting BS which every customer gets.
If you're BETTER than your competitors then Free Software levels the playing field, and you should find that your markets INCREASES. If you're not better, then frankly I don't care if your company sinks into the marshes, sooner or later your competitors will figure out that Open Source benefits them.
* Who would write this highly-specialized software if we didn't, and
why would we do it if there was no incentive for us to do so?
If no-one else would write the software, go find someone who wants it, and tell them you want to write it, FOR A PRICE. You can do them a great deal, because they will get the source code -- not in escrow (which is probably what you do now if you're in that sort of business) but up front, in exchange for the final check for the development work. There's your incentive, cold hard currency.
If no-one else wants it then I don't either. Go peddle your worthless software to someone who cares, and ask yourself why anyone, least of all Free Software advocates should think of incentives for you to write useless software.
(FWIW I don't intend to remain unpaid forever either, but for now I have
enough money and work not to want a Free Software job)
Nick.
That can't possibly be true for all cases; ping is still broken for rh 6.1. Users are forced to backtrack to the version shipped with 6.0.
/bin/ping, and no fix! I know for us do-it-yer-selfers it's trivial to force-downgrade to the one shipped with rh6.0, but let's be honest, redhat is not impressing new users with this behavior.
It is an undisputed fact that RH has been aware of this since October 7, 1999.
Over three months on something as simple as
For those interested, it's Bugzilla bugid 5692, found here.
Thanks,
Josh
Don't sweat the petty things. But do pet the sweaty things.
Try installing a NT4 driver in 2k. What happens?
Well, my logitech driver made me loose keyboard and mouse. SoundBlaster Live! driver caused a BSOD on boot. May I ask, why does a sound card driver kill the entrie system? How about a "Couldn't load driver" message and then no sound?
BTW, To install a NT4 driver, just stick in the driver cd, it will auto-install without any warnings. I would be very afraid if I was a hardware vendor. Maybe the RTM is better then RC2 but I wouldn't hold my breath.
(appended to the end of comments you post, 120 chars)
I do hope the RTF version is better then RC2. I'm sure(hope) it is. But, a RC is not a beta, it is a release canidate. Only MINOR changes are(should?) be allowed before RTF. I will be using W2K for the next 5-10 years so I hope they get it mostly right. For the most part it does seem pretty nice, or at least better then NT4.
(appended to the end of comments you post, 120 chars)
so, how the hell do you find out if the solution's reasonable? do a cost analysis and see if it's worth it. it will cost $4.2 million to save 1 life? not worth it--a similar investment in the frame would save 3 lives. end of story. the irrisponsible comapany is the one who, understanding, fixes the gas tank and not the frame.
as far as internalizing the externalities... they are already internilized for the following reason: people decline to buy fords when consumer reports says they are unsafe.
as far as the original analogy goes, it would be even more stupid to hold companies liable in the general case. if, on the other hand, the company is willing to guarantee that its software is resistant to certain types of attack, then let them make their own contracts!
Interested in learning Chinese or Japanese? check out Chinese/Japanese-English Dictiona
first of all, i reject your distinction between incremental changes and fundamental defects. it dosen't really matter.
nevertheless, your point is: ford could have saved many lives cheaply. maybe you're right and maybe you're not. if you are, then they are stupid not to have. anyway, the only way to make your case is to do some real number crunching, which, despite your good technical descriptions, you haven't done. (neither, of course, have i)
what the jury fined ford several billion dollars wasn't for making a poor deisgn choice, but for putting a price on human life, which is something they simply have to do. unfortunately it's something that we, precious children of god, would rather not hear.
Interested in learning Chinese or Japanese? check out Chinese/Japanese-English Dictiona
But maybe what we need is a good Pinto case - wherein the bean counters at Ford decided that the cost of adding an 8 cent plastic cap to a bolt in front of the gas tank was more than the projected number of immolation-deaths per year. Jury-award was a record at the time, nailing Ford for hundreds of millions in punitive damages to demonstrate the moral repugnance of such calculation. Something to think about, at least.
a prof. of mine once said that this case showed the immaturity of our society. after all, you can always add, say, an ounce more of steel to the frame (or a damn plastic bolt to the gastank) and save a few deaths per year. I don't expect slashdotters to be a bunch of libertarians like me, but i do expect more sophistication than this jury had.
if you wanna cough up the cash for your safety, buy a volvo. cheers,
sh_
Interested in learning Chinese or Japanese? check out Chinese/Japanese-English Dictiona
Pick the 3 things that lacks the msot in Linux and pretend they're the best.
Moderate this guy up, he's making me roll around on the floor with laughter.
Looks like there's a new edition of this title due soon. Amazon have an edition listed for pubication in 'December 1999' at 30 bucks, as well as the older 1996 edition at 19.95.
The publisher Butterworth-Heinemann and the ISBN is 0139277730
free experimental electronic music netlabel at www.viablehybrid.com
I am a big believer that open source is great at squashing bugs, but in my experience Redhat is kinda slow at getting out the official fix. For example, the linux kernel is at 2.2.14 but Redhat has not put out a official rmp yet even though 2.2.14 contains a bunch of fixes.
Why not post it, even with all of the hard-coded stuff left in. At least it would give people a chance to play with some puzzles and possibly give you extra eyes to spot problems.
it has less bugs because you havent found a bug? What kind of logic is that? W2K has 40 million lines of code or so, I guarantee there are MORE bugs, based on size alone, then there are in other MS products.
What exactly is broken about ping? It works fine on my box
Here's my DeCSS mirror, where's yours?
if someone from the open source community had headed up the QA team, could it then have less bugs
:-)
Nah, they'd spend too much time going to meetings, just like all people who head up teams.
Hardly a fairer comparison.. microsoft doesn't ship those other popular windows programs. Redhat ships those open source programs, therefore they should accept responsibility for what's on the CD with their name and logo.
It's easy to fly.. Just throw yourselves at the floor, and miss. :-)
(1) In the case of major architectural bugs, I am not willing to release my 'fixes' until it's been determined that they didn't actually make the problem worse; this can often take upwards of a month.
I'm sure that's the same reason microsoft and other companies take so long. When you ship so much software (or some software that is just so giant), just about *any* change you make can affect other products or other parts of your own product, and it takes quite a while to verify there are no bad reactions. And if there are, well then the cycle starts all over again.
Really, I don't think 11 or 16 days is bad at all. Now, Sun's statistics...
Yes, they can tell lies, and quoting them leads to more lies. Taking the different development models and business structures into account, I would think that it beehoves M$ to fix the easy bugs faster. Of course, they are not open to the widespread peer review that code released to the public domain is, and I believe taht is part of the bug refix problem.
All comments are my own (Unless I am having a out-of-body experience).
That is why the article stated that an aware IT professional could cut the Red Hat time in half. They pretty much stated the same thing in fewer words.
B. Elgin
B. Elgin
"Read at your own risk; feel free to ignore."
this guy's website sux
/. does not suck. It is a wonderful means of communication. It is extremely effective And has >GREAT power to enhance OpenSource and other general geek values.
/. as a community to discuss geek stuff. I hate the fact that they are ripping us off in the process.
You're missing the point.
You may not like my application, or my web site. You may think the smattering of avatars people have taken the time to put on the site suck too. but you are still missing the point.
The point is... Slashdot is riding the OpenSource / Linux wave while not participating by releasing their code in manner which allows people to participate in the development of this environment And making money off of our ideals in the process.
I love
As for advertising my site in my sig, It's called pride in what you do.. Perhaps if you had something to be proud of you would not be posting as an anonymous coward and would have a link to your own site... even if it did suck somewhat. But for what it's worth.. Enough people think that OpenVerse Visual Chat does not suck that we have a fairly large userbase which includes some major OS heros who I will spare mentioning here. Have a look at the comments page if you're insterested to see who thinks OV doesn't suck.
They are a threat to free speech and must be silenced! - Andrea Chen
Fish! LipHo
Ah!! I found the reference to the sig.. so it's changed now... (Credit where credit is due and all......)
They are a threat to free speech and must be silenced! - Andrea Chen
Fish! LipHo
You are a threat to free speech and must be SILENCED!
It is a quote made by a female free speech advocate. I really wish I could find the reference to give the credit to her for that statement. But I assure you, it definatly is meant to be irony since the most controversial subjects on slashdot are often moderated "out of view". The admins encourage people to set thresholds to 2 which supports the above statement.
They are a threat to free speech and must be silenced! - Andrea Chen
Fish! LipHo
How are you going to guarantee this wise guy? Are you going to send me money if you're wrong?
Are you saying it is absolutely impossible that Microsoft could have done appropriate QA on this product? What if someone from the open source community had headed up the QA team, could it then have less bugs, or would the inherent superiority of open source be overwhelmed by the inherent inferiority of Microsoft?
hg
Drop the
But, it does alter their definition of "Recess", which is what matters for security bugs.
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
I especially dig the phrase "I'll probably get flamed and moderated down for this", since almost every post I see with this phrase gets moderated up. Moderators, they are playing with your mind. It's almost like the poster is say "nah nah, I dare you to moderate me up!"
Haha... I was thinking the EXACT same thing when I read that post...
- Dr E. -
Yes, but you selected it by setting LD_LIBRARY_PATH. Not by overwriting the system version.....
You've got it in one! So many good "freeware" programs have just stagnated out of existence but the whole point of Open Source is that if you don't like it and no-one else is willing to do anything about it...you can just do it yourself!
~me
Does it really have less bugs? Ive been running w2k for a few months, and besides taking a long time to load, it has a few bugs with the mouse pointer and confusing left and right mouse clicks in older games, which is really annoying, it hasnt blue screened on me yet, though its not the final release Im sure they should have fixed up everything when it comes out soon. Oh, and does ping in w2k work for you? thats my 2 cents, even though its probably not too relevant.
I think most software companies that ship their software on physical media would have those problems. My own company gets bug fixes out the door usually within a week. But then again we do shareware and it's only available on the Internet. I've noticed most Internet only software tends to get fixed faster just because it doesn't have that huge inventory.
If you go and buy Windows 95 off a store shelf (if you could find a copy) it's the first release. Why? Inventory. Microsoft probably doesn't need more Win95 CD coasters so sell it to the unsuspecting consumer who will just be "so pleased" to have win95 over win3.1 they won't care it's totally buggy.
two posts and slashdotted already? Mirrors anyone?
I'll probably live to regret this, but here's a mirror of the main page only with no images. If this overwhelms my shared T-3 or campus networking services complains, I'll have to take the site down. http://141.219.83.94/security.html
Good point.
..
.tar.gz file does (and any bugs it fixes) and the general direction to go when installing it.
.rpm file is avaiable.
I am not claiming to be a elite code hacker, the most programming I do is in the bourne shell or Perl. I won't know what to do with a peice of C code if it bite me.
The point is, I am not an elite kernel hacker, just a system admin without decent coding skills, but I still can apply source code patches. Most of the time, they just release a new sub version, like if 1.1 had a security hole, 1.2 is exactly the same with the bug fix. Normal I can find software on ftp sites and patch the system up with a
tar zxvf program_without_bug.tar.gz
cd program_without_bug
./configure; make; su
********
make install
exit; cd
rm -rf program_without_bug*
The point is, even though I don't have mad coding skills, the bug is ussually fixed before Red Hat puts it in a nice little package for me, sure it takes a couple more commands to get it installed, but it isn't something any other (unix) sys admin couldn't do.
Even if they don't make a nice configure and Makefile they are going to have atleast a README file or a blurb on their web page of how to install it.
(one of) the good things about GNU code junkies is that they do honestly try and work with the people installing and using their programs. They aren't just going to throw some x86 ASM in an unknown compressed format on their ftp without explaining why it is there or how to use it. They will try and atleast create a short README explain what the
I will admit I am not a "ruthless code hackers of Kung Fu level", but me (like any other unix system admin) knows what to do when no
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
I disagree. Nobody is claiming Slashdot is in violation of any licenses, but it IS hypocritical (though not illegal) for Slashdot to give so much lip service to the benefits of Open Source while not Open Sourcing their own code.
That post was irony. I HOPE. Otherwise that guy is deluded, as he picked out most of the current weak spots in Linux (filesystem, support for 3D standards like OpenGL, SMP, etc...All of these things are coming, soon..but not quite there yet on Linux)...
faster /. effect.
if you are a developer and something you are working on is not working, you can figure out why. you don't run into the problem of an unresponsive undocumented API. Look at all the crap MSDN-CD is full of, and how impossible it would be to get any work done without it, and how many little SDK idioms you need to resort to.
What I don't understand is: why are you bashing MSDN, the biggest developersource on the planet? And why is it that it's impossible to get work done without it? because you don't know where to look or which of the numerous nice ways to find your way to the 1.5GB of information should be taken or is the fastest? That's exactly why it's not that interesting for a lot of developers to dive into a large pile of Open source code to fix something. Have you ever joined a developmentteam that was working on a software project for already some time? Did they expect you to know where to find every bit of functionality right away? NO! Not at all, because it would have been redicilous. It IS possible to find bugs yourself BECAUSE you have the source it's however not realistic every USER of an open source program and also knows how to program is ABLE to patch a bug quickly: because he/she doesn't know where to look, and HOW to patch a piece of sourcecode so that it won't effect other parts of the software.
Sorry if I sounded offended, but I can't really understand why people are talking so easy about adapting sourcecode and that it is 'all nice and easy because you can easily patch it yourself'. A lot of developers are confronted with this every day. Helping their managers think it's very easy to catch on is not the way to go IMHO.
Never underestimate the relief of true separation of Religion and State.
I.e. if I can profit from closed-source development for only the duration of my employment at, say, BigSoftwareCo, then it behooves me to maximize my salary & benefits during that duration, leaving it essentially up to BigSoftwareCo to decide how it will maximize its long-term viability. Since I can profit from OSS development for the duration of the practical life of that software, I have more incentive to make it live a long, healthy life, even if that means making less $$ in the short run (not necessarily always the trade-off I have to make, but one I've willingly made a few times already).
Of course the whole argument works the other way, too. If you're employed at a closed source shop you just might want to write a crufty, awful, undocumented nightmare that only you understand as a way of guaranteeing job security. I don't work in a software shop, but I have seen the "only I know how it works so you'll just have to put up with me" trick pulled. Others have alleged that many undocumented API's in Windows have been engineered as a form of job security.
That kind of programmer initiated crap is also not practical with open source. The peer review inherent to the system will tend to weed out lousy, difficult to maintain code before it gets into the main distribution. It also means that programmers are more easily replaced. After all, there are already plenty of people out there who have been working on the source and know the system. They won't need break in time while they learn the code, and the code they've already submitted can act as a portfolio in judging them.
There's no point in questioning authority if you aren't going to listen to the answers.
How is that FUD? Remember the word has a very specific meaning. It was invented in reference to tactics by IBM. These tactics are the lifebread of microsoft's current operations.
/fuhd/ An acronym invented by Gene Amdahl after he left IBM to found his own company: "FUD is the fear, uncertainty, and doubt that IBM sales people instill in the minds of potential customers who might be considering [Amdahl] products." The idea, of course, was to persuade them to go with safe IBM gear rather than with competitors' equipment. This implicit coercion was traditionally accomplished by promising that Good Things would happen to people who stuck with IBM, but Dark Shadows loomed over the future of competitors' equipment or software.
FUD
--
He lives in a world where those who do not run the client software of the omnipresent meme are unacceptable.
Awesome .sig
Best yet!
--
He lives in a world where those who do not run the client software of the omnipresent meme are unacceptable.
I'd rather delay a package for a day than having to release yet another security update for the same package the next day...
That is why Glint (which was the graphical pagkage manager software people used to use to install RPM packages, including updates and bugfixes) was broken on the Red Hat 5.0 CD-ROMs, right? Because Red Hat cares about quality, eh? All anybody would have had to do to find that particular bug was install a copy of Red Hat using the ISO before it was shipped to the presses, and run Glint once. Somehow it made it out and into the release.
Maybe quality has improved as the customer base has exploded and the top managers have gotten flashier sports cars. I tend to suspect not.
I think I was wrong. It was in the 5.1 release.
The Glint problem wasn't a security fix. But it was an ironic package to have failed, as it's the program many people used at the time to apply package fixes.
And I haven't noticed any additional bugs in Red Hat distributions, because I haven't made the mistake of using Red Hat since then.
I think the fastest responses are when the projects are not correlated with an enterprise, Linux "official" support by various distributions are quicker than microsoft, but slower than the projects outside any enterprise.
Well, my standard response to all bugs is, are you using the latest version? Which has much the same effect.
So name a bunch of OSS projects that don't rely on people working for free.
That's true, providing the "current release" is actually on the market.
There is a time span where the new release spends some time being "internally tested", etc. This is a situation where the "latest release" will not be available to the user. If the bug is important enough, and the customer is also important enough, you can almost bet that there will be a "political" response to the matter. A response where execs get involved, to make sure that the customer is satisifed. This is where said developer ends up working 12 hour days until the code is migrated back to the current release.
Heck, in some situations, I've seen it where many developers take shifts getting the fix out (Bug is worked on 24/7, with each developer taking 8-10 hour shifts.)
Don't expect the number of fixed bugs to be accurate (read on to find out why.) I can't speak for all the software companies out there but ...
... usually done by referencing a Problem/Bug # of some type.)
A nameless software product that was developed at a company where I worked at one time, would have bugs (as all programs do.) Now, the "official" process for fixing reported bugs were to, of course, document everything (e.g.: How to recreate the bug, any symptoms that occured, frequency of occurance, plus appropriate comments in the source code to match the changed lines to the supported documents
Things would be great if ALL the developers followed procedures ALL of the time, but they do not.
In fact, I have seen situations where bugs were reported in a product, and a developer would (instead of following procedures) "hide" the fix for the bug in with the code for a next-release-type of feature. This would result in the bug being fixed, but ONLY in the next release of the software, NOT as a patch in the current release.
Meanwhile, the documentation for the bug would sit there, with some type of "pending" status. It eventually sits there for such a long length of time, that it is eventually closed off with some type of reason such as "Need more info," "unable to reproduce," etc. Basically, this is done after no one really cares anymore, as the customers are now using the next release of the software, which has the bugfix "hidden."
Now, you can go ahead and draw your own conclusions about this, but keep in mind the following: I am NOT saying that any of the software products represented in this post fall under this category, simply that if one company out there in world does this, I wouldn't be surprised to find another that does something similar, if not the same.
I have also seen it where a developer would find bugs themselves, and in some cases rather serious ones. Instead of documenting the bug, they would "hide" the fix in with the next release code.
... in the case where a user DOES find the bug, and reports it, the software company, which has already fixed the bug in the future release, just has to migrate the fix back to the current release (much faster than fixing it like it was an unkown bug,) and VOILA! The user's happy, and the company looks really sharp for having addressed this "very serious bug" so fast and efficiently.
Of course, the result of this is that there would be software out there, with potentially serious bugs that a company knows about. Instead of it being patched in the current release, it is fixed in a future release. Another interesting "side effect" is that there is no negative publicity generated by the public being told about the bug.
AND
OK, I'll shut up now.
OSS bug fixes are simply faster because lots of people are reporting bugs and fixing them.
... Faster bug fixes do not mean higher quality code.
Much better code is produced for worthwhile projects Like it was said elsewhere in these comments about this post
In fact, the more of these speed comparison stories that surface, the more I start to get concerned. Concerned, for one thing, that some OSS developers out there will get into a certain mindset that a fast bugfix is "required" in order to help the image of OSS in general. If this turns out to be the case, I fear that we may start to see the quality of OSS bugfixes drop.
I hope that this does not happen.
Open source software will always be the quickest for bugfixes assuming that the software is currently being actively maintained. As the source is there it just means that anyone with the ability is able to provide patches to fix the bugs so even if the original writers of the software are to give up on the project some one else can come along and fix the bugs. With closed source software you don't have that option and you are therefore reliant on the vendor fixing the bugs, if they don't fix them they never get fixed.
--
Posted with Mozilla
Sounds like 3 programmers just got a crash course in job security. I bet one of them realized, "Hey, if we release the code, then 300 to 3000 programmers will get to work on this stuff and the suits will see us sitting on our duffs. Then they'll start wondering what they're paying us for. Let's keep the code here so that we'll have something to do."
Ain't Open Source a bitch? The nastiest thing you can do to a worker is increase productivity. It makes everyone look bad.
I'm not one of those test managers who manage but don't test. I've done everything from writing the tests to performing them -- for banks and large government projects. I own my own company, and brought in over $100,000 last year in the Y2K frenzy.
Mostly I do (test), and don't spend much time managing -- unless it's to fight for more time to test.
If anyone knows or supports the idea of detailed regression testing, it's me...insisting on a contractual minimum level of testing. I've generated test plans with over 1,000 individual tests -- all specifically targeted to the requirements in the actual contracts. (I don't just make this stuff up!)
Yet, with Open Source projects, there's little or no formal testing. What testing gets done tends to be tainted; testing by the developers themselves. Do I care? Actually, no. The quality tends to be fairly high since the developers, themselves, care. They pay attention, and the quality of programmers is visibly increasing.
This trend -- and that, yes, testing jobs suck -- has convinced me that less testing will be approved in the future and that I'd better adapt.
Five years ago, I would have promoted VV&T as a good if unrespected career. Now, I'm convinced that it's a place for two groups of people only;
1. Loosers: ex-school teachers, temps, less technical analysts who just pick up a check, and "black group" annoying folk, or
2. Professionals: The kind of people who know IEEE or CMM test methods and tools or at a minimum have exceptional puzzle solving and logic skills and seek those tools out.
It's difficult not to be lumped into and treated like group #1. No, I'll amend that. It's nearly impossible not to have someone chew your ass out every few weeks just for doing the tests right and documenting actual, real, problems or deviations from the requirements they, themselves, aren't paying attention to.
My decision? Drop testing and become a network admin. After a while, when I can do the job well, I'll try to find a new nitch and specialize. Five computers in my basement, networked, one of them a Sparc system with Solaris, a pile of O'Reilly books, and countless hours installing/changing/securing them has given me the basics. On a scale of 1 to 5, I'm a 2...and don't deny it; I know I can do quite a bit of dammage and don't yet understand how to be a good admin. In a couple years, I hope to be at level 4.
Sure, as an admin I'll catch about as much hell and get thrown off projects by the same political currents as before, yet after going through testing I'll be prepaired for that kind of flack and lack of respect. After a while, it won't matter...but I'll have a good job and in demand. Then, I'll get back to double digit contract increases...ahhhh!
Does choice of language affect the unmaintainablity? You bet it does. And in the opinion of many, Perl is not well suited to large maintainable programs. One method of taming this problem is to choose a more modern language, an Object Oriented language. While the benefits are not realized in many partial OO languages (such as C++), clean languages like Eiffel and Python are an effective tool in order to ensure long term maintainability and extensibility.
(No flames please. This is offered up a food for thought, and as an object lesson in how even people like Rob Malda ignore the best advice of their Computer Science professors.)
>We have our best perl coders here slaving over the Slash release. Patrick, Rob, and Pater...
Ever stop to think there might be folks out there that could help who are better than your three best perl coders?
>The Slash code really is hardcoded in many ways and they are trying to unhardcode it for you now.
And we're somehow not able to figure this out ourselves? Or at least lend a hand finding bugs, hardcoded assumptions, off-by-one errors, etc?
Y'all need to stop trying to make a release that 'looks good,' and take a little time to re-read CatB. "Release early, release often." Not "when it looks pretty," not "when we think we have most of the bugs fixed," not "after we've added this one new feature."
Because what that's going to get you is an immaculately-debugged Slash that is going to have to be rewritten anyway since you didn't expose the code to enough eyes to find the bad practices and assumptions that no doubt live in there. You'll have cleaned up a bunch of code that will get thrown away anyway. cf Mozilla....
Do it now -- 'tar cvfz slash-0.50.tar.gz slash/' and put it out there, warts and all, money where your mouth is. I double dare you -- you might end up surprised at how much faster the code (and therefore your revenue generating site) gets better. Ah, and that takes us right back to the original topic, donnit?
--
If you assume for someone else to profit, you have to lose, you will avoid this situation at all costs.
If you consider it possible for yourself and another to both profit in some manner, then you will be more inclined to allow this situation to happen.
There are good arguments on both sides- for instance, when you include corporations in the equation you have to understand that, while you may wish a mutually-profitable situation, the corporation is legally bound to not only try to profit, but to try to hurt you and cause you to lose, if you are in the same line of business. It cannot cooperate with you. But at the same time, if the corporation is copying your GPLed source, there is a limit to how uncooperative it can be. It can take your code, use it, outmarket you and then withhold its changes until release- but then it has to let you have them, and even without using your code it still outmarketed you, get used to it ;)
The basic issue is simply this: how important is it that you be able to prevent someone else from profiting by your labors? Are your labors so miraculously advanced beyond the rest of the industry that (a) nobody can help you with them, and (b) they'd make a significant difference in the performance of your competitor? This is software, people- there's never been much of a link between quality and profitability. If there seems to be a gain from cooperating, consider the possibility that 'having someone else profit from your labors' is just a chance you'd have to take.
This whole 'winner takes all' concept seems to have grown out of the years of Microsoft monopoly. I suggest that this is not the only way the world works, and that the software industry is drifting back into regions where developers can profitably cooperate with each other. It's _normal_ to not need to take a 100% hostile ruthless attitude at all times. Such things are quirks of history, and we have lived through such a quirk. Amazingly enough, some things survived, such as Macintoshes and Linux. Now it's time to settle down a bit, quit scorching the earth, and get back to more normal interactions.
Have you ever joined a developmentteam that was working on a software project for already some time? Did they expect you to know where to find every bit of functionality right away? NO!
[sigh]...
Have you ever joined a development team that was working on a software project for some time with a buggy API underneath it, that they didn't have the source to? Have you ever just have to learn to live with its quirks (like they already had)? Have you ever wanted to have the source to that d**m thing and be able to fix it yourself?
No, this doesn't mean you don't have to spend a couple hours staring at the thing going "how the fsck does that work?", but it does mean you at least can do this if you're so motivated (like I am). And it's much easier to understand the code if you understand the API.
Of course, getting folks to use your revisions is a different matter... :)
As for making patches that don't mess other stuff up, that's a matter of having properly designed and documented software -- which a well-maintained open source project will be.
such as this - if a company knows of a material defect in their product and conceals such to the consumer, resulting in losses to the consumer - said greedheads are liable under the higher standards of gross-negligence, recklessness, or even intentional tort, resulting in statutory treble damages or unlimited punitive damages in some cicumstances.
The greedheads are already well on their way to taking care of that little problem. Go read up on UCITA.
http://www.troubleshooters.com/ucita/
http://www.2bguide.com/nccusl.html
Here's a list of Infoworld articles on UCITA
You can find a whole lot more besides these by doing a Google search.
It's not enough to bash in heads, you've got to bash in minds. - Captain Hammer
Red Hat doesn't do the majority of the bug fixes.
Red Hat just re-packages programs that other people write. The real bug fixes are being done by the project maintainers.
The only exception to this is that the Debian project has package maintainers that foster a good relationship with the upstream project maintainer. The Debian project really passes those bugfixes upstream.
--
I noticed
--
I noticed
It's getting about time to leave everywhere
I'll agree with you on that. I've it happen to many people. My opening line of "I'll probably get flamed and moderated down for this " wasn't intended as carrot, but truly reflected my feeling (as you put it) that you do have to tip toe around. In hindsight, I don't like it when I see other people make similar comments, so I won't be doing it again.
Oh! Was that my tongue in my tongue in my cheek? ;)
Nice.
I guess that it depends on the platform/market.
I'll probably get flamed and moderated down for this (there seems to be a rather vocal fundamentalist open source community here on /.)
Everybody toutes open source and how good it is. These people generally cite certain prime examples to support their arguments. (I think also think that many of these people are as biased and tunnel-visioned as the esteemed Mr. Raymond.)
For some software it works well. Although Linux is a stable and it's security holes are filled quickly, it's not as successful as other products. Everybody seems to want it to be success on the desktop - I won't call it a success until it actually puts a dent in Microsoft's huge majority. Mozilla certainly far is from being a success. We await the future on that one. I don't think that there are any hugely successful pieces of open source software (sendmail? but then it basically started off with a monopoly)
However, I do not think that all software is suited for open source. The last company I worked with developed database marketing software. Nobody is going to work on that kind of software for free. If we'd open the source then our already established (and far bigger) competitors would have been able to leverage our work in putting us out of business. I don't work for free, I have to pay bills. Infact, I'm quite happy to be paid a lot of money for what I do.
/. doesn't seem to think that open source helps fix bugs. Otherwuse the source that they've released would be more up to date, and consistently kept that way.
Thanks
Bruce
Bruce Perens.
As you have pointed out, there _are_ so-called "unmaintained" software in BOTh the open-sourced and close-sourced software arena, and you have also aptly pointed out that the "deadends" in the open-sourced are not-so-deadends, because if you have the skill and inclination, there _exists_ the possibility that YOU take up the job to fix whatever is needed to be fixed.
You have also pointed out that _NOT_ everyone has the skill and inclination, and you hinted that, therefore, the "open-sourced" model doesn't work for all occassion.
But do you ever try to put your thought on the OTHER SIDE? Think of the close-sourced software - when they are NOT maintained, they remains DEAD no matter if those who want to fix it has the skill and inclination, or not.
Take for example - the software OPTASM - a REMARKABLE assembly laugnage compiler. It is a CLOSE-SOURCE product, and is no longer in the market.
I heard that the company that used to own OPTASM was sold to Symantec, the people who produces Norton Utilities, so, I contacted Symantec, trying to find out if they still sell the OPTASM compiler or not.
The answer I got is NO. Symantec isn't selling OPTASM anymore, and they have no plan to update the product. That means, essentially, the people in Symantec has ABANDONED a remarkable product that was once one of the BEST assembly compiler for the X86 chip line.
And when I further enquired Symantec regarding the possibility for them to release the SOURCE of OPTASM to the general public, - since they are NOT going to sell OPTASM anymore, I figured that they have NO PLAN to make money out of that thing anymore, right? - and the answer I got from Symantec is a BIG SILENCE.
I can code. Although I am not a CRACK PROGRAMMER, I have enough experience to do _some_ update and code cleanups for the OPTASM compiler, if I can get the source to it. And I AM WILLING TO DO THAT.
In other words, I _HAVE_ the skill and the inclination to update the OPTASM compiler, but because of its close-sourced nature, there is NO WAY I get to do it.
On the other hand, if the OPTASM compiler was a open-sourced product, with my skill, and inclination, at least I can get to TRY to update the thing.
In summary, a HUGE difference between the Open and Close sourced software arena are in the MAINTAINABILITY of the ORPHANED softwares - the softwares that are not being maintained anymore.
The orphaned, but open-sourced softwares _could_ be updated by ANYONE who has the skill and inclination, but those orphand close-sourced software will be DEAD FOREVER, if the owner decline to release the source to the public domain.
I hope what I am saying here will bring attention to those who have the right over source-codes of orphaned and previously close-sourced softwares, and hope that they will release their sources to the public domain. If they do not want others to PROFIT from the good gesture (releasing source-codes to the public domain), then they could have release it under GPL.
Muchas Gracias, Señor Edward Snowden !
Hmm: the link you give simply asserts that this is an urban legend -- there's no further information.
As far as I recall, it has to do with the fact that the bumblebee (and other sorts, for all I know) is continually altering the pitch of its wings during flight -- the scientists who were baffled by its seemingly-impossible ability to fly had only consider the case of static wings.
Red Hat is generally considered least secure distribution of Linux available because of the default configuration which runs all kinds of servers after boot-up, not because of their security updates.
They are usually the first Linux distibution to release updates after a security problem arises.
If you go and buy Windows 95 off a store shelf (if you could find a copy) it's the first release. Why? Inventory.
Nope, it's support. They don't want to have to train their OS tech people on original, OSR 2, 2.1 and 2.5. They (Microsoft) want the OEMs to handle that kind of stuff.
Sure, open source can get bug fixes out there faster... but its not like for most open source projects anyone is going out and regression testing the fixes against anything to make sure nothing else is broken by the fix, etc...
Can you give me an example of this happening? I'm not sure what you are talking about.
Speak friend and enter
Mellon
Finkployd
Bill Gates: "Innovation"
This is what attracts me to Open Source Packages/OS as security solutions. You can audit the source code yourself for security vulnerabilities (overflows). Plus the code is audited by security hobbiest/professionals all over the world.
Microsoft aggravates my tourettes syndrome.
Yes, and I've seen scientific arguments that a bumblebee should not be able to fly. But the fact is, it can fly, so any scientific "evidence" to the contrary is probably not taking other factors into account.
----
Celebrate the finer things in life
NDA?
I heard *NOTHING* about removing the fix for NDA reasons, and I was in support at the time. From the moment we had a fix up, there was a fix available all day every day until we got our "final" fix.
The original one was "M310-hangfix", I believe; the !@#*! bug came out days after 3.1 shipped.
I believe we didn't ship source for the fix until we had a "final" patch - that may have been the NDA deal.
I do know that the reengineering work was pretty much internal; we were aware of flaws in the initial patch (performance hits, however minor), but we wanted a fix out so people's systems would stay up long enough for them to get the newer fix.
But yes, the fact that BSDI and Intel engineers were on a first-name basis probably helped immensely in getting the fix out.
The question this raises is, why did it take longer for Windows to get a fix than it took BSDI? They certainly have their hooks in over at Intel.
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
Would somebody please explain exactly what part of any commonly-accepted definition of "Open Source" dictates what release methodology or schedule the developers are compelled to follow?
Weblogging Considered Harmful:
It takes dedication and commitment to make a good open product into a quality open product.
"Cause there's 40 different shades of black, so many fortresses and ways to attack, so why you complainin'?"
If you think that you can write a better slashdot, then go out and do it. I wish you well. The folks that run this site are under no obligation to release anything that they do. The author is the one who ultimately has the rights to the software that he writes, no matter how much you demand otherwise.
Ability To Do Better is NOT a prerequisite to the Right To Complain. If that were true, then:
all movie critics can't complain unless they can make a better movie.
all game critics can't complain unless they can make a better game.
and so on.
I especially dig the phrase "I'll probably get flamed and moderated down for this", since almost every post I see with this phrase gets moderated up. Moderators, they are playing with your mind. It's almost like the poster is say "nah nah, I dare you to moderate me up!"
I think finkployd is on the money when he postulates that Malc is just trying to be funny, or he's craving for karma.
Frac
2k is supposed to have some provisions for not allowing other random progs to overwite dll in system/system32 (which would be nice) - every random Joe Blow app should *NOT* replace system-wide dll s. Ever. Even MS Office (are you listening, chief of software architecture??
Actually, an edict was handed down at MS saying exactly what you're saying - system DLLs are now only to be updated in service packs - not in apps.
Fingers crossed that it stays that way...
Si
Coming soon - pyrogyra
I agree with the sense of your argument, but would like to expand upon it with a few potential reasons.
1) Multithreaded development and debugging. The well-discussed reason is the distributed model of work. Since there are many potential testers in the world for each piece of Open Sourced software, there are also many potential patchers for siad software. The person who finds the problem actually has a possibility of being able to offer a fix.
2) Risk aversion. Big corporations like M$, Sun, HP, IBM, etc. have reputations to consider. If they offer a "fix" that later has to be fixed itself, they are embarrassed and sales could be hurt. This is bad for the decision makers because they have something to lose for their efforts besides pride -- money. The Open Source community has much less to lose. This has primarily been due to the fact that since their work was volunteer, they could hardly get fired or sued. As the world awakens to Open Source and corporations enter the arena, I wonder if this will change.
Be the bee, be the wing, happy birthday Martin Luther King?
Tux is here; Gates to shear; Someone pass another beer!
"If one is really a superior person, the fact is likely to leak out without too much assistance" -- John Andrew Holmes
The AFU FAQ Shows this as False
What I found interesting is that Microsoft has more bugs to be fixed. This in itself isn't a surprise, as much as the fact that the general public doesn't seem to want to face-up to this fact.
:-)
And, with Windows 2000 on the way, won't it just get worse?
Not an incredibly insightful comment, I know. That's why I'm hoping for some insightful responses.
-- I lived through the IPO Rush of '99
Yes, and how many are "Oh, $h17" bugs which just all of a sudden break stuff (I'm thinking of service pack 6 + Lotus Notes(MUST DIE!)). For a week, the only solution they had was, "um, you'll have to run as Administrator until we get off of our arses." Not that Lotus Notes(MUST DIE!) has a whole lot of trouble breaking things by itself...
but that is another rant for another day...
"It's tough to be bilingual when you get hit in the head."
I remember reading an article about how the person who reviewed some Windows source code for the Microsoft v. DoJ trial found that there were plenty of known bugs. Apparently, if my memory serves me correctly, he was allowed one-third of the Windows source code and in that one-third, he found over 3000 documented bugs. Included was exactly how the bugs worked and what they did and, in some cases, even how to fix them.
Chris Hagar
"The price of freedom is eternal vigilance." - Thomas Jefferson
Naw, it's not slashdotted. They're just very, very, security conscious. I got back 'Forbidden: you do not have permssion to access "ads.html" on this server.' Dang, that's great! Can I enable that feature on my end? "Forbidden: you do not have permission to display ads on my browser." ;)
--
I am quite civilized, and I should be brought a beer immediately. -- Bruce Sterling
A "fix" also has the possibility of opening up bigger holes.
The fastest fix is to disable that service until a well-tested patch comes out. This is true whether it is closed or open.
the latter [closed source] favors the development of monoliths, since they represent a harder-to-reverse-engineer, and therefore steeper, wall for competitors to climb
It does something else as well. A monolithic product having once garnered customers for one of its features is more likely to seduce them into using it instead of its competition for its other features. And it can be sold against a range of competitors, none of whom offer its full range of features.
The net will not be what we demand, but what we make it. Build it well.
This captures something I was trying to explain to a UI class I took a few weeks ago. The rest of the points tie into it in various ways, but the two things I brought up were:
These two points led me to the statement "Open source is exposing the interfaces" a couple of weeks ago right here on Slashdot. The ideas behind that are simple:
The difference between the interfaces in open source and proprietary software is not clear-cut. But there is a tendency for open source to have a more dynamic view of the world. The programmers working on the project aren't going to have complete control over all of the customization. So there is an incentive to give away a rich configuration mechanism, or someone will build it in.
One example, among my favorites, is the Free Translation Project. This project is enhancing quite a number of open source projects with translated messages and documentation in a variety of languages. I suspect that my own team are the entire community of users for the Esperanto translations at the moment. No proprietary software project could ever justify the cost of rolling the translations into the distribution and testing them. Our team has taken on that burden. We translate, we test,
The net will not be what we demand, but what we make it. Build it well.
The bumblebee (and other insects like dragonflies and houseflies that have similar flight surfaces) *use* the vortexes that their wing flaps generate to cause a slight vaccuum above the wing, which creates additional lift, in addition to the normal lift from the wings' downbeat. Dragonflies in particular take advantage of the weird turbulences their wings generate to do all the amazing dragonfly types of things they do in the air.
I could have sworn I had seen a reference to some scientist at Berzerkely (I think) right here on Slashdot who had recently built like a 50x scale model of a bumblebee to study its aerodynamic properties and come up with the canonical explanation of how they manage to stay aloft.
-=-=-=-=-
-=-=-=-=-
My mom's going to kick you in the face!
This is why I think the benefits of OSS strongly outweigh the setbacks. Much better code is produced for worthwhile projects.
"You ever have that feeling where you're not sure if you're dreaming or awake?"
"You spoony bard!" -Tellah
That is why glint was broken on the Red Hat 5.0 CD-ROMs, right? Because Red Hat cares about quality, eh?
Well, all I can say here is that shit happens, even here.
Also, there's a big difference between QA'ing one updated package (I'm not aware of any errata package needing another update for the same problem), and QA'ing an entire distribution - the more packages you have to QA, the more likely it is that something gets overlooked.
Also, please keep in mind that Red Hat didn't have as many people to look after bugs back then as we have now.
This message is provided under the terms outlined at http://www.bero.org/terms.html
ping is still broken for rh 6.1.
/bin/ping, and no fix!
Get the iputils and netkit-base packages from Raw Hide. This will help.
We don't usually issue errata for bugs that aren't critical for most users.
It is an undisputed fact that RH has been aware of this since October 7, 1999. Over three months on something as simple as
Well, not quite true. The fix has been around for quite a while (in Raw Hide).
But yes, there was indeed a mistake, it wasn't added as a comment in bugzilla and the bug wasn't closed. I've done that now (ping isn't my responsibility though).
Stupid stuff like this occasionally happens everywhere, and probably can't be avoided completely. (I wish it could.)
This message is provided under the terms outlined at http://www.bero.org/terms.html
Would an all-bugs comparison bring the same results?
My guess is yes - it would bring at least similar results.
If you find a bug in Windows, what do you do? Microsoft does not even have an official bug-reporting system. That's (part of) why long known bugs in Windows (such as "can't install driver from directory with long name unless I tell the installer the short name") simply don't get fixed.
Most Linux distributions, on the other hand, have a bug tracking system (Red Hat's, for example, is at http://bugzilla.redhat.com/bugzilla). The developer responsible for the package you're reporting a bug in is immediately notified.
If a bug is left unattended in the Red Hat bug tracking system for 7 days, the system sends another mail to the assigned developer (repeated every 7 days).
Someone WILL take a look at the bug, and probably fix it (stuff like "On my xyz system with the AAA graphics card, my X server hung yesterday and lacking a network card I had to reboot" is VERY hard to reproduce and even harder to fix though), or at the very least decide he doesn't have the time to look into it deeply and pass the bug report on to the maintainer(s) of the base package, and update our package as soon as the maintainer(s) release a new version.
This message is provided under the terms outlined at http://www.bero.org/terms.html
What I don't understand is: why are you bashing MSDN, the biggest developersource on the planet?
I did not say that the sorts of information that are in MSDN are not useful, they are indispensible. But they are especially indispensible because so little information is available from other sources. These scraps are not a substitute (in terms of usefulness) for source, not the source of an example, but the source of the implementation. I'm bashing MSDN because
Have you ever worked on an MSWindows-platform product that was competitive with Microsoft? I don't understand why all the Microsoft-boot-licking engineers we see here -- that by no means includes everybody, I'm talking about the people who defend Microsoft with an enthusiasm out of all proportion -- don't resent the many hours they spend searching for a work-around to some poorly documented Microsoft bug, while Microsoft's engineers laugh and sneer at you behind their phony smiles. Are you guys sheep? It's like the athletes from a lesser team volunteering to help rub-down the stars from the dominant team before the game. "Oh, OJ, you're so strong!" I don't get it.
More precisely, Open Source software is the bee, we're the wings, and our efforts testing, debugging, and improving software constitute the turbulence that Closed Source development tries hard to exclude but Open Source development, ideally, welcomes with open arms.
Okay, I just made it up and maybe it's a bit lame, but it could inspire somebody to come up with an improved version. ;-)
Practice random senselessness and act kind of beautiful.
If you want something to be open source, get off your ass and write something that's open source.
/. I am interested in the community involvement in IMPROVING this one which is impossible without an ongoing availability of the /. source.
/. /. is making it hard on a lot of us to remain loyal.
Perhaps the people who are being loud about this issue are OpenSource authors? (I am)
I for one am not interested in writing a new
I cannot speak for everyone but I don't think anyone is interested in the code to "steal the slashdot crowd and relocate them to a new forum". nor do I think this is even possible. The net has shown that he who comes first, leads (amazon.com's auction site is a good example as it lags behind eBay even with the troubles eBay has). Users become loyal to the first commers and I include myself as a loyal slashdotter (for now)
What I am shouting about is the hipocrisy which runs rampant from a site which is making money off of our OpenSource model while refusing to participate in it. I'm glad they're making money don't get me wrong... It's a good thing to have money. It's a bad thing to have made that money off of someone else's idea and then to deficate on the idea with comments like "ask me again and I'll delay it again". At the very least, Andover should make a public announcement as to IF,WHEN,and HOW the source will be released and stick to that schedule. They have nothing to loose, and everythgin to gain. There are other discussion forums out there. Some may even argue that they are better, more user friendly, etc... But we WANT to be loyal to
They are a threat to free speech and must be silenced! - Andrea Chen
Fish! LipHo
Trying to judge Microsoft on patch management is a hit and miss situtation at best. For how much MS claims it that it's programs have to be part of the core OS, it's obvious that product groups aren't talking much to each other. For example, take Windows NT. It's no where near perfect, but you can pretty much count on Service Packs every now and then that have some degree of regression testing. This is at least a passible pack stragegy.
Is it anywhere near IBM or HP for OS patches? Hell no. MS is where HP and IBM were 7 years ago when it comes to patching and bugs.
Let's take a look at MS at it's worst. Microsoft Outlook 98. As Steven Webb of Microsoft Technical support described the patches "strategy" went a little something (paraphased) like this:
"I have this printing problem. [Describes problem]
Well, you know those security patches or the archive patch? It should really be considered a service Pack. See, it has about 150 odd fixes inside of it.
Is that documented somewhere in Technet?
No.
So it's been fully regression tested right?
Yeah, sure...that's the ticket"
Luckally I was a premier support customer. Basically, you pay MS a boat load of money and they assign some dude to you who is supposed to be dedicated just to your company, yet is never at his desk to answer your call. However, you do get to see all the neat little comments in the Technet that are marked confidential.
For MS a confidential note is usually the exact steps it takes to reproduce the problem. You can't be letting non-support contract customers figuring out what that intermittent problem is and demanding a free hot fix. No sir!
"You owe me thirty-five dollars!"
"I don't have a dime."
"Didn't ask for a dime, thirty-five dollars...cash"
Other common confidential notes indicate Y2K fixes that are undocumented, or other problems that will get fixed when the hot fix is applied.
The best part was when I asked the tech "Exactly what is fixed in the security patch your are recommending?" To which I was told they don't have that information. Even after escalating MS has yet to document exactly what it fixed in any of the Outlook patches. They said they would do better with documenting patches in Outlook 2000. The best solution I got was to install the patch, check the dates on the DLL then corilate that to the file dates documented in the 150 odd hotfixes...
Long story short, I don't think it's only a matter of Opensource VS Closed source. It's how committed the is to fixing the problems and how open they are about it. MS in general lacks consistancy across product lines. In many cases it seems that patches don't come out when they are needed, but rather when the press puts a problem in the spotlight. And as long as MS pays for IT managers and CIO's to spend a week in seattle getting brainwashed I don't think that is going to change.
--
Gott'a run, time to reboot the NT box.
Please talk more about the bumblebees. These are the threads that make Slashdot a wonderful place!
Don't be too quick to judge based on the statistics Security Focus gave:
Looking at their results, the time to fix 50% of the bugs is 4 days for Red Hat and 3 days for Microsoft.
After 1 day, Microsoft fixed 42% of their bugs. Red Hat only 29%.
I know I'll probably get moderated to hell for this, but the simple fact is the "average" statistic tells nothing at all. What the results seem to be saying is that Microsoft is faster on simple bugs (probably better distribution channels) though they fail on the more difficult bugs (probably more complex code, but who can tell without the source).
Acutally, there is some discussion of this point in the article, and your interpretation of the statistics is probably more of a distortion than the "average" time presented in the article. One point specifically made in the article is that the time it actually takes to fix a bug is not well demonstrated by their statistics. The time they mention is the time between when the security hole is generally known and when it's fixed- not between when it's first discovered and fixed.
A significant percentage of the security holes are discovered, worked on, and not publicized until the bug fix is already available. It's litterally a case of "We found this hole and here's the patch," and not one of actually fixing the bug in less than a day. Apparently, about 42% of Windows holes and 29% of Linux holes fit into this category. In that respect, the statistics are much more favorable to Linux than to Microsoft. They actually mean that only about 14% (8% of all bugs v.s. 58% not announced and patched simultaneously) of holes in Windows that are publicized by someone other than Microsoft are patched within 3 days. In Linux, though, about 30% are fixed and available as RPMs within 4 days.
That also means that the average time for bugs not announced by the respective vendors is actually longer than the averages presented. The average time to fix a non-vendor announced bug is more like 27 days for Microsoft and 17 days for Red Hat. Since the non-vendor announced holes are the really scary ones- the vulnerability is known and there's no available cure- that's a more reasonable comparison.
There's no point in questioning authority if you aren't going to listen to the answers.
Is this important? IMHO, yes. Never mind corporate interest, something like the Bastille Project, OpenWall, Trustees, ACL, or even ReiserFS, could -never- have been written by 3rd parties if Linux had been closed-source, and many of these packages might never have been written at all.
100,000 developers & debuggers is a lot more than Sun, Microsoft, IBM and Apple can muster, combined. Why should it surprise anyone that such a large number can out-perform such small companies? *Note: The 100,000 is an estimate of the number of people who are on the kernel mailing list, plus the number who aren't but who play with the development kernel and will write bug reports in the event of finding any.
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
BSDI made their fix first because they had information about the bug direct from Intel (under NDA, before the bug was announced to the general public). They were forced by Intel to remove the fix they posted almost immediately because it violated the NDA. The Linux fix, IIRC, was not reverse engineered from the BSDI fix, but was a separate effort that worked in a slightly different way, without the help of Intel's additional info. As I understand it, BSDI's fix was later reengineered to behave in the same way as the Linux fix.
PS. I'm not knocking BSDI here, who I think make a great product. I'm merely correcting misinformation (at least, I think I am -- my memory's not great, and I'm too lazy to search the Linux kernel archives to find out for sure :-)
"The invisible and the non-existent look very much alike." -- Delos B. McKown
They should have, IMHO, tracked how bugs fixed made it into production environments. The chief complaint I hear now is "I have to depend on some kid in Nebraska to fix his software, or at least get the patch happening and released?" (no offense to anyone from Nebraska). I had this very conversation at a meeting where I was in a kind of cheerleader/salesman mode for Linux/OSS.
I think that ANY commercial Linux distributor should, as point one of the business model, establish a means to rapidly and loudly manage bug fixes and updates. Hell, call 'em "Service Packs" so the PHB's will understand what you're talking about. Coordinate with the developers. Try to create a "path of least resistance" for people, esp. those that don't care about technology, just that they can have it fixed. Hire a couple of people to deal directly with developers and customers.
ZOMG I WOULD LOVE TO KNOW ABOUT YOUR FEELINGS ON MACINTOSH VERSUS WINDOWS, VI VERSUS EMACS, AND HOW YOU'RE NOT A DORK
From the web page. Apologies for the formatting.
1999 Advisory Analysis
Vendor - Total Days of Hacker Recess - Total Advisories - Days of Recess per Advisory
Red Hat - 348 - 31 - 11.23
Microsoft - 982 - 61 - 16.10
Sun - 716 - 8 - 89.50
Interesting that Red Hat comes out better overall than both of the others, even though Red Hat is generally considered least secure distribution of Linux available.
FWIW, BSDI had a fix on day one or two of the F00F bug announcements. Sources reported that the BSDI fix was reverse-engineered to make a Linux fix. Days later, BSDI came up with improvements to their fix (first enabling it only on Pentium chips, later improving performance even on those systems affected). I assume the Linux folks did too.
Solaris and MS took weeks, plural, as I recall.
Conclusion? Competent engineers who care make for faster code fixes too.
(Disclaimer: I work for BSDI, but honestly, if I didn't really think their engineers were that good, I wouldn't work here either.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
I suppose this is karma bait, but assuming that the same day fixes are all "friendly" a reasonable assumption considering the inertia of companies of these sizes then the following figures come out:
Red Hat:
348 days for 22 fixes 15.8 days per fix
Microsoft
982 days for 35 fixes 28.1 days per fix
Sun
716 days for 6 fixes 119.3 days per fix
Also Red Hat had 29% (about 1/3 for those non-math inclined out there) friendly bugs, MS had 42% (~2/5) friendly bugs and Sun had 25% (1/4) friendly bugs.
Draw your own conclusions.
I thought it was interesting that although Red Hat came out on top by a decent margin, the article said that RedHat could be even faster if they payed more attention to the community.
Microsoft does amazingly well when you stop to consider what the have to work with. Their code is probably very complex due to the requirements of backwards compatibility and interaction along unusal connections between types of software. They only have a comparatively small number of programmers to be working on it at a given time, and they get the hot seat as soon as there is a problem. Everyone in the business world simultaneously expects perfection and low quality from MS, so that they can bitch about something all the time. When you consider the strains they have to deal with, they are doing very well.
I work for IBM and Sun is one of our big competitors, so I can't really say anything without risking excessive personal bias. However, I suspect that people are less inclined to roast Sun for every security breach, as there are fewer personal users than either of the two other systems.
B. Elgin
B. Elgin
"Read at your own risk; feel free to ignore."
Which brings me to an OT rant about small ISV's and (wait for it) open source:
;) Usually, the story goes like this:
:-)
The consulting company I work for (and many others) makes a lot of money fixing problems created by some dork who was too stupid to realize you can't start your own software company.
Dork writes app with some puny but vital business purpose (If unethical dork, insert "on customer's time" here.), invariably in a lame-ass tool that really should only be used to handle smallish recipe files.
Dork manages to sell to one big client where an in-law works.
Dork makes major release and generates marketing pamphlets for distro at industry trade shows, which promise that the app will have user docs and a real-database port Real Soon Now.
Meanwhile, the app really hasn't progressed beyond "almost alpha" at the one big client who is paying for "integration services".
Hapless company (my future client!) correctly decides that buy is better than build, but incorrectly assumes that there must be a decent package out there for this. Someone at hapless company randomly stumbles upon dork's marketing pamphlet or web site, and buys in.
Hapless company is promised by dork that software is ready to go, and the "integration services" should only last a month or so.
Fast forward six to eighteen months (depending on client IQ)...
Client has no system, or worse, has a crippled system and turned off or stopped paying for the old one, has spent hundreds of thousands on dork hours alone, has no docs on how to install, operate, or fix, has no source to allow me to fix or diagnose it for them, has no database schema (and often a dork-encrypted/proprietary database), is paying more thousands for staff to babysit and undo the misdeeds of the app, has dork saying that he can't spend any more time with them (assuming his number is still listed), etc.
Basically, the only good news is that hapless company didn't bring Andersen Consulting in to do the app
So, how would this have improved with Open Source?
Well, dork could have:
Had input on his app from client or consultant help,
Started a bit smaller before hapless company showed up,
Made continuous improvement to his app based on experiences at first big client,
Gotten paid the honest way, for development services, rather than for vaporware,
And eventually have built a user base big enough to handle the Hapless account smoothly.
Meanwhile (and, per RMS, more importantly), the client could have:
reviewed dork's code before betting the company on it,
brought in extra help that would really fix problems, not just clean up after them,
been assured that they could still improve the app after dork fled the country,
had a consultant provide necessary docs and schema,
and been part of a community of users that would work together to improve the app, whether dork was there to help or not.
Or, at least I've heard it could work this way...
"You can't get something for nothing." - my grandfather, on the stock market and Reaganomics.
I used to code at a small accounting software company - and saw the worst side of this issue. Starting with the totally irrational resistance of the luddite owners to posting patches on the web site, there was an economic disadvantage to releasing patches when another (due to city tax schedule releases) would be out a few weeks later - shipping 10,000 diskettes was a substantial cost for a small company. Add to this the understaffing of the testing department and tech support, and even the refusal of the owners to allow us to use point designations for patches (on the theory that it advertised how many time it took to get it right), and you can imagine the confusion and frustration. I don't (oh blasphemer!) think open source is the solution to every problem - but I'm sure that my prior employer wasn't the only sociopathic corporate greedhead torturing employee and customer alike. I gave them a lot of unsolicited legal advice (why I'm no longer working there ;-) - such as this - if a company knows of a material defect in their product and conceals such to the consumer, resulting in losses to the consumer - said greedheads are liable under the higher standards of gross-negligence, recklessness, or even intentional tort, resulting in statutory treble damages or unlimited punitive damages in some cicumstances. Of course it is common in the industry to hide bugs as long as possible, under the mistaken idea that quietly fixing the bug in a later release saves consumer goodwill by avoiding embarassment. Sometimes the lag between discovering a problem and coming up with an assured good fix is even justified. But maybe what we need is a good Pinto case - wherein the bean counters at Ford decided that the cost of adding an 8 cent plastic cap to a bolt in front of the gas tank was more than the projected number of immolation-deaths per year. Jury-award was a record at the time, nailing Ford for hundreds of millions in punitive damages to demonstrate the moral repugnance of such calculation. Something to think about, at least.
The article clearly focuses on plugging security holes, which is just a subset of the vast debugging space out there. Sure this may be the main concern of a sysadmin, but what about the 95% of us who do not have to admin for a living? Would security be our prime concern? Would an all-bugs comparison bring the same results?
Most bugs are just annoying, but some make you waste time, some lead to wrong results with varying consequences and some lead to data loss. I have never seen an advisory or a mailing list dealing with this kind of bug. I *know* there must be some, but the point is it's so easier to be informed about security gaps. Isn't anybody paying attention to overall quality or is this just a natural PR reaction to the known preference mainstream (even underground) media has for security holes, given its theft/trespass inviting nature?
It's easy to understand one's motivations to code, but we just debug because we *have* to. So, if these smaller bugs are something software can live with (mainly software planned to last only for a certain period), what would be the motivations for real debugging?
I am not saying that an intense debugging effort maens quality (maybe even the contrary is true), but if the only motivation to take corrective measures is pressure from consumers/clients who can have sensitive data compromised, then we will continue to use buggy software.
OTOH, when pride, reputation and commitment enter the scene, then we do our best to excel. So, my guess to the question in the first paragraph is that OS can have a response time orders of magnitude shorter than commercial products if we consider bugs in general, but that, if true, would be something hard to prove.
-------------------------
-------------------------
"People ask FAQs all the time". - David Allen
First, let me say this isn't a flame, troll bait non any disrespect to the open source community or Red Hat software, just my opinion.
:)
No offensive, but I don't think Red Hat is a fair repersentive of Open Source software, at least in this test here. The test is going to be on open source verus closed source in terms of "turn around" on bug fixes.
Linux/GNU which is what Red Hat is pushing, is not coded by Red Hat. It is made by out side developers and Red Hat only puts the product out. When Red Hat learns about a patch fix, they check it, package it and then up load it.
Case goes like this, a bug is found in Linux/GNU and people are informed for it. Some guru fixes the bug, posts it to ftp site. After awhile Red Hat finds the fix, reviews it, packages it, documents it, puts it on it's ftp then releases it, the announces the fix is avaiable.
The extra step of Red Hat doing this, is going to cost allot of time for the open source community. It should not count when the bug is found to when RH announces the fix, it should count from when the bug is found to when their is a working fix or work around anywhere in any form (even if it is source) on any ftp site.
Red Hat can only work with what the community gives them, say this
Day 1 - bug that opens a hole in program found in OSS
Day 2 - nothing
Day 3 - Maintainer and head programmer of XYZ announces a fix and uploads the source to ftp.
The problem is fixed, patch is avaiable to close the hole and fix the nasty bug is XYZ software.
Day 4 - nothing
Day 5 - Red Hat reviews the code
Day 6 - Red Hat tests the code
Day 7 - Red Hat packages the code
Day 8 - Red Hat documents the code and uploads it to ftp
Day 9 - Red Hat announces there is a fix avaiable for Red Hat users that are using XYZ software.
Now, yes, I know this is REALLY dramatic, but I am trying to make a point. (BTW, I got some REALLY good fishing stories). Anyway, I haven't seen a bug in a RH last more than 3-4 days at the very most (then again I don't use RH), but time of fix, to time of RH announces a fix, can be, and is drawen out. This could impact the study some what.
Neither a-less I still know Red Hat is going to kick MS ass at bug fix turn arounds, but the point it, raw OSS could do it faster and better than RH ever could. But the packages are allot nicer with RH
Again this is not a flame and I don't mean any disrespect to anyone.
"`Ford, you're turning into a penguin. Stop it.'" -THHGTTG
Sometimes I wonder how many closed source bugs have been known before the bulletin/news went public, with the fix withheld until there was a known "problem". Which can make the response time seem really nice if you're just holding onto the bugfix and releasing at the right moment.
And I'll still wonder what's with the legalese every bulletin has about "no known people being affected" by the security bug.
zlxiss
Don't be too quick to judge based on the statistics Security Focus gave:
Looking at their results, the time to fix 50% of the bugs is 4 days for Red Hat and 3 days for Microsoft.
After 1 day, Microsoft fixed 42% of their bugs. Red Hat only 29%.
I know I'll probably get moderated to hell for this, but the simple fact is the "average" statistic tells nothing at all. What the results seem to be saying is that Microsoft is faster on simple bugs (probably better distribution channels) though they fail on the more difficult bugs (probably more complex code, but who can tell without the source).
John Wiltshire
Fear: When you see B8 00 4C CD 21 and know what it means
Important bugs in important software will be fixed just about as quickly in either system: the 5 key people who know the source behave more or less the same way in open or closed source situations. It's the vastly larger number that matter to most developers. And, as more and more developers realize this and enjoy more working on open source, it won't matter what the other guys think.
Didja read the article? I know it was /.'ed -- I waited a longish time for it -- but it addressed the quality-of-fix issue pretty well.
BTW, while I don't know for sure whether you're right that many OSS projects don't regression-test such fixes first, I do know the ones I've worked on could stand some improvement...and also that it's a bit easier to regression-test a fix to a small component than a large one, and that OSS thrives on collections of small components in a way Closed Source $$$-making development doesn't (the latter favors the development of monoliths, since they represent a harder-to-reverse-engineer, and therefore steeper, wall for competitors to climb).
Also, the article made mention of various Microsoft-issued "fixes" that, themselves, had to be fixed. Didn't mention that happening with GCC, though it has happened there (not security fixes AFAIK, but the same principle applies), but the implication was that the most heavily-funded closed-source-development organization in the world doesn't seem to do to well producing correct fixes in the first place.
Practice random senselessness and act kind of beautiful.
Taco, How can you find this information interesting while refusing to release the slashdot source via CVS and following the OpenSource model which so many other applications use.
/. source.
/. bugfixes is more interesting perhaps?
Your comment says "interesting" while you still remain uninterested in your user's demands to Open the
Slow
They are a threat to free speech and must be silenced! - Andrea Chen
Fish! LipHo
I think I'd like to point Slashdot readers to a wonderful book: The UNIX Philosophy by Mike Gancarz. This book explains the tenets and values that traditional UNIX programmers have held. It goes on to list the 9 most primary tenets:
As you probably guessed, Open Source _pushes_ Tenet 6 to the forefront. Let others use your code!
Along with those primary, religiously-followed tenets, 10 lesser tenets are typically followed:
The book also mentions something very important: The Three Systems of Man. Software goes through the First system, the "innovative" cycle where one or only a few develop something revolutionary, to the Second system, where committees are formed for the software so more people can feel they're worth something contributing to the idea, and the Third system, where experts who left the scene during the 2nd stage come back to implement the idea, now that the obvious solution for it is well-known and has been walked many times.
CREDITS: This posting contains lots of quotations from, of course, the book: The UNIX Philosophy by Mike Gancarz, Copyright 1995 Butterworth-Heinemann. ISBN 1-55558-123-4 ... about $19.95. Well worth the money.
People calm down. We have our best perl coders here slaving over the Slash release. Patrick, Rob, and Pater are trying to convert their undocumented code and database schema into something that can be installed on other machines besides this one. The Slash code really is hardcoded in many ways and they are trying to unhardcode it for you now now. But they very much appreciate your flames so please keep 'em coming. =)
Sure, open source can get bug fixes out there faster... but its not like for most open source projects anyone is going out and regression testing the fixes against anything to make sure nothing else is broken by the fix, etc...
As far as speed goes, big deal... give me a fix that works.
DrLunch.com The site that tells you what's for lunch!
The assumption was that bee wings act like airplane wings. Uner those assumptions, a bee would not be able to fly. Somewhat more recently it was shown that bee wings do not work the same as airplane (or ornithoper) wings. Aside from the flapping thing, there's a basic modal difference.
Airplane and ornithopter (and bird?) wings work on laminar airflow. Try 'too hard' to fly, and you get turbulence above the wing. In other words, a stall.
The bee has a different method of dealing with this. Rather than prevent turbulence, the bee wing uses turbulence, and has a machanism for continually spinning the turbulent vortices off of the wing. In this flight mode, a given size wing has much as 50X more effective lift than in laminar mode.
I'm not sure we can apply this to the whole Linux vs Microsoft thing, other than to say that a new modality changes the whole landscape. But I guess that's what Open Source is all about. In this case, we're the bee.
The living have better things to do than to continue hating the dead.