Realistically the only advantage of Plex is being able to watch it over the internet without a VPN. Which means it makes it easier to get friends and family access to your server or to access it yourself from random smart tvs outside your house.

If you only watch at home or have a fire stick that you take with you to watch abroad or your friends/family members have one and can setup a VPN on it it’s not needed.

You do know that there are security issues with that, right? For example, if someone can guess your media files they can watch them https://github.com/jellyfin/jellyfin/issues/5415

Maintenance is a breeze, setup is a bitch. I switched from Arch a short while back, getting the initial thing up to the same level as what I had before took me a few weeks, and a few months to get to the current iteration. But then to setup my other system to the same level was a couple minutes and I had the exact same system on both machines.

Honestly I can’t see myself going back, the assurances when I do a change/update that I’ll be able to rollback if anything goes wrong it’s just too valuable to me. If you’re willing to pay the price of the initial setup it’s absolutely worth it, but that price is high and the learning curve is steep, so it’s not for everyone. If you’re interested I strongly recommend you check out https://youtube.com/@vimjoyer and maybe setup a VM or an old machine and get your feet wet and learn the basics.

When I first started using Linux I used Kate, I know, I know, not command line, but I didn’t needed a command line editor for my own computer. Eventually I started using nano for quick edits and that became my default CLI editor for a while. I don’t remember what I used as an IDE back then, but maybe it was Eclipse, although I think it was mostly just Kate.

Eventually I decided to learn either VI or Emacs, and a friend who used Emacs pushed me to that side. I ended up switching everything to emacs, CLI, IDE, I even learnt org-mode and had tables and presentations in it.

Eventually my pinky started to hurt too much, so I switched to Pycharm for python, and kept emacs for C++, text edits and org-mode. I ended up slowly switching emacs everywhere and reverted to nano.

Some years back I decided to properly learn vim. I have been using nvim for a few years, and while it’s not the everything tool that emacs was for me, it’s still pretty darn useful. I also haven’t become a movement ninja and oftentimes I go wwwwww to get where I want to be. But still, there are some very nice shortcuts that I use a lot like Change Inside/Around or Delete X lines. Macros are cool, and sometimes feel magical, but other times they don’t work like I expected and I can’t figure out why. I don’t see myself changing to something else, the ubiquity of vim shortcuts in other programs makes it very convenient when I have to use something else.

Everyone who said proxmox didn’t read your post to the end. Proxmox is great for people who want a machine to just self-host things and don’t care about how things work. You don’t seem like that sort of person, and you also mentioned Moonlight which will be annoying to do on proxmox as it’s not intended for that use case.

Every system capable of being used as a Moonlight client can run self-hosted services, but the other way around is not true. So it’s better to start with the Moonlight part.

So, with that in mind I imagine you want this machine to be plugged to a TV in the living room or something similar, so it needs to have a GUI, and the GUI probably needs to be something you can navigate with a controller (although the new Steam controller probably increases that definition dramatically).

You will already have one system with a GUI, so it’s easier to use the same thing. Really, don’t overthink this, if it’s good for general use it’s good for self-hosting, and you don’t want to have to learn how to solve the same problem in multiple ways because of different distros. In the future considering different distros makes sense, but when you’re just getting started nailing the basics is easier with consistency across systems. Think about it this way, if you were learning how to write mixing cursive and print at the same time would be harder than choosing one and then learning the other.

But why proxmox is great? It’s because it makes it easy and gives you a GUI to add services. How hard is it to do the same on Linux using docker? Ssh into the server, edit a small text file and run a single command, all of which should be easy for you since you’ve probably done this in the past, but for most people that is very hard and that is where proxmox shines.

Don’t believe me? You said Jellyfin, this is the whole Jellyfin file with comments:

# Services that this file creates
services:
  # Name of the service, it can be whatever you want
  jellyfin:
    # Image this server runs, this is what tells what the service is
    image: lscr.io/linuxserver/jellyfin:latest
    # Volumes to mount. In the format <local>:<inside the image>
    # So this will mount the ./jellyfin folder inside /config for the image
    # some services require specific folders inside of them, e.g. /config to store jellyfin's configs, otherwise the folder would get lost with every restart of the service 
    volumes:
      - ./jellyfin:/config
    # Rarely needed, but this gives hardware access to the image. Specifically access to the /dev/dri device
    # Jellyfin specifically benefits from this for transcoding 
    devices:
      - /dev/dri:/dev/dri
    # This shows what ports you want to expose, again in the format <local>:<inside the image>
    # So if you want Jellyfin on port 8080 on your machine you don't need to change settings, just do 8080:8096
    ports:
      - 8096:8096
      - 8920:8920
      - 7359:7359/udp
    # This tells docker to restart the service if it crashes, unless you've stopped it
    restart: unless-stopped

That’s it, and this is one of the most complicated ones out there, here’s a simple one:

services:
  radarr:
      image: lscr.io/linuxserver/radarr:latest
      volumes:
        - ./radarr:/config

Of course there’s more to those files, and lots of extra configurations to be used, but the core is very simple and the rest is just needed for special cases.

I don’t get how that output showcases anything, unless he had run that against a known instance of forgejo so the owners of that instance could confirm that he actually executed code. But he’s only showing a text file, that’s like saying look I hacked super_secure_self_hosted_service:

python hack_it.py localhost:3000

Hacked!

For all we know chain_alpha.py is just a bunch of prints.

Also, even if it is real (which I don’t really doubt, but I have seen no proof) holding the information instead of properly disclosing it is just childish. It’s not a carrot methodology, it’s a stick one, and one without a carrot. This is the sort of thing you do to big companies with no morals, doing it to a small open source project is just wrong, they don’t have the manpower or money to redo the investigation you already did. Release a CVE, talk to the devs, and/or push a PR, but saying “I found a vulnerability but I won’t tell you about it” is just dumb.

That article has lots of issues:

17% of the most popular Rust packages contain code that virtually nobody knows what it does

That’s not true at all, the article where he got that information from says:

Only 8 crate versions straight up don’t match their upstream repositories. None of these were malicious: seven were updates from vendored upstreams (such as wrapped C libraries) that weren’t represented in their repository at the point the crate version was published, and the last was the inadvertent inclusion of .github files that hadn’t yet been pushed to the GitHub repository.

So, of the 999 most popular crates analyzed 0% contains code nobody knows what it does.

He then lists some ways packages can be maliciously compromised:

1. Steal credentials and impersonate a dev
2. Misleading package names
3. Malicious macros (this one is interesting, had never considered it before)
4. Malicious build script

And his solutions are:

1. Bigger std library (solves none of the above)
2. Source dependencies (solves none of the issues he showed, only the issue that happens in 0% of packages where binary doesn’t match the source and is detectable)
3. Decentralized packages (which worsens every security concern)
4. Centralized Checksum database (so a centralized package manager is bad, but a centralized Checksum index is good? How does that work?)

Honestly I can’t take that article seriously, it grossly misinterpreted another study, presents problems that exist on every single package manager ever, doesn’t propose ANY valid solution, and the only thing he points to as a solution suffers from ALL of the same issues and then some.

You’re completely missing the point. Discord is a chat app, not a package manager, therefore it should NOT update things EVER. You’re complaining that discord tries to do something it shouldn’t, fails and somehow you seem to think that’s pacman’s fault.

The “issue” doesn’t exist on flatpaks because discord probably checks if it’s installed via flatpak and runs an update using the flatpak command without your say so. The “solution” is to stop discord from trying to be “smart” and failing and let it be updated when pacman decides to.

The idea of a package manager is to let it manage your packages, if you want self-updating apps you don’t need a package manager, and good luck with dependencies and overlapping libraries.

I have only ever had this issue with discord on arch.

The issue you describe is not Arch specific and it’s not an issue. Using a package manager means using a program to manage your packages. Things can’t auto-upgrade, that breaks the point of a package manager.

Whenever discord has an update, it will not fetch the update, but it tells me that an update can be downloaded.

Of course, if you install discord through pacman, then pacman manages the update.

As for the JSON file that’s a very hacky approach, discord shouldn’t outright fail to launch if there is an update. And in fact the Arch wiki says it has a flag to skip the version check completely:

To disable the update check, add the line “SKIP_HOST_UPDATE”: true to ~/.config/discord/settings.json. If the file does not exist, create it and add the following:

~/.config/discord/settings.json

{
  "SKIP_HOST_UPDATE": true
}

More info on https://wiki.archlinux.org/title/Discord

What is the air branch? Discord has a package on pacman, so it should just get updated with your normal system update, there’s no config or anything that could prevent that, pacman doesn’t care. What JSON do you have to edit and why?

All of the things you mentioned are annoying level problems.

ATMs

Card payment should still work, ATMs are more of a footnote in today’s world. I can’t even remember the last time I used one. If I were to use one and it didn’t worked it would be annoying.

There is a lot of industrial machinery running Windows 98 or XP to this day.

And there are lots that don’t. Plus, wine has excellent support for old windows versions, I would be very surprised if something didn’t just worked. So there would be some downtime while people annoyingly set things up with wine.

A lot of POS devices too.

And a lot of POS don’t, the ones that do would have to change OS, an annoyance.

Almost all accounting is done on Windows.

The ones that don’t would receive lots of new clients, and the rest would leave clients annoyed while adapting.

The amount of chaos if it disappeared would be immense

I think you’re probably exaggerating the proportions, nearly 100% of the hardware that runs Windows runs Linux. Yes, there would be some chaos until things migrate, but there are alternatives that are reachable and usable.

Linux is probably still worse because it would mean that more than half of smartphones are suddenly bricked,

