Systems/Journald keeps 4GB of logs stored by default.
Systems/Journald keeps 4GB of logs stored by default.
I didn’t expect him to live to 2024, but he’s still here. Kept alive by pure rage.
Bazzite for personal/gaming, currently Arch for my work install. Will be migrating to Aurora-DX for work one of these upcoming weekends. I still have Windows for the occasional game that doesn’t quite work right under Proton and for my VR headset which requires Windows Mixed Reality 🤮. Don’t do VR much, so it’s quite rare that I boot it up.
deleted by creator
That just made me imagine a Rust rewrite of systemd
What about the installer? Anaconda isn’t great, but you only need about 1 minute to set the options to install and then let it do it’s job before rebooting.
I’ve been using a Raspberry Pi 400 with LibreELEC installed. Mostly watch 4K HDR Blu-ray Remuxes that I have on another machine with a Samba server. Works really well for me.
Another good option would be to have Jellyfin on a media server and cast to the TV or use the TV directly if it has a Jellyfin app (I know there are official apps for Roku and WebOS (LG)). Jellyfin is similar to Plex but open-source and fully local (no need for an external account).
Of course, this is only works for local media. For streaming, just use a Chromecast.
You can’t. Just wait for it to be stable
A line of code that enables the backdoor was out present in the tarball. The actual code was obfuscated within an archive used for the unit testing.
I like the way kde does it. On first install it gives a slider with how much analytics you want to send. I just do all of it because I trust KDE, but it’s nice that it asks you. They probably have some pretty good data.
I actually have my ~/.cache
mounted as a tmpfs. No need to write that to disk when I have like 50GB of free RAM most of the time.
“Free” memory is actually usually used for cache. So instead of waiting to get data from the disk, the system can just read it directly from RAM after the first access. The more RAM you have, the more free space you’ll have to use for cache. My machine often has over 20GB of RAM used as cache. You can see this with free -m
. IIRC both Gnome and KDE’s system managers also show that now.
I imagine you could find a lot of options. Just a quick google turned up ThinStation, which only needs 30-50MB if storage and 64MB+ of RAM. A bit outdated, but should work fine.
You could also make your own OS with LFS if you want to optimize it to the extreme.
Chrome is actually doing a lot of work to display modern webpages though. A thin client only needs to receive a video stream and send inputs to a server. That can be done with an extremely low memory footprint. The Steam Link only had 512MB of RAM and it actually ran a steam client (which contains embedded chromium) instead of acting as a pure thin client.
You do realize that all modern phones have parental controls, right? This won’t block parents from being able to monitor their children.
Yeah, it looks like that little Jenga block from the xkcd meme was XZ and a bunch of infrastructure is gonna have issues because of it.
We also need support for the new protocol in Nvidia’s driver. Support will be available in driver 555, the beta of which will be released on May 15. So there’s still some time to wait until it’s fully fixed.
The Nvidia driver on Wayland has been decent for a couple of years and stabilized a lot over the past ~6 months. The flickering issue was specific to XWayland. Normal Wayland apps don’t have flickering problems (not quite sure why tbh), but XWayland apps would often rapidly flicker between 2 frames since it only supported implicit sync, which confused the Nvidia driver, which only supports explicit sync. Now with a Wayland protocol for explicit sync, XWayland can be updated to support it and resolve the flickering there.
So the 3rd dragon should just be /dev/nvme%d
run0
is the newsudo su