You're assuming one slot, but they actually sell multiple slot monstrosities that are aggregated together as a single drive. Here's a similar one to what I tested benchmarked at 5.8GB/s on reads.

That a startup succeeds is quite rare. Just considering those cases though, I don't think ones where the employees also get screwed are rare at all. The groundwork for that is usually in place from day 1, with how shares in the company are split into classes.

For me it's been 100%: all three of the successful startups I've been involved with, all purchased by another company, did that transaction in a way that valued the common stock in employee options I owned at nothing. All the books were cooked until the company founders and, more importantly, the funding investors were paid all of the proceeds. And just to rub some extra salt in the wound there, the second also removed my name from the patent they were granted near the end of the process, to grease concerns that I'd expect more from the sale than nothing and could cause trouble with its licensing. (I signed those rights away in my employee contract, and all I really wanted was the little patent plaque)

The third laid me off, forced me to exercise my options to keep them, then valued the common stock at zero during the sale. That one's bonus fuck used some going out of business loopholes to cancel my COBRA policy with zero advance notice the week after the sale, as if they'd gone bankrupt and couldn't afford to administer the policy anymore. The company was sold for millions to Cisco; the engineers who built its technology lost their health insurance.

I've come to see these anecdotes as a pattern by design. Startups are not structured to make the employees happy if the company succeeds. They're setup so the majority share holder(s) get what they want. And there's a lot of rich assholes who will screw over anyone they can in that chain.

LinkedIn used to have InMaps, which drew graphs of how all your networks were connected. It used some graph theory to cluster the people who knew each other together.

At a conference I got a printout of that drawing on large format paper. It not only clustered every school and social scene I've participated in, it even figured out who introduced me to the new ones when that happened. They stuck out as the middle point between the clusters.

Right now Facebook keeps guessing where I work, and it's cycling through each company I have a number of friends employed at. it's impossible for Facebook to figure it out, but the guesses are very good. It's still not as scary as when I look at a picture and it guesses the identity of everyone who isn't tagged in the picture.

Handling power off issues is a different problem. What the GP was referring to is how drives will fail spectacularly in the face of anything seen as corruption. You can see some examples in some longevity failure tests.

The problem in those cases was wearout, but the way that happens is scary. Let's say there's a bug in the firmware that causes a write to fail for no good reason. It's quite likely that the drive will kick into a mode where it doesn't trust itself anymore. And the way that will play out on most SSDs, the drive will shut itself down at the firmware level, so it isn't even picked up by the BIOS on boot anymore. What people would expect is getting read-only behavior there; instead they will find everything gone. And unlike most catastrophic spinning drive failures, you could easily hit the same bug that wipes out your data on both halves of a RAID-1 pair at the same time.

Those improvements are not necessary to reach the full speed of this drive, at 440K IOPS. In my own tests I've even seen a FusionIO drive hit 8GB/s under the old RHEL6 2.6.32 kernel. This new drive is at an amazing price/performance spot, but it's not exploring the upper limits of where the Linux kernel is shooting at.

A few of my Mitsui Gold and Kodak Gold (similar formulation) burns from 1995 and 1996 went bad in the last few years. Expensive media from back then (when it all was expensive), written to at low speed, did seem to last better than the mass-produced media of later years. I also have two cheap Ritek disks burned closer to 2006 that lasted less than 5 years.

Don't be silly, Apple doesn't have piles of cash in Cupertino. They move the money to other countries where they can avoid US taxation.

Just send him to Libertarian Island with Peter Thiel, and then they can all be killed by pirates once they're outside of US jurisdiction.

Union representation.

The Debian package for libudev1 is built from the systemd source code. Says it right on the page: "Download Source Package systemd".

Good plan. Then when those guys all get together to go out drinking again on Comcast's dollar, they will have a funny story to talk about.

Comcast has over 100 lobbyists whose careers revolve around preventing that. They will scale up that spending as needed. And the FCC is practically a case study in how to execute regulatory capture.

There's an additional service fee if you want an invisible handjob.

And have a trivial exploit as a result too. It's a good thing that people who write bad Python and Java code are using those languages.

It's all operating system cached writes, they're not even getting to the disk's write cache.

Python's file flush() function does not flush data to disk. You have to call os.fsync(f.fileno()) for that.

Same problem with the Java code. flush doesn't make sure data is on disk. You have to use sync or force or something.

This is an excellent way to introduce the smart scientist/moron coder archetype to people though, so it's not completely useless.