Beta

Slashdot: News for Nerds

×

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!

Kernel Trap Interview with Theo de Raadt

Hemos posted more than 8 years ago | from the the-man-speaks dept.

181

An anonymous reader writes "KernelTrap has an insightful interview with Theo de Raadt, creator of OpenBSD. The wide-ranging interview focuses first on the past few years of OpenBSD development, then moves on to the recently released OpenBSD 3.9. De Raadt talks about how binary blobs threaten free software, and how OpenBSD developers work to reverse engineer them. He also talks about the future of OpenBSD, his views on Linux, and why developing truly free software is so important to him."

cancel ×

181 comments

Blobs eh (-1, Offtopic)

GigsVT (208848) | more than 8 years ago | (#15246402)

If you feed them jellybeans, they will do useful things for you.

Re:Blobs eh (2, Funny)

A Boy and His Blob (772370) | more than 8 years ago | (#15246895)

Indeed, I can confirm this.

Dang it... (-1, Offtopic)

DaHat (247651) | more than 8 years ago | (#15246429)

I was hoping he'd say something about his thoughts on Linus' calling the Mach and FreeBSD people 'incompetent idiots [kerneltrap.org] '.

Sure he's an OpenBSD guy... but I'm sure he's got an opinion on it.

Theo (5, Funny)

Anonymous Coward | more than 8 years ago | (#15246515)

Weird... was Theo having a bad day? He's always seemed like such a nice guy, but in this interview he really comes off like a total a-hole... very un-Theo-ish.

Re:Theo (0)

Anonymous Coward | more than 8 years ago | (#15246572)

He always seemed like such a nice guy? What planet do you live on?

Re:Theo (0)

jonnythan (79727) | more than 8 years ago | (#15246676)

The planet where people laugh at jokes.

Re:Theo (2, Informative)

grub (11606) | more than 8 years ago | (#15246741)


He's always been cordial when I've had dealings with him. In fact recently on the misc@ list I mentioned problems with getting both cores on an AMD64X2 going with 3.9, pasted dmesgs, etc. and he wrote me off-list suggesting I compile up to -current. His suggestion worked and saved my sanity.

Re:Theo (0)

Anonymous Coward | more than 8 years ago | (#15246770)

Wow, he told you to use the latest version!

Re:Theo (1)

grub (11606) | more than 8 years ago | (#15246820)


My point was that he didn't yell "Upgrade to -current, you mindless fucking retard!" or whatever people may assume he'd write. And his subsequent mail was just as cordial.

Re:Theo (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15246902)

Wow! Did he also offer to suck your withered cock?

Re:Theo (4, Insightful)

ArbitraryConstant (763964) | more than 8 years ago | (#15246861)

I've witnessed him being an asshole.

Having to deal with him regularly might not be fun, but sometimes it takes assholes to get things done because they're prepared to piss people off to do what needs doing. If the goal were to make OpenBSD into another Ubuntu or Gentoo, his attitude probably wouldn't be that helpful, but for the goals they have it seems to work.

Re:Theo (-1, Flamebait)

Anonymous Coward | more than 8 years ago | (#15247056)

"See, there's three kinds of people: dicks, pussies, and assholes. Pussies think everyone can get along, and dicks just want to fuck all the time without thinking it through. But then you got your assholes, Chuck. And all the assholes want us to shit all over everything! So, pussies may get mad at dicks once in a while, because pussies get fucked by dicks. But dicks also fuck assholes, Chuck. And if they didn't fuck the assholes, you know what you'd get? You'd get your dick and your pussy all covered in shit!"

Re:Theo (1)

grub (11606) | more than 8 years ago | (#15247400)

I've witnessed it, too. Usually warranted (imho) as the person won't read the FAQs or manpages. Or won't listen to reason. Or expects the lists to be a google-proxy.

Re:Theo (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15247625)

I've only interacted with him a couple times in online-forums. Indeed he has at times disagreed with my point of view, skipped over the traditional "You are wrong because..." portion of a discussion, and instead launched (almost incoherent) personal attacks. Taking into account his obvious intelligence, coupled with the number of times his behaviour has really stung him personally, and I really believe the guy just can't help it -- quite simply, he goes off half-cocked.

To all the people that call him as asshole and never miss an occasion to trash him publically, I can only say that his actions speak louder than words: The guy is astonishingly committed noble pursuits ... a characteristic a lot more rare than mere technical skill.

Re:Theo (4, Interesting)

MerlynEmrys67 (583469) | more than 8 years ago | (#15246854)

Here is the problem with Theo. He is smart and opinionated. Having these two things in common make him a very difficult person to get along with if you are either Smart, but hold a different opinion because you come from a different set of assumptions - but especially if you are NOT smart and opinionated.

I have had discussions with Theo about trying to get my current employer (at the time) to open up documentation so OpenBSD could write drivers for our hardware. Lets just say I failed (Sorry Theo - I really tried, to the point that my annual raise was affected by it). However I found Theo to be very supportive and personally agreeable to me - I assume he realized I was trying to help and doing the best I could.

I can imagine people that are fighting against things he is trying to do could see him in a negative light - but again... I see the same kinds of things said about all of the great ones.

Re:Theo (1)

Pollardito (781263) | more than 8 years ago | (#15247264)

I have had discussions with Theo about trying to get my current employer (at the time) to open up documentation so OpenBSD could write drivers for our hardware. Lets just say I failed (Sorry Theo - I really tried, to the point that my annual raise was affected by it). However I found Theo to be very supportive and personally agreeable to me - I assume he realized I was trying to help and doing the best I could.
a nice guy is someone who's nice even when you don't have something that they want, an asshole can certainly act nice if it profits him. it doesn't sound like your experience was one where an asshole and a nice guy would necessarily give a different impression, i'm sure that BSD would have benefitted from having your hardware opened

Re:Theo (2, Insightful)

jo42 (227475) | more than 8 years ago | (#15247000)

Thank Gawd he's not a limp-wristed, touchy-feely, mamby-pamby, pear-shaped, wet noodle.

Re:Theo (1)

MoxFulder (159829) | more than 8 years ago | (#15248215)

BSD confirms it. Theo is rude.

Who cares (0, Flamebait)

Viriatus (886319) | more than 8 years ago | (#15246577)

about BSD??

FCC Rules (5, Insightful)

jusdisgi (617863) | more than 8 years ago | (#15246582)

I sure wish he had taken a better position on the wifi "FCC Rules require Binary Blobs" issue. He basically agreed that the FCC does require that the consumer not be able to change the frequency, but claimed that it should be dealt with in hardware, not the driver. This line is particularly poorly thought out: "Let the FCC go after the vendors who made the flawed devices."

See, here's the thing...the people he needs to convince here are the hardware manufacturers. You aren't going to get them to release open drivers by suggesting that the FCC should "go after" them. In fact, it serves to reinforce their binary-blobs-only position; after all, that's their current protection. But worse, by tacitly agreeing with their position about the FCC rules, he cedes the important part of the argument...the part where he could have won it. That's because while the FCC does indeed require that the consumer not be able to change the frequency to licensed spectrum, they have never taken the position that changing the source code is normal consumer operation. After all, consumers can change the frequency on many other chipsets (even in Windows) with binary patches. This is simpler than changing source code and recompiling it. I have never heard anything from the FCC that says you can't distribute source code with this functionality. Which is good, because the current mainline Linux kernel does distribute code that does this. If FCC rules actually forbade this (as the hardware companies are claiming) then it would be illegal to distribute the Linux (and presumably OpenBSD) kernel in the USA.

There was a wonderful discussion of this on the LKML recently in context of Intel's binary blob driver.

Re:FCC Rules (1)

gowen (141411) | more than 8 years ago | (#15246703)

You aren't going to get them to release open drivers by suggesting that the FCC should "go after" them.
Theo de Raadt in "Express opinion first, consider consequences later (if at all)" shock.

Re:FCC Rules (2, Interesting)

Homology (639438) | more than 8 years ago | (#15246720)

See, here's the thing...the people he needs to convince here are the hardware manufacturers. You aren't going to get them to release open drivers by suggesting that the FCC should "go after" them.

You did not really read that article, did you? OpenBSD wants hardware documentation, and besides, why should I as an EU citizen care about FCC regulations?

Re:FCC Rules (1)

HardCase (14757) | more than 8 years ago | (#15246829)

...why should I as an EU citizen care about FCC regulations?

For the same reason that I, as a US citizen, should care about the EU's RoHS regulations.

Re:FCC Rules (1)

Homology (639438) | more than 8 years ago | (#15246922)

For the same reason that I, as a US citizen, should care about the EU's RoHS regulations.

FCC rules does not apply to me, so why should I care about those restrictions? This is similar to use of strong encryption and US regulations.

Re:FCC Rules (2, Insightful)

jusdisgi (617863) | more than 8 years ago | (#15246995)

Now damn it, this is completely wrong. Read my other reply to your previous, identical statement, which I posted before you posted this. Our laws impact you because the hardware manufacturers want to sell their stuff here. So you are stuck with FCC compliant products, regardless of whether you are under FCC jurisdiction.

Re:FCC Rules (1)

Homology (639438) | more than 8 years ago | (#15247146)

Now damn it, this is completely wrong. Read my other reply to your previous, identical statement, which I posted before you posted this. Our laws impact you because the hardware manufacturers want to sell their stuff here. So you are stuck with FCC compliant products, regardless of whether you are under FCC jurisdiction.

You are very confused. I'm not obliged to follow FCC regulations while not in USA, or any other US law for that matter. A wireless product sold in USA has to be FCC compliant, and that is clear, but that does not imply that FCC regulations are world wide in their scope. Actually, in some countries it's downright illegal to use FCC regulations (think about different channels availalable for home use).

Re:FCC Rules (1)

jusdisgi (617863) | more than 8 years ago | (#15247344)

A wireless product sold in USA has to be FCC compliant, and that is clear, but that does not imply that FCC regulations are world wide in their scope.

That is correct. And I never once said or implied that FCC regulations were global in scope. I did, however, say that US regulations impact all FOSS users regardless of where they live. And I've given far more than adequate evidence to support that position. Again, note that Theo does not reside in the US, yet he obviously considers these particular FCC regulations important to him and to the rest of the (mostly non-US) OpenBSD team.

Re:FCC Rules (3, Informative)

Kadin2048 (468275) | more than 8 years ago | (#15248189)

I'm not sure if you're being intentionally thick or what. FCC regulations cover more than just how a device can be used, they affect every stage of its design, and the market that's controlled by the FCC is a pretty big one. You over in Europe may think that what the FCC does isn't relevant to you, but I can guarantee you if you turn over a few peripherals you have on your desktop, that you'll see "Tested to Comply with FCC Standards: For Home or Office Use."

Because hardware and device manufacturers don't want to have to make multiple versions of their product if they can avoid it, chances are they're going to make it compliant to the largest number of regulatory bodies that they possibly can. Hence why my mouse is manufactured in China but approved according to regulations in the U.S., Canada, Germany, the E.U. (separate from Germany), and a bunch of Asian ones I can't read. And that's without even counting the non-governmental certifications (UL, CE, etc.).

An FCC regulation that changes something fundamental about how electronic devices have to be made is almost sure to affect people everywhere in the world, just like the E.U. RoHS rules are going to change the stuff I buy here in the U.S., even if we as a country didn't give a damn about how much hazardous substances were in our electronics. (We do, we're just taking our time about it.)

So while the FCC doesn't have any direct authority outside of the U.S., it affects how lots of things which end up on the world market are made, and you'd have to be pretty naive to just ignore that.

Re:FCC Rules (2, Informative)

HardCase (14757) | more than 8 years ago | (#15247840)

FCC rules does not apply to me, so why should I care about those restrictions? This is similar to use of strong encryption and US regulations.

EU rules don't apply to me, but I care about RoHS restrictions because manufacturers tend to design to the most restrictive set of regulations that will apply to a product. Same deal with FCC regulations, in a broad sense.

-h-

Re:FCC Rules (1)

TigerNut (718742) | more than 8 years ago | (#15246847)

For you, the EC certification organization rules things just like the FCC does in the US and Industry Canada does in the Great White North. There is no place on the planet (or, in fact, within about 40,000 km of its surface) that there isn't a wireless standards compliance organization that claims control of the airwaves. One of the reasons that radio works at all as a commercially available communications medium, is that everyone designing and deploying the transmitters is playing by a cooperative set of rules. It would not take too many folks deciding that their transmissions were more important to significantly degrade the utility of wireless systems.

Re:FCC Rules (2, Insightful)

jusdisgi (617863) | more than 8 years ago | (#15246882)

You did not really read that article, did you? OpenBSD wants hardware documentation...

I did indeed read the article...I just recognized the larger issue that was not explicitly stated therein. Yes, what he really wants is documentation, although I'm sure he would be just as happy if they simply released the source to their binary blob. In any case, the reason he wants documentation is so that FOSS developers can write a completely open source driver for their hardware. The reason the hardware manufacturers refuse is ostensibly that it would violate FCC rules. The argument for that is that the FCC prohibits devices that the consumer can change to a licensed frequency. TFA actually discusses this.

...and besides, why should I as an EU citizen care about FCC regulations?

Surely you are just making a joke, and are not so utterly naive. You'll note that Theo is Canadian, but he obviously seems to care. When you find a wifi chipset that isn't sold in the USA at all, let me know. Until then, the restrictions placed on hardware and software manufacturers by the US government will continue to have a strong impact on FOSS users, regardless of where they live. This is an excellent example; you aren't under FCC jurisdiction, but you're still stuck with binary blob drivers from companies that claim it's their only method of FCC compliance.

Re:FCC Rules (1)

Homology (639438) | more than 8 years ago | (#15247023)

An open source driver is not the same as documentation. In the article he mentions open source drivers written under NDA that are essensially unmaintainable, whence of dubious quality. In another article Theo de Raadt describes open source drivers written under NDA as the open source equivalent of binary blobs.

As for FCC regulations and me as an EU citizen: I don't have to comply with FCC regulations while not in USA. The same goes for strong encryption. In this sense I don't care about FCC regulations. That US based companies think that I should care about FCC just means I go elsewhere with my money.

Re:FCC Rules (2, Informative)

jusdisgi (617863) | more than 8 years ago | (#15247213)

In the article he mentions open source drivers written under NDA that are essensially unmaintainable, whence of dubious quality.

No he doesn't. He says "Some Linux (and recently FreeBSD too) developers are willing to sign NDAs so that a few people get the documentation, and I believe that this is the largest problem facing the kernel side of the open source community today." Now, you'd have to ask him to clarify to be certain, but I would say the chances are extremely slim that he's talking about people writing open source drivers under NDA. Mostly I say the chances are slim because that's a totally ridiculous idea that no hardware company would consider; if you're going to let somebody write an open driver, what's the point of an NDA? On the other hand, I am familiar with at least one case (madwifi) where a developer (Sam Leffler) signed an NDA in order to produce a binary blob and an open-source interface component for a chipset (atheros) which had no driver available. I think it is extremely likely that these situations are the ones to which Theo referred.

As for FCC regulations and me as an EU citizen: I don't have to comply with FCC regulations while not in USA. The same goes for strong encryption. In this sense I don't care about FCC regulations. That US based companies think that I should care about FCC just means I go elsewhere with my money.

Your ignorance and lack of thought are astonishing. "US based companies" have nothing to do with it...where else are you going to go with your money? Every wifi chipset manufacturer sells its products in the US, and thus abides by FCC rules. The manufacturers in question here are mostly Taiwanese. The issue here is that, regardless of where a company is based or chooses to make its products, it invariably wants to sell those products in the US. Thus the manufacturer must comply with US regulations. So it doesn't matter whether you have to abide by US regulations...the people who make the products you use do. And once again, this is a great example. You can't have a certain driver, because it doesn't exist, because (ostensibly) of US regulations. Therefore US regulations impact you. Period.

Re:FCC Rules (1)

RollingThunder (88952) | more than 8 years ago | (#15247345)

Not quite "Period".

The manufacturers could make multiple versions - one FCC compliant for sale in the US, and one for everywhere else.

They don't because that costs more and eats into profit margins.

Things like this are one of the reasons why "power bricks" are so popular. The highest regulation tends to be where the highest voltage is. By having the country-regulation specific wiring in a seperate power brick, the companies can mass-produce the main unit (Xbox, etc) and just have regionalized power bricks.

Re:FCC Rules (1)

jusdisgi (617863) | more than 8 years ago | (#15247458)

The manufacturers could make multiple versions - one FCC compliant for sale in the US, and one for everywhere else.

Well, yes, obviously; I just sort of took the cost factor as a given. Note my line "when you find a wifi chipset that isn't sold in the US let me know" It's also worth noting that the 802.11b spectrum is different in Europe than in the US, and that many drivers have multiple versions so as to open up the extra two channels for non-US users. This is another piece of evidence that the source-code isn't a violation...after all, any US citizen could go get the foreign version of the driver and use channel 13. But this is all beside the point; the discussion has gone off into one of "I'm not from the US so why should I care what your government does" which in my opinion is dumb as hell. If you can't figure out why non-US citizens should care about the policies of the largest importer of goods, the largest economy, the largest provider of foreign aid, the largest IMF contributor, a permenant member of the UN security council, and the largest military power....well, then you don't have a very good handle on world issues.

Re:FCC Rules (1)

Homology (639438) | more than 8 years ago | (#15247601)

But this is all beside the point; the discussion has gone off into one of "I'm not from the US so why should I care what your government does" which in my opinion is dumb as hell.

Now you are misrepresenting my posts. Let me rephrase: I do not have to follow US regulations as an EU citizen living in EU. In this sense I don't care about US regulations.

If you can't figure out why non-US citizens should care about the policies of the largest importer of goods, Of course we do! We are financing your consumerism and Iraq war.

the largest economy, You sure got the largest debt.

the largest provider of foreign aid, You mean weapons?

the largest IMF contributor To protect the interests of companies like Enron.

a permenant member of the UN security council, Yo got that one right. If you only paid your fees to UN.

and the largest military power Yes, it's obscene in it's size.

Re:FCC Rules (0)

Anonymous Coward | more than 8 years ago | (#15247962)

At least we didn't have to wait too long for the first anti-US non-sequitor to pop up. And you also very nicely rephrased your original position, too.

For what it's worth, you don't have to be directly concerned with US regulations. But the rest of your reply shows an awful lot of ignorance. While I'm sure that you were trying to be snide and clever, you're just coming across as a crank. Too bad, really, because you were raising some interesting points up until then.

Re:FCC Rules (1)

flosofl (626809) | more than 8 years ago | (#15248048)

I do not have to follow US regulations as an EU citizen living in EU. In this sense I don't care about US regulations.

No one is saying that... You really are thick-headed, aren't you?

If you had a scintilla of intelligence in your hollow cranium, you would have seen his point immediately.

In a world market, a company will manufacture to the most restrictive specifications. In the case of wireless chipsets it is the FCC regulations. They are *not* going to make different versions for the EU/CAN/US, etc... It is too cost prohibitive. Therefore, the *world* gets the same version as the US. Unless you can figure out the microcode, your Intel wifi card has the same FCC imposed restrictions as the US version.

Is that clear, or do you need it spelled out in crayon and using smaller words?

Incidentally, thanks for the unwelcome political diatribe in the last post. You really added something to the entire thread. I mean how could we have *ever* missed the importance of bringing up the Iraq war and US Imperialism* in a thread about BSD.

Ass.

* - or Consumerism, etc... insert the -ism of your choice. Don't forget to capitalize it to show it's Serious(tm)

Re:FCC Rules (1)

Homology (639438) | more than 8 years ago | (#15247349)

No he doesn't. He says "Some Linux (and recently FreeBSD too) developers are willing to sign NDAs so that a few people get the documentation, and I believe that this is the largest problem facing the kernel side of the open source community today."

Yeah, yeah, here's the quote [newsforge.com]

TdR: There are always at least a few efforts in the project to get more documentation out of vendors. But some vendors are still incredibly resistant. We often run into vendors who have signed NDA agreements with Linux developers, who will then happily write a Linux driver filled with magic numbers, which only one developer in the world understands. Having signed the NDA ensured that Linux got a working driver, sure, but the internals are indistinguishable from magic. It cannot be fixed by anyone else, because it is full of secrets. It is a source code version of a blob.

Your ignorance and lack of thought are astonishing. "US based companies" have nothing to do with it...where else are you going to go with your money? Every wifi chipset manufacturer sells its products in the US, and thus abides by FCC rules.

Of course everyone selling products in USA has to comply with US regulations and laws.

The manufacturers in question here are mostly Taiwanese. The issue here is that, regardless of where a company is based or chooses to make its products, it invariably wants to sell those products in the US. Thus the manufacturer must comply with US regulations.

Are you stupid? The manufacturer has to comply with US regulations when doing business in USA. When doing business in another country, then another set of regulations apply.

Re:FCC Rules (1)

NutscrapeSucks (446616) | more than 8 years ago | (#15247907)

Now, you'd have to ask him to clarify to be certain, but I would say the chances are extremely slim that he's talking about people writing open source drivers under NDA. Mostly I say the chances are slim because that's a totally ridiculous idea that no hardware company would consider; if you're going to let somebody write an open driver, what's the point of an NDA?

I think you're reading too much into the term "NDA". For example -- "Here's some hardware documentation, don't post it on the web" is an NDA.

Theo is correct, and there's a very large number of open source driver being written this way.

Re:FCC Rules (5, Insightful)

TigerNut (718742) | more than 8 years ago | (#15246790)

As a current and past employee of several companies that make wireless transceivers subject to FCC licensing, I can tell you that there is no cost effective way to limit a device to FCC restrictions purely in hardware. Example: A cellular radio or any other modern RF link uses a synthesizer to set the transmit frequency. The output frequency of the synthesizer is a function of the reference frequency and the programmed divide ratio, and the total span of achievable output frequencies is dependent on the VCO that the synth is controlling. The maker of the synthesizer is not usually in a position to dictate the exact reference frequency, nor the VCO that it's hooked up to. The VCO vendor doesn't dictate the type of system that it will be installed into, and therefore can't strictly limit the frequency that it will tune to - and even if they did know exactly where it was going to go, then production tolerances dictate that you have some tuning margin in the design to allow all parts to hit the specified span. That means that individual parts will be tunable outside of the specified span on either the high or low side, and if the micro that controls the synthesizer commands a frequency outside the FCC limits, a lot of the time the hardware will have no problem doing it.

The same thing applies generally to power output levels. Sophisticated radios have some spare margin in the transmitter power output, and the actual output power level is calibrated at manufacturing time and then set in a FLASH based lookup table. The output power is then controlled using the embedded micro, driving a DAC. In this system, having open code on the embedded micro means that an uncaring individual could just crank the power output without regard for the FCC requirements.

You can say what you want about the motivations and ethics of the OpenBSD team members - if the source is out there, there will be others that take advantage of any "gains" they could make by tweaking some tuning parameters beyond the design or regulatory limits.

Ask Theo de Raadt how long it took him to get from his buffer-overrun Sun console hacking days to where he is now - almost everyone goes through a phase where "Just because I can" is sufficient justification to do poorly thought out things.

Re:FCC Rules (1)

jusdisgi (617863) | more than 8 years ago | (#15246933)

As a current and past employee of several companies that make wireless transceivers subject to FCC licensing, I can tell you that there is no cost effective way to limit a device to FCC restrictions purely in hardware.

I understood that sentence, but very little of the technical discussion that followed. However, it seems like you're making this too hard; if one wanted to limit the output of an RF transmitter in hardware, wouldn't it be trivial to simply put a couple of RF filters (one high-pass, one low-pass) in front of the antenna connector?

Re:FCC Rules (2, Informative)

drinkypoo (153816) | more than 8 years ago | (#15247072)

That would limit the possible frequencies but do nothing for the power levels. The FCC not only limits which frequencies you're supposed to be able to use in the US, but also total output power levels which depend on the antenna fitted. For instance if you use a primestar dish with a coffee can, and have super high gain, you are required to turn down your transmission power to be within FCC regs. Also, it would require additional hardware, which would cost money.

Re:FCC Rules (1)

Plunky (929104) | more than 8 years ago | (#15247990)

For instance if you use a primestar dish with a coffee can, and have super high gain, you are required to turn down your transmission power to be within FCC regs

Can you do that, with drivers and hardware that dont allow you to tune the power levels?

Re:FCC Rules (3, Informative)

TigerNut (718742) | more than 8 years ago | (#15247105)

Filters limit the frequencies that a system can broadcast or receive, but they also have an insertion loss penalty. This reduces the efficiency of the system significantly - if a given filter has 1 dB insertion loss (which would be pretty good, implying that the filter probably costs a decent amount of money) then it would impart a 20 percent reduction in power output. Therefore it would cost you 20 percent more current, at least, to get the same RF range. That would (a) decrease the battery life and (b) increase the heat load in your system.

Wireless system designers use filters already to limit out-of-band emissions, but the problem is that no practical filter has a 'brick-wall' response where the passband ends exactly at the edge of the allowed spectrum. In a typical 2.4 GHz wireless network system you could probably go outside the band by 10 MHz before the filter rolloff became significant. With that freedom, an enterprising wireless LAN operator could set up his own little playing area away from everyone else's interference - but he'd be tromping on some unsuspecting folks.

Re:FCC Rules (2, Informative)

LWATCDR (28044) | more than 8 years ago | (#15247475)

Maybe but then that hardware could only work in one market so it would cost more.
Also if you put in a hardware filter it would "absorb" some of the power that they device uses to transmit. So you would get a weaker signal or have less battery life. Also it wouldn't limit the power of the transmitter.
In short if you put the limits in hardware the produce would cost more, have a smaller market, and use more power. It just wouldn't be as good as a card that does everything is software.
It would fail on the market because as a product it would suck. It could have open source drivers with the current FCC rules but it would still not be a good wi-fi card.

I think a better solution is a stable binary driver interface for Linux and BSD. Just like the video card situation the current system of trying to "force" hardware manufactures to open source their drivers has not worked.

Re:FCC Rules (1)

agony_zhou (950311) | more than 8 years ago | (#15247829)

High quality analog filter (usually SAW filters) is bulky, expensive, and have other complication well. In the RF industry, people are going through all the trouble to eliminate every one of them.

Re:FCC Rules (1)

qwijibo (101731) | more than 8 years ago | (#15247128)

An individual who changed the code would potentially be in violation of FCC regulations. However, that's not the same as saying that the possibility facilitates an actual problem. The code is not likely to be modified by most users. Hams are allowed to modify and utilize radio hardware in the appropriate bands. I don't know how many people would really do so, but cutting off the possibility of compliant experimentation because of the possibility of noncompliant abuse seems like a uneven tradeoff.

Re:FCC Rules (2, Insightful)

jusdisgi (617863) | more than 8 years ago | (#15247303)

See, you're missing the point here. It's not whether a consumer might be able to violate FCC regulations. It's the fact that manufacture of a device that allows the consumer to transmit in a licensed band is itself a violation.

In other words, the manufacturers are prohibited by FCC rules from making a device that a consumer can run in a licensed band or at a higher-than-allowed output power. However, the part the manufacturers are ignoring is that the FCC seems to mean this in the context of the normal consumer-level interfaces, which doesn't include the source code. Changing the source code would be abnormal activity not sanctioned by the manufacturer and outside of normal use.

Re:FCC Rules (1)

Bill_the_Engineer (772575) | more than 8 years ago | (#15247620)

I can tell you that there is no cost effective way to limit a device to FCC restrictions purely in hardware.

Wow, you went through a lot of trouble to justify your case but you seemed to forgot something. The current operating parameters of WiFi are dictated by software. Therefore the hardware has a broad enough design to operate within the parameters dictated by the software.

BTW, yes there is a cost effective way to limit a device to FCC restrictions purely in hardware. I have radio equipment that was designed for different markets and their operation are restricted based on the regulations of their target country of operation. This is accomplished by firmware programmed within the equipment that have several modes of operations stored within it. The manufacture simply uses SMT diodes or zero-ohm resistors (jumpers) to tell the device what region the device should operate within. The placement of these SMT components can be programmed for each target market and be taken care of during board assembly. This method did have one disadvantage. During the early 90's, the FCC was frustrated by how easy it was for the end user to operate the radio device outside legal limits (power and/or frequency) by simply removing a diode. Newgroups were full of HOWTO instructions on how to MOD the radio equipment.

Another method (and more "secure" method) would require placing the current binary blobs into FLASH memory within the device themselves and publish the API so that driver developers can make use of them. Basically this simply moves the binary from a loadable file image to something already on the device. This would go against the current trend, since most (all!) of todays design decisions are based on increasing the profit margin by reducing part count by taking advantage of the host device.

Brgds, Bill

Re:FCC Rules (1)

TigerNut (718742) | more than 8 years ago | (#15247769)

I don't think I forgot that part. In fact I stated that not only does the hardware have a broad enough design to operate within the parameters dictated by the software, manufacturing and component spec tolerances require that the hardware design be broad enough to allow it to meet the system design spec when significant component variations are taken into account.

In multi-band radios, the equipment can typically be operated slightly beyond the intended band edge due to the filters not having an infinitely steep roll-off. It doesn't matter whether or not the manufacturer allowed for other operating bands with hardware configuration diodes or resistors. Also... these configuration resistors are generally (but not always) interpreted by software, since operating in multiple bands usually also requires slight protocol variations. Therefore, if the software is open, you can just eliminate the part where the configuration is read.

I interpreted Theo's comments to imply that they want the radio firmware to be open down to the hardware level. Pushing binary blobs into flash and publishing an API into a buggy hardware driver does not do what he wants...

Logical fallacy (1, Insightful)

Anonymous Coward | more than 8 years ago | (#15247647)

"In this system, having open code on the embedded micro means that an uncaring individual could just crank the power output without regard for the FCC requirements."

An uncaring individual can already do this, regardless of whether the code is open or closed. Having the code being open simply saves some time; but it does NOT prevent the effort. Most consumers could care less, and won't touch it. The ones who really want to can already do this.

Re:FCC Rules (1)

JesseMcDonald (536341) | more than 8 years ago | (#15247738)

The software that you are talking about is the firmware -- it runs on a microcontroller on the device, not the host PC. According to the interview, the OpenBSD developers have no problems with firmware provided that the copyright license allows them to redistribute it with OpenBSD (i.e. they don't need the firmware's source code). IANAEE, but that ought to be sufficient to satisfy the FCC's requirements.

If there is some problem with having the firmware loaded by an open-source driver, then the hardware manufacturer should have put the firmware directly on the device (in a ROM, for example) rather than delegating the loading to the driver. Even with a closed-source driver the firmware image can be altered by a binary patch off the Internet, so I don't really see how making the host driver closed-source enforces the FCC's regulations.

Financing? (3, Interesting)

AltGrendel (175092) | more than 8 years ago | (#15246593)

...I swear I will never get over how incredibly much money a University acting as a middle man between DARPA and us can bleed the flow of financing.

Any idea who he's refering to?

Re:Financing? (4, Informative)

kevin_conaway (585204) | more than 8 years ago | (#15246677)

About 15% of the funding, awarded in mid-2000, had remained unspent, de Raadt said. According to de Raadt, two days before the funding was cut off, Jonathan Smith, the computer science professor in charge of the project at the University of Pennsylvania, phoned de Raadt. Smith told de Raadt that several people at the university and DARPA were uncomfortable with de Raadt's antiwar comments, which appeared in The Globe and Mail of Toronto in early April.

Source [computerworld.com]

Re:Financing? (1)

jonastullus (530101) | more than 8 years ago | (#15246821)

well, i guess <exaggerate>throwing war criticism in DARPA's face</exaggerate> isn't exactly the most diplomatic approach, but cutting funding for an important application like OpenSSH over such personal issues seems like a pretty childish action to me! there's just nothing like being a "good patriot", i guess.

Re:Financing? (0, Offtopic)

updatelee (244571) | more than 8 years ago | (#15246855)

thats about it, pretty sad...

" all praise lord bush, or get the fuck out "

Re:Financing? (1)

jonastullus (530101) | more than 8 years ago | (#15246875)

ok, after reconsidering, i guess he bad-mouthed his (so-to-speak) employer and then his funding was discontinued. so i guess he has only partial reason to complain. but i still think that OpenSSH funding should be more important than such political quarrels.

Re:Financing? (2, Insightful)

Arandir (19206) | more than 8 years ago | (#15248211)

...but i still think that OpenSSH funding should be more important than such political quarrels.

So how come no one's blaming Theo then? If it is true that his attitude lost him his funding (which isn't demonstrated, btw), then let's blame the attitude. You don't tell someone to fuck off and then expect them to fund you.

Re:Financing? (0)

KarmaMB84 (743001) | more than 8 years ago | (#15246856)

His comments were just as sure to cut off his funding as pissing on a 5-star general.

Re:Financing? (2, Interesting)

Anonymous Coward | more than 8 years ago | (#15246763)

All of them. In grant financing, the institution will often take a percentage of the gross, as large as 48%, or more in some cases. It's justified under a multitude reasons, e.g., management, common facilities, name, reputation, goodwill, etc.

Sometimes these funds get funneled back through deans to dept. chairs and, yes, the even PI as a salary bonus, thereby allowing them to write a larger salary number in the next grant.

I'm not saying it's right but that is the way it is.

Department of Redundancy Dept. (2, Insightful)

scottennis (225462) | more than 8 years ago | (#15246811)

I thought "blob" stood for "binary large object."

So isn't it redundant to say "binary blob"?

Re:Department of Redundancy Dept. (1)

camperdave (969942) | more than 8 years ago | (#15247322)

In this context, it means Binary Locked OBject.

Re:Department of Redundancy Dept. (1)

asdfgl (891883) | more than 8 years ago | (#15247339)

Yes and no. Blob is often (and I think this notion predates the other) used to refer to something indistinct and shapeless. As for "binary large object" it might very well be a backronym of some sort.

Re:Department of Redundancy Dept. (0)

Anonymous Coward | more than 8 years ago | (#15247674)

Editor has a stutter you insensitive clod.

-- Moomin.

We don't buy hardware that OpenBSD doesn't support (4, Interesting)

linuxbaby (124641) | more than 8 years ago | (#15246930)

Though we only use OpenBSD on a few of our servers (we have about 150 servers) - we NEVER buy hardware that OpenBSD doesn't support, because to us that's a good test of whether this hardware is going to last or not.

If a hardware company is so proprietary or secretive or locked-down that OpenBSD can't (or chooses not to) support it, I don't believe that company will last in the long run.

Re:We don't buy hardware that OpenBSD doesn't supp (3, Funny)

idontgno (624372) | more than 8 years ago | (#15247279)

If a hardware company is so proprietary or secretive or locked-down that OpenBSD can't (or chooses not to) support it, I don't believe that company will last in the long run.

OpenBSD confirms it. Adaptec [adaptec.com] is dying.

Re:We don't buy hardware that OpenBSD doesn't supp (0)

Anonymous Coward | more than 8 years ago | (#15248310)

That's why it's important that the OpenBSD people provide a list of hardware players that they recommend. Let us as custumors know which hardware vendor to prefer.

So petulant and arrogant. (-1, Troll)

NDPTAL85 (260093) | more than 8 years ago | (#15246960)

Isn't it pretty amazing that when you purposefully select a license (the BSD license) that allows both individuals and corporations to use your code without contributing so much as a bad thought in return you get angry when people aren't rushing out to fund your project. The begging was just flat out shameless.

"Jeremy Andrews: I use OpenSSH every single day. I use it at home, and have used it at every computer job I've ever worked. I imagine this is true for a lot of people. What was the reaction to your recent request for donations from people and companies that benefit from OpenSSH?

Theo de Raadt: There were many reactions.
Some people thought that the tie between OpenBSD and OpenSSH is the problem, and thus they would not donate. Those selfish people apparently don't realize that OpenSSH-p is maintained by OpenBSD people, who don't need to do so, of course.
Roughly stated, painting with some broad strokes, the Linux vendors flat out refused to help. They have not even really replied to requests. The commercial Unix vendors have tried to stay away from funding us as well, hiding in their castles, especially when users of our software sent them requests for action.
Hundreds of people donated!
Smoothwall, Mozilla, and GoDaddy made some large contributions, as large users of OpenSSH. A few other large players (users, not Unix/Linux vendors) have something happening inside their accounting departments.

I don't understand why the Unix/Linux vendors (and Cisco) who ship our product are avoiding us. Maybe they are afraid to give to the first project, because then other projects will come asking too.

I think that contributions should have come first from the vendors, secondly from the corporate users, and thirdly from individual users. But the response has been almost entirely the opposite, with almost a 15 to 1 dollar ratio in favor of the little people. Thanks a lot, little people!"

No one owes any BSD licensed project anything, no matter how useful the project is. It was his choice to choose a license that basically says "Come on, steal what I have and give me nothing in return people!"

For a lot of folks the thinking is like this. A little self respect goes a LONG way, and if you don't respect yourself and your skills enough to charge something for your software or at the very least require that no one can take advantage of your code without giving something back (via the GPL) then you deserve to be used and abused like a cheap hooker. In this case with Theo De Radt we have the hooker following her John home to his suburban house, knocking loudly on the door and demanding additional money in front of his alarmed wife and children.

Incredible.

Re:So petulant and arrogant. (1)

LurkerXXX (667952) | more than 8 years ago | (#15247138)

Lots of companies use OpenSSH but don't distribute it. Lots of companies redistribute the vanilla version, with no changes made. In either of those cases, there's no 'giving something back'. And they aren't going to toss money at it just because it's GPL.

Making it GPL would do nothing for the funding, it mearly would add more restrictions to the license, which the OpenBSD folks are totally against.

Re:So petulant and arrogant. (0, Offtopic)

DrSkwid (118965) | more than 8 years ago | (#15247198)

Why do you think abusing women is "deserved" ?

Re:So petulant and arrogant. (4, Insightful)

hahiss (696716) | more than 8 years ago | (#15247356)

Agreed; this analogy is utterly awful! Not only is there this unhealthy response to prostitutes (someone needs to get some therapy. . .), the *ENTIRE* analogy doesn't work:

A prostitute is someone who gives what they otherwise wouldn't (sex) in exchange for cash. Theo gives his software away for free, to anyone, to use as they wish.

Now maybe you (GP) think the Free Software isn't a sound business strategy, and maybe you think Theo's a jackass---and heck, maybe you think he's getting what he deserved because he didn't demand that corporations leave their cash on the nightstand ahead of time [THAT'S how you make a prostitution reference!] but holy crap son could you find a way to say that without invoking repellant examples that contradict your point completely.

Re:So petulant and arrogant. (1)

NDPTAL85 (260093) | more than 8 years ago | (#15247639)

A lack of concern for prostitutes is not identical to a lack of concerns for women in general. Prostitutes put themselves in their positions, no one makes someone walk the streets at night. There's nothing unhealthy about heaping scorn on a whore. Even if you'd use them yourself.

My example doesn't contradict my point. Most street walkers simply don't get a fair value for their sex. $20 a blow job? $50 for intercourse? Admist the risk for lifelong disease? The prostitutes are getting screwed on a major scale just as BSD license developers are. The BSD developers work their butts off and still have to beg at the end of the day for funds to continue their work. Its a pretty pathetic place to be...not unlike the position in society afforded to prostitutes.

Re:So petulant and arrogant. (4, Funny)

mobby_6kl (668092) | more than 8 years ago | (#15247940)

>A prostitute ... gives what they otherwise wouldn't ... for cash. Theo gives his software away for free, to anyone, to use as they wish.

So, he's a slut?

Re:So petulant and arrogant. (1)

NDPTAL85 (260093) | more than 8 years ago | (#15247590)

Prostitutes do not equal women. Although they are women, not all women are prostitutes. Nice try.

Re:So petulant and arrogant. (0)

Anonymous Coward | more than 8 years ago | (#15248067)

Dude, not all prostitutes are women either.

Re:So petulant and arrogant. (2, Insightful)

Craig Davison (37723) | more than 8 years ago | (#15247336)

Come on. He's asking for money, not code changes. On that level, GPL-licensed code and BSD-licensed code are the same. A company like Linksys could use the Linux kernel in their routers without giving a cent to Linus or the hundreds of others.

There's nothing wrong with _asking_ for contributions. He knows that nobody owes him anything, and that jackasses like you will give him nothing but hot air, probably all the while logged into an OpenSSH server somewhere.

Re:So petulant and arrogant. (-1, Troll)

Anonymous Coward | more than 8 years ago | (#15248306)

That kind of kills the argument we hear so often about BSD being "more free" than GPL. The fact is, BSD is free only if you don't mind being harassed by people who actually expect you to pay for it. I just wish Theo would be more honest and change the license to a commercial one.

Re:So petulant and arrogant. (4, Insightful)

Anonymous Coward | more than 8 years ago | (#15247348)

Oh my, you really don't have a fucking clue, do you?
The OpenBSD project's recent funding problems have absolutely nothing to do with licensing; zero, zip, nada. The problem is not companies (Linux vendors, Cisco, Sun, etc.) modifying OpenSSH and without releasing changes publicly. The OpenBSD/OpenSSH project doesn't care about that, they expect it to happen. The problem is with said vendors using, redistributing and profiting from OpenSSH without making even a modest monetary donation in return. Given this, please, enlighten me as to releasing OpenSSH under the GPL would have any impact on this? Where in the GPL does it state that all redistribution and/or modification requires supporting the software's developers financially?
You think expecting a little money for something you poured blood, sweat, and tears into is "arrogant"? How about including open source software in almost all of your products (Cisco, Sun), and not giving a penny back for being given the opportunity to do so? Of course you have no obligation, but given the fact you're profiting off of this software, wouldn't it be wise to donate something (money, hardware) to the developers so that the software you're profiting from can continue to be developed? Some companies/projects have: GoDaddy and the Mozilla foundation. And hopefully more will in the future.

Oh, and whoever modded the parent up as insightful needs to be hit with a cluestick.

Re:So petulant and arrogant. (1)

PietjeJantje (917584) | more than 8 years ago | (#15247360)

Theo said regarding donations:
>I don't understand why the Unix/Linux vendors (and Cisco) who ship our product are avoiding us. Maybe they are afraid to give to the first project, because then other projects will come asking too.

These vendors are a bunch of losers. In their quest for the accumulation of scarcity tokens, they take a gift, make money with it, then avoid the gift giver, don't share tokens, and thus basically give up being civilized beings. That's a big price to pay for a small donation. Losers.

What this communicates to me is: Don't support *NIX vendors. Penny wise, pound stupid.

Re:So petulant and arrogant. (1)

Adam Hazzlebank (970369) | more than 8 years ago | (#15247550)

It makes good business sense of a company to use Linux in their product and give nothing back. If they contribute funds to a project what happens? The project gets better and /everybody/ benefits, if everybody benefits how does that push you ahead of the pack and increase your market share?

Re:So petulant and arrogant. (1)

PietjeJantje (917584) | more than 8 years ago | (#15247708)

I'm not sure if it's good business sence in the long term. Just as dual licensed OS projects don't attract many contributors, something similar is at play for me choosing an OS vendor, if any. But that was not the argument. Steve Balmer, for instance, has an almost perfect business sense in terms of personal wealth. For many though, he will always remain Monkey Boy.

Re:So petulant and arrogant. (1)

Plunky (929104) | more than 8 years ago | (#15248138)

Well you already had a headstart and now you are a leader of many rather than few and your followers are richer which makes you richer.

The alternate scenario where everybody just takes what their neighbour has, would seem to end up with us all sitting around in the dirt stealing sticks.

Re:So petulant and arrogant. (1)

lky (246353) | more than 8 years ago | (#15247472)

I have one question from Mr. De Radt. Since OpenBSD does not exist in a vaccum and since it does use parts of other projects (Like GCC from GNU), how much does OpenBSD give to those projects that it uses?

Or does OpenBSD feel entitled to take those things without payment because its giving away what it produces? Kinda like the Linux and other BSD distros are doing with OpenSSH?

Pot? Kettle?

Looking for a small, fast, correct compiler... (0)

Anonymous Coward | more than 8 years ago | (#15246980)

I wonder if they have looked at tcc? It's small, fast, and aiming for C99 compliance. It only supports x86 right now but since it's capable of compiling the Linux kernel it obviously supports most of the GNU extensions that people find useful.

You answered your own question. (1)

Homestar Breadmaker (962113) | more than 8 years ago | (#15247024)

"It only supports x86 right now". So that means its not an option. And given what a lackluster compiler it is, its probably not even worth using as a starting point to add more arches to.

Re:Looking for a small, fast, correct compiler... (1)

DrSkwid (118965) | more than 8 years ago | (#15247226)

Theo means "just like the plan9 compilers", but he doesn't like the license Lucent offer for them.

Great Interview... (3, Insightful)

link915 (900930) | more than 8 years ago | (#15247005)

This was an excellent interview and Theo seemed fairly down-to-earth. I actually agree with many of Theo's POV's but don't always agree with how he conveys them. This interview seemed to show his *softer* side :)

Honestly though, he is right...the big Linux vendors really needed to step up and donate to the project. I am a FreeBSD user and certainly understand the need for funding to keep these projects going. OpenSSH is an amazing piece of software that we all use quite a bit. I can't say that I give all of my money to these projects but I do purchase CD sets and can only hope that the rest of you do as well.

I guess sometimes we are all dicks when we really believe in something. Although Theo can come across as a dick sometimes he really does stand for a good cause. Software should be free!

Re:Great Interview... (0)

Anonymous Coward | more than 8 years ago | (#15247181)

Theo openly admit his project regularly needs to take from Linux, maybe he should be paying all those Linux coders developing device drivers?

Re:Great Interview... (0)

Anonymous Coward | more than 8 years ago | (#15247788)

The ones creating the glue for blob hardware abstraction layers? (Madwifi)

More seriously, even if OpenBSD used the GPL, or the Linux kernel used a BSD-style license, the OpenBSD project couldn't just incorporate device drivers from the Linux kernel the way it can do it with the other BSDs: they're still very different operating systems! Most of what is "taken" from the Linux kernel are static values: register offsets and such (see this [kerneltrap.org] excellent interview where OpenBSD developers describe what writing their nfe(4) driver for NForce ethernet involved). It's hard to do much more without violating the GPL anyways.

NDAs are a big problem? (1)

Bralkein (685733) | more than 8 years ago | (#15247038)

Some Linux (and recently FreeBSD too) developers are willing to sign NDAs so that a few people get the documentation, and I believe that this is the largest problem facing the kernel side of the open source community today.

Why is this a problem? If you are signing an NDA so you can write an open-source driver that anyone can read, edit and redistribute, surely that's not so bad? Of course it would be better to have completely open hardware specs, but if you really need to understand how this piece of hardware works, can't you take this open driver for it, read it, experiment with it, et cetera?

This is not a troll, I'm just not a programmer, so if this is a stupid question, that's why.

Re:NDAs are a big problem? (2, Interesting)

drinkypoo (153816) | more than 8 years ago | (#15247123)

Theo apparently feels (as I do) that the more we support vendors who refuse to just open up their specs, the less vendors will open them up. If Linux is taking over the server market (it is) and they need to open their device specs up to have them supported (they don't, if people will go NDA) then more companies will open up their specs so that they can be supported by linux - because companies like to minimize the variety of hardware in their organization for support reasons, and they are more likely to spec a single NIC that works in all situations (if available) than spec two different ones, one for Linux, and one for Windoze.

As long as people develop drivers for these products through reverse engineering or NDA, then these manufacturers will have no reason to release specs.

Re:NDAs are a big problem? (3, Interesting)

J.R. Random (801334) | more than 8 years ago | (#15247975)

The very fact that an NDA is used means that the manufacture knows that the writer of the driver needs facts that can not be determined by looking at the source of the driver itself. Typically this involves the use of various magic constants that must be loaded into device registers at appropriate times. The manufacturer knows what the magic constants mean. Hopefully the writer of the driver does too. But nobody else does, and the author of the device driver can't tell them. So if there's a bug (maybe because the magic constant wasn't quite the right one to use in certain circumstances) there's no way for another person to fix it. Likewise if there's a desire to expand the functionality of the driver there is again no way for a third party to know what the magic constants should be.

Re:NDAs are a big problem? IP! Trade secrets! (1)

Doug Coulter (754128) | more than 8 years ago | (#15248307)

Yes, NDA's can be a problem. Typically, the most performance is wrung from a video display chipset via a number of tecniques, some of which are patentable, some of which are merely trade secrets (see sources like www.groklaw.net to discern what I'm talking about around IP and how the current laws stink). Some of these are on-chip, some are in the driver, and this varies by manufacturer. If one could combine, say, Nvidia's chips with ATI's trade secret rendering tricks (or vice versa), one might have something better than either...And they will both fight to the death to keep some little marketing advantadge in these areas. Seeing the driver code in human readable form would instantly inform one (at least me) which was where, and allow things like this. Althought a good gpu has passed the general purpose X86 in pure mips, there are still conditions where the smarts need to be in the driver for best results, for example, in the case of (always) limited throughput to the chip, or heavy conditional stuff where the X86 shines but the vector processor does not. Why would any company give this sort of thing away? Trade secrets are "fair game" once revealed -- so one company might benefit by having its chip and the other's nifty driver tricks, whilst the one that had the nice driver gets nada out of it. Yes, it stinks. But there it is. Why would any manufacturer give this kind of thing away? They have what they have in chip form (some patentable, some not, but fairly well protected practically speaking) and other things that are best done in the host cpu given the total systems design, most of which are fair game once revealed. It stinks, but there it is.

The reason companies do not open up their drivers (3, Insightful)

Anonymous Coward | more than 8 years ago | (#15247124)

The fundamental reason why companies do not open up their drivers is because the average end user considers it a Linux problem when Linux doesn't have proper support for a given proprietary piece of hardware, instead of a problem with the maker of the chipset in question.

I think one reason for this is because there are a zillion consumer devices out there and no real place to be able to look up a given piece of consumer hardware and see who is making the chips for said hardware, and whether the chipset in question has a Linux driver. More importantly, if a given chipset doesn't have a Linux driver, the documentation should tell us whether this is because the chipset in question is closed, or if it is because no one has had a chance to write a driver.

If this information is out there, when people give the usual "Linux sucks because it doesn't support X piece of hardware" flame, the reply can be "blame the makers of X piece of hardware, not Linux". If this mindset catches on, companies will start supporting Linux better. For example, I bought a Creative Zen Nano instead of an iPod Nano because the Zen had full Linux support; the iPod doesn't.

The problem with making this online database is that someone will need to be motivated to make such a database; this is a non-trivial task. The wiki model is perfect for something like this. Indeed, someone has a wiki-based database like this for IBM Thinkpad computers [thinkwiki.org]

theo de raad (0)

Anonymous Coward | more than 8 years ago | (#15247289)

was that the guy who was seriuosly sick and asked for help on slashdot?

Re:theo de raad (1)

rehabdoll (221029) | more than 8 years ago | (#15247326)

No. You probably refer to Patrick Volkerdi, the author and maintainer of Slackware.
And he did not ask for help on slashdot, he asked for help in the slackware-changelog, which was later posted on slashdot.

Compilers (1)

StarHeart (27290) | more than 8 years ago | (#15247670)

I think Theo is crazy for wanting a compiler with little or no optimization. It would make his life easier for development, but completely screw the user. From everything I have heard gcc isn't good enough at optimization.

Re:Compilers (1)

GnuVince (623231) | more than 8 years ago | (#15248052)

Maybe the idea would be to start with a clean slate, a clean and simple compiler and adding optimizations afterwards.

Re:Compilers (1)

Clover_Kicker (20761) | more than 8 years ago | (#15248204)

If the tree compiled cleanly with both compilers, they'd develop with speedycompiler and ship the GCC optimized version.
Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...