As Nextcloud advanced with progresses making it competitive in fully integrated government and corporate workflows, OpenCloud is getting more and more attention.
The fact, that both are collaborative cloud plattforms, designed to be selfhosted and mainly developed in/around Berlin from FOSS-Community-Surroundings, makes one ask about the differences.
The main difference I see, is the software stack
- Nextcloud, as a fork of ownCloud, kept the PHP code base and is still mainly developing in PHP
- OpenCloud, also a fork of ownCloud, did a complete rewrite in Go
Until know, Nextcloud is far more feature complete (yes I know, people complain, they should fix more bugs instead of bringing new features) than OpenCloud, if we compair it with comercial cometitors like MS Teams.
I like Nextcloud!
I deploy it for various groups, teams, associations, when ever they need something where they want to have fileshare, calendar, contacts and tasks in one place. Almost every time, when I show them the functionality of Nextcloud Groups an the sharing-possibilities, people are thrilled about it, because they didn’t expect such a feature rich tool. Although I sometimes wish it would be more performant and easier to maintain, so non-tech-people could care for their hosting themselves.
Why OpenCloud?
Now, with OpenCloud, I am asking my self, why not just contribute to the existing colab-cloud project Nextcloud. Why do your own thing?
Questions
So here I expect the Go as a somewhat game-changer (?). As you may have noticed, that I am not a developer or programmer, so maybe there are obvious advantages of that.
- Will OpenCloud, at some point, outreach Nextclouds feature completeness and performance, thanks to a more modern approach with Go?
- Will Nextcloud with their huge php stack run into problems in the future, because they cant compete with more modern architectures?
- If you would have to deploy a selfhosted cloud environment for a ~500 people organization lasting long term: Would you stick to the goo old working php stack or see possible advantages in the future of the OpenCloud approach?
Thanks :)
I have no experience with Opencloud, but Nextcloud is borderline unmaintainable in my opinion. I welcome any new player in this space.
Nextcloud’s biggest issue is performance, and PHP, while not a problem per se, doesn’t help. PHP is not designed for huge applications that need to have processes running in the background; it only runs when a request is made then stops the process, therefore it needs to load itself from scratch on every single page load.
This is because PHP uses something called CGI; the webserver (usually nginx or Apache) calls an external PHP binary to generate a page. With Go (or pretty much any other language), the app is its own server and can keep data in memory and do stuff even when no request is coming.
Isn’t Opencloud just extended Nextcloud? (Still PHP)
Also, nextcloud core components are written in Rust, the PHP just handles incoming requests.
https://nextcloud.com/blog/nextcloud-faster-than-ever-introducing-files-high-performance-back-end/
The scaling, in particular, is a huge benefit of PHP over practically every other technology out there: to double the performance of a PHP server, you can simply have twice as many cores and things will work without any changes needed. Not only is the scaling you get pretty much 100%, unlike other languages, this scaling continues beyond a single server!
There is so much wrong with this that it’s difficult to know where to start…
PHP does actually scale better than something like Lemmy which is written in rust
But sure, you can act like you know more than the Nextcloud devs
PHP does actually scale better than something like Lemmy which is written in rust
Okay - How then?
But sure, you can act like you know more than the Nextcloud devs
I’m a web developer too - so I feel rather qualified to speak on the subject. I don’t think the Nextcloud developers are some sort of genius team of engineers but I’m not saying they’re stupid or anything - just that PHP does not scale better than “practically every other technology out there”.
It forks or creates a thread per request. It’s horizontal scaling which is pretty common with any webapp. I don’t know why they claim PHP is special here. It’s a very common way to handle requests and you can do that with lots of languages and frameworks. More CPUs = more threads = more scaling. Throw more servers into the mix and you’re now “infinitely scaling” right? Well… No. Because I/O.
Webapps tend to be I/O bound rather than CPU bound. So asynchronous I/O leads to much better performance generally with fewer resources. Because no matter how many threads and servers you put in the app tier you’re going to be limited by the disks on your database at some point.
So really your only reason for possibly not liking next cloud is that it’s PHP, correct?
What is the problem with PHP? I keep asking it and until now every response has been near me worthy. “Don’t like PHP because some function calls are not consistent.”, “don’t like PHP because 20 years ago it had Manu unsafe practices!”, that sort of nonsense.
What is the problem with PHP, for you?
I’m not OP, but here are my reasons:
- needs a webserver to be configured properly, in addition to the application itself - most other projects handle the server itself, so I can simply reverse proxy to it
- recent security audit found a variety of vulnerabilities - PHP has been known to have a lot of security vulnerabilities, and it’s commonly targeted due to popularity and the prevalence of these vulnerabilities; using literally anything else reduces the likelihood that you’ll be targeted by script kiddies
- since it doesn’t run an active server, things like WebSockets are wonky - AFAICT, Nextcloud solves this by using a separate Rust binary, which is weird
- using the templating feature (i.e. the whole point of PHP) takes a lot of resources vs client-side rendering, so the main sell of PHP is architecturally suspect
- I don’t use it, so if I needed to fix a bug, it would be a lot of work; I’m a lot more familiar with other languages, like Go, Rust, and Python
There are a bunch of other reasons I strongly dislike PHP, but hopefully this is enough to show why I generally prefer to avoid it. In fact, Nextcloud is my only PHP-based app, and I’m testing out OCIS now (will probably try OpenCloud soon).
-
PHP doesn’t have a built in web server because it doesn’t need one, makes development a whole lot easier as each page is it’s independent process. No worries about memory loss, state corruption, or other issues. IMHO it adds to its security and ease of handling
-
It’s super fast and easy to setup and get going
-
Web sockets work just fine, I use them daily on dozens of servers doing hundreds of requests / sec all day every day
-
They did an audit and found issues? Great, I applaud people searching and finding issues. Shall we do the same for Rust, go, or chuckle JavaScript?
-
You’re unfamiliar.with the language. <<< Yeah, that is the standard reason for hating PHP, it’s not <insert my personal favorite language>
adds to its security and ease of handling
PHP… security?
Any security you get from running as a separate process/thread is undermined by sloppy language semantics and standard library. The built-in “mysql_” library was atrocious and stayed in the standard library for years (removed in 7.0, ~10 years after the previous release). Errors at least used to be really inconsistently communicated (sometimes need to call another function to check error status, sometimes returns 0 or - 1, sometimes raises exceptions). Types are pretty loose and subtly change type (e.g. when an int overflows, it becomes a float?). Variables spring into existence when you use them, so no warning about typos, shadowing, etc.
The language wasn’t really designed, it evolved from a simple templating engine to a full fledged language, and it cleaned up a little along the way. But a lot of the old cruft still remains.
super fast and easy to setup and get going
Yeah, that was always the goal. All you need is a webserver and a directory of scripts and you’re golden.
But lowering the barrier to entry comes with costs. It encourages people to just copy and paste crap until it works, I know because that’s exactly what I did when I first used PHP (JS w/ jQuery is the same way). This encourages a “just get it working” mindset instead of actually understanding what’s going on.
You can certainly write good PHP code, my point is that it actively encourages cludgy code, which means security holes, and the best example is the language and standard library themselves.
Web sockets work just fine
Do they? I assume they hog a whole process/thread for themselves instead of being efficiently managed in something with proper async tooling, so it sounds like it would scale horribly. What happens if you have a million open websockets?
They did an audit and found issues? Great, I applaud people searching and finding issues. Shall we do the same for Rust, go, or chuckle JavaScript?
Yes. I would be very surprised if Go or Rust yield even a fraction of the vulnerabilities as PHP. Even if we expand the scope a bit to a full-fledged web server framework. And that’s with all the server bits, while PHP only worries about its standard library.
I’ve used each of those languages. I’ve built sites in PHP, Go, and Rust, as well as Python and JavaScript (nodejs). PHP is by far the jankiest, and that’s including all the footguns w/ Go’s concurrency model.
@sugar_in_your_tea @phoenixz Hi there! If you wouldn’t mind indulging grampa for a minute - I’m a former php4 maintainer for Debian with a story.
One time we found a bug that caused the php interpreter to crash, based on the input passed to a function. We decided it was a security issue, but even that was kind of besides the point. We reported it upstream to the php folks. They (Rasmus!) told us it was not a high priority issue, because apache would simply restart when it crashes - no big deal
🤦♂️
Oh man, that’s exactly the cultural thing I’m talking about. Thanks!
-
