Why build it at NCSA instead of just upgrading Kraken? Because:
1) Kraken is an XT5, not an XE system - the associated changes of an upgrade from XT to XE would be very large. 2) NCSA already has a big machine room (that they just built) to support that scale of a system. Does ORNL have enough additional power and cooling capacity to support Keeneland, Jaguar, and growing Kraken by an order of magnitude in size? 3) ORNL is already installing Keeneland, an NSF track 2 system this coming year 4) The larger political implications to NSF of failing the $200M track 1 grant that was awarded to NCSA would probably be catastrophic.
As opposed to inexpensive IBM maintenance contracts? All of the big HPC machines are expensive to run and maintain, and NCSA/NSF would be incredibly foolish if they haven't already budgeted for this.
Pretty surprising development, given the length of time that IBM and NCSA had been working on this. Dropping a contract like this essentially puts into question IBM's costing on future contract bids, so it's not something that they'd do lightly. It'll be interesting to see the scuttlebutt that comes out afterward to see how much of this was technical shortcomings and how much pure financial considerations from IBM. Maybe since IBM already got their big publicity for Power7 from Watson, they're being more profit-concious on future Power systems so they don't tie themselves to margins that are too low.
From the NCSA side, there will certainly be a fallback of some sort - NSF and NCSA are already working out those details according to recent reports. I'd guess that they go with a large Cray XE6 system, given that a pretty sizeable version of that system is already being stood up and ironed out (the Sandia/Los Alamos Cielo system), and Cray has a lot of history successfully standing up big systems (e.g. ORNL Jaguar, Sandia Red Storm, etc.). SGI Altix is the other alternative, I guess, and there's a pretty big one up at NASA now, though that'd probably be a riskier proposition than Cray IMO, and I expect that NCSA and NSF are going to be pretty risk averse on following up on this.
Palacios can run on real x86 hardware or on QEMU. In fact, most of our development is done on QEMU, which is open source. The VMWare image was something we did on the original 1.0 release just to help people get started running it and haven't done since, but VMware has *never* been required for development.
Palacios lives inside the lightweight kernel host. Applications that want to run natively on the lightweight kernel without virtualization can at *no* penalty. Applications that are willing to pay the performance penalty of Linux can run Linux as a guest at a nominal additional virtualization cost. That way, applications that demand peak hardware performance get it, applications that need more complex OS services get it, and the downtimes associated with a complete system reboot are avoided.
In addiiton, the costs of something like Linux to a scientific application can be much higher for than many might expect. Cray's target was to get application performance on their Compute Node Linux within 10% of Catamount performance; they did so for most (but not all) of their apps as I understand it, but had to spend a significant effort to even get within 10%.
We're happy to leverage their hard work, however, so that users who want CNL can boot it on top of our VMM, while users who don't can get done faster or save some of their allocated cycles. I sometimes wonder if ORNL wished they had been running a VMM/LWK on Jaguar when Roadrunner beat them on the SC 2008 Top 500 list by 0.5%. Being able to use the lightweight kernel for Top500 Linpack runs and CNL for running apps that needed it might have come in handy for them then.:)
Finally, our experience has been that a small, simple, open-source LWK/VMM combination is a very powerful platform for OS and hardware HPC research - it provides a simple, understandable, and powerful base for addressing HPC systems problems (e.g. fault tolerance) without the complexity of trying to do that in, for example, Linux.
Virtualization offers a number of potential advantages. A paper we have had accepted to IPDPS 2010 that enumerates more of them, but a few advantages quickly:
1. The combination of a lightweight kernel and a virtualzation layer allows applications to choose which OS they run on and how much they pay in terms of performance for the OS services they needs. Because Palacios is hosted inside an existing lightweight kernel that presents minimal overhead to applications that run directly on it, applications that don't need the services (and overheads) of full-featured OS like Linux can run directly on the LWK/VMM with minimal overhead. On the other hand, apps or app frameworks that need higher-level OS services (e.g. shared libraries) can run the OS they need as a virtualized guest on top of the LWK/VMM. Because doing an actual kernel reboot on a machine like Red Storm is very time-consuming, (compared to a guest OS boot), this is a substantial advantage.
2. Mean-time-to-interrupt on some of the most recent large-scale systems is much less than a single day, and virtualization is potentially useful technique for addressing fault tolerance and resilience issues in HPC systems, assuming that its overhead at scale can be kept small.
3. A small open-source LWK/VMM combination enables a wide range of OS and hardware research on HPC systems both by being a small, understandable, low-overhead platform, and by providing a way to support existing HPC OSes and applications while enabling OS and hardware innovation.
4. A number of others I won't mention right now as they're being actively researched here at UNM, and by my colleagues at Northwestern and Sandia.;)
We're not trying to hide anything, and so I will admit to being surprised by this (anonymous) accusation. To address the anonymous coward's concerns, however:
1. Actual users of supercomputers care most about application run time because applications are what scientists run, not micro-benchmarks. As a result, our paper and research more generally focuses on the runtime penalty to real applications (e.g. Sandia's CTH code) as opposed to focusing on optimizing micro-benchmarks that aren't what real users of these systems care about.
2. Micro-benchmarks do provide useful information about the exact costs of various low-level operations, however, to the extent that they can show you what is causing the application slowdowns you do see. They also can potentially help understand how proposed changes might impact applications other than the ones we were able to run in our limited access to the production Red Storm system. Because of this, the paper the anonymous coward above refers to explicitly measures and presents micro-benchmark latency and bandwidth overheads. Specifically, it cites the latency cost on both Red Storm's SeaStar NIC (5 or 11 microseconds, depending on how you virtualize paging) and QDR Infiniband (0.01 microseconds). It also presents a bandwidth curve to fully characterize virtualization's cost over the full range of potential message sizes on SeaStar. (IB is less expensive to virtualize than SeaStar, because IB doesn't have interrupts that Palacios must virtualize on the messaging fast path where as SeaStar does, at least when running Cray's production firmware).
We're very up front about the costs of virtualization because we are well aware that there is no such thing as a free lunch. Virtualization provides a number of potential advantages in supercomputing systems, for example in terms of dealing with node failures, providing a small open-source platform for OS research and innovation on supercomputing systems, handling applications with different OS feature and performance requirements, and a variety of other things. However, it does come with a cost to applications and application scientists that has to be weighed against its potential benefits.
ACSI Red Storm normally runs a dedicated lightweight kernel called Catamount, not Linux. Similarly, the IBM BlueGene systems run the IBM compute node kernel, not Linux. Linux is used on some supercomputers, even some of the biggest ones (e.g. ORNL's Jaguar system) but the performance penalty of using Linux as opposed to a lightweigher kernel for some applications can be substantial(e.g. > 10%).
Actually, the micro-endgame in Go is pretty well understood. Combinatorial game theory does a good job of setting up optimal endgame moves, better than many pros can play. MoGo, the program that played yesterday generally plays a pretty reasonable endgame.
Uh, you'll note I was referring to the media access methods, not the spread spectrum technologies. 802.11a is still a shared-media system, so you're going to have collisions and such no matter what spread-spectrum technology you use. You're right that I don't know much about ODFM, though of course I do know what DSSS is.
802.11a, which operates in the 5GHz range, is not a significantly different meda access protocol than the one used in 2.5GHz 802.11b. If there are enough people moving into the 5GHz range, then collisions and such are inevitable there. 5GHz is still preferable to 2.5GHz, however. One reason the 2.5GHz range was given to unlicensed spread-spectrum transmitters because it's so noisy to begin with - there are a lot of devices that radiate in the 2.5 range that don't follow *any* network media access protocol like CSMA/CA, like a microwave oven. At least when two access points fight over a single frequency, they might be able to do so in a structured way that's relatively fair to each transmitter. Microwaves, however, don't "play nice.":)
Apparently the 5GHz band is cleaner than the 2.5GHz band, so at least the background noise will be less, and hopefully the transmitters in the range will all use a common media access protocol so that the interference that is there will be more cooperative and not just straight radio interference. One possible solution to this problem might be a configuration protocol is created to allow different access points in the area to automatically negotiate which channels they will use, so there isn't even the collisions that happen when to WiFi devices share the same channel. I've never heard of anything like this before, however.
As far as research kernels go, microkernels are somewhat out of favor - the performance loss is significant and the benefits to stability, fault tolerance, and ease of development have never been as significant as microkernel reseachers touted them to be. Well-designed, modular kernels typically perform better than microkernel systems and can be as easy or easier to develop and maintain.
As far as OS X's microkernel goes, my understanding is that it's based on Mach 2.5, which is not a pure microkernel. Mach 2.5 was an older version of Mach from before it became a pure microkernel - essentially a BSD kernel with the Mach message passing and memory and task management interfaces added to it. As other posters have said, NeXTStep was also Mach 2.5 based. Mach 3.0, upon which the Hurd microkernel is based, was a pure microkernel without the UNIX system calls in kernel.
Coming from a similar viewpoint, I'd like to completely agree. I'm finishing my PhD in the CS department at the University of Arizona, and will be taking a faculty position at another university this fall. In completing my degree, I've had the opportunity to teach several undergraduate classes, and to grade for several graduate ones. It is, in many ways, an eye-opening experience. I sincerely enjoy teaching, but the amount of cheating that goes on is surprising, at both the graduate and undergraduate level.
As an instructor, I worked very hard both in class and out of class to help students learn, with a combination of large amounts of time preparing lectures, generous and flexible office hours, and interesting assignments. The students that take advantage of this are a complete joy, and make teaching a wonderful and worthwhile experience. Not all students do, and the most infuriating students are those who, despite all of your encouragement to come by and get help, visit your office exactly once - at the end of the semester to beg for points.
What most of the people reading here seem to be failing to understand is that while *they* went to school to learn, and in fact most students do, some students don't. These students want the CS degree so that they can go out and make $$$, and don't really care if they learn anything on the way. This is particularly true in introductory courses before students find that they'll actually have to *work* to get a computer science degree.
To make a computer science degree meaningful, professors have to make sure that the students who get the degree have earned it, and *can do things themselves*. This means that, particularly in introductory classes, students *must do their own work* so that they aquire the skills that can be useful in group projects later. These classes almost invariably have large amounts of help from professors, TAs, and other assistants available for those students who need it. Students who aren't *willing* to work need to be caught soon and not let slide by so that they don't hold up the more advanced classes later. Of course, students who are having trouble but *are* willing to work *must* be helped. Helping these students and showing them just how cool CS is and teaching them how to do cool things with computers on their own is one of the true joys of teaching computer science.
The best moment at the USENIX technical conference this year, by far, was the spantaneous 5 minute standing ovation given by the entire conference when Steven's family was presented with a lifetime achievement award for Mr. Steven's excellent work.
It'll clearly be a challenge-response sort of security scheme: For example:
"ICraveTV Canadian-ness Challenge: Complete the following sentence: "Beauty, ____!"
And of course, Hockey questions could be their bread-and-butter....
Re:chess is not that hard, Go is
on
Solving Chess?
·
· Score: 1
Oops, Handtalk is Japanese 3k, (which is roughtly American 4k/5k), and Janice Kim only gave it 25 stones and beat it, not 35. That'll teach me to double-check before I post.:(
Re:chess is not that hard, Go is
on
Solving Chess?
·
· Score: 3
Now, take the game of Go... it's much harder to figure out the victory condition. There are currently no computer Go program that play very very well (I think the best if first dan?)
Not even that good. Handtalk, one of the best programs, has a 5 kyu Japanese diploma, but most people agree that it is not even that good. For reference, I'm a American 5 kyu, and have only been playing 2 years. A pro player, the equivalent of a chess grandmaster, would probably give me between 9 and 13 free moves at the start of the game to make it reasonably even.
In a public demonstration, Janice Kim (one of the few western-born pros, and far from one of the top pros) gave Handtalk a handicap of 35(!) free moves at the start of the game, and then beat it. The current best program, Go4++, is perhaps two or three stones (free moves) stronger than Handtalk, but that's still a *long* way from the chess equivalent of grandmaster.
Now, I'm not saying that Go is a "better" game, but computationally, Go is a whole different scope of problem than Chess.
If the patch is from Lucent, it contains two things: a small source file to hook into the pcmcia code, and a binary library that that source file refers to. Look in/lib and you'll find libhcf.a, which contains the binary code for working the Wavelan/IEEE hardware. I *think* there may be some source-only drivers around, but not from Lucent.
We've been using the Lucent WaveLAN 11Mbps cards here, and they work like a charm. Lucent supplies (binary) drivers for their cards which work quite well. The only annoyance is that the access points have to be configured remotely VIA M$ Windoze, but it all works really well. In addition, they interoperate with the Apple iBook/AirPort stuff, too, IIRC.
Slashdot Mirror
Call immediately to get your ObamaGun! Thanks, Obama!
Why build it at NCSA instead of just upgrading Kraken? Because:
1) Kraken is an XT5, not an XE system - the associated changes of an upgrade from XT to XE would be very large.
2) NCSA already has a big machine room (that they just built) to support that scale of a system. Does ORNL have enough additional power and cooling capacity to support Keeneland, Jaguar, and growing Kraken by an order of magnitude in size?
3) ORNL is already installing Keeneland, an NSF track 2 system this coming year
4) The larger political implications to NSF of failing the $200M track 1 grant that was awarded to NCSA would probably be catastrophic.
As opposed to inexpensive IBM maintenance contracts? All of the big HPC machines are expensive to run and maintain, and NCSA/NSF would be incredibly foolish if they haven't already budgeted for this.
Pretty surprising development, given the length of time that IBM and NCSA had been working on this. Dropping a contract like this essentially puts into question IBM's costing on future contract bids, so it's not something that they'd do lightly. It'll be interesting to see the scuttlebutt that comes out afterward to see how much of this was technical shortcomings and how much pure financial considerations from IBM. Maybe since IBM already got their big publicity for Power7 from Watson, they're being more profit-concious on future Power systems so they don't tie themselves to margins that are too low.
From the NCSA side, there will certainly be a fallback of some sort - NSF and NCSA are already working out those details according to recent reports. I'd guess that they go with a large Cray XE6 system, given that a pretty sizeable version of that system is already being stood up and ironed out (the Sandia/Los Alamos Cielo system), and Cray has a lot of history successfully standing up big systems (e.g. ORNL Jaguar, Sandia Red Storm, etc.). SGI Altix is the other alternative, I guess, and there's a pretty big one up at NASA now, though that'd probably be a riskier proposition than Cray IMO, and I expect that NCSA and NSF are going to be pretty risk averse on following up on this.
Palacios can run on real x86 hardware or on QEMU. In fact, most of our development is done on QEMU, which is open source. The VMWare image was something we did on the original 1.0 release just to help people get started running it and haven't done since, but VMware has *never* been required for development.
Doh, my mistake, Roadrunner beat Jaguar by a little less than 5% in the SC08 Top500 list, not 0.5%. Still, I do wonder. :)
Palacios lives inside the lightweight kernel host. Applications that want to run natively on the lightweight kernel without virtualization can at *no* penalty. Applications that are willing to pay the performance penalty of Linux can run Linux as a guest at a nominal additional virtualization cost. That way, applications that demand peak hardware performance get it, applications that need more complex OS services get it, and the downtimes associated with a complete system reboot are avoided.
In addiiton, the costs of something like Linux to a scientific application can be much higher for than many might expect. Cray's target was to get application performance on their Compute Node Linux within 10% of Catamount performance; they did so for most (but not all) of their apps as I understand it, but had to spend a significant effort to even get within 10%.
We're happy to leverage their hard work, however, so that users who want CNL can boot it on top of our VMM, while users who don't can get done faster or save some of their allocated cycles. I sometimes wonder if ORNL wished they had been running a VMM/LWK on Jaguar when Roadrunner beat them on the SC 2008 Top 500 list by 0.5%. Being able to use the lightweight kernel for Top500 Linpack runs and CNL for running apps that needed it might have come in handy for them then. :)
Finally, our experience has been that a small, simple, open-source LWK/VMM combination is a very powerful platform for OS and hardware HPC research - it provides a simple, understandable, and powerful base for addressing HPC systems problems (e.g. fault tolerance) without the complexity of trying to do that in, for example, Linux.
Virtualization offers a number of potential advantages. A paper we have had accepted to IPDPS 2010 that enumerates more of them, but a few advantages quickly:
1. The combination of a lightweight kernel and a virtualzation layer allows applications to choose which OS they run on and how much they pay in terms of performance for the OS services they needs. Because Palacios is hosted inside an existing lightweight kernel that presents minimal overhead to applications that run directly on it, applications that don't need the services (and overheads) of full-featured OS like Linux can run directly on the LWK/VMM with minimal overhead. On the other hand, apps or app frameworks that need higher-level OS services (e.g. shared libraries) can run the OS they need as a virtualized guest on top of the LWK/VMM. Because doing an actual kernel reboot on a machine like Red Storm is very time-consuming, (compared to a guest OS boot), this is a substantial advantage.
2. Mean-time-to-interrupt on some of the most recent large-scale systems is much less than a single day, and virtualization is potentially useful technique for addressing fault tolerance and resilience issues in HPC systems, assuming that its overhead at scale can be kept small.
3. A small open-source LWK/VMM combination enables a wide range of OS and hardware research on HPC systems both by being a small, understandable, low-overhead platform, and by providing a way to support existing HPC OSes and applications while enabling OS and hardware innovation.
4. A number of others I won't mention right now as they're being actively researched here at UNM, and by my colleagues at Northwestern and Sandia. ;)
We're not trying to hide anything, and so I will admit to being surprised by this (anonymous) accusation. To address the anonymous coward's concerns, however:
1. Actual users of supercomputers care most about application run time because applications are what scientists run, not micro-benchmarks. As a result, our paper and research more generally focuses on the runtime penalty to real applications (e.g. Sandia's CTH code) as opposed to focusing on optimizing micro-benchmarks that aren't what real users of these systems care about.
2. Micro-benchmarks do provide useful information about the exact costs of various low-level operations, however, to the extent that they can show you what is causing the application slowdowns you do see. They also can potentially help understand how proposed changes might impact applications other than the ones we were able to run in our limited access to the production Red Storm system. Because of this, the paper the anonymous coward above refers to explicitly measures and presents micro-benchmark latency and bandwidth overheads. Specifically, it cites the latency cost on both Red Storm's SeaStar NIC (5 or 11 microseconds, depending on how you virtualize paging) and QDR Infiniband (0.01 microseconds). It also presents a bandwidth curve to fully characterize virtualization's cost over the full range of potential message sizes on SeaStar. (IB is less expensive to virtualize than SeaStar, because IB doesn't have interrupts that Palacios must virtualize on the messaging fast path where as SeaStar does, at least when running Cray's production firmware).
We're very up front about the costs of virtualization because we are well aware that there is no such thing as a free lunch. Virtualization provides a number of potential advantages in supercomputing systems, for example in terms of dealing with node failures, providing a small open-source platform for OS research and innovation on supercomputing systems, handling applications with different OS feature and performance requirements, and a variety of other things. However, it does come with a cost to applications and application scientists that has to be weighed against its potential benefits.
ACSI Red Storm normally runs a dedicated lightweight kernel called Catamount, not Linux. Similarly, the IBM BlueGene systems run the IBM compute node kernel, not Linux. Linux is used on some supercomputers, even some of the biggest ones (e.g. ORNL's Jaguar system) but the performance penalty of using Linux as opposed to a lightweigher kernel for some applications can be substantial(e.g. > 10%).
Actually, the micro-endgame in Go is pretty well understood. Combinatorial game theory does a good job of setting up optimal endgame moves, better than many pros can play. MoGo, the program that played yesterday generally plays a pretty reasonable endgame.
All that's been found was a mis-inventoried disk at Sandia. Two classified items are still missing at LANL and classified work is still stopped there.
> the FORTH REICH ENSUES!!!!!
All hail Charles Moore
Uh, you'll note I was referring to the media access methods, not the spread spectrum technologies. 802.11a is still a shared-media system, so you're going to have collisions and such no matter what spread-spectrum technology you use. You're right that I don't know much about ODFM, though of course I do know what DSSS is.
802.11a, which operates in the 5GHz range, is not a significantly different meda access protocol than the one used in 2.5GHz 802.11b. If there are enough people moving into the 5GHz range, then collisions and such are inevitable there. 5GHz is still preferable to 2.5GHz, however. One reason the 2.5GHz range was given to unlicensed spread-spectrum transmitters because it's so noisy to begin with - there are a lot of devices that radiate in the 2.5 range that don't follow *any* network media access protocol like CSMA/CA, like a microwave oven. At least when two access points fight over a single frequency, they might be able to do so in a structured way that's relatively fair to each transmitter. Microwaves, however, don't "play nice." :)
Apparently the 5GHz band is cleaner than the 2.5GHz band, so at least the background noise will be less, and hopefully the transmitters in the range will all use a common media access protocol so that the interference that is there will be more cooperative and not just straight radio interference. One possible solution to this problem might be a configuration protocol is created to allow different access points in the area to automatically negotiate which channels they will use, so there isn't even the collisions that happen when to WiFi devices share the same channel. I've never heard of anything like this before, however.
-Patrick Bridges
A few points:
As far as research kernels go, microkernels are somewhat out of favor - the performance loss is significant and the benefits to stability, fault tolerance, and ease of development have never been as significant as microkernel reseachers touted them to be. Well-designed, modular kernels typically perform better than microkernel systems and can be as easy or easier to develop and maintain.
As far as OS X's microkernel goes, my understanding is that it's based on Mach 2.5, which is not a pure microkernel. Mach 2.5 was an older version of Mach from before it became a pure microkernel - essentially a BSD kernel with the Mach message passing and memory and task management interfaces added to it. As other posters have said, NeXTStep was also Mach 2.5 based. Mach 3.0, upon which the Hurd microkernel is based, was a pure microkernel without the UNIX system calls in kernel.
Coming from a similar viewpoint, I'd like to completely agree. I'm finishing my PhD in the CS department at the University of Arizona, and will be taking a faculty position at another university this fall. In completing my degree, I've had the opportunity to teach several undergraduate classes, and to grade for several graduate ones. It is, in many ways, an eye-opening experience. I sincerely enjoy teaching, but the amount of cheating that goes on is surprising, at both the graduate and undergraduate level.
As an instructor, I worked very hard both in class and out of class to help students learn, with a combination of large amounts of time preparing lectures, generous and flexible office hours, and interesting assignments. The students that take advantage of this are a complete joy, and make teaching a wonderful and worthwhile experience. Not all students do, and the most infuriating students are those who, despite all of your encouragement to come by and get help, visit your office exactly once - at the end of the semester to beg for points.
What most of the people reading here seem to be failing to understand is that while *they* went to school to learn, and in fact most students do, some students don't. These students want the CS degree so that they can go out and make $$$, and don't really care if they learn anything on the way. This is particularly true in introductory courses before students find that they'll actually have to *work* to get a computer science degree.
To make a computer science degree meaningful, professors have to make sure that the students who get the degree have earned it, and *can do things themselves*. This means that, particularly in introductory classes, students *must do their own work* so that they aquire the skills that can be useful in group projects later. These classes almost invariably have large amounts of help from professors, TAs, and other assistants available for those students who need it. Students who aren't *willing* to work need to be caught soon and not let slide by so that they don't hold up the more advanced classes later. Of course, students who are having trouble but *are* willing to work *must* be helped. Helping these students and showing them just how cool CS is and teaching them how to do cool things with computers on their own is one of the true joys of teaching computer science.
The best moment at the USENIX technical conference this year, by far, was the spantaneous 5 minute standing ovation given by the entire conference when Steven's family was presented with a lifetime achievement award for Mr. Steven's excellent work.
"ICraveTV Canadian-ness Challenge: Complete the following sentence: "Beauty, ____!"
And of course, Hockey questions could be their bread-and-butter....
Oops, Handtalk is Japanese 3k, (which is roughtly American 4k/5k), and Janice Kim only gave it 25 stones and beat it, not 35. That'll teach me to double-check before I post. :(
Not even that good. Handtalk, one of the best programs, has a 5 kyu Japanese diploma, but most people agree that it is not even that good. For reference, I'm a American 5 kyu, and have only been playing 2 years. A pro player, the equivalent of a chess grandmaster, would probably give me between 9 and 13 free moves at the start of the game to make it reasonably even.
In a public demonstration, Janice Kim (one of the few western-born pros, and far from one of the top pros) gave Handtalk a handicap of 35(!) free moves at the start of the game, and then beat it. The current best program, Go4++, is perhaps two or three stones (free moves) stronger than Handtalk, but that's still a *long* way from the chess equivalent of grandmaster.
Now, I'm not saying that Go is a "better" game, but computationally, Go is a whole different scope of problem than Chess.
For more information on Go, email me or check out the home page of the American Go Association.
Patrick Bridges
If the patch is from Lucent, it contains two things: a small source file to hook into the pcmcia code, and a binary library that that source file refers to. Look in /lib and you'll find libhcf.a, which contains the binary code for working the Wavelan/IEEE hardware. I *think* there may be some source-only drivers around, but not from Lucent.
We've been using the Lucent WaveLAN 11Mbps cards here, and they work like a charm. Lucent supplies (binary) drivers for their cards which work quite well. The only annoyance is that the access points have to be configured remotely VIA M$ Windoze, but it all works really well. In addition, they interoperate with the Apple iBook/AirPort stuff, too, IIRC.