|
|
|
||||||
|
|||||||
Where 2.0 Conference: June 29-30, 2005, San Francisco, CA |
|
OpenBSD 3.7: The Wizard of OSby Federico Biancuzzi05/19/2005 Today the OpenBSD project announced the new 3.7 release. This is the
first release to support newer wireless chipsets, especially for 802.11g,
thanks to a big activism campaign lead by project leader Theo de Raadt. It's
now possible to create a portable access point with a tiny PDA using the Zaurus
port, too. As usual, there are a lot of other big and small changes, such as the
import of Xorg, the jump towards Damien Bergamini: Ralink Tech. and Realtek have been very
friendly by providing us documentation for their wireless chipsets. Ralink
Tech. gave us the spec for their RT2500USB 802.11 b/g chipset and about one
week later, we had a working driver ( It is important to show vendors what they can benefit at no cost when cooperating with us. We are very respectful toward these vendors and if they ask us not to spread the documentation around, we respect this. But we do not sign NDAs.
OTOH, Intel has been quite uncooperative by refusing to give us the right to
redistribute the binary firmware images for their PRO/Wireless
2100/2200BG/2915ABG adapters (Centrino). As a consequence, although drivers
for these adapters ( ORN: Is there anything that our readers could do to help you succeed? Damien Bergamini: Buy hardware made by open-source-friendly vendors (there is almost always a choice) and continue to contact the closed vendors. It has proven to be effective in the past. And to the Linux "vendors" that regardlessly ship non-free firmware images with their OSes, I'd say that they are playing against their camp. Why would vendors ever change their policies if such things are accepted by the open source community? ORN: I read that you have a plan to create a global Marco Peereboom: Yes, work has started on a tool that will
do universal RAID management; it is actually called The idea behind Unfortunately, there are still vendors out there that believe that there is IP inside of a hardware API. In my experience this is mostly nonsense, and whenever there is IP hidden inside an API it only means that the device was architected poorly. We are talking about filling in some sort of structure, sending it to the device and awaiting an answer either directly or through a callback. There is no secret sauce hidden in these numbers that enables competitors to magically understand what goes on in the firmware. Reverse-engineering hardware is all about motivation and resources. If a vendor is motivated enough, it will have to spend considerable resources on people with specialized knowledge and equipment to X-ray a board in order to obtain the schematics. It is even harder to reverse engineer programmable chips like FPGAs and CPLDs. Compared to this, reverse-engineering a software API is trivial. Hiding an API does not help a vendor in any way, shape, or form, and it really is silly to keep it hidden as if the farm depends on it. ORN: This release fixes the mirroring mode in Michael Shalayeff: As usual, two choices: software or
hardware. All of the drivers we have currently do not support any management, but
we are working on a few that we have enough info to make some management
usable. Software ORN: A lot of companies have been using OpenSSH in their products (Sun Microsystems, Cisco, Apple, GNU/Linux vendors, etc.). Did they give anything back, like donations or hardware? Henning Brauer: Nobody ever gave us anything back. A plethora of vendors ship OpenSSH--commercial Unix vendors (basically all of them), all of the Linux distributors, and lots of hardware vendors (like HP in their switches)--but none of them seem to care; none of them ever gave us anything back. All of them should very well know that quality software doesn't "just happen," but needs some funding. Yet, they don't help at all. ORN: This release includes the new OpenSSH 4.1. What's new? Damien Miller: 4.1 is just a bugfix release; it didn't include any new features over 4.0. The new features in 4.0 included:
ORN: Does Henning Brauer: The only bigger new feature is the ORN: I read some complaints about its limited precision. Is this a real problem for most users? Henning Brauer: No, not at all. It reaches offsets of way below 100ms, typically below 50ms. That is about the clock resolution typical PC hardware reaches. None of the people crying for "better" resolution could ever give any valid reason why they'd need it--in fact, almost all couldn't give any at all. ORN: I read that OpenBSD added the support for PIM (Protocol Independent Multicast). What is it? When is it useful? Damien Miller: These changes came from FreeBSD and NetBSD via Pavlin Radoslavov and Ryan McBride. It is the kernel support required to implement the PIM multicast routing protocols (PIM sparse-mode and PIM dense-mode). These are the most popular ways to route multicast traffic between networks. Note that OpenBSD doesn't have PIM-SM or PIM-DM daemons that can use this support in the base OS, but you can use Xorp from ports. Claudio Jeker: PIM replaces the traditional multicast
mechanisms like PIM makes only sense in larger networks that need to do a lot of multicasting. A possible example are some IP TV solutions that stream every channel as its own multicast group. This reduces the network load on the backbone, but the end user is still capable of switching quickly between channels. ORN: OpenBSD 3.7 includes in-kernel PPPoE support. Previous versions already have a PPPoE implementation in userland; why is there a kernel-based one now, too? Can Erkin Acar: PPP is a protocol for establishing
point-to-point links. It is a quite complicated protocol with many options for
authentication, encryption, and compression. The existing userland
The main problem with userland PPP/PPPoE processing is the overhead. A single packet has to travel quite a number of times between the kernel and the userland before finally reaching the TCP/IP stack in the kernel. While not really noticeable with slow links, high-speed PPPoE links may increase the CPU utilization and the throughput may be affected. When the PPPoE processing is moved to the kernel, much of the overhead is
removed. However, the PPP layer inside of the kernel (the OpenBSD's PPPoE (PPP over Ethernet) code is initially ported from NetBSD by
David Berghoff. It was developed and tested outside of the tree until one of the
developers (me) had enough time and motivation (Theo) to put it into the tree.
I modified the initial port to work with our I continue to work on and improve the Claudio Jeker: The userland PPPoE is a bit tricky insofar
as it uses ORN: The 3.7 release page shows some new PF features. How does each one work?
ORN: What is new in the IPsec/ Hans-Joerg Hoexer: For 3.7, we mainly focused on stability
and interoperability: the implementations of the NAT-traversal (NAT-T) and
dead-peer-detection (DPD) features that we shipped with 3.6 were not mature
enough. These issues have been resolved for 3.7. Among many minor bugfixes, we
also made sure that it is possible to run multiple instances of
Ryan McBride added a nice feature for typical roadwarrior setups:
in addition to IP addresses, isakmpd.conf now also understands
interface names and the special keyword ORN: Did you develop any new feature to fight spam? Bob Beck: Yes, I've added a "greytrapping" feature to
if a server is running doing greylisting, any greylisted host who attempts
to mail to the destination address of
The spamtrap address has no effect on established Good candidates are any unused address or formerly used address that has
been harvested or appears in a public forum. (in fact, you can pretty much
count on my putting I have small servers consistently running several hundred
This is the first of several new features to take advantage of the 30-minute
initial delay given by greylisting, as spammers seem to be noticing. Noticing
is good. This means both that it works, and that spammers are easier to identify if they
don't like talking to
ORN: Reading the changelog I found a funny point: "The Great Apache Cleanup of 2004 to remove code we don't use." What is the status of the forked Apache included in OpenBSD? Henning Brauer: Well, we're cleaning up the mess, starting by removing code we don't use. In the end, we hopefully have readable code, and we're pretty sure we will fix security bugs in the process. Since the Apache people decided to change their license to an un-free one, we cannot import newer versions anyway--which is not really a loss, given that they don't really put any work into the 1.3 tree any more. Our Apache has hundreds of fixes they didn't take back even before the licensing issue. Now it has even more, and they still don't have them. We're fixing more stuff on the way, most often without noticing--we are just fixing bugs. So, technically, this could be called a fork. ORN: This is the first release that includes X.Org. Why did you choose to import it instead of XFree86 4.5.0? Matthieu Herrb: The primary reason is that the new revision 1.1 of the XFree86 license is less free than the old MIT license that had been used for years by XFree86. OpenBSD already avoided shipping the final XFree86 4.4 release that also uses the new license in 3.6. Then, as many other projects moved away from XFree86 because of the license, it became obvious that most new developments in the X window system now take place in X.Org. Having said that, projects like OpenBSD have to stay vigilant that X.Org doesn't turn into a Linux-only project (that would slowly slip to a GNU General Public License). ORN: What new features do package tools support? Marc Espie: A lot! The most visible new feature is probably the progress meter. If you add/remove packages, you will now get instant feedback that something is going on. A related features is that the message system has been completely redesigned to be more useful: it's much harder to miss things now. In general, the system is more robust, handles more fringe cases better, and is a wee little bit faster. Package tools in 3.7 consume half the memory they did in 3.6. Shared library handling has been totally rethought. Packages will now check that libraries in the base system are present, with the correct version. And also register and handle inter-package library dependencies fully. From the ports people point of view, it's now much easier to write correct package dependencies than it ever was. The object-oriented packing-list framework has been cleaned up, and is now used extensively through the whole package system. This is a huge improvement, because some very nice tricks are now feasible with a few lines of Perl. For instance:
Alongside shared libraries, the package system now includes smart ways to handle:
And I've probably forgotten a few things along the way. This means that most
special cases ( This is way more robust than the old tools. A lots of simple manual mistakes in making ports with the old tools will just not happen with the new ones. OK, I've kept the big one for last. You can use That's right, we've got a real update system.
Yes, Virginia, you no longer have to uninstall the old packages before
installing the new ones. So you just have to:
and it will just work, by first updating It handles shared libraries correctly, keeping old libraries around until all packages that need them are updated, and is generally pretty safe. ORN: What is the roadmap for their development? Marc Espie: Next on my list is handling really complicated update cases, where you can't update packages individually (for instance, when files move from package to package, you have to update both packages at once). There's also some redesign for dependencies (again) to take updates into account. And there's a smarter tool to do updates too. If you read As usual, there's some quality-assurance work to do. Even though
The next very significant change will probably be in the ports tree itself.
A lot of the One important policy you'll already see is that we're much more careful in bumping package names each time we change anything--having update capabilities mean people will want updates to work. And they will mix and match packages from various points in time, even though this is not guaranteed to work. Between very precise package names, and the registration of shared libraries versions, the package system is doing its best to "get out of the way" and ensure things will just work, or say in a very obvious way, "Hu, hu, no, sorry, you really shouldn't do that" if the user does a stupid mistake. ORN: I saw various updates for Martin Reindl: As you noted, pretty much. OpenBSD on It all started in fall 2004 when I dusted off a stray NuBus network card. It
was not recognized back then, but the fix was easy. Miod Vallat then contacted
me, gently pushed me in the right directions, and gave me some good information
on where and how to start working if Things took off and Claudio Jeker fixed the So what we have now is a ORN: I think people will get excited by the Zaurus port, bringing a secure SSH-capable machine to their pocket. What is the development status? David Gwynne: It is trivial to find an OpenSSH package and install it on the Zaurus's default Linux distribution. I believe the availability of these packages is a good demonstration of the effectiveness of the work that the portable OpenSSH guys are doing. Personally, I am more interested in having OpenBSD itself and some of its
other features on a wireless device in my pocket. Being able to build a
temporary access point out of a Zaurus with a USB Ethernet device and a
wireless CF card and using four commands to set it up is extremely cool. Apart
from my own needs, I know that people want OpenBSD on the Zaurus for the same
reason they want it on The 3.7 release on the Zaurus C3000 is surprisingly usable considering the short amount of time it has actually been in-tree. It is a functional system with exactly the same software and ports tree as found on any other architecture OpenBSD runs on. As for Zaurus hardware, 3.7 ships with support for its display, keyboard, touchscreen, Compact Flash slot, and the USB controller. This means that if your USB device works on your desktop or laptop, you can expect it to work on the Zaurus. The same goes for Compact Flash devices. Development is already progressing post-3.7. Power management is constantly being improved, mostly thanks to Uwe Stuehler. Drivers for the rest of the onboard Zaurus hardware are being written. For example, Chris Pascoe has already provided a basic driver for the sound hardware. The Zaurus has become a popular toy among the developers, so there is a lot of interest in producing good device support. ORN: Are there any particular limitations? David Gwynne: In my opinion the biggest limitation is the need to keep Linux on the device; it is only used as a glorified boot loader for OpenBSD itself. I would love to see OpenBSD boot up when I press the power button instead of Linux. Uwe Stuehler: A minimal fraction of Linux must remain on internal flash memory in order to run OpenBSD's boot loader. Those who want to use the whole disk for OpenBSD can do that, assuming they can do well without the applications that ship with the Zaurus. The boot loader is mostly the same as on other OpenBSD platforms. It is conveniently installable via the same package installer that you would use to install OpenSSH on Linux. Once it is installed, OpenBSD can indeed start immediately every time you press the power button or reboot the Zaurus. There are intrinsic limitations of the ARM processor being used in the
Zaurus, such as the lack of a hardware floating-point unit. Our ports tree already
contains alternative software that is better optimized for integer arithmetic
(like ORN: Is there any plan to support other devices beyond the Sharp Zaurus SL-C3000? David Gwynne: The Zaurus port originally started out on the SL-C860, but was quickly moved to the C3000 due to the better onboard hardware. The intention has always been to go back and make OpenBSD work on the C860 once we're happy with our work on the C3000. In the short term, it might be easy to support the new C1000, since it is basically a C3000 without a hard disk. Support for other Zaurus handhelds should be fairly trivial once the C860 and C3000 are both working, since the same devices and CPUs on these handhelds are used on other models, too. Uwe Stuehler: Despite there being certainly at least a little bit of interest, I think realistically nothing much apart from recent Zaurus models has a chance to be supported anytime soon. ORN: This release introduce Marc Espie: Obvious con: Pros: a lot of modern C++ code now compiles. There's no way to avoid recent
ORN: Do you plan to update to Marc Espie: Nope. ORN: In a previous interview I did with Richard
Stallman, he stated that Marc Espie: OK, this might be the scoop you're looking for. This is not news to me. This is definitely not good news. In this instance, Richard was all talk, and no action. There is absolutely nothing going on that indicates that ProPolice will be a part of future GCC releases. Let me publicize that more. The GCC people are going to say they haven't had any luck collaborating with Etoh Hiroaki. I've inquired into the problem, I've offered to help by acting as liaison between the GCC developers and Etoh Hiroaki. I got a lukewarm response at best. Right now, the ProPolice technology is not considered stable enough for inclusion in GCC. Technically, the stuff Etoh does is a nice hack that plays interesting games with GCC internals. Those games are actually not really supported inside of GCC. (ProPolice assumes the frames have a given internal representation, which is 99 percent the case in practice, but is not part of the GCC internals' contract.) And this is it--this is as far as ProPolice integration so far has gone. Richard asked for ProPolice to be integrated, which does not cost him anything. It's just a PR move, as far as I'm concerned. No resources have been devoted in actually pushing for ProPolice to be integrated. The GCC people are handling other stuff, which is more important for them, which is something I quite understand. There is absolutely nothing going on where ProPolice integration is concerned. Yes, there's a lot of work. Ask the OpenBSD developers how many issues we
had to solve in Well, right now, ProPolice stops at GCC 3.4. No one has a working ProPolice for GCC 4.0. No one is devoting enough resources to ensure this will happen. And you think we will switch to GCC 4.0? Think again. Instead, GCC 4.0 will ship with a framework called No ProPolice in sight. Federico Biancuzzi manages the BSD section of the Italian magazine Linux&C. As a freelancer, he writes for ONLamp, LinuxDevCenter, and NewsForge. Return to the BSD DevCenter.
What's your favorite new feature of OpenBSD 3.7?
You must be logged in to the O'Reilly Network to post a talkback. Trackbacks appear below the discussion thread. Showing messages 1 through 1 of 1.
Trackbacks
Comments made on other sites via trackbacks appear below. OpenBSD 3.7 Released 2005-05-20 16:12:38 Yes yes. Everyones favourite secure operating system has had a new release. There are oodles of new features, including tons of new and improved wireless drivers, new ports for the Sharp Zaurus and SGI, improvements to OpenSSH, OpenBGPD, OpenNTPD, C... OpenBSD 3.7 Released 2005-05-20 09:57:32 The OpenBSD project has released version 3.7 of OpenBSD, a free and highly secure open source operating system. New features in this release include support for Zaurus and SGI platforms, enhanced 64-bit CPU support |
Sponsored by: |
Contact Us | Advertise with Us | Privacy Policy | Press Center | Jobs Copyright © 2000-2005 O’Reilly Media, Inc. All Rights Reserved. |