Want to read Slashdot from your mobile device? Point it at m.slashdot.org and keep reading!

 


Forgot your password?
Close
typodupeerror
×

Kernel Trap Interview with Theo de Raadt 181

Posted by Hemos from the the-man-speaks dept.
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."
This discussion has been archived. No new comments can be posted.

Kernel Trap Interview with Theo de Raadt More

Kernel Trap Interview with Theo de Raadt

Comments Filter:

  • Theo (Score:5, Funny)

    by Anonymous Coward on Tuesday May 02, 2006 @12:46PM (#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 (Score:2, Insightful)

      by jo42 ( 227475 )
      Thank Gawd he's not a limp-wristed, touchy-feely, mamby-pamby, pear-shaped, wet noodle.
    • BSD confirms it. Theo is rude.

  • FCC Rules (Score:5, Insightful)

    by jusdisgi ( 617863 ) on Tuesday May 02, 2006 @12:53PM (#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 (Score:3, Interesting)

      by Homology ( 639438 )
      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?

      • ...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.
        • 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 (Score:3, Insightful)

            by jusdisgi ( 617863 )
            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.
            • 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 i

              • 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 reg

              • Re:FCC Rules (Score:4, Informative)

                by Kadin2048 ( 468275 ) <.ten.yxox. .ta. .nidak.todhsals.> on Tuesday May 02, 2006 @03:36PM (#15248189) Homepage Journal
                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.
                • 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.

                  Of course FCC regulations have influence outside USA, as many other laws and regulations. This does not imply that the rest of the world should meekly accept these regulations as an excuse for hardware companies not to release hardware documentation. That I don't care for some US regulations/laws does not me

                  • Of course FCC regulations have influence outside USA, as many other laws and regulations. This does not imply that the rest of the world should meekly accept these regulations as an excuse for hardware companies not to release hardware documentation.

                    I think you answered your own question that you wrote in a previous post:

                    "FCC rules does not apply to me, so why should I care about those restrictions?"

                    You should care because they have influence outside the USA and you shouldn't meekly accept those restriction

          • Re:FCC Rules (Score:3, Informative)

            by HardCase ( 14757 )
            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-
      • 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 r

      • Re:FCC Rules (Score:3, Insightful)

        by jusdisgi ( 617863 )

        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 manufacture

        • 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. T

          • Re:FCC Rules (Score:3, Informative)

            by jusdisgi ( 617863 )

            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 w

            • 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

              • 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-c

                • 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 cons

                  • 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, et
                  • 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.

                    I think that you have it backwards - the US imports goods and "exports" money. If "you" were financing US consumerism and the Iraq war, the flow of money would be going the other way. In fact, you could make a better case that the US was financing your opposition of the war (assuming that you're posting from a country that does not sup
                    • You don't like the US, I think, and that's OK.

                      I think that USA is great country, and there is much to admire. However, that cannot be said of the current Administration which is downright scary.

                      There is a hug influx of money into US by foreign central banks having valuta reservers in US dollars, enormous foreign investments (funds, Arab petro dollars etc) and huge trade deficit. Conbine this with enourmous Federal spending (Iraq, as an example), budget deficit, huge tax cuts and US families that are i

                    • As for the size of US "defence": It uses more than even at the coldest of the cold war. And to what ends?
                      Do you have a citation for this claim? It looks to me like current US defense spending, in relation to GDP, is lower than during the cold war.

                      http://www.truthandpolitics.org/military-relative- size.php [truthandpolitics.org]

            • 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,

            • 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

    • Re:FCC Rules (Score:5, Insightful)

      by TigerNut ( 718742 ) on Tuesday May 02, 2006 @01:14PM (#15246790) Homepage Journal
      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.

      • 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-

        • Re:FCC Rules (Score:3, Informative)

          by drinkypoo ( 153816 )
          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.
          • 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?

            • You are sometimes allowed to tune the power levels in the downward direction, just not in the upward. Some cards' drivers provide for this, and some don't.

        • Re:FCC Rules (Score:4, Informative)

          by TigerNut ( 718742 ) on Tuesday May 02, 2006 @01:48PM (#15247105) Homepage Journal
          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 (Score:3, Informative)

          by LWATCDR ( 28044 )
          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 mark
      • 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 (Score:3, Insightful)

          by jusdisgi ( 617863 )

          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 co

      • 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 manu
      • 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.

        Um, sure. But I don't think Theo cares about it being "pure hardware" or a hardware/firmware mixture. As long as it isn't in the software driver, wifi hardware companies can't claim that releasing source is against FCC rules. And, as the parent was saying, it probably isn't anyway.
      • Bah restricting in software is just plain stupid: if you put restriction in the driver, how can you prevent the user using a driver for a different country where say the output power or the channel he wants is allowed?
      • Here is how to "put it in hardware". True you really can't but this comes close. You write code to enforce the limits and you burn this into ROM the on-board procesor is designd to execute the ROM code periodically.

        This is typical with spacecraft. There is an interval timmer that forces and interrupt that drive the processor to execute coe from ROM periodically. The "safe mode" or "fail safe" or "watchdog" stuf runs there even if a totally bogus set junk gets uploaded in the the RAM. Alows remote rec

      • Oh come ON. You can easily put middleware firmware between the raw VCO frequency input and power level settings, so that the end-user will be effectively limited to only what frequencies and power levels you wish the end-user to access.

        Then you can DOCUMENT THAT INTERFACE.

        There's nothing particularly difficult or expensive about doing that. It's just a shim between the driver and the hardware. And done right (e.g. ENGINEERED PROPERLY), you can also save your company from ever having to release anything o

  • Financing? (Score:4, Interesting)

    by AltGrendel ( 175092 ) <(su.0tixe) (ta) (todhsals-ga)> on Tuesday May 02, 2006 @12:54PM (#15246593) Homepage
    ...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? (Score:5, Informative)

      by kevin_conaway ( 585204 ) on Tuesday May 02, 2006 @01:02PM (#15246677) Homepage
      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]
      • 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.
        • 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? (Score:2, Insightful)

            by Arandir ( 19206 )
            ...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? (Score:2, Interesting)

      by Anonymous Coward

      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.

    • Overhead rates (Score:3, Informative)

      by alexhmit01 ( 104757 )
      Universities have an overhead level, including salary fringe, etc., that then gets estimated. If the university's overhead rate is 65%, then for every $1 in grant money, 35 cents goes to cover DIRECT costs of the work, and 65 cents go to the University Overhead Income Account.

      Basically, things like lab space may be direct or indirect (overhead) costs, depending on setups.

      Given that they weren't on staff so there was no fringe (taxes, benefits, etc.), and they weren't using any school resources, maybe they

  • Department of Redundancy Dept. (Score:3, Insightful)

    by scottennis ( 225462 ) on Tuesday May 02, 2006 @01:16PM (#15246811) Homepage
    I thought "blob" stood for "binary large object."

    So isn't it redundant to say "binary blob"?
    • I thought "blob" stood for "binary large object."

      Yeah. You can't imagine my disappointment in the 80's when I bought a ticket to see a technical movie about "binary large objects", only to see NOT ONE computer in the whole movie!

      I mean, they even CAPITALIZED "BLOB" to fool people into thinking it was an acronym.
    • No. You can have XML "blobs" that you don't understand but just insert into a section of other XML that you do understand (assuming it's all well-formed, etc...).

      A "blob" is just something that you don't understand but still use. Binary or text, it doesn't matter.

  • We don't buy hardware that OpenBSD doesn't support (Score:5, Interesting)

    by linuxbaby ( 124641 ) * on Tuesday May 02, 2006 @01:31PM (#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.

  • Great Interview... (Score:3, Insightful)

    by link915 ( 900930 ) on Tuesday May 02, 2006 @01:38PM (#15247005) Homepage
    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!
    • Code donations most directly support OpenSSH.

      Money donations go into the OpenBSD pot, supporting a competitor.

      It's kind of a bait-and-switch Theo is trying. He asks for OpenSSH donations, but he doesn't keep the funding separate from OpenBSD. So he's demanding that Red Hat donate to OpenBSD. Excuse me???
  • 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 ha

    • 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 s

    • Re:NDAs are a big problem? (Score:4, Interesting)

      by J.R. Random ( 801334 ) on Tuesday May 02, 2006 @03:13PM (#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.

      • no (Score:3, Informative)

        by r00t ( 33219 )
        Usually documentation does not exist. Under an NDA, the company can supply hardware design plans and Windows source code instead.

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

    by Anonymous Coward on Tuesday May 02, 2006 @01:49PM (#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]
  • 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.
    • Maybe the idea would be to start with a clean slate, a clean and simple compiler and adding optimizations afterwards.
    • If the tree compiled cleanly with both compilers, they'd develop with speedycompiler and ship the GCC optimized version.

    • Re:Compilers (Score:3, Insightful)

      by mccoma ( 64578 )
      It seemed to me he was more concerned that the correctness of the generated code was being compromised by the optimizations. I would expect the would love a small, correct compiler that they could add various security enhancements (e.g. stack protection) in a straightforward manner.
  • You know what I like most about OpenBSD? A sane version numbering scheme. In this day and age where version numbers have become a marketing tool, it is a nice change.

    The worse offender in this regard has to be Mac OS X. I see people write "Mac OS X 10.4", which is the same as saying "Mac OS Ten Ten-point-four". And I've never seen anyone write it as "Mac OS X.IV" or "Mac OS X.4". (Most people say "ex" instead of "ten", I bet.)
    • I used to version OS X the same way they do references for Shakespeare plays: e.g. X.iv.6 refers to the latest version of Tiger, for example. But, not only did it not catch on, no one really understood it so I gave up. The problem is that no one's really sure whether there will ever be an eleventh version of Mac OS or not. After all, it has an X in the name like all good commercial Unices. But OS X has been around for nearly six years, and we've still neither hide nor heard of the next version.
  • What, exactly, is "truly free software"? I can't find that term in the interview.

  • OpenBSD code auditing? (Score:3, Interesting)

    by raw-sewage ( 679226 ) on Wednesday May 03, 2006 @01:02AM (#15251462)
    TFA had a typical comment from Theo or any OpenBSD core team member: "As we become aware of more problems in the C language, we are trying to be very agressive to make the code cleaner. Just the standard OpenBSD proactive auditing process."

    My question is this: what is the "standard OpenBSD proactive auditing process"? Before, I've lightly asked about this on the misc@ mailing list, but the answers weren't very helpful, generally paraphrased as (1) experience or (2) study the CVS diffs.

    Well... that's nice, but I'd like to have a more straightforward "beginner's approach", something a little more accessible. I agree that only experience will make you a truly great secure and correct coder, but it would be nice to have a book that explained (and gave examples) of the kinds of things that the OpenBSD developers routinely look for in their code audits.

    Put another way, I feel I have a good understanding of the fundamentals of secure C programming: generally prefer strncpy() (or strlcpy()) to strcpy(), know when to use memmove() or memcpy(), always check input parameters to make sure they are within the defined boundaries of the function, etc... but surely there's more than just these well-known general rules of thumb, right? It would be nice if core OpenBSD developers could have their secure C programming expertise dumped into a book!

Slashdot Top Deals

It is easier to write an incorrect program than understand a correct one.

Close