#pacman — Public Fediverse posts

With Hall Effect thumbsticks, impulse triggers, and two types of glow, bring the spirit of the arcade to your controller with the PAC-MAN Special Edition PowerA Wireless Controller. On sale now: amzn.to/4rxDWx0 #Games #RetroGaming #Xbox #Arcade #PacMan #BandaiNamco #GameDev #GamingSky #PromoSky

With Hall Effect thumbsticks, impulse triggers, and two types of glow, bring the spirit of the arcade to your controller with the PAC-MAN Special Edition PowerA Wireless Controller. On sale now: amzn.to/4rxDWx0 #Games #RetroGaming #Xbox #Arcade #PacMan #BandaiNamco #GameDev #GamingSky #PromoSky

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.

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.

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.

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.

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.

Arch Tip týdne: pacman jako profík

📦 pacman umí mnohem víc než jen instalovat balíčky.
Tady jsou dotazy, které ti pomůžou pochopit, co máš v systému.

═══════════════════════════════════════════
🔍 ZÁKLADNÍ DOTAZY (-Q = QUERY)
═══════════════════════════════════════════

výpis všech nainstalovaných balíčků

pacman -Q

kolik balíčků mám?

pacman -Q | wc -l

jen explicitně nainstalované (bez závislostí)

pacman -Qe

jen závislosti (instalované jako "side effect")

pacman -Qd

balíčky z AUR / mimo oficiální repo

pacman -Qm

balíčky JEN z oficiálních repo

pacman -Qn

osiřelé balíčky (závislosti, které už nikdo nepotřebuje)

pacman -Qtdq

odstranění osiřelých

sudo pacman -Rns $(pacman -Qtdq)

═══════════════════════════════════════════
📋 pacman -Qi → INFO O BALÍČKU
═══════════════════════════════════════════

detailní info

pacman -Qi firefox

co uvidíš:

- verze, popis, URL

- licence

- závislosti (Depends On)

- co na něm závisí (Required By)

- volitelné závislosti (Optional Deps)

- velikost, datum instalace

- důvod instalace (Explicitly installed / Dependency)

rozšířené info (přidá Backup Files = konfiguráky chráněné při update)

pacman -Qii firefox

info z repa (i pro nenainstalované)

pacman -Si firefox

jen velikost balíčku

pacman -Qi firefox | grep "Installed Size"

řazení balíčků podle velikosti (potřebuje: pacman -S expac)

expac -H M "%m\t%n" | sort -h | tail -20

═══════════════════════════════════════════
📂 pacman -Ql → SEZNAM SOUBORŮ
═══════════════════════════════════════════

co všechno balíček nainstaloval

pacman -Ql firefox

jen binárky

pacman -Ql firefox | grep '/bin/'

konfigurační soubory balíčku (vše v /etc)

pacman -Ql firefox | grep '^firefox /etc'

počet souborů v balíčku

pacman -Ql firefox | wc -l

soubory nenainstalovaného balíčku (z repa)

nejdřív aktualizuj file database:

sudo pacman -Fy
pacman -Fl firefox

═══════════════════════════════════════════
🔎 pacman -Qo → KDO VLASTNÍ TENTO SOUBOR?
═══════════════════════════════════════════

který balíček nainstaloval daný soubor?

pacman -Qo /usr/bin/firefox

výstup:

/usr/bin/firefox is owned by firefox 123.0-1

najdi balíček podle příkazu v PATH

pacman -Qo $(which nvim)

najdi balíček, kterému patří soubor – i když ho nemáš nainstalovaný

sudo pacman -Fy
pacman -F /usr/bin/htop

═══════════════════════════════════════════
🛠️ pacnew / pacsave – CHRÁNĚNÉ KONFIGURÁKY
═══════════════════════════════════════════

Backup Files = soubory označené v balíčku jako "neredisej moji verzi"

Když přijde update a soubor jsi upravil, pacman vytvoří .pacnew

(nová verze z balíčku) a tvoji verzi nechá být.

seznam backup files konkrétního balíčku

pacman -Qii pacman | awk '/^Backup Files/,/^$/'

najdi všechny .pacnew/.pacsave v systému (čekající na merge)

sudo find /etc ( -name ".pacnew" -o -name ".pacsave" )

interaktivní merge (z pacman-contrib)

sudo pacman -S pacman-contrib
sudo pacdiff

═══════════════════════════════════════════
🌳 pactree → STROM ZÁVISLOSTÍ
═══════════════════════════════════════════

instalace (pokud nemáš)

sudo pacman -S pacman-contrib

co všechno balíček potřebuje (závislosti)

pactree firefox

obrácený strom – kdo závisí NA tomto balíčku

pactree -r glibc

omezení hloubky

pactree -d 1 firefox

jen názvy, bez ozdob

pactree -u firefox

grafický výstup (potřebuje: pacman -S graphviz)

pactree --graph firefox | dot -Tpng > firefox-deps.png

═══════════════════════════════════════════
🔧 BONUS – DALŠÍ UŽITEČNÉ DOTAZY
═══════════════════════════════════════════

hledání balíčku v repech

pacman -Ss firefox

hledání v nainstalovaných

pacman -Qs firefox

poslední full upgrade systému

grep "starting full system upgrade" /var/log/pacman.log | tail -5

co se naposled instalovalo/aktualizovalo

tail -50 /var/log/pacman.log

