Many folks have woken up to the dangers of commercialization and centralisation of this very fine internet we have around here. For many of us, of course, it's one big "I told you so"... (To fair, I stopped "telling you so" because evangelism is pretty annoying. It's certainly dishonest coming from an atheist, so I preach by example now. I often wonder what works better. But I digress.) Colleagues have been posting about getting back into blogging. This post from gwolf, in particular, reviews his yearly blog output, and that made me wonder how that looked like from my end. The answer, of course, is simple to generate:

anarcat@angela:~$ cd anarc.at
/home/anarcat/wikis/anarc.at
anarcat@angela:anarc.at$ ls blog   grep '^[0-9][0-9][0-9][0-9]'   sed s/-.*//   sort   uniq -c    sort -n -k2
     62 2005
     49 2006
     26 2007
     25 2008
      8 2009
     16 2010
     24 2011
     19 2012
     17 2013
      7 2014
     19 2015
     32 2016
     43 2017
     40 2018
     27 2019
     33 2020
     22 2021
     45 2022
      1 2023

(I thought of drawing this as a sparkline but it looks like Sparklines are kind of dead. https://sparkline.org/ doesn't resolve and the canonical PHP package is gone from Debian. The plugin is broken in ikiwiki anyway...) So it seems like I've been doing this very blog for 18 years, and it's not even my first blog. I actually started in 2003, which makes this year my 20-year blogging anniversary. (And even if that sounds really old, note that I was not actually an early adopter. Jorn Barger having coined the term "weblog" in 1997. Yes, in another millenia.) Reading back some of the headlines in those older posts, I have definitely changed style. I used to write shorter, more random ideas, and more often. I somehow managed to write more than one article per week in 2005! Now, I take more time writing, a habit I picked up while writing for LWN (those articles), which started in 2016. But interestingly, it seems I started producing more articles then: I hit 43 articles per year in 2017, my fourth best year ever. The best years in terms of numbers are the first two years (2005 and 2006, I didn't check the numbers on earlier years), but I doubt they are the best in terms of content. Really, the best writing I have ever did was for LWN. I dare hope I have kept the quality I was encouraged (forced?) to produce, but I know I cannot come anywhere close to what the LWN editors were juicing out of me. You can also see that I immediately dropped to a more normal 27 article in 2019, once I stopped writing for LWN... Back when I started blogging, my writing was definitely more personal. I had less concerns about privacy back then; now, I would never write about my personal life like I did back then (e.g. "I have a cold"). I was also writing mostly in French back then, and it's sad to think that I am rarely writing in my native language here anymore. I guess that brings me an international audience, which is simultaneously challenging, gratifying, and terrifying. But it also means I reach out to people that do not speak English (or French, for that matter) as their first language. For me that is more valuable than catering to my little corner of culture, at least for now, and especially when writing technical topics, which is most of what I do now anyways. Interestingly, I wrote a lot in 2022. People sometimes ask me how I manage to write so much: I don't actually know. I don't have a lot of free time on my hand, and even less than before in the past two years, but somehow I keep feeding this blog. I guess I must have something to say. Can't quite figure out what yet, so maybe I should just keep trying. Or, if you're new to this Internet thing, Bring Back Blogging! Whee! PS: I wish I had time to do a review of my visitors like i did for 2021 but time is missing.

Review: Postwar, by Tony Judt

Publisher:	Penguin Books
Copyright:	2005
ISBN:	1-4406-2476-3
Format:	Kindle
Pages:	835

Tony Judt (1948 2010) was a British-American historian and Erich Maria Remarque Professor in European Studies at New York University. Postwar is his magnum opus, a history of Europe from 1945 to 2005. A book described as a history of Europe could be anything from a textbook to a political analysis, so the first useful question to ask is what sort of history. That's a somewhat difficult question to answer. Postwar mentions a great deal of conventional history, including important political movements and changes of government, but despite a stated topic that would suit a survey textbook, it doesn't provide that sort of list of facts and dates. Judt expects the reader to already be familiar with the broad outlines of modern European history. However, Postwar is also not a specialty history and avoids diving too deep into any one area. Trends in art, philosophy, and economics are all mentioned to set a broader context, but still only at the level of a general survey. My best description is that Postwar is a comprehensive social and political history that attempts to focus less on specific events and more on larger trends of thought. Judt grounds his narrative in concrete, factual events, but the emphasis is on how those living in Europe, at each point in history, thought of their society, their politics, and their place in both. Most of the space goes to exploring those nuances of thought and day-to-day life. In the US university context, I'd place this book as an intermediate-level course in modern European history, after the survey course that provides students with a basic framework but before graduate-level specializations in specific topics. If you have not had a solid basic education in European history (and my guess is that most people from the US have not), Judt will provide the necessary signposts, but you should expect to need to look up the signposts you don't recognize. I, as the dubious beneficiary of a US high school history education now many decades in the past, frequently resorted to Wikipedia for additional background. Postwar uses a simple chronological structure in four parts: the immediate post-war years and the beginning of the Cold War (1945 1953), the era of rapidly growing western European prosperity (1953 1971), the years of recession and increased turmoil leading up to the collapse of communism (1971 1989), and the aftermath of the collapse of communism and the rise of the European Union (1989 2005). Each part is divided into four to eight long chapters that trace a particular theme. Judt usually starts with the overview of a theme and then follows the local manifestations of it on a spiral through European countries in whatever order seems appropriate. For the bulk of the book that covers the era of the Cold War, when experiences were drastically different inside or outside the Soviet bloc, he usually separates western and eastern Europe into alternating chapters. Reviewing this sort of book is tricky because so much will depend on how well you already know the topic. My interest in history is strictly amateur and I tend to avoid modern history (usually I find it too depressing), so for me this book was remedial, filling in large knowledge gaps that I ideally shouldn't have had. Postwar was a runner up for the Pulitzer Prize for General Non-Fiction, so I think I'm safe saying you won't go far wrong reading it, but here's the necessary disclaimer that the rest of my reactions may not be useful if you're better versed in modern European history than I was. (This would not be difficult.) That said, I found Postwar invaluable because of its big-picture focus. The events and dates are easy enough to find on the Internet; what was missing for me in understanding Europe was the intent and social structures created by and causing those events. For example, from early in the book:

On one thing, however, all were agreed resisters and politicians alike: "planning". The disasters of the inter-war decades the missed opportunities after 1918, the great depression that followed the stock-market crash of 1929, the waste of unemployment, the inequalities, injustices and inefficiencies of laissez-faire capitalism that had led so many into authoritarian temptation, the brazen indifference of an arrogant ruling elite and the incompetence of an inadequate political class all seemed to be connected by the utter failure to organize society better. If democracy was to work, if it was to recover its appeal, it would have to be planned.

It's one thing to be familiar with the basic economic and political arguments between degrees of free market and planned economies. It's quite another to understand how the appeal of one approach or the discredit of another stems from recent historical experience, and that's what a good history can provide. Judt does not hesitate to draw these sorts of conclusions, and I'm sure some of them are controversial. But while he's opinionated, he's rarely ideological, and he offers no grand explanations. His discussion of the Yugoslav Wars stands out as an example: he mentions various theories of blame (a fraught local ethnic history, the decision by others to not intervene until the situation was truly dire), but largely discards them. Judt's offered explanation is that local politicians saw an opportunity to gain power by inflaming ethnic animosity, and a large portion of the population participated in this process, either passively or eagerly. Other explanations are both unnecessarily complex and too willing to deprive Yugoslavs of agency. I found this refreshingly blunt. When is more complex analysis a way to diffuse responsibility and cling to an ideological fantasy that the right foreign policy would have resolved a problem? A few personal grumblings do creep in, particularly in the chapters on the 1970s (and I think it's not a coincidence that this matches Judt's own young adulthood, a time when one is prone to forming a lot of opinions). There is a brief but stinging criticism of postmodernism in scholarship, which I thought was justified but probably incomplete, and a decidedly grumpy dismissal of punk music, which I thought was less fair. But these are brief asides that don't detract from the overall work. Indeed, they, along with the occasional wry asides ("respecting long-established European practice, no one asked the Poles for their views [on Poland's new frontiers]") add a lot of character. Insofar as this book has a thesis, it's in the implications of the title: Europe only exited the postwar period at the end of the 20th century. Political stability through exhaustion, the overwhelming urgency of economic recovery, and the degree to which the Iron Curtain and the Cold War froze eastern Europe in amber meant that full European recovery from World War II was drawn out and at times suspended. It's only after 1989 and its subsequent upheavals that European politics were able to move beyond postwar concerns. Some of that movement was a reemergence of earlier European politics of nations and ethnic conflict. But, new on the scene, was a sense of identity as Europeans, one that western Europe circled warily and eastern Europe saw as the only realistic path forward.

What binds Europeans together, even when they are deeply critical of some aspect or other of its practical workings, is what it has become conventional to call in disjunctive but revealing contrast with "the American way of life" the "European model of society".

Judt also gave me a new appreciation of how traumatic people find the assignment of fault, and how difficult it is to wrestle with guilt without providing open invitations to political backlash. People will go to great lengths to not feel guilty, and pressing the point runs a substantial risk of creating popular support for ideological movements that are willing to lie to their followers. The book's most memorable treatment of this observation is in the epilogue, which traces popular European attitudes towards the history of the Holocaust through the whole time period. The largest problem with this book is that it is dense and very long. I'm a fairly fast reader, but this was the only book I read through most of my holiday vacation and it still took a full week into the new year to finish it. By the end, I admit I was somewhat exhausted and ready to be finished with European history for a while (although the epilogue is very much worth waiting for). If you, unlike me, can read a book slowly among other things, that may be a good tactic. But despite feeling like this was a slog at times, I'm very glad that I read it. I'm not sure if someone with a firmer grounding in European history would have gotten as much out of it, but I, at least, needed something this comprehensive to wrap my mind around the timeline and fill in some embarrassing gaps. Judt is not the most entertaining writer (although he has his moments), and this is not the sort of popular history that goes out of its way to draw you in, but I found it approachable and clear. If you're looking for a solid survey of modern European history with this type of high-level focus, recommended. Rating: 8 out of 10

When Firefox receives a file with media type text/markdown, it prompts the user to download it, while other browsers display it as plain text. In the ticket 1319262, it is proposed to display Markdown files by default, but there needs a patch

Version 0.0.12 of RcppSpdlog is now on CRAN and in Debian. RcppSpdlog bundles spdlog, a wonderful header-only C++ logging library with all the bells and whistles you would want that was written by Gabi Melman, and also includes fmt by Victor Zverovich. This release adds support for the stopwatch object, a simple container around a std::chrono object. It makes (simple) time measurements of routines and code segments trivially easy. Instantiate a stopwatch object, and formatting it in a logging string displays elapsed time. And given that the whole mojo of RcppSpdlog (and its sibbling package spdl) is to make use easy in both R and C++ we can do this nicely and consistently in both languages. The vignette has an added section with a concrete example. The NEWS entry for this release follows.

Changes in RcppSpdlog version 0.0.12 (2023-01-07)

• Addeed support for 'stopwatch' object allowing for simple timing (from both C++ and R) via the logging framework.
• The spdlog logging pattern is documented via a reference.

Courtesy of my CRANberries, there is also a diffstat report. More detailed information is on the RcppSpdlog page, or the package documention site. If you like this or other open-source work I do, you can sponsor me at GitHub.

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. Please report excessive re-aggregation in third-party for-profit settings.

Welcome to the December 2022 report from the Reproducible Builds project.

---

We are extremely pleased to announce that the dates for the Reproducible Builds Summit in 2023 have been announced in 2022 already:

• When: October 31st, November 1st, November 2nd 2023.
• Where: Dock Europe, Hamburg, Germany.

We plan to spend three days continuing to the grow of the Reproducible Builds effort. As in previous events, the exact content of the meeting will be shaped by the participants. And, as mentioned in Holger Levsen s post to our mailing list, the dates have been booked and confirmed with the venue, so if you are considering attending, please reserve these dates in your calendar today.

---

R my Gr nblatt, an associate professor in the T l com Sud-Paris engineering school wrote up his pain points of using Nix and NixOS. Although some of the points do not touch on reproducible builds, R my touches on problems he has encountered with the different kinds of reproducibility that these distributions appear to promise including configuration files affecting the behaviour of systems, the fragility of upstream sources as well as the conventional idea of binary reproducibility.

---

Morten Linderud reported that he is quietly optimistic that if Go programming language resolves all of its issues with reproducible builds (tracking issue) then the Go binaries distributed from Google and by Arch Linux may be bit-for-bit identical. It s just a bit early to sorta figure out what roadblocks there are. [But] Go bootstraps itself every build, so in theory I think it should be possible.

---

On December 15th, Holger Levsen published an in-depth interview he performed with David A. Wheeler on supply-chain security and reproducible builds, but it also touches on the biggest challenges in computing as well. This is part of a larger series of posts featuring the projects, companies and individuals who support the Reproducible Builds project. Other instalments include an article featuring the Civil Infrastructure Platform project and followed this up with a post about the Ford Foundation as well as a recent ones about ARDC, the Google Open Source Security Team (GOSST), Jan Nieuwenhuizen on Bootstrappable Builds, GNU Mes and GNU Guix and Hans-Christoph Steiner of the F-Droid project.

---

A number of changes were made to the Reproducible Builds website and documentation this month, including FC Stegerman adding an F-Droid/apksigcopier example to our embedded signatures page [ ], Holger Levsen making a large number of changes related to the 2022 summit in Venice as well as 2023 s summit in Hamburg [ ][ ][ ][ ] and Simon Butler updated our publications page [ ][ ].

---

On our mailing list this month, James Addison asked a question about whether there has been any effort to trace the files used by a build system in order to identify the corresponding build-dependency packages. [ ] In addition, Bernhard M. Wiedemann then posed a thought-provoking question asking How to talk to skeptics? , which was occasioned by a colleague who had published a blog post in May 2021 skeptical of reproducible builds. The thread generated a number of replies.

---

Android news obfusk (FC Stegerman) performed a thought-provoking review of tools designed to determine the difference between two different .apk files shipped by a number of free-software instant messenger applications. These scripts are often necessary in the Android/APK ecosystem due to these files containing embedded signatures so the conventional bit-for-bit comparison cannot be used. After detailing a litany of issues with these tools, they come to the conclusion that:

It s quite possible these messengers actually have reproducible builds, but the verification scripts they use don t actually allow us to verify whether they do.

This reflects the consensus view within the Reproducible Builds project: pursuing a situation in language or package ecosystems where binaries are bit-for-bit identical (over requiring a bespoke ecosystem-specific tool) is not a luxury demanded by purist engineers, but rather the only practical way to demonstrate reproducibility. obfusk also announced the first release of their own set of tools on our mailing list. Related to this, obfusk also posted to an issue filed against Mastodon regarding the difficulties of creating bit-by-bit identical APKs, especially with respect to copying v2/v3 APK signatures created by different tools; they also reported that some APK ordering differences were not caused by building on macOS after all, but by using Android Studio [ ] and that F-Droid added 16 more apps published with Reproducible Builds in December.

---

Debian As mentioned in last months report, Vagrant Cascadian has been organising a series of online sprints in order to clear the huge backlog of reproducible builds patches submitted by performing NMUs (Non-Maintainer Uploads). During December, meetings were held on the 1st, 8th, 15th, 22nd and 29th, resulting in a large number of uploads and bugs being addressed:

• Chris Lamb: aespipe (#661079, #1020809), cdbackup (#1011428) & xmlrpc-epi (#865688, #1020651)
• Holger Levsen: apr-util (#1006865), lirc (#979024) & ruby-omniauth-tumblr
• Vagrant Cascadian: amavisd-milter (#975954), apophenia (#940013), cfi (#995647), chessx (#881664), cmocka (#991181), desmume (#890312), golang-gonum-v1-plot (#968045), intel-gpu-tools (#945105), jhbuild (#971420), libjama (#986601), libjs-qunit (#976445), liblip (#1001513, #989583), libstatgrab (#961747), mlpost (#977179 and #977180), netcdf-parallel (#972930), netgen-lvs (#955783), perfect-scrollbar (#1000770), python-tomli (#994979), pytsk (#992060), smplayer (#997689), squeak-plugins-scratch (#876771, #942006), stgit (#942009), strace (#896016), surgescript (#992061), sympow (#973601), wxmaxima (#983148), xavs2 (#952493), xaw3d (#991180, #986704) and yard (#972668).

The next sprint is due to take place this coming Tuesday, January 10th at 16:00 UTC.

---

Upstream patches The Reproducible Builds project attempts to fix as many currently-unreproducible packages as possible. This month, we wrote a large number of such patches, including:

• Bernhard M. Wiedemann:
  • OpenRGB (filesystem ordering issue)
  • python-maturin (report an issue regarding random numbers)
  • rav1e (datetime-related issue)
  • weblate (report that the build fails in 2038)
• Chris Lamb:
  • #1025415 filed against cctools.
  • #1025801 filed against sphinx (forwarded upstream)
  • #1026381 filed against python-django-health-check.
  • #1026876 filed against jamin.
  • #1026877 filed against opari2.

---

Testing framework The Reproducible Builds project operates a comprehensive testing framework at tests.reproducible-builds.org in order to check packages and other artifacts for reproducibility. In October, the following changes were made by Holger Levsen:

• The osuosl167 machine is no longer a openqa-worker node anymore. [ ][ ]
• Detect problems with APT repository signatures [ ] and update a repository signing key [ ].
• reproducible Debian builtin-pho: improve job output. [ ]
• Only install the foot-terminfo package on Debian systems. [ ]

In addition, Mattia Rizzolo added support for the version of diffoscope in Debian stretch which doesn t support the --timeout flag. [ ][ ]

---

diffoscope diffoscope is our in-depth and content-aware diff utility. Not only can it locate and diagnose reproducibility issues, it can provide human-readable diffs from many kinds of binary formats. This month, Chris Lamb made the following changes to diffoscope, including preparing and uploading versions 228, 229 and 230 to Debian:

• Fix compatibility with file(1) version 5.43, with thanks to Christoph Biedl. [ ]
• Skip the test_html.py::test_diff test if html2text is not installed. (#1026034)
• Update copyright years. [ ]

In addition, Jelle van der Waa added support for Berkeley DB version 6. [ ] Orthogonal to this, Holger Levsen bumped the Debian Standards-Version on all of our packages, including diffoscope [ ], strip-nondeterminism [ ], disorderfs [ ] and reprotest [ ].

---

If you are interested in contributing to the Reproducible Builds project, please visit our Contribute page on our website. You can get in touch with us via:

• IRC: #reproducible-builds on irc.oftc.net.
• Twitter: @ReproBuilds
• Mailing list: rb-general@lists.reproducible-builds.org

What are the most important improvements that Debian need to make? I decided to see what all the fuss is about and asked ChatGPT that exact question. It s response:

The list of potential improvements for Debian that I provided is based on my understanding of the challenges and opportunities that software projects like Debian typically face, as well as my understanding of the goals and values of the Debian project. It is not based on any specific information about the current priorities or needs of the Debian project or community. There are many areas where the Debian project could make improvements, and the most important ones will depend on the priorities and needs of the project and its community. Some potential areas for improvement could include:

1. Improving the user experience: Debian is known for its stability and security, but it is not always the easiest distribution to use, especially for new users. Improving the user experience and making Debian more accessible to a wider audience could be an important goal.
2. Keeping up with the rapid pace of change in the software ecosystem: With over 50,000 packages, Debian is a large distribution, and it can be difficult to keep up with the constant stream of updates and new software being released. Developing tools and processes to help manage this complexity and ensure that new packages are tested and integrated smoothly could be an important focus.
3. Maintaining the stability and security of the distribution: Ensuring that Debian remains a stable and secure platform is a top priority for the project. This includes testing new packages thoroughly before they are included in the distribution, responding quickly to security vulnerabilities, and investing in infrastructure and processes to support these efforts.
4. Ensuring the long-term sustainability of the project: Debian is a volunteer-driven project, and it can be challenging to attract and retain contributors over the long term. Developing strategies to support and encourage participation and collaboration within the community could be an important focus.
5. Enhancing the tools and infrastructure that support the project: The Debian project relies on a wide range of tools and infrastructure to support its development and distribution efforts. Improving and modernizing these resources could help to make the project more efficient and effective.

I find that to be a great response, and I m curious where it came from, so I asked How did you come to that conclusion? , it replied:

The list of potential improvements for Debian that I provided is based on my understanding of the challenges and opportunities that software projects like Debian typically face, as well as my understanding of the goals and values of the Debian project. It is not based on any specific information about the current priorities or needs of the Debian project or community.

Well, one thing is for sure, the IRC chat bots of the future are going to be much more complex than the ones I grew up with :-)

I have a patchset that makes it safe to use hibernation under Linux even in a secure boot world but it relies on preventing userland from using one of the TPM PCRs[1] that would otherwise be available to it. TPM 2 devices support emulating PCRs in NVRAM, which would obviously be beneficial in not taking away a scare resource, but the docs suggest there's no way to tie a key generation to an NVRAM value which makes this more complicated.

So, why not ask a computer to do this for me? I asked ChatGPT to write me some code that would bind a TPM key to an NVRAM value. After a couple of false starts it told me:To bind an encryption key to the value of a TPM NV index, you can use the TPM2_NV_DefineSpace command to define an NV index with the TPMA_NV_BIND attribute. Woo! That sounds perfect. Only one problem - I can't actually find the TPMA_NV_BIND attribute defined anywhere in the spec. Well, ask the AI again.

Here is the definition of TPMA_NV_BIND from the TPM 2.0 specification:
TPMA_NV_BIND (BIT 17) If SET, the contents of the NV Index are bound to the platform hierarchy.

Ok, that sounds convincing. Where is it in the spec?

The definition of TPMA_NV_BIND is on page 126 of the TPM 2.0 specification, in section 9.7.1 "TPMA_NV".

Huh. Nope. Page 126 says nothing about this. Section 9.7.1 says nothing about this. The TPMA_NV bits are actually described on page 168 of volume 2 of the spec, in section 13.4. Bit 17 is TPMA_NV_OWNERREAD. TPMA_NV_BIND does not appear in the spec anywhere. I told the AI that.

I apologize for the error in my previous response. You are correct that the TPMA_NV_BIND attribute does not appear in the TPM 2.0 specification.

To bind an encryption key to the value of a TPM NV index, you can use the TPM2_NV_DefineSpace command with the TPMA_NV_BIND attribute.

I'm not afraid of being unemployed in the near future.

[1] "Platform Configuration Registers" - a modern TPM has 24 of these. When something security sensitive happens, you generate a hash of that event and pass it to the TPM. The TPM appends that to an existing PCR value and then hashes that concatenated value and sets the PCR to that. This means the PCR value depends not only on the values provided, but also the order they're provided in. Various TPM operations can be made conditional on the PCR values meeting specific criteria.

comments

FTP master This month I accepted 276 and rejected 27 packages. The overall number of packages that got accepted was 288. Debian LTS This was my hundred-second month that I did some work for the Debian LTS initiative, started by Raphael Hertzog at Freexian. This month my all in all workload has been 14h but due to Christmas I managed only to do 10h. During that time I uploaded:

• [DLA 3256-1] xorg-server security update for six CVEs
• [DLA 3255-1] mplayer security update for ten CVEs

Debian ELTS This month was the fifty third ELTS month. During my allocated time I marked all CVEs of the multipath-tools as not-affected and started to work on another snapd update. As I spend more time than expected with my family, I also failed to accomplish my ELTS workload. Last but not least I did some days of frontdesk duties. Debian Astro This month I uploaded improved packages or new versions of:

• openvlbi
• astap
• astap-cli
• planetary-system-stacker

I also updated almost all of the about 50 indi-3rdparty packages. Debian Mobcom This month I uploaded improved packages of:

• osmo-fl2k

Debian IoT This month I uploaded improved packages of:

• openzwave-controlpanel
• pywws

Debian Printing This month I uploaded improved packages of:

• ipp-usb

Other stuff This month I uploaded improved packages of:

• meep
• meep-openmpi
• meep-mpi-default
• pipexec
• libdontdie
• harminv
• chktex
• npd6
• mpb

Further I uploaded new versions of a bunch of golang packages.

I am old enough to remember when BPF meant the traditional Berkeley Packet Filter, and was confined to filtering network packets. It s grown into much, much, more as eBPF and getting familiar with it so that I can add it to the suite of tips and tricks I can call upon has been on my to-do list for a while. To this end I was lucky enough to attend a live walk through of bpftrace last year. bpftrace is a high level tool that allows the easy creation and execution of eBPF tracers under Linux. Recently I ve been working on updating the RetroArch packages in Debian and as I was doing so I realised there was a need to update the quite outdated retroarch-assets package, which contains various icons and images used for the user interface. I wanted to try and re-generate as many of the artefacts as I could, to ensure the proper source was available. However it wasn t always clear which files were actually needed and which were either source or legacy. So I wanted to trace file opens by retroarch and see when it was failing to find files. Traditionally this is something I d have used strace for, but it seemed like a great opportunity to try out bpftrace. It turns out bpftrace ships with an example, opensnoop.bt which provided details of hooking the open syscall entry + exit and providing details of all files opened on the system. I only wanted to track opens by the retroarch binary that failed, so I made a couple of modifications:

retro-failed-open-snoop.bt

#!/usr/bin/env bpftrace
/*
 * retro-failed-open-snoop - snoop failed opens by RetroArch
 *
 * Based on:
 * opensnoop	Trace open() syscalls.
 *		For Linux, uses bpftrace and eBPF.
 *
 * Copyright 2018 Netflix, Inc.
 * Licensed under the Apache License, Version 2.0 (the "License")
 *
 * 08-Sep-2018	Brendan Gregg	Created this.
 */
BEGIN
 
	printf("Tracing open syscalls... Hit Ctrl-C to end.\n");
	printf("%-6s %-16s %3s %s\n", "PID", "COMM", "ERR", "PATH");
 
tracepoint:syscalls:sys_enter_open,
tracepoint:syscalls:sys_enter_openat
 
	@filename[tid] = args->filename;
 
tracepoint:syscalls:sys_exit_open,
tracepoint:syscalls:sys_exit_openat
/@filename[tid]/
 
	$ret = args->ret;
	$errno = $ret > 0 ? 0 : - $ret;
	if (($ret <= 0) && (strncmp("retroarch", comm, 9) == 0) )  
		printf("%-6d %-16s %3d %s\n", pid, comm, $errno,
		    str(@filename[tid]));
	 
	delete(@filename[tid]);
 
END
 
	clear(@filename);
 

I had to install bpftrace (apt install bpftrace) and then I ran bpftrace -o retro.log retro-failed-open-snoop.bt as root and fired up retroarch as a normal user.

bpftrace failed open log for retroarch

Attaching 6 probes...
Tracing open syscalls... Hit Ctrl-C to end.
PID    COMM             ERR PATH
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/glibc-hwcaps/x86-64-v2/lib
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/tls/x86_64/x86_64/libpulse
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/tls/x86_64/libpulsecommon-
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/tls/x86_64/libpulsecommon-
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/tls/libpulsecommon-16.1.so
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/x86_64/x86_64/libpulsecomm
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/x86_64/libpulsecommon-16.1
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/pulseaudio/x86_64/libpulsecommon-16.1
3394   retroarch          2 /etc/gcrypt/hwf.deny
3394   retroarch          2 /lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/tls/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/tls/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/glibc-hwcaps/x86-64-v2/libgamemode.so
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/tls/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/tls/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/libgamemode.so.0
3394   retroarch          2 /lib/glibc-hwcaps/x86-64-v2/libgamemode.so.0
3394   retroarch          2 /lib/tls/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/tls/libgamemode.so.0
3394   retroarch          2 /lib/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/x86_64/libgamemode.so.0
3394   retroarch          2 /lib/libgamemode.so.0
3394   retroarch          2 /usr/lib/glibc-hwcaps/x86-64-v2/libgamemode.so.0
3394   retroarch          2 /usr/lib/tls/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/tls/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/tls/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/x86_64/libgamemode.so.0
3394   retroarch          2 /usr/lib/libgamemode.so.0
3394   retroarch          2 /lib/x86_64-linux-gnu/libgamemode.so
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/libgamemode.so
3394   retroarch          2 /lib/libgamemode.so
3394   retroarch          2 /usr/lib/libgamemode.so
3394   retroarch          2 /lib/x86_64-linux-gnu/libdecor-0.so
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/libdecor-0.so
3394   retroarch          2 /lib/libdecor-0.so
3394   retroarch          2 /usr/lib/libdecor-0.so
3394   retroarch          2 /etc/drirc
3394   retroarch          2 /home/noodles/.drirc
3394   retroarch          2 /etc/drirc
3394   retroarch          2 /home/noodles/.drirc
3394   retroarch          2 /usr/lib/x86_64-linux-gnu/dri/tls/iris_dri.so
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/glibc-hwcaps/x86-64-v2/libedit.so.
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/tls/x86_64/x86_64/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/tls/x86_64/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/tls/x86_64/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/tls/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/x86_64/x86_64/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/x86_64/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/x86_64/libedit.so.2
3394   retroarch          2 /lib/x86_64-linux-gnu/../lib/libedit.so.2
3394   retroarch          2 /etc/drirc
3394   retroarch          2 /home/noodles/.drirc
3394   retroarch          2 /etc/drirc
3394   retroarch          2 /home/noodles/.drirc
3394   retroarch          2 /etc/drirc
3394   retroarch          2 /home/noodles/.drirc
3394   retroarch          2 /home/noodles/.Xdefaults-udon
3394   retroarch          2 /home/noodles/.icons/default/cursors/00000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/default/index.theme
3394   retroarch          2 /usr/share/icons/default/cursors/000000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/default/cursors/0000000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/Adwaita/cursors/00000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/Adwaita/index.theme
3394   retroarch          2 /usr/share/icons/Adwaita/cursors/000000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/Adwaita/cursors/0000000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/hicolor/cursors/00000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/hicolor/index.theme
3394   retroarch          2 /usr/share/icons/hicolor/cursors/000000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/hicolor/cursors/0000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/hicolor/index.theme
3394   retroarch          2 /home/noodles/.XCompose
3394   retroarch          2 /home/noodles/.icons/default/cursors/00000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/default/index.theme
3394   retroarch          2 /usr/share/icons/default/cursors/000000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/default/cursors/0000000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/Adwaita/cursors/00000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/Adwaita/index.theme
3394   retroarch          2 /usr/share/icons/Adwaita/cursors/000000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/Adwaita/cursors/0000000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/hicolor/cursors/00000000000000000000000000
3394   retroarch          2 /home/noodles/.icons/hicolor/index.theme
3394   retroarch          2 /usr/share/icons/hicolor/cursors/000000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/hicolor/cursors/0000000000000000000000000000
3394   retroarch          2 /usr/share/pixmaps/hicolor/index.theme
3394   retroarch          2 /usr/share/libretro/assets/xmb/monochrome/png/disc.png
3394   retroarch          2 /usr/share/libretro/assets/xmb/monochrome/sounds
3394   retroarch          2 /usr/share/libretro/assets/sounds
3394   retroarch          2 /sys/class/power_supply/ACAD
3394   retroarch          2 /sys/class/power_supply/ACAD
3394   retroarch          2 /usr/share/libretro/assets/xmb/monochrome/png/disc.png
3394   retroarch          2 /usr/share/libretro/assets/ozone/sounds
3394   retroarch          2 /usr/share/libretro/assets/sounds

This was incredibly useful - the only theme image I was missing is disc.png from XMB Monochrome (which fails to have SVG source). I also discovered the runtime optional loading of GameMode. This is available in Debian so it was a simple matter to add libgamemode0 to the binary package Recommends. So, a very basic example of using bpftrace, but a remarkably useful intro to it from my point of view!

The diffoscope maintainers are pleased to announce the release of diffoscope version 231. This version includes the following changes: You find out more by visiting the project homepage.

When rebuilding mozc with Mozc UT Dictionary, it may be better to build in docker container because you don't want install unused IM development packages. In beforehand, download latest Mozc UT dictionary here. osdn.net In a debian/sid container, you need to do it:

# apt install -y devscripts
# (enable deb-src, modify /etc/apt/sources.list.d/debian.sources)
# apt source mozc
# cat mozcdic-ut-20221230/mozcdic-ut-20221230.txt >> mozc-2.28.4715.102+dfsg/src/data/dictionary_oss/dictionary00.txt 
# cd mozc-2.28.4715.102+dfsg/
# (edit debian/changelog such as 2.28.4715.102+dfsg-2.2.1 )
# debuild -us -uc -nc

After that, you can install

% sudo apt install ./emacs-mozc_2.28.4715.102+dfsg-2.2.1_amd64.deb ./emacs-mozc-bin_2.28.4715.102+dfsg-2.2.1_amd64.deb ./fcitx-mozc-data_2.28.4715.102+dfsg-2.2.1_all.deb ./fcitx5-mozc_2.28.4715.102+dfsg-2.2.1_amd64.deb ./ibus-mozc_2.28.4715.102+dfsg-2.2.1_amd64.deb ./mozc-data_2.28.4715.102+dfsg-2.2.1_all.deb ./mozc-server_2.28.4715.102+dfsg-2.2.1_amd64.deb ./mozc-utils-gui_2.28.4715.102+dfsg-2.2.1_amd64.deb

Then, you can use own build binaries.

% dpkg -l  \grep mozc
ii  emacs-mozc                               2.28.4715.102+dfsg-2.2.1               amd64        Mozc for Emacs
ii  emacs-mozc-bin                           2.28.4715.102+dfsg-2.2.1               amd64        Helper module for emacs-mozc
ii  fcitx-mozc-data                          2.28.4715.102+dfsg-2.2.1               all          Mozc input method - data files for fcitx
ii  fcitx5-mozc:amd64                        2.28.4715.102+dfsg-2.2.1               amd64        Mozc engine for fcitx5 - Client of the Mozc input method
ii  ibus-mozc                                2.28.4715.102+dfsg-2.2.1               amd64        Mozc engine for IBus - Client of the Mozc input method
ii  mozc-data                                2.28.4715.102+dfsg-2.2.1               all          Mozc input method - data files
ii  mozc-server                              2.28.4715.102+dfsg-2.2.1               amd64        Server of the Mozc input method
ii  mozc-utils-gui                           2.28.4715.102+dfsg-2.2.1               amd64        GUI utilities of the Mozc input method

Update: There's actually a more detailed writeup of this here that I somehow missed. Original entry follows:

Today I had to deal with a system that had an irritating restriction - a firmware configuration option I really wanted to be able to change appeared as a greyed out entry in the configuration menu. Some emails revealed that this was a deliberate choice on the part of the system vendor, so that seemed to be that. Thankfully in this case there was a way around that.

One of the things UEFI introduced was a mechanism to generically describe firmware configuration options, called Visual Forms Representation (or VFR). At the most straightforward level, this lets you define a set of forms containing questions, with each question associated with a value in a variable. Questions can be made dependent upon the answers to other questions, so you can have options that appear or disappear based on how other questions were answered. An example in this language might be something like:
CheckBox Prompt: "Console Redirection", Help: "Console Redirection Enable or Disable.", QuestionFlags: 0x10, QuestionId: 53, VarStoreId: 1, VarStoreOffset: 0x39, Flags: 0x0
In which question 53 asks whether console redirection should be enabled or disabled. Other questions can then rely on the answer to question 53 to influence whether or not they're relevant (eg, if console redirection is disabled, there's no point in asking which port it should be redirected to). As a checkbox, if it's set then the value will be set to 1, and 0 otherwise. But where's that stored? Earlier we have another declaration:
VarStore GUID: EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9, VarStoreId: 1, Size: 0xF4, Name: "Setup"
A UEFI variable called "Setup" and with GUID EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 is declared as VarStoreId 1 (matching the declaration in the question) and is 0xf4 bytes long. The question indicates that the offset for that variable is 0x39. Rewriting Setup-EC87D643-EBA4-4BB5-A1E5-3F3E36B20DA9 with a modified value in offset 0x39 will allow direct manipulation of the config option.

But how do we get this data in the first place? VFR isn't built into the firmware directly - instead it's turned into something called Intermediate Forms Representation, or IFR. UEFI firmware images are typically in a standardised format, and you can use UEFITool to extract individual components from that firmware. If you use UEFITool to search for "Setup" there's a good chance you'll be able to find the component that implements the setup UI. Running IFRExtractor-RS against it will then pull out any IFR data it finds, and decompile that into something resembling the original VFR. And now you have the list of variables and offsets and the configuration associated with them, even if your firmware has chosen to hide those options from you.

Given that a bunch of these config values may be security relevant, this seems a little concerning - what stops an attacker who has access to the OS from simply modifying these variables directly? UEFI avoids this by having two separate stages of boot, one where the full firmware ("Boot Services") is available, and one where only a subset ("Runtime Services") is available. The transition is triggered by the OS calling ExitBootServices, indicating the handoff from the firmware owning the hardware to the OS owning the hardware. This is also considered a security boundary - before ExitBootServices everything running has been subject to any secure boot restrictions, and afterwards applications can do whatever they want. UEFI variables can be flagged as being visible in both Boot and Runtime Services, or can be flagged as Boot Services only. As long as all the security critical variables are Boot Services only, an attacker should never be able to run untrusted code that could alter them.

In my case, the firmware option I wanted to alter had been enclosed in "GrayOutIf True" blocks. But the questions were still defined and the code that acted on those options was still present, so simply modifying the variables while still inside Boot Services gave me what I wanted. Note that this isn't a given! The presence of configuration options in the IFR data doesn't mean that anything will later actually read and make use of that variable - a vendor may have flagged options as unavailable and then removed the code, but never actually removed the config data. And also please do note that the reason stuff was removed may have been that it doesn't actually work, and altering any of these variables risks bricking your hardware in a way that's extremely difficult to recover. And there's also no requirement that vendors use IFR to describe their configuration, so you may not get any help here anyway.

In summary: if you do this you may break your computer. If you don't break your computer, it might not work anyway. I'm not going to help you try to break your computer. And I didn't come up with any of this, I just didn't find it all written down in one place while I was researching it.

comments

These are some notes about my redesign work in staticsite 2.x. Maping constraints and invariants I started keeping notes of constraints and invariants, and this helped a lot in keeping bounds on the cognitive efforts of design. I particularly liked how mapping the set of constraints added during site generation has helped breaking down processing into a series of well defined steps. Code that handles each step now has a specific task, and can rely on clear assumptions. Declarative page metadata I designed page metadata as declarative fields added to the Page class. I used typed descriptors for the fields, so that metadata fields can now have logic and validation, and are self-documenting! This is the core of the Field implementation. Lean core I tried to implement as much as possible in feature plugins, leaving to the staticsite core only what is essential to create the structure for plugins to build on. The core provides a tree structure, an abstract Page object that can render to a file and resolve references to other pages, a Site that holds settings and controls the various loading steps, and little else. The only type of content supported by the core is static asset files: Markdown, RestructuredText, images, taxonomies, feeds, directory indices, and so on, are all provided via feature plugins. Feature plugins Feature plugins work by providing functions to be called at the various loading steps, and mixins to be added to site pages. Mixins provided by feature plugins can add new declarative metadata fields, and extend Page methods: this ends up being very clean and powerful, and plays decently well with mypy's static type checking, too! See for example the code of the alias feature, that allows a page to declare aliases that redirect to it, useful for example when moving content around. It has a mixin (AliasPageMixin) that adds an aliases field that holds a list of page paths. During the "generate" step, when autogenerated pages can be created, the aliases feature iterates through all pages that defined an aliases metadata, and generates the corresponding redirection pages. Self-documenting code Staticsite can list loaded features, features can list the page subclasses that they use, and pages can list metadata fields. As a result, each feature, each type of page, and each field of each page can generate documentation about itself: the staticsite reference is autogenerated in that way, mostly from Feature, Page, and Field docstrings. Understand the language, stay close to the language Python has matured massively in the last years, and I like to stay on top of the language and standard library release notes for each release. I like how what used to be dirty hacks have now found a clean way into the language:

• what one would implement with metaclass magic one can now mostly do with descriptors, and get language support for it, including static type checking.
• understanding the inheritance system and method resolution order allows to write type checkable mixins
• runtime-accessible docstrings help a lot with autogenerating documentation
• os.scandir and os functions that accept directory file descriptors make filesystem exploration pleasantly fast, for an interpreted language!

debcargo rust repository and some observations. It's been about a week since I first started looking at Debian rust packages and adding some packages in preparation for crosvm. Some things that don't work quite well right now yet. My local branches disappeared. I don't have access and everything is through a merge request, presumably that is not a generally supported workflow and the team members are using branches to manage pending works. ./release.sh is optimized for updates and for new packages, they only build source packages and then I need to rebuild a binary-full package for the NEW queue. Maybe I will figure out. I haven't quite gotten the right IRC client. I was using the web UI but that seemed to disconnect without any warnings, and didn't tell me even when it is disconnected, it just can't post more messages and doesn't receive messages. That's not very useful. I started using Emacs IRC (rcirc) client. Not sure how useful that is.

In theory I wanted to announce the release of staticsite 2.0, but then I found bugs that prevented me from writing this post, so I'm also releasing 2.1 2.2 2.3 :grin: staticsite is the static site generator that I ended up writing after giving other generators a try. I did a big round of cleanup of the code, which among other things allowed me to implement incremental builds. It turned out that staticsite is fast enough that incremental builds are not really needed, however, a bug in caching rendered markdown made me forget about that. Now I fixed that bug, too, and I can choose between running staticsite fast, and ridiculously fast. My favourite bit of this work is the internal cleanup: I found a way to simplify the core design massively, and now the core and plugin system is simple enough that I can explain it, and I'll probably write a blog post or two about it in the next days. On top of that, staticsite is basically clean with mypy running in strict mode! Getting there was a great ride which prompted a lot of thinking about designing code properly, as mypy is pretty good at flagging clumsy hacks. If you want to give it a try, check out the small tutorial A new blog in under one minute.

Focus This month I didn't have any particular focus. I just worked on issues in my info bubble.

Changes

• devscripts: allow rmadison to query archived releases, unofficial ports
• debiman: update prerequisites
• reportbug: drop cruft, add tags based on subject
• debbugs: fix usertag validation
• Debian DDPO: better syntax error messages
• Debian madison: allow querying archived releases, unofficial ports
• Debian ftp-master website: typos
• Debian mirrors list: fix debian.co.il
• Debian mirror status: fix crash, debianbts usage
• Debian screenshots:
  • deleted pcscd (manual page), stockfish (actually of chess.com)
• Debian BTS usertags: fixed some security, porter, QA, FTP and website usertags
• Debian package uploads: crawl, git-remote-hg, azure-functions-devops-build
• Debian wiki pages: ArchiveQualification (riscv64 (1 2)), BuildProfileSpec, ContinuousIntegration (GUI, TUI), Cruft, DAManager, debconf, DebianIndia, DeveloperNews, FediverseTeam, InterWikiMap, KernelFAQ, Ketchup, LocalGroups, LoongArch, MemberBenefits, MiniDebConf, MIPS/UserTags, Ports (arc, ia64, loong64, riscv64), PortsDocs/New, PortTemplate, qa.debian.org/usertagging, ReleaseRecertification (jessie, stretch, wheezy), reportbug, ServicesHosting, Services/PublicUddMirror, SystemBuildTools, Teams (Debbugs/ArchitectureTags (1 2), DebianNet, ReleaseTeam/ReleaseCheckList), ungoogled-chromium

Issues

• Potential security issue in several Python programs (sent to the Debian Security Team).
• Crashes in Debian Portfolio service (sent privately), GLib
• Broken symlink in llvm-defaults
• Non-breaking-space chars in emacs-cmake-mode
• Features in lintian
• Warnings in pyvmomi
• Inaccurate data in UDD how-can-i-help
• Invalid syntax in rust-plotters
• Fork updated for git-remote-hg
• Conffile removal needed in zutils
• Alternatives removal needed in g++-mingw-w64-x86-64-win32
• Regression in pkgconf (vs pkg-config)
• Unsupported device in ddccontrol-db

Review

• Spam: reported 93 Debian mailing list posts
• Debian wiki: RecentChanges for the month
• Debian BTS usertags: changes for the month
• Debian screenshots:
  • approved ace-of-penguins acfax alacritty bfbtester cwm dolphin freefilesync kleopatra libpam-runtime logsave materia-gtk-theme mesa-utils netselect neverball python3-asdf python3-unyt stockfish xfig xfractint xfwm4
  • rejected pcscd (help output), orthanc (non-anonymised medical data), fonts-courier-prime (better existing screenshot), shutter (Windows, browser screenshot), bash (an editor), dwarves (random instagram account), alacritty (help output), xfonts-100dpi/goxel/gparted (selfie)

Administration

• Debian BTS: unarchive/reopen/triage bugs for reintroduced packages: gnome-shell-extension-no-annoyance
• Debian servers: contact mail server blocking a Debian MX
• Debian wiki: unblock IP addresses, approve accounts

Communication

• Respond to queries from Debian users and contributors on the mailing lists and IRC

Sponsors The azure-functions-devops-build work was sponsored. All other work was done on a volunteer basis.

Python: typing.overload typing.overload makes it easier to type functions with behaviour that depends on input types. Functions marked with @overload are ignored by Python and only used by the type checker: Python's multiprocessing and deadlocks Python's multiprocessing is prone to deadlocks in a number of conditions. In my case, the running program was a standard single-process, non-threaded script, but it used complex native libraries which might have been the triggers for the deadlocks. The suggested workaround is using set_start_method("spawn"), but when we tried it we hit serious performance penalties. Lesson learnt: multiprocessing is good for prototypes, and may end up being too hacky for production. In my case, I was already generating small python scripts corresponding to worker tasks, which were useful for reproducing and debugging Magics issues, so I switched to running those as the actual workers. In the future, this may come in handy for dispatching work to HPC nodes, too. Here's a parallel execution scheduler based on asyncio that I wrote to run them, which may always come in handy on other projects.

Happy New Year! For the last 13 years I've been using standalone versions of the Lenovo (formerly IBM) Thinkpad keyboard design with integrated trackpoint as my main computer input devices. My latest ("ThinkPad TrackPoint Keyboard II") was starting to fail so I decided to look into alternatives for a replacement. The sticking point was I really like the trackpoint as a mouse replacement, and very few other manufacturers offer that. I've thus far managed to avoid the money pit that are mechanical keyboards. I can see the attraction: in the 90s I used an IBM Model M PS/2 keyboard as my daily driver until one tea spillage too many finally killed it. A friend kindly gifted me another Model M more recently, but the buckled-spring technology it uses is too loud for use in a public office, and the resistance too strong for my modern fingers. The latter could perhaps be fixed with training. But still: no trackpoint. (less importantly, no Windows keys.) In anticipation of possibly getting a mechanical keyboard, I bought a passive 12 key "tester": 12 keyboard switches of different variants inside a perspex frame. This gives you a rough idea of the feel of each switch type, to try and narrow down what your personal preference might be. At the beginning I imagined I'd like something clicky and stiff, like the buckled springs (and the Cherry MX Green was closest to that), but I was gravitating more towards the more common MX Red (popular with gamers) and MX Brown (popular with typists). I wasn't totally sure yet so I decided to buy a sacrificial mechanical keyboard to test a switch type properly. I managed to find a second-hand one for 20 with brown switches. It was a bad layout (ANSI) which detracted from its use but was a useful exercise: I decided I didn't really like the Browns that much! It seems 13 years with scissor switches have softened me up so that I want very little resistance on my keys. So. most likely, MX Reds. Tex Shinobi A small Taiwanese company, Tex, produce a series of mechanical keyboards very openly inspired by the IBM/Lenovo trackpoint models that I've been using for so long, complete with trackpoints. I'd been eyeing up their Tex Yoda II keyboard for some time, which looks great, very minimalistic, but in practise I do use the keys it omits, and it's pricey. I decided to take the plunge and buy a more key-ful and reasonably priced Tex Shinobi ISO/UK layout, and I opted for Cherry MX Silent Red switches. Silent to give me the option of using in the Newcastle office, but also to reduce the risk of waking up the kids at home. The Silent Reds are a bit "squishier" than raw Reds which is a shame, but not enough of an obstacle to typing rapidly. The keyboard shape and layout is a close clone of the old IBM Ultranav keyboards I used to use so I was at home on it straight away. The real unknown quantity to me was how well the trackpoint works. I'd read mixed responses, but it's not clear that the people reviewing it were very familiar with the Lenovo ones. I am pleased to report that it's indistinguishable to the Lenovo one to me (and I used that a lot). The keyboard came in a funky replica Thinkpad box and with some keycap and trackpoint pointer options. I opted for a yellow "hat" shaped trackpoint cover (to appease my yellow-obsessed youngest daughter) and the blue IBM-style Enter keycap. Future I don't need any more keyboards! Unless I break this one. But in writing this I did notice that they are taking pre-orders on a new model Shura which seems to be halfway between the Yoda II and Shinobi. I imported the Shinobi from Tex direct (incurring the corresponding duty cost) but next time I might look for a UK distributor such as https://www.keyboardco.com/.

In May 2014 I bought a Samsung Galaxy Note 10.1 2014 edition tablet (wikipedia page [1]) with 32G of RAM. It s display is 2560 1600 resolution which still compares well to the latest tablets. The Galaxy Tab S8 [2] is the latest high-end tablet series from Samsung and the 11 inch tablet in that series also has a 2560 1600 giving it a slightly lower DPI! The latest series also has 12.4 and 14.6 tablets with resolutions of 2800 1752 and 2960 1848 respectively. Obviously if you want a 14 tablet then the latest offerings are good, but if you want a 10 or 11 tablet then Samsung hasn t improved much. The Note 10.1 has 3G of RAM and a choice of 16G, 32G, or 64G of storage. The latest Tab S8 tablets have 8G to 16G of RAM and 128G to 512G of internal storage, which are great if you need such things. For many tasks 3G of RAM is quite adequate and as I chose the 32G model I haven t had a problem with storage. The s-pen is a feature of this tablet which is also on the latest high-end Samsung tablets, it is useful for accessing small elements in web sites designed for desktop use and for graphics editing. One noteworthy feature of this tablet is the fact that when in landscape orientation it has speakers on each side, which is the correct layout as the vast majority of video with stereo sound is in a landscape orientation. After using that tablet for about 4 years I bought myself a newer tablet and gave it to my wife. She has since passed it on to another relative who is using it regularly. That tablet seems to have lasted well still being quite usable when it s almost 9 years old. The price including delivery was $579, that works out to about $1.30 per week (disregarding interest and inflation). According to the Reserve Bank of Australia inflation calculator [3] $579 in 2014 is equivalent to $652 in 2021, they don t have results for later than 2021 so I ll assume it would be $675 in 2023. Currently the main problems with this tablet are lack of USB-C support (which means it s difficult to connect to an external display among other things) and lack of a recent version of Android, 4.4.2 was the latest OTA update available. The XDA Developers forum has a section for this tablet [4] which includes discussion of updates to Android 5.x for devices which didn t get it automatically and for upgrading to very recent Android versions in LineageOS. I m idly considering one of those options, but for the current user the Google Play store is a requirement. Newer Samsung Tablets The current equivalent Samsung tablet is the Galaxy Tab S8 which is currently being sold for $1055 which is 56% higher than the inflation adjusted price of my tablet. I don t think this is reasonable given that I bought it 7 months after release and it s now 11 months since the release of the Tab S8. The Tab S8 has more RAM, more storage, and a faster CPU due to improvements over the entire computer industry replacing old parts with newer versions of the same things (including changing to USB-C) doesn t justify a price rise. Increasing RAM size by a factor of 3-5 and increasing storage by a factor of 8 over the last 9 years doesn t match the industry trends for PCs, also as an aside my latest laptop only has 8G of RAM and works well for much more demanding tasks. The Tab S8 series also has significantly better cameras, but I don t think that s a big deal, the 2Mp front camera in my tablet can provide adequate quality for video conferencing and usually saturate the upload bandwidth and again that s an issue of the entire industry moving to newer hardware. I don t think it s bad to take a form factor and display that works well and put newer versions of the CPU, RAM, storage, cameras, and OS on it. But asking for 56% more money for the updated tablet seems unreasonable. The current S8 Ultra is going for $1760 and the S8+ is $1479. I think those are ridiculous prices for tablets as there is a decent range of new laptops that are cheaper. I believe that the purpose of a tablet is to be easy to carry and quick to start using (no waiting for a laptop to connect to wifi after leaving suspend). The largest of the S8 Tabs is about the same length and width as a Thinkpad X1 Carbon with the benefits being that it s thinner and lighter, but if you got a tablet case with keyboard then it would be thicker and heavier. The S8 seems like bad value for money and the S8+ and S8 Ultra don t seem to compare well to laptops and Chromebooks with touch screens unless you have a specific need for Android tablet apps. If Samsung are going to just make new tablets without any significant improvements other than refreshing to the latest CPU, RAM, storage, and Camera technology and force users to upgrade via a lack of new OS support then they shouldn t charge so much. Stick well below $1000 and people will be more inclined to replace items, expensive items are expected to last. Conclusion Buying this tablet was definitely a good choice. It has performed well for many years and after a couple of years of light use it s back in daily use again. The value for money it offered was significantly greater than newer tablets, when it was new it was really high-end, the current S8 Tab series of tablets aren t anything special when compared to other tablets.

• [1] https://en.wikipedia.org/wiki/Samsung_Galaxy_Note_10.1_2014_Edition
• [2] https://en.wikipedia.org/wiki/Samsung_Galaxy_Tab_S8
• [3] https://www.rba.gov.au/calculator/annualDecimal.html
• [4] https://forum.xda-developers.com/c/samsung-galaxy-note-10-1-2014-edition.2500/

So, it s this weird time of year where we make a balance and share with the world some ideas about the future. And yes, it s time to take care of this blog, as its activity has dropped once again. So maybe it d be nice to start this post by checking how much have I blogged over the years:

• 2004: 27
• 2005: 92
• 2006: 65
• 2007: 83
• 2008: 64
• 2009: 62
• 2010: 48
• 2011: 25
• 2012: 27
• 2013: 29
• 2014: 37
• 2015: 18
• 2016: 19
• 2017: 20
• 2018: 19
• 2019: 19
• 2020: 14
• 2021: 11
• 2022: 10

(yes, this is an old blog) So yes, there is a clear downwards trend towards the last few years. And it does make sense, all in all: Not only have I managed to keep myself busier than before, but Blogging is a social endeavor. And as people have moved over to the different flavors of social networks, there is somewhat less fueling us to share our thoughts and experiences in this fashion. So this connects me to my first point: Staring at Noodles Emptiness, I got to a campaign to Bring Back Blogging. I stand by all of what they suggest: Blogs are a great invention, they allow the sharing of a great insight into a person s mind, ideas and worldview (and even more so if, like mine, it shows already a window of almost two decades of life! This year my blog will be old enough to vote!), they are completely decentralized, and can be easily grouped according to each readers preferences via the RSS format. Anyway I do want to write a post summing up 2022, as well as sharing some hopes and projects I have for 2023. But I don t want to make it too long to read. So That shall be the blog post for today! (post caption image by Walt Stoneburner on Flickr; CC BY 2.0)