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

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

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

I enabled testing repos for KDE 6.0 early access, and they include an overlay like this that says it’s a test release

Despite thinking that was a good idea, it felt a little like this, lol

I would use it, if KDE plasma would support it in their settings GUI

Arch621

This is true

Although, i find this isn’t as much an issue if you use python’s STL as much as you can

Pathlib and shutil are really handy for file manips

But, yea interfacing with external CLI utilities like git is a PITA

Oh there’s also xonsh which is just a shell built put of python

I dunno really, something about tech support and no money

I was having a hard time with the fursuit, and she just said “forget it” after the third time i mentioned GNU/Linux

/s