pretty výpis posledních akcí (expac)

expac --timefmt='%Y-%m-%d %T' '%l\t%n' | sort -r | head -20

změnit důvod instalace (z dependency na explicit)

sudo pacman -D --asexplicit firefox

označit jako závislost (půjde uklidit přes -Rns)

sudo pacman -D --asdeps nějaký-balíček

═══════════════════════════════════════════
💡 TYPICKÝ WORKFLOW
═══════════════════════════════════════════

1. co mi žere místo?

expac -H M "%m\t%n" | sort -h | tail -20

2. co dělá tenhle balíček?

pacman -Qi <balíček>

3. můžu ho smazat? Co na něm závisí?

pactree -r <balíček>

4. odkud se vzal tenhle soubor?

pacman -Qo /cesta/k/souboru

5. úklid

sudo pacman -Rns $(pacman -Qtdq)
sudo paccache -rk2

#archlinux #pacman #linux #cli

Arch Tip týdne: pacman jako profík

📦 pacman umí mnohem víc než jen instalovat balíčky.
Tady jsou dotazy, které ti pomůžou pochopit, co máš v systému.

═══════════════════════════════════════════
🔍 ZÁKLADNÍ DOTAZY (-Q = QUERY)
═══════════════════════════════════════════

výpis všech nainstalovaných balíčků

pacman -Q

kolik balíčků mám?

pacman -Q | wc -l

jen explicitně nainstalované (bez závislostí)

pacman -Qe

jen závislosti (instalované jako "side effect")

pacman -Qd

balíčky z AUR / mimo oficiální repo

pacman -Qm

balíčky JEN z oficiálních repo

pacman -Qn

osiřelé balíčky (závislosti, které už nikdo nepotřebuje)

pacman -Qtdq

odstranění osiřelých

sudo pacman -Rns $(pacman -Qtdq)

═══════════════════════════════════════════
📋 pacman -Qi → INFO O BALÍČKU
═══════════════════════════════════════════

detailní info

pacman -Qi firefox

co uvidíš:

- verze, popis, URL

- licence

- závislosti (Depends On)

- co na něm závisí (Required By)

- volitelné závislosti (Optional Deps)

- velikost, datum instalace

- důvod instalace (Explicitly installed / Dependency)

rozšířené info (přidá Backup Files = konfiguráky chráněné při update)

pacman -Qii firefox

info z repa (i pro nenainstalované)

pacman -Si firefox

jen velikost balíčku

pacman -Qi firefox | grep "Installed Size"

řazení balíčků podle velikosti (potřebuje: pacman -S expac)

expac -H M "%m\t%n" | sort -h | tail -20

═══════════════════════════════════════════
📂 pacman -Ql → SEZNAM SOUBORŮ
═══════════════════════════════════════════

co všechno balíček nainstaloval

pacman -Ql firefox

jen binárky

pacman -Ql firefox | grep '/bin/'

konfigurační soubory balíčku (vše v /etc)

pacman -Ql firefox | grep '^firefox /etc'

počet souborů v balíčku

pacman -Ql firefox | wc -l

soubory nenainstalovaného balíčku (z repa)

nejdřív aktualizuj file database:

sudo pacman -Fy
pacman -Fl firefox

═══════════════════════════════════════════
🔎 pacman -Qo → KDO VLASTNÍ TENTO SOUBOR?
═══════════════════════════════════════════

který balíček nainstaloval daný soubor?

pacman -Qo /usr/bin/firefox

výstup:

/usr/bin/firefox is owned by firefox 123.0-1

najdi balíček podle příkazu v PATH

pacman -Qo $(which nvim)

najdi balíček, kterému patří soubor – i když ho nemáš nainstalovaný

sudo pacman -Fy
pacman -F /usr/bin/htop

═══════════════════════════════════════════
🛠️ pacnew / pacsave – CHRÁNĚNÉ KONFIGURÁKY
═══════════════════════════════════════════

Backup Files = soubory označené v balíčku jako "neredisej moji verzi"

Když přijde update a soubor jsi upravil, pacman vytvoří .pacnew

(nová verze z balíčku) a tvoji verzi nechá být.

seznam backup files konkrétního balíčku

pacman -Qii pacman | awk '/^Backup Files/,/^$/'

najdi všechny .pacnew/.pacsave v systému (čekající na merge)

sudo find /etc ( -name ".pacnew" -o -name ".pacsave" )

interaktivní merge (z pacman-contrib)

sudo pacman -S pacman-contrib
sudo pacdiff

═══════════════════════════════════════════
🌳 pactree → STROM ZÁVISLOSTÍ
═══════════════════════════════════════════

instalace (pokud nemáš)

sudo pacman -S pacman-contrib

co všechno balíček potřebuje (závislosti)

pactree firefox

obrácený strom – kdo závisí NA tomto balíčku

pactree -r glibc

omezení hloubky

pactree -d 1 firefox

jen názvy, bez ozdob

pactree -u firefox

grafický výstup (potřebuje: pacman -S graphviz)

pactree --graph firefox | dot -Tpng > firefox-deps.png

═══════════════════════════════════════════
🔧 BONUS – DALŠÍ UŽITEČNÉ DOTAZY
═══════════════════════════════════════════

hledání balíčku v repech

pacman -Ss firefox

hledání v nainstalovaných

pacman -Qs firefox

poslední full upgrade systému

