Buggies? Or just “furries”

There are a surprising number of moth and bee 'sonas, but the terms aren’t well defined

Can confirm, “scalies”

For birds it’s “avian”

I run Arch, so docker was the easiest method of installation.

Rather than try and figure out how to install a .deb manually (and lose package manager perks)

Vscode and dotnet core (5+) work well on linux

You can also run SQL Server via docker

The technology behind the registry is fine (which is what I think @VinesNFluff meant)

But it’s execution in Windows was ass

In theory, a configuration manager with DB-like abilities (to maintain relationships, schematic integrity, and to abstract the file storage details), isn’t a bad idea

But the registry as it is today is pure pain

I’ve been running Linux for 4 years, but this still hurts to read

that is a little more complicated

p.communicate() will take a string (or bytes) and send it to the stdin of the process, then wait for p to finish execution

there are ways to stream input into a running process (without waiting for the process to finish), but I don’t remember how off the top of my head

from shutil import which
from subprocess import Popen, PIPE, run
from pathlib import Path

LS   = which('ls')
REV  = which('rev')

ls   = run([LS, Path.home()], stdout=PIPE)

p = Popen([REV], stdin=PIPE, stdout=PIPE)
stdout, stderr = p.communicate(ls.stdout)

print(stdout.decode('utf-8'))

nushell is pretty good. I use it for my main shell

although, i still prefer writing utilities in python over nu scripts

just use python instead.

• wrap around subprocess.run(), to call to system utils
• use pathlib.Path for file paths and reading/writing to files
• use shutil.which() to resolve utilities from your Path env var

Here’s an example of some python i use to launch vscode (and terminals, but that requires dbus)

from pathlib import Path
from shutil import which
from subprocess import run

def _run(cmds: list[str], cwd=None):
    p = run(cmds, cwd=cwd)

    # raises an error if return code is non-zero
    p.check_returncode()

    return p

VSCODE = which('code')
SUDO   = which('sudo')
DOCKER = which('docker')

proj_dir = Path('/path/to/repo')

docker_compose = proj_dir / 'docker/'

windows = [
  proj_dir / 'code',
  proj_dir / 'more_code',
  proj_dir / 'even_more_code/subfolder',
]
for w in windows:
  _run([VSCODE, w])

_run([SUDO, DOCKER, 'compose', 'up', '-d'], cwd=docker_compose)

Unless Valve has said otherwise, I doubt SteamOS is going to be released for desktop. SteamOS is basically just Arch + kde plasma but with tweaks targeting the SteamDeck hardware

The kernel does stuff like

• process and CPU task management
• hardware abstraction
• memory management (at the process level),
• file system managment
• and resource isolation (such as randomized memory addresses (ASLR))

The rest of the OS provides the actual software that users interact with, like

• file managers
• desktop rendering and window management
• settings menus
• sound mixing between applications
• graphics rendering

How are you holding up?

Because I am a potato

You called?

It’s not a permanent one and it works for the time being, can’t see the reason for the downvotes honestly.

It’s just a bad idea in general. A better option would be to patch the binary to use 15. They both have the issue of forcing paru to work with a library it wasn’t explicitly designed for, but symlinking (or copying) 15 to 14 forces the hack to be “system wide” instead of restricted to a single binary

as well, your solution is “temporary” only if you remember to fix it, vs patching which is (by default) overwritten the next time paru is updated

it “works”, but it’s not something i’d recommend someone else do

You can either patch the binary

sudo patchelf --replace-needed libalpm.so.14 libalpm.so.15 "$(which paru)"

Or install paru-git

sudo pacman -S --needed base-devel
git clone https://aur.archlinux.org/paru-git.git
cd paru-git
makepkg -si

Or do both, patch the binary, then use it to install paru-git (which is what i did)

I love arch, but I’m also a pedantic computer nut

It’s not for everyone

this looks very interesting

although, i wonder how they’re able to get full system metrics, running within flatpak

Same boat

I effing love arch and kde plasma, but nothing I’ve ever used has felt like a true replacement for Task Manager

For a while, I had to do this after every kernel update

Turns out, i accidentally had two /boot folders. One was is own partition, and the other was on the rootfs partition. When Arch booted, the separate partition was mounted over the rootfs /boot dir, “shadowing” it

Except, UEFI / GRUB was still pointing to the rootfs partition. So when pacman installed a kernel update, it wasn’t able to update the kernel that UEFI was booting, but it was able to update the kernel modules

Kernel no likey when kernel modules are newer than the kernel itself

Idiocracy