Pleroma is a federated social networking platform, compatible with GNU social, Mastodon and other ActivityPub and OStatus implementations. And it has a gopher server.

"Pleroma is built on a lot less technology than Mastodon. To run a Mastodon instance, you need Rails, PostgreSQL, Redis, Sidekiq, NodeJS and - if you want search - ElasticSearch. For Pleroma, you only need Elixir and PostgreSQL, while still getting all the features. This simplifies installation and makes maintenance somewhat easier."

@jpmens Does it really?

Modern applications are deployed with various automated solutions:

- containers, e.g. Docker for both software
- configuration as code, e.g. Ansible playbooks

The installation is done from a template and reproducible solution, and so not a real time-consuming issue.

Actually, the main management cost is backup, logging, monitoring 50x issues, space disk issues and that's fairly independent of the technology stack.

@Dereckson I was quoting, but actually, it does make things easier, IMO. The fewer moving parts (and believe me, I'm a huge fan of few moving parts) the less that can go wrong.

@jpmens This seems more an intuitive thought.

Such thoughts should be treated as hypothesis, and proved or at least backed by evidences from experience.

As a counterexample, I've seen monolithic applications trigger a lot more issues than more complex stacks, especially when they try to implement themselves a communication layer instead of a message broker or a cache.

@jpmens Now, speaking of microservices, Martin Fowler has another hypothesis: more complex stacks require a more seasoned operations team.

If this hypothesis is valid, that would mean the "ideal" stack size and complexity depend of who manage it.

The consequence is pretty depressing for application developers: whatever are your stack choices, you'd be make things easier in one environment and harder in another.

@Dereckson @jpmens
Using pre-built docker images or pre-written playbooks are just easy solutions for people that don't want to/care to/can't understand what they are doing and what their stack is. Which means that most will be incapable of debugging stuff when something breaks.
Also, playbooks are often written to work "everywhere", which means that when using these, you are not benefiting from the specificities of your own hosting stack (including, more often than not, security).

@x_cli @jpmens No, they aren't just that. They are mainly tools to BUILD your own solutions.

You noticed to reuse a playbook is somewhat not optimal.

But they aren't marketed as "software distribution solution", but to build custom solutions.

And if as a side effect, packaging for end-users could somewhat be facilitated in common scenarii, that's a strength, not an issue, because your 1999-2005 100 lines tutorial "do this, do that" was treated as copy/paste cargo cult.

@Dereckson @jpmens
And now people are doing curl | sudo sh.
I don't think we really created a better world by letting people doing this blindly. At least, they had to go through the doc to copy/paste the commands. They skimmed through it, at least, and they might have been able to notice something odd.

@x_cli So the initial issue wasn't how end users react, but if and how exactly the maintenance of an application is made easier or harder.

It's the opinion of a post blog Plemora is easier to maintain than Mastodon, as it has less dependencies.

It's when I stressed on the fact installation was mainly a small cost of maintenance on the longer cycle of the application, and there a several incompressible factors asking time to maintain, regardless how the stack is simple or complex.

@Dereckson I understand and I don't think we parted ways with the initial conversation.
Installation is a one-time story, granted. However upgrades are a recurring maintainance task, which gets more tedious the larger an application dependency graph gets.
Thus, fatbins and applications with few dependencies require less time to maintain, since we can surely agree that the other maintainance tasks are likely to occur, whichever stack you installed.



You, Sir, have now attained level! Welcome to the club! :-)

@jpmens Thanks! (though I would have called it "The wise men" club, but hey! ;))

@Dereckson @jpmens
I'm not saying containers and playbooks are useless. I'm saying they are not really saving any time when written by someone else. Which circles back to: the less moving parts, the better.

@x_cli @jpmens Configuration as code big advantage isn't about time gain, it's about reproducibility, ease of migration and, probably one of the most underestimated advantage, documentation.

If a server is fully configured through a configuration as code repository, the documentation for this server is as a side effect up-to-date.

But of course they require time to be written, tested, tweaked for several OS, etc.

@Dereckson @jpmens
I never bought into "the code is the documentation" because the code contains errors that even the developer does not know about.
I am much more confident in a software where the code and the handwritten documentation (acting as a declaration of intent) say the same thing. That's a parity check. If there is a mismatch, there is a bug to fix in the documentation or the code.

@jpmens I have never heard of Sidekiq nor Elixir...

*mumbles "these youngsters..!"*

I am getting old by the minute *sigh*


Are you running a Pleroma of your own? I brought up a server running in localhost dev mode in a few minutes based on those instructions, wondering if it's a suitable spot for a light duty, "prove it can be done" self-hosted #arm64 system.

I'm just not sure I want to be sysop for more than a small handful of people.

Sign in to participate in the conversation

Server run by the main developers of the project 🐘 It is not focused on any particular niche interest - everyone is welcome as long as you follow our code of conduct!