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.
, 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.
I’m selfhosting a Matrix server and have all my Chats from other apps also bridged to there.
Same here, but with XMPP in place of Matrix. For historical context, XMPP was invented about 25 years ago on the premise that people were already tired of having their instant messaging scattered over multiple protocols (rather than Signal, Telegram, WhatsApp, Discord, iMessage now, it was Yahoo, MSN, AIM, ICQ, … then), so bridging is very much front and center in the XMPP world. Over time, people also realized that bridging sucks in general (you either dumb down your client to the lowest common denominator which sucks for yourself, or your client isolates itself from the source protocol enough that it sucks for everyone else).
To add insult to injury, most modern protocols also forbid, by their ToS, the use of alternative clients (which very much includes bridges), and to the best of my knowledge WhatsApp, Signal and Discord will eventually suspend your account on this basis.
Matrix is still trying to carve a niche for itself in this space, and is failing IMO (judging by the quality/security of the bridges they have come-up with, and the recent libera.chat fiasco). I’d say that the situation in this regard in XMPP is only marginally better due to the fact that XMPP had a decade headstart to fail and try over, and I would not recommend using bridges on either of them if that can be avoided.
It XMPP better for group VC?
I’d say “it depends”. Fun fact, Matrix uses jitsi-meet under the hood (which is XMPP + a media transcoding/multicasting component that doubles as a relay), and jitsi-meet is my recommendation for this use-case: as long as the central server has good bandwidth, you can really scale up your VC to many attendees. On top of that, XMPP has support for peer-to-peer group VC, with the benefit that hosting is simpler, it doesn’t require any central component/relay (but the bandwidth cost is incurred on all participants and you won’t go beyond a handful of attendees that way).
I’d rather push for XMPP personally, the matrix protocol has been a dumpster fire in an “almost ready, trust me bro” state for as long as it has existed, and failed to justify its own weight and complexity. But that’s mostly irrelevant since they are open protocols and can somewhat bridge with one another.
People don’t choose, people use whatever most people around them use. Whatsapp and telegram are both centralized, and shouldn’t be trusted because, by the nature of it, they can (and eventually will) turn user-hostile.
Messengers come and go, if we really want to make some progress in this area, we should embrace federated and p2p protocols as the logical evolution. Anything else is just wasting time and user privacy.
Or, you know, just use key auth only and fail2ban. Putting sshd behind another port only buys you a little time.
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?