Good. Now that they are turning on themselves, they will leave us alone for awhile.
This isn't good, it's bad. Bad Scenario - they sue us and win. Good Scenario - they sue us and lose. Worst Possible Scenario - they sue themselves and lose intentionally just to set a court precedent to make it far easier to sue us.
Perhaps for a very end user - I for one use Portage's features on a daily basis. make.conf is my freind, as is sandbox, "emerge config", and a host of other small innovations that add up to a lot.
You're rude, obnoxious, and uninformed. I'm not talking about PCs either you uneducated fuckwit. But let's digress for a minute:
1) the "10% is 10%" argument applies to money, time, and power - so your point is moot.
2) If you're paying people for cpu horsepower per hour, you're living in the stone age and you need to get with it. I bet I could take a month of your fees and purchase all the compute power you need permanently, and it would probably remain fast enough for you for at least a year or so before needing upgrade.
Inverse Multiplexing would happen at the dsl modem level, not at the ip level. It would require inverse multiplex support at your provider's DSLAM, and you would probably be using multiple lines under a single account.
IMHO the best way for a residential consumer to get more bandwidth (and reliability) is to multi-NAT your home network. Sign up for a couple of DSL lines (maybe pretend to be stupid enough that you want a second DSL for another room in the house or something) and perhaps a Cable Modem hokoup for redundancy and a bit more bandwidth.
Into the ethernet jacks of each of the 3 or so modems, plug a direct crossover cable to seperate ethernet ports on your NAT/Firewall/Router box. A Sun Ultra 5 running OpenBSD with a quad fast ethernet card would work great.
Have your NAT box run three dhcp client instances to get IPs on all three interfaces, and have it run NAT for a private network on the back.
The last remaining part of the puzzle is having the gateway loadbalance the three available default routes per connection stream, either round-robin or by utilization.
Hopefully someone will reply with a pre-shink-wrapped answer to that part, and preferably on OpenBSD since I already mentioned it, but I guess ultrapenguin could work too:)
Both conductive touch sensors and tripping light beams are good ideas, mentioned multiply above. In both cases all parts can be had at radio shack, and check out the Mini Engineer's Notebooks by Forrest Mims for circuit designs for both (also sold at Radio Shack). They used to come as seperate small thin booklets, but I think recently they've compiled them all into one larger book.
In either case you'll probably want to mount the device to her hand/arm so that her finger/wrist movement (whichever is still available) is always in range of the touch/light sensor. If you're doing it on the cheap, you might look around the sporting goods section of walmart (or a sports store like Oshmans or whatever) for mounting hardware. One thing that comes to mind is the professional-style slinghots that have a brace going back over the forearm, I'm sure there's lots more material to work from around there like medical wrist supports with the metal band that goes up under the wrist and whatnot.
If you're worried about your device failing on her, and both hands work - you could build two devices, mount one on each arm, and encourage her to alternate using them so she knows they both work. You could take redundancy a step further by making one of them light-based and the other touch-based, in case one or the other designs fails in some wierd circumstance.
Yes but 10% is 10%. If 10% is two days to you, it's two out of twenty - was it worth it? Given the whole Moore's law shebang, is 10% at any given time worth it when the 100% increases in underlying hardware come so fast?
It's at 2317 package currently, not bad for an distro that just made it second official release ever. I would think it will quickly pass the 8000 mark.
I've never touched Fortran in my life, and I have no desire to. I hear all the time about how fortran code is faster than language_x for math, but I have a hard time buying it.
In most cases, does a given numerical algorithm well-coded in C underperform the same algorithm well-coded in Fortan? Assume of course there are better and more expensive optimizing C compilers, as there are for Fortran.
If so, by how much? if it's 10%, or even 20-30%, I would think it's not worth the trouble of using a nonstandard language. Your next hardware upgrade will make C just as fast if not faster.
If Fortran wins - I would assume the win is because the restrictiveness and explicitness of the language make it easier for an optimizer to *really* know what's going and how to optimize things away safely. In this case I have to ask - can't you still code 90% in C and the rest in assembler - or be careful about your C code's semantics to make sure optimizations are obvious to the compiler? And wouldn't eitherof those still be preferable to supporting a klunky old language?
Of course in the process of producing ethanol for consumption in a car, the raw amount of energy delivered to the car per gallon of ethanol will be less than the raw total amount of energy that went into producing the ethanol. It's a basic fact that no process is perfectly conservative of energy, or else we could build perpetual motion mechanisms.
It's probably not much less efficient than oil - and more importantly corn can be renewed at a *very* fast pace compared to oil. It can also be grown where we choose, instead of explored for and drilled from special reserves. It also burns cleaner - and the extra plants should help the environment.
On RAID technologies, speaking in general terms assuming vendors do a good job of implementing it, here's a summary:
RAID 0: Pure striping, maximum performance, no redundancy. Cost is the same as concatenating disks to get the space you need.
RAID 1: Pure Mirroring, full redundancy - reads can be as fast as a stripe of the same width as the number of mirrors (2-way stripe, 2-way mirror, same read speed, etc) if they do round-robin reading. Writes happen in parallel, and can be slower unless you've got the headroom and the disk spindle is the only write bottleneck. Cost is double a simple concat or stripe.
RAID 2-4: Sometimes used for very special purposes, but generally ignored by all because one of the other raid levels does the same thing better. I've seen RAID-3 recently, there are occasionally valid uses for like 0.01% of people out there.
RAID 5: You get some data redundancy to survive a single disk failure, but you don't pay the double disk cost of full mirroring. It's an N+1 type of configuration. Speed is generally the slowest compared to everything else.
Now on top of those very basic things, there are other factors. Because RAID-5 is cheapest disk-wise, and (IMHO) because it has the highest number of the well-standardized RAID levels, RAID-5 is very popular. To make up for RAID-5's abysmal performance, people use hardware RAID-5 accelerators with cache and whatnot. The problem there is that the controller can add significant cost (in some cases enough to have paid for a full mirror in plainly controlled disks), and that the RAID controller itself can become a single point of failure.
At my office (where a lot of bad decisions get made every day and I have to eat it) they built a Veritas cluster of Sun machines around a SAN. The idea was that no node was a single point of failure because of clustering (with veritas allowing all nodes to reach the SAN storage). However, the SAN storage was a big fat RAID-5 array with redundant controllers/disks/yadda/yadda. Of course, as much as the vendor tries to bury it in the fine print, the RAID-5 hardware is a single point of failure. Sure enough, our very reputable vendor's "redundant" hardware raid-5 controller did fully fail one, knocking our data offline for hours.
For the same cost as the expensive raid-5 array and the disks in it, we could have bought two independant JBOD arrays (just a bunch of disks, no raid controller), placed them on the redundant SAN, with the redundant clustered machines doing software mirroring to the disks, and been truly free from single points of failure (assuming we do all the details right - that the mirrors are always across seperate arrays, and that the arrays are on seperate power, etc)..
I've spent a lot of time on these problems, and it is my strong belief that the optimal solution for almost all normal situations where you want high availability is to do software mirror/stripe (1+0). Be careful that there is a difference between 1+0 and 0+1 when the 0 part's stripe is more than two disks wide... Consider two JBOD arrays of 5x 36G disks each...
In 0+1, you first stripe each array into a 180G stripe, then mirror the two together. When your first disk fails, nothing so mcuh as hiccups. However, of your remaining 9 disks, if any of the 5 disks in the array opposite the one with the first disk fails, you will lose data. Thus there's a 5/9 chance that the second disk failure causes data loss.
In 1+0, you first mirror each disk from the first array with its partnet in the second array. You then take your 5 36G mirrors and stripe them together for your 180G. Again, first failure, no hiccups. If a second disk fails, in order to cause data loss it must be the partner of the first failed disk - any of the other disks can fail and you still lose nothing. So the chances of data loss on a second disk failure are now 1/9 instead of 5/9.
Gentoo Linux has a ports system that smokes BSD from a design standpoint, but it's still a little buggy at the moment. It's really cool to log into a freshly minimally installed Gentoo box as root and type "emerge gnome" or some such high level thing and watch it eat your processor for hours on end, compiling every dependency from scratch off the original tarballs from the net.
Fuck these people. If *any* private organization launches attacks at my machine, I will defend myself electronically and fight back. If any LEO shows up at my door for defending myself against these legitimized criminal organizations, well, I'll start excersicing my 2nd ammendment rights how they were meant to be excersiced.
Surveys survey the masses, which means computer illiterate people. It doesn't matter to them the ins and outs of where the randomization happens. If they have to put their real data into a form, they will assume the company asking the survey can get it if they want it. Telling them "don't worry, a client-side javascript function is randomizing this before it gets sent in" doesn't reassure them any more than the HibiJibi statement.
Yes, but surveys are tagetted at and only work with masses of people, the common plural man. From this person's perspective, it doesn't matter than the randomization technically happened in their PC in a java applet or javascript code. In either case they're entering personal data and trusting the company to not abuse them.
1) People lie on surveys, most likely because they don't trust the taker - but probably also just because they like putting in other answers (yeah, I'm a millionaire, woohoo!, etc). This only addresses the trust issue, ignoring other ptential sources of lying.
2) In order to work around the trust issue, they've developed a method of injecting random noise into the original answers as they are recorded and then extracting useful data in the end.
Notice their technology doesn't do anything to fix the underlying problem. The hope is that users will understand and trust the backend randomizer system, and that based on this trust they will answer more truthfully.
Without bothering with all this mumbo-jumbo, I can build a trustworthy system. I simply record survey statistics, and I promise not to use the individuals' personal data invidually.
They can either trust me that I'm telling the truth about this, or they can lie. In the IBM researchers' scenario, the users are again asked to trust that the backend system doesn't compromise them, and again they can choose to trust it or choose to lie.
Given the above, why on earth would you bother with this research and uneccesary complexity. It's not going to make any difference over just promising your users that you don't invade their privacy. You could replace their research results with a banner on top of the survey that says "After you sumbit your data to us, we use Magical HibiJibi technology to prevent ourselves from invading your privacy, so please trust us and answer truthfully"
The losses did *not* come from providing bandwidth at all. Worldcom's data business was the most profitable (in percentage of gross sales anyways) arm of the company. They lost in Long Distance Telephone, and other dying markets they were too heavily vested in.
IMHO, if Bernie had stopped his acquistion madness just after grabbing UUNet/MFS, and avoided going on and buying MCI, the company could have flourished. It was the acquisition on MCI that killed them. Sure, it brough InternetMCI, but it also brought way more than it's fair share of baggage.
You can even see Worldcom backpdeal on the MCI deal once they figured it out, as they took the crappy areas of the company and tried to spin them out as a tracking stock called MCIT (as it was largely former MCI business units). But the market didn't buy it and just kept hammering the main WCOM stock anyways.
That's why you get your own AS and participate in the global BGP. You then get your own netblock which is simultaneously visible through all your redundant connections.
There's lots of options available for SSH on Win32, a simple Google search turns them up. Specifically there's a free zipfile out there called ssh-win32.zip that contains a basic SSH terminal that works well. There's also GPL port-attempts of the unix commandline ssh tools, some of which work ok. In the cheapware/shareware category there's stuff like SecureCRT and F-Secure SSH. The list goes on and on... apparently some people like PuTTY.
I tried XFS for a bit, but I found it to be a bit too un-integrated for me. I like to put together my own kernels (grabbing various things from -ac and random other patches I like), and I've found that XFS (either on a source patch level or on a runtime stability level) is always a bit incompatible with other intrusive patches. It was just too much of a pain to be worth it to keep a solid XFS patchset in my kernel.
OTOH, ext3 works quite well, and is well-integrated in the mainline kernel. If your going for journalling to avoid fscks and for an overall saner and more stable filesystem, I would go ext3.
I paid for "Internet Access". Since I don't live in China, I expect that to mean uncensored, unabridged access to the global internetwork of IP-connected machines, using *any* IP protocol and/or port number that I see fit, within the limit of the bandwidth agreement we have.
I have tried to explain this to TWC multiple times by email when complaining of technical issues that they are cuasing, but they don't give a damn and still refuse to inform their customers.
They block inbound port 80, so that even with a DynDNS setup you can't run a home webserver without resorting to a non-default port. They state in their contract that you're not allowed to run any "server" services, enumerating several like smtp servers, news, www, etc.
The problem is that they see certain things (KaZaa, home web server, etc...) as eating up disproportionate amounts of their bandwidth, so they try to block the protocols to save themselves bandwidth.
IMHO - I paid for unlimited access at Cable's advertised speeds (shared with my neighborhood loop of course), and that's that. If they don't me using so much, don't sell me so much. If they *must*, they should implement monthly xfer limits in the up and down directions and charge for going over (e.g. 10GB down and 1GB up permonth for the usual low monthly fee, larger packages available).
I would much rather be limited in GB/mo that be limited in which ports/protocols I can use. I don't want (nor did I purchase) a Web/Email-only service. I want my IP access.
One good suggestion is to let a pro design your new datacenter, or at least help you out. I've had some really good experiences with IBM Global Services - they worked with us on overall design, and we bought and installed the raised floor, cable management, cabling, UPSs, cooling units, etc... through them. Companies like that have a lot of experiential knowledge you can lean on, it takes a lot of practice to learn how to design a rock solid datacenter without overdesigning too much.
That aside - You say 5 racks and 25 monitors in a command center - sounds like one monitor in your command center for every machine you own or something. Consider using switches and keeping your command center down to 4 heads or so (or however many you think you need for simultaneous admin access). You can set up a network of kvm switches such that any of your 4 head units can reach any of your 25 machines easily. If they're *nix, skip the kvm stuff alltogether and just go serail console. Cyclades makes a nice linux-based serial terminal server with ssh support and whatnot.
You'd think whoever was charged with designing a new coinage would have been tasked with making sure they are easily distinguishable by all, including older people with bad vision, the color blind, etc...
Slashdot Mirror
This isn't good, it's bad. Bad Scenario - they sue us and win. Good Scenario - they sue us and lose. Worst Possible Scenario - they sue themselves and lose intentionally just to set a court precedent to make it far easier to sue us.
Perhaps for a very end user - I for one use Portage's features on a daily basis. make.conf is my freind, as is sandbox, "emerge config", and a host of other small innovations that add up to a lot.
You're rude, obnoxious, and uninformed. I'm not talking about PCs either you uneducated fuckwit. But let's digress for a minute:
1) the "10% is 10%" argument applies to money, time, and power - so your point is moot.
2) If you're paying people for cpu horsepower per hour, you're living in the stone age and you need to get with it. I bet I could take a month of your fees and purchase all the compute power you need permanently, and it would probably remain fast enough for you for at least a year or so before needing upgrade.
Inverse Multiplexing would happen at the dsl modem level, not at the ip level. It would require inverse multiplex support at your provider's DSLAM, and you would probably be using multiple lines under a single account.
IMHO the best way for a residential consumer to get more bandwidth (and reliability) is to multi-NAT your home network. Sign up for a couple of DSL lines (maybe pretend to be stupid enough that you want a second DSL for another room in the house or something) and perhaps a Cable Modem hokoup for redundancy and a bit more bandwidth.
Into the ethernet jacks of each of the 3 or so modems, plug a direct crossover cable to seperate ethernet ports on your NAT/Firewall/Router box. A Sun Ultra 5 running OpenBSD with a quad fast ethernet card would work great.
Have your NAT box run three dhcp client instances to get IPs on all three interfaces, and have it run NAT for a private network on the back.
The last remaining part of the puzzle is having the gateway loadbalance the three available default routes per connection stream, either round-robin or by utilization.
Hopefully someone will reply with a pre-shink-wrapped answer to that part, and preferably on OpenBSD since I already mentioned it, but I guess ultrapenguin could work too
Both conductive touch sensors and tripping light beams are good ideas, mentioned multiply above. In both cases all parts can be had at radio shack, and check out the Mini Engineer's Notebooks by Forrest Mims for circuit designs for both (also sold at Radio Shack). They used to come as seperate small thin booklets, but I think recently they've compiled them all into one larger book.
In either case you'll probably want to mount the device to her hand/arm so that her finger/wrist movement (whichever is still available) is always in range of the touch/light sensor. If you're doing it on the cheap, you might look around the sporting goods section of walmart (or a sports store like Oshmans or whatever) for mounting hardware. One thing that comes to mind is the professional-style slinghots that have a brace going back over the forearm, I'm sure there's lots more material to work from around there like medical wrist supports with the metal band that goes up under the wrist and whatnot.
If you're worried about your device failing on her, and both hands work - you could build two devices, mount one on each arm, and encourage her to alternate using them so she knows they both work. You could take redundancy a step further by making one of them light-based and the other touch-based, in case one or the other designs fails in some wierd circumstance.
Yes but 10% is 10%. If 10% is two days to you, it's two out of twenty - was it worth it? Given the whole Moore's law shebang, is 10% at any given time worth it when the 100% increases in underlying hardware come so fast?
Have a look at the Portage Manual to see how their ports system works. It does smoke FreeBSD's make install.
It's at 2317 package currently, not bad for an distro that just made it second official release ever. I would think it will quickly pass the 8000 mark.
I've never touched Fortran in my life, and I have no desire to. I hear all the time about how fortran code is faster than language_x for math, but I have a hard time buying it.
In most cases, does a given numerical algorithm well-coded in C underperform the same algorithm well-coded in Fortan? Assume of course there are better and more expensive optimizing C compilers, as there are for Fortran.
If so, by how much? if it's 10%, or even 20-30%, I would think it's not worth the trouble of using a nonstandard language. Your next hardware upgrade will make C just as fast if not faster.
If Fortran wins - I would assume the win is because the restrictiveness and explicitness of the language make it easier for an optimizer to *really* know what's going and how to optimize things away safely. In this case I have to ask - can't you still code 90% in C and the rest in assembler - or be careful about your C code's semantics to make sure optimizations are obvious to the compiler? And wouldn't eitherof those still be preferable to supporting a klunky old language?
Of course in the process of producing ethanol for consumption in a car, the raw amount of energy delivered to the car per gallon of ethanol will be less than the raw total amount of energy that went into producing the ethanol. It's a basic fact that no process is perfectly conservative of energy, or else we could build perpetual motion mechanisms.
It's probably not much less efficient than oil - and more importantly corn can be renewed at a *very* fast pace compared to oil. It can also be grown where we choose, instead of explored for and drilled from special reserves. It also burns cleaner - and the extra plants should help the environment.
On RAID technologies, speaking in general terms assuming vendors do a good job of implementing it, here's a summary:
RAID 0: Pure striping, maximum performance, no redundancy. Cost is the same as concatenating disks to get the space you need.
RAID 1: Pure Mirroring, full redundancy - reads can be as fast as a stripe of the same width as the number of mirrors (2-way stripe, 2-way mirror, same read speed, etc) if they do round-robin reading. Writes happen in parallel, and can be slower unless you've got the headroom and the disk spindle is the only write bottleneck. Cost is double a simple concat or stripe.
RAID 2-4: Sometimes used for very special purposes, but generally ignored by all because one of the other raid levels does the same thing better. I've seen RAID-3 recently, there are occasionally valid uses for like 0.01% of people out there.
RAID 5: You get some data redundancy to survive a single disk failure, but you don't pay the double disk cost of full mirroring. It's an N+1 type of configuration. Speed is generally the slowest compared to everything else.
Now on top of those very basic things, there are other factors. Because RAID-5 is cheapest disk-wise, and (IMHO) because it has the highest number of the well-standardized RAID levels, RAID-5 is very popular. To make up for RAID-5's abysmal performance, people use hardware RAID-5 accelerators with cache and whatnot. The problem there is that the controller can add significant cost (in some cases enough to have paid for a full mirror in plainly controlled disks), and that the RAID controller itself can become a single point of failure.
At my office (where a lot of bad decisions get made every day and I have to eat it) they built a Veritas cluster of Sun machines around a SAN. The idea was that no node was a single point of failure because of clustering (with veritas allowing all nodes to reach the SAN storage). However, the SAN storage was a big fat RAID-5 array with redundant controllers/disks/yadda/yadda. Of course, as much as the vendor tries to bury it in the fine print, the RAID-5 hardware is a single point of failure. Sure enough, our very reputable vendor's "redundant" hardware raid-5 controller did fully fail one, knocking our data offline for hours.
For the same cost as the expensive raid-5 array and the disks in it, we could have bought two independant JBOD arrays (just a bunch of disks, no raid controller), placed them on the redundant SAN, with the redundant clustered machines doing software mirroring to the disks, and been truly free from single points of failure (assuming we do all the details right - that the mirrors are always across seperate arrays, and that the arrays are on seperate power, etc)..
I've spent a lot of time on these problems, and it is my strong belief that the optimal solution for almost all normal situations where you want high availability is to do software mirror/stripe (1+0). Be careful that there is a difference between 1+0 and 0+1 when the 0 part's stripe is more than two disks wide... Consider two JBOD arrays of 5x 36G disks each...
In 0+1, you first stripe each array into a 180G stripe, then mirror the two together. When your first disk fails, nothing so mcuh as hiccups. However, of your remaining 9 disks, if any of the 5 disks in the array opposite the one with the first disk fails, you will lose data. Thus there's a 5/9 chance that the second disk failure causes data loss.
In 1+0, you first mirror each disk from the first array with its partnet in the second array. You then take your 5 36G mirrors and stripe them together for your 180G. Again, first failure, no hiccups. If a second disk fails, in order to cause data loss it must be the partner of the first failed disk - any of the other disks can fail and you still lose nothing. So the chances of data loss on a second disk failure are now 1/9 instead of 5/9.
Gentoo Linux has a ports system that smokes BSD from a design standpoint, but it's still a little buggy at the moment. It's really cool to log into a freshly minimally installed Gentoo box as root and type "emerge gnome" or some such high level thing and watch it eat your processor for hours on end, compiling every dependency from scratch off the original tarballs from the net.
Fuck these people. If *any* private organization launches attacks at my machine, I will defend myself electronically and fight back. If any LEO shows up at my door for defending myself against these legitimized criminal organizations, well, I'll start excersicing my 2nd ammendment rights how they were meant to be excersiced.
No, you're still stupid.
Surveys survey the masses, which means computer illiterate people. It doesn't matter to them the ins and outs of where the randomization happens. If they have to put their real data into a form, they will assume the company asking the survey can get it if they want it. Telling them "don't worry, a client-side javascript function is randomizing this before it gets sent in" doesn't reassure them any more than the HibiJibi statement.
Yes, but surveys are tagetted at and only work with masses of people, the common plural man. From this person's perspective, it doesn't matter than the randomization technically happened in their PC in a java applet or javascript code. In either case they're entering personal data and trusting the company to not abuse them.
Let me summarize:
1) People lie on surveys, most likely because they don't trust the taker - but probably also just because they like putting in other answers (yeah, I'm a millionaire, woohoo!, etc). This only addresses the trust issue, ignoring other ptential sources of lying.
2) In order to work around the trust issue, they've developed a method of injecting random noise into the original answers as they are recorded and then extracting useful data in the end.
Notice their technology doesn't do anything to fix the underlying problem. The hope is that users will understand and trust the backend randomizer system, and that based on this trust they will answer more truthfully.
Without bothering with all this mumbo-jumbo, I can build a trustworthy system. I simply record survey statistics, and I promise not to use the individuals' personal data invidually.
They can either trust me that I'm telling the truth about this, or they can lie. In the IBM researchers' scenario, the users are again asked to trust that the backend system doesn't compromise them, and again they can choose to trust it or choose to lie.
Given the above, why on earth would you bother with this research and uneccesary complexity. It's not going to make any difference over just promising your users that you don't invade their privacy. You could replace their research results with a banner on top of the survey that says "After you sumbit your data to us, we use Magical HibiJibi technology to prevent ourselves from invading your privacy, so please trust us and answer truthfully"
What a waste of research.
The losses did *not* come from providing bandwidth at all. Worldcom's data business was the most profitable (in percentage of gross sales anyways) arm of the company. They lost in Long Distance Telephone, and other dying markets they were too heavily vested in.
IMHO, if Bernie had stopped his acquistion madness just after grabbing UUNet/MFS, and avoided going on and buying MCI, the company could have flourished. It was the acquisition on MCI that killed them. Sure, it brough InternetMCI, but it also brought way more than it's fair share of baggage.
You can even see Worldcom backpdeal on the MCI deal once they figured it out, as they took the crappy areas of the company and tried to spin them out as a tracking stock called MCIT (as it was largely former MCI business units). But the market didn't buy it and just kept hammering the main WCOM stock anyways.
That's why you get your own AS and participate in the global BGP. You then get your own netblock which is simultaneously visible through all your redundant connections.
Surely the 3.0 release is a hoax - they can't possibly have a stable release that includes the *current* stable kernel _and_ the latest XFree.
There's lots of options available for SSH on Win32, a simple Google search turns them up. Specifically there's a free zipfile out there called ssh-win32.zip that contains a basic SSH terminal that works well. There's also GPL port-attempts of the unix commandline ssh tools, some of which work ok. In the cheapware/shareware category there's stuff like SecureCRT and F-Secure SSH. The list goes on and on... apparently some people like PuTTY.
I tried XFS for a bit, but I found it to be a bit too un-integrated for me. I like to put together my own kernels (grabbing various things from -ac and random other patches I like), and I've found that XFS (either on a source patch level or on a runtime stability level) is always a bit incompatible with other intrusive patches. It was just too much of a pain to be worth it to keep a solid XFS patchset in my kernel.
OTOH, ext3 works quite well, and is well-integrated in the mainline kernel. If your going for journalling to avoid fscks and for an overall saner and more stable filesystem, I would go ext3.
I paid for "Internet Access". Since I don't live in China, I expect that to mean uncensored, unabridged access to the global internetwork of IP-connected machines, using *any* IP protocol and/or port number that I see fit, within the limit of the bandwidth agreement we have.
I have tried to explain this to TWC multiple times by email when complaining of technical issues that they are cuasing, but they don't give a damn and still refuse to inform their customers.
They block inbound port 80, so that even with a DynDNS setup you can't run a home webserver without resorting to a non-default port. They state in their contract that you're not allowed to run any "server" services, enumerating several like smtp servers, news, www, etc.
The problem is that they see certain things (KaZaa, home web server, etc...) as eating up disproportionate amounts of their bandwidth, so they try to block the protocols to save themselves bandwidth.
IMHO - I paid for unlimited access at Cable's advertised speeds (shared with my neighborhood loop of course), and that's that. If they don't me using so much, don't sell me so much. If they *must*, they should implement monthly xfer limits in the up and down directions and charge for going over (e.g. 10GB down and 1GB up permonth for the usual low monthly fee, larger packages available).
I would much rather be limited in GB/mo that be limited in which ports/protocols I can use. I don't want (nor did I purchase) a Web/Email-only service. I want my IP access.
They should have picked another name. XNS will always mean to me Xerox Network Systems.
One good suggestion is to let a pro design your new datacenter, or at least help you out. I've had some really good experiences with IBM Global Services - they worked with us on overall design, and we bought and installed the raised floor, cable management, cabling, UPSs, cooling units, etc... through them. Companies like that have a lot of experiential knowledge you can lean on, it takes a lot of practice to learn how to design a rock solid datacenter without overdesigning too much.
That aside - You say 5 racks and 25 monitors in a command center - sounds like one monitor in your command center for every machine you own or something. Consider using switches and keeping your command center down to 4 heads or so (or however many you think you need for simultaneous admin access). You can set up a network of kvm switches such that any of your 4 head units can reach any of your 25 machines easily. If they're *nix, skip the kvm stuff alltogether and just go serail console. Cyclades makes a nice linux-based serial terminal server with ssh support and whatnot.
You'd think whoever was charged with designing a new coinage would have been tasked with making sure they are easily distinguishable by all, including older people with bad vision, the color blind, etc...