bunitor

i run debian 13 on my laptop. it runs on a 5200rpm hard disk, so some bootup slowdown is to be expected, but it got really bad for some reason. booting up could take up to 3 minutes just to get to the display manager

after running systemd-analyze blame i found the two main culprits: docker and snapd. i had snapd and flatpak installed so that i could have access to as many applications as i could, but it seems that snaps have a huge amount of overhead. i knew about the one million mountpoints caused by snaps, but the amount of services they have to start on boot surprised me. snapd alone took 30 seconds to start and then there were its dependencies

my boot time is now down to 1min 50s. i recommend anyone who still has snapd installed on a non-ubuntu distro to uninstall it

i know this sounds silly and it should be obvious, but i've been using x forwarding at work for a few days now, but it just dawned on me that i'm running wayland on my plasma machine and the x forwarded window is display through xwayland. it works so well that i didn't even notice a difference and in fact it seems to perform better than on x

this is not even the first time xwayland works better than pure x at work. i also need to use horizon client every once in a while and it got so much more stable after i moved to wayland -- even though the application claims wayland is unsupported

the context is: the 470 legacy driver doesn't compile on the linux 6.12 kernel. because of that, debian decided to officially drop support to that driver. i tried installing the driver myself using nvidia's official installer, but the installation indeed fails during the module compilation stage.

this means i am stuck with nouveau. it got better since i last tested it on bookworm, but one major pain in the ass is that nouveau has no support for performance levels for my card and it runs at the lowest clock bc of that (~400 megahertz instead of its max ~900 mhz).

this causes a noticeable performance hit, even for desktop usage, but it's good enough for work. waching full hd 60 fps video is a bit painful, but it's possible. but gaming, which was possible, got way worse. even a lightweight game like celeste got frustrating to play due to stuttering.

i guess i'll have to deal with it and maybe this is the cue to buy another graphics card and never buy nvidia again, but i'm thinking about what my options would be here:

1. downgrade to bookworm. not easy to do, would only delay the problem.
2. install an older kernel and use only that. not sure how, the official repos only have the 6.12 kernel. i could get the older kernel from the bookworm backports and pin it to prevent any updates, but mixing repos from different versions makes me uneasy.
3. patch the driver. there are a few patches floating around that make nvidia's driver compile on the 6.12 kernel. applying the patch by hand is annoying and i would have to re-apply it at every kernel update.
4. cope.

any ideas?

edit

and it runs at the lowest clock bc of that (~400 megahertz instead of its max ~900 mhz).

that was a mistake. i was reading the clock off of my onboard video chip, which also happens to be nvidia. the onboard chip is at .../dri/0; my graphics card is at .../dri/1. nouveau seems to support reclocking for my card, but i'm trying to change the clock and the video signal goes crazy when i do it

trixie (aka debian 13) is about to get released with plasma 6.3. it seems that finally x11 is being left behind, which is good, but it worried me a little bit because

1. my nvidia graphics card is old: the 470 driver is the latest version that supports it (so no wayland support from nvidia proprietary drivers ever)

2. on bookworm (debian 12, the current stable version), nouveau works pretty well, but it crashed more or less daily when i tried to daily drive it at work

x11 is still very well supported by plasma 6, but the near future has no place to it and i worry i would eventually get stuck without updates to my system as the newer versions lose x11 support. i decided to try wayland+nouveau again on trixie to see if i had better luck this time

it all worked way better than i expected. performance is seemingly on par with the proprietary driver, i've had no crashes so far and i've been using it for a week and even screensharing, one of the most problematic aspects of the experience last time i tried, worked well. the one problem i had was with the slack flatpak, which didn't support wayland for some reason, so it had to run on xwayland. screen sharing wayland applications from x11 apps is possible through the xwaylandvideobridge, which kinda works, but it crashed xwayland entirely at one point, killing both x11 applications i had running. i won't blame that on the system itself and installing the slack deb package fixed the problem anyway

all in all, it seems like i can safely switch to plasma 6+wayland+nouveau at work

i get a little annoyed at posts that start with broad statements like "is linux actually ready for the average user?" but then it's just someone asking for help to fix a problem they have with their sources.list or whatever. it's not a massive problem, but it's misleading and it feels borderline inflammatory sometimes

