wantoncl

I often ask the technician if my tongue is in the way, and they always say it's not, but I'm not sure I believe them. I sometimes have anxiety that if my tongue slips a little bit I'll get injured, and that sure doesn't help.

Physiologically, I would imagine that when the mouth is closed, the tactile pressure on the tongue is constant enough that your brain filters it out. When my mouth is open, the tactile pressure is gone, so there's even less sense of location. Without the muscle extension, it's just a blob of jello with no sensation. Hence why I place the tip at a specific corner.

Basically balloon launches would only benefit small sub-orbital sounding type rockets.

https://en.wikipedia.org/wiki/FROSTBURG

Whatever your feelings about the NSA, it's an extremely cool museum, and free admission (at least when I went). The staff are incredibly knowledgeable, while obviously they can't discuss classified material, you're bound to get some great unpublished tidbits from them.

Not theorists. They researched and published actual conspiracies, based on government documentation.

https://en.wikipedia.org/wiki/H%C3%A1karl

https://www.youtube.com/watch?v=SJ7lOus1FzQ

You are in the minority, and it is absolutely someone else's business. At least it's their job to ensure that you're safe.

It doesn't even have to be for months at a time, just a simple wrong way turn in a national park on their way someplace else:

https://www.otherhand.org/home-page/search-and-rescue/the-hu...

