If you have the money (or want the debt), go to a "name" school for the highest degree you plan to pursue. If you set out to get a Masters degree, then you can get your Bachelors at a less recognized school (such as a decent quality state school). You just don't want to get the lower degree(s) from a low-quality school (e.g. no accreditation, bad reputation, degree mill, etc.), because that could impact your ability to get into the higher-level program. For the most part, once you have the higher-level degree, nobody cares where you started, so don't waste money and effort (e.g. busting your ass for good grades at a high-difficulty school, when an easier program somewhere else would get you to the next level) at the beginning.

If you aren't sure about the higher-level degree, or you don't always have good follow-through, go ahead and go to a bigger "name" school to start with.

The computers that flew were digital, but the computers that tested them were analog. My father worked on the Saturn V guidance system, and they built one of the earliest "hardware in the loop" simulation setups to test the software and flight-certify the computers that flew. Digital computers of the day were not fast enough to simulate the inputs and monitor the outputs in real time, so the simulation was built with analog computers.

I map the Windows logo key to Meta, and the other Windows key (context menu?) to Compose. I get an extra modifier for keyboard shortcuts, and I can easily type those funny characters like and ü.

We buy links from different upstream providers. Multiple links to the same provider only provides redundancy against link failure, not provider network problems, peering spats, etc. Also, buying two links from point A to point B from the same provider probably means they are muxed together, which means you don't have much redundancy at all. We use different local and long-haul carriers where possible, but that pushes up costs some more (you can't just find the cheapest provider and use them).

Yes, we can get flat rate. IIRC, our Internet transit OC-3s (155mbps) are around $6000-8000/month each, plus we have internal network links between POPs, routers to connect, power, cooling, etc. (and us employees like to get paid). We also have redundant links so a failure of one link doesn't cause a significant service disruption (so if we have N OC-3s, we can't sell Nx155mbps of bandwidth). A big portion of the costs are transport links (dedicated point-to-point circuits between cities), but the IP transit portion is still about $20-30/mbps/month IIRC.

Gas/petrol usually costs about 15 cents per mile.

Not for a comparable vehicle. I just paid $2.799/gallon for gas; at that price, 15 cents per mile means you are only getting 18.7 miles per gallon. The Volt is supposed to get double that on its gas engine, so call it 7.5 cents per mile.

This (and other electric cars presumably) will cost just under 4 cents per mile (based on current electricity costs)

The site you referenced doesn't say the actual power requirements, but if you charged on a typical household 120V outlet, you will typically be limited to about 1500 watts, so you'd use 15kWh to drive between 25 and 50 miles. I have relatively low power rates where I live at 9.012 cents per kWh, which would mean the cost per mile would be between 2.7 and 5.4 cents per mile (3.38 cents/mile at the target 40 mile range). So, you're now down to about half the cost per mile.

Gas prices will probably go up, but so will electricity prices. If plug-in electric vehicles become widespread, the "last-mile" part of the power grid is going to have similar problems to the "last-mile" part of residential Internet. It was built with certain assumptions (that have held true for decades in the case of power) that could change rapidly. A plug-in car could come close to doubling the power usage of a typical home, and the distribution system can't handle double the load (even if the generating stations can).

Not sure what you mean by "File-based dependencies like in RPM may be slightly deficient here". RPM only depends on specific files if you need them; e.g. if you have package A with a config file /etc/a.conf that is also required by package B, package B will depend on the file /etc/a.conf (commonly found with scripts and dependencies on /bin/sh, /usr/bin/perl, etc.). If package B just needs package A to work, it'll depend on "A".

Round trip (from your phone to a non-sat phone and back) takes 4 22,500+ mile trips: your phone to a sat, sat to ground station (to non-sat phone), (non-sat phone to) ground station to sat, sat to your phone. That's 90,000 miles, or about .48 seconds at the speed of light. Add in the regular non-sat phone delays (especially for cell phones), and you are at or above half a second.

Math is hard. Use a calculator next time.

HughesNet (the former DirecWay) uses satellite(s) in a geostationary orbit, over 22,000 miles above the equator. That results in a significant delay (round trip of almost half a second), which makes regular voice conversations impractical. The satellite phone systems like Iridium use a whole constellation of satellites in low-Earth orbit to avoid the big delay, but running a large number of satellites and ground stations costs a whole lot more (so the service costs a whole lot more).

The standard QoS bits are basically useless across any administrative boundary (such as the connection between you and your ISP, or your ISP and their upstreams/peers). Otherwise, you very quickly get people realizing they can just set all of their traffic to the "high priority" class. The only way an ISP could reasonably do QoS is by port or packet inspection.

It wasn't just Oracle. The Linux kernel would deadlock if the system was under load when the leap second happened. I only had one server hang, but a customer with a rack of busy servers had about half of them freeze. Lots of "fun" on New Year's Eve. Even more annoying was that the problem wasn't in handling the leap second, it was in printing a message that the leap second had been handled.

No, but the periodic full backup has to complete in a reasonable amount of time.

Our office is in a separate location, so off-site storage is carrying the tapes to the office. The time spent swapping tapes is a non-issue, as somebody needs to go to the NOC every day anyway for other stuff.

Meaningless question. Tape is only used for backups, and lots of data is not backed up (rightly or wrongly).

Who cares?

Most of the world is not Google, so irrelevant.

So to get 300Mbps would be $1200/month, just to handle off-site backups (since I don't really need that kind of bandwidth point-to-point for anything else). I could buy a new tape library and new tapes 2-3 times a year for that.

We're talking about backups; latency is not a big problem there. You stream data out to tape sequentially, and with modern tape formats, seeking to a desired block is quick. Restoring a file from our tape library only takes a few minutes (if the tape is currently in the library). If you need files from backups often enough that that latency is a problem, you have a bigger problem (but you could look at disk-to-disk-to-tape).