sim-

Android does this with zram, and I think this is a big part of the reason why it tends to use more battery once you run low on RAM, since paging in and out requires (de)compression, which uses CPU.

Imagine if Windows just allowed DeleteFile() even if the file was open, like unlink() on almost any other OS...

It'd be nice if they didn't break, but for example, since around OpenSSH 7.7, the order argument parsing changed from last wins to first wins. This change broke all of my aliases where I used to be able to have an alias sr="ssh -l root" and override the user with something such as "sr foo@host".

Last wins is how most other UNIX tools work, since it's the laziest approach (parse from first to last and just overwrite any old value). But I guess somebody tried to be explicit with the order of everything from the configuration file including the command line, and now this happened.

I really wish this would be reverted, but now it's probably been so long that it would break things for people again.

This is so cool!

Has anybody noticed the new Gmail feels way less responsive as well? Composing a new email is affected (just hold down a key with a fast repeat speed and it will not update for long periods), but also the prelight when hovering the mouse over messages an an index is way more chunky than it used to be. "perf top" shows some Chrome functions responsible -- probably something resulting in too much recalculation?

Amusingly, it is way smoother in Firefox. Related, can paste large amounts of data in sheets with Firefox, but Chrome grinds and hits some O(n^2) type of issue after so many rows.

Can you paste or describe your measuring technique?

I used to use text consoles for work and X only for the browser for many years. I switched only to terminals in X when I hacked up a rxvt enough to be very close to the text mode console (including the font and pretty closely matching GPM for cut-paste). It is generally responsive "enough", though for years I keep blabbing on about figuring out some way to check the latency.

rxvt versions newer than 2.7.1 and, more recently, rxvt-unicode seem to have some other issues that make them really slow (particularly non-bitmap font rendering), but rxvt-unicode supports mixing bitmap and other (Terminus) fonts which seems to be a reasonable solution.

On the desktop, prelighting _used_ to be a functional aid: as the mouse cursor hovers between two items, the instantaneous lighting of the next and darkening of the previous provided immediate feedback that a click would reach that widget. Chromium and Chrome decided to fade this in and out (countering the whole usefulness of the feature), and now do some sort of lagged/animated mouse surround, which seems to make even less sense.

While TCP is not ideal for this application by nature of it trying to be a fully reliable stream protocol, one often overlooked advantage of its congestion control is that it allows the stream to play nicely with others. For example, if you develop a datagram-based transport whose data rate results in congestion at some point in the network path, any TCP going through the same point would back off to nearly nothing in an attempt to save the link.

You can be greedy and take the bandwidth anyway at the expense of everything else, but possibly (in some conditions) this may even cause a worse outcome even for your traffic. It's likely better to change your data rate target and drop rarely than to send too much and drop randomly at a higher rate.