grep "starting full system upgrade" /var/log/pacman.log | tail -5

co se naposled instalovalo/aktualizovalo

tail -50 /var/log/pacman.log

pretty výpis posledních akcí (expac)

expac --timefmt='%Y-%m-%d %T' '%l\t%n' | sort -r | head -20

změnit důvod instalace (z dependency na explicit)

sudo pacman -D --asexplicit firefox

označit jako závislost (půjde uklidit přes -Rns)

sudo pacman -D --asdeps nějaký-balíček

═══════════════════════════════════════════
💡 TYPICKÝ WORKFLOW
═══════════════════════════════════════════

1. co mi žere místo?

expac -H M "%m\t%n" | sort -h | tail -20

2. co dělá tenhle balíček?

pacman -Qi <balíček>

3. můžu ho smazat? Co na něm závisí?

pactree -r <balíček>

4. odkud se vzal tenhle soubor?

pacman -Qo /cesta/k/souboru

5. úklid

sudo pacman -Rns $(pacman -Qtdq)
sudo paccache -rk2

#archlinux #pacman #linux #cli

Arch Tip týdne: pacman jako profík

📦 pacman umí mnohem víc než jen instalovat balíčky.
Tady jsou dotazy, které ti pomůžou pochopit, co máš v systému.

═══════════════════════════════════════════
🔍 ZÁKLADNÍ DOTAZY (-Q = QUERY)
═══════════════════════════════════════════

výpis všech nainstalovaných balíčků

pacman -Q

kolik balíčků mám?

pacman -Q | wc -l

jen explicitně nainstalované (bez závislostí)

pacman -Qe

jen závislosti (instalované jako "side effect")

pacman -Qd

balíčky z AUR / mimo oficiální repo

pacman -Qm

balíčky JEN z oficiálních repo

pacman -Qn

osiřelé balíčky (závislosti, které už nikdo nepotřebuje)

pacman -Qtdq

odstranění osiřelých

sudo pacman -Rns $(pacman -Qtdq)

═══════════════════════════════════════════
📋 pacman -Qi → INFO O BALÍČKU
═══════════════════════════════════════════

detailní info

pacman -Qi firefox

co uvidíš:

- verze, popis, URL

- licence

- závislosti (Depends On)

- co na něm závisí (Required By)

- volitelné závislosti (Optional Deps)

- velikost, datum instalace

- důvod instalace (Explicitly installed / Dependency)

rozšířené info (přidá Backup Files = konfiguráky chráněné při update)

pacman -Qii firefox

info z repa (i pro nenainstalované)

pacman -Si firefox

jen velikost balíčku

pacman -Qi firefox | grep "Installed Size"

řazení balíčků podle velikosti (potřebuje: pacman -S expac)

expac -H M "%m\t%n" | sort -h | tail -20

═══════════════════════════════════════════
📂 pacman -Ql → SEZNAM SOUBORŮ
═══════════════════════════════════════════

co všechno balíček nainstaloval

pacman -Ql firefox

jen binárky

pacman -Ql firefox | grep '/bin/'

konfigurační soubory balíčku (vše v /etc)

pacman -Ql firefox | grep '^firefox /etc'

počet souborů v balíčku

pacman -Ql firefox | wc -l

soubory nenainstalovaného balíčku (z repa)

nejdřív aktualizuj file database:

sudo pacman -Fy
pacman -Fl firefox

═══════════════════════════════════════════
🔎 pacman -Qo → KDO VLASTNÍ TENTO SOUBOR?
═══════════════════════════════════════════

který balíček nainstaloval daný soubor?

pacman -Qo /usr/bin/firefox

výstup:

/usr/bin/firefox is owned by firefox 123.0-1

najdi balíček podle příkazu v PATH

pacman -Qo $(which nvim)

najdi balíček, kterému patří soubor – i když ho nemáš nainstalovaný

sudo pacman -Fy
pacman -F /usr/bin/htop

═══════════════════════════════════════════
🛠️ pacnew / pacsave – CHRÁNĚNÉ KONFIGURÁKY
═══════════════════════════════════════════

Backup Files = soubory označené v balíčku jako "neredisej moji verzi"

Když přijde update a soubor jsi upravil, pacman vytvoří .pacnew

(nová verze z balíčku) a tvoji verzi nechá být.

seznam backup files konkrétního balíčku

pacman -Qii pacman | awk '/^Backup Files/,/^$/'

najdi všechny .pacnew/.pacsave v systému (čekající na merge)

sudo find /etc ( -name ".pacnew" -o -name ".pacsave" )

interaktivní merge (z pacman-contrib)

sudo pacman -S pacman-contrib
sudo pacdiff

═══════════════════════════════════════════
🌳 pactree → STROM ZÁVISLOSTÍ
═══════════════════════════════════════════

instalace (pokud nemáš)

sudo pacman -S pacman-contrib

co všechno balíček potřebuje (závislosti)

pactree firefox

obrácený strom – kdo závisí NA tomto balíčku

pactree -r glibc

omezení hloubky

pactree -d 1 firefox

jen názvy, bez ozdob

pactree -u firefox

grafický výstup (potřebuje: pacman -S graphviz)

pactree --graph firefox | dot -Tpng > firefox-deps.png

═══════════════════════════════════════════
🔧 BONUS – DALŠÍ UŽITEČNÉ DOTAZY
═══════════════════════════════════════════

hledání balíčku v repech

