throwawayish

Performance is a non-predictable good on macroscopic (application) scales.

Evidently there's at least one group of developers who mainly derive their decisions from irrelevant and often incorrectly conducted micro-benchmarks.

Meanwhile, most web applications are content with 1/10th of the computing resources that are deployed for them, regardless of language or framework.

My experience is that people that scream the loudest about "performance" are often also people that make micro-benchmarks and derive ridiculous claims from them, and also seem to often be the people that otherwise don't know much about "performance", or be in need of it.

For the by far largest share of web applications, easily everything to the 99th percentile, performance, in the "sense" of this benchmark, is wholly irrelevant.

ITT: Web developers being surprised by the meaninglessness of microbenchmarks.

Both VSCode and Atom are memory intensive as well.

That being said I've used PyCharm on a system with 2 GB memory before and that does work okay, you just need to make sure that no other memory-hungry apps run at the same time (browser, email, multimedia) and that the system itself doesn't use too much memory.

A 3.5" drive fits in most backpacks, and it can be powered of USB 3.

There isn't really a compelling reason to run significant storage off 2.5" HDDs anymore -- before SSDs 10k or 15k 2.5" HDDs made sense (access time), but nowadays...

More importantly: shingled recording slows things down as well.

Tasks = user threads, user processes, kernel threads

If you have their display enabled htop will divide them down as well.

The computer being unable to render it's UI fast enough has exactly what to do with the display...?

Actually does not sound like a bad idea.

> is it destruction of evidence?

I'd say that depends on how much you pissed persecuting entities off.

It does help a lot in many instances. I've been using 0MQ for this purpose, which facilitates the style nicely. However, things like setup/teardown and configuration are still not at all easy to get right -- and not all problems are apt for this style of concurrency, and it doesn't really change much about optimization; getting the most out of the platform is difficult and takes time, CSP doesn't really make a big difference there.

> I wouldn't be surprised if a modern USB-stick's processor had more computing power than 90s-era laptops.

Data transfers are handled in hardware; the MCU in these is not really powerful. Many are just 8051s. USB 3.0 controllers are a bit beefier, though.

Fun-fact: the digital rotary knobs on most equipment (given name: rotary encoder) are pretty much built like this - a disc with conductive patterning read by brushes (well, bent contacts). Only the far more expensive rotary encoders are optical with an etched or printed glass disc, like typically found in industrial incremental encoders. These optical encoders typically cost 10-15 EUR a pop.

Btw. using keyboard controllers to poll many switches isn't actually that unusual, but definitely a nice hack.

Various CPUs have hardware SHA-1/2 support, eg. everything with ARM NEON = many smartphones and ARM chips, even some ARM boards. Most Sun/Oracle SPARC machines have crypto engines that do this, and many other algorithms; the same goes for POWER.

I'm not quite sure why no mainstream x86 extensions have extra stuff for this (VIA PadLock does SHA), but I can take a guess: ARX is already reasonably efficient in software (more so with newer designs, eg. BLAKE2 + AVX2) - unlike AES. And unlike AES there aren't really many problems with side channels, especially when we think about GCM.

Of course it's a bit of an apples to oranges comparison.

An interesting question about CRCs is whether you can implement them efficiently. CRC32 is possible with some help from the CPU (CLMUL as mentioned, or complete instructions for specific polynomials, like crc32c); eg. on Haswell you get to 14-16 GB/s with a CLMUL approach on CRC32. That's obviously much faster than the hashes I mentioned. With the zlib implementation, on the other hand, you only get about one GB/s and there it's really close to B2b already.

Table-based approaches (classic zlib implementation, or slice-by-n, which needs n-times as many tables) would not work well with longer polynomials; the tables would outgrow L1/L2 cache sizes rather quickly. I'd have to think a bit about the tableless CLMUL approach.

> to the crisp 7pt pale-gray-on-white designers usually label "joy to read" or "beautiful".

Perhaps because they are actually neither and many designers are not well-versed in typography. Making text beautiful (but not necessarily readable) is design; making text readable (but not necessarily beautiful) is typography. They of course, overlap, and good typography usually looks good as well.

Reaaally not that simple.

- Structured data instead of always somewhat wonky text formats

- Request-reply -- Acknowledge stuff. Especially when it's security relevant

- For security relevant stuff, don't just silently fail or fall back to some idiot default. Eg. say a command message for setting a password doesn't contain the password field -- then fail the request, don't assume an empty password.

(Ie. be liberal about what you accept but not too liberal)

> Mosh /s

Is also a unit of measurement - how many times per second the mosh session would've been broken if it were SSH

/s

Especially true for backups. Make sure those aren't write-only!

> The system had been attempting to warn the admins as best it could of the impending doom for the better part of a year, and no one noticed.

This is the area were inverted Unix philosophy applies: Give me good news as well. A weekly mail, that backups (or the filer or RAID or whatever) works A-OK. If the mail stops coming, something broke.

Also - same shipping way. If I buy four disks from the same shop, then those four disks came in the same delivery to the shop (so they were all dropped at the same time), are handled by the same picker, thrown into the same parcel and dropped a couple times the same way.

I develop backup software among other things and I can tell you, that a CRC is neat but I've gotten many many reports where a CRC did not catch data corruption (but SHA-2 did). Much fewer reports indicated that the CRC caught it first.

My conclusion: A CRC32 over a couple megs of data is only good enough to likely catch "gross" corruption, like truncating the data, not finer corruption like memory and disks tend to do it, especially when we're talking about bit rot.

Also, unless you're using an optimized implementation -- and zlib is not optimized -- using eg. PCLMUL or at least a slice-by-4/8 variant it's a waste of time, because eg. BLAKE2b isn't much slower than zlib CRC, but will catch All The Corruption!1 [1] (Also, Python 3.6 added the full might of BLAKE2 to the stdlib, although it's the reference implementation and not some fancy SSE4/AVX(2) impl.)

[1] A technical note: There is a tradeoff between checksum length and data length; with a good checksum increasing it's length eventually increases the error rate over the same medium (aka false positives [the checksum is corrupted instead of the data]). However, it's usually more important these days to be certain about correctness and not to minimize total indicated BER over a certain channel.

But the system has five-nines security!

Notedly it runs on a very small configuration of an IBM mainframe (z10 BC - 8 GB of RAM), costing less than 100k USD.

I don't think anything is missing, but you don't get it all in one package.

click ( http://click.pocoo.org/6/ ) has a lot of this stuff in one package, but not everything, eg. composable command lines, progress bars, spinners, prompts, bash completion, colors, paging, launching common applications ($EDITOR) 'n stuff like that.

pyinvoke has a somewhat different focus, but also quite some stuff similar to this.

clint ( https://github.com/kennethreitz/clint ) is another bag of tools, with things like awesome tables, colors, progress bars, ...

I don't think it's ambiguous. In any case, it cannot be read as "people are locked into their hotel rooms".

(Which doesn't work with any electronic hotel door lock I've seen so far anyway)