at least it’s not on top of js!

jellyfin is a streaming server. get yourself a domain name and you can connect your apps to it from anywhere.

that’s what the robot arm with the suction cup on it is for

i’m usually on your side in situations like this, i like my software stable. but this this very much apples to oranges.

pew also seems like it’s only a venv manager, rather than a complete packaging system with dependency management, build scripts, and helpers. and it hasn’t been updated in five years.

oh no…

wait hang on, what? source on that?

i’m glad you found it useful, best of luck :)

this is more focused for sure, but it lacks the enthusiasm of the original. if i was trying to do this for work, i would appreciate how quickly it gets to the point. however, it no longer reads like this is something you’re interested in. it reads a bit wooden. i get that would happen after you’ve been told to correct your style though.

to be clear, the original article doesn’t need to be rewritten. for the future though, when you want to tell the story of how you got something working, include your reasons for doing something a certain way. if you need a self-inflicted complication, that’s not really a part of it (unless it’s funny)

your writing overall is good! it’s just a matter of information priority.

here’s a tip, dunno how applicable it is but i use it when writing technical documentation:

for each step, explain to yourself why you’re doing it the way you are. if it turns out you caused the step to be needed, rather than it being required, you probably need to rethink, or at least add the explanation to the text.

this guide, and the previous one, have a lot of weird superfluous steps. like, why use a command that includes nvim and then ask people to change it instead of just saying “edit the file”? why symlink systemd stuff to your own home directory?

the info is good, but having to separate the actually useful stuff from things that are specific to your config makes it less useful.

this! i got my first vista experience on a laptop with a Turion and 2GB of RAM and it was really smooth. bit too chunky for my taste ux-wise but it was solid. first bluescreen i got on that machine was after installing W7.

then the GPU melted its own solder after a few years and that machine was relegated to server duty.

unfortunately no, this machine is running an rdna3 card with amdgpu-pro. i should note that this only started happening in plasma6, v5 was not affected.

The right monitor is indeed first when enumerating, but it’s also an old-ass monitor that runs over DVI while the newer monitor is on HDMI since i can’t get it to its correct refresh rate otherwise. no way to swap them around i’m afraid.

I’ve done the primary switch trick before, and it works, but it’s just as temporary as just killing plasmashell, and that’s less keystrokes. deleting the cache also works for a boot or two, but as you say it’s a bit of a nuclear option.

Honestly, part of the reason i’m asking here is that i can’t navigate the kde bugtracker. I’ve tried looking for issues relating to kwin, plasmashell, desktop, graphical errors, but i either get thousands of vaguely related issues or nothing.

Good info. thanks.

One could easily make a client app

sure, and convince people to switch. it’s been done before of course but it’s a big effort. And anyway, the main point with the closed-server issue is that it’s impossible to know what the server does other than serving packages. this is true for other package repositories to a certain extent since there’s no real guarantee that they run the source code they show, but there’s a distributed trust network there. as for the snap store, they could be doing anything in there.

KDE also maintains most of the flathub.org packages for KDE apps.

what i was trying to get at is that they’re not hosting their own thing. they do host their own flatpak repo but it seems to be only for nightlies so that point wasn’t as strong as i originally thought.

Canonical are the primary employers of a lot of Debian developers, including to do Debian maintenance or development. This includes at least one of the primary developers of apt.

that does not mean that the particular developer agrees with or even approves of the snap thing. it’s good to know though. i know they upstream, but that’s sort of the bare minimum expected of them.

i’ve not really used ubuntu desktop lately, but i’ve been hearing more complaints from friends about it deciding to install snaps instead of debs lately. steam was a big one that a friend had trouble with, and they just installed that though apt i’m pretty sure.

the thing people dislike about that is that you’re silently moved from an open system to a closed-source one.

Debian’s .deb hosting is completely open and you can host your own repository from which anyone can pull packages just by adding it to the apt config. fedora, suse, arch, same thing.

only Canonical can host snaps, and they’re not telling people how the hosting works. KDE seems to upload their packages to the snap store for Neon, judging from their page.

also, crucially, canonical are not the ones doing the maintenance for those apt packages. the debian team does that.

learn kakoune or helix, become even more entrenched.

i vastly prefer the object-verb keybinds to vim’s verb-object, but now i can’t even find bindings for other editors so i’m permanently stuck now