I often feel the same way. I had someone ask me to make a microservice on some platform she built. I was told it would take 10 minutes. In reality, it took a couple weeks, and then every week for a year I was getting told something was changing and I had to mess with this or that, and also attend daily meetings about the project. 10 minutes turned into 30% of my whole year. The whole platform she built lasted maybe 2 years before it was decided we needed to move on from it. It was a total waste of time.

Meanwhile, I have a little LAMP project that is used significantly more than the micro service, that I’ve run for 15 years that I only have to touch when it needs feature updates. The platform itself just works. Occasionally I’ll need to move to a newer OS, which takes a few hours to get the new server built, run the job to configure it (doing it manually doesn’t take too much longer), then submit a request to change the load balancer to point to the new servers.

Granted, some of this comes down to experience. However, needing to know all the tools involved for the microservice was much more annoying and they broke half the time.

Boring technology just works. That's why it is boring and not appealing to younger developers.

https://boringtechnology.club/

people forget that you need a huge ranch, and several farm hands etc to handle cattle.

while everyone can care for pets with little effort.

That's another subject altogether. Huge ranch tools makers don't advertise their solutions as "simple".

They usually don't advertise at all to the general public because they are b2b oriented.

Its comprehensive. It is not complex. They just show all of the typical ways one would want to deploy.

I can't see any issue with what's in the installation part. It all looks very straightforward for _each_ installation method.

come on, you just need to teach a bit of git/k8s/docker/tls/proxies/storage/vault/markdown/linux/apt and then your family will be autonomous at managing this wiki IF you are allowed to take vacations.

I got it running locally like this, using uv to manage dependencies:

    git clone https://github.com/redimp/otterwiki.git
    cd otterwiki

    mkdir -p app-data/repository
    git init app-data/repository

    echo "REPOSITORY='${PWD}/app-data/repository'" >> settings.cfg
    echo "SQLALCHEMY_DATABASE_URI='sqlite:///${PWD}/app-data/db.sqlite'" >> settings.cfg
    echo "SECRET_KEY='$(echo $RANDOM | md5sum | head -c 16)'" >> settings.cfg

    export OTTERWIKI_SETTINGS=$PWD/settings.cfg
    uv run --with gunicorn gunicorn --bind 127.0.0.1:8080 otterwiki.server:app

I filed an issue here suggesting that for the docs https://github.com/redimp/otterwiki/issues/146 - and also that it would be great if getting started could be as simple as this:

    pip install otterwiki
    otterwiki \
      --repository app-data/repository \
      --sqlite app-data/db.sqlite \
      --secret-key secret1 \
      --port 8080

And to think people used to think

  ./configure —-prefix=/home/user/appname
  make
  make install

was too complicated

The problems was mainly that even "apt-get build-dep" is not enough to handle all the problems that arise from that. Even if configure was standardized, there was always problems with diversity in systems.

The NIH syndrome is still big in software build tools, everything is complicated unless you have written it yourself in your environment. Admitted I seldom run those commands manually anymore, but things have gotten way worse when I do try. Specific versions of tools, libraries and kernels, or just kernels. Nix build scripts are actually one of the worst offenders here often ignoring every other standard available. Not saying it is bad, just an example of why what you write above is more complicated than it sounds.

I got it to work under Piku (https://piku.github.io) in much the same way (since I support uwsgi, that bit was trivial).

I did have to hardcode the data path, and I think having some form of export/snapshot would help as well, but submitting a patch might be a fun weekend project.

Yeah I’m with you. I cannot stand having to jump through hoop after hoop just to get started - things to download, command line utils to install, line after line after line to copy into the terminal, layers and layers of dependencies, possibly with version incompatibilities that the “getting started” page was never updated to reflect… it’s a nightmare.

Sometimes you just want to sit down and write code and see it working.

But deploying on Docker is simpler than LAMP! All dependencies included. All binaries included. You can even just tell systemd run it (also usually included).