Am I the only one who thinks this interviewing technique is retarded?
In terms of actually finding people who are skilled and will do the job correctly, yes.
The only time I had to go through an actual interview process of any sort was a Unix sysadmin job (part time assistant admin, specifically), and it was a pretty good way to run it, I think.
First the guy asks me some random questions about experience, etc. Then he asked me what various things were, like "What does IMAP stand for and what does it do?" Finally, he pulls out some sort of SPARC. My memory is hazy but IIRC it was an Ultra. Probably an Ulra5. Anyway, so he starts pointing at stuff inside and asking "What is this?" The idea is to see how well I could figure out some random piece of hardware I'd never seen before.
I thought, given the envoronment there (wildly hetergenous setup - OS X, Linux, Ultrix, Solaris, NeXT, who knows what else) it was pretty good, if relativly trivial, test.
I would use these "tech interview questions" only for hiring interns or recent college grads where the expectation is zero experience, zero clue, zero skill, and a correspondingly low salary.
I am sort of vaguely insulted by that (as I am still in college for the next 6 months). I would agree that many people around here have no clue, but there are a decent number (and I include myself in the category) who are reasonably skilled. Probably that's because about 90% of what I know about creating software has come from working either on projects at work (like real software that people actually use) or free software.
Certainly I would agree that someone who just did the work in class would not be particular good, since it's pretty rare to have a class project that's really large enough (and long-lived enough) to really teach you about things like maintainability, portablity, security, etc.
Natedog sayz: what is really needed is a standard c++ abi
There is one for x86 and IA-64. And since most of the low-level stuff (which registers are caller-saved, etc) is handled by the C ABI, it probably wouldn't be too hard to 'port' the ABI definition to other machines.
The C++ ABI was originally only for IA-64, but I guess Intel realized that this was a good idea on other systems. I'm not sure if x86-64 has one. I know that the Linux/*BSD/GCC people are basically defining the ABI themselves, but I'm not sure if they're doing C++ or only C.
But in GitS, they completely changed the main character. I wouldn't call that trivial.
OK. Maybe it's just because I was up all night, but am I missing something? Yes, Motoko kills quite a few less people in the movie, and she's much less of a smartmouth. But I re-read the first half of the manga last night (up to the fight with the guys in Section 1), and I don't think she was completely changed. But given that two responses were made to that effect, maybe I'm wrong, so please clarify.
Even if we agreed on this point, I would still think the delta between Akira(manga) and Akira(movie) is far larger, given that the movie basically is the first 3 (or 2?) volumes, then it skips ahead to the very end of volume 6.
The manga of Ghost in the Shell is significantly more in-depth than the film. While most American fans love the anime (it is well done), I was always disappointed in it because it barely skimmed the surface of the printed story.
I agree that a movie would have been a better format for this. Most of the anime movies I've seen tend to be like that, particularly Akira and Ghost in the Shell. Though doing a whole series of Akira, and keeping the level of visual quality would have come at an outragous cost, I'm sure.
Compared to the differences between the movie and print versions of Akira, the changes in GiTS are absolutely trivial. Not to say the Akira movie didn't rock (it still is about the best animation I've ever seen), but the manga has so much more detail it's insane.
I only read the manga after seeing the movie (GiTS was the first 'real' anime I ever saw), so I've never felt too disapointed by the movie. Actually, it enhanced reading the manga a lot, because I would read sections that cleared up some obscure reference or statement in the movie, and think 'Oh, so that's what they meant!', which was kind of cool.
Actually, C with all its aliasing problems (read: ponters), defeats all sorts of static analysis and other optimizations that could otherwise be done.
Using the restrict keyword, or various compiler options, can often help this, by assuring the compiler that certain methods of aliasing are not used. Compilers still don't support it very well (GCC ignores it most of the time right now), but it can be useful.
C pretty much completely lacks a runtime layer completely, and the mismatch is starting to show.
I don't disagree with you here (completely, anyway). There are times when you really don't want a big runtime, however (embedded systems, OS, etc). And of course there is the problem of: what if the runtime isn't there, or it's the wrong version? I've had some 'interesting' problems with that (which is why one machine I admin has not 1, not 2, but 3 Java VMs installed).
Re:Read "The Millionaire Next Door"...
on
The Almighty Buck
·
· Score: 1
found that most wealthy people drink Budweiser, drive Fords, and live in Middle class 'burbs. They most often own their own businesses
Indeed. I found out a couple years ago that my dad's parents are multi-millionaires. I had absolutely no idea. They have two cars; an old Crown Victoria, and an even older Ford pickup. Their house is nice, but hardly huge (it's basically a ranch house in a rural area, which they have owned free and clear longer than I've been alive). I figured they were reasonably well off (never had any money problems that I heard about), but I was still quite suprised to find out their actual financial status.
And they do own their own business (several, actually, I think).
Open source is great for people out of work, or screwing around. It sucks if you have 3 kids and a wife, and need insurance, and all the other perks a job offers.
Dunno... some people at my place of work seem to manage it pretty well. AFAIK they do get insurance, though I don't know how good (If you want really good health insurance, IT/programming is the wrong industry anyway: industrial jobs have very good health insurance converage). I'm a summer employee right now, so I don't make the big bucks, nor do I get insurance, but whatever.
Whine all you want about it, but precious few people make money from open source, and I don't see those folks sharing all that much.
I'm making a decent living working on BSD and GPLed software (I may end up working there full time after I graduate this winter). Mostly it's DoD contract work that has potential commercial value. My last job was also working on BSD licensed software (which I don't think was DoD work, but I could be wrong).
I agree, not too many people do make a living this way, but it is certainly possible. I would be OK with programming proprietary stuff, but more likely than not, any proprietary stuff I would do would be Win32, and I really have 0 interest in that. Unix programming for me, thank you very much.
There's only been a few times that our total credit card debt has been over $1500 at the end of a month, which from what I understand is WAY below average. This is something that people seem to have forgotten - the people that give you those pieces of plastic want their money back someday, and someday SOON.
Of course some times you can't really help it. My Dad was laid off and couldn't find work for about 2 years right about the time I was born (I'm coming up on 21 now), and we still have, hell, at least several thousands of dollars in debt. Possibly it's still over 10K, even.
Xvision is a library written at JHU (originally at Yale; the main people moved over here a few years back). I used to work on it a little bit (theoretically, I was the sysadmin, but kinda I got roped into working on it for a while a couple summers back). It's not bad, though the code is pretty dirty in places. It's used to program the robots for that robot soccer competition.
Re:Nobody here is upset at the system crackers?
on
California Hax0red
·
· Score: 2
it's the admin's fault for not building up ridiculous amounts of security!
If "a ridiculous amount of security == not being able to get tons of financial and personal information on 200,000 people", I would hate to see "Oh, it's kind of secure."
security guys blame admins for not having installed Tripwire, shut down all unnecessary services, and firewalled off unneeded ports (although these are trivially-simple to do), I get really inflamed.
The admins shouldn't be blamed, they should be fired (especially given the quote from the article below).
It is the cracker's fault, and anybody (but ESPECIALLY anybody in security) who blames stupid admins instead should not be in IT.
From the article:
"work by the task force found that few of the security procedures that are supposed to be in place actually are used."
The crackers are the criminals, and let us never lose sight of that.
Of course they are. Break law -> criminal. That seems pretty obvious.
YES. I have an Antec SX830, and it's truly a joy to work with. Roomy, but not so big that it's a hard time getting everything connected (like some Supermicro cases I've dealt with). Plenty of space for fans, lots of drive bays. It's easy to open up, too. There's a review with some decent picutes here.
The removable hard drive bays are sheer brilliance. They work perfectly. My dad uses a 1030, and it's just as nice (but a little bigger than I needed for just a little desktop box).
when are we going to need error correction on these?
I'm pretty sure all or nearly all drives already do error correction. The high density may make it better to use longer codes, but it's really pretty trivial overhead. I know SCSI drives do ECC; if modern (post-1990) IDE drives don't, I would be very suprised.
A scratch on a magnetic platter would really suck too, after all.
I've never actually been in one of the ACM programming contests, because I'm one of the people running them (doing systems stuff + security) at our site.
I can say, from looking at the problems, that they are not the sort of things you would do in real life. Either they are weird graph theory or gemetrical problems, or stuff that could be done in 5 lines of Perl (which you aren't allowed to use, just C, C++, and Java).
Running them can kind of be good experience for doing system adminning, because you:
a) Have to deal with a bunch of people (both higher and lower then you in the command chain) that are complete idiots. I mean people that should not be allowed to live, much less be allowed near a computer. I can give plenty of examples if anyone cares.
b) You have to deal with absolutely horrible software (in our case, PC^2) because of organizational policy. I mean, way less stable than Windows 3.0, a UI that is incomprehensible, and a resource hog like nothing I've ever seen before or since. I really am not exaggerating. It's that bad.
Both of these things come up in real life far more often than I would like.:)
But as practical experience, please. These things are nothing at all like real life. Of course the winners do get cool prizes. It's a decent thing to put on a resume, but all other things being equal, I would think working a job in a lab on campus is much better real world experience than something like this.
Y'know, it seems odd to hear someone saying "get a life" in the context of "watch star wars movies, anime, and read comic books. Also, play computer games (specially multi-player games)"
Many/most/all of these can easily be activities undertaken with "other people" present. Possibly even people who don't spend all their time coding. I don't know, that seems like it might be tolerable to me.
But if you haven't already, read the Practice of Programming. It has some good thoughts about testing applications that should help you out. And it's a pretty decent book, anyway.
Here's a few random things that occur to me (most are probably repeats of other posts, though):
Automate as much as you can (testing, code generation, anything that's possible to automate - do it).
Use strongly typed languages, and strongly typed interfaces.
Use any and all warning flags, if available
Whenver you find a bug, add a test that detects that bug to your test suite. Then, and only then, fix the bug.
If the U.S. had a competitor in this race for Mars like they did for the moon in the late 60s, they would have a man there in a few short, focussed years.
China is supposed to start manned space flights pretty soon (next year, IIRC?). I've been hoping this will spark more funding for space missions here in the US. Hey, it worked for Apollo.
I doubt this Mars thing will happen, but I really do hope it does.
I don't know squat about this new standard but if they can zip bits from a hard drive to a cpu, why couldn't they zip them between two cpus instead?
Presumably there are length limitations on the cable. For example, ATA-133 can only go up to about 18 inches, I think, before crosstalk becomes so bad that you loose performance and/or stability. Because Serial ATA is, as the name suggests, a serial bus (or at least a mostly serial bus; I think it might send byte or word at a time), it should suffer from crosstalk less, and be able to go somewhat longer distances (say 3 feet, as a WAG).
But for networking, you often need something a lot longer than that (say a few hundred meters). So that won't really work. Anyway, it is very hard for something new to break into the wired networking space; Ethernet has that area pretty well sewn up.
From the article: Microsoft should withhold technical information from Intel and "work underground" to promote its competitors in the computer chip industry
Hasn't somebody mentioned to MS that AMD is helping with the porting of GCC, Linux, NetBSD, and FreeBSD to x86-64?
Let's say I write some super-important thing using the ABC and XYZ toolkits. My program fails and bad stuff happens. Do the people suing me have to prove that it was my code, and not in ABC or XYZ, that failed? Do I have to prove that it was not my code? And finally, how the hell could you prove something like that, anyway? [Especially if it was not repeatable - what if it was the OS, or the hardware, or something else entirely?]
I really don't understand why this is called a lemon law, actually. A car that's a lemon doesn't work, or works for a while and then throws a rod or something. I don't quite see the analouge between that and software.
In fact, someone mentioned a web server dying at some important moment, and the users of that web server losing a lot of money (ebay or amazon or something). Does this qualify under a lemon law? If I have to get somewhere important, and my car doesn't start, can I actually sue the makers of the car?
I should add that after UPS destroyed the hardware with the forklift 'o death, they refused to pay up (it was insured). In fact, the same thing happened to me with my machine, I insured it for some amount ($300-$500, I think), and after they trashed it, I went and complained - no luck. Total stonewall. Jerks.
I've shipped a lot of computers and almost always, UPS (pronounced Oops), would jiggle lots of cards and sockets. I rarely ship anything that doesn't have a seating problem with it on the other end.
I've heard some pretty good stories about UPS putting forklift arms through various things (including a block of AlphaServers that a friend's dad was going to sell). Oops.
My best/worst "carried destroyed my hardware" experience was with the postal service. Those guys can really mess up a (pretty tough) steel case. I'm amazed the machine survived; it must have been dropped repeatedly, from a good height, onto a hard floor to do what they did to that case.
Slashdot Mirror
Um, I was under the impression that RiscOS was written for the ARM processor(s)?
:)
Heh. Bet you didn't know about AIX/i386 then.
Yes, it seriously did exist. Or at least, GCC supported it. I suppose it's possible someone added it in support for it as a joke...
This 3.2 might be what really what 3.3 is going to be.
...) really wanted the coming 3.2 release. It's just 3.1.1 with some ABI fixes. It will probably be out in a day or two.
Nope. RedHat (and SuSE and
Basically they didn't want the same thing to happen with 2.96 vs 3.0 again.
Am I the only one who thinks this interviewing technique is retarded?
In terms of actually finding people who are skilled and will do the job correctly, yes.
The only time I had to go through an actual interview process of any sort was a Unix sysadmin job (part time assistant admin, specifically), and it was a pretty good way to run it, I think.
First the guy asks me some random questions about experience, etc. Then he asked me what various things were, like "What does IMAP stand for and what does it do?" Finally, he pulls out some sort of SPARC. My memory is hazy but IIRC it was an Ultra. Probably an Ulra5. Anyway, so he starts pointing at stuff inside and asking "What is this?" The idea is to see how well I could figure out some random piece of hardware I'd never seen before.
I thought, given the envoronment there (wildly hetergenous setup - OS X, Linux, Ultrix, Solaris, NeXT, who knows what else) it was pretty good, if relativly trivial, test.
I would use these "tech interview questions" only for hiring interns or recent college grads where the expectation is zero experience, zero clue, zero skill, and a correspondingly low salary.
I am sort of vaguely insulted by that (as I am still in college for the next 6 months). I would agree that many people around here have no clue, but there are a decent number (and I include myself in the category) who are reasonably skilled. Probably that's because about 90% of what I know about creating software has come from working either on projects at work (like real software that people actually use) or free software.
Certainly I would agree that someone who just did the work in class would not be particular good, since it's pretty rare to have a class project that's really large enough (and long-lived enough) to really teach you about things like maintainability, portablity, security, etc.
There is one for x86 and IA-64. And since most of the low-level stuff (which registers are caller-saved, etc) is handled by the C ABI, it probably wouldn't be too hard to 'port' the ABI definition to other machines.
The C++ ABI was originally only for IA-64, but I guess Intel realized that this was a good idea on other systems. I'm not sure if x86-64 has one. I know that the Linux/*BSD/GCC people are basically defining the ABI themselves, but I'm not sure if they're doing C++ or only C.
But in GitS, they completely changed the main character. I wouldn't call that trivial.
OK. Maybe it's just because I was up all night, but am I missing something? Yes, Motoko kills quite a few less people in the movie, and she's much less of a smartmouth. But I re-read the first half of the manga last night (up to the fight with the guys in Section 1), and I don't think she was completely changed. But given that two responses were made to that effect, maybe I'm wrong, so please clarify.
Even if we agreed on this point, I would still think the delta between Akira(manga) and Akira(movie) is far larger, given that the movie basically is the first 3 (or 2?) volumes, then it skips ahead to the very end of volume 6.
The manga of Ghost in the Shell is significantly more in-depth than the film. While most American fans love the anime (it is well done), I was always disappointed in it because it barely skimmed the surface of the printed story.
I agree that a movie would have been a better format for this. Most of the anime movies I've seen tend to be like that, particularly Akira and Ghost in the Shell. Though doing a whole series of Akira, and keeping the level of visual quality would have come at an outragous cost, I'm sure.
Compared to the differences between the movie and print versions of Akira, the changes in GiTS are absolutely trivial. Not to say the Akira movie didn't rock (it still is about the best animation I've ever seen), but the manga has so much more detail it's insane.
I only read the manga after seeing the movie (GiTS was the first 'real' anime I ever saw), so I've never felt too disapointed by the movie. Actually, it enhanced reading the manga a lot, because I would read sections that cleared up some obscure reference or statement in the movie, and think 'Oh, so that's what they meant!', which was kind of cool.
Actually, C with all its aliasing problems (read: ponters), defeats all sorts of static analysis and other optimizations that could otherwise be done.
Using the restrict keyword, or various compiler options, can often help this, by assuring the compiler that certain methods of aliasing are not used. Compilers still don't support it very well (GCC ignores it most of the time right now), but it can be useful.
C pretty much completely lacks a runtime layer completely, and the mismatch is starting to show.
I don't disagree with you here (completely, anyway). There are times when you really don't want a big runtime, however (embedded systems, OS, etc). And of course there is the problem of: what if the runtime isn't there, or it's the wrong version? I've had some 'interesting' problems with that (which is why one machine I admin has not 1, not 2, but 3 Java VMs installed).
found that most wealthy people drink Budweiser, drive Fords, and live in Middle class 'burbs. They most often own their own businesses
Indeed. I found out a couple years ago that my dad's parents are multi-millionaires. I had absolutely no idea. They have two cars; an old Crown Victoria, and an even older Ford pickup. Their house is nice, but hardly huge (it's basically a ranch house in a rural area, which they have owned free and clear longer than I've been alive). I figured they were reasonably well off (never had any money problems that I heard about), but I was still quite suprised to find out their actual financial status.
And they do own their own business (several, actually, I think).
Open source is great for people out of work, or screwing around. It sucks if you have 3 kids and a wife, and need insurance, and all the other perks a job offers.
Dunno... some people at my place of work seem to manage it pretty well. AFAIK they do get insurance, though I don't know how good (If you want really good health insurance, IT/programming is the wrong industry anyway: industrial jobs have very good health insurance converage). I'm a summer employee right now, so I don't make the big bucks, nor do I get insurance, but whatever.
Whine all you want about it, but precious few people make money from open source, and I don't see those folks sharing all that much.
I'm making a decent living working on BSD and GPLed software (I may end up working there full time after I graduate this winter). Mostly it's DoD contract work that has potential commercial value. My last job was also working on BSD licensed software (which I don't think was DoD work, but I could be wrong).
I agree, not too many people do make a living this way, but it is certainly possible. I would be OK with programming proprietary stuff, but more likely than not, any proprietary stuff I would do would be Win32, and I really have 0 interest in that. Unix programming for me, thank you very much.
There's only been a few times that our total credit card debt has been over $1500 at the end of a month, which from what I understand is WAY below average. This is something that people seem to have forgotten - the people that give you those pieces of plastic want their money back someday, and someday SOON.
:)
Of course some times you can't really help it. My Dad was laid off and couldn't find work for about 2 years right about the time I was born (I'm coming up on 21 now), and we still have, hell, at least several thousands of dollars in debt. Possibly it's still over 10K, even.
live WITHIN your means.
We drank dehydrated milk.
From the changelog:
<rml@tech9.net>
[PATCH] Robert Love likes leather and chains
> Hmm. That patch does not compile. "p->cpu" does not exist, it's
> "p->thread_info->cpu". Tssk.
Ouch, I am bad. Sorry.
Make the ChangeLog entry something really defamatory.
Robert Love
Xvision is a library written at JHU (originally at Yale; the main people moved over here a few years back). I used to work on it a little bit (theoretically, I was the sysadmin, but kinda I got roped into working on it for a while a couple summers back). It's not bad, though the code is pretty dirty in places. It's used to program the robots for that robot soccer competition.
Hrm... a URL... Ah, here:
Xvision2 page.
it's the admin's fault for not building up ridiculous amounts of security!
If "a ridiculous amount of security == not being able to get tons of financial and personal information on 200,000 people", I would hate to see "Oh, it's kind of secure."
security guys blame admins for not having installed Tripwire, shut down all unnecessary services, and firewalled off unneeded ports (although these are trivially-simple to do), I get really inflamed.
The admins shouldn't be blamed, they should be fired (especially given the quote from the article below).
It is the cracker's fault, and anybody (but ESPECIALLY anybody in security) who blames stupid admins instead should not be in IT.
From the article:
"work by the task force found that few of the security procedures that are supposed to be in place actually are used."
The crackers are the criminals, and let us never lose sight of that.
Of course they are. Break law -> criminal. That seems pretty obvious.
I find the anatec 1030 has lots of room to work.
YES. I have an Antec SX830, and it's truly a joy to work with. Roomy, but not so big that it's a hard time getting everything connected (like some Supermicro cases I've dealt with). Plenty of space for fans, lots of drive bays. It's easy to open up, too. There's a review with some decent picutes here.
The removable hard drive bays are sheer brilliance. They work perfectly. My dad uses a 1030, and it's just as nice (but a little bigger than I needed for just a little desktop box).
when are we going to need error correction on these?
I'm pretty sure all or nearly all drives already do error correction. The high density may make it better to use longer codes, but it's really pretty trivial overhead. I know SCSI drives do ECC; if modern (post-1990) IDE drives don't, I would be very suprised.
A scratch on a magnetic platter would really suck too, after all.
I've never actually been in one of the ACM programming contests, because I'm one of the people running them (doing systems stuff + security) at our site.
:)
I can say, from looking at the problems, that they are not the sort of things you would do in real life. Either they are weird graph theory or gemetrical problems, or stuff that could be done in 5 lines of Perl (which you aren't allowed to use, just C, C++, and Java).
Running them can kind of be good experience for doing system adminning, because you:
a) Have to deal with a bunch of people (both higher and lower then you in the command chain) that are complete idiots. I mean people that should not be allowed to live, much less be allowed near a computer. I can give plenty of examples if anyone cares.
b) You have to deal with absolutely horrible software (in our case, PC^2) because of organizational policy. I mean, way less stable than Windows 3.0, a UI that is incomprehensible, and a resource hog like nothing I've ever seen before or since. I really am not exaggerating. It's that bad.
Both of these things come up in real life far more often than I would like.
But as practical experience, please. These things are nothing at all like real life. Of course the winners do get cool prizes. It's a decent thing to put on a resume, but all other things being equal, I would think working a job in a lab on campus is much better real world experience than something like this.
Y'know, it seems odd to hear someone saying "get a life" in the context of "watch star wars movies, anime, and read comic books. Also, play computer games (specially multi-player games)"
Many/most/all of these can easily be activities undertaken with "other people" present. Possibly even people who don't spend all their time coding. I don't know, that seems like it might be tolerable to me.
But if you haven't already, read the Practice of Programming. It has some good thoughts about testing applications that should help you out. And it's a pretty decent book, anyway.
Here's a few random things that occur to me (most are probably repeats of other posts, though):
Automate as much as you can (testing, code generation, anything that's possible to automate - do it).
Use strongly typed languages, and strongly typed interfaces.
Use any and all warning flags, if available
Whenver you find a bug, add a test that detects that bug to your test suite. Then, and only then, fix the bug.
If the U.S. had a competitor in this race for Mars like they did for the moon in the late 60s, they would have a man there in a few short, focussed years.
China is supposed to start manned space flights pretty soon (next year, IIRC?). I've been hoping this will spark more funding for space missions here in the US. Hey, it worked for Apollo.
I doubt this Mars thing will happen, but I really do hope it does.
I don't know squat about this new standard but if they can zip bits from a hard drive to a cpu, why couldn't they zip them between two cpus instead?
Presumably there are length limitations on the cable. For example, ATA-133 can only go up to about 18 inches, I think, before crosstalk becomes so bad that you loose performance and/or stability. Because Serial ATA is, as the name suggests, a serial bus (or at least a mostly serial bus; I think it might send byte or word at a time), it should suffer from crosstalk less, and be able to go somewhat longer distances (say 3 feet, as a WAG).
But for networking, you often need something a lot longer than that (say a few hundred meters). So that won't really work. Anyway, it is very hard for something new to break into the wired networking space; Ethernet has that area pretty well sewn up.
From the article: Microsoft should withhold technical information from Intel and "work underground" to promote its competitors in the computer chip industry
Hasn't somebody mentioned to MS that AMD is helping with the porting of GCC, Linux, NetBSD, and FreeBSD to x86-64?
Let's say I write some super-important thing using the ABC and XYZ toolkits. My program fails and bad stuff happens. Do the people suing me have to prove that it was my code, and not in ABC or XYZ, that failed? Do I have to prove that it was not my code? And finally, how the hell could you prove something like that, anyway? [Especially if it was not repeatable - what if it was the OS, or the hardware, or something else entirely?]
I really don't understand why this is called a lemon law, actually. A car that's a lemon doesn't work, or works for a while and then throws a rod or something. I don't quite see the analouge between that and software.
In fact, someone mentioned a web server dying at some important moment, and the users of that web server losing a lot of money (ebay or amazon or something). Does this qualify under a lemon law? If I have to get somewhere important, and my car doesn't start, can I actually sue the makers of the car?
Unfortunately, the benefits of having an alpha are largely negated when half of your software MUST be compiled using a slowass compiler like gcc
That's why you use Compaq's Alpha compiler if you need fast code on the Alpha.
I should add that after UPS destroyed the hardware with the forklift 'o death, they refused to pay up (it was insured). In fact, the same thing happened to me with my machine, I insured it for some amount ($300-$500, I think), and after they trashed it, I went and complained - no luck. Total stonewall. Jerks.
I've shipped a lot of computers and almost always, UPS (pronounced Oops), would jiggle lots of cards and sockets. I rarely ship anything that doesn't have a seating problem with it on the other end.
I've heard some pretty good stories about UPS putting forklift arms through various things (including a block of AlphaServers that a friend's dad was going to sell). Oops.
My best/worst "carried destroyed my hardware" experience was with the postal service. Those guys can really mess up a (pretty tough) steel case. I'm amazed the machine survived; it must have been dropped repeatedly, from a good height, onto a hard floor to do what they did to that case.