Beta
×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

The 25-Year-Old BSD Bug

Soulskill posted more than 6 years ago | from the better-late-than-never dept.

Bug 213

sproketboy writes with news that a developer named Marc Balmer has recently fixed a bug in a bit of BSD code which is roughly 25 years old. In addition to the OSnews summary, you can read Balmer's comments and a technical description of the bug. "This code will not work as expected when seeking to the second entry of a block where the first has been deleted: seekdir() calls readdir() which happily skips the first entry (it has inode set to zero), and advance to the second entry. When the user now calls readdir() to read the directory entry to which he just seekdir()ed, he does not get the second entry but the third. Much to my surprise I not only found this problem in all other BSDs or BSD derived systems like Mac OS X, but also in very old BSD versions. I first checked 4.4BSD Lite 2, and Otto confirmed it is also in 4.2BSD. The bug has been around for roughly 25 years or more."

cancel ×

213 comments

Sorry! There are no comments related to the filter you selected.

Many eyes make bugs shallow... (-1, Flamebait)

pclminion (145572) | more than 6 years ago | (#23369184)

My ass. There are arguments for open source. The shallow bugs argument is not one of them.

Re:Many eyes make bugs shallow... (3, Insightful)

Anonymous Coward | more than 6 years ago | (#23369238)

Isn't it? The bug WAS found, wasn't it?

Re:Many eyes make bugs shallow... (3, Insightful)

TheLink (130905) | more than 6 years ago | (#23369782)

Sure it's found, but after 20+ years? That's not what I call a good approach.

"many eyes make bugs shallow" is equivalent to the "infinite number of monkeys..." thing.

In my experience it's better to have quality than quantity when it comes to the eyes used for finding bugs.

Any idiot can tell you about obvious bugs, and it's kind of waste of time to see 1 million duplicate bug reports, because it's too slow to search through 100 million other bugs (with dupes) for dupes ;).

For UI stuff, you get the naive (as in not yet unexposed to your evil software ;) ) users in and watch them, and even then you MUST have _trained_ eyes to watch them. The trained eyes can often spot problems the naive users are experiencing - the naive users may not even realize they are experiencing problems or realize what is wrong...

Re:Many eyes make bugs shallow... (2, Interesting)

morgan_greywolf (835522) | more than 6 years ago | (#23369910)

Hmmm....if the bug was found in 4.2BSD, then how do we know that that bug was not also in original AT&T UNIX that 4.2 BSD is derived from? One could always look in the source released by Caldera (now known as "The SCO Group") some years back.

Re:Many eyes make bugs shallow... (4, Insightful)

fudoniten (918077) | more than 6 years ago | (#23370090)

BSD has been checked over by 'quality' eyes--when it was used as the basis of NeXT/OSX, for example. They missed it too.

If the code wasn't open (i.e. if there weren't many eyes), this bug would have remained forever, or at least until the code was dumped.

Re:Many eyes make bugs shallow... (5, Insightful)

DannyO152 (544940) | more than 6 years ago | (#23369246)

How many "eyes" were watching BSD systems use Samba for a DOS filesystem? Seems to me, someone saw behavior and exactly because it was open source, looked into it, found the coding error and filed a bug report. It will be fixed, because everyone now knows about this, and that too is a side effect of open source, even if it's related to the politics.

Re:Many eyes make bugs shallow... (4, Insightful)

garett_spencley (193892) | more than 6 years ago | (#23369252)

From the sounds of it, this was a bug that was not triggered very often. When it was finally triggered, investigated and fixed the person who found it released the info publicly, thanks to the beauty of Open Source, and everyone affected, commercial entities and FOSS users using the code alike, benefited. If this were a proprietary system that were licensed out to various companies stricken by NDAs etc. it's quite likely that if one company discovered the bug the others would never learn about it.

Re:Many eyes make bugs shallow... (5, Interesting)

Goaway (82658) | more than 6 years ago | (#23369298)

Except that the bug had been triggered many times before, seeing as how Samba had code in place to work around it.

Re:Many eyes make bugs shallow... (1)

jimicus (737525) | more than 6 years ago | (#23369594)

Except that the bug had been triggered many times before, seeing as how Samba had code in place to work around it.
Yeah, I noticed that. Had the Samba team not reported the bug upstream? Most of them seem to be a fairly professional bunch, it seems unlikely they'd spot a bug like this and just code a workaround without at least a quick email to one of the BSD mailing lists.

Re:Many eyes make bugs shallow... (4, Insightful)

Goaway (82658) | more than 6 years ago | (#23369760)

Perhaps they didn't feel like doing the "no, it's supposed to work like that, you're wrong" dance.

Re:Many eyes make bugs shallow... (5, Informative)

TheRaven64 (641858) | more than 6 years ago | (#23369290)

This bug has been around for a long time, but is only visible if you have large directories and delete files from them in between calls to readdir and seekdir. This is quite uncommon behaviour, and was incredibly uncommon 25 years ago when filesystems were much smaller and directories almost never contained enough files to require more than one or two disk blocks to store the directory.

When the Samba people found it, they decided to just code a work-around and not bother to report it to any of the BSD teams. If they had done, it would probably have been fixed in 22 years.

Now that it has been fixed in OpenBSD, the change can easily be taken and incorporated into FreeBSD, NetBSD, DragonFlyBSD and Darwin.

Re:Many eyes make bugs shallow... (4, Interesting)

pclminion (145572) | more than 6 years ago | (#23369326)

This bug has been around for a long time, but is only visible if you have large directories and delete files from them in between calls to readdir and seekdir.

But that's exactly my point, isn't it? The bug was only "visible" through its behavior, not its manifestation in code. The shallow bugs argument basically says that if enough people stare at the code, they will find the bugs. Clearly that did not happen here.

Whether the bug fix can propagate rapidly has nothing to do with what I'm talking about. I'm not trying to disparage the concept of open source, I'm arguing that the shallow-bugs argument should be rejected.

Re:Many eyes make bugs shallow... (4, Insightful)

Peganthyrus (713645) | more than 6 years ago | (#23369430)

You see what you're looking for, most of the time. This sounds like a subtle bug that you're not going to find until you go looking for it; it's hard to invoke under normal usage patterns. Nobody stared at that code looking for this problem until now. But if it was closed source, the guy who fixed it wouldn't have been able to look at it and find the problem.

A quick googling of "many eyes make all bugs shallow" brings me the more complete statement that adage is simplified from: "Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone." (Linus via ESR). Clearly this 25-year-old bug is one of the exceptions that calls for the 'almost'.

Re:Many eyes make bugs shallow... (5, Insightful)

Derek Pomery (2028) | more than 6 years ago | (#23369450)

Erm. That's not what "many eyes make bugs shallow" means.
Well. Just reading the source is part of it, but not all.
Fact is, if I run into odd behaviour when testing/using - if the source is available I can read it, I can breakpoint.
I cannot do that with a binary.

So yes. Things did occur as they were supposed to. Someone found something odd, they were able to look at code in question, and fix it.

The shallowness is the fact that there is a direct connection between the thousands of testers/users and the code in question.
Instant turnaround. No "user reports behaviour in detailed fashion, including testcase, to some corporate e-mail address, and maybe it eventually gets a to a developer three layers down who may be able to figure it out and fix it if he has the time"

Re:Many eyes make bugs shallow... (1)

bsantos (655278) | more than 6 years ago | (#23369528)

I don't think it should be rejected, but taken as part of the set of advantages OSS has. After all that one argument of many, which sometimes applies others doesn't. There's bugs you have in the code itself and others in the way the code is supposed to work, the first you can catch by looking at the code, the second is more difficult if you don't know what the code intends to do, or don't have lots of experience with the language and paradigm. The argument that many eyes make bugs in the code shallow isn't a rule that could apply to bugs in the program itself.

Re:Many eyes make bugs shallow... (2, Insightful)

KGIII (973947) | more than 6 years ago | (#23369858)

The shallow bugs argument basically says that if enough people stare at the code, they will find the bugs. Clearly that did not happen here.
I am not an open source zealot or anything, in fact I'm more inclined to use proprietary software at home and open source, almost exclusively, for my business. I say this so that I'm clear about my disclosing my personal views. (In other words, I believe in all things moderation and think zealotry is absurd and I probably shouldn't be confused with an open source zealot or even an advocate.)

However... You are mistaken. Clearly that DID happen here. That is exactly what happened. It took a long time, granted, but it was found, it was fixed, and (seeing as no one was really bothered by it too much) it was even done in a "timely manner." (Albeit a very long time but it didn't seem to impact anyone to any great length.)

The bug was found, the code was open, the bug was fixed. Hell, it isn't even newsworthy. It's just a squished bug that had no real impact in the majority of people's experiences. The impact was so small that people coded around it, so be it. Open source doesn't even demand that it be bug free. Coding around an existing bug is perfectly okay (I think). Fixing the bug may have taken valuable developer time away from their core projects for all I know. Either way, it was found, it was fixed, and because of the open source nature of the software these two things were possible.

Re:Many eyes make bugs shallow... (1, Funny)

ahem (174666) | more than 6 years ago | (#23370208)

My parent said:


(In other words, I believe in all things moderation and think zealotry is absurd and I probably shouldn't be confused with an open source zealot or even an advocate.)


Sounds like you're a bit of a moderation zealot...

Re:Many eyes make bugs shallow... (2, Informative)

kithrup (778358) | more than 6 years ago | (#23369426)

seekdir and readdir are unreliable when you're modifying the directory being read. The API requirement is that readdir return each directory entry that existed at the time the directory was opened exactly once. In the traditional UNIX implementation, the directory is simply a sequential stream of bytes; this is pretty easy -- you can simply lseek to the position that telldir returned. However, other systems don't use something that simple -- Mac OS X, for example, uses a B-Tree for the catalog file. Worse, they use a single catalog file for the entire filesystem's catalog, meaning that any modifications (adding, removing, or renaming files anywhere) causes the layout to change.

And telldir only returns a long, which -- in most implementations -- is smaller than off_t, so a simplistic implementation can have some problems. Of course, having a directory that's larger than 4GBytes could result in some other problems 8-).

Re:Many eyes make bugs shallow... (1)

JoeBuck (7947) | more than 6 years ago | (#23369996)

You write: "This bug has been around for a long time, but is only visible if you have large directories and delete files from them in between calls to readdir and seekdir." Go back and read the link: the bug can be reliably reproduced in a directory with only 27 files, if the right file is deleted (the file whose directory entry is the first file in the second block). You assume that the Samba people didn't report the bug to any BSD people, but that's unclear. The problem is that they didn't have a reproducible way of demonstrating the bug, which tends to lead to responses like "we don't believe you" from upstream developers.

Re:Many eyes make bugs shallow... (4, Insightful)

InvisblePinkUnicorn (1126837) | more than 6 years ago | (#23369408)

This is like saying global warming either does exist because today was the hottest on record, or does not exist because today was the coldest on record. Why are these analogous? Because in both situations, you're only considering one data point, which does not even begin to indicate a trend.

Re:Many eyes make bugs shallow... (1)

pclminion (145572) | more than 6 years ago | (#23369618)

"Many-eyes-shallow-bugs" == absolute statement "Many-eyes-yet-bug-wasn't-found" == clear contradiction of absolute statement.

Re:Many eyes make bugs shallow... (3, Insightful)

AndGodSed (968378) | more than 6 years ago | (#23369960)

True, but you misquoted the statement. The correct statement is not absolute. It reads, and I quote a guy called Linus:

"Given a large enough beta-tester and co-developer base, almost every problem will be characterized quickly and the fix will be obvious to someone."
I am sure you will agree that the correct statement sans flamebait modifications does not warrant a "clear contradiction" as many detractors of FOSS who are jumping at this opportunity to point out a example of a fixed bug that was not necessarily a security risk and saying "see, the OSS model is clearly flawed! BSD has a 25year old bug that was only fixed now!"

Heck, how many other bugs have been fixed over the years?

These detracting arguments smack of FUD mongering...

Re:Many eyes make bugs shallow... (2, Interesting)

pclminion (145572) | more than 6 years ago | (#23370030)

I am sure you will agree that the correct statement sans flamebait modifications does not warrant a "clear contradiction" as many detractors of FOSS who are jumping at this opportunity to point out a example of a fixed bug that was not necessarily a security risk and saying "see, the OSS model is clearly flawed! BSD has a 25year old bug that was only fixed now!"

Take off your paranoid hat. Holy crap. I am an open source author myself. I just have always hated this particular argument.

Re:Many eyes make bugs shallow... (1)

AndGodSed (968378) | more than 6 years ago | (#23370060)

Well then I was mistaken. I did not react out of paranoia however.

yeah, sure (1)

someone1234 (830754) | more than 6 years ago | (#23369468)

I wonder how it still remained in MacOSX :>

Re:yeah, sure (3, Insightful)

AndGodSed (968378) | more than 6 years ago | (#23369974)

Excellent point.

This is touted as a slip up (or flaw) in the Open Source model of doing things, yet a proprietary software developer, and one of the largest mind you, failed to spot this completely.

Re:Many eyes make bugs shallow... (1)

HiThere (15173) | more than 6 years ago | (#23369710)

Were you to claim it was an overstatement, I'd agree. That doesn't seem to be what you're claiming.

"Many eyes make all bugs shallow" is clearly wrong, in detail. There do exist bugs that can't be traced that way, e.g. (The one I'm thinking of is the infamous C compiler that was jiggered to insert a binary mod into itself whenever it recompiled itself.)

However, being wrong in detail isn't the same as being wrong in principle. Very few statements that use an un-circumscribed "all" are actually TRUE!!!, but that doesn't keep them from being true. You just need to use a bit of sense in interpreting them. Once you do, you realize that the "Many eyes..." statement is a good first approximation to the truth, and possibly a good second approximation. (I.e., it's pretty close to always true.) Depending on how you define many and shallow, of course. With proper (and reasonable) definitions I could make an argument that this particular case was, indeed, an example of that rule working out in practice just as it claims to work. (My chosen approach would be to adopt a historical perspective, but there are other approaches that would also work.)

OTOH, if you adopt a definition of many == three or more, and shallow == found within a day then the rule is a massive failure. To me this would reveal more a misunderstanding of the rule than a defect in it, but it would be a legitimately defensible interpretation of it from the viewpoint of simple English rules of speech.

Wait... Would you ever hit this? (0, Redundant)

ivan256 (17499) | more than 6 years ago | (#23369194)

Isn't the first entry usually '.'? How often would that be deleted?

Re:Wait... Would you ever hit this? (4, Funny)

ivan256 (17499) | more than 6 years ago | (#23369230)

Of course, now that I've R'd the FA, I understand that it's the first entry in the block (of which a directory with a sufficient number of files would have multiple), and not the first entry in the directory. Kindly ignore my previous response... Nothing to see here...

Re:Wait... Would you ever hit this? (0)

njcoder (657816) | more than 6 years ago | (#23369582)

Hahaha, you were modded insightful and interesting.

Re:Wait... Would you ever hit this? (0)

Namlak (850746) | more than 6 years ago | (#23370156)

Kindly ignore my previous response
What previous response?

Re:Wait... Would you ever hit this? (5, Informative)

TheRaven64 (641858) | more than 6 years ago | (#23369258)

The first entry in a disk block, not the first entry in a directory. Each disk block is 512 bytes, so you can store around 30 files in there with shortish file names (each stores the name, the inode and a cumulative free space counter). For large directories you have around a one in 30 chance that the deleted file will be the first one in a block. Delete a dozen files from a large directory and there's a pretty large chance you'll hit this bug.

Re:Wait... Would you ever hit this? (2, Funny)

youthoftoday (975074) | more than 6 years ago | (#23369268)

an existential philosopher turned empiricist perhaps?

Re:Wait... Would you ever hit this? (1)

solafide (845228) | more than 6 years ago | (#23369270)

If you RTA, you'd see that it's a bug where the first entry in a block is deleted. If a directory spans more than one block, there are multiple first-entries-for-a-block, not just '.'. Thus, in the article's example, in a 28-file directory, deleting file 25 and seeking to file 26 would return file 27.

more proof (5, Funny)

Anonymous Coward | more than 6 years ago | (#23369210)

...of the superiority of Microsoft.

Re:more proof (3, Funny)

rubycodez (864176) | more than 6 years ago | (#23369222)

that's funny, since Microsoft has used gobs of BSD code over the years

Re:more proof (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23369354)

Woooooooooooooooooooooooooshhhhhh!

The joke flies right over your head at the speed of sound!

Re:more proof (2, Insightful)

Keyper7 (1160079) | more than 6 years ago | (#23369318)

Unless you present some proof that this never happened in a Microsoft product, you have nothing.

I'm not saying it did, but you have to take Microsoft's word that it didn't, and no more evidence than that.

I'd rather go with the more transparent option, thank you.

Re:more proof (2, Funny)

kabloom (755503) | more than 6 years ago | (#23370028)

Of course. Because they keep 25 year old bugs as compatibility features, while we break compatibility and fix them.

the developers probably knew about it (5, Funny)

Anonymous Coward | more than 6 years ago | (#23369214)

but they had more important things to do. At least until Balmer started throwing chairs.

Re:the developers probably knew about it (1, Informative)

Anonymous Coward | more than 6 years ago | (#23369522)

Modded Offtopic?

Marc Balmer uncovered the bug.

Marc Balmer confirmed the bug was sitting in the code of all BSDs (including Mac OS X), including a lot of old releases.

Marc Balmer confirmed the bug was already in 4.2BSD, released in August of 1983.

Mildly amusing, so +1 Funny in my book.

Re:the developers probably knew about it (4, Funny)

Cheapy (809643) | more than 6 years ago | (#23370138)

At that point they had far more important things to do.

Such as dodging chairs.

They actually do... (0)

Anonymous Coward | more than 6 years ago | (#23369228)

After all, someone closed a 25-year bug... how many hidden bugs will remain that way in os/2 warp? windows 95? other proprietary systems?

And sometimes, people who collaborate on a given open-source project are from different parts of the world and not subjected to corporate rules. So when you get creative people with different mindsets and no reason to pull back their punches when they see something wrong, you have quality.

Re:They actually do... (4, Insightful)

Goaway (82658) | more than 6 years ago | (#23369266)

After all, someone closed a 25-year bug... how many hidden bugs will remain that way in os/2 warp? windows 95? other proprietary systems?
Er, this bug was in current versions, too, you know.

Now it's time for a little housekeeping (1)

rocjoe71 (545053) | more than 6 years ago | (#23369232)

Will we be hearing alot of "How did that get there?" as versions of BSD get patched up?

That is, wouldn't somebody in the past quarter century have exploited this bug to hide a malicious executable file or two?

Not sayin', just wonderin'...

Re:Now it's time for a little housekeeping (4, Informative)

TheRaven64 (641858) | more than 6 years ago | (#23369416)

It doesn't let you hide an executable. Something like ls, which iterates over the directory entries, will see the executable. It's only things which maintain an internal cache of directory entries which will have the problem. The 'fix' for Samba was to turn off directory caching and this made all of the files visible again.

Re:Now it's time for a little housekeeping (2, Insightful)

hitmark (640295) | more than 6 years ago | (#23369440)

i dont think its easy to trigger this reliably enough to use it to hide files.

See? SEE? (4, Funny)

Frosty Piss (770223) | more than 6 years ago | (#23369274)

See? See?

This is the power of Open Source!

With all those eyes looking at the code, stuff like this gets ID'd and fixed LICKITY SPLIT!

(runs and hides)

Re:See? SEE? (4, Insightful)

Spy der Mann (805235) | more than 6 years ago | (#23369316)

No need to run and hide. The only reason the bug's so old is because the OS is that old. And remember that 25 years ago, we didn't have web 2.0.

In comparison, Microsoft has been around for what... 20 years? And who knows what bugs in Windows are there, lurking, just waiting to bite us?

Old Code (2, Insightful)

Frosty Piss (770223) | more than 6 years ago | (#23369376)

One would think that after all these years, Windows source would have leaked, Microsoft being what they are. Everyone knows that your most secret secrets are the first things to leak... And yes, I've seen the "secret MS code" joke.

Re:Old Code (1)

swb (14022) | more than 6 years ago | (#23369692)

Hasn't Windows source code leaked? I seem to recall a leak of either 2000 or XP a couple of years ago, although it wasn't complete and not readily buildable, IIRC.

Re:Old Code (1)

rubycodez (864176) | more than 6 years ago | (#23369706)

windows 2000 and NT source had been leaked to usenet in 2004

Re:Old Code (2, Funny)

gweihir (88907) | more than 6 years ago | (#23370132)

Indeed. Not surptisingly nobody was really interessted.

Re:See? SEE? (0)

Anonymous Coward | more than 6 years ago | (#23369388)

we don't have "web 2.0" now, because it doesn't exist. if you want to give version numbers that really doesn't have version numbers anyway, we are more like 1.2.

it's nothing more than a bullshit buzzword with no real meaning.

Re:See? SEE? (1)

neumayr (819083) | more than 6 years ago | (#23370202)

Really?
Buzzwords are not entirely derived of meaning, it's just that they don't convey a clear message, more of an idea. Granted, most of the time, that idea has a lot of different interpretations, making the buzzword nearly meaningless.
But you wouldn't really argue that when someone calls something "Web 2.0", that there's no way to know what is meant, would you?

Re:See? SEE? (0)

Anonymous Coward | more than 6 years ago | (#23369838)

Is this a good time to make a Mozilla WONTFIX joke?
No?
Alrighty then. /vote yes +1

Sometimes you need... (0)

Anonymous Coward | more than 6 years ago | (#23369304)

Sometimes you need some heavier unit tests just to pick up little bugs like these. Just because everyone assumes code is correct and a few mission critical systems have been working fine on it, doesn't mean some corner case won't blow the world away tomorrow.

Re:Sometimes you need... (1)

j-pimp (177072) | more than 6 years ago | (#23369398)

Sometimes you need some heavier unit tests just to pick up little bugs like these.

Was that flamebait aimed at stirring up responses from all the people that were thinking about looking into unit tests until they got permission from Knuth to not use them in his recent interview? BTW, this bug didn't exactly blow the world away, and this is the sort of heavy load testing that you don't have time to run in your "make tests" phase or your xUnit derived unit testing platform.

BSD is dying! (0, Offtopic)

Doug52392 (1094585) | more than 6 years ago | (#23369306)

It is official. Netcraft now confirms: *BSD is dying Get over it and move on with your lives.....

Trac (5, Funny)

extirpater (132500) | more than 6 years ago | (#23369348)

Bug tracking software missed this because it's bug #1. lol.

Re:Trac (1, Redundant)

v1 (525388) | more than 6 years ago | (#23369542)

or because it was bug #0 and someone started keeping track of them at #1.

(hate those boundary bugs!)

Re:Trac (4, Funny)

chooks (71012) | more than 6 years ago | (#23369802)

I program in FORTRAN, you insensitive clod!

Samba knew, but didn't pass it on? (4, Insightful)

quarrel (194077) | more than 6 years ago | (#23369362)

The most telling thing in TFA for me was that the bug had been identified by the Samba team and a workaround implemented for Samba.

Surely both the samba communities and the *BSD communities are active enough that this could have been passed on for further investigation by the *BSD crowd? (Sure, samba probably would still need a workaround, particularly given the long uptimes and widespread deployment of *BSDs)

I know nothing of the devs at Samba and *BSD, but seems a bit strange. Perhaps they did try..

Meanwhile, congrats to Marc on fixing a bug. One of the most touted benefits of open source (whatever your license) code.

--Q

Re:Samba knew, but didn't pass it on? (1, Interesting)

Anonymous Coward | more than 6 years ago | (#23369556)

It never takes very long for the BSD zealots to start finger pointing. Yes, folks, BSD had a bug that was there for 25 years that many people knew about and noone bothered to fix, but it is SAMBA's fault for not doing.... what exactly.... to force the theo the rats of the world to acknowledge it? You guys really are shamelessly arrogant.

Re:Samba knew, but didn't pass it on? (-1)

Anonymous Coward | more than 6 years ago | (#23369650)

Many people did NOT know about the bug otherwise it would have been fixed. You stupid idiotic douche bag.

Re:Samba knew, but didn't pass it on? (1)

Grey_14 (570901) | more than 6 years ago | (#23369856)

Theo, Is that you?

Re:Samba knew, but didn't pass it on? (0)

Anonymous Coward | more than 6 years ago | (#23370140)

no, the you would have been called a hypocrite/asshole

Re:Samba knew, but didn't pass it on? (0)

Anonymous Coward | more than 6 years ago | (#23370170)

People like you are the reason why, despite a solid technical foundation, BSD sucks ass [samba.org] . Finger point at Samba all you want. Whine, bitch, moan and complain about other people doing everything except sending you a stripper-gram to inform you of the bug. Your attitude is exactly the reason why so many of us have left BSD behind and moved on to better things.

Re:Samba knew, but didn't pass it on? (3, Insightful)

irc.goatse.cx troll (593289) | more than 6 years ago | (#23369724)

I wouldn't pass it on either if it meant having to deal with Theo.

Re:Samba knew, but didn't pass it on? (5, Interesting)

id10ts (1147541) | more than 6 years ago | (#23369964)

Yes, Samba did pass on what it found and it appears they were promptly shot down by someone on the *BSD side.

The Samba e-mail archives contain a message from over 3 years ago [samba.org] , but it doesn't give attribution to the *BSD source.

The Samba Bugzilla also has a bug reported more recently [samba.org] involving the same issue. Reading through the bug history, you can see there was one FreeBSD dev involved in the bug discussion, and he referenced a prior conversation between Tridge (Samba) and PHK (FreeBSD) where PHK said there was no bug in FreeBSD.

Re:Samba knew, but didn't pass it on? (0)

Anonymous Coward | more than 6 years ago | (#23370018)

Even if they did try, Samba would still need the workaround. Not all BSD releases are updated or even have source published.

Would this be a "Critical" or "Important?" (2, Funny)

FurtiveGlancer (1274746) | more than 6 years ago | (#23369368)

If no one has cared enough to fix it for 25 years, I'm guessing this should be rated as "inconsequential."

Must have been a really slow news day at OSNews.

bug blassification, side effects and Insults! (4, Funny)

JonTurner (178845) | more than 6 years ago | (#23369634)

3 thoughts on this:

1. I think this bug would be classified "archeological".

2. The question now is what happens to the Samba work-around patches. Now that the bug is fixed, do the patches cause a side-effect (i.e. "a new bug")?

3. This gives rise to a new meme of nerd insults. "You call yourself a programmer? Why I've fixed bugs older than you!" Of course, only one man is entitled to use that line.

Re:bug blassification, side effects and Insults! (1)

FurtiveGlancer (1274746) | more than 6 years ago | (#23369806)

1. Excellent point! Wish I'd thought of it before submitting.

2. It's still a feature that now will need remediation. Argues well against using work-arounds for long periods, rather than fixing the root problem. Think ITIL or Y2K.

3. Actually others have solved older bugs, they just haven't had a slashdot article with their names in light. Think COBOL/FORTRAN.

Re:Would this be a "Critical" or "Important?" (2, Insightful)

Goaway (82658) | more than 6 years ago | (#23369752)

Samba cared enough to implement a workaround.

GNAA Penis Rocket To The Moon Project (-1, Troll)

Anonymous Coward | more than 6 years ago | (#23369390)

GNAA Penis Rocket To The Moon Project - $5Million Received! - Our Goal: $1 Billion

Dear friends,

We're getting closer!

http://www.gnaa.us/penis-rocket-to-the-moon-project.html [www.gnaa.us]

Re:GNAA Penis Rocket To The Moon Project (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23369496)

Why is this not modded funny?

Re:GNAA Penis Rocket To The Moon Project (-1, Offtopic)

Anonymous Coward | more than 6 years ago | (#23369848)

The link goes nowhere. I'm disappointed.

BSD is Dying! (4, Funny)

Doc Ruby (173196) | more than 6 years ago | (#23369420)

If you define BSD as a collection of bugs, this story proves that BSD is dying.

Re:BSD is Dying! (3, Funny)

MillionthMonkey (240664) | more than 6 years ago | (#23369796)

No, this story proves that BSD is dying because there was a bug in it and no complaints were heard for 25 years.

Re:BSD is Dying! (-1, Flamebait)

Grey_14 (570901) | more than 6 years ago | (#23369870)

hey sure, and while we're randomly defining things to make stupid meme jokes, how about we define you as a goddamn idiot and therefor in soviet russia, you ARE THE JOKE!

Re:BSD is Dying! (-1, Flamebait)

Doc Ruby (173196) | more than 6 years ago | (#23369982)

How about fuck you?

Anyone with enough competence in BSD to have an opinion about it worth caring about would be able to tell that if BSD isn't defined as a collection of bugs, then BSD isn't dying.

A sense of humor would also suffice instead. Likewise you fail it.

Must have been a CockRoach. (1)

arthurpaliden (939626) | more than 6 years ago | (#23369454)

After all it had survived for 25 years. Are we sure that it really is dead and did not just scurry away when the light was shined on it?

Can Marc look at ... (0)

Anonymous Coward | more than 6 years ago | (#23369484)

Can Marc look at that file dialog in GNOME? That's been around for a while as well ...

After this long (4, Funny)

Hawkeye477 (163893) | more than 6 years ago | (#23369486)

After this long would this not be considered a feature? :)

Re:After this long (1)

Ibn al-Hazardous (83553) | more than 6 years ago | (#23370068)

Obviously, that was the approach taken by Samba (thus the workaround). What does this imply?
That too long time messing with MS products/protocols makes you treat all software as if it works like MS software (ie it makes you a bit soft in the head).

Should it be fixed? (5, Insightful)

CaroKann (795685) | more than 6 years ago | (#23369520)

Considering how old this bug is, and how much work-around code probably exists as a result, I wonder how many new bugs this bug fix will create.

Re:Should it be fixed? (2, Insightful)

iamhigh (1252742) | more than 6 years ago | (#23369768)

Yeah, imagine if you had, like 90% market share, and your OS supported everything from 8 bit games to 64 bit collaborative applications... then it would be a real bitch to fix stuff.

Re:Should it be fixed? (1)

andi75 (84413) | more than 6 years ago | (#23370054)

What the parent is hinting at is that Microsoft knows about a LOT of bugs in their operating system, but decided not to fix them, because that would break many many application already working around these bugs.

Re:Should it be fixed? (4, Informative)

irc.goatse.cx troll (593289) | more than 6 years ago | (#23369774)

Most workarounds involve disabling caching. As a result they could re-enable caching for a performance increase, but leaving it off should have no iller effects with the patch than without.

Known defect? (2, Interesting)

oso (7152) | more than 6 years ago | (#23369596)

What really intrigues me is that this had been discovered, years earlier, by the Samba folk.
Did the Samba folk not tell the BSD folk of the issue?

Please tag "stumbled" (0)

Anonymous Coward | more than 6 years ago | (#23369610)

It is not coincidental that I happened to find this page on stumbleupon hours before it appeared on the slashdot front page. Is there such a grave deficiency of technology news that slashdot has to rely on social bookmarking sites to generate news-worthy material??

Re:Please tag "stumbled" (1)

sveard (1076275) | more than 6 years ago | (#23369756)

This is not CNN. News isn't supposed to appear only minutes after breaking. Who cares if it takes some time (only a few hours in this case!) for news to propagate across websites.

Excuses Excuses... (1)

wolferz (1173471) | more than 6 years ago | (#23369690)

I see a lot of people making excuses for this bug not being fixed sooner. If this happened to Windows the comments would be over flowing with "MS SUCKS" and "Switch to Linux/BSD" comments. Yet, when it happens to BSD the comments are more along the line of "this is no big deal..." and "so what... it still got fixed didn't it?"

Hi Kids! Today's word is: Hypocrisy!

I don't disagree that open source is less prone to have bugs that dont get fixed for long periods of time. Nor do I disagree that open source bugs are easier to find fixes for. However... this seems to indicate that the difference between open source and closed source in this regard is not as big as open source proponents have been trying to claim. All the excuses and explanations in the world wont change that this is EXACTLY what open source proponents have been saying wouldn't happen with open source.

This couldn't have happened with Linux... (2, Insightful)

Baumi (148744) | more than 6 years ago | (#23369912)

...because currently, no Linux bug could possibly be older than roughly 17 years [wikipedia.org] . :-)

-1 Offtopic (0)

Anonymous Coward | more than 6 years ago | (#23370014)

What the fuck is slashdot doing popping up "please take a survey" windows on me?

Re:-1 Offtopic (1)

Tranzistors (1180307) | more than 6 years ago | (#23370174)

Aren't you, by any chance, running windows ;)

Long live the Code (5, Interesting)

GuldKalle (1065310) | more than 6 years ago | (#23370092)

Am I the only one who thinks it's quite impressive to have 25 year old code still being used and employed on new systems?

There's a bug in a piece of Microsoft software (-1, Flamebait)

mr_lizard13 (882373) | more than 6 years ago | (#23370126)

that's 23 years old.

It's called Windows.
Load More Comments
Slashdot Login

Need an Account?

Forgot your password?