That’s an annoyance. It’s not just some phones, it’s absolutely every network connected device that is not a Windows or apple thing. If you Google something on your phone yo go through possibly 20 different Linux devices back and forth.

literally all of the internet just stops working

This is the big one, removing Linux menas breaking the internet (and most intranets). And it’s not breaking one thing or another, it’s breaking every single internet service, the ATMs in your windows example wouldn’t work, nor would any PoS, since they usually depend on inventory management and card connectivity.

And it’s not a “until people reinstall their system” deal, it’s breaking in an essentially unrepairable way. There’s a very high chance that outside of a very small subset of devices there’s just no alternative to Linux. That’s the difference, Windows disappearing is a hiccup while things adapt, Linux disappearing is chaos without a foreseeable solution, 90% of electronics become e-waste.

Yup, that sounds like a good approach. I could even see people doing Pacman -> Flatpaks -> AUR and it would make sense to me.

What makes it confusing to you?

Your question is not Arch specific, it’s “should I use flatpaks?” And the answer in my opinion is probably no.

Flatpaks are a good idea to isolate certain applications and to provide a uniform way of installing packages. So there might be some apps that are not available in your native package manager, but do provide flatpaks. For those cases flatpaks are probably preferred. But Arch based distros have the AUR, so there are a lot of apps that aren’t packaged for Arch that you can still get as a native package. Sure, using the AUR is risky and if you’re not on actual Arch things might break sporadically because of mismatched dependencies (although I think CachyOS is full parity of packages with Arch, so that’s maybe more of a Manjaro warning).

But flatpaks are clunky, bloated, require annoying permissions to be set to do basic things, and require you to update two package managers to do a full system update. They are more appealing for systems where you don’t want to give users root access but still allow them to install programs, but for your own computer I have never seen the appeal.

Yes, that should work, but as someone who went through that phase before BTRFS was a thing keeping /home in a separate partition helps quite a lot, because then reinstalling the system is just a 15 min afair and you’re mostly back where you were before except some programs you might have installed that you will need to do so again.

The next logical step for me was to keep a list of those programs, so I could just run a single command and get all of them installed. That eventually evolved into convincing me to use Gentoo, since it has this concept baked into the system. But compiling everything wasn’t for me, so I went back to Arch where I stayed for over a decade. And even though I almost never broke my system again, I always had that fear. I even switched to BTRFS when it became more stable, but never had to use a snapshot, so can’t help you on how much it restores.

Recently I’ve migrated to NixOS, and I’m very happy with it. The appeal of it for me was how the system is declared, which is a very advanced version of my packages in a file that also includes configurations. This makes it so that making changes to your system requires you to modify those files and rebuild your system, and at boot time you can select from the previous generations of the system in case you broke something. In short, this makes your system unbreakable because worst case scenario you boot into the previous generation that worked and figure out what you did wrong.

That being said, it’s learning curve is very steep, but the payoff for those of us who like to tinker is huge. If you’re interested I recommend checking vimjoyer’s YouTube channel, he has several videos about it, and since you’re already used to running things in VMs to test it should be easy for you to get started. And the best thing is that once you’re done with configuring the VM, almost the exact same config would work on your main machine out of the box and give you the exact same system (the only caveat is that there’s one file that relates to hardware which would have to be different, but it gets auto-generated during the install process).

That reminds me of something I read once: If every copy of Windows were to magically disappear, some people would be annoyed. If every copy of Linux were to magically disappear, it would be utter chaos and absolutely nothing would work.

Honestly that’s probably a good use case for LLMs, mostly because there are enough Linux forums that there will be enough content for it to scrape. Just be weary as it can hallucinate or worse use joke answers as real and tell you to run :(){ :|:& };: because someone made a joke saying that was the way to solve your issue in a forum.

I agree with the man pages being very heavy, which is why I like https://github.com/tldr-pages/tldr there’s also a web app if you prefer that https://tldr.sh/ in short its a condensed man page to the most common cases for a tool. It’s less versatile than LLMs, but it might give you confirmation on the commands the LLM is telling you to run.

Overall I think yours is a good approach, just be mindful about wrong commands.

The moment you think you might possibly need documentation is the moment you should seriously consider using Ansible or similar to orchestra things. Sure, it’s annoying for a single server, but it is the best form of documentation there is.

I know you’re not me because I’m definitely not going slowly hahaah

Hi, been on Linux for over 20 years now. Very recently (less than a month ago) I switched my personal system to NixOS, I also switched one of my servers to it. Some of my other systems are on Arch as that’s what I was using before. My work computer is on Ubuntu as that is company issued.

I liked Arch because of its simplicity and the AUR, but I missed the package sets from Gentoo, NixOS is excellent because it brings the package lists and also includes configuration on them. A pain to do the initial setup, but then you get reproducible systems very easily and most of the time you want your systems to be mostly the same.