• [1] https://www.aliexpress.com/item/1005006820869547.html
• [2] https://www.aliexpress.com/item/1005007099994832.html
• [3] https://www.aliexpress.com/item/1005009741428514.html
• [4] https://etbe.coker.com.au/2024/01/19/2-5gbit-ethernet/
• [5] https://www.aliexpress.com/item/1005007257555687.html
• [6] https://www.aliexpress.com/item/1005007561221707.html
• [7] https://www.aliexpress.com/item/1005009176898872.html
• [8] https://www.aliexpress.com/item/1005007046872368.html

• [1] https://etbe.coker.com.au/2023/10/11/pinetime/
• [2] https://pine64.org/documentation/PineTime/Accessory/Watch_band/
• [3] https://etbe.coker.com.au/2025/09/22/more-colmi-p80/
• [4] https://www.aliexpress.com/item/1005006159932767.html
• [5] https://www.aliexpress.com/item/1005007707373939.html

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

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

xrandr --newmode 7680x4320 1042.63  7680 7984 7760 7824  4320 4353 4323 4328
xrandr --addmode HDMI-3 7680x4320
xrandr --output HDMI-3 --mode 7680x4320

xrandr: Configure crtc 0 failed

• [1] https://etbe.coker.com.au/2024/12/15/hisense-65u80g-8k-tv/
• [2] https://etbe.coker.com.au/2025/03/06/8k-video-cards/
• [3] https://lemmy.ml/post/38586188
• [4] https://en.wikipedia.org/wiki/Extended_Display_Identification_Data
• [5] https://github.com/linuxhw/EDID
• [6] https://codeshack.io/what-is-my-screen-resolution/

A view to select the theme 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 main base view of Debusine reads the value from the cookie and makes it available to the templates:

      def get_context_data(self, **kwargs: Any) -> dict[str, Any]:
          ctx = super().get_context_data(**kwargs)
          ctx["theme"] = self.request.COOKIES.get("theme", None)
          # ...
          return ctx

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:

<form id="footer-theme" class="col-auto" method="post"
      action=" % url "theme-selection" % ">
     % csrf_token % 
    <input type="hidden" name="next" value="  request.get_full_path  ">
    Theme:
    <button type="submit" name="theme" value="dark">dark</button>
     
    <button type="submit" name="theme" value="light">light</button>
     
    <button type="submit" name="theme" value="auto">auto</button>
</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:

footer button  
    background: none;
    border: none;
    margin: 0;
    padding: 0;
    color: var(--bs-link-color);
 

Theme autoselection Bootstrap would support theme autoselection via browser preferences, but that requires rebuilding its Sass sources. Alternatively, one can use JavaScript:

 % 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:

:root[data-bs-theme=light]  
    --debusine-hover-layer: rgb(0 0 0 / 20%);
    --debusine-hover-color-multiplier: 0.8;
    --debusine-disabled-color-multiplier: 1.5;
 
:root[data-bs-theme=dark]  
    --debusine-hover-layer: rgb(255 255 255 / 20%);
    --debusine-hover-color-multiplier: 1.2;
    --debusine-disabled-color-multiplier: 0.5;
 

/* Button that preserves the underlying color scheme */
.btn-debusine  
  --bs-btn-hover-color: rgb(from var(--bs-btn-color) calc(r * var(--debusine-hover-color-multiplier)) calc(g * var(--debusine-hover-color-multiplier)) calc(b * var(--debusine-hover-color-multiplier)));
  --bs-btn-hover-bg: var(--debusine-hover-layer);
  --bs-btn-disabled-color: rgb(from var(--bs-btn-color) calc(r * var(--debusine-disabled-color-multiplier)) calc(g * var(--debusine-disabled-color-multiplier)) calc(b * var(--debusine-disabled-color-multiplier)));
  --bs-btn-disabled-bg: var(--bs-btn-bg);
  --bs-btn-disabled-border-color: var(--bs-btn-border-color);
 

Dark mode! 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. And Debusine now has a dark mode!

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
• The DESCRIPTION file now uses Authors@R

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

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
• OpenMP detection in configure has been simplified

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can sponsor me at GitHub.

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.

$ faketime '2008-12-24 08:15:42'  qemu-x86_64 ./test_static_clock_gettime
2008-12-24 08:15:42.725404654
$ file test_static_clock_gettime 
test_clock_gettime: ELF 64-bit LSB executable, x86-64, version 1 (GNU/Linux), statically linked, ...

