• 0 Posts
  • 4 Comments
Joined 3 years ago
cake
Cake day: June 10th, 2023

help-circle


  • 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.