pacman -Ss firefox

hledání v nainstalovaných

pacman -Qs firefox

poslední full upgrade systému

grep "starting full system upgrade" /var/log/pacman.log | tail -5

co se naposled instalovalo/aktualizovalo

tail -50 /var/log/pacman.log

pretty výpis posledních akcí (expac)

expac --timefmt='%Y-%m-%d %T' '%l\t%n' | sort -r | head -20

změnit důvod instalace (z dependency na explicit)

sudo pacman -D --asexplicit firefox

označit jako závislost (půjde uklidit přes -Rns)

sudo pacman -D --asdeps nějaký-balíček

═══════════════════════════════════════════
💡 TYPICKÝ WORKFLOW
═══════════════════════════════════════════

1. co mi žere místo?

expac -H M "%m\t%n" | sort -h | tail -20

2. co dělá tenhle balíček?

pacman -Qi <balíček>

3. můžu ho smazat? Co na něm závisí?

pactree -r <balíček>

4. odkud se vzal tenhle soubor?

pacman -Qo /cesta/k/souboru

5. úklid

sudo pacman -Rns $(pacman -Qtdq)
sudo paccache -rk2

#archlinux #pacman #linux #cli

Arch Tip týdne: pacman jako profík

📦 pacman umí mnohem víc než jen instalovat balíčky.
Tady jsou dotazy, které ti pomůžou pochopit, co máš v systému.

═══════════════════════════════════════════
🔍 ZÁKLADNÍ DOTAZY (-Q = QUERY)
═══════════════════════════════════════════

výpis všech nainstalovaných balíčků

pacman -Q

kolik balíčků mám?

pacman -Q | wc -l

jen explicitně nainstalované (bez závislostí)

pacman -Qe

jen závislosti (instalované jako "side effect")

pacman -Qd

balíčky z AUR / mimo oficiální repo

pacman -Qm

balíčky JEN z oficiálních repo

pacman -Qn

osiřelé balíčky (závislosti, které už nikdo nepotřebuje)

pacman -Qtdq

odstranění osiřelých

sudo pacman -Rns $(pacman -Qtdq)

═══════════════════════════════════════════
📋 pacman -Qi → INFO O BALÍČKU
═══════════════════════════════════════════

detailní info

pacman -Qi firefox

co uvidíš:

- verze, popis, URL

- licence

- závislosti (Depends On)

- co na něm závisí (Required By)

- volitelné závislosti (Optional Deps)

- velikost, datum instalace

- důvod instalace (Explicitly installed / Dependency)

rozšířené info (přidá Backup Files = konfiguráky chráněné při update)

pacman -Qii firefox

info z repa (i pro nenainstalované)

pacman -Si firefox

jen velikost balíčku

pacman -Qi firefox | grep "Installed Size"

řazení balíčků podle velikosti (potřebuje: pacman -S expac)

expac -H M "%m\t%n" | sort -h | tail -20

═══════════════════════════════════════════
📂 pacman -Ql → SEZNAM SOUBORŮ
═══════════════════════════════════════════

co všechno balíček nainstaloval

pacman -Ql firefox

jen binárky

pacman -Ql firefox | grep '/bin/'

konfigurační soubory balíčku (vše v /etc)

pacman -Ql firefox | grep '^firefox /etc'

počet souborů v balíčku

pacman -Ql firefox | wc -l

soubory nenainstalovaného balíčku (z repa)

nejdřív aktualizuj file database:

sudo pacman -Fy
pacman -Fl firefox

═══════════════════════════════════════════
🔎 pacman -Qo → KDO VLASTNÍ TENTO SOUBOR?
═══════════════════════════════════════════

který balíček nainstaloval daný soubor?

pacman -Qo /usr/bin/firefox

výstup:

/usr/bin/firefox is owned by firefox 123.0-1

najdi balíček podle příkazu v PATH

pacman -Qo $(which nvim)

najdi balíček, kterému patří soubor – i když ho nemáš nainstalovaný

sudo pacman -Fy
pacman -F /usr/bin/htop

═══════════════════════════════════════════
🛠️ pacnew / pacsave – CHRÁNĚNÉ KONFIGURÁKY
═══════════════════════════════════════════

Backup Files = soubory označené v balíčku jako "neredisej moji verzi"

Když přijde update a soubor jsi upravil, pacman vytvoří .pacnew

(nová verze z balíčku) a tvoji verzi nechá být.

seznam backup files konkrétního balíčku

pacman -Qii pacman | awk '/^Backup Files/,/^$/'

najdi všechny .pacnew/.pacsave v systému (čekající na merge)

sudo find /etc ( -name ".pacnew" -o -name ".pacsave" )

interaktivní merge (z pacman-contrib)

sudo pacman -S pacman-contrib
sudo pacdiff

═══════════════════════════════════════════
🌳 pactree → STROM ZÁVISLOSTÍ
═══════════════════════════════════════════

instalace (pokud nemáš)

sudo pacman -S pacman-contrib

co všechno balíček potřebuje (závislosti)

pactree firefox

obrácený strom – kdo závisí NA tomto balíčku

pactree -r glibc

omezení hloubky

pactree -d 1 firefox

jen názvy, bez ozdob

pactree -u firefox

grafický výstup (potřebuje: pacman -S graphviz)

pactree --graph firefox | dot -Tpng > firefox-deps.png

