Skip Navigation

InitialsDiceBearhttps://github.com/dicebear/dicebearhttps://creativecommons.org/publicdomain/zero/1.0/„Initials” (https://github.com/dicebear/dicebear) by „DiceBear”, licensed under „CC0 1.0” (https://creativecommons.org/publicdomain/zero/1.0/)P
Posts
1
Comments
631
Joined
2 yr. ago

  • Mine was not really long and stretched out over multiple devices. First Ubuntu Server, on my server, then a Kali dual boot on my main PC (which was actually useful), then PopOS. Then Ubuntu/Debian, after some time LFS and finally Arch on my old laptop. Then Arch on my PC too, and my new Laptops, and finally Arch on all devices.

  • Everyone who needs to use Mac or Windows due to work will very likely not have permissions to install anything anyway. And the lost souls using those "Operating Systems" out of free will ... well "some just need to be left behind. The family doesn't need to care for them anymore."

  • They fixed one specific issue afaik, not by actually fixing it but working around it, and they didn't address the real, main issue: The driver being closed source. Until then, there are and will always be issues that aren't present for AMD, because the latter has thousands of experts working, fixing and adapting other programs for it for free, around the clock.

  • When selfhosting stuff, it's just incredibly difficult to properly set this up while maintaining compatibility with http for other stuff. Usually you'll have one reverse proxy (eg. nginx) handling http/https encryption and forwarding to a socket (or in case of docker, one of a dozen open ports on one of a hundred interfaces, fuck you docker), over http. The APIs themselves almost never have direct https support, and even if I wanted to manage them directly, certbot only supports reverse proxies directly. So you need to differentiate between api and non-api in the reverse proxy.