I can't believe they're still using ATM. I mean, seriously what is this 1996?

"Ve...haf vays... of making you valk...'

You mean MySQL 5.0. Latest version via yum on RHEL 5 series is MySQL 5.0.95.

You can backport and install 5.5 on it I believe, but that's not exactly out of the box. This article states that official 5.5 support for RHEL5 is beta...

https://access.redhat.com/solutions/106493

Every one of these is supported by Red Hat. Call them out for other things, but do your research first. I'm upgrading MySQL from 5.1 to 5.5 and many of these are specifically in new Red Hat Collections.
https://access.redhat.com/documentation/en-US/Red_Hat_Software_Collections/1/html-single/1.1_Release_Notes/index.html#sect-Installation_and_Usage-Install

Since the idea is that this universe is a simulation, who says it is a simulation of reality? Maybe we are some kids crazy fantasy world in which the container has to be larger then its contents! FREAKY!

The trick to thinking outside the box, is to stop thinking the box is real.

IF this is a simulated world, there is no reason to assume the rules in the simulation are the same as the ones of the world in which the simulation is running.

This doesn't apply to four post gear or anything that gets too toasty; but the fact that a lot of music related hardware is rackmount and has to survive roadies and touring makes rack hardware surprisingly attractive for mobile use. If the job is too big for a laptop and small enough for half depth hardware, just check out the local music supply place and pick out a nice portable rack. Quite sturdy and shock resistant, usually at least offers a front door that clips on well enough that you can ship it, available in a variety of heights(and typically stackable unless you go for a wheeled one). A very convenient overlap.

I doubt it would be trivial: you can sacrifice capacity for some speed by reducing the amount of platter area you use(and thus how far back and forth the read/write head assembly needs to move); but RPM is still a serious constraint, and bumping that tends to get rather costly. 15k RPM has been the effective ceiling for years, and while increases in data density improve best-case read and write speeds they have no effect on how long you have to wait for a given chunk of disk to finish its rotation and come back under the read head.

It also doesn't help that SSDs are aggressively moving into the high speed area. If you applied the engineering tricks used in ultracentrifuges you could probably build a damn fast HDD; but doing so for less than the price of a really nice SSD would be a great deal more challenging.

"A" home server? Who would have just one?
Local DNS, DHCP and DCHPv6 servers need failover, and onsite online backups are done cross-server.
So I'd think any nerd would have at least two.

I also have two different wired networks - one that is used for clients to talk to the servers and the gateway, and one that's used for servers to talk between themselves. There's no reason for traffic between a client and a server or internet to get slowed down just because one server backs itself up to another.

And two different Wireless N networks - one 2.4 and one 5 GHz. That way, using one band won't slow down the other.

They already have been changed to glucose before they become fat, which means that the body quite obviously could process them. That they became fat is because there weren't any takers for the glucose.

Wow, I can't believe that someone missed the point so completely!
The point being that it is unlikely that the brain is stealing the glucose and thus stunting growth like the article supports, because when kids are fat, that means they have metabolized carbs->glucose->fat, and thus have had plenty of glucose. That fat kids' bones don't appear to shoot past normal kids in growth strongly suggest that there are other reasons why kids don't grow physically to adults in half the time.

I suggest that being smaller and having different proportions to adults triggers the "do not harm" and "protect" instinct in most adults, thus increasing the chance of reaching adulthood and bringing one's genes on.
There are probably other survival advantages, like having less mass and more flexible bones might be adventageous at the age one learns to climb trees and cliffs.
When reaching the age where one is going to procreate and bring up own children, the advantage is to have a more adult body, capable of hunting, foraging, carrying and protecting.

Get it now, or are you going to get sidetracked by a single word again?

New Hampshire runs a very similar operation. I've never quite understood why a state whose motto is "Live Free or Die" lets The Man control their booze supply; but I imagine that the indirect tax of a state liquor monopoly is more popular than some direct tax levied elsewhere.

Between manufacturer avarice and customer stupidity I hold out very little hope; but it would warm my cold, black, shriveled, heart if somebody would standardize a key-fill interface (like the DS-101/DS-102 devices that the DoD has for connection to U-229 ports on communications gear and other things that need crypto keys; but actually remotely suitable for end users, unlike those systems) for dealing with this class of problems...

Right now, it seems like everything is either "Oh, totally wide open, maybe papered over with some pitiful little obfuscation attempt" or "So damn much asymmetric key crypto that you'll need to beg the vendor for permission to do anything"; but options are very, very, thin on the ground if you want something as secure as a mothership-bound lockdown device; but obedient to your crypto keys, not the ones burned in at the factory.

It's like the 'secure boot' controversy that erupted a while back. "Well, you can have Microsoft's keys and protection against certain types of OS tampering, or you can turn it off entirely(x86 only other restrictions may apply); but set your own root of trust? Ha!"

It's insane that it isn't easier to re-key/re-pair with a replacement device; but I suspect that it is otherwise very much for the best to move some functions to the iPod.

Apple has spent a Lot of money designing iDevices and perfecting them over multiple generations. Hard to say how much; but it's a large number. Conveniently for you, they'll sell 'em to you in quantities of 1 for a only a modest premium over production cost.

In an ideal world, the prosthesis would require no 'interface' at all(your arm doesn't, after all); but if it does, a company specializing in prosthetics doesn't have a prayer of delivering an interface device nearly as good as an iDevice or Android unit for less than they could just buy one and develop the necessary software on top of it. (In practice, they'd probably be lucky to develop something substantially worse for three powers of ten more, if they tried it.)

If it turns out that timing-critical control and feedback loop stuff is being done over bluetooth, by an 'app', somebody needs a hell of a beating; but if it's just a UI/Configuration/etc. interface using an off-the-shelf device is extremely logical.

It tends to be discouraged, out of concern that states aren't very good at it, or that they might be inclined to use their other powers to make themselves more competitive; but there isn't anything architecturally precluding a state from earning money. They can have employees, own and operate R&D and production facilities, sell products, same as a company.

There are reasons to discourage that, and have them focus on things that the private sector can't do or does poorly; but those are pragmatic considerations, not fundamental obstacles.