Most developers have never seen anything better. They start working within an artificially complicated ecosystem, get used to it and perpetuate all of the assumptions the ecosystem makes when they create their own products.

And when you point this out, most people just get angry, because for them it suggests they have been doing something wrong for as long as they've done engineering. This is why you always hear things like "buy my website is an application" or "but it has to be complicated to use, because it had complicated functionality".

Simplicity is not easy or intuitive.

I've only started to learn the principles of designing simple systems that do complex things around 10-12 years in my career, after accidentally discovering certain people's talks online (Alan Kay, Rich Hickey) and learning a bit about old-school AI systems. Most people aren't familiar with any of that stuff and don't really care.

One thing I personally cannot comprehend is why web applications are almost universally installed and managed through command line, rather than web interfaces. The only advantage of a command-line interface is pipe chaining, and it's never uses installation/configuration. There is nothing fundamental about command line. It's just a software simulation of a teletype terminal.

Repeatability, scriptability, debugability ... ?

It's a very powerful interface.

Any "recipe" you're getting is likely something you get from a web page to begin with. That can be a tool for composition and automation on it own.

Not necessarily. Distro package maintainers use and construct recipes that are not web pages, in order to allow folks to install complex software with, in many cases, one click.

This is not some trivial web application, it's a federated social network, and it's all laid out for you, basically up to and including steps for ensuring security and production readiness.

I am exasperated too by this stuff, and I am a professional that works with it every day (but these instructions are especially well laid out.)

I'm counting on Helm to save us. I've been admining a Jenkins server on Helm and Kubernetes and I just haven't seen the "miserable experience" I've heard of other Jenkins admins describing.

I've run several other projects using Helm and I'm convinced it's a pattern of admin-friendliness that is common to stable and well-maintained charts. They are just generally easier to work with, don't feel cobbled together, and you basically never get Configuration Drift.

But it still won't be universally easy until Kubernetes is ubiquitous. It seems easy to me now, because I've already grown accustomed to basic Kubernetes maintenance and it's mostly optional, thanks to the proliferation of managed Kubernetes providers on-the-cheap.

It's still a lot to reason about, and at my place of business the status quo is simply worse than that because of struggling with adoption.

To be fair, its cousin Pleroma is comparatively easy to install

https://i2p.rocks/blog/the-magical-world-of-pleroma-setting-...

Is this easier? It looks at least a bit more complicated at a glance to me. I haven't honestly tried either of them, but neither of these are simple to install. Add a config file to nginx, install erlang and use mix to grab the dependencies... these things are not totally foreign to me as a Ruby programmer, but I could see how a newbie would trip over them.

I still don't know which part people are tripping over, I'd like to hear from GP... The Pleroma doc might actually be simpler because it skips over all of the "Hardening your instance" stuff, but I'm only guessing about what people see as the hard part, since none of this looks particularly hard to me.

To be equally fair, it's really never as simple as "docker run someone/image:latest" – that's only the first step, so you can see it running. In Kubernetes terms, that's the equivalent of firing off a "run-once" pod. In other words, if that's all you did then it's not deployed yet.

Mastodon also has this reputation on its own platform.

There's several systems set up to make self-hosting projects easy. It usually involves some behind-the-scenes docker containers with custom scripts and a custom web interface. If you're interested in something like this, try Sandstorm: https://sandstorm.io/ It has a free demo that shows exactly what it can do. It works quite nice, actually.

As you might have seen, there is only a limited amount of software packages available on Sandstorm. The trouble comes with dependencies and overhead. Not every project can talk to Postgres (WordPress mostly relies on MySQL), leading to multiple databases running at once unless you go and manually configure addons and config files to make software talk to each other. Software is designed to run well on a specific base system, be it Ubuntu Server with postgres, CentOS with MySQL or Arch with sqlite.

To make this easier, large software packages are usually packed into Docker containers. Running multiple Docker containers still requires some effort (you need to specify what persistent data needs to go where) but that's nothing compared to manual installation. It's also a requirement one cannot easily get around, as most people/companies have their own preferred storage paths and data storage requirements for important data (think encrypted databases, separate encrypted disk mounts, etc.). This is tiresome and requires reading up on the relevant documentation, but not difficult.

With most of the complexity removed (just ports and paths), you quickly end up running multiple versions of Nginx and Apache at once because every docker container comes with its own web server and its own specific, non-compatible add-ons. This wastes RAM and CPU which could be used to have your services run more smoothly. Most big applications therefore are designed to run best on their own separate hosts to take full advantage of the (virtual) hardware.

The article linked is a good example. It is not a manual about writing config stanzas and downloading packages; it's the bare minimum one needs to handle to configure something like Mastodon.

wget https://cloudron.io/cloudron-setup chmod +x ./cloudron-setup ./cloudron-setup --provider [digitalocean,ec2,generic,ovh,...]

https://cloudron.io/get.html And that's it, after that it's only a web UI.

Does anybody know other examples of software which provides command line install personnalized to the provider you use?

I am currently working on an end-to-end test suite, as required by cloudron.io platform, to add it to their appstore,

Docker. Its how any software can be packaged with its dependencies. Best for linux serverside/webapp software.

Install and run a docker with one console command, just provide a network-port and folder mapping.

Or use a webinterface, i like how Unraid does this. If you have a old server/PC to spare, definitely try Unraid.net by just booting it from USB stick.

"Docker" is perhaps part of the solution, but only a very small part.

Helm is the closest thing to a package manager for Docker, but it targets Kubernetes, not vanilla Docker (and k8s is overkill for a single server, at least considering the time/expertise required to stand up a productionized k8s installation).

It is an issue, but like, you have to get over it.

Most of the complications come from dependencies (db, caching, etc). How can I, as a web service creator, make it easier to install and configure a postgres DB? I can't! Software is complicated, and sometimes the requirements for software are complicated.

Sure, I could release a version that uses sqlite but then people will whine that it's too slow and doesn't scale. If I release a version that supports both, now I've introduced an entire layer of complexity that I have to support (and tends to break endlessly in my experience).

Yeah, it sucks. but if you're really that worried about it, like you mentioned, use a SaaS service for the app itself or for its dependencies.

What languages have a lower pain point level in your opinion?

If you are using something like digitalocean they have a one click lamp install. It couldn't be easier.

With me, the gripes of installing these apps are not just the app itself but the dependencies, which is a necessary evil and impossible to avoid once things get sufficiently complicated.