This is the first time that I actually like a design trend in the web. Thank god we got rid of those barely readable thin grey fonts on white backgrounds.

Last time I tried libinput, I couldn't disable acceleration on touchpads. "Flat" acceleration profile still had acceleration.

From my experience, Intel is no better.

I have a 4 year old laptop with an Intel CPU that has the same problem, it was never fixed by Intel. [see EDIT]

For the first 3 years of use I just accepted the fact that my laptop would randomly freeze and I would have to reboot it.

One day, I got sick of it and started digging into forums until I found a way to avoid the specific c-state (by modifying kernel boot parameters) that caused the issue.

EDIT: Apparently, it's getting fixed now. Just 5 years late, issue was reported in 2015 https://bugzilla.kernel.org/show_bug.cgi?id=109051

Think of how much of a difference that makes in low and middle income countries. Maybe in the first world people have always been able to buy books for cheap (relative to their income), but the amount of reading opportunities people in low and middle income countries have with the Internet is, in my opinion, a new and beatiful thing.

Capitalism, as defined by communists is about the "private ownership of the means of production". The term has now been widely adopted, even by its defenders, although we don't care specifically about the means of production, we defend property whenever it enhances the freedom of the human individual (an abstract individual, not any specific person).

Intellectual "property" doesn't enhance freedom in any way. Most libertarians and philosophical defenders of capitalism agree with me on this (except Ayn Rand fans)

Also, if they do this, it's highly probable that they do other user-hostile things. AFAIK, you can't upload photos from the desktop web version.

> the compression algorithm needs knowledge of the video stream, which would be impossible if it's compressed.

That makes perfect sense and I guess my theory of secure encryption + post-re-compression fails because of this. But what if we didn't need perfectly secure encryption, but just per-block encryption. So the server knows that you've sent 60 frames, but doesn't know what is in those frames.

What if the codec was made in such a way that the server knew that certain blocks in the stream could be discarded to reduce size while the stream without those blocks still makes sense to the recipient.

For example: the stream is composed of 64 byte blocks, but the codec says that every 2 blocks there's a discardable block that adds image quality but is not essential. So, with this knowledge, the server discards every 2 blocks when sending that data to people with low bandwidth and sends the original stream with all its blocks to those with high bandwidth.

It's an extremely naive scheme, but maybe this principle could be applied to more complicated codecs, so the server only needs to know metadata about the stream (where each block is and whether it's essential), but not the content of the block itself (framebuffer and audio sample values).

I'm sorry if this idea is too dumb (and my English skills are not the best).

1. Sender sends an encrypted stream at K bps.

2. Server takes the encrypted stream and compresses it, without decrypting anything. It then sends encrypted+compressed stream at J bps (J3. The end recipient decrypts the compressed stream using a key provided by the original sender, not the server.

This with reasonably secure encryption and reasonably size-efficient codecs, obviously. So the step 2 would add compression additional to the compression of the original codec.

Is this mathematically possible?