═══════════════════════════════════════════
🔧 BONUS – DALŠÍ UŽITEČNÉ DOTAZY
═══════════════════════════════════════════

hledání balíčku v repech

pacman -Ss firefox

hledání v nainstalovaných

pacman -Qs firefox

poslední full upgrade systému

grep "starting full system upgrade" /var/log/pacman.log | tail -5

co se naposled instalovalo/aktualizovalo

tail -50 /var/log/pacman.log

pretty výpis posledních akcí (expac)

expac --timefmt='%Y-%m-%d %T' '%l\t%n' | sort -r | head -20

změnit důvod instalace (z dependency na explicit)

sudo pacman -D --asexplicit firefox

označit jako závislost (půjde uklidit přes -Rns)

sudo pacman -D --asdeps nějaký-balíček

═══════════════════════════════════════════
💡 TYPICKÝ WORKFLOW
═══════════════════════════════════════════

1. co mi žere místo?

expac -H M "%m\t%n" | sort -h | tail -20

2. co dělá tenhle balíček?

pacman -Qi <balíček>

3. můžu ho smazat? Co na něm závisí?

pactree -r <balíček>

4. odkud se vzal tenhle soubor?

pacman -Qo /cesta/k/souboru

5. úklid

sudo pacman -Rns $(pacman -Qtdq)
sudo paccache -rk2

#archlinux #pacman #linux #cli

Arch Tip týdne: pacman jako profík

📦 pacman umí mnohem víc než jen instalovat balíčky.
Tady jsou dotazy, které ti pomůžou pochopit, co máš v systému.

═══════════════════════════════════════════
🔍 ZÁKLADNÍ DOTAZY (-Q = QUERY)
═══════════════════════════════════════════

výpis všech nainstalovaných balíčků

pacman -Q

kolik balíčků mám?

pacman -Q | wc -l

jen explicitně nainstalované (bez závislostí)

pacman -Qe

jen závislosti (instalované jako "side effect")

pacman -Qd

balíčky z AUR / mimo oficiální repo

pacman -Qm

balíčky JEN z oficiálních repo

pacman -Qn

osiřelé balíčky (závislosti, které už nikdo nepotřebuje)

pacman -Qtdq

odstranění osiřelých

sudo pacman -Rns $(pacman -Qtdq)

═══════════════════════════════════════════
📋 pacman -Qi → INFO O BALÍČKU
═══════════════════════════════════════════

detailní info

pacman -Qi firefox

co uvidíš:

- verze, popis, URL

- licence

- závislosti (Depends On)

- co na něm závisí (Required By)

- volitelné závislosti (Optional Deps)

- velikost, datum instalace

- důvod instalace (Explicitly installed / Dependency)

rozšířené info (přidá Backup Files = konfiguráky chráněné při update)

pacman -Qii firefox

info z repa (i pro nenainstalované)

pacman -Si firefox

jen velikost balíčku

pacman -Qi firefox | grep "Installed Size"

řazení balíčků podle velikosti (potřebuje: pacman -S expac)

expac -H M "%m\t%n" | sort -h | tail -20

═══════════════════════════════════════════
📂 pacman -Ql → SEZNAM SOUBORŮ
═══════════════════════════════════════════

co všechno balíček nainstaloval

pacman -Ql firefox

jen binárky

pacman -Ql firefox | grep '/bin/'

konfigurační soubory balíčku (vše v /etc)

pacman -Ql firefox | grep '^firefox /etc'

počet souborů v balíčku

pacman -Ql firefox | wc -l

soubory nenainstalovaného balíčku (z repa)

nejdřív aktualizuj file database:

sudo pacman -Fy
pacman -Fl firefox

═══════════════════════════════════════════
🔎 pacman -Qo → KDO VLASTNÍ TENTO SOUBOR?
═══════════════════════════════════════════

který balíček nainstaloval daný soubor?

pacman -Qo /usr/bin/firefox

výstup:

/usr/bin/firefox is owned by firefox 123.0-1

najdi balíček podle příkazu v PATH

pacman -Qo $(which nvim)

najdi balíček, kterému patří soubor – i když ho nemáš nainstalovaný

sudo pacman -Fy
pacman -F /usr/bin/htop

═══════════════════════════════════════════
🛠️ pacnew / pacsave – CHRÁNĚNÉ KONFIGURÁKY
═══════════════════════════════════════════

Backup Files = soubory označené v balíčku jako "neredisej moji verzi"

Když přijde update a soubor jsi upravil, pacman vytvoří .pacnew

(nová verze z balíčku) a tvoji verzi nechá být.

seznam backup files konkrétního balíčku

pacman -Qii pacman | awk '/^Backup Files/,/^$/'

najdi všechny .pacnew/.pacsave v systému (čekající na merge)

sudo find /etc ( -name ".pacnew" -o -name ".pacsave" )

interaktivní merge (z pacman-contrib)

sudo pacman -S pacman-contrib
sudo pacdiff

═══════════════════════════════════════════
🌳 pactree → STROM ZÁVISLOSTÍ
═══════════════════════════════════════════

instalace (pokud nemáš)

sudo pacman -S pacman-contrib

co všechno balíček potřebuje (závislosti)

pactree firefox

obrácený strom – kdo závisí NA tomto balíčku

pactree -r glibc

omezení hloubky

pactree -d 1 firefox

jen názvy, bez ozdob

pactree -u firefox

