Well, can’t say fairer than that.

Yeah, I did try to stress that just because I can’t envision a use for it, doesn’t mean it shouldn’t exist. I’m totally OK with that. My question was more “Am I the idiot here for not being able to see what the use is?”

Obscurity is not the same thing as security.

You know those can be self hosted, right?

And yes, by all means just set up your own Wireguard or OpenVPN access if that’s what you prefer. You do you bud.

But that implies you do have your SSH open to the world, right?

The way I access my private web interfaces remotely is through something like Netmaker, Tailscale or Zerotier. Same thing for SSH. No way in hell am I opening 22 on my router.

I’ll admit, as neat as this is, I’m a little unclear on the use case? Are there really situations where it’s easier to get a command prompt than it is to open a webpage?

The CLI side I can see more use for since that does expose a lot of actions to bash scripting, which could be neat. But on the whole I can’t say I’ve ever really found myself thinking “Man, I really wish I had a UI for managing Radarr, a program that already includes a really good UI.”

I know it’s shitty to hate on something just because you’re not the target for it. That’s not my intent, it’s more that I’m just fascinated by the question of how anyone has a burning need for this? It feels like there must be something I’m missing here.

I don’t think there’s anything inherently wrong with the idea of using a GUI, especially for a non-professional who mostly just wants to get into self-hosting. Not everyone has to learn all the ins and outs of every piece of software they run. My sister is one of the least technical people in the world, and she has her own Jellyfin server. It’s not a bad thing that this stuff has become more accessible, and we should encourage that accessibility.

If, however, you intend to use these tools in a professional environment, then you definitely need to understand what’s happening under the hood and at least be comfortable working in the command line when necessary. I work with Docker professionally, and Dockge is my go to interface, but I can happily maintain any of my systems with nothing but an SSH connection when required. What I love about Dockge is that it makes this parallel approach possible. The reason I moved my organization away from Portainer is precisely because a lot of more advanced command line interactions would outright break the Portainer setup if attempted, whereas Dockge had no such problems.

The thing is, those poor design decisions have nothing to do with those features, i claim that every feature could be implemented without “holding the compose files hostage”.

Yes, this is exactly my point. I think I’ve laid out very clearly how Portainer’s shortcomings are far more than just “It’s not for your use case.”

Portainer is designed, from the ground up to trap you in an ecosystem. The choices they made aren’t because it’s necessary to do those things that way in order to be a usable Docker GUI. It’s solely because they do not want you to be able to easily move away from their platform once you’re on it.

Not the point. If you want to interact with the compose files directly through the command line they’re all squirelled away in a deep nest of folders, and Portainer throws a hissy fit when you touch them. Dockge has no such issues, it’s quite happy for you to switch back and forth between command line and GUI interaction as you see fit.

It’s both intensely frustrating whenever it comes up as an issue directly, and speaks to a problem with Portainer’s underlying philosophy.

Dockge was built as a tool to help you; it understands that it’s role is to be useful, and to get the fuck out of the way when its not being useful.

Portainer was built as a product. It wants to take over your entire environment and make you completely dependent on it. It never wants you to interact with your stacks through any other means and it gets very upset if you do.

I used Portainer for years, both in my homelab and in production environments. Trust me, I’ve tried to work around its shortcomings, but there’s no good solution to a program like Portainer other than not using it.

Please don’t use Portainer.

• It kidnaps your compose files and stores them all in its own grubby little lair
• It makes it basically impossible to interact with docker from the command line once it has its claws into your setup
• It treats console output - like error messages - as an annoyance, showing a brief snippet on the screen for 0.3 seconds before throwing the whole message in the shredder.

If you want a GUI, Dockge is fantastic. It plays nice with your existing setup, it does a much better job of actually helping out when you’ve screwed up your compose file, it converts run commands to compose files for you, and it gets the fuck out of the way when you decide to ignore it and use the command line anyway, because it respects your choices and understands that it’s here to help your workflow, not to direct your workflow.

