From what I've read (including BengalsUF's comments, which seem to be the only authoritative source for the case), it sounds to me like Mr. Childs was taking extreme security precautions.

It's been mentioned several times that the network devices were configured to not store their configs in NVRAM or to wipe the configs if password recovery was used. I personally think that is a bit much, but I could see people I've worked with over the years arguing for this in order to prevent the configs from being retrieved by an attacker (and then analyzed and used to attack the rest of the network).

So once you've gone that far, you have to have a way to legitimately store and reload the configs when the inevitable failure occurs or an update is required. But if you just put the configs in CVS somewhere, then that becomes the security hole people can attack. So encrypting them and requiring multi-factor authentication to access makes a certain amount of sense.

As I said, I think it's going a bit far, but if you really really really want to ensure security of a critical piece of infrastructure, that's one way to do it. The way Mr. Childs went about it didn't scale beyond him (another common failing in small environments where the team size = 1), and maybe was too limiting to really be practical, but I don't necessarily think it equates to a matter of ensuring job security as has been claimed.

Video games aren't like other forms of entertainment. Paul McCartney's old albums are regularly updated for new mediums (tapes, CDs, etc.) and are fundamentally comparable to new albums made today minus some audible differences in production.

A video game made in 1988 may still be great, but there are much higher barriers to it finding a modern audience:

1. It may be difficult to run on modern systems (or at least require a level of knowledge -- e.g. what is ScummVM -- that makes it harder to access than a modern game for the uninitiated).

2. It may be so dated from a graphics, interface, or gameplay mechanics perspective that someone coming to it fresh will not enjoy it.

3. It may not even be possible to legally acquire; unlike movies and music, where old releases are often available alongside new releases, old games disappear from shelves.

Sure, there are exceptions. GOG.com, ScummVM, buying something on Ebay. But you have to already have an interest in exploring or revisiting older games.

Game designers are celebrities within their field, not within society. Paul McCartney is a celebrity because of his musical contributions, but he also is immediately recognizable to millions of people who may have never heard his music. Richard Garriott is a celebrity only to people who know his work -- which, as mentioned, has not continued to be relevant in recent gaming history.

And that in a nutshell is why someone as important to early gaming history as Richard Garriott was may not roll off the tip of someone's tongue today.

He also hasn't made a noteable game since 1997 (or 1999 if you consider Ultima IX noteable), at best 11 years ago. While I instantly know who Lord British is, he is far from a household name to someone who was 3 when Ultima Online launched.

That's right, it's happened to you: you got old.

I was going to say "Surprise! It's always orange" but then I actually checked before posting and was shocked to see that it's yellow.

It's also intensely stupid.

I think it's conceivable that the world's population could have its quality of life raised across the board so that there are not people living in abject poverty who are literally starving to death, although it would be quite difficult and especially problematic to do so without causing the abject poor and working poor to effectively combine (meaning a reduction in quality of life for those presently at the low end of the scale but above the very bottom).

However, raising the quality of life so that literally no one has anything to lose (as you put it) doesn't seem practical. If everyone is a millionaire, then that will be the new poverty as the value of things will adjust accordingly based on their scarcity as already happens.

Put another way, someone will always have more than you in one way or another. More possessions, more political power, more social influence. If you feel that this is unbearable (as in someone who is legally permitted to obtain an abortion) or that you have no power to change this within the system (as with a tyrant suppressing political freedom) then people of a particular disposition will gravitate towards terrorism as a means to achieve their goals. Not to mention those who possess a strong enough dislike for another group of people based on religion, ethnicity, or other factors that their mere existence is offensive to you, which is even more difficult to solve as there is no middle ground.

