>Chip scale atomic clocks have been commercially available for 20 years
Not quite. I remember looking around when NIST first announced that research, but it took several more years until they were commercially available. The first one you could actually buy was the SA.45s in 2011. source

>The way data is exposed is almost ALWAYS via a compromised "client" machine talking to a database server
Are there published stats on that or is that a hunch? I don't actually know.
>(other than unencrypted database dumps I supposed).
Yes, that's one of the reasons of having encrypted data at rest. Another is hardware theft, another is being able to store data with a host you don't completely trust.
  All the cloud data and backup providers aren't just going to stop encrypting data at rest just because lsllll says compromises "almost ALWAYS" happen at the client side. Even if that were true, encrypting data at rest is still a good thing for the times when it isn't true.

Here!

Were you watching? It's easy to say now after the carnage is over.
S&P did move, about 30% top to bottom in a few weeks, with the highest single-day volatility index except for a day in 2008. Crude light futures tanked went below 0 for the last trading day of that contract around that time.

That's a pretty fucking stupid casus belli to get rid of community contributions.

Most of us have heard the common saying: "programmer time is expensive, hardware is cheap" -- the justification to buy better servers and to buy the developers high-end workstations because developers can get more work done in less time.
Another phrase IMO ought to become commonly understood by businesses: user time is more important than developer time.
Sure programmers are expensive, but users seldom have the fastest mobile devices or workstations and they won't get the same experience as developers.
I don't use messenger but am pleased to see that Facebook has saved even a half a second a day for a billion active users.

Progressives bellyached and clamoured for free speech for decades. Now progressives deride it as "freeze peach" and are pretty happy to take on the libertarian position of "don't like it? build your own platform then :^)"
If you count yourself among them, then you are a worm. An eel. An absolute shit-heel.

This isn't the first time I've heard of reversible computing and its purported benefits, and over the years every time I looked it up I haven't seen significant advancements or implementations. This article is no exception. And I'm still not convinced there exists any design of a reversible-logic processor is practical or useful for general purpose computing, assuming that the physical hardware problems have been solved.

I would be quite happy to see a software simulation of an 8 bit processor with a simple instruction set and a small amount of RAM, all implemented in simulated reversible-logic gates. Does anyone know if such a simulation exists? Or is the answer "well, it's complicated" which means probably not?

>According TFA, they actually do an explicit sync to disk at the end of the writes. So it's not purely writing into cache.

The code in the paper says they flush before closing the file. This is not the same as a sync. They don't even flush (or sync) after each write.

>This is the dumbest research I've seen in 2015. There was actually no computation involved -- they just wanted to write a long string to disk. They concluded that adding the superfluous step of concatenating strings in memory, then writing to disk, was slower. Well duh! That's not what memory is for!

Agreed with you on the uselessness of their research, but that is most definitely one important and common use of memory: buffer caches used by the operating system.

Effectively, they unintentionally tested the speed of the OS to concatenate strings vs Java or Python. The researchers are wrong right out of the gate: they say "Heavy Disk Usage" in their research headline, but at no point did they actually test disk performance, everything they did is being handled by the OS buffer cache.

All the researchers have shown is that string concatenation operations in Java and Python are atrociously slow. The java example used the naive form a=a+b; to concatenate strings, which is one of the slowest ways to do it in Java if you are doing repeated concatenations to a string.

If, in their tests, they had also done a string concatenation in C by allocating a buffer and appending to it using a pointer (not strcat) the speed difference doing that vs. 1 million write calls would have been negligible.

Also, if they sync'd after each of a million 1-byte writes to test how slow "Heavy Disk Usage" is compared to a single write of a million bytes, they wouldn't have bothered finishing this paper at all because it's so damn obvious that memory is faster.

>The question is, what have we learned as an industry since 1982?

Quite a bit.
I have three books on electromagnetic compatibility. The most recent, Electromagnetic Compatibility Engineering (2009), is comprehensive and thick enough to stun an ox.

What next? You use 15 or 20 character passwords, or a passphrase of several words.

But for the server side, use key strengthening with something like bcrypt or scrypt.
If it takes 1 second on very fast hardware to hash a single password, then your attacker has to also spend a lot of time on each hash attempt.
scrypt was also designed with custom hardware attacks in mind (it uses lots of memory) so it is still slow and expensive even if the attacker has key derivation logic in an asic or fpga.

If it takes a tenth of a second for an attacker to derive a key (or hash) from a password then a 10 character password is still incredibly strong.
If the passwords have salt (as they should) even a plain english dictionary attack on a 2M password file will take years to finish.

As faster hardware becomes available, you adapt by changing the key derivation parameters.

You are hilarious.