A decade or so ago we did a consulting gig out at a different national lab, which then had a classified-projects design network and a regular network, and they'd decided they wanted to do the fastest hairiest network they could for the classified net, because the security decisions involved in changing or upgrading things were so painful and difficult. They decided that a gigabite/second per user was about enough - because that's enough for two 32-bit-color 30fps 1024x1024 displays, so the bottleneck is no longer the user's computer, it's the user's eyeballs. In reality, they could use a bit more today, because we're close to 2Kx2K displays, but back then that was about as greedy as they could get, and there wasn't really anything that quite did that:-)
Those annoying copper-wire people keep taking our "we'll finally make you buy fiber now, this time for sure!" standards and implementing them on copper for much less money:-) I can get a GigE-on-copper NIC card at Fry's for $59 bucks, though the cheapest switch I saw that supported it was about $300. It's almost tempting to do gigabit copper at home just because I can:-)
Obviously if you're actually going anywhere, you want fiber, and the ability to go 10-20km over fiber (for GigE and also for storage-network technologies like FibreChannel) is starting to change the economics and scaling decisions about where you put servers and storage, how much clustering you do, how you handle disaster recovery, etc., but for inside wiring, copper is still convenient.
I've got one of those. It's only marginally thicker than the description of the Logitech, and the price at Fry's has gone down from $49 to $39. It's also usable as a webcam, and comes with a stand. There was an article in the San Jose Mercury News about SiPix, saying they're coming out with an even smaller camera for about $39 (square, same height as the current one but less wide, and only one battery).
The SiPix seems to be a battery hog - I'm now using NiMH rechargables instead of the rechargable alkalines I used at first, which helps a lot, but at least they're all standard AAA batteries, so in a pinch you can switch batteries on the fly and hope you don't lose any pictures:-(. And it really *is* nice and small, though you need to keep it in the case since there's no lens cap. Unlike my old Toshiba PDR camera (lens scratch - sigh...), or most higher-end cameras, the software doesn't look like a disk drive - it uses Twain drivers and some hokey software that copies them into temporary files and encourages you to edit them with lame decorations. I've had other cheap cameras that also did this. Much more trouble, but once you figure it out you can work around the limitations, and at least it's running on USB power while it does it.
I've noticed that a lot of the cheap digital cameras lately are taking advantage of rapidly decreasing memory prices by doing less compression - instead of 2MB memory with tightly compressed pictures, they've got 8MB memory, and the files are about twice as big, maybe more. My guess is that this lets them save money and/or battery by using dumber CPUs or get faster storage performance.
My Psion 3A and my Palm 3 and Palm 7 all last for a couple of weeks on battery, using either regular or rechargeable alkaline or NiMH. Newer battery technologies like Lithium Polymer seem to be even more promising. Good power management in the device, and good recharging technology for rechargeables, and ability to use AC power adapters if you need to do long periods of work (without trashing the recharging performance) are really all you need unless you want to carry a high-power-drain CPU-blaster with you.
QNX is probably the best-known working microkernel system out there. (Mach is better-known, but nobody actually used the microkernel versions, they used the 2.5ish versions like Next mostly.) Runs on a reasonably large number of Intel platforms, though unfortunately the single-floppy network demo only had drivers for a model of Ethernet card I didn't have, and hasn't been updated since 1999. They've probably had enough bloatware that the kernel no longer fits in 4KB (but newer Intel chips have bigger L1 caches these days:-), not that you're really need it to stay in L1.
The standard joke about telco operations is that the network is made to be run by a man and a dog:
The man's job is to feed the dog.
The dog's job is to keep the man from touching any of the equipment.
As you and others have said, if nothing goes bad, it doesn't take much maintenance to keep running, though it's adding new service that needs resources and causes mistakes that break things.
The parts of KPNQwest that everybody's worried about these days aren't running either Linux or Windows - they're routers (probably Cisco) and fiber muxes of various sorts (which do have OSs for their configuration and user interfaces) and the air conditioners for the rooms the equipment runs in. Both non-HVAC categories are pretty reliable as long as there aren't technicians adding or changing things and as long as nobody backhoes any important circuits.
There are other parts of KPNQwest that do run on general-purpose computers, such as the administrative and billing databases, network management systems, etc. Probably some are running Windows or Linux, and others are probably running Solaris or HPUX.
I'll admit that student computing environments have changed since I was an undergrad - one of the geek fraternities had their own keypunch, but everybody else had to come up to campus to access computers.:-) Not every college student has a computer, and not every computer is a laptop, and not every laptop has a wireless LAN card (though the latter's become affordable, if the college has the access points). The jobs of an open lab have changed a lot from the days when most work was on terminals connected to a big shared machine, and they'll keep changing as technology changes the affordability and portability of the average student's computing resources, and y'all in the academic-staff business will have to keep hopping, reinventing yourselves, and getting new budgets approved.
So what are they for now?
Computing with lab assistants, whether they're class-specific TAs or computing-center assistants.
Collaborative work! Once you've finished Programming 100 and maybe Data Structures 200, much of the important classwork isn't individual - it's either explicitly collaborative projects, or at least study-groups working together on homework, and until everybody's got a wireless laptop, open labs are the most convenient place to do that. Also, if your project involves doing major changes to a machine's operating system, you're not going to do that on your main PC, you're going to do it on a lab machine which can be wiped and rewritten, or at very least on a removable drive.
Computing near classes - most universities are large enough that dorms aren't right next to classrooms, and campuses are large enough that academic buildings aren't all within a 5-minute walk of each other.
High-speed network access - many campuses have ethernets or dsl or similar LANs in their dorms, but many don't, and many students don't live in dorms, especially non-freshmen.
Specialized resources - unlike a few years ago, most interesting projects really _can_ be done with an individual's PC with a fast net connection to appropriate local file servers, but there really are still projects that need larger machines, or special hardware.
Several people have suggested that the database is in dBase4 and that there are $29 utilities for cracking it, which sounds like the obvious right choice. But suppose it had been in a more securely encrypted format, and an initial guess of easy passwords had failed. Do you temporarily divert SETI@HOME to search for signals that aren't in alien languages, just NyNorsk? Or do you go for non-free computing services, and if so, how much do you spend and how long does it take?
Or do you hire a clerk to rebuild the database by looking through the books? At some point, that probably wins, at least to the extent that the indexing is mostly gruntwork rather than creative thought. That doesn't mean it's not worth posting the file to the web and asking for volunteers to hack it, which would be a fine idea.
A long long time ago, on an IBM System34 far far away, somebody out in the shop wanted to turn off his welder by flipping circuit breakers, and found the computer room before he found the welder, and the 34's quaint little operating system wasn't designed for that sort of thing; the open file which represented six or seven hours of typing by our accounting clerk got truncated to its last good state. I spent about 5 hours on the phone with IBM tech support doing the hexedit on the disk drive to find the right pointers and patch it so we could recover the file. If it had taken much longer, we'd have been better off retyping the thing.... But of course, sometimes you only know that in hindsight.
Quantum computers aren't deterministic - the techniques that have been discussed have non-trivial chances of getting incorrect answers. With problems like factorization, it's fast and trivial to determine whether an answer was correct or incorrect, but not obvious what to do about an incorrect one. There may be deterministic algorithms a bit faster than NFS (it's got lots of relatives), but they're mostly in the same general range.
The interesting thing about quantum computing is that it's the one technology that, if it's actually possible to develop usable machines with it, might offer the possibility of getting beyond the exponential-difficulty traps in factoring and other current techniques of public-key math. It's not clear that it will work, but it's the only thing so far that doesn't hit the "well, if you build a keycracking computer the size of the planet and run it for the remaining age of the solar system, I can add three more key bits and make you take over some more planets" wall.
They're not off the shelf, and won't be any time soon. The biggest quantum computer made so far was able to factor 15 into 5 x 3. The number of bits of answer you can get out of a quantum computer depends on the precision to which you can measure its output - does this hit Heisenberg limits? 10**47 is only ~140 bits. Or do you hit practical limits first? Or are there ways to break up the answer into many parts each of which gets you a few bits of precision? (The latter case is the only way to get it to work...)
What if quantum crypto does work? Maybe it'll crack conventional RSA and Diffie-Hellman, but that doesn't mean it transfers to Elliptic-Curve cracking, so we may luck out. Alternatively, it's back to conventional techniques like Kerberos and other symmetric-based Key Distribution Center systems.
Back in the mumblety-early 80s, when Unix was a trademark of Bell Labs and/or AT&T and/or Western Union and a commercial product, the Fedz put out an RFP for a big software project, which included the then-not-uncommon requirement (for custom software deals) that they get unlimited rights to all the software delivered - that meant not just access to the source, but the ability to do anything they want to with it, resell it, modify it, whatever. They didn't insist that they _had_ to buy that as part of the final deal, but it had to be offered and priced. The rumor is that we gave them a price, which reflected what we thought the future commercial value of Unix was - a cool $1B. They said thank you, checked the box on their form, and didn't buy it:-) (Too bad - I forget what the price that the rights to Unix finally sold for, but it was a lot less.... though by then we had *BSD and Linux available under various free-ish licenses.)
Get Cable Modem, Go To Jail - Update
on
What Free Cable?
·
· Score: 2
Apparently, Maryland's Cable TV Service Theft Laws are designed with guilty-until-proven-innocent built in, and "Comcast The TV Company" and "Comcast the Cable Modem Company" didn't talk to each other very well about who was buying what services, so the author got a Kafka-esque runaround because she wasn't a TV-watching couch potato.
Shredding and compressing mail messages is almost always a bad idea. Essentially *nobody* does it correctly, and you can't reconstruct messages in their original byte-for-byte formats, which trashes digital signatures. You won't save much disk space, because real text doesn't take up enough space for anybody except a big ISP mailsystem to worry about, and binary attachments usually only compress well if they've been encoded in some non-8-bit-transparency format like base64 or uucode. About the only time it wins is when one person on your keep-mail-on-server mailsystem is sending an attachment to a bunch of people who can then all use the original, which is to say they should probably have stored the file on the web and mailed a URL. If you're going to do things like this, get yourself a compression-equipped filesystem and just store your raw mail messages there.
Unix, from pretty much the beginning, has always done a good job of cache management, and a heavily-measured-and-tuned job of file system design, while Windows basically never got the concept. (If you don't use the diskdrive when you can use RAM instead, and do better pre-planning of disk accesses, disk performance is less critical, though of course reducing the amount of bloatware and associated swapping also makes a big difference.) This is partly the difference between a commercial operating system and an openish-source university-oriented operating system (i.e. between minimizing ship date vs. maximizing number of scientific papers written about cool optimizations), and also partly because Unix started off supporting a much wider variety of platforms where portability, tunability, and fault-recovery were essential features.
The anti-virus people have certainly done lots of benchmarking, but the most critical way to speed it up is not to scan stuff you don't need to be scanning. Maybe you should be scanning new files acquired from the Internet, and maybe even scanning files you save to disk, but neither one of those is the 50MB/sec disk speed - you don't need to scan a file every time you read it if your operating system can keep track of when it was last changed, and most viruses can be detected in the first block or two of a file, so you don't need to scan the whole body of most files, just the suspect parts.
The eskimo.com site really has some excellent stuff, and it also has lots of pointers to Cryptome, John Young's archive. TEMPEST protection was *much* easier a decade or two ago, when computers were typically 1-50 MHz, as opposed to now when anything new is 1GHz or more. The higher frequencies are much more penetrating, so blocking them (and their harmonics) is much harder. On the other hand, they're often lower power than in the past (my VAX used 3-phase power:-) and the higher frequencies probably don't travel as far.
By the way, I'm the source of at least some of the anecdotes Joel mentions about laptop screens being received on televisions - I no longer have that laptop, but my mom still has the TV:-) It wasn't very good sync, and I was running 640x480, so it wasn't a direct full-screen image and rolled around slowly, but it had clearly recognizable text, and a device built for the purposes of eavesdropping would be able to get the sync right. I suspect that most of the emissions were from the VGA port on the back of the laptop rather than from the LCD circuitry itself, but that's pure guesswork, and the depth of scientific inquiry consisted of looking at the noise on the screen, saying "yes, that looks it's like the text on my computer", and turning the PC off so we could go back to watching TV:-)
you can look in the window and see the iMac sitting on the desk. (Unlike daytime, when you can see that my laptop is pointed the wrong way.) Of course, if you look more closely, you'll see that it's really just an iMac *poster* positioned at the right height:-)
TCP windows get up to 64KB - that's the most you can have outstanding waiting for ACKs, because that's all the bits the header has room for. Typical windows are more like 2KB-8KB. The problem, for long-haul data connections, is that the size of the window times the transmission latency is the maximum rate you can transmit data. So if you have a satellite with a 0.5 second round-trip time (roughly) and a 64KB TCP window, your maximum speed is 128KB/sec, aka 1024 kbps, which doesn't fill a T1. If you've got a 10000-mile round-trip (Alaska to NL is probably farther than that) the speed-of-light limit on RTT is about 100ms, so you're limited to about 5Mbps/sec. These guys went a lot faster than that, so they were clearly doing something intelligent, like keeping multiple TCP windows open, or using UDP with applications that do their own ACKs.
Any idea what software they used for the transfer? A simple TCP session won't work - the maximum window size of 64KB limits the transfer rate over large speed*delay products. Were they using a multi-session FTP, or customware, or something UDP-based?
1-2MB is enough for most people for freemail space if they read their email every day or two. But if you don't catch up really often, a bad Sircam attack or a lot of spam with attached decoration can easily burn that space. There was this guy in India who kept sending me this 200 KB file in order to have my advice. Several times per day. It wasn't an account I use very often, and it has a high limit, and every six months or so I go clean up 500 spams.
A year or two ago, 2MB of disk space cost 1 cent at Fry's*. Now that penny gets you 10MB. So why did MSHotmail change their capacity limits in the OTHER direction?
It's true that raw disk capacity isn't their only cost:-) But CPUs keep gaining performance, and wholesale internet bandwidth keeps getting cheaper. Labor for managing the space doesn't keep getting cheaper, though there's some downward pressure given the current dot-com bust, and system management automation software should keep getting more powerful, reducing the amount of sysadmin time per Hotmail customer.
* 20GB drive for $100 then; $100 is now about 100 GB, depending on what's on sale. (More often 60-80GB, if you don't catch a really good sale.)
Since you do computational chemistry using grant money, I'm guessing you're at a university. Apple *is* trying to sell processors to that market, but they might also be talked into donating some, especially if you can make your chemistry code open-source so their paying customers can use it and buy more computers. It's probably at least as easy to beg one from Apple as it is to do your large-grant paperwork to get the cash to buy one.
Last I saw, a license or 25 or 50 or 100 Linux users was free.... if you want to run Windows, there are far more serious problems than the price:-). Darwin may be a decent Unix implementation, but I don't see why this is such an amazing win compared to a 1U server. (Admittedly, I couldn't get Dell's web page to simply give me a list price without becoming a registered customer:-)
If you dislike Ameritech so much that you won't pay THEM $10-15/month to get an phone line with a dial-tone you never use that enables you to spend $160 for a really-high-speed ADSL connection that does linesharing, fine, attitude is its own reward. You could get SDSL instead, and a number of vendors will hide from you the fact that they're paying Ameritech $20-25 to rent the copper:-)
It won't get quite the speed that the high-speed ADSL might be able to get, but it doesn't do line-sharing, and there's no need for a dialtone.
Slashdot Mirror
A decade or so ago we did a consulting gig out at a different national lab, which then had a classified-projects design network and a regular network, and they'd decided they wanted to do the fastest hairiest network they could for the classified net, because the security decisions involved in changing or upgrading things were so painful and difficult. They decided that a gigabite/second per user was about enough - because that's enough for two 32-bit-color 30fps 1024x1024 displays, so the bottleneck is no longer the user's computer, it's the user's eyeballs. In reality, they could use a bit more today, because we're close to 2Kx2K displays, but back then that was about as greedy as they could get, and there wasn't really anything that quite did that:-)
Obviously if you're actually going anywhere, you want fiber, and the ability to go 10-20km over fiber (for GigE and also for storage-network technologies like FibreChannel) is starting to change the economics and scaling decisions about where you put servers and storage, how much clustering you do, how you handle disaster recovery, etc., but for inside wiring, copper is still convenient.
The SiPix seems to be a battery hog - I'm now using NiMH rechargables instead of the rechargable alkalines I used at first, which helps a lot, but at least they're all standard AAA batteries, so in a pinch you can switch batteries on the fly and hope you don't lose any pictures :-(. And it really *is* nice and small, though you need to keep it in the case since there's no lens cap. Unlike my old Toshiba PDR camera (lens scratch - sigh...), or most higher-end cameras, the software doesn't look like a disk drive - it uses Twain drivers and some hokey software that copies them into temporary files and encourages you to edit them with lame decorations. I've had other cheap cameras that also did this. Much more trouble, but once you figure it out you can work around the limitations, and at least it's running on USB power while it does it.
I've noticed that a lot of the cheap digital cameras lately are taking advantage of rapidly decreasing memory prices by doing less compression - instead of 2MB memory with tightly compressed pictures, they've got 8MB memory, and the files are about twice as big, maybe more. My guess is that this lets them save money and/or battery by using dumber CPUs or get faster storage performance.
My Psion 3A and my Palm 3 and Palm 7 all last for a couple of weeks on battery, using either regular or rechargeable alkaline or NiMH. Newer battery technologies like Lithium Polymer seem to be even more promising. Good power management in the device, and good recharging technology for rechargeables, and ability to use AC power adapters if you need to do long periods of work (without trashing the recharging performance) are really all you need unless you want to carry a high-power-drain CPU-blaster with you.
QNX is probably the best-known working microkernel system out there. (Mach is better-known, but nobody actually used the microkernel versions, they used the 2.5ish versions like Next mostly.) Runs on a reasonably large number of Intel platforms, though unfortunately the single-floppy network demo only had drivers for a model of Ethernet card I didn't have, and hasn't been updated since 1999. They've probably had enough bloatware that the kernel no longer fits in 4KB (but newer Intel chips have bigger L1 caches these days :-), not that you're really need it to stay in L1.
As you and others have said, if nothing goes bad, it doesn't take much maintenance to keep running, though it's adding new service that needs resources and causes mistakes that break things.
There are other parts of KPNQwest that do run on general-purpose computers, such as the administrative and billing databases, network management systems, etc. Probably some are running Windows or Linux, and others are probably running Solaris or HPUX.
Not every college student has a computer, and not every computer is a laptop, and not every laptop has a wireless LAN card (though the latter's become affordable, if the college has the access points). The jobs of an open lab have changed a lot from the days when most work was on terminals connected to a big shared machine, and they'll keep changing as technology changes the affordability and portability of the average student's computing resources, and y'all in the academic-staff business will have to keep hopping, reinventing yourselves, and getting new budgets approved.
So what are they for now?
Or do you hire a clerk to rebuild the database by looking through the books? At some point, that probably wins, at least to the extent that the indexing is mostly gruntwork rather than creative thought. That doesn't mean it's not worth posting the file to the web and asking for volunteers to hack it, which would be a fine idea.
A long long time ago, on an IBM System34 far far away, somebody out in the shop wanted to turn off his welder by flipping circuit breakers, and found the computer room before he found the welder, and the 34's quaint little operating system wasn't designed for that sort of thing; the open file which represented six or seven hours of typing by our accounting clerk got truncated to its last good state. I spent about 5 hours on the phone with IBM tech support doing the hexedit on the disk drive to find the right pointers and patch it so we could recover the file. If it had taken much longer, we'd have been better off retyping the thing.... But of course, sometimes you only know that in hindsight.
The interesting thing about quantum computing is that it's the one technology that, if it's actually possible to develop usable machines with it, might offer the possibility of getting beyond the exponential-difficulty traps in factoring and other current techniques of public-key math. It's not clear that it will work, but it's the only thing so far that doesn't hit the "well, if you build a keycracking computer the size of the planet and run it for the remaining age of the solar system, I can add three more key bits and make you take over some more planets" wall.
They're not off the shelf, and won't be any time soon. The biggest quantum computer made so far was able to factor 15 into 5 x 3. The number of bits of answer you can get out of a quantum computer depends on the precision to which you can measure its output - does this hit Heisenberg limits? 10**47 is only ~140 bits. Or do you hit practical limits first? Or are there ways to break up the answer into many parts each of which gets you a few bits of precision? (The latter case is the only way to get it to work...)
What if quantum crypto does work? Maybe it'll crack conventional RSA and Diffie-Hellman, but that doesn't mean it transfers to Elliptic-Curve cracking, so we may luck out. Alternatively, it's back to conventional techniques like Kerberos and other symmetric-based Key Distribution Center systems.
But basically, you're trolling
Back in the mumblety-early 80s, when Unix was a trademark of Bell Labs and/or AT&T and/or Western Union and a commercial product, the Fedz put out an RFP for a big software project, which included the then-not-uncommon requirement (for custom software deals) that they get unlimited rights to all the software delivered - that meant not just access to the source, but the ability to do anything they want to with it, resell it, modify it, whatever. They didn't insist that they _had_ to buy that as part of the final deal, but it had to be offered and priced. The rumor is that we gave them a price, which reflected what we thought the future commercial value of Unix was - a cool $1B. They said thank you, checked the box on their form, and didn't buy it :-) (Too bad - I forget what the price that the rights to Unix finally sold for, but it was a lot less.... though by then we had *BSD and Linux available under various free-ish licenses.)
They think Slashdot discussed it in April 1999" and cached that too.
Apparently, Maryland's Cable TV Service Theft Laws are designed with guilty-until-proven-innocent built in, and "Comcast The TV Company" and "Comcast the Cable Modem Company" didn't talk to each other very well about who was buying what services, so the author got a Kafka-esque runaround because she wasn't a TV-watching couch potato.
Shredding and compressing mail messages is almost always a bad idea. Essentially *nobody* does it correctly, and you can't reconstruct messages in their original byte-for-byte formats, which trashes digital signatures. You won't save much disk space, because real text doesn't take up enough space for anybody except a big ISP mailsystem to worry about, and binary attachments usually only compress well if they've been encoded in some non-8-bit-transparency format like base64 or uucode. About the only time it wins is when one person on your keep-mail-on-server mailsystem is sending an attachment to a bunch of people who can then all use the original, which is to say they should probably have stored the file on the web and mailed a URL. If you're going to do things like this, get yourself a compression-equipped filesystem and just store your raw mail messages there.
The anti-virus people have certainly done lots of benchmarking, but the most critical way to speed it up is not to scan stuff you don't need to be scanning. Maybe you should be scanning new files acquired from the Internet, and maybe even scanning files you save to disk, but neither one of those is the 50MB/sec disk speed - you don't need to scan a file every time you read it if your operating system can keep track of when it was last changed, and most viruses can be detected in the first block or two of a file, so you don't need to scan the whole body of most files, just the suspect parts.
By the way, I'm the source of at least some of the anecdotes Joel mentions about laptop screens being received on televisions - I no longer have that laptop, but my mom still has the TV
you can look in the window and see the iMac sitting on the desk. (Unlike daytime, when you can see that my laptop is pointed the wrong way.) Of course, if you look more closely, you'll see that it's really just an iMac *poster* positioned at the right height :-)
TCP windows get up to 64KB - that's the most you can have outstanding waiting for ACKs, because that's all the bits the header has room for. Typical windows are more like 2KB-8KB. The problem, for long-haul data connections, is that the size of the window times the transmission latency is the maximum rate you can transmit data. So if you have a satellite with a 0.5 second round-trip time (roughly) and a 64KB TCP window, your maximum speed is 128KB/sec, aka 1024 kbps, which doesn't fill a T1. If you've got a 10000-mile round-trip (Alaska to NL is probably farther than that) the speed-of-light limit on RTT is about 100ms, so you're limited to about 5Mbps/sec. These guys went a lot faster than that, so they were clearly doing something intelligent, like keeping multiple TCP windows open, or using UDP with applications that do their own ACKs.
Any idea what software they used for the transfer? A simple TCP session won't work - the maximum window size of 64KB limits the transfer rate over large speed*delay products. Were they using a multi-session FTP, or customware, or something UDP-based?
1-2MB is enough for most people for freemail space if they read their email every day or two. But if you don't catch up really often, a bad Sircam attack or a lot of spam with attached decoration can easily burn that space. There was this guy in India who kept sending me this 200 KB file in order to have my advice. Several times per day. It wasn't an account I use very often, and it has a high limit, and every six months or so I go clean up 500 spams.
It's true that raw disk capacity isn't their only cost :-) But CPUs keep gaining performance, and wholesale internet bandwidth keeps getting cheaper. Labor for managing the space doesn't keep getting cheaper, though there's some downward pressure given the current dot-com bust, and system management automation software should keep getting more powerful, reducing the amount of sysadmin time per Hotmail customer.
* 20GB drive for $100 then; $100 is now about 100 GB, depending on what's on sale. (More often 60-80GB, if you don't catch a really good sale.)
Hey, there are priorities in life :-)
Since you do computational chemistry using grant money, I'm guessing you're at a university. Apple *is* trying to sell processors to that market, but they might also be talked into donating some, especially if you can make your chemistry code open-source so their paying customers can use it and buy more computers. It's probably at least as easy to beg one from Apple as it is to do your large-grant paperwork to get the cash to buy one.
Last I saw, a license or 25 or 50 or 100 Linux users was free.... if you want to run Windows, there are far more serious problems than the price :-). Darwin may be a decent Unix implementation, but I don't see why this is such an amazing win compared to a 1U server. (Admittedly, I couldn't get Dell's web page to simply give me a list price without becoming a registered customer :-)
It won't get quite the speed that the high-speed ADSL might be able to get, but it doesn't do line-sharing, and there's no need for a dialtone.