anarcat

In case you haven't seen, in April, Framework published an official Optimizing Ubuntu Battery Life guide that is quite useful: https://knowledgebase.frame.work/en_us/optimizing-ubuntu-battery-life-… If that doesn't help, I'd recommend reviewing some of the resources: * Framework Forum Linux battery life tuning thread (300+ messages) https://community.frame.work/t/guide-linux-battery-life-tuning/6665 * anarcat's Framework Battery Life and Power management testing: https://anarc.at/hardware/laptop/framework-12th-gen/#battery-life * I also did a long review covering different ways of optimizing CPU performance, evaluating idle and near idle power consumption, various power-testing (including writing a suspend battery logging tool that people may find useful, etc): https://github.com/lhl/linuxlaptops/wiki/2022-Framework-Laptop-DIY-Edi…

> I know xterm is the slowest of the bunch, but it always works with minimal putzing. I though that Xterm was the fastest in terms of latency and configured adequately, pretty going dealing with big amounts of text: https://anarc.at/blog/2018-05-04-terminal-emulators-2/ Xterm*fastScroll: true I am really grateful for Xterm, it is a great default for all my machines.

https://anarc.at/hardware/laptop/purism-librem13v4/#hardware-reliabili… And the third top level comment here: https://old.reddit.com/r/linux/comments/hr8hvi/not_recommending_purism… I've heard similar things in the past, but can't remember where.

I thought Debian were moving towards "pagure" (developed by Fedora)? https://anarc.at/blog/2017-06-26-alioth-moving-pagure/ Then I saw this, which dates from August 2017: https://wiki.debian.org/Alioth/GitNext/GitLab Personally, I work on a medium-size free software project, which has to choose between JIRA/Confluence (current), Github (where pull-requests currently happen), custom CI scripts/infra with Jenkins and a patchwork of other stuff. So far, Gitlab is the best option.

> This is patently false, the latest Kobo Libra Color is using secure boot which completely locks out custom development: > > https://www.mobileread.com/forums/showthread.php?t=363175 Thanks for the link on mobileread. I was not aware of current development in direction of secure boot / chain of trust. Not OP, but when I was looking for an e-reader, I looked up the Pinenote. I could not find easily a lot of information on its software state. I could find a lot on Kobo hacking. I notably found https://anarc.at/hardware/tablet/kobo-clara-hd/ and this motives me to get a second hand Clara HD for less than 100$. It was way cheaper than starting with 400$ and unknown software state.

I've found Syncthing to work well with my Kobo; it's easier than plugging it in and adding/removing books through Calibre. There's a KOReader plugin (https://github.com/jasonchoimtt/koreader-syncthing), or it can be enabled/disabled through Nickel (https://anarc.at/hardware/tablet/kobo-clara-hd/#install-syncthing).

Thanks for this. I am loosely familiar with mbsync and OfflineIMAP, used to use OfflineIMAP with mutt but it had a lot of bugs and crashed often. In this article https://anarc.at/blog/2021-11-21-mbsync-vs-offlineimap/ the author observes missing emails with both of them. And I thought neither tool supported upload, am I mistaken? Is simply using rsync to transfer the mail folders from one Maildir-based email server to another a viable approach?

The companion article to this is "procmail considered harmful": https://anarc.at/blog/2022-03-02-procmail-considered-harmful/

this fits my theory that the average bus factor is ~1: https://anarc.at/blog/2019-10-16-bus-factor/ Cynics have also suggested the average is closer to zero, but I still have hope that we at least need buses for a catastrophe to happen. ;)

Different conclusion for the same article: I picked mlterm https://anarc.at/blog/2018-05-04-terminal-emulators-2/

I found this benchmark http://anarc.at/blog/2014-11-18-bup-vs-attic-silly-benchmark/

> But I don't think they're around anymore and have no idea how you could achieve similar functionality with dynamic pages anyway. Chromium's MHTML "Save as…" and the SingleFile WebExtension should both save copies of the rendered DOM. Apparently Safari has WebArchive and Mozilla had MAFF for similar use cases. I think WARC is supposed to save enough data about network streams for dynamic pages to work. At least on the Wayback Machine, infinite scrolling and "Load More" buttons do kinda work sometimes. You may have to load the archived pages in a browser and try to use each dynamic feature at least once, to trigger requests for needed resources. SingleFile: https://github.com/gildas-lormeau/SingleFile LWN on WARC, tools: https://anarc.at/blog/2018-10-04-archiving-web-sites/ Self-hostable web archives: https://awesome-selfhosted.net/tags/archiving-and-digital-preservation… Wayback Machine addons, bookmarklets: https://help.archive.org/help/save-pages-in-the-wayback-machine/

My first upload will soon be 10 years ago. One thing that is definitely noticeable is that while creating a package is still by no means trivial, it has definitely become much, much easier. 10 years ago, you had a handful of very idiosyncratic build helpers to help you manage your package. Today, effectively it's just one [1], debhelper, and it has become trivial to build packages with it. It's a very powerful framework that can be overridden do do basically anything you like, but usually automagically does the right thing. Gone are the days where you had to write an unwieldy debian/rules file. 3 years ago, you had X version control systems supported: git, svn, mercurial, cvs, and who nows what else. Sounds unreasonable, right? Well, when you rely on volunteer work, you need to live with the fact that volunteers will choose the particular tooling they like to work with. Today, you have Salsa which is a GitLab instance, and people apparently just learned to deal with it, and the world hasn't come tumbling down. I absolutely agree with the author that some things are just wrong within Debian. However, I believe these are inherent to the nature of an organization comprised entirely of volunteers; achieving consensus becomes really hard because nobody wants to be told how to spend their free time. On the other hand, being involved in Debian has also been an incredibly formative experience. I believe Debian does some things right that others still fail at or trail…