(Previously on HN: https://news.ycombinator.com/item?id=12019567)

While that's a long story (and well worth reading), it illustrates how even the simplest things going wrong could lead to an entire family dying, within walking distance of paved roads, certainly less remote than Alaska. There were multiple SAR teams/missions that put their own lives at risk, even when it wasn't their job, that took responsibility to find out what happened.

Anyone who wants to "go out into the wilderness" has to remember that, it isn't just their own life at stake.

Whenever you have the option, use tab-delimited if it ever has to go into Excel reliably.

It was getting more expensive to keep up year after year, but parts were available and never had any major issues with it.

The Abyss Part 2

Coming Summer 2029

> Why? Credit cards are faster

No. There's no electronic lookup to verify cash is valid. No swipe, no chip with cash.

> safer

Nope. Thanks to Target and Home Depot breaches, plus some other hacks, I've had to replace cards 4 times in the last 18 months (3 in 6 months). Those last 3 all had chips too, so much for being safer or more secure. To say nothing of skimmers or card cloning. Fortunately they don't use RFID in credit cards or else it would be double.

I will note that I was never on the hook for fraudulent charges, so protection is a definite advantage to credit. Amex has also been secure for me throughout my history with them.

> easier and simpler

Open wallet. Hand cash over. Get change, if any. This is the same effort as taking out a card, swiping/inserting it, and putting it back in my wallet. The only advantage to credit is online purchasing, which excludes cash transactions by its very nature.

> and come from with benefits and service

Very true. Except for purchase protection however, these always require a membership fee, and not all services offered are useful. I've seen high-end card services that "book your travel, hotel, everything" for you, but are still subject to blackout dates. So what am I paying $450/year for if you can't overcome that? (Takes me 15-30 minutes online to figure out) Also a lot of travel services are pegged to a single airline or hotel chain, e.g. Chase Sapphire and United Airlines. (that's working out well recently)

>How is cash really better outside of anonymity and quick transactions these days?

You said credit was "faster" and then later said cash is better from "quick" transactions? Typo?

Regarding anonymity, that's crucial. Credit card breaches risk revealing all kinds of other personal information, and can be used for credit history gaming, loan applications, identity theft, etc. There is no convenience in having your credit score wrecked by some hacker just because you bought a greeting card at Target, and then only because their HVAC vendor was lazy/stupid.

Even if that didn't happen, every company is sharing purchase and customer information. Once they link it to Facebook, they can find out what all your friends are buying as well, and then target ads or sell info to spammers. Cash prevents that, at least for now.

They are primarily mental processes that require focus and concentration on specific things. Any distraction, no matter how small, will derail the entire process.

Once interrupted, the person cannot just pick up from that point, they have to start over from the beginning and redo all that work.

I've found this analogy pretty solid, even though it sounds silly. You certainly don't need to explain to anyone about interrupted orgasm, or what it takes to get back on track.

(Of course, for orgasm, that re-work is pretty enjoyable, unless you are a professional who gets paid to produce orgasms for other people who demand them of you. Therefore all coders are whores. ;)

We're a Microsoft shop, .Net application with SQL Server RDBMS on Azure Virtual Machines. We use Availability Groups (AG) for failover/redundancy and read-only copies. AG uses Windows clustering, and the recommended MS configuration for clustered Azure VMs is a storage pool of the attached VHDs, with OS virtual disks on top of that. It looks and acts the same as physical hardware. One thing I didn't fully appreciate is that the Windows cluster still aggregates all the storage across nodes even if they aren't cluster resources. Remember this.

About 8-9 months ago we wanted to migrate our databases to a new VM config without incurring any downtime. Standard method with AG is to add a new node to the cluster, include it in the AG config, and manually synchronize the databases to that node. Once done we fail over to the new nodes and evict the old ones. We did several tests and all went well, so we scheduled the production migration for 9:00 pm that night.

We added the new nodes to prod during the day and made a small change in drive letters (originally R:, S: and T:, new nodes were SSD based so consolidated it all on Z:) Turns out that while AG will replicate with database files on different drive letters, it won't fail over unless the drive layout is identical. While this was technically a mistake it saved my ass.

We had all the drive letters on the new nodes and decided to prep early for the migration. I open our PowerShell script to manage the storage pool and virtual disks. I run Get-VirtualDisk and see all the volumes listed, but each name shows 3 times (we had 3 nodes). I've noticed this before but didn't really grasp the implication, because all the volumes had the same names on each node. I decided to remove the old drive letters from the new node and run Remove-VirtualDisk for each of them (local backup drive first, then transaction log drive, then data file drive). Literally 5 seconds later:

"Hey ___, the application isn't responding. Is there something going on with the database?"

Turns out, there was. Since the volumes were all the same name, and it was a Windows cluster, drives on all nodes were dropped.

Fuck.

As this was a storage pool with striped disks, rebuilding it was going to be tricky at best, and if it could be done at all, would need manual work and a lot of time. And no one had any experience doing that. And this was during peak business hours.

Fuck fuck fuck fuck...

You notice the sequence I dropped drives? All local backups were gone. Our cluster disk redundancy consisted of copying to every node in the cluster. Our Azure cloud backups were 12-24 hours old, and would take minimum 4-6 hours to restore.

Fuck ^ Graham's number. (yes, all fucks were spoken out loud during this episode)

Since MS recommends not keeping the system databases on the C: drive, we had moved them to one of the drives that no longer existed, so SQL Server wouldn't even start on the primary node. I'm actually sweating at this point and thinking I'm going to get fired. In any case we get the word out to our support folks and they notify customers.

Fortunately that new Z: drive with all the database files on it was still intact. After the the fastest round of Googling ever, I ended up having to evict the dead nodes from the cluster, and forced a failover (the option for this is helpfully and deliberately named FORCE_FAILOVER_ALLOW_DATA_LOSS). First time I ever had to do this BTW. (have done many planned failovers though)

Everything came back up, and from what we could tell no actual data was lost, any in-flight transactions were rolled back when the disks went away. In effect we performed our migration in the middle of the day instead of that night, and were down for 23 minutes. (We had planned on 1-2 hours)*

Lessons learned and/or reinforced:

0. You CAN recover from catastrophic data loss. Don't panic. Or, panic in a controlled and practiced fashion.

1. Understand your product's features and implement them properly. Fortunately SQL Server's features are designed to preserve data as best it can, even if you fuck up.

2. You cannot have too much redundancy. We now copy our backup files to independent local storage, and have a disaster recovery site in another data center, log shipped on 15 minute intervals. (Sadly we have yet to test failing over to it)

2a. All our production database changes now require additional backups immediately prior. (You should also verify that they can be restored)

3. On a Windows cluster, ensure every disk volume has a unique name that includes the node in it.

4. Practice disaster recovery. And that means true disaster, unexpected issues. Look at these and other threads for examples, and ACTUALLY DO THEM.

5. Practice all production changes multiple times in a separate environment. WRITE DOWN the procedures and DO NOT DEVIATE FROM THEM when actually changing production.

Thanks for reading this long thing.

* Our customers were actually happy after the migration because the SSD performance was much faster than the original disk setup.

He just left Microsoft's Jim Gray Labs 1-2 years ago and is now at MIT. He also led the teams that developed Hekaton and PolyBase for SQL Server in the past 8-10 years. He's still making plenty of advances.

It's still quite hard to optimize queries especially if there are numerous JOINs involved. For reference, please check Dr. David DeWitt's PASS Keynote slides http://www.slideshare.net/GraySystemsLab/pass-summit-2010-ke... and his additional papers on database systems: http://gsl.azurewebsites.net/People/dewitt.aspx.

I can't find the video of the keynote online, I believe it's only available to PASS Summit attendees, but if you can find someone with access it's a superb talk. And he didn't even address parallelism or distributed processing as optimizations. Microsoft has already added a new cardinality estimator to SQL Server 2014 and it's still not perfect.

"In 2016 we're still manually creating indexes, and databases still use the exact same physical data structures for everything they store, no matter if they're storing 1,000 rows or 1 billion."

As of SQL Server 2014 there are 3 different physical storage methods: row store, columnstore, and in-memory hash table store (formerly called Hekaton). Each type of storage has completely different optimization methods and are best suited for specific types of data and queries. Dr. DeWitt's page has additional detail on those, and you can watch his PASS Summit Keynote on Hekaton on Youtube: https://youtu.be/aW3-0G-SEj0?t=1336

With all this in mind, self-tuning is going to take quite a while to get to something that provides consistent improvement over detailed analysis and testing. And new technology can completely change how one would approach optimization: https://blogs.msdn.microsoft.com/bobsql/2016/11/08/how-it-wo...