grafický výstup (potřebuje: pacman -S graphviz)

pactree --graph firefox | dot -Tpng > firefox-deps.png

═══════════════════════════════════════════
🔧 BONUS – DALŠÍ UŽITEČNÉ DOTAZY
═══════════════════════════════════════════

hledání balíčku v repech

pacman -Ss firefox

hledání v nainstalovaných

pacman -Qs firefox

poslední full upgrade systému

grep "starting full system upgrade" /var/log/pacman.log | tail -5

co se naposled instalovalo/aktualizovalo

tail -50 /var/log/pacman.log

pretty výpis posledních akcí (expac)

expac --timefmt='%Y-%m-%d %T' '%l\t%n' | sort -r | head -20

změnit důvod instalace (z dependency na explicit)

sudo pacman -D --asexplicit firefox

označit jako závislost (půjde uklidit přes -Rns)

sudo pacman -D --asdeps nějaký-balíček

═══════════════════════════════════════════
💡 TYPICKÝ WORKFLOW
═══════════════════════════════════════════

1. co mi žere místo?

expac -H M "%m\t%n" | sort -h | tail -20

2. co dělá tenhle balíček?

pacman -Qi <balíček>

3. můžu ho smazat? Co na něm závisí?

pactree -r <balíček>

4. odkud se vzal tenhle soubor?

pacman -Qo /cesta/k/souboru

5. úklid

sudo pacman -Rns $(pacman -Qtdq)
sudo paccache -rk2

#archlinux #pacman #linux #cli

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #DeadLikeMe #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #DeadLikeMe #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #DeadLikeMe #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #DeadLikeMe #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

New #blog #post: Package Manager Tier List

https://rldane.space/package-manager-tier-list.html

1521 words

Note: this is a very off-the-cuff tier list, using speed as the main qualifier, but the article explains exceptions to that as it goes on.

cc: my wonderful #chorus: @joel @dm @sotolf @thedoctor @pixx @orbitalmartian @adamsdesk @krafter @roguefoam @clayton @giantspacesquid @Twizzay @stfn

(I will happily add/remove you from the chorus upon request! :)

#rlDaneWriting #blost #DeadLikeMe #Linux #BSD #RunBSD #FreeBSD #OpenBSD #NetBSD #Debian #Arch #pacman #AUR #Fedora #homebrew #flatpak #snap #OpenSuSE #RPM

With Hall Effect thumbsticks, impulse triggers, and two types of glow, bring the spirit of the arcade to your controller with the PAC-MAN Special Edition PowerA Wireless Controller. On sale now: amzn.to/4rxDWx0 #Games #RetroGaming #Xbox #Arcade #PacMan #BandaiNamco #GameDev #GamingSky #PromoSky

With Hall Effect thumbsticks, impulse triggers, and two types of glow, bring the spirit of the arcade to your controller with the PAC-MAN Special Edition PowerA Wireless Controller. On sale now: amzn.to/4rxDWx0 #Games #RetroGaming #Xbox #Arcade #PacMan #BandaiNamco #GameDev #GamingSky #PromoSky

Avui és el vintè aniversari de la publicació a casa nostra de "Namco Museum 50th Anniversary" per "GameCube" de #Nintendo 🕹🎮. #NamcoMuseum50thAnniversary #PacMan #Galaga #Gamecube #Shooter #Arcade #Videojocs #Gaming #VideoGames #RetroGaming #ClassicGaming

Avui fa 20 anys que ens arribava "Pac-Man World 3" per "Nintendo DS" de #Nintendo 🕹🎮. #PacManWorld3 #PacMan #NintendoDs #Plataformes #Videojocs #Gaming #VideoGames #RetroGaming #ClassicGaming #RetroGames #VideojocsAntics

Pac-Man: hoe een simpele gele bol een gaming legende werd

Pac-Man is een arcadegame uit 1980 die nog steeds wereldwijd gespeeld wordt en gaming heeft beïnvloed.

Lees meer: https://www.mastanet.com/artikel/pac-man-arcade-geschiedenis

#PacMan #arcadegame1980 #retrogames #Namco #PacMangeschiedenis #PacMangameplay #klassiekegames #gaminggeschiedenis #Mastanet

#pacman #tinygo #badge

#Nintendo agrega #PacMan, Mendel Palace y The Tower of Druaga del NES a #NintendoSwitchOnline y conviene darles un vistazo. El segundo es creación de Game Freak, el estudio de #Pokemon, y también de su creador, Satoshi Tajiri :3. https://universo-nintendo.com.mx/2026/04/08/pac-man-mendel-palace-the-tower-of-druaga-nintendo-switch-online/

Nintendo suma tres títulos de NES a la app de Switch Online, incluyendo Pac-Man y The Tower of Druaga

https://web.brid.gy/r/https://www.eurogamer.es/nintendo-suma-tres-titulos-de-nes-a-la-app-de-switch-online-incluyendo-pac-man-y-the-tower-of-druaga

Nintendo suma tres títulos de NES a la app de Switch Online, incluyendo Pac-Man y The Tower of Druaga

https://web.brid.gy/r/https://www.eurogamer.es/nintendo-suma-tres-titulos-de-nes-a-la-app-de-switch-online-incluyendo-pac-man-y-the-tower-of-druaga

Nintendo suma tres títulos de NES a la app de Switch Online, incluyendo Pac-Man y The Tower of Druaga

