GNU/Linux, BSD, and Hardware

posted by Roy Schestowitz on Jul 20, 2026

• Server

  • Steen ☛ The death and rebirth of my home server

    A few evenings ago my partner and I were in the mood to install this particular Linux ISO. The guys from Red Letter Systems had spoken of it well, it had good reviews on boundingboxd, and my partner liked the installation trailer.

    I opened Tremotesf on my phone to check whether I already had it on the Pi, but the torrent list wouldn't load. The SMB mount wouldn't mount. I couldn't SSH into it either.

    Not eager to ruin the evening by starting a debugging session then and there, I chalked it up to a simple issue with the recent changes I made to the NixOS configuration and resolved to take a look at it the next day.

• Applications

  • OSTechNix ☛ Best Kiwix ZIM Files to Download for Your Offline Knowledge Library

    Discover best ZIM files, storage planning, library management, and everything you need to build a offline knowledge library with Kiwix.

• Distributions and Operating Systems

  • Distro Watch ☛ Put the fun back into computing. Use Linux, BSD.

    [...] For our Opinion Poll this week we respond to Linus Torvalds suggesting people who do not like LLM tools can fork the kernel. Do you think anyone will take him up on the suggestion? [...]

  • BSD

    • Undeadly ☛ WPA3 support coming to OpenBSD

      Stefan Sperling (stsp@) posted a message with the subject add WPA3 support to the tech mailling list with a patch that implements WPA3 in OpenBSD's net80211 subsystem including ifconfig(8), asking for testing and feedback.

      He also noted that this effort is supported by the NLNet Foundaton (as noted in an earlier article).

  • Fedora Family / IBM

    • Red Hat ☛ What 429 chaos experiments taught us about Kubernetes operator resilience

      In my article Why killing pods is not enough: Testing operator reconciliation with operator-chaos, I ran operator-chaos against cert-manager. Eighteen experiments. Eighteen Resilient verdicts. The reconciliation loop detected every failure and restored the desired state within seconds. That was the good news, but here's what happened next.

      We ran operator-chaos against twenty-two Kubernetes operators with 429 CLI experiments. Most of them passed the standard tests: PodKill, NetworkPartition, LabelStomping. These are the tests that traditional chaos tools run, and they produce comforting green results because they are mostly testing the built-in Kubernetes Deployment controller, not the operator itself.

    • Red Hat ☛ PyTorch distributed is changing and TorchComms is why

      For most PyTorch users, "distributed" still means c10d. That's the runtime surface they use today, and it will remain the surface for a while. The real question is what should replace the old backend layer underneath it as training and inference systems demand more than host-driven process groups and standard collectives. TorchComms is the clearest answer PyTorch has presented so far.

      Why replace c10d

      The c10d library gave PyTorch a ProcessGroup-centered distributed runtime. That interface is still what most users touch, and it's not going away overnight. But the old back-end layer underneath it was designed around host-driven collectives and a smaller communication design space than modern LLM training and inference now need. TorchComms is the replacement path for that back-end layer.

  • Mobile Systems/Mobile Applications

    • Andre Franca ☛ Disappointment with Samsung

      Samsung makes great hardware and then ruins the experience with software.