it should use the encryption passphrase to auto unlock the keyring after the autologin
It doesn’t, hence the need to remove the password. Password only comes back every once in a while, rather than every login. Maybe a bad combination of desktop environment/session manager? LightDM with XFCE in my case.
Meanwhile, I’m fighting to get rid of the password on the keyring each time it comes back by itself. For context, my root partition is encrypted, so it’s not a huge deal if the keyring stored on it doesn’t have its own password, I think. I set up autologin to avoid a duplicate password, but since the session manager no longer unlocks the keyring, the keyring must have no password else I get a password prompt all over again. There’s probably a more elegant way, but I’ve yet to find it.
As long as you have a strong backup strategy, I would recommend full disk encryption during installation, especially if for a laptop. Peace of mind with negligible cost on modern hardware. Even accessing the encrypted disk from a live USB takes only two extra commands compared to an unencrypted disk. As long as the LUKS header doesn’t corrupt, hence the need for good backups.
This is one of the mundane scripting tasks I would have my local LLM help with. I would still read through and make sure I understand the resulting script before running it.
Wanted to, but lacked the motivation to learn it. Was stuck on one occasion without nano, so I pulled up the vim cheat sheet on my phone.
Not going after a bug though, it’s just the way the included battery meter in Xfce (and other X11 battery indicators I’ve found) works, while things like Android track usage over time to give a better estimate.
But based on the other responses, it looks like I’ll have to cook it up myself.
Not that I’m aware of
That is correct, IIRC, the mismatch does limit how much of it can run in dual-channel. Even if a single stick is natively 24 or 48 GB, there is additional strain on the memory controller. It is the way it is on my setup since I had planned an upgrade to a full 64 GB and was holding off until a good deal on the remaining 32 GB kit, which will never come unless the AI bubble bursts.
I think I could hack such a feature into the tray indicator as a weekend project, but wanted to see if someone already accomplished it before I go reinventing the wheel.
What about it? I see it kicking in at least 10 GB before my RAM is full and I haven’t noticed any fundamental differences between how zram works on my 48 GB workstation and my 8 GB devices. Maybe I’ve never had a workload that filled all 48 GB + extra zram capacity, but it’s never given me an issue.
My workstation has 48 GB RAM with 50% allocation allowed to zram, no disk swapping. It works just fine. Once I use up the majority of my RAM, it kicks in the same way it would on any other system with less RAM.
16 GB VRAM GPU, models stored on SSD, rest of the computer doesn’t have to be crazy. Intel Arc is best bang for the buck at the moment. You can get LLM running on 8 GB cards or even the CPU, but IMO such small models are more novelties than workhorses. I personally use Debian but you’ll be fine as long as your distro’s repo has drivers recent enough for your GPU.
For perspective, I’m using such a build to help with boilerplate code, single-use scripts that I don’t have the patience to trial-and-error (like ones that have to deal with directory structures and special characters), getting an idea of what’s what when decompiling and reverse engineering, brainstorming tip-of-the-tongue ideas, and upscaling images.
I was so excited I could finally solve it, but unfortunately, it already was set to Latency.
Shutter times are ridiculous on mine. The preview will be perfectly focused already, but then it takes a good second to actually capture, by that time it might already have lost focus. Capture resolution aside, it’s literally faster to screenshot the preview. And got into an argument with a friend once because the shutter time made miss a shot.
Removing all the system-level bloat that makes them unpleasant to use, perhaps stripping one down to the level of a fancy MP3 player with its microSD slot. Also having “disposable” phones to play with various rooted tweaks. All of my easily-rootable phones are too valuable as daily drivers to experiment on, while all of the ones I don’t care about also don’t have rooting methods yet.
Can’t wait for one that’ll work on Android so I can maybe root some otherwise useless old phones
There is a lot to justify my move to Linux in hindsight, including privacy, less bloat, the nature of FOSS, etc. But before I really understood those concepts, a good chunk of why I switched over was my dissatisfaction with the loss of customization options starting with Windows 8.
I’d still never bounce back to Windows, of course, though I am strongly considering writing a full theming engine like Kvantum, but to act as a libadwaita replacement/shim, if it creeps into too many packages I use on a daily basis. I’m glad to see that the theming can be altered in some capacity system-wide, rather than being baked into each package.
I feel this but with libadwaita apps. Stick out like a sore thumb, can’t theme them, and many aren’t even GNOME’s own core apps.
As someone who has used X11 and Wayland, it doesn’t matter for the typical user. If you, like me, have a penchant for some smaller desktop environments like XFCE or window managers, you will be stuck with X11, but many are already working on porting to Wayland.
Couple edge cases for gaming, namely screen tearing on some X11 configurations and certain Nvidia hardware running into issues on Wayland. For multi-monitor or high DPI users, Wayland handles per-monitor DPI and fractional scaling far better than X11. Maybe a couple more edge use cases for remoting into the desktop, but Wayland support is also improving quickly on that end. In any case, Wayland is by design more secure than X11.