Imo, it’s nice to see tools written in a memory safe systems language

Especially if you use a lot of them. More utility, less attack surface

It can be useful if you want a different desktop layout for different use cases

I set up a Personal activity, and a Work activity, with different backgrounds and different apps pinned to the taskbar. That helps maintain a “virtual” separation of work and personal life, and helps me not screw off on discord as much

Well, it would if i actually used it

Activities let you change the desktop layout, panels, wallpapers, etc.

Virtual desktops keep the desktop settings

I still stand by my assumption that anyone complaining about systemd has never tried to configure SysVInit scripts before

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