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.

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.

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.

As a newbie it is easier to set up Cachy. When shit hits the fan either fixing it on Arch or Cachy would give a similar experience to a noob I think.

Yes, but Arch prepared you for it. Arch philosophy is one of teaching you why you need to do something, and then how to do it, so if something breaks you have some vague idea of what was and how to fix it. CachyOS is Arch, it has the same expectations of you knowing things, and having read the wiki, but you skipped the tutorial. This is why me and many others despite the idea of recommending an “easy” Arch to newbies, it’s not easy and only causes trouble.

Arch is very unstable (in the sense that anything can change) and that means it’s easier to break things if you’re not careful with things you don’t know to be careful about. For example, not saying that this is your case, but I’ve seen people install drivers and programs through binaries downloaded form a webpage like they would on Windows, that is a TERRIBLE idea as it will likely break on the next update, and if it’s something important like a GPU driver you will be dropped to a terminal.

I understand it might be a fluke or that I am at least a minority in this issue. But that makes troubleshooting harder.

It’s not about being a minority, it’s about we don’t have all of the info so can’t help you. From the info you gave us I can tell you it’s not something known, as I haven’t seen it being reported by others, which means it’s something specific that you did to your system. Every thread I find for CachyOS update breaking things is a unique case where the person did something.

And I know your knee jerk reaction will be “I did nothing, I only updated”, but that’s probably not true, otherwise we would see other people reporting the issue. If simply updating now was enough to break the system we would be hearing from hundreds of people whose system broke. But we haven’t, the only report we have is yours, which very likely means you did something different from everyone else. And I get that you don’t know what it is, when I first started using Linux I used to break my system every couple of months, and I always thought it was the system fault, but guess what? It wasn’t. Eventually I learnt to use Linux and my system never broke again, I can’t tell you for sure what I was doing before, but clearly I was doing something.

It’s interesting that the whole idea about stability (the system not breaking) shifts from the developer to the user.

Well, that’s bound to happen if you own the system. Same reason most companies have a warranty void if you fiddle with the internals, once you do that it’s impossible to say if the issue was caused by you or them, and the same thing is true for a Linux system. My guess here is that you changed a config, or installed an unofficial package or something or the sort, it might have been months ago, but now the update changed one of the underlying things and it broke. I would probably lean to the config side of things, since I don’t expect you installed anything critical from outside the repos. Or another possibility is that you went a long time without updating, that can have consequences on Arch systems.

PS: I get it, I know this seems harsh, I know you’re probably thinking “I did nothing, this Linux is unstable and finicky”, I know that because I was in your shoes 20 years ago. Arch is not for everyone, even some extremely knowledgeable people dislike the high maintenance it sometimes imposes, for new people without experience it can be like walking on a landmine field. Which is why I always recommended more newbie friendly distros like Mint, because they try to be more stable in all senses of the word (you can still break them though, as you are in control of the system, but it’s more difficult).

I’d argue that CachyOS is more noon friendly than arch.

I’d say no, Arch forces you to learn to use a terminal, chroot and other things so you can fix your system if it breaks. CachyOS expects you to know this but doesn’t force you to. It’s like saying jumping off an airplane is more noob friendly because of the static line.

People fail to see my point that sometimes Linux breaks very easily and I’m not blaming Cachy or Arch specifically but a simple update and sleep should not result in a black screen on any OS IMO.

Yes, that’s correct, I have never ever in my 20 years of running Linux and administering Linux laboratories seen a system break because of a sleep during an update. It’s very likely that that was just a coincidence and the system would have broken regardless of the sleep. I don’t have all of the info but my guess would be either Nvidia driver related (as I see recent news mention it on both Arch and Cachy) or (more likely) you changed a system config and the update kept your version which is now not compatible (it happens, it’s part of the reason why Arch is called unstable, on stable distros that can only happen during version updates, and you get promoted about each of them, but Arch expects you to check pacnew/pacsave files after an update)

It’s you who’s missing the point that the other person made, your experience is not something that matches other Linux users. CachyOS is not noob friendly, these sort of thing should never happen in Mint or other more noob friendly, but Cachy expects you to be aware of certain things because it is a bleeding edge rolling release distro. People think Arch is difficult because of the installation process, but that’s not it, that’s very straightforward, maintain the system is what’s difficult.

This is exactly what I think every time someone recommends CachyOS or Manjaro to new users. Arch is great, but it expects the user to know how to deal with things, it expects user to read the news and it pulls the rug periodically because it expects you to be able to figure things out.

In your case in particular I don’t think it was Cachy on its own, otherwise we would have seen other users affected, but still, it’s likely that the Arch philosophy got you because of something you changed without even remembering and now with the update your config is no longer backwards compatible.

NixOS is great, but it’s a very different paradigm, you will not be able to install things from the graphical interface as you’re expected to declare your system. And it can never be compatible with a graphical installation as that would beat the whole purpose of reproductible builds.

I think what you’re looking for might be something like Bazzite, where the core system is immutable but you get user space freedom. But personally, if 0 downtime is your goal NixOS is better, as you can rollback to previous generations of your system if something goes wrong, but to get that you have to pay the price of declaring your whole system which might be too steep to pay for some.

Are you not aware of https://search.nixos.org/options or https://nix-community.github.io/home-manager/options.xhtml ? You can search all available options, sometimes with links to the docs for the thing they set for extra context. Those are both official docs and are derived from the code that you’re already looking at.

I’ve checked the NixOS documentation extensively for setting things up, my point was that I hadn’t had to do so for migrating to flakes, as that’s not a NixOS thing, but rather a Nix language thing.