$ firebuild -d comm bash -c ./test_static
...
FIREBUILD: fd 9.1: ( ExecedProcess 161077.1, running, "bash -c ./test_static", fds=[0:  FileFD ofd= FileO
FD #0 type=FD_PIPE_IN r  cloexec=false , 1:  FileFD ofd= FileOFD #3 type=FD_PIPE_OUT w   Pipe #0  close_o
n_popen=false cloexec=false , 2:  FileFD ofd= FileOFD #4 type=FD_PIPE_OUT w   Pipe #1  close_on_popen=fal
se cloexec=false , 3:  FileFD NULL  /* times 2 */] )
 
    "[FBBCOMM_TAG]": "exec",
    "file": "test_static",
    "// fd": null,
    "// dirfd": null,
    "arg": [
        "./test_static"
    ],
    "env": [
        "SHELL=/bin/bash",
 ...
        "FB_SOCKET=/tmp/firebuild.cpMn75/socket",
        "_=./test_static"
    ],
    "with_p": false,
    "// path": null,
    "utime_u": 0,
    "stime_u": 1017
 
FIREBUILD: -> proc_ic_msg()  (message_processor.cc:782)  proc= ExecedProcess 161077.1, running, "bash -c 
./test_static", fds=[0:  FileFD ofd= FileOFD #0 type=FD_PIPE_IN r  cloexec=false , 1:  FileFD ofd= FileOF
D #3 type=FD_PIPE_OUT w   Pipe #0  close_on_popen=false cloexec=false , 2:  FileFD ofd= FileOFD #4 type=F
D_PIPE_OUT w   Pipe #1  close_on_popen=false cloexec=false , 3:  FileFD NULL  /* times 2 */] , fd_conn=9.
1, tag=exec, ack_num=0
FIREBUILD:   -> send_fbb()  (utils.cc:292)  conn=9.1, ack_num=0 fd_count=0
Sending message with ancillary fds []:
 
    "[FBBCOMM_TAG]": "rewritten_args",
    "arg": [
        "/usr/bin/qemu-user-interposable",
        "-libc-syscalls",
        "./test_static"
    ],
    "path": "/usr/bin/qemu-user-interposable"
 
...
FIREBUILD: -> accept_ic_conn()  (firebuild.cc:139)  listener=6
...
FIREBUILD: fd 9.2: ( Process NULL )
 
    "[FBBCOMM_TAG]": "scproc_query",
    "pid": 161077,
    "ppid": 161073,
    "cwd": "/home/rbalint/projects/firebuild/test",
    "arg": [
        "/usr/bin/qemu-user-interposable",
        "-libc-syscalls",
        "./test_static"
    ],
    "env_var": [
        "CCACHE_DISABLE=1",
...
        "SHELL=/bin/bash",
        "SHLVL=0",
        "_=./test_static"
    ],
    "umask": "0002",
    "jobserver_fds": [],
    "// jobserver_fifo": null,
    "executable": "/usr/bin/qemu-user-interposable",
    "// executed_path": null,
    "// original_executed_path": null,
    "libs": [
        "/lib/x86_64-linux-gnu/libatomic.so.1",
        "/lib/x86_64-linux-gnu/libc.so.6",
        "/lib/x86_64-linux-gnu/libglib-2.0.so.0",
        "/lib/x86_64-linux-gnu/libm.so.6",
        "/lib/x86_64-linux-gnu/libpcre2-8.so.0",
        "/lib64/ld-linux-x86-64.so.2"
    ],
    "version": "0.8.5.1"
 

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

This post by Dirk Eddelbuettel originated on his Thinking inside the box blog. If you like this or other open-source work I do, you can now sponsor me at GitHub.

• 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.

• 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 boxes
SSHD_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 precedence
    echo -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"

 create_box.sh sle16.qcow2 sle16.box
 vagrant box add --name my/sles16 test.box

1. When a job cause a hang, call driver specific handler.
2. Stop the scheduler.
3. Copy all jobs from the ring buffer, minus the job that caused the issue, to a temporary ring.
4. Reset the ring buffer.
5. Copy back the other jobs to the ring buffer.
6. Resume the scheduler.

• https://lore.kernel.org/amd-gfx/20250701184451.11868-1-alexander.deucher@amd.com/T/#m5df543b5cbbdc31e2834c955d1e3e30b939cb77

• IGT: At the IGT level, we can have more tests that insert malicious instructions into the ring buffer, forcing the driver into an invalid state and triggering the recovery process.
• HangTest suite: HangTest suite is a tool that simulates some potential hangs using Vulkan. Some tests are already available in this suite, but we should explore more creative combinations for trying to trigger hangs.