To explain

There are 2 Error struct / enum declarations, probably in separate files

To the ?, they are different types and cannot be converted from one to the other (because they are two disparate structs that happen to have the same name, but can have different bodies)

To fix this

You can either use .some_func_result().map_err(|err| /* conversion here/*)?; +

Or you can impl From<Error1> for Error2

And you should also name it ThingError, so you can visually differentiate the two

+ There are like 10 different mapping functions, depending on if you’re using an option or a result

I never remember which one specifically i need, (unwrap_or, map_or, map_or_else, ok, ok_or)

I usually just hunt through the auto complete list until i find the function signature that gives me what i need

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

I mean, you just need to look at the conflicting files, fix up the code, then stage those changes and pop a new commit

There’s no “special” merge conflict resolution commit “type”

As for fixing the code itself, I usually look at what changed between both versions, and then re-author the code such that both changes make “sense”

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

All distros are equivalent, as far as software is concerned. They all have access to the same open source software, and Flatpak; AppImage; and Snap can be used for extra portability.

Think of a distro like a pre-configured image of linux. You can always change the configuration later, if you desire. For example, the Desktop Environment. All you have to do is just install a different DE package (usually via command line)

The DE has a major impact on user experience. Use KDE plasma for a more windows-familiar experience, or Gnome for a more Mac-familiar experience. Or experiment with others

The Linux Experiment is a good resource

Linux is already at 4.5%

https://gs.statcounter.com/os-market-share/desktop/worldwide/

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