please tell when you're asking for help

ty

anyone else noticed this? it started a few days ago

i want to test debian trixie (13) so i can report bugs and troubleshoot before the release later this year. i thought about simply installing trixie alongside my current bookworm installation, but that won't be my scenario when the time comes, since i've been updating my system instead of reinstalling it since debian jessie (8) and this time it won't be different. how can i clone my current system so i can simulate an update to trixie? do i simply create a new partition and copy my files over, then chroot to it and install grub?

i'm having a little bit of a hard time expanding the unstaged changes on magit. the mode menu works fine via touch on android, so i can do most operations, but i can't expand the unstaged files in the main magit buffer without the keyboard, which is a problem since read-only buffers hide the kb by default. i could change that configuration, but i'm using a phone, so screen real state is very limited, so i want to avoid that if possible. i tried touching, double tapping, holding, but nothing seems to expand the files

i feel like i'm in uncharted territory, so this is a long shot i think, but is anyone else having similar problems?

please dump any small browsers you know about, i'd like to try them out

the two i can think of are emacs's eww and links (text mode). eww has been surprisingly useful, even without js support and extremely barebones html rendering

this is eww:

and this is links:

sadly, neither is able to login to lemmy, but I was able to login to mastodon through brutaldon

EDIT: ooh, i forgot about lynx (not links). also command-line. it managed to successfully login to lemmy:

tl;dr if you have an encoding problem while running guile on emacs for android with termux, make sure the LANG env var on emacs matches the value of termux:

;; ~/.emacs.d/early-init.el
(setenv "LANG" "en_US.UTF-8")

don't where else to post this, so i'm posting it here so it doesn't gets lost

emacs >=30 comes with android support. i've been using it for a while now, but it's really only useful if you can install applications to use it with. that's why the project offers an emacs package and a termux package with the same signature so you can share the termux binaries with the emacs runtime. packages and instructions here: https://sourceforge.net/projects/android-ports-for-gnu-emacs/files/termux/

i tried running guile on emacs with geiser a few days ago but it failed to run due to some encoding issues. it ran fine on termux

after a little googling, i compared the values of the LANG variable in both termux and emacs:

• termux: LANG=en_US.UTF-8
• emacs: LANG=en_US.utf8

then i just changed ˋLANGˋ on emacs to match the termux value and that solved the problem! to keep it working, i added the change to ˋ~/.emacs.d/early-init.elˋ:

(setenv "LANG" "en_US.UTF-8")

over on reddit, there's a distinction between /r/linux (general discussions) and /r/linuxquestions (community support). i notice a lot of support posts over here, which could warrant the split, but otoh maybe the volume of posts is not enough to justify it and it could risk spreading our community way too thin

what do you think?

i've instaled opensuse tumbleweed a bunch of times in the last few years, but i always used ext4 instead of btrfs because of previous bad experiences with it nearly a decade ago. every time, with no exceptions, the partition would crap itself into an irrecoverable state

this time around i figured that, since so many years had passed since i last tried btrfs, the filesystem would be in a more reliable state, so i decided to try it again on a new opensuse installation. already, right after installation, os-prober failed to setup opensuse's entry in grub, but maybe that's on me, since my main system is debian (turns out the problem was due to btrfs snapshots)

anyway, after a little more than a week, the partition turned read-only in the middle of a large compilation and then, after i rebooted, the partition died and was irrecoverable. could be due to some bad block or read failure from the hdd (it is supposedly brand new, but i guess it could be busted), but shit like this never happens to me on extfs, even if the hdd is literally dying. also, i have an ext4 and an ufs partition in the same hdd without any issues.

even if we suppose this is the hardware's fault and not btrfs's, should a file system be a little bit more resilient than that? at this rate, i feel like a cosmic ray could set off a btrfs corruption. i hear people claim all the time how mature btrfs is and that it no longer makes sense to create new ext4 partitions, but either i'm extremely unlucky with btrfs or the system is in fucking perpetual beta state and it will never change because it is just good enough for companies who can just, in the case of a partition failure, can just quickly switch the old hdd for a new one and copy the nightly backup over to it

in any case, i am never going to touch btrfs ever again and i'm always going to advise people to choose ext4 instead of btrfs