For the record, it seems the project moved on, just without its previous maintainer, to github: https://github.com/tt-rss/tt-rss

Prosody is a great piece of software, and so is ejabberd which offers some perks. I can’t speak for the other servers (mongooseim, openfire, tigase, …) which I haven’t tried in a long time,

All that’s to say that it’s amazing that we get so many well maintained and compatible servers (and clients) implementations in XMPP-land, and all the implications for its healthy future.

I mean, a mechanical timer costs, like, 3 bucks in any currency and lets you set charge and discharge cycles. Add 10 bucks and you have one that you can pilot via REST API.

Don’t rip out the battery, that’s free UPS!

If there’s nothing utterly specific from the nextcloud ecosystem that you absolutely need, no, Synology has you covered

You seem to be obsessed with optimising one resource at the expense of others.

If you want to push it and paint me as obsessed about something, then let it be this: providing this community with on-topic and reasonable advice

you’re only going to save a few MB of RAM.

This is false, and you should read once again my previous message illustrating why: on a decent “self-host”-friendly machine, the same software may work very well, or not at all, depending on whether the user would engage with very basic configuration. This goes beyond RAM (memory isn’t the sole shared resource), and I’m adamant that the alternative (which was “pretending that the problem doesn’t exist” turned into “throwing money at the problem”) is unreasonable.

On the other hand, if you’re doing it to learn more about computers then it might be worthwhile. This is a community of hobbiests, after all…

Or more importantly: the extent to which you can self-host out of sheer luck and ignorance like you suggest is very limited. If you don’t want to engage with a minimum amount of configuration, you might bump into security issues (a much broader and complex subject) long before any of the above has a material impact.

I’m saying this based on real world experience

And do you think I would spend my time engaging if that wasn’t from my own very “real world experience” of lessons learned the hard way?

Bringing-up “diminishing returns” as if this was an optimisation game also doesn’t do this justice. Take the typical “household FOSS package” with software names often brought up in here: a nextcloud instance, a photo-sharing service like immich, private instant messaging, a software forge, a subsonic-compatible audio/video streaming server, a couple php websites like wallabag and RSS aggregators.

An Intel Atom CPU and 4GB of RAM is plenty sufficient for all that, and will cost you single digit USD a month, granted you put the (one-time) effort to tune and balance those services. Would you run all the above from upstream’s docker files, I can guarantee you that you would deem this (perfectly fine otherwise) server underpowered for the task at hand (and would probably go for a 10th gen or so Intel Core CPU, quadruple the RAM and 3-6× the energy cost in the process).

And that’s the point I’m making here: a self-hosting community of tinkerers should (ideally) know better, for the ethics’ sake of keeping the process environmentally friendly, and not wasting other people’s money.

Do you have the data to back that up?

I mean, you are the one making the exceptional claim that unnecessarily running multiple instances of programs on a device with finite resources has no practical adverse effect. Of course, the effects can be more or less drastic depending on the many variables at play (hardware, software, memory pressure, thread starvation, cache misses, …) and can indeed be negligible in some lucky circumstances. The point is that you don’t call that shot, and especially not by burying your head in the sand and pretending it’s never gonna be a problem.

Effective use of computing resources requires tuning. Introduction of a new service creates imbalance. Ensuring that the server performs nominally and predictably for all intended services is a balancing act and a sysadmin’s job. Services whose deployment settings are set by someone with no prior knowledge of the deployment constraints can’t be trusted to do a good job at it (that’s the nature of the physical world we live in, not my opinion), and promoting this attitude promote the kind of wasteful and irresponsible computing I was on about.

Now, I’ll give you the link to this basic helper for tuning a PostgreSQL server: https://pgtune.leopard.in.ua/
Will you tell me what are the correct inputs for my homelab (I won’t tell you the hardware, the set-up, the other services running on it, the state of the system, etc)?
And later, when you will distribute your successful container to millions of users, what will you respond to the angry ones that will complain that your software is slow, to no fault of your coding, because they happen to pile up multiple DBs, web servers, application servers, reverse proxies, … on their banana SoCs?

I disagree. You are just entertaining the idea that servers must always and forever be oversized, that’s the definition of wasteful (and environmentally irresponsible). Unless you are firing-up and throwing-away services constantly, nothing justifies this and sparing the relatively low effort it is to deploy your infrastructure knowingly.

Precisely what pre-devops sysadmins were saying when containers were becoming trendy. You are just pushing the complexity elsewhere, and creating novel classes of problems for yourself (keeping your BoM in control and minimal is one of many others that got thrown away)

Self hosting doesn’t mean “being wasteful and letting containers duplicate services”. I want to know which DB application X is using, so I pool it for applications Y and Z.

As someone who’s been using ttrss for decades but would be open to trying something new, what would you say is FreshRSS’ killer feature (and missing killer feature) compared to ttrss?

(Not trying to start a flame war, ttrss feels like a finished project, which is not a bad thing, but I think it’s healthy to wish for more innovation in this space)

One of them, for a 50% premium and worse finishing/less robust

Not in the way of ThinkPads being one of the last bastions of laptop durability and upgradeability, though

I’ve compared the two a while ago, seems to me like slightly different takes around the same core ideas. It’s true that a couple of things in Ansel feel more natural, but it’s not much, and it’s probably not worth the risk (AFAICT the bus factor is one, compat with DT isn’t a goal).

Darktable developers pride themselves for their non-destructive processing pipeline and use it as an excuse for how quirky and inflexible their UX is. I believe they are highly competent on the highly technical bits that ultimately very few people see or understand. Personally I can use it to an extent if I unlearn what other software have taught me over decades of UX conventions.

, and this is just the beginning.
It’s bad omen to criticize an opensource project, I know, but in my eyes Matrix is a big technical and organizational failure, for not having succeeded in stabilizing the protocol after a whole decade of unsuccessful explorations, and for having its leadership consistently fail to define clear goals and steer the project towards them (just get it done and working well before trying to make it “peer to peer” or “in the metaverse”).

If this is the electroshock that Matrix needs to reconsider its design and directions? good for them. If that kills them? Well too bad, but it’s not like they are the only cool kid in town.

It says it’s federated. When you are your own provider, e2ee doesn’t matter nearly as much (you probably have a bunch of personal files, backups, services running on the same box anyway).

Edit: I would gladly take constructive comments with the downvotes. For a moment I thought we were on “selfhosted”, where “you are your own provider” should resonate in with most

Or, you know, just use key auth only and fail2ban. Putting sshd behind another port only buys you a little time.

And so damn easy to self-host in general. Ejabberd is batteries included down to offering stun/turn for audio/video calls, Erlang is just unrivaled when it comes to hot reloading so updates are effectively zero-downtime (unsurprising considering all the business critical environments it’s deployed).

At first (and especially because I went with Matrix originally) I wouldn’t think of self hosting all my instant messaging, but in retrospect, ejabberd is one of the easiest services I’ve got to maintain. I highly recommend everyone to give it a shot, especially to all the matrix refugees to whom it was a surprise/disappointment.