Sure, Theo is not exactly a candidate for "Mr. Nice Guy 1999", but that can be said for a lot of people - take Tom Christiansen (please...) as an example. Many developers can change into real bastards if you push the right buttons, the same as any other person.
I'm not going to get involved in a license flamewar, so I'll just ignore the comments on the BSD license...
The BSD TCP stack is generally agreed to be very good. It has had its problems (just as the Linux stack, the Solaris stack, the WinNT (blech) stack...), but it performs very well.
For freaky devices, take a look at some of the stuff that NetBSD supports on its various platforms.
And as for the last bit about the *BSDs being "too late", the BSD kernel codebase has been around for a lot longer than the Linux kernel...
There's probably more detailed information on the FreeBSD web site, but basically what happened was:
- USB released a bunch of UNIX code that was supposedly "free". This formed the basis for 386BSD, which begat FreeBSD.
- AT&T sued USB (and also BSDi, I think) for infringement of copyright, claiming that some of the code in the original release was under AT&T copyright.
- The case was settled out-of-court, and the FreeBSD team threw out all the AT&T-tainted code and rewrote those sections.
Unfortunately, the AT&T lawsuit made corporations wary of BSD-based products, thinking that what had happened once could happen again. Luckily, most people aren't bothered by any of that now.
Use the OpenBSD mailing lists, rather than newsgroups. You'll usually get a response (if, sometimes, not exactly the kind of response you were hoping for) within a couple of hours.
FreeBSD (and the other *BSDs) may be *based* on the original BSD source, but they removed any AT&T "tainted" bits a long time ago.
The GPL is not a contract. It's a copyright license. (Yes, there IS a difference.)
Linux is *not* developed by anyone and their dog. Patches that go into the kernel are looked over quite thoroughly by a group of programmers that are just as "elite" as anyone on the FreeBSD core team.
No, this is not a PR issue. It's an issue with the way that/. posts stories. In particular, Roblimo seems to succumb to the urge to post stories with inflammatory titles ("Napster attacks open source clone") and without proper confirmation (which in this case simply means "reading the link yourself").
And as for your remark about how it was important enough for four to respond on/., what do you think he's going to do? He's probably had a whole bunch of gibbering/. monkeys piling all sorts of garbage into his mailbox about how they'll mailbomb Napster/crack Napster's server/otherwise harass Napster. It's happened before and it'll happen again...
Yeah! 'Cause we're/. readers and we're R3477Y KEWL!!!!!
Come on, get off your high horse. The problem was between gnap's author and Napster - and they settled it between them. That makes it a private matter.
While Napster might be better off going public with what they did and said (if only to clear the air), there is ABSOLUTELY no excuse for ragging on the author of gnap. I mean, what does he care whether you like the fact that he removed a letter that now has little relevance to what he is doing? Free source != full disclosure of private correspondence. F'chrissakes, it's HIS BUSINESS, so leave him alone. Sheesh.
Roblimo, at least look at the link before you post a story. There's been a number of stories on/. lately that caused a lot of problems for a few people and got a whole lot more people in an uproar simply because the story poster didn't check the linked story properly.
Golly, look at this - three ACs send similar comments calling the original poster a "fucking moron", etc., all within the space of four minutes. Looks like somebody's been busy...
No. It's perfectly possible to do bounds checking manually, but it's a real pain to do that every time you deal with unverified data, not to mention that many programmers don't have security as their main consideration. As for snprintf, the problem is not so much that it's a GNU extension (which it's really not; many systems implement similar functions, but with slightly different syntax or results), but rather that sprintf is an ANSI standard function, which means that any ANSI-compliant compiler/C library can handle it, making it the 'default'.
Once you get into the habit of bounds-checking unverified data, it's not so much of a problem, but this sort of stuff is not usually taught in CS courses...
Um... did you read the second half of my comment? Perl, sendmail and bind have to run on a HUGE range of systems. snprintf and other similar functions might either operate differently or not be available on many of those.
Don't be so quick to count SGI out. They have many very valuable technologies (cc/NUMA, XFS...), great hardware (look at their clustered stuff sometime; also, MIPS is about the cleanest chip architecture you'll ever see), and while they seem to be clutching at straws by jumping on the Linux bandwagon, you never know where that bandwagon might take them. Let's just wait and see.
I saw a documentary here in Japan about those balloons (although I think it was a dubbed American documentary). It showed a monument somewhere in the Northwest that gave the name(s) of the only person (people?) to be killed on the U.S. mainland by Japanese weaponry.
Because many programmers are either too lazy or too busy to bother with the bounds checking involved. The other common case is where they use functions which are inherently prone to buffer overflows (sprintf springs to mind), often because the more secure versions (snprintf) are not available on all systems (or, more precisely, a standard version is not available on all systems.)
Yeah, I played that game too, but it was a bit too fiddly for my tastes. Anyway, I remember reading a book (called, I think, "The Dambusters" - gee, that's a surprise) written by a journalist(?) who contacted many of the guys involved (including Barnes, who was responsible for the design of the bomb itself). It was pretty old; published in the late 60s, I think.
>Voodoo Rush is dead. It was still-born. Take it from someone who was foolish enough to actually buy one at one time.
I agree - you are a fool.
>Waah waah waahh... Look, 3dfx is still on probation in my book too, but god are you ever an ingrate. Has the Linux Way become to bitch at companies who don't do ALL your work for you?
What exactly is your point? Glide is proprietary, and 3Dfx have been very vigorous in defending it (recall the Glide wrappers for TNT cards), preventing anybody from finding a way around the restrictions on it (like lack of cross-platform support, for a start). I paid exactly the same amount of cash for my Voodoo2 card as any Windows weenie, and yet the company that made that card still insists on treating me like a second-class citizen. Does that make me an ingrate? Or did you just feel like spouting bullshit?
Um...that Mesa support for Voodoo2 etc. is just a wrapper around the Glide libraries, which with this new development don't look like they're going to be updated for much longer.
Well, yes, it's called rsh, and it's exactly that sort of idiocy that ssh was designed to prevent. Relying on either hostnames or IP addresses for authentication is about the easiest way to get your box rooted by someone that can do elementary spoofing. Don't use it.
One of the aims of Debian is to produce a distribution that is as unencumbered as possible. In this case, OpenSSH is quite obviously more "free" than the original SSH, so if you don't like that policy, I'd say it's time for you to move to a distribution like TurboLinux that has no qualms about including commercial or otherwise "less-free" software.
Sure, Theo is not exactly a candidate for "Mr. Nice Guy 1999", but that can be said for a lot of people - take Tom Christiansen (please...) as an example. Many developers can change into real bastards if you push the right buttons, the same as any other person.
I'm not going to get involved in a license flamewar, so I'll just ignore the comments on the BSD license...
The BSD TCP stack is generally agreed to be very good. It has had its problems (just as the Linux stack, the Solaris stack, the WinNT (blech) stack...), but it performs very well.
For freaky devices, take a look at some of the stuff that NetBSD supports on its various platforms.
And as for the last bit about the *BSDs being "too late", the BSD kernel codebase has been around for a lot longer than the Linux kernel...
Take a look at Slackware. I've used the standard installer to install a very basic setup on a 48MB flash card.
There's probably more detailed information on the FreeBSD web site, but basically what happened was:
- USB released a bunch of UNIX code that was supposedly "free". This formed the basis for 386BSD, which begat FreeBSD.
- AT&T sued USB (and also BSDi, I think) for infringement of copyright, claiming that some of the code in the original release was under AT&T copyright.
- The case was settled out-of-court, and the FreeBSD team threw out all the AT&T-tainted code and rewrote those sections.
Unfortunately, the AT&T lawsuit made corporations wary of BSD-based products, thinking that what had happened once could happen again. Luckily, most people aren't bothered by any of that now.
Use the OpenBSD mailing lists, rather than newsgroups. You'll usually get a response (if, sometimes, not exactly the kind of response you were hoping for) within a couple of hours.
Out of interest - in what way is OpenBSD not "intuitive"? Compared to what?
No, this is not a flame - I really want to know.
To add a few points:
FreeBSD (and the other *BSDs) may be *based* on the original BSD source, but they removed any AT&T "tainted" bits a long time ago.
The GPL is not a contract. It's a copyright license. (Yes, there IS a difference.)
Linux is *not* developed by anyone and their dog. Patches that go into the kernel are looked over quite thoroughly by a group of programmers that are just as "elite" as anyone on the FreeBSD core team.
Give it a PIII for a brain, and you have an instant heater
No, this is not a PR issue. It's an issue with the way that /. posts stories. In particular, Roblimo seems to succumb to the urge to post stories with inflammatory titles ("Napster attacks open source clone") and without proper confirmation (which in this case simply means "reading the link yourself").
/., what do you think he's going to do? He's probably had a whole bunch of gibbering /. monkeys piling all sorts of garbage into his mailbox about how they'll mailbomb Napster/crack Napster's server/otherwise harass Napster. It's happened before and it'll happen again...
And as for your remark about how it was important enough for four to respond on
Yeah! 'Cause we're /. readers and we're R3477Y KEWL!!!!!
Come on, get off your high horse. The problem was between gnap's author and Napster - and they settled it between them. That makes it a private matter.
While Napster might be better off going public with what they did and said (if only to clear the air), there is ABSOLUTELY no excuse for ragging on the author of gnap. I mean, what does he care whether you like the fact that he removed a letter that now has little relevance to what he is doing? Free source != full disclosure of private correspondence. F'chrissakes, it's HIS BUSINESS, so leave him alone. Sheesh.
Roblimo, at least look at the link before you post a story. There's been a number of stories on /. lately that caused a lot of problems for a few people and got a whole lot more people in an uproar simply because the story poster didn't check the linked story properly.
Strangely enough, 1.8 million counterfeit YKK zippers were seized in Beijing on November 8th...
Golly, look at this - three ACs send similar comments calling the original poster a "fucking moron", etc., all within the space of four minutes. Looks like somebody's been busy...
No. It's perfectly possible to do bounds checking manually, but it's a real pain to do that every time you deal with unverified data, not to mention that many programmers don't have security as their main consideration.
As for snprintf, the problem is not so much that it's a GNU extension (which it's really not; many systems implement similar functions, but with slightly different syntax or results), but rather that sprintf is an ANSI standard function, which means that any ANSI-compliant compiler/C library can handle it, making it the 'default'.
Once you get into the habit of bounds-checking unverified data, it's not so much of a problem, but this sort of stuff is not usually taught in CS courses...
Um... did you read the second half of my comment? Perl, sendmail and bind have to run on a HUGE range of systems. snprintf and other similar functions might either operate differently or not be available on many of those.
Don't be so quick to count SGI out. They have many very valuable technologies (cc/NUMA, XFS...), great hardware (look at their clustered stuff sometime; also, MIPS is about the cleanest chip architecture you'll ever see), and while they seem to be clutching at straws by jumping on the Linux bandwagon, you never know where that bandwagon might take them. Let's just wait and see.
I saw a documentary here in Japan about those balloons (although I think it was a dubbed American documentary). It showed a monument somewhere in the Northwest that gave the name(s) of the only person (people?) to be killed on the U.S. mainland by Japanese weaponry.
Because many programmers are either too lazy or too busy to bother with the bounds checking involved.
The other common case is where they use functions which are inherently prone to buffer overflows (sprintf springs to mind), often because the more secure versions (snprintf) are not available on all systems (or, more precisely, a standard version is not available on all systems.)
Yeah, I played that game too, but it was a bit too fiddly for my tastes. Anyway, I remember reading a book (called, I think, "The Dambusters" - gee, that's a surprise) written by a journalist(?) who contacted many of the guys involved (including Barnes, who was responsible for the design of the bomb itself). It was pretty old; published in the late 60s, I think.
Hmmm... I remember a Vic-20 emulator running on the C64... that would have been 1982 or so, I guess.
>Voodoo Rush is dead. It was still-born. Take it from someone who was foolish enough to actually buy one at one time.
I agree - you are a fool.
>Waah waah waahh... Look, 3dfx is still on probation in my book too, but god are you ever an ingrate. Has the Linux Way become to bitch at companies who don't do ALL your work for you?
What exactly is your point? Glide is proprietary, and 3Dfx have been very vigorous in defending it (recall the Glide wrappers for TNT cards), preventing anybody from finding a way around the restrictions on it (like lack of cross-platform support, for a start). I paid exactly the same amount of cash for my Voodoo2 card as any Windows weenie, and yet the company that made that card still insists on treating me like a second-class citizen. Does that make me an ingrate? Or did you just feel like spouting bullshit?
Why don't you take some time out to grow up.
Um...that Mesa support for Voodoo2 etc. is just a wrapper around the Glide libraries, which with this new development don't look like they're going to be updated for much longer.
Why am I somewhat less than dazzled by drivers that (A) do not support Voodoo Graphics/Rush/2 cards, and (B) do not support the full Glide API?
Basically that means that I can say bye-bye to playing any new 3D games in the future on my Voodoo2. For some reason, that really pisses me off.
Well, yes, it's called rsh, and it's exactly that sort of idiocy that ssh was designed to prevent. Relying on either hostnames or IP addresses for authentication is about the easiest way to get your box rooted by someone that can do elementary spoofing. Don't use it.
One of the aims of Debian is to produce a distribution that is as unencumbered as possible. In this case, OpenSSH is quite obviously more "free" than the original SSH, so if you don't like that policy, I'd say it's time for you to move to a distribution like TurboLinux that has no qualms about including commercial or otherwise "less-free" software.
I presume you intended to write "wouldn't" instead of "would" in your second sentence...