Slashdot Mirror
Kernel Trap Interview with Theo de Raadt
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."
If you feed them jellybeans, they will do useful things for you.
I've had enough abrasive sigs. Kittens are cute and fuzzy.
I was hoping he'd say something about his thoughts on Linus' calling the Mach and FreeBSD people 'incompetent idiots'.
Sure he's an OpenBSD guy... but I'm sure he's got an opinion on it.
Help Brendan pay off his student loans
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.
about BSD??
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.
Given a choice between free speech and free beer, most people will take the beer.
Any idea who he's refering to?
The simple truth is that interstellar distances will not fit into the human imagination
- Douglas Adams
I thought "blob" stood for "binary large object."
So isn't it redundant to say "binary blob"?
Read any good sonnets lately?
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.
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.
Mac OS X and Windows XP working side by side to fight back the night.
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.
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!
"I reject your reality and substitute my own!"
"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.
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.
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
OpenBSD confirms it. Adaptec is dying.
Welcome to the Panopticon. Used to be a prison, now it's your home.
was that the guy who was seriuosly sick and asked for help on slashdot?
"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.
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.
Havoc Penington, the bane of my Linux desktop.
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.
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.
The simple, easy optimizations that have the most effect are fine. But gcc spends ages trying to over-optimize code, making it take 5 times longer to compile, and then producing code that is often incorrect (crashes or corrupts data) and/or slower than without the optimizations.
You hear that gcc isn't good enough at optimization because its true. Its really bad at it, and produces slow, broken output. That doesn't mean everyone else should try to make their compiler blow too, it means gcc sucks.
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 got a discount and a 45% or 50% overhead rate.
Essentially, in grant accounting, you have to account for your direct expenditures (and get reimbursed from the grant issuer), but the overhead you keep. So the university wants as high an overhead rate as possible, as they keep that money. The researchers that "earned the grant" want the lowest rate possible, so more of the money goes into their accounts for their expenditures (you know, things like their salaries).
Also, if grant money is spent on not-aprroved things (let's say Theo calls 25% of his house his office, but the grant doesn't cover the home office, or he hires a project manager and that isn't approved for the grant), then the school won't be able to get reimbursed for those expenditures. Each organization's politics determines what happens when the school "eats" the costs (part of why they have such a high overhead, they cover over-runs, etc.), but in this case, it was an outside organization. I wonder how comfortable the University was cutting checks to Theo's personal account without knowing that they would get reimbursed, so they probably kept a high reserve that they wouldn't release, and a large overhead rate.
Ah, grant accounting...
Alex
The plan 9 compiler is available under an MIT license as part of inferno.
No SMP server, then ?
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.)
Theo openly admit his project regularly needs to take from Linux, maybe he should be paying all those Linux coders developing device drivers?
:)
And linux devs openly admit that OpenBSD often identifies and patches security holes that also affect linux. So bug and security fixes cancels out drivers, Theo's OpenSSH point is left standing.
What, exactly, is "truly free software"? I can't find that term in the interview.
Digital Citizen
It's designed to maximize compile speed so that you can use it as a script interpreter for C code. The qemu emulator evolved out of tcc.
#!/usr/bin/tcc
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???
Usually documentation does not exist. Under an NDA, the company can supply hardware design plans and Windows source code instead.
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!
Dying? It sad they can't somehow, how to say in English, change themselves, alter their way of doing things ... ach, what is that word?
$META_SIG_JOKE
I remember that the last big OpenSSH vulnerability was a problem with signed/unsigned integer conversion, and that lint was able to detect this vulnerable usage, which facilitated a complete audit of the source tree.
Granted that Theo makes further mention of their lint work in the interview, if you had C code that concerned you, you should start with the OpenBSD lint.
This leads to a couple of points:
Would Linus trash one of his open-source peers for, *gasp*, reverse engineering a closed-source protocol?
http://www.realworldtech.com/forums/index.cfm?acti on=detail&PostNum=3322&Thread=2&entryID=49312&room ID=11