Edit to add: A great partner for Dockge is Dozzle, which gives you a nice unified view for logs and performance data for your stacks.

I also want to note that both Dockge and Dozzle are primarily designed for homelab environments and home users. If we’re talking professional, large scale usage, especially docker swarms and the like, you really need to get comfortable with the CLI. If you absolutely must have a GUI in an environment like that, Portainer is your only option, but it’s still not one I can recommend.

So noble. So majestic. SO STUBBY.

I’ll bet your boot process is a lot shorter too.

The reasonable way to approach this problem would have been to ask a follow up question, rather than bitching at someone for not answer in the exact format you required. You’re the beggar here, you get zero fucking say in how much or how little people choose to help you.

Is everything supposed to be black and white? Also, how does one access the purported customisability? I can’t seem to find a settings option anywhere, and the readme.me is just a vague list of selling points.

Edit: NVM, figured it out. For anyone else wondering, long press on the desktop and select “Tweaks” from the menu that pops up.

There’s no backend server to do the transcoding in this case. Kodi can access raw NFS/SMB file shares the same as accessing local storage, so it’s just reading the file over the network, the same as if you were playing it in VLC on your PC.

Certain domain names are locally routed only. So if you use internal or local as a tld, you can just assign whatever names you want and your computer won’t go looking out on the internet for them. This means you and I can both have fileserver.local as an address on our respective network without conflicting. It’s the URI equivalent of 192.168.0.0/16.

Tim Walz seems like what would have happened if Mr Rogers went into politics.

I’ll see about digging up recommendations if I can, but I’m on my phone right now.

My biggest single piece of advice would be this: Understand that your reader does not share your context.

What this means is that you have to question your assumptions. Ask yourself, is this something everyone knows, or something only I know? Is this something that’s an accepted standard, or is it simply my personal default? If it is an accepted standard, how widely can I assume that accepted standard is known?

A really common example of this in self-hosting is poorly documented Docker instructions. A lot of projects suffer from either a lack of instructions for Docker deployment, because they assume that anyone deploying the project has spent 200 hours learning the specifics of chroot and namespaces and can build their own OCI runtime from scratch, or needlessly precise Docker instructions built around one hyper-specific deployment method that completely break when you try to use them in a slightly different context.

A particularly important element of this is explaining the choices you’re making as you make them. For example a lot of self-hosted projects will include a compose file, but will refuse to in any way discuss what elements are required, and what elements are customisable. Someone who knows enough about Docker, and has lots of other detailed knowledge about the Linux file system, networking, etc, can generally puzzle it out for themselves, but most people aren’t going to be coming in with that kind of knowledge. The problem is that programmers do have that knowledge, and as the Xkcd comic says, even when they try to compensate for it they still vastly overestimate how much everyone else knows.

OK, I said I’d try for examples later, but while writing this one did come to mind. Haugene’s transmission-openvpn container implementation has absolutely incredible documentation. Like, this is top tier, absolutely how to do it; https://haugene.github.io/docker-transmission-openvpn/

Starts off with a section that every doc should include; what this does and how it does it. Then goes into specific steps, with, wonder of wonders, notes on what assumptions they’ve made and what things you might want to change. And then, most importantly, detailed instructions on every single configuration option, what it does, and how to set it correctly, including a written example for every single option. Absolutely beautiful. Making docs like this is more work, for sure, but it makes your project - even something like this that’s just implementing other people’s apps in a container - a thousand times more usable.

(I’ve focused on docker in all my examples here, but all of this applies to non-containerized apps too)

I write technical documentation and training materials as part of my job, and the state of most open source documentation makes me want to stab people with an ice pick.

Xpipe has rapidly become an essential part of my day to day workflow. I wish I could get it to play nice with MobaXTerm as I prefer that to any of the supported terminals, but that’s really my only gripe. In every other regard it’s just an excellent toolkit for managing remote devices.