https://web.brid.gy/r/https://www.eurogamer.es/nintendo-suma-tres-titulos-de-nes-a-la-app-de-switch-online-incluyendo-pac-man-y-the-tower-of-druaga

Nintendo suma tres títulos de NES a la app de Switch Online, incluyendo Pac-Man y The Tower of Druaga

https://web.brid.gy/r/https://www.eurogamer.es/nintendo-suma-tres-titulos-de-nes-a-la-app-de-switch-online-incluyendo-pac-man-y-the-tower-of-druaga

¿Conflicto entre iptables y arptables en @archlinux?

No es un error, es una migración.

Al actualizar mi Arch me encontré con este mensaje. Lejos de ser un problema, es parte de la transición hacia #nftables como backend unificado.

🔍 ¿Qué está pasando?

El paquete moderno #iptables (1.8.11-4) ahora incluye funcionalidad ARP y Ethernet.

Ya no necesita paquetes separados como #arptables o #ebtables.

#pacman te avisa del conflicto para que no queden paquetes huérfanos.

(1/2)

To celebrate Pac-Man Day, I'm making myself 4 specialty “shots”, each based on one of the four original ghosts: Blinky, Pinky, Inky, and Clyde. Can you guess what’s in each one?#pixelart #PacManDay #8bitart #Pixology #PacMan

To celebrate Pac-Man Day, I'm making myself 4 specialty “shots”, each based on one of the four original ghosts: Blinky, Pinky, Inky, and Clyde. Can you guess what’s in each one?#pixelart #PacManDay #8bitart #Pixology #PacMan

To celebrate Pac-Man Day, I'm making myself 4 specialty “shots”, each based on one of the four original ghosts: Blinky, Pinky, Inky, and Clyde. Can you guess what’s in each one?#pixelart #PacManDay #8bitart #Pixology #PacMan

Aquest any es compleixen 20 anys que arribava "Namco Museum 50th Anniversary" per "PlayStation 2" de #Sony 🕹🎮. #NamcoMuseum50thAnniversary #PacMan #Galaga #Playstation2 #Shooter #Arcade #Videojocs #Gaming #VideoGames #RetroGaming #ClassicGaming

Shelly - Eine Paketverwaltung für Arch

Auf der Suche nach einer Paketverwaltung für Arch-basierte Distributionen ist der Autor auf Shelly gestossen. Diese Anwendung kommt Manjaros Pamac nahe.

#Paketverwaltung #CachyOS #pacman #Pamac #Shelly #Linux

https://gnulinux.ch/shelly-eine-paketverwaltung-fuer-arch

Avui fa 20 anys que ens arribava "Namco Museum 50th Anniversary" per "Xbox" de #Microsoft 🕹🎮. #NamcoMuseum50thAnniversary #PacMan #Galaga #Xbox #Shooter #Arcade #Videojocs #Gaming #VideoGames #RetroGaming #ClassicGaming #RetroGames #VideojocsAntics

:arch: PacHub | Una potente interfaz para Pacman y AUR creada con GTK4 y libadwaita 👇

#GNOME #ArchLinux #GTK4 #Pacman #AUR #Linux

Picross S Namco Legendary Edition (Switch): COMPLETED!

It’s been a while since I last completed a Picross game, but I’ve actually been playing this one off and on for six months or more. It is, as they always are, more of the same – a polished, Jupiter developed, game of Picross with loads of puzzles.

The difference this time, however, is that it’s Namco themed. Specifically, 8-bit Namco games from the 1980s. Pixel representations of the likes of Dig Dug, The Tower of Druaga, Pac-Man, Rally-X, Mappy, Xevious and several Japanese titles I’ve never heard of, all in Picross puzzle form. Excellent.

Aside from the music. I mean, I love the Mappy theme tune as much as anyone, but the same 8 seconds over it repeating overandoverandoverandover for a 45 minute puzzle? Nah mate, that got turned down fast.

Picross S Namco Legendary Edition (Switch): COMPLETED!

It’s been a while since I last completed a Picross game, but I’ve actually been playing this one off and on for six months or more. It is, as they always are, more of the same – a polished, Jupiter developed, game of Picross with loads of puzzles.

The difference this time, however, is that it’s Namco themed. Specifically, 8-bit Namco games from the 1980s. Pixel representations of the likes of Dig Dug, The Tower of Druaga, Pac-Man, Rally-X, Mappy, Xevious and several Japanese titles I’ve never heard of, all in Picross puzzle form. Excellent.

Aside from the music. I mean, I love the Mappy theme tune as much as anyone, but the same 8 seconds over it repeating overandoverandoverandover for a 45 minute puzzle? Nah mate, that got turned down fast.

Picross S Namco Legendary Edition (Switch): COMPLETED!

It’s been a while since I last completed a Picross game, but I’ve actually been playing this one off and on for six months or more. It is, as they always are, more of the same – a polished, Jupiter developed, game of Picross with loads of puzzles.

The difference this time, however, is that it’s Namco themed. Specifically, 8-bit Namco games from the 1980s. Pixel representations of the likes of Dig Dug, The Tower of Druaga, Pac-Man, Rally-X, Mappy, Xevious and several Japanese titles I’ve never heard of, all in Picross puzzle form. Excellent.

Aside from the music. I mean, I love the Mappy theme tune as much as anyone, but the same 8 seconds over it repeating overandoverandoverandover for a 45 minute puzzle? Nah mate, that got turned down fast.

