> A disproportionate number of the new recruits > are in computer-related occupations.
Really? I wouldn't be surprised if today's programmers are regarded as something akin to war criminals in the far future. With the trend of putting "Microsoft Bob" and friends in charge of more and more of our essential social infrastructure, it's only a matter of time before it all falls down.
"You seem to have forgotten how to run your civilization. Would you like to choose a new one?"
I'm not sure I'd want to wake up wearing my "Code Monkey" T-shirt in a world after that crack-up. They'd probably put me on trial.
- Tim
Re:Generation X phenomenon
on
Hacker Survey
·
· Score: 1
> very gen x of you.
I suppose I should mutter "whatever" now and go back to staring at the TV.
- Tim
Generation X phenomenon
on
Hacker Survey
·
· Score: 2, Interesting
This survey was very interesting, and I'd like to applaud the authors for taking the time to do it. However, I have some sort of bizarre genetic defect that causes me to get cranky whenever someone uses the phrase "Generation X", so I can't help but foam a bit about slide 21 on v0.73 of the slides on the OSDN site.
The slide is titled "Open Source is a Generation X phenomenon". Don't draw too many conclusions from this data - although most Free/Open Source programmers may be 21-38 years old now, I'm sure plenty of those larval hackers who are presently younger will join in the fun once they've got some more coding experience under their belts.
I don't think the whole hacking phenomenon will die out in 60 years. So, although the graph shows a peak, what I think we're witnessing is the beginning of a phenomenon that will continue indefinitely (or at least until debuggers are made illegal).
Oh, and I hate this whole "Generation foo" marketing thing.
> So we should all give up and accept it as a way of life?
That is one option. On the other hand, if you'd still like to do research, and your goal is to produce useful knowlege (and not to become the big fish in some small pond) you might try the following:
Try to set a good example by giving credit where credit is due. Remeber that other people can have good ideas, too.
Using political influence to marginalize other researchers is particularly reprehensible, because it makes the peer-review system less efficient at identifying useful knowlege. Don't sink to that level.
Oh, and remember to keep your sense of humor - you'll need it.
I had a GPL'd project that was fortunate enough to attract the contributions of a small handful of generous people a while back. In one case I handled the contributions well, and everyone was happy. In another case, I did not handle it well at all, and I feel bad about it to this day. Here's what I did; perhaps my story will help you out:
The project was so closely intertwined with my real-life job that I found myself leaving it untouched for long periods of time as work dragged me in other directions.
One patch I got was a clear win. It came during a period in which I had time to integrate it quickly, so I did, and made a new release. This was a good case - it made me feel happy and I hope it made the contributor happy, too.
However, there was another case where the patch wasn't so clear a win. I thought I could implement a better solution, so I didn't integrate it. Then, I got dragged away from the project for a very long time.
I never wrote back to the contributor - I didn't want to create bad feelings by criticizing his solution, so I took the easy way out. (Mistake.) Ages later, I announced that I was stopping work on the project because I was changing jobs. The contributor was pretty upset that I hadn't used his patch in all that time.
So, my advice is, if you're given a patch that you don't want to use, don't use it. Tell the contributor what's wrong with it right away. Saying 'no' to someone may be hard, but leaving them hanging is worse.
Look on the good side, if your criticism is constructive, perhaps they'll fix their patch so you can use it.
I'm not brave enough to buy a laptop and put my favorite OS on it.
I've been lusting after a number of tiny sub-notebooks for a while now. But I'm too afraid to pay $1600US for a laptop when I'm not sure I'm going to be able to get it to work very will with the Linux kernel.
Can I expect to be able to return the laptop (with the hard drive in some sort of pseudo-penguined state)? The "terms and conditions" I've been reading on online-store sites seem pretty unfriendly - stuff about having to ask for the seller's permission (Return Material Authorization) to return an item, and promises that the seller will keep some of my money if they decide I've "abused" their product.
Linux-on-laptops sites like www.linux-laptop.net give me some confidence, but the models they list are often older than the newer models I see on sale. What if the newer models have some sort of fatal show-stopping quirk? I don't have money to burn, and I don't want to be stuck with a laptop that runs only windoz.
Is there a way I can put money down on a tiny Fujitsu or Sony sub-notebook, try to put Debian GNU/Linux on it, and then return it for a full refund if I fail?
I was lucky enough to experience a similar exhibit in back in 1999: it was called
Videotopia. Videotopia had its own Slashdot story a while back.
It was a room full of 1980's coin-op games - it was like being dropped back into an old-time arcade (except the air wasn't thick with cigarette smoke - times have changed.)
I got to play Computer Space and Pong, along with many other classics like Tempest and Asteroids.
Unfortunately, the tour schedule on the videotopia web site has no entries past 1999. There's still some interesting pictures of games to drool over, though.
These are my favorite Maryland Hamfests, in order of preference:
Greater Baltimore Hamboree and Computerfest - the event mentioned by the previous poster. A big two-day event in April in Timonium. See http://gbhc.org/.
BRATS Ham/ComputerFest. A big one-day event in July in Timonium. See http://www.bratsatv.org/hamfest.html.
CARA Hamfest. I always enjoy this event, even though it's relatively small. Occurs in September, in West Friendship. See http://www.qsl.net/cara/
FARFest. This one used to be very big, but their move to Bowie a couple of years ago greatly decreased their attendance. Occurs in September. See http://www.amateurradio-far.org/
There are events in other US states too, of course. See http://www.arrl.org/hamfests.html. Some Virginia hamfests should also be convenient for folks living in the DC area.
Ham fests are indeed the answer. Often, companies dump their old equipment there, so you can expect to find industrial-grade equipment that you won't see at your average neighbor's yard sale. I've seen old hardware RAID controllers, SPARCstations, dumb terminals, big rack-mount Ethernet hubs and switches, etc.
There are several Hamfests in the DC area every year. You can search for hamfests throughout the US at http://www.arrl.org/hamfests.html.
Note that some hamfests are bigger and better than others, so your mileage may vary.
Certainly, running bind in a chroot/jail environment is a good idea. With LOMAC or without, it's always wise to have defense-in-depth. It's also a good idea to run only carefully audited code whenever possible, for the same reason.
However, your question ("why not just chroot jail bind") implies that bind harbors the only exploitable hole in your system. In reality, holes could be in a number of applications besides bind, and it's very hard to know where all of them are. LOMAC automatically applies itself to all processes on your system, so you don't have to identify the dangerous ones before you run LOMAC in order to get protection.
LOMAC also provides some kinds of integrity protection that chroot can't. For example, LOMAC provides integrity protection in cases where the administrator unknowingly executes a Trojan horse with root privilege while doing day-to-day administration tasks. This isn't something chroot is designed to do.
So, defense-in-depth is good. Chroot. Audit your code. Use LOMAC, if you like.
The GPL vs. BSDL debate aside, I'd like to point out that LOMAC does not include TrustedBSD code. However, I've been talking to Robert Watson, TrustedBSD's creator, about porting LOMAC to TrustedBSD's framework sometime after I finish the FreeBSD port. Robert and I both work for NAI Labs; he's presently mirroring LOMAC to help with the slashdot effect.
We'll both be at the Kernel Security Extension BOF at the upcoming USENIX Annual Technical Conference this June. We'll be presenting TrustedBSD and LOMAC papers in the FreeNIX track as well. So, you can come interrogate us there, if you like.:^)
> is there a solution to provide high level access via SSH or something,
Yes, LOMAC releases since v1.0.5 provide an exception that allows remote administration via SSH. The no-remote-administration restriction was a problem in earlier prototypes, though.
> if that is true, you won't be able to ssh into your box
Yes, this was a problem with the early LOMAC prototypes. Fortunately, starting with v1.0.5, LOMAC has provided an exception to allow remote administration via SSH.
> I installed it on my debian system, `apt-get upgrade` would fail, because the.debs would have been downloaded over the network.
This is a good question. Remaining compatible with traditional methods of administration is important to LOMAC. Ultimately, I'd like to have apt-get work with LOMAC just as it does without.
Presently, LOMAC provides a partial solution: there is a program called "lup" you can use to change a level-1 downloaded file (like a.deb) to a level-2 file. (The LOMAC manual describes how lup is implemented to avoid providing a backdoor to malicious users.)
This solution is sub-optimal, because the administrator has to manually bless the.deb's before installation. A better solution might be to set an exception for the apt-get program, stating that anything apt-get downloads is automatically safe to put at level 2. This should allow apt-get to run without manual intervention, as it does without LOMAC.
LOMAC has a mechanism for providing this kind of exception. I haven't set it for apt-get yet, but now that you've pointed it out, I'll consider it. Thanks for the feedback!
Thanks for giving LOMAC a shot; I'm sorry you ran into problems. The early versions of LOMAC did prevent remote administration, as you describe. However, LOMAC releases since 1.0.5 provide an exception to allow remote administration via SSH.
LOMAC is my project, and I was among the NAI Labs contractors working on the NSA's SELinux project for a short while, too. SELinux is indeed an excellent technology. I've found SELinux to be extremely stable - I never had any of the released versions of SELinux crash on me in my (roughly) 6 months of usage.
The NSA's SELinux project and NAI Labs' LOMAC project have different goals. SELinux is designed to provide powerful features like extremely-fine-grained access control and a time-tested highly-general Flask architecture. LOMAC is designed to remain compatible with existing Linux kernels and software, and work without configuration, even at the cost of some features.
So, the LOMAC LKM is completely specialized towards supporting a single, simple, coarse-grained form of access control. However, it can be loaded into unmodified off-the-CD-ROM Linux kernels, and you don't have to configure it to recognize your local users and applications. SELinux provides many more powerful features, but it requires you do some configuration, and to patch your kernel and some of your applications.
It's a tradeoff. Depending on your requirements, you may prefer different choices along the features/compatibility line.
As for the comparison with the immutable flag, LOMAC provides a more flexible solution that allows admins to modify critical files that are immutable to normal users. LOMAC also provides a mechanism to prevent clever attackers from using Trojan horses or input designed to cause buffer overflows to get control of privileged processes.
There's a complete description in the LOMAC manual on ftp.tislabs.com/pub/lomac, if you're curious.
Thanks for your interest in LOMAC! LOMAC is my project, and I've talked quite a bit with Amon Ott, RSBAC's creator. We'll both be at the Kernel Security Extension BOF at the upcoming USENIX Annual Technical Conference this June.
LOMAC and RSBAC have different goals. RSBAC's goal is to provide a general framework that can (simultaneously) support a wide variety of access control mechanisms. LOMAC's goal is to be compatible with existing Linux kernels and software. There's a tradeoff between functionality and compatibility: RSBAC provides general support, but requires a kernel patch. The LOMAC LKM supports only one access control mechanism, but it can be loaded into unmodified off-the-CD-ROM Linux kernels.
I've talked to Amon Ott about porting LOMAC to RSBAC's framework. I'm hoping to do a demo-quality port this summer, if I can find the time.
Also, LOMAC allows remote administration via SSH.
- Tim Fraser, NAI Labs
Freshmeat announcements == downloads
on
Freshmeat II
·
· Score: 1
Hi!
I've had my LOMAC project on Freshmeat since June of 1999. I keep close track of LOMAC's FTP download logs, and they've shown me that nothing brings in the downloads like a release announcement on Freshmeat! Mailing list discussions, newsgroup posts, papers at conferences - none of these things seem to make a bump in the download rate. But every release announcements I've made on Freshmeat has immediately brought a nice sharp spike.
There are low-cost Alpha boxes out there: the Multia. DEC sold these as "Universal Desktop Boxes" running Linux in the mid-90's. Unfortunately, they discontinued them in 1995. You can still occasionally find them for sale on the web, though. I bought one on onsale.com last year, and I won (most of) another one in a raffle from thelinuxstore.com earlier this month. They have an appealingly compact "pizza-box" desktop tower design that looks like a fat closed laptop with integral ide, video, and sound support. They also use laptop parts (PC and PCI-bus cards), making them easy to customize. Unfortunately, the Multia CPUs are quite slow by today's standards - perhaps roughly equivalent to a Pentium 100 (just a guess) for the most common version with a "low-cost" 166MHz 21066 Alpha CPU.
You can find more info by searching the web; www.viking.org/lca.html is also a good starting-point.
If only COMPAQ would come out with an updated version with a faster CPU...
Slashdot Mirror
> A disproportionate number of the new recruits
> are in computer-related occupations.
Really? I wouldn't be surprised if today's programmers are regarded as something akin to war criminals in the far future. With the trend of putting "Microsoft Bob" and friends in charge of more and more of our essential social infrastructure, it's only a matter of time before it all falls down.
"You seem to have forgotten how to run your civilization. Would you like to choose a new one?"
I'm not sure I'd want to wake up wearing my "Code Monkey" T-shirt in a world after that crack-up. They'd probably put me on trial.
- Tim
> very gen x of you.
I suppose I should mutter "whatever" now and go back to staring at the TV.
- Tim
This survey was very interesting, and I'd like to applaud the authors for taking the time to do it. However, I have some sort of bizarre genetic defect that causes me to get cranky whenever someone uses the phrase "Generation X", so I can't help but foam a bit about slide 21 on v0.73 of the slides on the OSDN site.
The slide is titled "Open Source is a Generation X phenomenon". Don't draw too many conclusions from this data - although most Free/Open Source programmers may be 21-38 years old now, I'm sure plenty of those larval hackers who are presently younger will join in the fun once they've got some more coding experience under their belts.
I don't think the whole hacking phenomenon will die out in 60 years. So, although the graph shows a peak, what I think we're witnessing is the beginning of a phenomenon that will continue indefinitely (or at least until debuggers are made illegal).
Oh, and I hate this whole "Generation foo" marketing thing.
- Tim
Great, it's Bush's "faith-based security initiative."
- Tim
> So we should all give up and accept it as a way of life?
That is one option. On the other hand, if you'd still like to do research, and your goal is to produce useful knowlege (and not to become the big fish in some small pond) you might try the following:
Try to set a good example by giving credit where credit is due. Remeber that other people can have good ideas, too.
Using political influence to marginalize other researchers is particularly reprehensible, because it makes the peer-review system less efficient at identifying useful knowlege. Don't sink to that level.
Oh, and remember to keep your sense of humor - you'll need it.
- Tim
> That is how you become King of the A.I. Anthill.
Let me assure you, AI isn't the only branch of CS "research" where this rule holds true.
- Tim
Hi.
I had a GPL'd project that was fortunate enough to attract the contributions of a small handful of generous people a while back. In one case I handled the contributions well, and everyone was happy. In another case, I did not handle it well at all, and I feel bad about it to this day. Here's what I did; perhaps my story will help you out:
The project was so closely intertwined with my real-life job that I found myself leaving it untouched for long periods of time as work dragged me in other directions.
One patch I got was a clear win. It came during a period in which I had time to integrate it quickly, so I did, and made a new release. This was a good case - it made me feel happy and I hope it made the contributor happy, too.
However, there was another case where the patch wasn't so clear a win. I thought I could implement a better solution, so I didn't integrate it. Then, I got dragged away from the project for a very long time.
I never wrote back to the contributor - I didn't want to create bad feelings by criticizing his solution, so I took the easy way out. (Mistake.) Ages later, I announced that I was stopping work on the project because I was changing jobs. The contributor was pretty upset that I hadn't used his patch in all that time.
So, my advice is, if you're given a patch that you don't want to use, don't use it. Tell the contributor what's wrong with it right away. Saying 'no' to someone may be hard, but leaving them hanging is worse.
Look on the good side, if your criticism is constructive, perhaps they'll fix their patch so you can use it.
- Tim
I'm not brave enough to buy a laptop and put my favorite OS on it.
I've been lusting after a number of tiny sub-notebooks for a while now. But I'm too afraid to pay $1600US for a laptop when I'm not sure I'm going to be able to get it to work very will with the Linux kernel.
Can I expect to be able to return the laptop (with the hard drive in some sort of pseudo-penguined state)? The "terms and conditions" I've
been reading on online-store sites seem pretty unfriendly - stuff about having to ask for the seller's permission (Return Material
Authorization) to return an item, and promises that the seller will keep some of my money if they decide I've "abused" their product.
Linux-on-laptops sites like www.linux-laptop.net give me some confidence, but the models they list are often older than the newer models I see on sale. What if the newer models have some sort of fatal show-stopping quirk? I don't have money to burn, and I don't want to be stuck with a laptop that runs only windoz.
Is there a way I can put money down on a tiny Fujitsu or Sony sub-notebook, try to put Debian GNU/Linux on it, and then return it for a full refund if I fail?
- Tim
I was lucky enough to experience a similar exhibit in back in 1999: it was called Videotopia. Videotopia had its own Slashdot story a while back.
It was a room full of 1980's coin-op games - it was like being dropped back into an old-time arcade (except the air wasn't thick with cigarette smoke - times have changed.)
I got to play Computer Space and Pong, along with many other classics like Tempest and Asteroids.
Unfortunately, the tour schedule on the videotopia web site has no entries past 1999. There's still some interesting pictures of games to drool over, though.
- Tim
Hi!
These are my favorite Maryland Hamfests, in order of preference:
Greater Baltimore Hamboree and Computerfest - the event mentioned by the previous poster. A big two-day event in April in Timonium. See http://gbhc.org/.
BRATS Ham/ComputerFest. A big one-day event in July in Timonium. See http://www.bratsatv.org/hamfest.html.
CARA Hamfest. I always enjoy this event, even though it's relatively small. Occurs in September, in West Friendship. See http://www.qsl.net/cara/
FARFest. This one used to be very big, but their move to Bowie a couple of years ago greatly decreased their attendance. Occurs in September. See http://www.amateurradio-far.org/
There are events in other US states too, of course. See http://www.arrl.org/hamfests.html. Some Virginia hamfests should also be convenient for folks living in the DC area.
- Tim
Hi!
The University of Maryland runs Terrapin Trader. See http://www.purchase.umd.edu/ttrader/.
They had an old VAX for sale earlier this year. I was tempted to buy it, just to watch all the lights in my neighborhood dim when I turned it on.
- Tim
Hi!
Ham fests are indeed the answer. Often, companies dump their old equipment there, so you can expect to find industrial-grade equipment that you won't see at your average neighbor's yard sale. I've seen old hardware RAID controllers, SPARCstations, dumb terminals, big rack-mount Ethernet hubs and switches, etc.
There are several Hamfests in the DC area every year. You can search for hamfests throughout the US at http://www.arrl.org/hamfests.html.
Note that some hamfests are bigger and better than others, so your mileage may vary.
- Tim
Hi!
> hope that theyroll that code back into
> FreeBSD for all of us civvies to use
I work on the CBOSS project, and that's the plan - we want to integrate the good stuff CBOSS produces directly into FreeBSD for everyone to use.
- Tim Fraser
Certainly, running bind in a chroot/jail environment is a good idea. With LOMAC or without, it's always wise to have defense-in-depth. It's also a good idea to run only carefully audited code whenever possible, for the same reason.
However, your question ("why not just chroot jail bind") implies that bind harbors the only exploitable hole in your system. In reality, holes could be in a number of applications besides bind, and it's very hard to know where all of them are. LOMAC automatically applies itself to all processes on your system, so you don't have to identify the dangerous ones before you run LOMAC in order to get protection.
LOMAC also provides some kinds of integrity protection that chroot can't. For example, LOMAC provides integrity protection in cases where the administrator unknowingly executes a Trojan horse with root privilege while doing day-to-day administration tasks. This isn't something chroot is designed to do.
So, defense-in-depth is good. Chroot. Audit your code. Use LOMAC, if you like.
- Tim Fraser, NAI Labs
Hi!
:^)
The GPL vs. BSDL debate aside, I'd like to point out that LOMAC does not include TrustedBSD code. However, I've been talking to Robert Watson, TrustedBSD's creator, about porting LOMAC to TrustedBSD's framework sometime after I finish the FreeBSD port. Robert and I both work for NAI Labs; he's presently mirroring LOMAC to help with the slashdot effect.
We'll both be at the Kernel Security Extension BOF at the upcoming USENIX Annual Technical Conference this June. We'll be presenting TrustedBSD and LOMAC papers in the FreeNIX track as well. So, you can come interrogate us there, if you like.
- Tim Fraser, NAI Labs
Hi!
> is there a solution to provide high level access via SSH or something,
Yes, LOMAC releases since v1.0.5 provide an exception that allows remote administration via SSH. The no-remote-administration restriction was a problem in earlier prototypes, though.
- Tim Fraser, NAI Labs
Hi!
> if that is true, you won't be able to ssh into your box
Yes, this was a problem with the early LOMAC prototypes. Fortunately, starting with v1.0.5, LOMAC has provided an exception to allow remote administration via SSH.
- Tim Fraser, NAI Labs
Hi!
.debs would have been downloaded over the network.
.deb) to a level-2 file. (The LOMAC manual describes how lup is implemented to avoid providing a backdoor to malicious users.)
.deb's before installation. A better solution might be to set an exception for the apt-get program, stating that anything apt-get downloads is automatically safe to put at level 2. This should allow apt-get to run without manual intervention, as it does without LOMAC.
> I installed it on my debian system, `apt-get upgrade` would fail, because the
This is a good question. Remaining compatible with traditional methods of administration is important to LOMAC. Ultimately, I'd like to have apt-get work with LOMAC just as it does without.
Presently, LOMAC provides a partial solution: there is a program called "lup" you can use to change a level-1 downloaded file (like a
This solution is sub-optimal, because the administrator has to manually bless the
LOMAC has a mechanism for providing this kind of exception. I haven't set it for apt-get yet, but now that you've pointed it out, I'll consider it. Thanks for the feedback!
- Tim Fraser, NAI Labs
Hi.
Thanks for giving LOMAC a shot; I'm sorry you ran into problems. The early versions of LOMAC did prevent remote administration, as you describe. However, LOMAC releases since 1.0.5 provide an exception to allow remote administration via SSH.
- Tim Fraser, NAI Labs
Hi!
LOMAC is my project, and I was among the NAI Labs contractors working on the NSA's SELinux project for a short while, too. SELinux is indeed an excellent technology. I've found SELinux to be extremely stable - I never had any of the released versions of SELinux crash on me in my (roughly) 6 months of usage.
The NSA's SELinux project and NAI Labs' LOMAC project have different goals. SELinux is designed to provide powerful features like extremely-fine-grained access control and a time-tested highly-general Flask architecture. LOMAC is designed to remain compatible with existing Linux kernels and software, and work without configuration, even at the cost of some features.
So, the LOMAC LKM is completely specialized towards supporting a single, simple, coarse-grained form of access control. However, it can be loaded into unmodified off-the-CD-ROM Linux kernels, and you don't have to configure it to recognize your local users and applications. SELinux provides many more powerful features, but it requires you do some configuration, and to patch your kernel and some of your applications.
It's a tradeoff. Depending on your requirements, you may prefer different choices along the features/compatibility line.
As for the comparison with the immutable flag, LOMAC provides a more flexible solution that allows admins to modify critical files that are immutable to normal users. LOMAC also provides a mechanism to prevent clever attackers from using Trojan horses or input designed to cause buffer overflows to get control of privileged processes.
There's a complete description in the LOMAC manual on ftp.tislabs.com/pub/lomac, if you're curious.
- Tim Fraser, NAI Labs
Hi!
Thanks for your interest in LOMAC! LOMAC is my project, and I've talked quite a bit with Amon Ott, RSBAC's creator. We'll both be at the Kernel Security Extension BOF at the upcoming USENIX Annual Technical Conference this June.
LOMAC and RSBAC have different goals. RSBAC's goal is to provide a general framework that can (simultaneously) support a wide variety of access control mechanisms. LOMAC's goal is to be compatible with existing Linux kernels and software. There's a tradeoff between functionality and compatibility: RSBAC provides general support, but requires a kernel patch. The LOMAC LKM supports only one access control mechanism, but it can be loaded into unmodified off-the-CD-ROM Linux kernels.
I've talked to Amon Ott about porting LOMAC to RSBAC's framework. I'm hoping to do a demo-quality port this summer, if I can find the time.
Also, LOMAC allows remote administration via SSH.
- Tim Fraser, NAI Labs
Hi!
I've had my LOMAC project on Freshmeat since June of 1999. I keep close track of LOMAC's FTP download logs, and they've shown me that nothing brings in the downloads like a release announcement on Freshmeat! Mailing list discussions, newsgroup posts, papers at conferences - none of these things seem to make a bump in the download rate. But every release announcements I've made on Freshmeat has immediately brought a nice sharp spike.
Thanks Freshmeat! You rule!
Well, if you do go to college, be sure to go to one with lots of girls.
- Tim
> Microsoft is working ... to port their apps to Linux
And in the anti-virus industry, there was MUCH rejoicing...
- Tim
There are low-cost Alpha boxes out there: the Multia. DEC sold these as "Universal Desktop Boxes" running Linux in the mid-90's. Unfortunately, they discontinued them in 1995. You can still occasionally find them for sale on the web, though. I bought one on onsale.com last year, and I won (most of) another one in a raffle from thelinuxstore.com earlier this month. They have an appealingly compact "pizza-box" desktop tower design that looks like a fat closed laptop with integral ide, video, and sound support. They also use laptop parts (PC and PCI-bus cards), making them easy to customize. Unfortunately, the Multia CPUs are quite slow by today's standards - perhaps roughly equivalent to a Pentium 100 (just a guess) for the most common version with a "low-cost" 166MHz 21066 Alpha CPU.
You can find more info by searching the web; www.viking.org/lca.html is also a good starting-point.
If only COMPAQ would come out with an updated version with a faster CPU...
- Tim