OK, this isn't the Velicovsky thesis, but it's reminiscent of it.

The lack of seatbelts makes sense. If you're on a spaceship that can accelerate quickly enough to turn everyone into a fine paste and relies on inertial dampeners (adjustments of the artificial gravity) to prevent this, then there aren't many situations where you'll need a seatbelt: either the inertial dampeners are preventing you from needing them, or you're dead. The problem is that the drama needed the ship to seem to shake. It's the same issue as feeling the ship warm up as you get close to a star: it makes for good drama, but the difference between 'humans are comfortable' and 'humans are on fire' is tiny compared to the difference between 'humans are comfortable' and 'nuclear fusion is happening' - it's far more likely that the shields would work fine and no one would be discomforted right up until the point where much of the ship vaporised.

I was quite surprised by the numbers they had for the old model. On my 2014 MBP, I recently did some tests doing sha calculations of VM images. These were multithreaded and not CPU-bound, but they ended up getting almost 2GB/s reads from the SSD. The benchmark is interleaving reads and writes, so that may account for it, but if you're just loading game data from disk then the old model can fill the whole of physical RAM in 8 seconds, so I doubt that's the bottleneck.

If people are actually being killed, then as soon as you get near the house you're likely to hear screams / gunshots. If they're just being threatened, then you have time to plan something that has a good chance of having the victims survive. Well-trained police forces don't rush in guns blazing.

Step one, drive past the house - no sirens or lights, just see if there's anything odd. Step two, knock on a couple of the neighbours' doors - say that you've received a non-specific report of gunfire in the area, ask if they heard anything. Step three, from somewhere inconspicuous see if you can see in through the windows with binoculars. Step four, visit the nearest take-away and have someone in plain clothes take the food to the house pretending that they misread the number, look for signs of distress from the person answering the door. Step five, surround the house with armed officers at all exits and have someone in uniform knock on the front door and ask the person who answers to step outside - if they're refusing and showing signs of distress, then go in.

Or they could just forget all of their police training and pretend that their soldiers in enemy territory.

The workplace is special because it's somewhere where your freedom of association is limited. If you're being racist in a public place, I can leave or use my freedom of speech to tell you to shut up. If you're being racist in my house, I can ask you to leave (and call the police if you don't). If you're being racist in work, then my ability to do anything about it is limited by the management. If you are the management, then there's nothing that I can do about it except quit, and (depending on the state of the economy) that may hurt me more than you.

The problem for feminists today is that their parents (or grandparents) won all of the easy battles. Now the only ones left are difficult and nuanced. Addressing them is hard - it's much easier to make up an easy target to attack than deal with real issues.

They don't admit to anything, but the fact that they're willing to pay to make the lawsuit go away counts for something. Precedent doesn't usually apply in a small claims court anyway (and magistrates tend to get a bit cranky with anyone trying to be a lawyer in one).

For most use cases I've found where MySQL is more appropriate than PostgreSQL, SQLite is better than either. For things where you actually want a real RDBMS, PostgreSQL usually wins.

Because needs grow. The entire point of the free version is to encourage people to use it for everything and then discover that their data has grown to over 10GB and they can either pay MS for the full version or spend a lot more migrating all of their data and software to something else. If you start out on PostgreSQL, then you don't have that issue.

When a class action suit is settled, if you are a member of the class then you should receive a letter asking if you want to opt in to the class. If not, then you don't get the money and are free to take it to court yourself. Opting out then turning up in a small claims court with a class action result and evidence of the value of your losses should get you a few hundred dollars fairly easily. If enough people do this, then it will discourage companies from offering too low settlements for class action suits. The cost for them to send someone to defend is sufficiently high that it's probably not worth it and small claims courts have a habit of ruling against people who don't turn up...

Exactly. There's a reason why 'no commercial use' licenses are generally best avoided: defining commercial use is hard. The problem for the FAA is that, traditionally, it's pretty easy with an aeroplane: if someone is paying you to fly the plane, it's commercial, otherwise it isn't. The distinction makes sense because you want tighter regulation on pilots who are going to fly with passengers, or for those passengers to definitely know that they're flying with a hobbyist at their own risk. For drones, it makes a lot less sense.

Well, fuck you Slashcode! Apparently I was using too many junk characters by having the temerity to post code snippets. Posting lots of mathematics also triggers it. Remember when this place used to be for nerds? Rather than try to work around the filter, I have placed the contents of my post here: http://pastebin.com/HtQXTnX0

I don't think I understand what you think you're trying to do. You can't make a cache flush a line that you're modifying with an atomic operation to RAM, because atomic ops require the value to be in cache. Given an n-way set associative cache, however, you can typically force cache flushes (without requiring special cache flush instructions) by writing N+1 values at cache-line offsets (e.g. at address X, X+64, X+128,...) repeatedly. This probably wouldn't trigger the rowhammer issues though, because it's up to the CPU which row it evicts each time and you'd end up repeatedly stalling on loads without bashing a single DRAM line. You might be able to do something similar with the nontemporal store instructions that Intel added in recent generations of processor...

I suspect that we could persuade those caches to flush to RAM, simply by exhausting the number of possible lines for that address - if the cache is set-associative. Of course modern processors have multiple levels of cache, so that makes it harder.