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.

That is actually the accepted practice for backing up InnoDB databases with MySQL. Of course, you take a filesystem snapshot to get a point-in-time in-use copy of the database files; backing up the real filesystem wouldn't work due to the time shift of the data while you're backing up.

You do have to recover the files upon restoration (I would usually run the recover after the backup finished, since time is of the essence when you need to do a restore), but by not having to take a read lock or halt MySQL, you avoid a service interruption or having to replicate out your data just to backup (which could be problematic in itself, what if the slave server is not in sync?).

Of course, this works because of the way that storage engine functions on disk. You can't do this with MyISAM tables or you'll be in a world of hurt. There are also online backup tools readily available, which are the superior solution now in my opinion.