Your records belong to you. You can request them (and depending on the hospital / doctor's office, they may claim you can only receive copies or that they will only send them directly to your new healthcare provider) at any time and take them with you.

My ISP links to http://www.smallnetbuilder.com/component/option,com_chart/Itemid,189/ which has throughput numbers for common home routers.

The long and short of it is that a lot of these devices have pretty poor performance, and can get away with it because they're used on 1.5mbps lines. However, there are some out there that are decent.

Of course, there's the build-it-yourself approach with m0n0wall or pfSense or something else. With a spare PC laying around you'll likely get reasonable performance, although electricity usage is quite a bit higher than an appliance.

You may be disappointed in the results: http://en.wikipedia.org/wiki/List_of_United_States_extradition_treaties

I guess The Spanish Prisoner lied to us.

I agree that all of those things could be of value, but I still contend that even if someone was willing, the average employee doesn't have access to that kind of data.

It's not so much that I don't believe ANYONE would steal from their former employers but that EVERYONE would do so as the article is practically saying (50% is absurdly high).

Yep, that's me. I even put it on my resume once as a joke (I had one empty line to fill).

I'm sure that some people do try to profit from illicitly obtained information from their past employers; I've heard a few stories here and there about people getting busted. But there is simply no way that 50% of everyone in the workforce is doing this for a few simple reasons:

1. Risk - I think everyone is aware that the damage to your career and professional reputation would be catastrophic if you were caught, not to mention the legal ramifications.

2. Ethics - Yes, people do have them. Maybe not everyone is the pinnacle of ethical behavior, but that doesn't mean every other person you see at the office is just waiting to mug you and steal your wallet in the parking lot.

3. Nothing to steal - The majority of employees just don't have access to proprietary information that is actually of value outside the company. Sure, I could tell a future employer about my company's HR policies or give them an org chart. That might be very slightly useful, but certainly isn't going to get me hired or land me millions. I could also give them all of the company's internally developed code, but it would be of little use without all of the institutional knowledge, expertise and essentially the entire original company to go along with it.

4. Employers are liable as well - Take the case of the people who tried to sell some of Coke's trade secrets to Pepsi. They were refused, and Pepsi informed the police. They know that they would be liable for the illegal behavior as well, and want no part of it. Now not every employer operates above board, but it's a risky game to try to sell information to someone who may not even want to buy it.

So in summary: bullshit.

I was under the impression that the bridge had to go through Yerba Buena not to serve the island population (who are only there because the bridge makes it convenient I imagine), but because the bay is too deep and without a firm bedrock to otherwise locate the middle section of the bridge securely.

Possibly that was only a concern when it was originally built, but regardless, you would essentially need to route it in the same path as otherwise you'd need a new landing point on the Oakland side and there's Alameda in the way.

There are four bridges running east/west over the bay, it just happens that there is only one in this particular (useful) location. Also, given that the Bay Bridge has to connect to Yerba Buena island, there's not really a lot of room for another one right next to it. So there is redundancy, but you have to deal with the physical realities of the area.

That's a completely valid option, but I'm leery of MySQL replication due to prior experiences. When it works it's fine, it just has a few issues that I've had crop up. Keep in mind, if your official backup copy is coming from the slave, you have to make absolutely sure that the data is really in sync and up-to-date.

That means using tools like mk-table-checksum and mk-heartbeat from Maatkit. If you're not using them (or comparable things), then your data could be silently corrupted or out of date which would invalidate your backup. Note that seconds_behind_master from MySQL is kind of a joke for verifying that your slave is up-to-date.

My other beef with MySQL slaves is that they, by design, can only write in a single thread whereas the master can use all of its cores to do this. So even with two identical systems, the master may be fine at load and the slave may totally choke. People also have a habit of purchasing underpowered slaves, because "they don't do anything", forgetting that they still do 100% of the write load from the master, even if nothing else uses the host. Buying larger hardware just to keep up with the master for a once-an-hour backup feels dirty to me, but it is what it is.

Yes, but as I mentioned, this is not necessary specifically only with InnoDB. Because it writes to disk atomically, you will get a valid point-in-time copy of the database simply by taking a filesystem snapshot; no read lock required, which means the application can continue operating from the user's perspective.

The problem with a read lock is that, if done on a master DB, you will impact the production service that uses the database. Depending on the workload, this could take a minute or even longer, which is usually not acceptable.

However, there's another problem: MySQL performance degrades significantly on LVM when a snapshot is active. So even though the database continues operating as usual, performance will not be the same (and perhaps not at all adequate) during the backup period -- especially considering that you're doing extra disk I/O to get the data copied off.

So, I prefer to use xtrabackup these days. This presumes that you have no MyISAM tables though; otherwise you're back to mysqldump or taking a read lock or some other less desirable method.

One other point: if you backup with filesystem snapshots (of the raw DB files), then you have to restore the entire database during a restore. Maybe this is fine and maybe it's a huge headache.

There are a million ways to backup MySQL (and other DB's), and it really comes down to what kind of downtime you can tolerate during your backup. I generally want to back up very frequently, without impacting the service, and avoiding replication (and all of the headaches involved in that -- see the existence of tools like mk-table-sync for an idea of what can go wrong) if possible. If you don't have those requirements, then mysqldump or mylvmbackup or something else are totally valid options.