home.social

Search

449 results for “cmdln”

  1. miccaman ✔️ @[email protected] ·

    instagram.com/p/CvzZx-WMm7M/
    Signal Station - LXII
    .
    Software: bash
    Media: JPG
    Title: Composition 62
    Timestamp: 20230811-134718

    #imagemagick #cmdlineart #belgiumartist #geometricabstract #artepovera #constructivism #reductiveart #modernminimalistart #postminimalism #geometricabstraction #nonobjectiveart #concretepoetry

    #concretepoetry #nonobjectiveart #geometricabstraction #postminimalism #modernminimalistart #reductiveart
  2. Armin Hanisch @[email protected] ·

    Wer ein kleines Beispiel sucht, warum sich jemand mit der Kommandozeile befassen sollte und wie produktiv das Konzept der Verkettung von Befehlen ist: zerlegt den Barden.
    arminhanisch.de/2016/07/shakes

    #Scripting #Shell #Bash #TextTools #CmdlineDataScience

    #scripting #shell #bash #texttools #cmdlinedatascience
  3. Kevin @[email protected] ·

    When two Hetzner servers died at the same time

    On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

    Several hours went into hypotheses that turned out to be wrong:

    • The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
    • PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
    • Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
    • Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
    • Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

    The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

    What it almost certainly was

    Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

    • Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
    • New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

    Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

    GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

    One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

    Why it matters for anyone running this stack

    If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

    Tooling

    While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

    → github.com/kevinveenbirkenbach/hetzner-arch-luks

    Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

    #ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd
    #archlinux #bootfailure #debugging #devops #dhcp #dropbear
  4. Kevin @[email protected] ·

    When two Hetzner servers died at the same time

    On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

    Several hours went into hypotheses that turned out to be wrong:

    • The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
    • PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
    • Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
    • Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
    • Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

    The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

    What it almost certainly was

    Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

    • Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
    • New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

    Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

    GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

    One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

    Why it matters for anyone running this stack

    If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

    Tooling

    While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

    → github.com/kevinveenbirkenbach/hetzner-arch-luks

    Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

    #ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd
    #archlinux #bootfailure #debugging #devops #dhcp #dropbear
  5. Kevin @[email protected] ·

    When two Hetzner servers died at the same time

    On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

    Several hours went into hypotheses that turned out to be wrong:

    • The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
    • PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
    • Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
    • Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
    • Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

    The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

    What it almost certainly was

    Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

    • Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
    • New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

    Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

    GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

    One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

    Why it matters for anyone running this stack

    If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

    Tooling

    While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

    → github.com/kevinveenbirkenbach/hetzner-arch-luks

    Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

    #ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd
    #archlinux #bootfailure #debugging #devops #dhcp #dropbear
  6. Kevin @[email protected] ·

    When two Hetzner servers died at the same time

    On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

    Several hours went into hypotheses that turned out to be wrong:

    • The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
    • PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
    • Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
    • Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
    • Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

    The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

    What it almost certainly was

    Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

    • Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
    • New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

    Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

    GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

    One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

    Why it matters for anyone running this stack

    If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

    Tooling

    While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

    → github.com/kevinveenbirkenbach/hetzner-arch-luks

    Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

    #ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd
    #systemdnetworkd #sysadmin #serveroutage #pythoncli #postmortem #pacman
  7. Kevin @[email protected] ·

    When two Hetzner servers died at the same time

    On May 12, 2026, two of my Arch Linux + LUKS servers at Hetzner became unreachable at the same moment. Both had been running for 4+ months without issue. Both had received the same pacman -Syyu the day before, but had stayed on the old kernel until the morning the websites stopped responding. I rebooted — SSH never came back. nmap -Pn -p 22 showed filtered from anywhere. No ping. No banner. The Hetzner Robot panel insisted the hardware was fine.

    Several hours went into hypotheses that turned out to be wrong:

    • The encryptssh initcpio hook referencing a /usr/lib/initcpio/udev/11-dm-initramfs.rules file that no longer exists. Real bug, no boot impact — the initramfs rebuilds anyway.
    • PermitRootLogin no in sshd_config. Real misconfiguration, fixed it, didn’t help. A refusing sshd shows closed, not filtered.
    • Predictable interface-naming drift after the systemd 260 upgrade. Patched the .network config to match by MAC. Useful hardening; not the cause.
    • Stale GRUB stage1 + core.img in the MBR. Arch never re-runs grub-install after a grub package upgrade. Refreshed it. Still filtered.
    • Kernel 7.0.5 regression. Downgraded to 6.18.3, the kernel that had run for 4 months. Still filtered. So the kernel itself wasn’t it either.

    The clue was in the persistent journal: a single recorded boot from December 31 to May 12 10:13 UTC, and absolutely nothing after. Every reboot since the upgrade was failing before systemd-journald could flush to disk — so the failure had to be in the initramfs, before the root filesystem was even mounted.

    What it almost certainly was

    Hetzner Dedicated servers configure the initramfs network with ip=dhcp on the kernel command line. That depends on Hetzner’s DHCP server replying to whatever request format the current kernel sends. Somewhere between kernel 6.18 / iproute2 6.18 and kernel 7.0 / iproute2 7.0, the request format changed enough that Hetzner’s DHCP stopped responding. Effects:

    • Old kernel at runtime kept the interface already configured (Phase A — 32 hours of healthy operation after the package upgrade).
    • New kernel cold-boots, hits DHCP, never gets an IP, dropbear cannot listen, port 22 stays filtered.

    Hetzner’s own documentation has been quietly moving away from ip=dhcp toward static IPv4 in the kernel command line. The fix is exactly that:

    GRUB_CMDLINE_LINUX="cryptdevice=/dev/md1:cryptroot ip=A.B.C.D::GATEWAY:255.255.255.255:hostname:eth0:none"

    One line in /etc/default/grub, grub-mkconfig, reboot. No more dependency on Hetzner’s DHCP responding to whatever your current kernel sends.

    Why it matters for anyone running this stack

    If you run Arch on Hetzner Dedicated with full-disk encryption and remote unlock via dropbear, the ip=dhcp shipped by installimage is a latent bug. It can keep working for years and then break overnight, on every machine you have, after a routine pacman -Syyu. The static-IP version is what Hetzner now recommends and removes the entire dependency.

    Tooling

    While debugging, I turned the whole rescue / chroot / diagnose / fix workflow into a Python CLI (hal) — including hal fix static-ip, which derives the static cmdline directly from your existing systemd-networkd .network file:

    → github.com/kevinveenbirkenbach/hetzner-arch-luks

    Single command, idempotent, reversible (the original /etc/default/grub is backed up to .hal-backup). If you’re on this stack, switch to static IP before the next kernel upgrade catches you.

    #ArchLinux #bootFailure #debugging #DevOps #DHCP #Dropbear #fullDiskEncryption #GRUB #Hetzner #initramfs #kernelUpgrade #Linux #LUKS #mkinitcpio #pacman #postmortem #PythonCLI #serverOutage #sysadmin #systemdNetworkd
    #archlinux #bootfailure #debugging #devops #dhcp #dropbear
  8. Jan Walraven ⁂ @[email protected] ·

    Als we de komende jaren evenveel CO2 blijven uitstoten als in 2025 dan is het resterende ‘koolstofbudget’ – de hoeveelheid CO2 die we nog mogen uitstoten om onder een opwarming van 1,5°C te blijven – uitgeput binnen de vier jaar.

    Nu al wordt de gemiddelde globale temperatuurstijging geschat op ongeveer 1,4°C boven het pre-industriële niveau. De gevolgen van die opwarming draaien we niet zomaar even terug. En alle ellende die dit veroorzaakt evenmin. De planeet heeft geen thermostaat die je naar believen kan instellen.

    Begrotingsdiscipline blijkt in het geval van koolstof minder dwingend dan wanneer het over overheidsfinanciën gaat.

    #klimaatcrisis #overshoot

    apache.be/2026/05/02/kanarie-h

    #klimaatcrisis #overshoot
  9. Jan Walraven ⁂ @[email protected] ·

    The European Investment Fund will no longer provide funding to #spyware companies based outside the EU. This was revealed during an exchange of vieuws in the European Parliament.

    The decision comes after @apache_be revealed that the Fund had provided funding to the controversial Israeli spyware company #Paragon.

    @edri applauds the policy change, but argues that “the EIB and the EIF should go much further. No spyware company - regardless of whether it is Israeli, European, or from anywhere else - should receive public money from European taxpayers.”

    apache.be/2026/05/08/european-

    #spyware #paragon
  10. Jan Walraven ⁂ @[email protected] ·

    This investigation from October is being discussed in the European Parliament today.

    In 2020, the European Investment Fund provided capital for Israeli spyware company #Paragon Solutions, through an Israeli venture capital fund.

    A number of questions remained unanswered. How much money was involved? How much did the investment yield?

    A representative of the #EIF will answer some questions on the investment today.

    apache.be/2025/10/01/european-

    #paragon #eif
  11. Jan Walraven ⁂ @[email protected] ·

    Deze onthulling uit oktober krijgt vandaag een staartje. Het Europees Investeringsfonds voorzag in 2020 kapitaal voor het Israëlische spywarebedrijf #Paragon Solutions, via een Israëlisch durfkapitaalfonds.

    Een aantal vragen bleef onbeantwoord. Om hoeveel geld ging het? Hoeveel leverde de investering op?

    Een vertegenwoordiger van het #EIF geeft deze middag in het Europees Parlement tekst en uitleg bij de omstreden investering.

    apache.be/2025/01/01/europees-

    #paragon #eif
  12. Jan Walraven ⁂ @[email protected] ·

    Italian prosecutors investigating a domestic spying scandal say they have independently confirmed that two immigration activists and a journalist were hacked with Paragon spyware in late 2024, suggesting all three were part of the same “infection campaign”, The Guardian reports.

    For @apache_be I revealed last year that, in 2020, the European Investment Fund provided capital for #Paragon through an Israeli venture capital fund.

    apache.be/2025/10/01/european-

    #paragon
  13. Klaus Frank @[email protected] ·

    Reading the readme of the ReBarUEFI project for now. What I don't understand is this part in the FAQ:
    github.com/xCuri0/ReBarUEFI?ta

    > Can I use Resizable BAR on my system without modifying BIOS ?

    I have "pci=realloc" in my kernel cmdline. So why is the xe driver not working then?

    #Linux #Kernel #PCIe #NixOS #ReBar

    #linux #kernel #pcie #nixos #rebar
  14. Klaus Frank @[email protected] ·

    Reading the readme of the ReBarUEFI project for now. What I don't understand is this part in the FAQ:
    github.com/xCuri0/ReBarUEFI?ta

    > Can I use Resizable BAR on my system without modifying BIOS ?

    I have "pci=realloc" in my kernel cmdline. So why is the xe driver not working then?

    #Linux #Kernel #PCIe #NixOS #ReBar

    #linux #kernel #pcie #nixos #rebar
  15. Klaus Frank @[email protected] ·

    Reading the readme of the ReBarUEFI project for now. What I don't understand is this part in the FAQ:
    github.com/xCuri0/ReBarUEFI?ta

    > Can I use Resizable BAR on my system without modifying BIOS ?

    I have "pci=realloc" in my kernel cmdline. So why is the xe driver not working then?

    #Linux #Kernel #PCIe #NixOS #ReBar

    #linux #kernel #pcie #nixos #rebar
  16. Klaus Frank @[email protected] ·

    Reading the readme of the ReBarUEFI project for now. What I don't understand is this part in the FAQ:
    github.com/xCuri0/ReBarUEFI?ta

    > Can I use Resizable BAR on my system without modifying BIOS ?

    I have "pci=realloc" in my kernel cmdline. So why is the xe driver not working then?

    #Linux #Kernel #PCIe #NixOS #ReBar

    #rebar #nixos #pcie #kernel #linux
  17. Klaus Frank @[email protected] ·

    Reading the readme of the ReBarUEFI project for now. What I don't understand is this part in the FAQ:
    github.com/xCuri0/ReBarUEFI?ta

    > Can I use Resizable BAR on my system without modifying BIOS ?

    I have "pci=realloc" in my kernel cmdline. So why is the xe driver not working then?

    #Linux #Kernel #PCIe #NixOS #ReBar

    #linux #kernel #pcie #nixos #rebar
  18. The Void @[email protected] ·

    #Nushell vs. #Fish

    Fish es excelente por su auto-completado y facilidad de uso sin configuración, pero sigue basado en texto. Nushell ofrece esa misma amabilidad visual pero con una potencia de manipulación de datos muy superior.

    #Nushell vs. #PowerShell

    Ambas comparten la idea de no usar texto plano. Sin embargo, Nushell se siente más ligera y "Unix-friendly" en su sintaxis, evitando la verbosidad de los cmdlets de PowerShell (como Get-ChildItem).

    Si trabajas mucho con APIs, archivos de configuración (JSON/YAML) o simplemente estás cansado de pelear con awk y sed para formatear salidas de comandos, Nushell es una herramienta que vale la pena probar.

    #linux #debian #void #arch #terminal #shell

    #nushell #fish #powershell #linux #debian #void
  19. The Void @[email protected] ·

    #Nushell vs. #Fish

    Fish es excelente por su auto-completado y facilidad de uso sin configuración, pero sigue basado en texto. Nushell ofrece esa misma amabilidad visual pero con una potencia de manipulación de datos muy superior.

    #Nushell vs. #PowerShell

    Ambas comparten la idea de no usar texto plano. Sin embargo, Nushell se siente más ligera y "Unix-friendly" en su sintaxis, evitando la verbosidad de los cmdlets de PowerShell (como Get-ChildItem).

    Si trabajas mucho con APIs, archivos de configuración (JSON/YAML) o simplemente estás cansado de pelear con awk y sed para formatear salidas de comandos, Nushell es una herramienta que vale la pena probar.

    #linux #debian #void #arch #terminal #shell

    #nushell #fish #powershell #linux #debian #void
  20. The Void @[email protected] ·

    #Nushell vs. #Fish

    Fish es excelente por su auto-completado y facilidad de uso sin configuración, pero sigue basado en texto. Nushell ofrece esa misma amabilidad visual pero con una potencia de manipulación de datos muy superior.

    #Nushell vs. #PowerShell

    Ambas comparten la idea de no usar texto plano. Sin embargo, Nushell se siente más ligera y "Unix-friendly" en su sintaxis, evitando la verbosidad de los cmdlets de PowerShell (como Get-ChildItem).

    Si trabajas mucho con APIs, archivos de configuración (JSON/YAML) o simplemente estás cansado de pelear con awk y sed para formatear salidas de comandos, Nushell es una herramienta que vale la pena probar.

    #linux #debian #void #arch #terminal #shell

    #nushell #fish #powershell #linux #debian #void
  21. The Void @[email protected] ·

    #Nushell vs. #Fish

    Fish es excelente por su auto-completado y facilidad de uso sin configuración, pero sigue basado en texto. Nushell ofrece esa misma amabilidad visual pero con una potencia de manipulación de datos muy superior.

    #Nushell vs. #PowerShell

    Ambas comparten la idea de no usar texto plano. Sin embargo, Nushell se siente más ligera y "Unix-friendly" en su sintaxis, evitando la verbosidad de los cmdlets de PowerShell (como Get-ChildItem).

    Si trabajas mucho con APIs, archivos de configuración (JSON/YAML) o simplemente estás cansado de pelear con awk y sed para formatear salidas de comandos, Nushell es una herramienta que vale la pena probar.

    #linux #debian #void #arch #terminal #shell

    #nushell #fish #powershell #linux #debian #void
  22. Simon Poirier @[email protected] ·

    Microsoft is now rolling out the rename of Azure Active Directory (Azure AD) to Microsoft Entra ID, with no impact on deployments or daily work, and no changes to capabilities, licensing, terms of service, or support. Check out this article to learn more about how you can update your own documentation or experiences to reflect the new name and find answers to questions from the community about managing Microsoft Entra ID in the Azure portal, supporting on-premises identities with Microsoft Entra ID, identity developer and devops experiences not being renamed, Azure AD PowerShell cmdlets not being renamed and continuing support for Azure AD B2C. Click here to read more!
    Post generated with the help of Azure OpenAI GPT 🤖 #msftadvocate #AAD #Identity techcommunity.microsoft.com/t5

    #msftadvocate #aad #identity
  23. Jan Walraven ⁂ @[email protected] ·

    Amerikaans defensietechnologiebedrijf Anduril dingt samen met Cobbs Belux en Nokia mee naar het Belgische contract voor droneafweer van ruim 1 miljard euro.

    #Anduril is niet zomaar een wapenbedrijf. Onder de regering-Trump rijft het miljardencontracten binnen. Met welke “warfighters” gaat België potentieel in zee?

    apache.be/2026/05/11/van-trump

    #anduril
  24. root42 @[email protected] ·

    So a little nut to crack for my #linux bubble: I am running #mintlinux on my external Thunderbolt SSD on the 2013 iMac. Problem is: When I suspend and then resume, the TB SSD does NOT wake up. System hangs -- because there is no root FS anymore!
    I already tried iummu=soft and pcie_aspm=off in the grub defaults:

    GRUB_CMDLINE_LINUX_DEFAULT="quiet splash iommu=soft pcie_aspm=off"

    But that does nothing to help. Any other ideas how to wake the sleeping princcess?

    #linux #mintlinux
  25. derSammler @[email protected] ·

    Ok, mittlerweile läuft es. Braucht für #Picasso96 v2.x seit #VideoCore 1.2 einen zusätzlichen Tooltype. Doku oder Info in den Release Notes für sowas gibt's natürlich nicht...

    Falls jemand das gleiche Problem hat:

    • der Monitor braucht "VC4_LEGACY_ID" als Tooltype

    Außerdem muss man drauf achten, dass die cmdline.txt nicht mit einem Zeilenumbruch endet. Sonst schaltet der #Framethrower zwar, zeigt aber nur ein schwarzes Bild, weil kein Scaler definiert ist (der Zeilenumbruch wird mit interpretiert und damit erkennt er den letzten Eintrag nicht).

    #Amiga #PiStorm #RetroComputing #RetroGaming

    #picasso96 #videocore #framethrower #amiga #pistorm #retrocomputing
  26. Kevin's Blog @[email protected] ·

    TD4 4-bit DIY CPU – Part 7

    Once the idea was floated, in Part 6 of creating an Arduino “direct to ROM” assembler, I had to just do it, so this post is a little diversion from the hardware discussion into how that could work.

    • Part 1 – Introduction, Discussion and Analysis
    • Part 2 – Building and Hardware
    • Part 3 – Programming and Simple Programs
    • Part 4 – Some hardware enhancements
    • Part 5 – My own PCB version
    • Part 6 – Replacing the ROM with a microcontroller
    • Part 7 – Creating an Arduino “assembler” for the TD4

    Basic Concepts

    This relies on using an Arduino as the ROM as described in Part 6, but the Arduino now has the option to change the ROM contents independently of the TD4 itself.

    The Arduino sketch will do the following:

    • Run the TD4 ROM routine off a timer interrupt so that it is always running and responsive.
    • Take input over the Arduino serial port to allow basic control, e.g. list, clear, etc.
    • Allow the direct input of assembler instructions, such as MOVE A,B or OUT B and so on.
    • Provide a means of selecting which line of the program to change.

    The code will thus have a number of key sections:

    • The TD4 ROM routine.
    • Some kind of serial-port command-line interpreter.
    • Handler routines for all the commands.
    • An assembler.
    • A disassembler.

    The TD4 ROM routine has already been fully described in Part 6. The only difference is that the scanning routine will be driven from a 1mS timer using the TimerOne library.

    As I want to still support a built-in demo, I now have the concept of ROM being the demo code and RAM being the “live” code to pass onto the TD4. The Arduino will initialise the RAM on startup from the ROM.

    As far as the TD4 is concerned of course, this is all still ROM.

    Command Line Interpreter

    The standard Arduino Serial routines will be used to scan for input via the serial port. It will support a line-oriented input as follows:

    bool cmdRunner (void) {
      while (Serial.available()) {
        char c = Serial.read();
        if (c == '\n') {
          strcpy(cmdSaved, cmdInput);
          cmdIdx = 0;
          return true;
        }
        else if (cmdIdx < CMD_BUFFER-1) {
          cmdInput[cmdIdx++] = c;
          cmdInput[cmdIdx] = '\0';
        }
      }
      return false;
    }

    This will keep adding any received characters to the cmdInput buffer until a newline is received, at which point the command is saved in cmdSaved and the routine will return true indicating a full line is ready to be processed.

    Once a complete line is received, then a processing function will parse it.

    Key to the processing of commands is a command table that stores the text to match and the handler function to call on finding a valid command. There is an additional parameter that will be passed into the handler function to allow the same handler function to support several commands. This will be used in the assembler itself later.

    struct cmd_t {
      char    cmd[CMD_BUFFER+1];
      hdlr_t  pFn;
      uint8_t idx;
    };

    const cmd_t PROGMEM cmdTable[NUM_CMDS] = {
      {"H", hdlrHelp, 0},
      {"L", hdlrList, 0},
      {"G", hdlrGoto, 0},
    };

    The algorithm for parsing commands is as follows:

    cmdProcess:
      Look for a space or newline
      IF found a space THEN
        This is the start of the parameter

      Look for the command in the command table
      IF command found THEN
        Call the handler function with the parameters

    The implementation is a bit complex, as it uses string pointers and has to chop and parse strings as it goes. It is also detailing with the command table in the Arduino’s PROGMEM which is an additional complication too.

    In order to be able to use the same command line interpreter for the input of assembler instructions, I’ve had to simplify the syntax. There are no spaces in opcodes and there has to be a space between the opcode and immediate value if used.

    Here are some examples:

    IN A       -> INA
    MOVE A,B   -> MOVAB
    OUT im     -> OUT im
    JNC im     -> JNC im
    ADD A,im   -> ADDA im

    Handler Routines

    All handler routines have the following prototype:

    typedef void (*hdlr_t)(int idx, char *param);

    void hdlrHelp(int idx, char *pParam) {
      Serial.print("\nHelp\n----\n");
      Serial.println("H: Help");
    }

    The idx parameter is the number in the last field of the command table. pParam will be a pointer to the parameter string for the command (if used).

    As we’re dealing with strings all the time, there are a number of helper functions to do things like convert strings to numbers as well as others to print numbers in various formats.

    Number formats are assumed to be as follows:

    0..9   - decimal digits
    0x0..F - hex digits
    b0..1  - binary digits

    The code provides the following:

    • str2num – the basic string parsing routine to recognise all three number formats as strings.
    • printbin – print a number in b0..1 format.
    • printhex – print a number in 0x0..F format, allowing for a possible leading zero if required.
    • printins – print an instruction in textual format.
    • printop – print an instruction in binary and hex opcode format.
    • printline – print a line number in a consistent binary and hex format.

    The code supports the following commands, so each has its own handler function:

    • H – help – show the list of commands.
    • L – list – show the disassembly of the whole working memory (RAM).
    • G – goto – set the working line number.
    • C – clear – reset all working memory (RAM) to zeros.
    • R – restore – restore the working memory (RAM) to the pre-build demo code (ROM).
    • O – opcodes – list the supported opcodes.

    Assembler

    As already mentioned, I’m using the same command line interpreter code to create the assembler. To do this, each opcode has an entry in the command table:

    const cmd_t PROGMEM cmdTable[NUM_CMDS] = {
      // Assembly commands - must be first
      {"ADDA", hdlrAsm, 0},
      {"MOVAB", hdlrAsm, 1},
      {"INA", hdlrAsm, 2},
      {"MOVA", hdlrAsm, 3},
      {"MOVBA", hdlrAsm, 4},
      {"ADDB", hdlrAsm, 5},
      {"INB", hdlrAsm, 6},
      {"MOVB", hdlrAsm, 7},
      {"OUTB", hdlrAsm, 8},
      {"OUT2B", hdlrAsm, 9},
      {"OUT", hdlrAsm, 10},
      {"OUT2", hdlrAsm, 11},
      {"JNCB", hdlrAsm, 12},
      {"JMPB", hdlrAsm, 13},
      {"JNC", hdlrAsm, 14},
      {"JMP", hdlrAsm, 15},

      // Other commands
      {"H", hdlrHelp, 0},
      {"L", hdlrList, 0},
      {"G", hdlrGoto, 0},
      {"C", hdlrClear, 0},
      {"R", hdlrRestore, 0},
      {"O", hdlrOpcodes, 0},
    };

    The order corresponds to the opcode command value, as does the parameter. As these are at the start of the table, I can assume that the position in the table is the same as the command value. This does mean that I also need to account for the duplicated instructions even if I don’t need to use them.

    I’m making the following design decisions:

    • There is the concept of a “current line” which can be set with the G (goto) command.
    • Entering a valid opcode automatically moves the current line on by 1.
    • No line information is entered as part of the opcode.

    The main logic of the assembler handler is as follows:

    Assembler:
      Command value is the provided index parameter
      Determine the im value from the provided string parameter
      RAM[line] = cmd << 4 + im
      Increment current line

    Disassembler

    Disassembly is really largely a look-up table matching opcode command values to text. This is all hidden away behind the two print routines printins() and printop().

    void printins (uint8_t ins) {
      uint8_t cmd = ins >> 4;
      uint8_t im = ins & 0x0F;

      Serial.print(FSH(cmdTable[cmd].cmd));
      if (HASIM(cmd)) {
        Serial.print(" b");
        printbin(im,4);
      } else {
        Serial.print("      ");
      }
    }

    void printop (uint8_t op) {
      uint8_t cmd = op >> 4;
      uint8_t im = op & 0x0F;

      Serial.print("b");
      printbin(cmd,4);
      Serial.print(" ");
      printbin(im,4);
      Serial.print("\t0x");
      printhex(op,2);
    }

    The main complexity is pulling the strings out of the command table. I’ve had to include a macro to provide access to the strings from the Arduino’s PROGMEM:

    #define FSH(x) ((const __FlashStringHelper *)x)

    This feels like a bit of a hack, but apparently this is how it should be done for the kind of thing I need to do!

    There is another macro here that needs explaining:

    #define HASIM(op) (op==0||op==3||op==5||op==7||op>9)

    This is a set of conditions that if true means that the command supports an immediate value. This is used in a few places to know how to parse the commands.

    Whilst in principle all commands could use the immediate value, the “official” statement of how they work assumes im=0 in many cases. So, for example, OUT B does not require an immediate value, but if one is provided then OUT B becomes OUT B+im.

    I’m not really supporting that with this code at the moment.

    Putting it all together

    Here is a serial output log of a session using the assembler.

    > H
    Help
    ----
    H: Help
    L: List
    G: Goto
    C: Clear
    R: Restore
    O: Opcodes
    OpCode
    OpCode im

    Current line: b0000 [0]

    > L
    RAM Disassembly

    b0000 [0]: JNC b1000b1110 10000xE8
    b0001 [1]: JMP b0011b1111 00110xF3
    b0010 [2]: OUT b0010b1010 00100xA2
    b0011 [3]: ADDB b0001b0101 00010x51
    b0100 [4]: OUT b0100b1010 01000xA4
    b0101 [5]: ADDA b0001b0000 00010x01
    b0110 [6]: OUT b1000b1010 10000xA8
    b0111 [7]: ADDB b0001b0101 00010x51
    b1000 [8]: OUT b0100b1010 01000xA4
    b1001 [9]: ADDA b0001b0000 00010x01
    b1010 [A]: OUT b0010b1010 00100xA2
    b1011 [B]: ADDB b0001b0101 00010x51
    b1100 [C]: JMP b0000b1111 00000xF0
    b1101 [D]: ADDA b0000b0000 00000x00
    b1110 [E]: ADDA b0000b0000 00000x00
    b1111 [F]: ADDA b0000b0000 00000x00
    Current line: b0010 [2]

    > G 13
    Goto line 13
    Current line: b1101 [D]

    > OUTB
    Assemble:
    b1101 [D] OUTB      b1000 00000x80
    Current line: b1110 [E]

    > L
    RAM Disassembly

    b0000 [0]: JNC b1000b1110 10000xE8
    b0001 [1]: JMP b0011b1111 00110xF3
    b0010 [2]: OUT b0010b1010 00100xA2
    b0011 [3]: ADDB b0001b0101 00010x51
    b0100 [4]: OUT b0100b1010 01000xA4
    b0101 [5]: ADDA b0001b0000 00010x01
    b0110 [6]: OUT b1000b1010 10000xA8
    b0111 [7]: ADDB b0001b0101 00010x51
    b1000 [8]: OUT b0100b1010 01000xA4
    b1001 [9]: ADDA b0001b0000 00010x01
    b1010 [A]: OUT b0010b1010 00100xA2
    b1011 [B]: ADDB b0001b0101 00010x51
    b1100 [C]: JMP b0000b1111 00000xF0
    b1101 [D]: OUTB      b1000 00000x80
    b1110 [E]: ADDA b0000b0000 00000x00
    b1111 [F]: ADDA b0000b0000 00000x00
    Current line: b1110 [E]

    > O
    Supported OpCodes:
      b0000 dataADDA im
      b0001 0000MOVAB
      b0010 0000INA
      b0011 dataMOVA im
      b0100 0000MOVBA
      b0101 dataADDB im
      b0110 0000INB
      b0111 dataMOVB im
      b1000 0000OUTB
      b1001 0000OUT2B
      b1010 dataOUT im
      b1011 dataOUT2 im
      b1100 dataJNCB im
      b1101 dataJMPB im
      b1110 dataJNC im
      b1111 dataJMP im

    > C
    Clearing RAM ... Done

    Find the code on GitHub here.

    Conclusion

    The basics for this actually came together fairly quickly, but I must admit to spending a fair bit of time fiddling about with output formats and refactoring various bits of code to try to give some consistency in terms of when newlines are applied, what is shown in binary, what in hex, and so on.

    I can’t guarantee everything has been caught, but I’ve typed in all the code (using the newer, limited syntax) from Part 3 and they all seem to work.

    It would be nice to be able to automatically reset the TD4 from the Arduino, but for now, pressing the button when required is fine.

    For the most part, unless there is a loop to get caught in, the code will cycle back to the start anyway.

    In terms of possible updates and enhancements, there are a few on my mind:

    • It would be nice to support the undocumented use of immediate values somehow.
    • It might be nice to have a way to save/load the code. It only needs to be a string of 16 2-byte hex codes.
    • It might be nice to have several demo programs to choose from.

    If I expand the instruction set and architecture, then I’ll have to think again about chunks of this code, but for now, it seems to work pretty well.

    Kevin

    #4bit #arduinoUno #define #td4

    #4bit #arduinouno #define #td4
  27. Debacle @[email protected] ·

    This cool trick (some would call it "dirty hack" 🙂) by @plantarum can be used for #dot/#graphviz, as well:

    (defun my-babel-execute-maybe ()
    (interactive)
    (org-mode)
    (org-babel-execute-maybe)
    (org-display-inline-images)
    (normal-mode))

    E.g. imagine this comment or doc string:

    /*
    #+BEGIN_SRC dot :file myfunction.svg :cmdline -Kdot -Tsvg
    digraph {
    a -> b;
    }
    #+END_SRC
    */

    #elisp #Emacs #orgmode

    #dot #graphviz #elisp #emacs #orgmode
  28. e-teaching.org @[email protected] ·

    📋Das Programm für das E‑Prüfungssymposium 2026 an der Albert-Ludwigs-Universität Freiburg ist veröffentlicht.

    Unter dem Motto „Herausforderungen digitaler Prüfungen: KI, Unterschleif, Infrastruktur” werden am 19. und 20. Mai 2026 aktuelle Entwicklungen rund um digitale Prüfungen, KI-gestützte Formate und organisatorische Innovationen diskutiert.

    Anmeldung bis zum 30. April 2026: lnkd.in/dbTix8Qi
    Programm: wb-ilias.uni-freiburg.de/ilias

    #DigitalePrüfungen #Hochschullehre #EAssessment #KI

    #digitaleprufungen #hochschullehre #eassessment #ki
  29. derSammler @[email protected] ·

    Ok, mittlerweile läuft es. Braucht für #Picasso96 v2.x seit #VideoCore 1.2 einen zusätzlichen Tooltype. Doku oder Info in den Release Notes für sowas gibt's natürlich nicht...

    Falls jemand das gleiche Problem hat:

    • der Monitor braucht "VC4_LEGACY_ID" als Tooltype

    Außerdem muss man drauf achten, dass die cmdline.txt nicht mit einem Zeilenumbruch endet. Sonst schaltet der #Framethrower zwar, zeigt aber nur ein schwarzes Bild, weil kein Scaler definiert ist (der Zeilenumbruch wird mit interpretiert und damit erkennt er den letzten Eintrag nicht).

    #Amiga #PiStorm #RetroComputing #RetroGaming

    #picasso96 #videocore #framethrower #amiga #pistorm #retrocomputing
  30. derSammler @[email protected] ·

    Ok, mittlerweile läuft es. Braucht für #Picasso96 v2.x seit #VideoCore 1.2 einen zusätzlichen Tooltype. Doku oder Info in den Release Notes für sowas gibt's natürlich nicht...

    Falls jemand das gleiche Problem hat:

    • der Monitor braucht "VC4_LEGACY_ID" als Tooltype

    Außerdem muss man drauf achten, dass die cmdline.txt nicht mit einem Zeilenumbruch endet. Sonst schaltet der #Framethrower zwar, zeigt aber nur ein schwarzes Bild, weil kein Scaler definiert ist (der Zeilenumbruch wird mit interpretiert und damit erkennt er den letzten Eintrag nicht).

    #Amiga #PiStorm #RetroComputing #RetroGaming

    #picasso96 #videocore #framethrower #amiga #pistorm #retrocomputing
Next page