Picross S Namco Legendary Edition (Switch): COMPLETED!

It’s been a while since I last completed a Picross game, but I’ve actually been playing this one off and on for six months or more. It is, as they always are, more of the same – a polished, Jupiter developed, game of Picross with loads of puzzles.

The difference this time, however, is that it’s Namco themed. Specifically, 8-bit Namco games from the 1980s. Pixel representations of the likes of Dig Dug, The Tower of Druaga, Pac-Man, Rally-X, Mappy, Xevious and several Japanese titles I’ve never heard of, all in Picross puzzle form. Excellent.

Aside from the music. I mean, I love the Mappy theme tune as much as anyone, but the same 8 seconds over it repeating overandoverandoverandover for a 45 minute puzzle? Nah mate, that got turned down fast.

Episódio 172 – Dossiê Namco – Parte B

https://retropolis.com.br/2026/03/18/episodio-172-dossie-namco-parte-b/

#Podcast #Bosconian #Galaga #MSX #namco #Namcot #PacMan #PCEngine #rallyx

#my9games list marked as my favorites since 2013.

Add your 9 favorites on the next link:
https://my9games.com/

#RandyandManilla #FixItFelixJr #SuperMarioBros #Sonic #PacMan #Nintendo #Sega #Disney #BandaiNamco #Mar10 #MarioDay #WreckItRalph #Gaming #Indiegames #Sonic35thAnniversary #NES #Retro

#my9games list marked as my favorites since 2013.

Add your 9 favorites on the next link:
https://my9games.com/

#RandyandManilla #FixItFelixJr #SuperMarioBros #Sonic #PacMan #Nintendo #Sega #Disney #BandaiNamco #Mar10 #MarioDay #WreckItRalph #Gaming #Indiegames #Sonic35thAnniversary #NES #Retro

Episódio 172 – Dossiê Namco – Parte A

https://retropolis.com.br/2026/03/04/episodio-172-dossie-namco-parte-a/

#Podcast #Arcade #Bosconian #celofane #compile #DigDug #Fantastic #ForceFeedback #Galaga #Galaxian #GeeBee #Hydlide #mappy #microcomputador #MsPacMan #namco #Namcot #NES #Nintendo #Pacman #papel #PCEngine #podcast #PolePosition #Puckman #rallyx #Retrocomputao #retrogaming #Retrpolis #RidgeRacer #shmup #Splatterhouse #TESoft #Taito #videogame #Xevious

Episódio 172 – Dossiê Namco – Parte A

https://retropolis.com.br/2026/03/04/episodio-172-dossie-namco-parte-a/

#Podcast #Arcade #Bosconian #celofane #compile #DigDug #Fantastic #ForceFeedback #Galaga #Galaxian #GeeBee #Hydlide #mappy #microcomputador #MsPacMan #namco #Namcot #NES #Nintendo #Pacman #papel #PCEngine #podcast #PolePosition #Puckman #rallyx #Retrocomputao #retrogaming #Retrpolis #RidgeRacer #shmup #Splatterhouse #TESoft #Taito #videogame #Xevious

Episódio 172 – Dossiê Namco – Parte A

https://retropolis.com.br/2026/03/04/episodio-172-dossie-namco-parte-a/

#Podcast #Arcade #Bosconian #celofane #compile #DigDug #Fantastic #ForceFeedback #Galaga #Galaxian #GeeBee #Hydlide #mappy #microcomputador #MsPacMan #namco #Namcot #NES #Nintendo #Pacman #papel #PCEngine #podcast #PolePosition #Puckman #rallyx #Retrocomputao #retrogaming #Retrpolis #RidgeRacer #shmup #Splatterhouse #TESoft #Taito #videogame #Xevious

Episódio 172 – Dossiê Namco – Parte A

https://retropolis.com.br/2026/03/04/episodio-172-dossie-namco-parte-a/

#Podcast #Arcade #Bosconian #celofane #compile #DigDug #Fantastic #ForceFeedback #Galaga #Galaxian #GeeBee #Hydlide #mappy #microcomputador #MsPacMan #namco #Namcot #NES #Nintendo #Pacman #papel #PCEngine #podcast #PolePosition #Puckman #rallyx #Retrocomputao #retrogaming #Retrpolis #RidgeRacer #shmup #Splatterhouse #TESoft #Taito #videogame #Xevious

Episódio 172 – Dossiê Namco – Parte A

https://retropolis.com.br/2026/03/04/episodio-172-dossie-namco-parte-a/

#Podcast #Arcade #Bosconian #celofane #compile #DigDug #Fantastic #ForceFeedback #Galaga #Galaxian #GeeBee #Hydlide #mappy #microcomputador #MsPacMan #namco #Namcot #NES #Nintendo #Pacman #papel #PCEngine #podcast #PolePosition #Puckman #rallyx #Retrocomputao #retrogaming #Retrpolis #RidgeRacer #shmup #Splatterhouse #TESoft #Taito #videogame #Xevious

With her pink bow and power pellets, experience the thrill of the chase as you eat your way through mazes full of ghosts with the Ms. Pac-Man Nano Player! On sale now: amzn.to/4r6R6As #Games #RetroGaming #Arcade #MsPacMan #PacMan #BandaiNamco #Retro #Vintage #Art #GameDev #GamingSky #PromoSky