[ Main ] [ Home ] [ Work ] [ Code ] [ Rants ] [ Readings ] [ Links ] |
|
|
[2024] December November October September August July June May April March February January [2023] [2022] [2021] [2020] [2019] [2018] [2017] [2016] [2015] [2014] [2013] [2012] [2011] [2010] [2009] [2008] [2007] [2006] [2005] [2004] [2003] |
On Flatpak
[Fri May 31 11:51:40 CDT 2024]
I must admit I've been installing Flatpak packages for a while now, and I have mixed feelings about it. On the one hand, I do like the flexibility it provides. No worries about dependencies, and no concerns on whether one's favorite distro carries a particular package on their repos. In addition to this, for someone like me who runs the stable branch of Debian, it gives me the chance to run new software that I wouldn't be able to run otherwise. That's nice. Yet, on the other hand, aside from the fact that it does take a good amount of time to launch the applications, they do use a large amount of disk space sometimes. Yes, I understand disk space is sort of cheap these days. Still, it feels quite wasteful, to be honest. {link to this entry} On AI apropos a debate by the Debian community
[Tue May 28 11:12:19 CDT 2024]
Since Gentoo decided to ban the use of generative AI tools due to copyright, ethical, and quality concerns, it turned out that the Debian community discussed the same topic. In the end, they took a "wait and see" attitude. But the reason why I think all this is important is mainly due to the reasons why they considered that using AI for coding might not be a good idea. It boils down to a coupe of considerations: first of all, there are questions and concerns about copyright issues and, in particular, where the AI vendors are getting their data from; and, second, there is also the consideration that the code provided by AI simply does not show a good quality. I think both arguments apply to regular users who don't plan to use AI for programming too. One of them has an ethical nature. Where did the data used to train these tools come from? Were they provided freely? Can we trust that data? Is it impartial, objective? The second argument is more practical: can we trust the tool itself? Can we trust that the information it provides is correct? Or do we always need to double-check and confirm (in which case perhaps its usefulness is limited)? {link to this entry} Debian kernel 5.10.0-29-amd64 fails to boot due to Nvidia bug
[Thu May 16 14:06:07 CDT 2024]
After installing updates on my laptop, which is still running Debian 11 (bullseye), it failed to boot with the new kernel version 5.10.0-29-amd64. My first reaction was to reinstall the package. You know, as the old saying goes, stupidity is to continue trying the same thing, even though it didn't work the first time. Anyways, this second time, after apt failed setting up the package, I noticed some errors. I followed the directions from the output to check the contents of the following file: Sure enough, we had some errors while setting up the Nvidia kernel module:/var/lib/dkms/nvidia-current/470.199.02/build/make.log After a quick search, it seemed clear that this was a bug with the Nvidia code. See, for instance, this post on the Nvidia developer forum. For the time being, I purged the new kernel, reverted back to the old one, and things are working fine again. {link to this entry}(...) FATAL: modpost: GPL-incompatible module nvidia.ko uses GPL-only symbol 'rcu_read_unlock_strict' make[3]: *** [/usr/src/linux-headers-5.10.0-29-common/scripts/Makefile.modpost:123: \ /var/lib/dkms/nvidia-current/470.199.02/build/Module.symvers] Error 1 make[2]: *** [/usr/src/linux-headers-5.10.0-29-common/Makefile:1783: modules] Error 2 make[2]: Leaving directory '/usr/src/linux-headers-5.10.0-29-amd64' make[1]: *** [Makefile:192: __sub-make] Error 2 make[1]: Leaving directory '/usr/src/linux-headers-5.10.0-29-common' make: *** [Makefile:80: modules] Error 2 Downgrading a package on Debian GNU/Linux
[Thu May 16 13:48:32 CDT 2024]
Even though Debian 12 (bookworm) released almost a year ago, I haven't upgraded my laptop yet. I've been too busy with a thousand other things. So, it didn't totally surprise me when I installed the latest available updates for Debian 11 (bullseye), the oldstable release, yesterday, and ran into issues with an application, particularly since it's a third-party app. In this case, it was Slack, which I download from their own repos. Whenever I launch it, it segfaults right away. It doesn't even show the main screen. I just don't have time to troubleshoot this right now, so I decided to downgrade to the older version. Here are the steps: That's all. It's now the old version fine. If anything, don't forget to pin the package so apt doesn't try to install the newer one next time around. {link to this entry}# apt policy slack-desktop (Pick the version to downgrade to; version 4.37.101 in my case) # apt install slack-desktop=4.37.101 |