Review: A Matter of Execution, by Nicholas & Olivia Atwater
Series:
Tales of the Iron Rose #0
Publisher:
Starwatch Press
Copyright:
2024
ISBN:
1-998257-08-8
Format:
Kindle
Pages:
131
A Matter of Execution is the introductory novella that kicked off the Tales of the Iron Rose series. It is steampunk fantasy with airships. I previously read and reviewed the subsequent novel, Echoes of the Imperium.
As noted in that review, I read the novel first. That was a mistake; this is a much better place to start. A Matter of Execution was clearly intended as the introduction of all of these characters. More importantly, I think reading the novella first would have given me enough affinity with the characters to not mind the worst part of Echoes of the Imperium: the extremely slow first half that seemed filled with the protagonist's impostor syndrome.
A Matter of Execution opens, fittingly, with Captain William Blair, a goblin, former Imperial soldier, Oathbreaker, and series first-person protagonist being carted to his execution. He is not alone; in the same prison wagon is an arrogant (and racist) man named Strahl, the killer of one of the rulers of Lyonesse.
Strahl is rather contemptuous of Blair's claim to be a captain, given that he's both a goblin and an Oathbreaker. Strahl quickly revises that opinion when Blair's crew, somewhat predictably given that he is the series protagonist, creates a daring escape for both of them. The heat of action gives both a chance to gain some respect for the other, which explains why Blair is not only willing to invite Strahl to join his crew, but to go back for Strahl's companion.
Breaking out Strahl's companion will be a more difficult, and surprising, problem.
Nicholas Atwater is a role-playing game GM, something that you will learn the "about the author" section at the end of this novella but probably will have guessed by then. Even more than Echoes of the Imperium, this novella feels like a (good) write-up of an RPG adventure. A wildly varied cast of characters come together and form a party with a well-defined objective that has some surrounding mysteries and surprises. Each of those characters get their individual moments to show off their specific skills. Readers with a certain gaming background will know exactly where to insert the Borderlands-style title card with a slightly demented description of each character.
This is not a complaint. You may be able to see the bones of the setup adventure for a long-running campaign, but I like this style of character introduction and the story moves right along. There are a ton of varied characters, some interesting villains and maybe-villains, a rather satisfying heist setup, and some good chemistry and a bit of banter. This is not a deep story - it's clearly an introductory episode for both the characters and the world background - but it's a fun way to spend a few hours.
I think the best part of this series is the world-building. If you have read my review of Echoes of the Imperium, you have unfortunately been mildly spoiled for the revelation in this novella. I don't think it hurt the story that much; you will be able to predict what obvious gaps in the novel backstory the novella is going to fill in, but it's just as enjoyable to see how that happens. But the Atwaters aren't going to drop any of the big world-building bombs in the introductory novella, of course. Instead, you get a gradual introduction to the nature of magic in this world, some of the political setup of the recent war, and a quick introduction to the capabilities of Strahl's mysterious companion.
If you've not yet read this series, I recommend starting here. It's a quick investment to see if you'll be interested. The novel is heavier and slower, and the pacing of the first half isn't great, but the world-building is even better.
If you've already read the novel, this is still worth reading as long as you enjoyed it. You'll have a few moments of "oh, that's how that happened," and it's a fun and fast-moving way to spend a bit more time with the characters.
Followed by Echoes of the Imperium. The back matter of the novella says that The Winds of Fortune is supposedly forthcoming.
I started writing this post while using the band from a Colmi P80 [3]. I bought one for a relative who wanted the metal band and the way the Aliexpress seller does it is to sell the package with the plastic band and include the metal band in the package so I had a spare band. It fits quite well and none of the reported problems of the PineTime having insufficient space between the spring bar and the watch. The Colmi band in question is described as "rose gold" but is more like "pinkish beige" and doesn't match the style of the black PineTime.
I ordered a couple of cheap bands from AliExpress which cost $9.77 and $13.55 including postage while the ones that Pine64 recommend have over $15 postage from Amazon!
There are claims that getting a replacement band for a PineTime is difficult. My experience is that every band with a 20mm attachment works as long as it's designed for a square watch, some of the bands are designed to partly go around a round face and wouldn't fit. I expect that some bands won't fit, but I don't think that it's enough of a problem to be worried about buying a random band from AliExpress. The incidence of bands not fitting will probably be lower than the incidence of other AliExpress products not doing quite what you want (while meeting the legal criteria of doing what they are claimed to do) and not being used.
I'm now wearing the PineTime with the "Magnetic Buckle Watch Strap Band" and plan to wear it for the next year or so.
A few years ago I wrote some planner generating code to make myself a custom planner; in November 2023 I generated a few, and posted them here on the blog, in case somebody was interested in using them.
In 2024 I tried to do the same, and ended up being even more late, to the point where I didn't generate any (uooops).
I did, however, start to write a Makefile to automate the generation (and got stuck on the fact that there wasn't an easy way to deduce the correct options needed from just the template name); this year, with the same promptness as in 2023 I got back to the Makefile and finished it, so maybe next year I will be able to post them early enough for people to print and bind them? maybe :)
Anyway, these are all of the variants I currently generate, for 2026.
The files with -book in the name have been imposed on A4 paper for a 16 pages signature. All of the fonts have been converted to paths, for ease of printing (yes, this means that customizing the font requires running the script, but the alternative also had its drawbacks).
Some of the planners include ephemerids and moon phase data: these have been calculated for the town of Como, and specifically for geo:45.81478,9.07522?z=17, because that's what everybody needs, right?
If you need the ephemerids for a different location and can't run the script yourself (it depends on pdfjam, i.e. various GB of LaTeX, and a few python modules such as dateutil, pypdf and jinja2), feel free to ask: unless I receive too many requests to make this sustainable I'll generate them and add them to this post.
I hereby release all the PDFs linked in this blog post under the CC0 license.
You may notice that I haven't decided on a license for the code dump repository; again if you need it for something (that is compatible with its unsupported status) other than running it for personal use (for which afaik there is an implicit license) let me know and I'll push "decide on a license" higher on the stack of things to do :D
Finishing the Makefile meant that I had to add a tiny feature to one of the scripts involved, which required me to add a dependency to pypdf: up to now I have been doing the page manipulations with pdfjam, which is pretty convenient to use, but also uses LaTeX, and apparently not every computer comes with texlive installed (shocking, I know).
If I'm not mistaken, pypdf can do all of the things I'm doing with pdfjam, so maybe for the next year I could convert my script to use that one instead.
But then the planners 2027 will be quick and easy, and I will be able to publish them promptly, right?
Another maintenance release of the tidyCpp package arrived on CRAN this morning, the first in about two years. The packages offers a clean C++ layer (as well as one small C++ helper class) on top of the C API for R which aims to make use of this robust (if awkward) C API a little easier and more consistent. See the (now updated, see below) vignette for motivating examples.
This release contains mostly internal upkeep of the usual type: refreshing continuous integration, updating links, switching to Authors@R. But as we wrap the C API of R here too, changes made in R-devel this week affected the two reverse-dependencies (i.e. "downstream") packages (of mine) using this. So we commented-out the definitions for the five now-hidden accessors so that these downstream packages can build again under R-devel.
The NEWS entry follows.
Changes in tidyCpp version 0.0.8 (2025-11-25)
Updated continuous integration setup several times
Updated README.md documentation with link to R API site
Updated example snippets to use of Protect
Updated documentation in defines.h header
Updated internals.h header reflecting in R API changes
As it happens, hours after the release at CRAN a helpful issue ticket was opened detailing more than a handful of typos in the vignette. This has been corrected, and I am not exporting the vignette via GitHub Pages so the motivating examples vignette contains the corrections.
This post covers many attempts to try and get the TV to work correctly and it doesn't have good answers. The best answer might be to not buy Hisense devices but I still lack data.
Attempts to Force 8K
I posted on Lemmy again about this [3] and got a single response, which is OK as it was a good response. They didn't give me the answer on a silver platter but pointed me in the right direction of EDID [4].
I installed the Debian packages read-edid, wxedid, and edid-decode.
The command "get-edid > out.edid" saves the binary form of the edid to a file. The command "wxedid out.edid" allows graphical analysis of the EDID data. The command "edid-decode out.edid" dumps a plain text representation of the output, the command "edid-decode out.edid|grep VIC|cut -d: -f2|sort -n" shows an ordered list of video modes, in my case the highest resolution is 4096×2160 which is the highest that Linux had allowed me to set with two different video cards and a selection of different cables (both HDMI and DisplayPort).
At this time I don't know how much of this is due to the video card and how much is due to the TV. The parameters for xrandr came from a LLM because I couldn't find any Google results on what 8K parameters to use. As an aside if you have a working 8K TV or monitor connected to a computer please publish the EDID data, xrandr, and everything else you can think of.
I found a Github repository for EDID data [5] but that didn't have an entry for my TV and didn't appear to have any other entry for an 8K device I could use.
Resolution for Web Browsing
I installed a browser on the TV, Chrome and Firefox aren't available for a TV and the Play Store program tells you that (but without providing a reason) when you search for them. I tried the site CodeShack What is my Screen Resolution [6] which said that my laptop is 2460*1353 while the laptop display is actually 2560*1440. So apparently I have 100 pixels used for the KDE panel at the left of the screen and 87 pixels used by the Chrome tabs and URL bar - which seems about right. My Note 9 phone reports 384*661 out of it's 2960*1440 display so it seems that Chrome on my phone is running web sites at 4/15 of the native resolution and about 16% of the height of the screen is used by the system notification bar, the back/home/tasklist buttons (I choose buttons instead of swipe for navigation in system settings), and the URL bar when I have "Screen zoom" in system settings at 1/4. When I changed "Screen zoom" to 0/4 the claimed resolution changed to 411*717 (2/7 of the native resolution). Font size changes didn't change the claimed resolution. The claimed "Browser Viewport Size" by CodeShack is 1280*720 which is 1/6 of the real horizontal resolution and slightly more than 1/6 of the vertical resolution, it claims that the Pixel Density is 2* and a screen resolution of 970*540 which means to imply that the browser is only working at 1920*1080 resolution!
Netflix
When I view Netflix shows using the Netflix app running on the TV is reports "4K" which doesn't happen on Linux PCs (as they restrict 4K content to platforms with DRM) and in the "Device" setting it reports "Device Model" as "Hisense_SmartTV 8K FFM" so the Netflix app knows all about 4K content and knows the text string "8K".
YouTube
When I view a YouTube video that's described as being 8K I don't get a request for paying for YouTube Premium which is apparently what happens nowadays when you try to play actual 8K video. I turn on "State for Nerds" and one line has "Viewport / Frames 1920×1080*2.00" and another has "Current / Optimal Res 3840×2160@60 / 3840×2160@60" so it seems that the YouTube app is seeing the screen as 4K but choosing to only display FullHD even when I have Quality set to "2160p60 HDR". It declares the network speed to be over 100mbit most of the time and the lowest it gets is 60mbit while 50mbit is allegedly what's required for 8K.
I installed a few Android apps to report hardware capabilities and they reported the screen resolution to be 1920*1080.
Have I Been Ripped Off?
It looks like I might have been ripped off by this. I can't get any app other than Netflix to display 4K content. My PC will only connect to it at 4K. Android apps (including YouTube) regard it as 1920*1080.
The "AI Upscaling" isn't really that great and in most ways it seems at best equivalent to a 4K TV and less than a 4K TV that runs Android apps with an actual 4K display buffer.
Next Steps
The next things I plan to do are to continue attempts to get the TV to do what it's claimed to be capable of, either an Android app that can display 8K content or a HDMI input of 8K content will do. Running a VNC client on the TV would be an acceptable way of getting an 8K display from a Linux PC.
I need to get a somewhat portable device that can give 8K signal output. Maybe a mini PC with a powerful GPU or maybe one of those ARM boards that's designed to drive an 8K sign. Then I can hunt for stores that have 8K TVs on display.
It would be nice if someone made a USB device that does 8K video output - NOT a USB-C DisplayPort alternative mode that uses the video hardware on the laptop. Then I could take a laptop to any place that has an 8K display to show and connect my laptop to it.
The one thing I haven't done yet is testing 8K MP4 files on a USB stick. That's mainly due to a lack of content and the fact that none of the phone cameras I have access to can do 8K video. I will try displaying 8K PNG and JPEG files from a USB stick.
Most people would give up about now. But I am determined to solve this and buying another large TV isn't out of the question.
By default, the color mode is selected depending on the user browser preferences. If explicitly selected, we use a cookie to store the theme selection so that a user can choose different color modes in different browsers.
First is a simple view to configure the selected theme and store it in a cookie. If auto is selected, then the cookie is deleted to delegate theme selection to JavaScript:
class ThemeSelectionView(View):
"""Select and save the current theme."""
def post(
self, request: HttpRequest, *args: Any, **kwargs: Any # noqa: U100
) -> HttpResponse:
"""Set the selected theme."""
value = request.POST.get("theme", "auto")
next_url = request.POST.get("next", None)
if next_url is None:
next_url = reverse("homepage:homepage")
response = HttpResponseRedirect(next_url)
if value == "auto":
response.delete_cookie("theme")
else:
response.set_cookie(
"theme", value, httponly=False, max_age=dt.timedelta(days=3650)
)
return response
The base template will use this value to set data-bs-theme on the main <html> element, and that's all that is needed to select the color mode in Bootstrap:
<html lang="en"{% if theme %} data-bs-theme="{{ theme }}"{% endif %}>
The view uses HTTP POST as it changes state, so theme selection happens in a form:
Since we added the theme selection buttons in the footer, we use CSS to render the buttons in the same way as the rest of the footer links.
Bootstrap has a set of CSS variables that can be used to easily in sync with the site theme, and they are especially useful now that the theme is configurable:
{% if not theme %}
<script blocking="render">
(function() {
let theme = window.matchMedia('(prefers-color-scheme: dark)').matches ? 'dark' : 'light';
let [html] = document.getElementsByTagName("html");
html.setAttribute("data-bs-theme", theme);
})();
</script>
{% endif %}
This reads the color scheme preferences and sets the data-bs-theme attribute on <html>.
The script is provided inline as it needs to use blocking="render" to avoid flashing a light background at the beginning of page load until the attribute is set.
Given that this is a render-blocking snippet, as an extra optimization it is not added to the page if a theme has been set.
Bootstrap CSS fixes
We were making use of the bootstrap btn-light class in navbars to highlight elements on hover, and that doesn't work well with theme selection.
Lacking a button class that does the right thing across themes, we came up with a new CSS class that uses variables to define a button with hover highlight that works preserving the underlying color:
This was a nice integration exercise with many little tricks, like how to read color scheme preferences from the browser, render form buttons as links, use bootstrap variables, prevent a flashing background, handle cookies in Django.
A minor release of RcppQuantuccia arrived on CRAN moments ago. RcppQuantuccia started from the Quantuccia header-only subset / variant of QuantLib which it brings it to R. This project validated the idea of making the calendaring functionality of QuantLib available in a more compact and standalone project - which we now do with qlcal which can be seen as a successor package to this earlier package. qlcal tracks QuantLib (releases) closely and provides approximately quarterly updates. Switching to using qlcal is generally recommended.
This release, the first in almost exactly two years, only updates internals (as detailed below). Notably it switches to 'Authors@R' to avoid a nag from CRAN on two platforms. The complete list changes for this release follows.
Changes in version 0.1.3 (2025-11-24)
A badge URL and link have been updated in README.md
The continuous integration sript switched first to r-ci-setup and then to the r-ci action with embedded setup
Armadillo is a powerful and expressive C++ template library for linear algebra and scientific computing. It aims towards a good balance between speed and ease of use, has a syntax deliberately close to Matlab, and is useful for algorithm development directly in C++, or quick conversion of research code into production environments. RcppArmadillo integrates this library with the R environment and language-and is widely used by (currently) 1286 other packages on CRAN, downloaded 42.6 million times (per the partial logs from the cloud mirrors of CRAN), and the CSDA paper (preprint / vignette) by Conrad and myself has been cited 659 times according to Google Scholar.
This versions updates to the 15.2.2 upstream Armadillo release made two days ago. It brings a few changes over the RcppArmadillo 15.2.0 release made only to GitHub (and described in this post), and of course even more changes relative to the last CRAN release described in this earlier post. As described previously, and due to both the upstream transition to C++14 coupled with the CRAN move away from C++11, the package offers a transition by allowing packages to remain with the older, pre-15.0.0 'legacy' Armadillo yet offering the current version as the default. During the transition we did not make any releases to CRAN allowing both the upload cadence to settle back to the desired 'about six in six months' that the CRAN Policy asks for, and for packages to adjust to any potential changes. Most affected packages have done so (as can be seen in the GitHub issues #489 and #491) which is good to see. We appreciate all the work done by the respective package maintainers. A number of packages are still under a (now formally expired) deadline at CRAN and may get removed. Our offer to help where we can still stands, so please get in touch if we can be of assistance. As a reminder, the meta-issue #475 regroups all the resources for the transition.
With respect to changes in the package, we once more overhauled the OpenMP detection and setup, following the approach take by package data.table but sticking with an autoconf-based configure. The detailed changes since the last CRAN release follow.
Changes in RcppArmadillo version 15.2.2-1 (2025-11-21)
Upgraded to Armadillo release 15.2.2 (Medium Roast Deluxe)
Improved reproducibility of random number generation when using OpenMP
Skip a unit test file under macOS as complex algebra seems to fail under newer macOS LAPACK setting
Further OpenMP detection rework for macOS (Dirk in #497, #499)
Define ARMA_CRIPPLED_LAPACK on Windows only if 'LEGACY' Armadillo selected
Changes in RcppArmadillo version 15.2.1-0 (2025-10-28) (GitHub Only)
Upgraded to Armadillo release 15.2.1 (Medium Roast Deluxe)
Faster handling of submatrices with one row
Improve OpenMP detection (Dirk in #495 fixing #493)
Changes in RcppArmadillo version 15.2.0-0 (2025-10-20) (GitHub Only)
Upgraded to Armadillo release 15.2.0 (Medium Roast Deluxe)
Added rande() for generating matrices with elements from exponential distributions
shift() has been deprecated in favour of circshift(), for consistency with Matlab/Octave
Reworked detection of aliasing, leading to more efficient compiled code
Transferring a Signal account between two Android devices
I spent far too much time recently trying to get a Signal Private Messenger account to transfer from one device to another.
What I eventually found worked was a very finicky path to enable functioning "Wi-Fi Direct", which I go into below.
I also offer some troubleshooting and recovery-from-failure guidance.
All of this blogpost uses "original device" to refer to the Android pocket supercomputer that already has Signal installed and set up, and "new device" to mean the Android device that doesn't yet have Signal on it.
Why Transfer?
Signal Private Messenger is designed with the expectation that the user has a "primary device", which is either an iPhone or an Android pocket supercomputer.
If you have an existing Signal account, and try to change your primary device by backing up and restoring from backup, it looks to me like Signal will cause your long-term identity keys to be changed. This in turn causes your peers to see a message like "Your safety number with Alice has changed."
These warning messages are the same messages that they would get if an adversary were to take over your account. So it's a good idea to minimize them when there isn't an account takeover - false alarms train people to ignore real alarms.
You can avoid "safety number changed" warnings by using signal's "account transfer" process during setup, at least if you're transferring between two Android devices.
However, my experience was that the transfer between two Android devices was very difficult to get to happen at all. I ran into many errors trying to do this, until I finally found a path that worked.
Dealing with Failure
After each failed attempt at a transfer, my original device's Signal installation would need to be re-registered. Having set a PIN meant that i could re-register the device without needing to receive a text message or phone call.
Set a PIN before you transfer!
Also, after a failure, you need to re-link any "linked device" (i.e. any Signal Desktop or iPad installation). If any message came in during the aborted transfer, the linked device won't get a copy of that message.
Finally, after a failed transfer, i recommend completely uninstalling Signal from the new device, and starting over with a fresh install on the new device.
Permissions
My understanding is that Signal on Android uses Wi-Fi Direct to accomplish the transfer. But to use Wi-Fi Direct, Signal needs to have the right permissions.
On each device:
Entirely stop the Signal app
Go to Settings » Apps » Signal » Permissions
Ensure that the following permissions are all enabled whenever the app is running:
Location
Nearby Devices
Network
Preparing for Wi-Fi Direct
The transfer process depends on "Wi-Fi Direct", which is a bit of a disaster on its own.
I found that if i couldn't get Wi-Fi Direct to work between the two devices, then the Signal transfer was guaranteed to fail.
So, for clearer debugging, i first tried to establish a Wi-Fi Direct link on Android, without Signal being involved at all.
Setting up a Wi-Fi Direct connection directly failed, multiple times, until i found the following combination of steps, to be done on each device:
Turn off Bluetooth
Ensure Wi-Fi is enabled
Disconnect from any Wi-Fi network you are connected to (go to the "Internet" or "Wi-Fi" settings page, long-press on the currently connected network, and choose "Disconnect"). If your device knows how to connect to multiple local Wi-Fi networks, disconnct from each of them in turn until you are in a stable state where Wi-Fi is enabled, but no network is connected.
Close to the bottom of the "Inteernet" or "Wi-Fi" settings page, choose "Network Preferences" and then "Wi-Fi Direct"
if there are any entries listed under "Remembered groups", tap them and choose to "Forget this group"
If there are Peer devices that say "Invited", tap them and choose to "Cancel invitation"
I found that this configuration is the most likely to enable a successful Wi-Fi Direct connection, where clicking "invite" on one device would pop up an alert on the other asking to accept the connection, and result in a "Connected" state between the two devices.
Actually Transferring
Start with both devices fully powered up and physically close to one another (on the same desk should be fine).
On the new device:
Reboot the device, and log into the profile you want to use
Enable Internet access via Wi-Fi.
Remove any old version of Signal.
Install Signal, but DO NOT OPEN IT!
Set up the permissions for the Signal app as described above
Open Signal, and choose "restore or transfer" -- you still need to be connected to the network at this point.
The new device should display a QR code.
On the original device:
Reboot the device, and log into the profile that has the Signal account you're looking to transfer
Enable Internet access via Wi-Fi, using the same network that the old device is using.
Make sure the permissions for Signal are set up as described above
Open Signal, and tap the camera button
Point the camera at the new device's QR code
Now tap the "continue" choices on both devices until they both display a message that they are searching for each other. You might see the location indicator (a green dot) turn on during this process.
If you see an immediate warning of failure on either device, you probably don't have the permissions set up right.
You might see an alert (a "toast") on one of the devices that the other one is trying to connect. You should click OK on that alert.
In my experience, both devices are likely to get stuck "searching" for each other. Wait for both devices to show Signal's warning that the search has timed out.
At this point, leave Signal open on both devices, and go through all the steps described above to prepare for Wi-Fi Direct. Your Internet access will be disabled.
Now, tap "Try again" in Signal on both devices, pressing the buttons within a few seconds of each other. You should see another alert that one device is trying to connect to the other. Press OK there.
At this point, the transfer should start happening! The old device will indicate what percentag has been transferred, and the new device will indicate how many messages hav been transferred.
When this is all done, re-connect to Wi-Fi on the new device.
Temporal gap for Linked Devices
Note that during this process, if new messages are arriving, they will be queuing up for you.
When you reconnect to wi-fi, the queued messages will flow to your new device. But the process of transferring automatically unlinks any linked devices. So if you want to keep your instance of Signal Desktop with as short a gap as possible, you should re-link that installation promptly after the transfer completes.
Clean-up
After all this is done successfully, you probably want to go into the Permissions settings and turn off the Location and Nearby Devices permissions for Signal on both devices.
I recommend also going into Wi-Fi Direct and removing any connected devices and forgetting any existing connections.
Conclusion
This is an abysmally clunky user experience, and I'm glad I don't have to do it often. It would have been much simpler to make a backup and restore from it, but I didn't want to freak out my contacts with a safety number change.
By contrast, when i wanted extend a DeltaChat account across two devices, the transfer was prompt and entirely painless -- i just had to make sure the devices were on the same network, and then scanned a QR code from one to the other. And there was no temporal gap for any other deviees. And i could use Delta on both devices simultaneously until i was convinced that it would work on the new device -- Delta doesn't have the concept of a primary account.
I wish Signal made it that easy! Until it's that easy, i hope the processes described here are useful to someone.
Well, you are right, you can't. At least not directly. This is well documented in many projects relying on interposing binaries, like faketime.
But what if we could write something that would take a static binary, replace at least the direct syscalls with ones going through libc and load it with the dynamic linker? We are in luck, because the excellent QEMU project has a user space emulator! It can be compiled as a dynamically linked executable, honors LD_PRELOAD and uses the host libc's syscall - well, at least sometimes. Sometimes syscalls just bypass libc.
The missing piece was a way to make QEMU always take the interposable path and call the host libc instead of using an arch-specifix assembly routine (`safe_syscall_base`) to construct the syscall and going directly to the kernel. Luckily, this turned out to be doable. A small patch later, QEMU gained a switch that forces all syscalls through libc. Suddenly, our static binaries started looking a lot more dynamic!
With this in place, Firebuild can finally wrap even those secretive statically linked tools. QEMU runs them, libc catches their syscalls, LD_PRELOAD injects libfirebuild.so, and from there the usual interposition magic happens. The result: previously uncachable build steps can now be traced, cached, and shortcut just like their dynamic friends.
There is one more problem though. Why would the static binaries deep in the build be run by QEMU? Firebuild also intercepts the `exec()` calls and now it rewrites them on the fly whenever the executed binary would be statically linked!
The QEMU patch is forwarded to qemu-devel. If it lands, anyone using QEMU user-mode emulation could benefit - not just Firebuild.
For Firebuild users, though, the impact is immediate. Toolchains that mix dynamic and static helpers? Cross-builds that pull in odd little statically linked utilities? Previously "invisible" steps in your builds? All now fair game for caching.
Firebuild 0.8.5 ships this new capability out of the box. Just update, make sure you're using a patched QEMU, and enjoy the feeling of watching even static binaries fall neatly into place in your cached build graph. Ubuntu users can get the prebuilt patched QEMU packages from the Firebuild PPA already.
Release 0.6.39 of the digest package arrived at CRAN today and has also been uploaded to Debian.
digest creates hash digests of arbitrary R objects. It can use a number different hashing algorithms (md5, sha-1, sha-256, sha-512, crc32, xxhash32, xxhash64, murmur32, spookyhash, blake3,crc32c, xxh3_64 and xxh3_128), and enables easy comparison of (potentially large and nested) R language objects as it relies on the native serialization in R. It is a mature and widely-used package (with 86.8 million downloads just on the partial cloud mirrors of CRAN which keep logs) as many tasks may involve caching of objects for which it provides convenient general-purpose hash key generation to quickly identify the various objects.
As noted last week in the 0.6.38 release note, hours after it was admitted to CRAN, I heard from the ever-so-tireless Brian Ripley about an SAN issue on arm64 only (and apparently non-reproducible elsewhere). He kindly provided a fix; it needed a cast. Checking this on amd64 against our Rocker-based ASAN and UBSAN containers (where is remains impossible to replicate, this issue is apparently known for some arm64 issues) another micro-issue (of a missing final argument NULL missing in one .Call()) was detected. Both issues were fixed the same day, and constitute the only change here. I merely waited a week to avoid a mechanical nag triggered when release happen within a week.
r2u brings CRAN packages for R to Ubuntu. We mentioned it in the R4 series within the last year in posts #54 about faster CI, #48 about the r2u keynote at U Mons, #47 reviewing r2u it at its third birthday, #46 about adding arm64 support, and #44 about the r2u for mlops talk.
Today brings news of an important (internal) update. Following both the arm64 builds as well as the last bi-annual BioConductor package update (and the extension of BioConductor coverage to arm64), more and more of our build setup became automated at GitHub. This has now been unified. We dispatch builds for amd64 packages for 'jammy' (22.04) and 'noble' (24.04) (as well as for the arm64 binaries for 'noble') from the central build repository and enjoy the highly parallel build of the up to fourty available GitHub Runners. In the process we also switched fully to source builds.
In the past, we had relied on p3m.dev (formerly known as ppm and rspm) using its binaries. These so-called 'naked binaries' are what R produces when called as R CMD INSTALL --build. They are portable with the same build architecture and release, but do not carry packaging information. Now, when a Debian or Ubuntu .deb binary is built, the same step of R CMD INSTALL --build happens. So our earlier insight was to skip the compilation step, use the p3m binary, and then wrap the remainder of a complete package around it. Which includes the all-important dependency information for both the R package relations (from hard Depends / Imports / LinkingTo or soft Suggests declarations) as well as the shared library dependency resolution we can do when building for a Linux distribution.
That served us well, and we remain really grateful for the p3m.dev build service. But it also meant were dependending on the 'clock' and 'cadence' of p3m.dev. Which was not really a problem when it ran reliably daily, and early too, included weekends, and showed a timestamp of last updates. By now it is a bit more erratic, frequently late, skips weekends more regularly and long stopped showing when it was last updated. Late afternoon releases reflecting the CRAN updates ending one and half-days earlier is still good, it's just not all that current. Plus there was always the very opaque occurrencem where maybe one in 50 packages or so would not even be provided as a binary so we had to build it anyway-the fallback always existing, and was used for both BioConductor (no binaries) and arm64 (no binaries at first, this now changed). So now we just build packages the standard way, albeit as GitHub Actions.
In doing so we can ignore p3m.dev, and rather follow the CRAN clock and cadence (as for example CRANberries does), and can update several times a day. For example early this morning (Central time) we ran update for the then-new 28 source packages resulting in 28 jammy and 36 noble binary packages; right now in mid-afternoon we are running another build for 37 source packages resuling in 37 jammy and 47 noble packages. (Packages without a src/ directory and hence no compilation can be used across amd64 and arm64; those that do have src/ are rebuilt for arm64 hence the different sets of jammy and noble packages as only the latter has arm64 now.) This gets us packages from this morning into r2u which p3m.dev should have by tomorrow afternoon or so.
And with that r2u remains "Fast. Easy. Reliable. Pick all three!" and also a little more predictable and current in its delivery. What's not to like?
Last week, our university held a «Mega Vaccination Center». Things cannot be small or regular with my university, ever! According to the official information, during last week ≈31,000 people were given a total of ≈74,000 vaccine dosis against influenza, COVID-19, pneumococcal disease and measles (specific vaccines for each person selected according to an age profile).
I was a tiny blip in said numbers. One person, three shots. Took me three hours, but am quite happy to have been among the huge crowd.
And why am I bringing this up? Because I have long been involved in organizing DebConf, the best conference ever, naturally devoted to improving Debian GNU/Linux. And last year, our COVID reaction procedures ended up hurting people we care about. We, as organizers, are taking it seriously to shape a humane COVID handling policy that is, at the same time, responsible and respectful for people who are (reasonably!) afraid to catch the infection. No, COVID did not disappear in 2022, and its effects are not something we can turn a blind eye to.
Next year, DebConf will take place in Santa Fe, Argentina, in July. This means, it will be a Winter DebConf. And while you can catch COVID (or influenza, or just a bad cold) at any time of year, odds are a bit higher.
I know not every country still administers free COVID or influenza vaccines to anybody who requests them. And I know that any protection I might have got now will be quite weaker by July. But I feel it necessary to ask of everyone who can get it to get a shot. Most Northern Hemisphere countries will have a vaccination campaign (or at least, higher vaccine availability) before Winter.
If you plan to attend DebConf (hell… If you plan to attend any massive gathering of people travelling from all over the world to sit at a crowded auditorium) during the next year, please… Act responsibly. For yourself and for those surrounding you. Get vaccinated. It won't absolutely save you from catching it, but it will reduce the probability. And if you do catch it, you will probably have a much milder version. And thus, you will spread it less during the first days until (and if!) you start developing symptoms.
SLES 16 has been released. In the past, SUSE offered ready built vagrant images. Unfortunately that's not the case anymore, as with more recent SLES15 releases the official images were gone.
In the past, it was possible to clone existing projects on the opensuse build service to build the images by yourself, but i couldn't find any templates for SLES 16.
Naturally, there are several ways to build images, and the tooling around involves kiwi-ng, opensuse build service, or packer recipes etc.. (existing packer recipes wont work anymore, as Yast has been replaced by a new installer, called agma). All pretty complicated, …
So my current take on creating a vagrant image for SLE16 has been the following:
Spin up an QEMU virtual machine
Manually install the system, all in default except for one special setting: In the Network connection details, "Edit Binding settings" and set the Interface to not bind a particular MAC address or interface. This will make the system pick whatever network device naming scheme is applied during boot.
After installation has finished, shutdown.
Two guestfs-tools that can now be used to modify the created qcow2 image:
run virt-sysrpep on the image to wipe settings that might cause troubles:
virt-sysprep -a sles16.qcow2
create a simple shellscript that setups all vagrant related settings:
#!/bin/bash
useradd vagrant
mkdir-p /home/vagrant/.ssh/
chmod 0700 /home/vagrant/.ssh/
echo"ssh-rsa AAAAB3NzaC1yc2EAAAABIwAAAQEA6NF8iallvQVp22WDkTkyrtvp9eWW6A8YVr+kz4TjGYe7gHzIw+niNltGEFHzD8+v1I2YJ6oXevct1YeS0o9HZyN1Q9qgCgzUFtdOKLv6IedplqoPkcmF0aYet2PkEDo3MlTBckFXPITAMzF8dJSIF
o9D8HfdOV0IAdx4O7PtixWKn5y2hMNG0zQPyUecp4pzC6kivAIhyfHilFR61RGL+GPXQ2MWZWFYbAGjyiYJnAmCP3NOTd0jMZEnDkbUvxhMmBYSdETk1rRgm+R4LOzFUGaHqHDLKLX+FIPKcF96hrucXzcWyLbIbEgE98OHlnVYCzRdK8jlqm8tehUc9c9W
hQ== vagrant insecure public key"> /home/vagrant/.ssh/authorized_keys
chmod 0600 /home/vagrant/.ssh/authorized_keys
chown-R vagrant:vagrant /home/vagrant/
# apply recommended ssh settings for vagrant boxesSSHD_CONFIG=/etc/ssh/sshd_config.d/99-vagrant.conf
if[[!-d"$(dirname${SSHD_CONFIG})"]];then
SSHD_CONFIG=/etc/ssh/sshd_config
# prepend the settings, so that they take precedenceecho-e"UseDNS no\nGSSAPIAuthentication no\n$(cat${SSHD_CONFIG})">${SSHD_CONFIG}else
echo-e"UseDNS no\nGSSAPIAuthentication no">${SSHD_CONFIG}fi
SUDOERS_LINE="vagrant ALL=(ALL) NOPASSWD: ALL"if[-d /etc/sudoers.d ];then
echo"$SUDOERS_LINE">| /etc/sudoers.d/vagrant
visudo -cf /etc/sudoers.d/vagrant
chmod 0440 /etc/sudoers.d/vagrant
else
echo"$SUDOERS_LINE">> /etc/sudoers
visudo -cf /etc/sudoers
fi
mkdir-p /vagrant
chown-R vagrant:vagrant /vagrant
systemctl enable sshd
use virt-customize to upload the script into the qcow image:
virt-customize -a sle16.qcow2 --upload vagrant.sh:/tmp/vagrant.sh
execute the script via:
virt-customize -a sle16.qcow2 --run-command"/tmp/vagrant.sh"
After this, use the create-box.sh from the vagrant-libvirt project to create an box image:
Just like a ship needs an anchor to stabilize and hold it to port, humans too, I feel, have and require anchors to hold them in life. It could be an emotional anchor, a physical anchor, an anchor that stimulates your curiosity, a family member, a friend or a partner or a spiritual being.
An anchor holds you and helps you stabilize in stormy weather. An anchor can keep you going or stop you from going. An anchor orients you, helps you formulate your values and beliefs.
An anchor could be someone or something or oneself (thanks Saswata for the thought). Writing here is one of my anchors; what's your anchor?
