Most containers don’t package DB programs. Precisely so you don’t have to run 10 different database programs. You can have one Postgres container or whatever.

Well, that’s not the case of the official Nextcloud image: https://hub.docker.com/_/nextcloud (it defaults to sqlite which might as well be the reason of so many complaints), and the point about services duplication still holds: https://github.com/docker-library/repo-info/tree/master/repos/nextcloud

You can typically configure the software in a docker container just as much as you could if you installed it on your host OS…

True, but how large do you estimate the intersection of “users using docker by default because it’s convenient” and “users using docker and having the knowledge and putting the effort to fine-tune each and every container, optimizing/rebuilding/recomposing images as needed”?

I’m not saying it’s not feasible, I’m saying that nextcloud’s packaging can be quite tricky due to the breadth of its scope, and by the time you’ve given yourself fair chances for success, you’ve already thrown away most of the convenience docker brings.

See my reply to a sibling post. Nextcloud can do a great many things, are your dozen other containers really comparable? Would throwing in another “heavy” container like Gitlab not also result in the same outcome?

Well, that is boldly assuming:

• that endlessly duplicating services across containers causes no overhead: you probably already have a SQL server, a Redis server, a PHP daemon, a Web server, … but a docker image doesn’t know, and indeed, doesn’t care about redundancy and wasting storage and memory

• that the sum of those individual components work as well and as efficiently as a single (highly-optimized) pooled instance: every service/database in its own container duplicates tight event loops, socket communications, JITs, caches, … instead of pooling it and optimizing globally for the whole server, wasting threads, causing CPU cache misses, missing optimization paths, and increasing CPU load in the process

• that those images are configured according to your actual end-users needs, and not to some packager’s conception of a “typical user”: do you do mailing? A/V calling? collaborative document editing? … Your container probably includes (and runs) those things, and more, whether you want it or not

• that those images are properly tuned for your hardware, by somehow betting on the packager to know in advance (and for every deployment) about your usable memory, storage layout, available cores/threads, baseline load and service prioritization

And this is even before assuming that docker abstractions are free (which they are not)

and why would that be? More abstraction thrown in for the sake of sysadmin convenience doesn’t magically make things more efficient…

Take that as you want but a vast majority of the complaints I hear about nextcloud are from people running it through docker.

Would be nice to be able to run WG on the NAS directly and not need a server, wouldn’t it? I believe there are a few go/rust userspace WG servers out there but I don’t know if anyone’s using them for anything like that.

What is “old arse” to you might be blazing fast and great for someone else (potentially in a less fortunate area of this world), and besides that, no matter your or my sensobilities, if it works, it works and should be kept that way as long as it has a purpose and the hardware permits it.

Except for a marginal fraction of the top YouTubers, aren’t most of them getting paid to inject sponsored links and from donations/patronage these days? It seems that the deal you are referring to has been off the table for a majority of YouTubers for a very long time now, and I don’t see why other platforms wouldn’t be as good, or even healthier than YouTube to provide them that kind of revenue.

I can’t pretend to know the future, but if you read between the lines and the justifications provided, this isn’t really about AGPL per se, but about Element brokering AGPL exceptions. Practically we can expect all kinds of forks with opencore options that might enshittify the user experience in different ways, and further solidification of Element’s single-handed control over Matrix (which had been a prime concern for many years). Matrix is by the day closer to the closed-source centralized silos it was first pretending to oppose.

Interesting. Were the apps/features installed comparable between the OC and NC instances? I can’t even find an “email” equivalent app for owncloud from their marketplace.
I don’t want to sound like I’m coming in defence of NC, but I’d be curious to find an as factual as possible comparison between “bare-bones NC” vs “bare-bones OC”.

Matrix problems become unmanageable at scale, but the effects of the underlying complexity can be felt long before: https://telegra.ph/why-not-matrix-08-07

If you read between the lines, Matrix 2 is practically about handing the client state over to the server (what they refer to as “sliding sync”). Realistically, this is an admission that the protocol is too complex to be handled efficiently on the user’s devices. I’m not saying there are not clear benefits (and new trade-offs) to the approach, just that in the grand scheme of things the complexity is shifted elsewhere (and admins foot a larger bill).

