If clay figures are the price to pay for clean, spaced user interfaces and readable text, then bring it on.
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.
As a touchpad-ignorant person (I have not used Macbook touchpad, so I don't know what I'm missing) Linux touchpad support had always seemed fine to me until distros started using libinput by default.
Last time I tried libinput, I couldn't disable acceleration on touchpads. "Flat" acceleration profile still had acceleration.
> Turns out it was the CPU and how crappy AMD handle C-states that save energy
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.
On the other hand, those who really want to read have a vast supply of amazing content online in both fiction and non-fiction. Those who have time and are willing to pirate books basically have the keys to the kingdom, they can learn whatever the hell they want with just a computer and an Internet connection.
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.
I would like to use Instagram because all my friends are on it, but I have a low bullshit tolerance and stuff like this reminds me why I shouldn't sign up.
> 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).
Tangential (and noob) question: Could there be an encryption+compression scheme where:
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 (J<K) to end recipient.
3. 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.