Yup, like pretty much everyone else :) https://nlnet.nl/project/XMPP-MLS/

Please, don’t recommend pidgin, it’s a security hellhole, and a pretty terrible XMPP client at that. If you want something with a similar vibe, check-out https://dino.im/ or https://gajim.org/ if you are more on the “power-user” side of things :)

I assessed XMPP vs Matrix about 8 years ago, and strikingly, the basis on which it didn’t make the cut still applies today. Here’s what I responded to a sibling post: https://programming.dev/comment/5408356

In short, Matrix dug themselves into a complexity pit with an inadequate protocol, survived for a while on venture capital money (upscaling servers and marketing at all cost), all of it dried up, and now they are in financial trouble. Matrix won’t disappear overnight, but is definitely losing the means to run the managed instances and the client/server ecosystem.

Neither XMPP nor Matrix will ever become “the next WhatsApp”: the current internet has seen too much consolidation for the tech majors to permit it (and open and federated protocols can’t compete, do not have the marketing budget nor the platforms to promote their software, but I salute the EU’s Market Act attempt to shake-up the status quo).

But that doesn’t really matter IMO. What (I believe) is important in the grand scheme of things is that such protocols remain alive, maintained and secure, so that:

• small-scale instances can flourish and contribute to a more resilient/efficient internet (think of family-/district-level providers ; this is the kind of service I personally offer: family members and friends at large appreciate that the messages and data that we exchange aren’t shared over some cloud or facebook server for no good reason)

• IM identities can persist over time: if you are a business or an individual, you may want to look into having a stable/lasting contact address, that will survive the inevitable collapse of facebook/whatsapp/instagram/… If you are old enough, your current email address probably existed before facebook. Why not your IM address?

And yes, I hear you, this is rather niche, but what got me there (and on XMPP in particular) is having been long-enough on the internet to become tired of the never-ending cycle of migrations from service to service. More and more people will have a similar experience as time goes, so this niche will only grow :)

Edit: Sorry, I responded to the wrong parent.

I don’t believe Matrix is better positioned than XMPP to succeed. On a technical aspect, Matrix hasn’t managed to stabilize its protocol, and they’ve been a decade into it. This has resulted in only a single organization being in charge of the protocol, the client and the server implementations. This isn’t sound, this isn’t sustainable. And now, unsurprisingly, this organization is in a financial crisis, has lost important customers, has no budget secured to maintain its staff in the next years, and recently underwent a major licensing change that we can only interpret as a shift towards an opencore model at the detriment of the regular user.

The thing is that I have experience with other complex or high usage PHP applications and I know how to optimize things. What I see in NC is poorly structured code, warnings and erros thrown around left and right.

Well, on my instance, logs are pretty quiet and I am not a PHP developer to form an opinion on the overall architecture. But if you take the time to write down what you feel is wrong with the nextcloud codebase, I’m pretty sure many people (and me first) will read it with interest and perhaps even do something about it (typically the kind of “HN frontpage” content, if it’s well written).

The OP also said that ownCloud gave him a much better experience out of the box, and that’s still a “complex” PHP application.

Last I heard of ownCloud, people were saying that it had been rewritten in go or something similar. Funny bit of history, nextcloud forked off of owncloud, got a ton of mindshare in the early days, and quickly became the better/faster of the two (perf was one compelling reason for me to migrate back then). I wouldn’t mind NC following suit (in the end, we benefit from this type of competition).

NC webmail is unusable

I don’t plan on ever using it, but thanks for the heads-up. That said, if you feel that roundcube performs better, it happens that someone has packaged it for NC, so you should be able to use that instead of the troublemaking client.

Yup, that’s a big reason why centralized protocols aren’t sustainable. XMPP is 25 years old (which is older than almost anything else on the contemporary internet) and thriving. Unfortunately, judging by the cycle of messengers coming and dying, and people still being eagerly part of that, this isn’t something that people value very much.

If you are curious, you should give XMPP a shot, it’s equivalent to Signal in terms of encryption, but anyone can host their own. Signal is ideologically opposed to anyone but themselves being in control of your account, and because of that I don’t want to trust them.