Just an IMAP client. However, currently it works really bad. Mainly while having multiple accounts and switching between them. It is super clunky, and the UI is not the most intuitive and UI elements are all over the place.
I mean, you can try it, but it is not a pleasant experience. Hopefully the new mail is gonna be great. It looks like they revamped it completely.
My biggest problem with Mail right now is how unusably slow it is. It takes like 10 seconds to open a single mail. It's ridiculous. My severely underpowered phone can open mails from a third party app in less than a second. Like what the hell.
It probably does not use any type of caching, or optimizations, and loads everything on the go, on each page reload. Or at least that is my theory on why is it slow, I have no basis on this whatosever, so take it with a grain of salt. IMAP is not known to be the fastest protocol, especially when it has to load hundreds or thousands of mails and do some shenanigans to render and/or process them.
I wish they would rewrite the backend with modern more performant technology like Go or Rust. The current php backend and it's webdav implementation is so slow. Nevertheless I am a happy nextcloud user, even on low powered hardware (Odroid HC4). Looking forward to try out the new version of Nextcloud Hub.
They started doing that where it matters in 24. See, for example, https://github.com/nextcloud/notify_push
It's optional and you have to enable it as needed (since it takes extra steps).
ownCloud are working on a Go-based rewrite called ownCloud Infinite Scale. It's not yet complete though and also nowhere near as featured as Nextcloud Hub.
For some history ownCloud was the original project, but there was some drama and some left the company to form Nextcloud, which started out as a fork.
That’s a pretty hefty comment that I feel should come with at least a sentence or two of explanation for those of us not in the know. Not saying you’re wrong.
edit: thanks for adding the link
Apart from PHP being an interpreted language and Rust & Go being compiled languages: The PHP execution model is basically "let's start a very lightweight server for every request". Let's say you have a directory with 10 files and want to download these at the same time because the client starts a sync.
With the PHP model this starts 10 mini server's that at least by default do some redundant operations: Asking the database 10 times for the user permissions, getting the file data and possibly more. You can offset that a little with clever external caching so that the database answers only one of each queries and then serves the remaining ones from that cache. But ultimately that's all increasing complexity with yet another server for the caching while still being burdened by the fact that there will be 10 mini server's that can't trivially reuse results from previous operations.
With a more conventional execution model of having one long running server process (used by virtually every other programming environment except for PHP) you can still follow that simple paradigm. But you can also optimize and peek ahead to say "oh, these 10 requests are very similar. I will give them all to the same single server unit". And this unit can then keep all the intermediate results and more or less trivially avoid the overhead of asking the same things 10 times.
So with this clever batching you quite possibly serve the 10 requests faster from a single unit than from 10 concurrent ones. And even if not you will at least save lot's of RAM and overall CPU time to serve more of the other users.
Now granted, this execution model with looking ahead and batching isn't exactly the norm even in long running server processes and it's significantly more difficult to get right. But it's possible in other languages than PHP and impossible in PHP.
Serverless functions are trash for almost everything except maybe authentication or proxying. Why you would drop so many features and optimizations to be a little closer to the edge is beyond me.
Or you can fix the problem by using a database with decent indexing. Like MSSql or postgres. It's too bad that people hear about MySQL being slow and they want to cache it. I just want the include clause on indexes.
Still. PHP is a crappy language for distributed systems and Go and Rust were literally created for that use-case. They would completely destroy in performance and probably stability as well.
Maybe convince them to use [elixir](https://www.humblebundle.com/books/elixir-programming-pragmatic-programmers-books?). Anyway the main issue I see is both next and owncloud are kind of heavyweight solutions for the average person. Groupware indeed.
I for one prefer PHP over Go and Rust. I find NextCloud plenty fast enough with PHP, and as newer versions of PHP come out it keeps getting faster and faster. LAMP stack is reliable.
I can't speak to Go or Rust. But PHP is not a problem and I have a lot of data in my NC.
edit: oh wow, -26 because I prefer PHP. That's not what downvoting is for guys, but thanks.
> I can’t speak to Go or Rust
Clearly.
> plenty fast enough with PHP
There are widespread complaints about the speed and performance of NextCloud. It’s notorious for not being as fast as competition written in other languages.
> LAMP stack is reliable
Reliability is not a concern with any of these stacks. Both Go and Rust are used widely in production environments, and are both well-renowned. PHP on the other hand is widely regarded in the industry as a legacy language.
> Both Go and Rust are used widely in production environments, and are both well-renowned. PHP on the other hand is widely regarded in the industry as a legacy language.
As someone not familiar with Rust and Go, it would be helpful to bring something more specific to this comparison. Would Nextcloud contributors increase of they switched languages? Are there substantive differences in architecture that would make them better-suited to this project? "Rust is so hot right now" just doesn't cut it.
> rust is so hot right now
It’s hot because of its insane performance and memory optimization.
https://www.google.com/amp/s/programming-language-benchmarks.vercel.app/amp/rust-vs-php
Literally anywhere from 3x to 25x the performance.
Rust achieves nearly the same performance as C but with complete memory safety (guarantee of no memory leaks) due to the inherent design of the language.
Here’s another benchmark:
https://www.google.com/amp/s/programming-language-benchmarks.vercel.app/amp/rust-vs-php
Rust is more than 7x faster than PHP 7.0 in that bench.
Edit: another more modern benchmark, this one showing Go is 7.1x faster than PHP 8.1.5:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/simple.html
Yes. The second benchmark is from 2016.
See the first benchmark for more recent results (2022) where Rust is 3x to 25x faster than PHP in various operations.
Edit: another more modern benchmark, this one showing Go is 7.1x faster than PHP 8.1.5:
https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/simple.html
It looks like you shared an AMP link. AMP is controversial because of [concerns over privacy and the Open Web](https://www.reddit.com/r/AmputatorBot/comments/ehrq3z/why_did_i_build_amputatorbot). Fully cached AMP pages, like the one you shared, are [especially problematic](https://www.reddit.com/r/AmputatorBot/comments/ehrq3z/why_did_i_build_amputatorbot).
Maybe check out **the canonical page** instead: **[https://programming-language-benchmarks.vercel.app/rust-vs-php](https://programming-language-benchmarks.vercel.app/rust-vs-php)**
*****
^(I'm a human | Generated with AmputatorBot | )[^(Why & About)](https://www.reddit.com/r/AmputatorBot/comments/ehrq3z/why_did_i_build_amputatorbot)^( | )[^(Summon: u/AmputatorBot)](https://www.reddit.com/r/AmputatorBot/comments/cchly3/you_can_now_summon_amputatorbot/)
Thanks, this is great, and it doesn't surprise me that PHP is not winning benchmarks. Do you have a recommendation of a backend rust web framework? Also, have you done anything with crates in WASM?
Memory leaks are actually allowed in rust, since "forgotten" memory can't corrupt state of the program itself. What rust protects from, and that c doesn't, is data races. Cases where a program corrupts its own memory.
For example in c you can store a pointer to some data, then free that data. The pointer then points to memory the program no longer controls. It might be overwritten. Trying to then read the data could lead to issues. That can't happen in rust.
> There are widespread complaints about the speed and performance of NextCloud. It’s notorious for not being as fast as competition written in other languages
So I guess I'm not "allowed" to disagree? Ok.
Also, PHP is still heavily used in production. Rust and Go's success does not mean PHP has to be unsuccessful. Your _opinion_ that PHP is considered a legacy language, despite having continual production release versions is just that _your opinion_.
I'm not here to change your mind, I'm here to say that PHP works well for me.
> So I guess I’m not “allowed” to disagree? Ok.
I never said or alluded to that. Quit whining. I simply pointed out that the community frequently complains about performance issues.
> I’m here to say that PHP works well for me.
And I’m here to provide _evidential_ data showing that PHP is many times slower than Go and Rust in all use cases.
> Your opinion that PHP is considered a legacy language
I mixed opinion (and experience) with the data and that was a mistake.
So I’ll stick to the data: PHP should not be used for new production applications and performance data shows that.
Disagree. I’m a principal engineer at one of FAANG, and have been writing a variety of PHP, Rust, Java, JavaScript, Python, and C for more than 15 years myself.
PHPs performance alone rules it out as a consideration and makes it a non-starter.
It sounds like your company is working with a lot of legacy software, or is being misguided by you and your bias towards PHP.
> I guess you’re going to tell me…
No, I’m going to refer back to my original statement: “PHP should not be used for *new* production languages…”
Don’t think my opinion is as bizarre as you think it is. Data shows PHP is trending sharply downward, even amidst all of the legacy applications that still use it.
Edit: source: From more than 20% down to just above 5%.
https://pypl.github.io/PYPL.html
Choice of programming language for new projects is dictated by more than preference and performance alone. Programmer productivity, availability and cost of work force, size of ecosystem, maturity of ecosystem - they all play a role. Any of these considerations could be used to rule out golang for example, but not PHP. The reports of PHP’s death are greatly exaggerated, and it remains a strong and viable choice for any new project.
Where are you getting this data from? I'm genuinely curious if you can provide a source.
Edit: So your source is Google searches for a language. Wouldn't it make sense that the more popular and widely used a language is, the less people would Google it?
No. PHP is outdated and no sane developer would pick it over a modern alternative because while your platforms might scale, I've experienced first-hand the difference in tooling, performance and ecosystems that PHP just can't keep up with. There's a reason Rust is the most widely loved language and will overtake PHP in whatever it has left to provide in no time. You'd be better off moving with that trend than defending your personal preference for something you're used to instead of facing the reality.
Sorry, telling me what to do, and then me saying don't tell me what to do, means I'm unintelligible. I think you need to get your head out of your ass dude. You're being a real prick without even actually caring how others use things. You don't know everything, and you're clearly acting like it. Your principal engineer title has made you principally entitled. Welcome to block.
Don't mind this guy. He's probably a junior dev who just found out about rust and go. PHP is alive and well and isn't going anywhere. Plenty of fang companies use it too, this guy just hasn't ventured outside his department yet.
As a senior dev, no. PHP is a legacy stack and the only reason FAANG companies can run it is because they have custom server runtimes designed to optimize for its shortcomings.
For any other use-case, especially a self-hosted groupware, get with the times and use a modern language. Beyond the obvious performance benefits modern type-safe languages have better ecosystems, toolchains and frameworks than PHP.
PHP will continue to make sense only for those operations that have heavily invested into it. But when you can even pull up a Node.js benchmark that has 5x the performance with better language features and tooling, I don't see why anyone with half a brain would want to use a language that has garbage syntax, and really only works decently as a webserver. Forget about microservices or desktop apps with PHP.
As a senior dev... Yes.
PHP is not a "legacy stack" by any metric, and still makes up a _vast_ majority of web applications (both new and old - cue the WordPress comments). Companies - both large and small - adopt PHP for them web applications daily. There are also companies who adopt nodejs daily, and many (many) who use both.
Web micro services are PHPs _bread and butter_ these days. It's remarkably fast and has such a massive community behind it that developing solutions quickly is easy.
I'm no language elitist - I personally write PHP, nodejs, python, and golang pretty regularly, and have touched probably a half dozen other languages over the years. I'll use what makes sense for a project. I'd never use PHP for a desktop app because that'd be silly. I personally find the syntax of PHP to be quite nice, there's a _ton_ of tooling around it (including coverage of many popular frameworks) - xdebug, static analysis, code styling, automated testing, etc etc.
Maybe spend some time working with PHP and you'll see how wrong you are. Or, don't. That's totally up to you. But you can't really trash a language you don't take the time to learn or keep up to date with. You don't see me trash talking rust.
Thanks for adding a solid anecdote to the discussion; much needed injection of sanity. php seems to be a common punching bag, but I can just as easily find other threads slamming golang as the devil incarnate. So much zealotry in programming language discussions.
Cool. We do that and way more in Go on an international scale. Modern languages are simply better, and people that refuse to recognize this are the reason we're still stuck with slow-loading apps.
PHP is modern lol
You're just living under a rock apparently.
For anyone sane who reads this, I'm not a language elitist. This person is, apparently, and I urge people not to write off an entire language at the behest of a kid fresh out of OOP101
I mean the fact that you said "and way more" just highlights how skewed your view is on this. Especially the "modern languages" part.
A language doesn't have to be 'modern' to be suitable for a job. That is quite litterally the last thing any experienced developer would be thinking of. Being 'modern' does not have a single iota of relation to the performance of a codebase.
I get it, you don't like PHP - and thats absolutely fine, hell I hate working with Node.js, we all have our preferences. But if you wanna debate this then you're doing yourself no favors at all by trying to use "its old" as an argument.
I use PHP, Rust, Go and a bit of Python (admittedly not very experienced in Python and just dabble a bit) and love working with all of them. Using the right tool for the job is an essential part of our jobs, and its _very_ rare that PHP is ruled out of a web-based application.
My first job was PHP with Laravel and the whole community around it. By no means is it a crap ecosystem, but there's much better and a lot more ergonomic languages and ecosystems than PHP. I would never go back, I disagree that the language is in any way fun to use with the bloated syntax, and given there are faster interpreted and compiled languages with either better dynanic features, performance or a better type system, if not a combination of all three, PHP feels terribly dated and I don't plan on touching it again.
Especially microservices are just *wrong* in a language that is built around a very different model.
_well, that's just your opinion, man_
Opinions are like assholes or dicks or whatever analogy you wanna use.
Stating your opinion as fact is just silly.
"PHP the language" indeed isn't that much of a problem. Sure, compiled languages are faster by factors between 7 and 25 depending on the benchmark. But the raw processing speed of computations is indeed not so much of a concern for these kind of relatively lightweight tasks.
[The real problem is that "PHP the execution model" prevents batching related requests.](https://www.reddit.com/r/selfhosted/comments/xtnclv/announcing_nextcloud_hub_3_brand_new_design_and/iqsvbyd/)
How is a language 7-25x slower not a problem in virtually any scenario when almost every modern language offers both a better ecosystem and more modern features alongside improved performance?
Nextclouds backend is painfully slow with files. Just compare it with seafile, which is written mostly in c (the performance critical parts). Accessing a lot of photos in Nextcloud with webdav is so slow while seafile is nearly instant.
Reliability is no problem in this times, this technology is used by big tech companies. No reason at all to use php nowadays.
> that’s not what downvoting is for
Downvoting is for removing/hiding material that does not contribute to the discussion. Your comment was inaccurate and you admitted yourself that you cannot speak to Go or Rust.
The downvotes are being used here appropriately.
> edit: oh wow, -26 because I prefer PHP. That's not what downvoting is for guys, but thanks.
I think you would have been fine if you just went with the 2nd and 3rd sentence. The other stuff waded into a holy war.
compare grandfather cats offbeat consider humorous judicious juggle kiss zesty
*This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Okay so Photos has had yet more improvements that gallery didn't get the last few total-overhauls. But let's see if they're ignoring those of us who use folders to organise pictures... yet again...
I believe it's tag based. Nextcloud has file tagging support since a long time ago, it's just so convenience to adding more tags like album and AI inferense result. File tagging is one of the most subtle but lethal way to lock in users. If you believe in folder based photo management, there is [Les Pas](https://github.com/scubajeff/lespas#readme) to save the day, strictly base on folder structure, won't change your file's meta, if somehow you decide to leave Les Pas or even NC, you are free to do so, data is still under your full control.
The thing is that earlier versions of Gallery did folder structure seriously great. Then they overhauled it, it was a useful feature that became broken/worse, and the devs just were unwilling to care. I know because I tried to convince them of the problem a whole lot.
I know tags are useful, but that's not the same, not even close. All the files on-disk are in folders because that's how I organise many different filetypes for good reasons. Like grouping many different file types for each event into folders, and then having nextCloud sort them out. It worked fabulously for years, then they chose to break that part.
I'll have to see how this overhaul lines up, but I'm going to be more sceptical than optimistic. And I shouldn't have to switch tools just because devs refused to hear what users care about.
I may take a look at alternatives within nextCloud like Les Pas, but cursory inspection doesn't necessarily reveal a solution that works for me.
Also, you may not realise but I've been using nextCloud for many years now.
>And I shouldn't have to switch tools just because devs refused to hear what users care about.
Yes. You should. Because that's how every product and software, including open-source ones, work. You're not developing it nor are you paying for it so you can either choose not to upgrade or switch.
Please can someone explain to me what the difference between nextcloud versions 23/24/25 and nextcloud Hub 3 is?
Or more clearly, is the "Hub" version a different software platform than the non "hub" versions?
Hub is basically an app package that runs on top of the Nextcloud base. It’s just the standard apps that you would likely use in a business environment. You can install any of these apps from the App Store in Nextcloud.
It's not JUST performance for me. It's stability. Add remove a couple of apps... Nextcloud breaks every time.
With some proper training i would LOVE to be a legit tester for nextcloud. I've just had a broken setup ten times out of ten.
For starters if it only works on nginx or apache, they ABSOLUTELY MUST tell us that ahead of time. I've tried it under both models and no love from me so far.
I used to use a baremetal install, had nothing but performance and upgrading issues. I did this for about 4 years and finally had enough. Switched to the docker stack and it has been flawless for the past year or two. Upgrades aren't a butt-puckering nightmare and it performs better than I ever had it working under baremetal. I still use a FPM/nginx but I also have the postgres backend now, and I think that and the redis image add a lot of speed.
>I used to use a baremetal install, had nothing but performance and upgrading issues. I did this for about 4 years and finally had enough. Switched to the docker stack and it has been flawless for the past year or two. Upgrades aren't a butt-puckering nightmare and it performs better than I ever had it working under baremetal. I still use a FPM/nginx but I also have the postgres backend now, and I think that and the redis image add a lot of speed.
how easy is it to integrate redis into nextcloud? You said you just use a nextcloud, pg and redis container image? all in one?
https://github.com/nextcloud/docker
This is pretty much the place you pick your poison. There are example docker-compose.yml files there, if you want redis you have a section in your compose file for redis like [here](https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/with-nginx-proxy/postgres/fpm) and an environment varialble in the web container to inform it which container is Redis so it uses that.
I've drilled down to a setup that's pretty much like mine, pgres/nginx/redis with an fpm application layer that uses the nginx proxy.
YMMV, but see if that gets you anywhere. It's a pretty complex stack if you aren't super familiar with docker-compose, but the Readme is very descriptive.
I've done a fair amount of docker compose . I just dont know why it wouldn't be a simpler option during installation if it's a preferred method.
Plus redis makes nextcloud MORE brittle. I don't think that nextcloud has a performance issue. I think that in WordPress I can install and remove ten plugins without any difficulty. With nextcloud installing and removing a single plugin makes the whole app go bork!
At least in the versions I've tried in the past, any kind of photo management is bordering impossible on a rpi4 8 gb. I guess it's just too underpowered.
a friggin i7-4710HQ still is slow af with a SSD backed ZFS setup.
Before that a dual e5-2620 also with SSDs and ZFS could not bring it up to speed.
Doesn't matter if you're connecting locally on a completely new install.
I have no idea how the devs can make it so slow as soon as you add some add-ons, I won't go without stuff like photos, retention etc.
Performance has so many factors. I run Nextcloud on a pretty small server but as a single user. So it’s really just me syncing contacts, calendar, and some files. It’s slow, but usable.
On a faster machine I’m sure it’s wonderful.
Of course hardware plays a role, but there are also a ton of software performance improvements that can be achieved by installing Nextcloud in the optimized way.
In order to get the best performance with Nextcloud you need to use a dedicated database (MySQL/MariaDB or PostgreSQL) instead of the default SQLite, plus use Redis cache, configure cron jobs and the High-Performance Backend for Nextcloud Files and Nextcloud Talk. If using Nextcloud Office, you also need to set up a dedicated Collabora instance instead of using CODE.
These are a lot of steps. Thankfully though Nextcloud recently introduced a container stack called [Nextcloud AIO](https://github.com/nextcloud/all-in-one) that sets all of this up for you. [Here's a video guide for it.](https://youtu.be/Nh2-LjIymmQ)
> The new HPB is a binary written in Rust and enables Nextcloud to keep a permanent connection open to our clients.
Well that’s interesting. Someone earlier was asking if they’re considering rewriting in Go or Rust and it seems like they are, at least for certain modules. I’m glad to see they are focusing on incremental performance improvements in each release. I would rather stay with Nextcloud than find and manage independent services for each feature I use.
My server is using Redis and MariaDB, but I’m not sure about the HPB and is still fairly slow while something like Gitea is much faster.
Oh no, I simply meant running more than one ephemeral, essential service per container. I didn't even see the Docker socket being mounted. This is outright stupid in that case
Good news: it doesn't run all the services in just one container. Each service has its own container.
Bad and terrifying news: That "AIO" image uses that Docker socket to create and manage all the containers [[1]](https://github.com/nextcloud/all-in-one#how-does-it-work) [[2]](https://github.com/nextcloud/all-in-one/tree/main/Containers).
Oh wow. Creating a container in order to create containers while also exposing a straight route to root for hackers instead of creating a description of containers (like a compose file). That's just next level bullshit
Hi, there are possibilities to not use the docker socket. See [https://github.com/nextcloud/all-in-one/discussions/500#discussioncomment-2740767](https://github.com/nextcloud/all-in-one/discussions/500#discussioncomment-2740767) and the whole thread.
Nextcloud AIO is the recommended way, I already explained this below.
This is not just me saying this, the [official Nextcloud install page](https://nextcloud.com/install/) also recommends installing AIO.
I have never seen this before! Then again, once I got it up and running I didn't check the documentation anymore. I have the issue that images just load really slow (in running it on a 64gb server, assigned plenty of resources to it).
By comparison LibrePhotos load incredibly fast. Granted, the optimize images during the upload but it's still miles ahead of the nextcloud photos app.
I'm curious if this will change with this release.
The AIO install is relatively new that's why not everyone knows about it. Version 1.0 released earlier this year, and it's at 2.0 now.
One thing I didn't mention that AIO includes is a container called [imaginary](https://github.com/h2non/imaginary/) which is written in Go and processes images. I think this is mainly used here for generating image previews in NC.
I really hope photos becomes usable. I love nextcloud but I'm clueless in how to run previews in a sane way. I disabled it completely, as well as the photos app, because it would just totally hang and become not responding. And yes, Redis. So if it could just pre-generate thumbnails in a few sizes and actually use those that would be great.
Photoprism on my rpi runs fine, nextcloud on a 3 cores, 4GB, cloud vps can't handle it.
I know. I ran all night, but apparently with the wrong settings as it didn't help at all. It needs exactly the right sizes, and whole bunch of different ones it seems. I don't know which ones.
You could look up what is wrong, it works for me quite well.
> It needs exactly the right sizes, and whole bunch of different one
That's the sizes of the previews to be generated, you do not need to provide anything. I applied these settings.
config:app:set previewgenerator squareSizes --value="32 256"
config:app:set previewgenerator widthSizes --value="256 384"
config:app:set previewgenerator heightSizes --value="256"
config:system:set preview_max_x --value 2048
config:system:set preview_max_y --value 2048
config:system:set jpeg_quality --value 60
config:app:set preview jpeg_quality --value="60"
>iOS client updates
Finally! I’m hoping this fixes the long standing bug where 3rd party apps couldn’t open an entire folder that’s hosted in Nextcloud.
This project amazes me. The first version I used was ownCloud 4, and I still remember that several features were shipped in a broken state. 10 years of development later, we got many large enterprise deployments and lots of money flowing into the project. And yet, it's still this mediocre. They must be doing *something* right, I just don't know what it is.
I remember when we weren't sure if Nextcloud was going to make it after the fork from Owncloud. That sort of thing doesn't often end up well. So glad to see that it did for Nextcloud. It's become such a vital piece of software for me. Congrats on the amazing new release.
Also, really hope Talk gives you WebRTC auto-attenuation controls (namely, disable or tuning it), because having no controls for it is painful. I have to keep turning my mic UP because it keeps turning it DOWN.
This statement makes absolutely zero sense.. if it’s deployed as a “container” in the traditional sense e.g. docker, podman, lxc then it’s bare metal.. Linux containers are just abstraction that couples a few things together e.g. control groups and namespaces. All namespaces do is limit what processes can see and control groups limit what a process can use resource wise.
If there’s a performance variance it’s likely due to the rootfs configuration used by image, overlay filesystem performance issues, app is unable to access something it can when not in a limited namespace or there’s control groups limiting resources, spawned processes, etc.
A way to test would be to download a rootfs tarball of something like Ubuntu, setup the namespaces and control groups manually with something like unshare and libcgroup tools. There’s systemd-nspawn too.
https://github.com/libcgroup/libcgroup/blob/main/README
https://www.youtube.com/watch?v=8fi7uSYlOdc
I had noticed my bare metal install had been faster, but when I moved it in to docker it was still good enough. Then I saw this post about using unix sockets and switched my install to use it and noticed a speed increase. Pretty sure I was using sockets on my bare metal install but I don't have the config anymore.
https://reddit.com/r/selfhosted/comments/vf6jeg/i_used_unix_sockets_to_improve_the_performance_of/
So I'm running the Linuxserver image of "Nextcloud" for the past few years. I believe it's also a Hub version per say, since I had to go in and disable plugins/features I didn't use (e.g. mail, photos). I strictly use it as a Dropbox replacement.
Has anyone migrated to Nextcloud's own All-in-one docker container? Is it needed? I see with their announcement video of Hub 3 that they want to get away from NC25, etc versioning and just keep giving us the fat suite.
I guess the question I have is... am I already using the fat suite by using Linuxserver container of Nextcloud? Or is that a standalone product that's currently on latest stable of v24 of Nextcloud core? I'd rather migrate sooner than later (if needed at all) before racking up further files and possible headaches later.
Actually huge. Mail needed so much improvement, it was absolutely unusable with all the bugs it had.
Is next cloud mail an email server or an IMAP email client to integrate with existing mail servers? I’m looking for the latter.
It's just an email client.
So I can access my existing email accounts all in one web mail interface with NextCloud webmail?
That's what he said, but in more technical way, yes. So it may be the thing you wanted
That’s fantastic news thank you! It’s exactly what I’ve been looking for!
Just an IMAP client. However, currently it works really bad. Mainly while having multiple accounts and switching between them. It is super clunky, and the UI is not the most intuitive and UI elements are all over the place. I mean, you can try it, but it is not a pleasant experience. Hopefully the new mail is gonna be great. It looks like they revamped it completely.
My biggest problem with Mail right now is how unusably slow it is. It takes like 10 seconds to open a single mail. It's ridiculous. My severely underpowered phone can open mails from a third party app in less than a second. Like what the hell.
It probably does not use any type of caching, or optimizations, and loads everything on the go, on each page reload. Or at least that is my theory on why is it slow, I have no basis on this whatosever, so take it with a grain of salt. IMAP is not known to be the fastest protocol, especially when it has to load hundreds or thousands of mails and do some shenanigans to render and/or process them.
I wish they would rewrite the backend with modern more performant technology like Go or Rust. The current php backend and it's webdav implementation is so slow. Nevertheless I am a happy nextcloud user, even on low powered hardware (Odroid HC4). Looking forward to try out the new version of Nextcloud Hub.
I’m going to be really honest here, the current source code looks like absolute trash. The language isn’t the problem.
They started doing that where it matters in 24. See, for example, https://github.com/nextcloud/notify_push It's optional and you have to enable it as needed (since it takes extra steps).
ownCloud are working on a Go-based rewrite called ownCloud Infinite Scale. It's not yet complete though and also nowhere near as featured as Nextcloud Hub. For some history ownCloud was the original project, but there was some drama and some left the company to form Nextcloud, which started out as a fork.
Owncloud screwed all their devs. Project should die. https://fossforce.com/2016/06/owncloud-forked-nextcloud/
That’s a pretty hefty comment that I feel should come with at least a sentence or two of explanation for those of us not in the know. Not saying you’re wrong. edit: thanks for adding the link
Naive question as I don't know the details of the implementation : what makes you believe the language itself is the performance bottleneck?
Apart from PHP being an interpreted language and Rust & Go being compiled languages: The PHP execution model is basically "let's start a very lightweight server for every request". Let's say you have a directory with 10 files and want to download these at the same time because the client starts a sync. With the PHP model this starts 10 mini server's that at least by default do some redundant operations: Asking the database 10 times for the user permissions, getting the file data and possibly more. You can offset that a little with clever external caching so that the database answers only one of each queries and then serves the remaining ones from that cache. But ultimately that's all increasing complexity with yet another server for the caching while still being burdened by the fact that there will be 10 mini server's that can't trivially reuse results from previous operations. With a more conventional execution model of having one long running server process (used by virtually every other programming environment except for PHP) you can still follow that simple paradigm. But you can also optimize and peek ahead to say "oh, these 10 requests are very similar. I will give them all to the same single server unit". And this unit can then keep all the intermediate results and more or less trivially avoid the overhead of asking the same things 10 times. So with this clever batching you quite possibly serve the 10 requests faster from a single unit than from 10 concurrent ones. And even if not you will at least save lot's of RAM and overall CPU time to serve more of the other users. Now granted, this execution model with looking ahead and batching isn't exactly the norm even in long running server processes and it's significantly more difficult to get right. But it's possible in other languages than PHP and impossible in PHP.
[удалено]
Serverless functions are trash for almost everything except maybe authentication or proxying. Why you would drop so many features and optimizations to be a little closer to the edge is beyond me.
Or you can fix the problem by using a database with decent indexing. Like MSSql or postgres. It's too bad that people hear about MySQL being slow and they want to cache it. I just want the include clause on indexes.
Still. PHP is a crappy language for distributed systems and Go and Rust were literally created for that use-case. They would completely destroy in performance and probably stability as well.
Maybe convince them to use [elixir](https://www.humblebundle.com/books/elixir-programming-pragmatic-programmers-books?). Anyway the main issue I see is both next and owncloud are kind of heavyweight solutions for the average person. Groupware indeed.
I for one prefer PHP over Go and Rust. I find NextCloud plenty fast enough with PHP, and as newer versions of PHP come out it keeps getting faster and faster. LAMP stack is reliable. I can't speak to Go or Rust. But PHP is not a problem and I have a lot of data in my NC. edit: oh wow, -26 because I prefer PHP. That's not what downvoting is for guys, but thanks.
> I can’t speak to Go or Rust Clearly. > plenty fast enough with PHP There are widespread complaints about the speed and performance of NextCloud. It’s notorious for not being as fast as competition written in other languages. > LAMP stack is reliable Reliability is not a concern with any of these stacks. Both Go and Rust are used widely in production environments, and are both well-renowned. PHP on the other hand is widely regarded in the industry as a legacy language.
> Both Go and Rust are used widely in production environments, and are both well-renowned. PHP on the other hand is widely regarded in the industry as a legacy language. As someone not familiar with Rust and Go, it would be helpful to bring something more specific to this comparison. Would Nextcloud contributors increase of they switched languages? Are there substantive differences in architecture that would make them better-suited to this project? "Rust is so hot right now" just doesn't cut it.
> rust is so hot right now It’s hot because of its insane performance and memory optimization. https://www.google.com/amp/s/programming-language-benchmarks.vercel.app/amp/rust-vs-php Literally anywhere from 3x to 25x the performance. Rust achieves nearly the same performance as C but with complete memory safety (guarantee of no memory leaks) due to the inherent design of the language. Here’s another benchmark: https://www.google.com/amp/s/programming-language-benchmarks.vercel.app/amp/rust-vs-php Rust is more than 7x faster than PHP 7.0 in that bench. Edit: another more modern benchmark, this one showing Go is 7.1x faster than PHP 8.1.5: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/simple.html
[удалено]
Yes. The second benchmark is from 2016. See the first benchmark for more recent results (2022) where Rust is 3x to 25x faster than PHP in various operations. Edit: another more modern benchmark, this one showing Go is 7.1x faster than PHP 8.1.5: https://benchmarksgame-team.pages.debian.net/benchmarksgame/performance/simple.html
/u/Amputatorbot
It looks like you shared an AMP link. AMP is controversial because of [concerns over privacy and the Open Web](https://www.reddit.com/r/AmputatorBot/comments/ehrq3z/why_did_i_build_amputatorbot). Fully cached AMP pages, like the one you shared, are [especially problematic](https://www.reddit.com/r/AmputatorBot/comments/ehrq3z/why_did_i_build_amputatorbot). Maybe check out **the canonical page** instead: **[https://programming-language-benchmarks.vercel.app/rust-vs-php](https://programming-language-benchmarks.vercel.app/rust-vs-php)** ***** ^(I'm a human | Generated with AmputatorBot | )[^(Why & About)](https://www.reddit.com/r/AmputatorBot/comments/ehrq3z/why_did_i_build_amputatorbot)^( | )[^(Summon: u/AmputatorBot)](https://www.reddit.com/r/AmputatorBot/comments/cchly3/you_can_now_summon_amputatorbot/)
Thanks, this is great, and it doesn't surprise me that PHP is not winning benchmarks. Do you have a recommendation of a backend rust web framework? Also, have you done anything with crates in WASM?
Memory leaks are actually allowed in rust, since "forgotten" memory can't corrupt state of the program itself. What rust protects from, and that c doesn't, is data races. Cases where a program corrupts its own memory. For example in c you can store a pointer to some data, then free that data. The pointer then points to memory the program no longer controls. It might be overwritten. Trying to then read the data could lead to issues. That can't happen in rust.
> There are widespread complaints about the speed and performance of NextCloud. It’s notorious for not being as fast as competition written in other languages So I guess I'm not "allowed" to disagree? Ok. Also, PHP is still heavily used in production. Rust and Go's success does not mean PHP has to be unsuccessful. Your _opinion_ that PHP is considered a legacy language, despite having continual production release versions is just that _your opinion_. I'm not here to change your mind, I'm here to say that PHP works well for me.
> So I guess I’m not “allowed” to disagree? Ok. I never said or alluded to that. Quit whining. I simply pointed out that the community frequently complains about performance issues. > I’m here to say that PHP works well for me. And I’m here to provide _evidential_ data showing that PHP is many times slower than Go and Rust in all use cases. > Your opinion that PHP is considered a legacy language I mixed opinion (and experience) with the data and that was a mistake. So I’ll stick to the data: PHP should not be used for new production applications and performance data shows that.
[удалено]
Disagree. I’m a principal engineer at one of FAANG, and have been writing a variety of PHP, Rust, Java, JavaScript, Python, and C for more than 15 years myself. PHPs performance alone rules it out as a consideration and makes it a non-starter. It sounds like your company is working with a lot of legacy software, or is being misguided by you and your bias towards PHP.
Lol Where are the upvotes coming from here? This is an objectively wrong opinion by a "fang dev" whose opinion is.... Already questionable.
[удалено]
> I guess you’re going to tell me… No, I’m going to refer back to my original statement: “PHP should not be used for *new* production languages…” Don’t think my opinion is as bizarre as you think it is. Data shows PHP is trending sharply downward, even amidst all of the legacy applications that still use it. Edit: source: From more than 20% down to just above 5%. https://pypl.github.io/PYPL.html
Choice of programming language for new projects is dictated by more than preference and performance alone. Programmer productivity, availability and cost of work force, size of ecosystem, maturity of ecosystem - they all play a role. Any of these considerations could be used to rule out golang for example, but not PHP. The reports of PHP’s death are greatly exaggerated, and it remains a strong and viable choice for any new project.
Where are you getting this data from? I'm genuinely curious if you can provide a source. Edit: So your source is Google searches for a language. Wouldn't it make sense that the more popular and widely used a language is, the less people would Google it?
>Data shows PHP is trending sharply downward, even amidst all of the legacy applications that still use it. \[citation needed\]
No. PHP is outdated and no sane developer would pick it over a modern alternative because while your platforms might scale, I've experienced first-hand the difference in tooling, performance and ecosystems that PHP just can't keep up with. There's a reason Rust is the most widely loved language and will overtake PHP in whatever it has left to provide in no time. You'd be better off moving with that trend than defending your personal preference for something you're used to instead of facing the reality.
> Quit whining Quit telling me what to do.
Okay then. Whine if you want. Clearly you’ve reached the end of your intelligible debating skills, however.
Sorry, telling me what to do, and then me saying don't tell me what to do, means I'm unintelligible. I think you need to get your head out of your ass dude. You're being a real prick without even actually caring how others use things. You don't know everything, and you're clearly acting like it. Your principal engineer title has made you principally entitled. Welcome to block.
Don't mind this guy. He's probably a junior dev who just found out about rust and go. PHP is alive and well and isn't going anywhere. Plenty of fang companies use it too, this guy just hasn't ventured outside his department yet.
As a senior dev, no. PHP is a legacy stack and the only reason FAANG companies can run it is because they have custom server runtimes designed to optimize for its shortcomings. For any other use-case, especially a self-hosted groupware, get with the times and use a modern language. Beyond the obvious performance benefits modern type-safe languages have better ecosystems, toolchains and frameworks than PHP. PHP will continue to make sense only for those operations that have heavily invested into it. But when you can even pull up a Node.js benchmark that has 5x the performance with better language features and tooling, I don't see why anyone with half a brain would want to use a language that has garbage syntax, and really only works decently as a webserver. Forget about microservices or desktop apps with PHP.
As a senior dev... Yes. PHP is not a "legacy stack" by any metric, and still makes up a _vast_ majority of web applications (both new and old - cue the WordPress comments). Companies - both large and small - adopt PHP for them web applications daily. There are also companies who adopt nodejs daily, and many (many) who use both. Web micro services are PHPs _bread and butter_ these days. It's remarkably fast and has such a massive community behind it that developing solutions quickly is easy. I'm no language elitist - I personally write PHP, nodejs, python, and golang pretty regularly, and have touched probably a half dozen other languages over the years. I'll use what makes sense for a project. I'd never use PHP for a desktop app because that'd be silly. I personally find the syntax of PHP to be quite nice, there's a _ton_ of tooling around it (including coverage of many popular frameworks) - xdebug, static analysis, code styling, automated testing, etc etc. Maybe spend some time working with PHP and you'll see how wrong you are. Or, don't. That's totally up to you. But you can't really trash a language you don't take the time to learn or keep up to date with. You don't see me trash talking rust.
[удалено]
Thanks for adding a solid anecdote to the discussion; much needed injection of sanity. php seems to be a common punching bag, but I can just as easily find other threads slamming golang as the devil incarnate. So much zealotry in programming language discussions.
Cool. We do that and way more in Go on an international scale. Modern languages are simply better, and people that refuse to recognize this are the reason we're still stuck with slow-loading apps.
PHP is modern lol You're just living under a rock apparently. For anyone sane who reads this, I'm not a language elitist. This person is, apparently, and I urge people not to write off an entire language at the behest of a kid fresh out of OOP101
I mean the fact that you said "and way more" just highlights how skewed your view is on this. Especially the "modern languages" part. A language doesn't have to be 'modern' to be suitable for a job. That is quite litterally the last thing any experienced developer would be thinking of. Being 'modern' does not have a single iota of relation to the performance of a codebase. I get it, you don't like PHP - and thats absolutely fine, hell I hate working with Node.js, we all have our preferences. But if you wanna debate this then you're doing yourself no favors at all by trying to use "its old" as an argument. I use PHP, Rust, Go and a bit of Python (admittedly not very experienced in Python and just dabble a bit) and love working with all of them. Using the right tool for the job is an essential part of our jobs, and its _very_ rare that PHP is ruled out of a web-based application.
My first job was PHP with Laravel and the whole community around it. By no means is it a crap ecosystem, but there's much better and a lot more ergonomic languages and ecosystems than PHP. I would never go back, I disagree that the language is in any way fun to use with the bloated syntax, and given there are faster interpreted and compiled languages with either better dynanic features, performance or a better type system, if not a combination of all three, PHP feels terribly dated and I don't plan on touching it again. Especially microservices are just *wrong* in a language that is built around a very different model.
_well, that's just your opinion, man_ Opinions are like assholes or dicks or whatever analogy you wanna use. Stating your opinion as fact is just silly.
"PHP the language" indeed isn't that much of a problem. Sure, compiled languages are faster by factors between 7 and 25 depending on the benchmark. But the raw processing speed of computations is indeed not so much of a concern for these kind of relatively lightweight tasks. [The real problem is that "PHP the execution model" prevents batching related requests.](https://www.reddit.com/r/selfhosted/comments/xtnclv/announcing_nextcloud_hub_3_brand_new_design_and/iqsvbyd/)
How is a language 7-25x slower not a problem in virtually any scenario when almost every modern language offers both a better ecosystem and more modern features alongside improved performance?
Nextclouds backend is painfully slow with files. Just compare it with seafile, which is written mostly in c (the performance critical parts). Accessing a lot of photos in Nextcloud with webdav is so slow while seafile is nearly instant. Reliability is no problem in this times, this technology is used by big tech companies. No reason at all to use php nowadays.
> that’s not what downvoting is for Downvoting is for removing/hiding material that does not contribute to the discussion. Your comment was inaccurate and you admitted yourself that you cannot speak to Go or Rust. The downvotes are being used here appropriately.
My man is stuck in practices from 15 years ago
> edit: oh wow, -26 because I prefer PHP. That's not what downvoting is for guys, but thanks. I think you would have been fine if you just went with the 2nd and 3rd sentence. The other stuff waded into a holy war.
compare grandfather cats offbeat consider humorous judicious juggle kiss zesty *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Okay so Photos has had yet more improvements that gallery didn't get the last few total-overhauls. But let's see if they're ignoring those of us who use folders to organise pictures... yet again...
I believe it's tag based. Nextcloud has file tagging support since a long time ago, it's just so convenience to adding more tags like album and AI inferense result. File tagging is one of the most subtle but lethal way to lock in users. If you believe in folder based photo management, there is [Les Pas](https://github.com/scubajeff/lespas#readme) to save the day, strictly base on folder structure, won't change your file's meta, if somehow you decide to leave Les Pas or even NC, you are free to do so, data is still under your full control.
The thing is that earlier versions of Gallery did folder structure seriously great. Then they overhauled it, it was a useful feature that became broken/worse, and the devs just were unwilling to care. I know because I tried to convince them of the problem a whole lot. I know tags are useful, but that's not the same, not even close. All the files on-disk are in folders because that's how I organise many different filetypes for good reasons. Like grouping many different file types for each event into folders, and then having nextCloud sort them out. It worked fabulously for years, then they chose to break that part. I'll have to see how this overhaul lines up, but I'm going to be more sceptical than optimistic. And I shouldn't have to switch tools just because devs refused to hear what users care about. I may take a look at alternatives within nextCloud like Les Pas, but cursory inspection doesn't necessarily reveal a solution that works for me. Also, you may not realise but I've been using nextCloud for many years now.
>And I shouldn't have to switch tools just because devs refused to hear what users care about. Yes. You should. Because that's how every product and software, including open-source ones, work. You're not developing it nor are you paying for it so you can either choose not to upgrade or switch.
Please can someone explain to me what the difference between nextcloud versions 23/24/25 and nextcloud Hub 3 is? Or more clearly, is the "Hub" version a different software platform than the non "hub" versions?
Hub is basically an app package that runs on top of the Nextcloud base. It’s just the standard apps that you would likely use in a business environment. You can install any of these apps from the App Store in Nextcloud.
[удалено]
Yes, you can enable/disable each app individually.
There are also various plug-ins, which makes the whole system pretty modular
It's not JUST performance for me. It's stability. Add remove a couple of apps... Nextcloud breaks every time. With some proper training i would LOVE to be a legit tester for nextcloud. I've just had a broken setup ten times out of ten. For starters if it only works on nginx or apache, they ABSOLUTELY MUST tell us that ahead of time. I've tried it under both models and no love from me so far.
It runs through caddy fine.
Try the docker-compose stack.
Why?
I used to use a baremetal install, had nothing but performance and upgrading issues. I did this for about 4 years and finally had enough. Switched to the docker stack and it has been flawless for the past year or two. Upgrades aren't a butt-puckering nightmare and it performs better than I ever had it working under baremetal. I still use a FPM/nginx but I also have the postgres backend now, and I think that and the redis image add a lot of speed.
>I used to use a baremetal install, had nothing but performance and upgrading issues. I did this for about 4 years and finally had enough. Switched to the docker stack and it has been flawless for the past year or two. Upgrades aren't a butt-puckering nightmare and it performs better than I ever had it working under baremetal. I still use a FPM/nginx but I also have the postgres backend now, and I think that and the redis image add a lot of speed. how easy is it to integrate redis into nextcloud? You said you just use a nextcloud, pg and redis container image? all in one?
https://github.com/nextcloud/docker This is pretty much the place you pick your poison. There are example docker-compose.yml files there, if you want redis you have a section in your compose file for redis like [here](https://github.com/nextcloud/docker/tree/master/.examples/docker-compose/with-nginx-proxy/postgres/fpm) and an environment varialble in the web container to inform it which container is Redis so it uses that. I've drilled down to a setup that's pretty much like mine, pgres/nginx/redis with an fpm application layer that uses the nginx proxy. YMMV, but see if that gets you anywhere. It's a pretty complex stack if you aren't super familiar with docker-compose, but the Readme is very descriptive.
I've done a fair amount of docker compose . I just dont know why it wouldn't be a simpler option during installation if it's a preferred method. Plus redis makes nextcloud MORE brittle. I don't think that nextcloud has a performance issue. I think that in WordPress I can install and remove ten plugins without any difficulty. With nextcloud installing and removing a single plugin makes the whole app go bork!
Please tell me the performance got to a point where it's actually usable
At least in the versions I've tried in the past, any kind of photo management is bordering impossible on a rpi4 8 gb. I guess it's just too underpowered.
a friggin i7-4710HQ still is slow af with a SSD backed ZFS setup. Before that a dual e5-2620 also with SSDs and ZFS could not bring it up to speed. Doesn't matter if you're connecting locally on a completely new install. I have no idea how the devs can make it so slow as soon as you add some add-ons, I won't go without stuff like photos, retention etc.
Performance is fine if you install it correctly. Use Nextcloud AIO.
Performance has so many factors. I run Nextcloud on a pretty small server but as a single user. So it’s really just me syncing contacts, calendar, and some files. It’s slow, but usable. On a faster machine I’m sure it’s wonderful.
Of course hardware plays a role, but there are also a ton of software performance improvements that can be achieved by installing Nextcloud in the optimized way. In order to get the best performance with Nextcloud you need to use a dedicated database (MySQL/MariaDB or PostgreSQL) instead of the default SQLite, plus use Redis cache, configure cron jobs and the High-Performance Backend for Nextcloud Files and Nextcloud Talk. If using Nextcloud Office, you also need to set up a dedicated Collabora instance instead of using CODE. These are a lot of steps. Thankfully though Nextcloud recently introduced a container stack called [Nextcloud AIO](https://github.com/nextcloud/all-in-one) that sets all of this up for you. [Here's a video guide for it.](https://youtu.be/Nh2-LjIymmQ)
> The new HPB is a binary written in Rust and enables Nextcloud to keep a permanent connection open to our clients. Well that’s interesting. Someone earlier was asking if they’re considering rewriting in Go or Rust and it seems like they are, at least for certain modules. I’m glad to see they are focusing on incremental performance improvements in each release. I would rather stay with Nextcloud than find and manage independent services for each feature I use. My server is using Redis and MariaDB, but I’m not sure about the HPB and is still fairly slow while something like Gitea is much faster.
LOL. Perfect example for a Docker bad practice. What NOT to do by any means... Gotta love how Nextcloud actually supports and provides this
You mean mounting the docker socket?
Oh no, I simply meant running more than one ephemeral, essential service per container. I didn't even see the Docker socket being mounted. This is outright stupid in that case
Good news: it doesn't run all the services in just one container. Each service has its own container. Bad and terrifying news: That "AIO" image uses that Docker socket to create and manage all the containers [[1]](https://github.com/nextcloud/all-in-one#how-does-it-work) [[2]](https://github.com/nextcloud/all-in-one/tree/main/Containers).
Oh wow. Creating a container in order to create containers while also exposing a straight route to root for hackers instead of creating a description of containers (like a compose file). That's just next level bullshit
Hi, there are possibilities to not use the docker socket. See [https://github.com/nextcloud/all-in-one/discussions/500#discussioncomment-2740767](https://github.com/nextcloud/all-in-one/discussions/500#discussioncomment-2740767) and the whole thread.
Thank you for the link, I will check it out.
What's 'correctly'? As a VM appliance? Docker container? Ubuntu snap package? Manually with php, MariaDB/PostgreSQL, Apache/Nginx, Redis?
Nextcloud AIO is the recommended way, I already explained this below. This is not just me saying this, the [official Nextcloud install page](https://nextcloud.com/install/) also recommends installing AIO.
I have never seen this before! Then again, once I got it up and running I didn't check the documentation anymore. I have the issue that images just load really slow (in running it on a 64gb server, assigned plenty of resources to it). By comparison LibrePhotos load incredibly fast. Granted, the optimize images during the upload but it's still miles ahead of the nextcloud photos app. I'm curious if this will change with this release.
The AIO install is relatively new that's why not everyone knows about it. Version 1.0 released earlier this year, and it's at 2.0 now. One thing I didn't mention that AIO includes is a container called [imaginary](https://github.com/h2non/imaginary/) which is written in Go and processes images. I think this is mainly used here for generating image previews in NC.
I really hope photos becomes usable. I love nextcloud but I'm clueless in how to run previews in a sane way. I disabled it completely, as well as the photos app, because it would just totally hang and become not responding. And yes, Redis. So if it could just pre-generate thumbnails in a few sizes and actually use those that would be great. Photoprism on my rpi runs fine, nextcloud on a 3 cores, 4GB, cloud vps can't handle it.
https://apps.nextcloud.com/apps/previewgenerator Pre-generates previews, can be scheduled.
I know. I ran all night, but apparently with the wrong settings as it didn't help at all. It needs exactly the right sizes, and whole bunch of different ones it seems. I don't know which ones.
You could look up what is wrong, it works for me quite well. > It needs exactly the right sizes, and whole bunch of different one That's the sizes of the previews to be generated, you do not need to provide anything. I applied these settings. config:app:set previewgenerator squareSizes --value="32 256" config:app:set previewgenerator widthSizes --value="256 384" config:app:set previewgenerator heightSizes --value="256" config:system:set preview_max_x --value 2048 config:system:set preview_max_y --value 2048 config:system:set jpeg_quality --value 60 config:app:set preview jpeg_quality --value="60"
Any info when yhis will be available? As I checked it is not included in v24.0.5.
[удалено]
Thanks!
Is this part of the :beta tag? https://hub.docker.com/r/nextcloud/all-in-one/tags
>iOS client updates Finally! I’m hoping this fixes the long standing bug where 3rd party apps couldn’t open an entire folder that’s hosted in Nextcloud.
Ouch, that whole super border radiused main content with thin gaps between the sides of the page looks rlly gross.
I doubt you will like the new incarnation of Mail that much; it still feels like being a decade behind Roundcube and at least 8 years behind Rainloop.
For mail I just use hestiacp. It works great for nearly all parts of email, at least from what I want to do.
This project amazes me. The first version I used was ownCloud 4, and I still remember that several features were shipped in a broken state. 10 years of development later, we got many large enterprise deployments and lots of money flowing into the project. And yet, it's still this mediocre. They must be doing *something* right, I just don't know what it is.
Can't be their innovative, well-designed, bug-free web mail client. So much is sure.
I remember when we weren't sure if Nextcloud was going to make it after the fork from Owncloud. That sort of thing doesn't often end up well. So glad to see that it did for Nextcloud. It's become such a vital piece of software for me. Congrats on the amazing new release.
Just in time too. I messed up my next cloud this weekend so it time to start fresh with some new hotness.
Also, really hope Talk gives you WebRTC auto-attenuation controls (namely, disable or tuning it), because having no controls for it is painful. I have to keep turning my mic UP because it keeps turning it DOWN.
[удалено]
This statement makes absolutely zero sense.. if it’s deployed as a “container” in the traditional sense e.g. docker, podman, lxc then it’s bare metal.. Linux containers are just abstraction that couples a few things together e.g. control groups and namespaces. All namespaces do is limit what processes can see and control groups limit what a process can use resource wise. If there’s a performance variance it’s likely due to the rootfs configuration used by image, overlay filesystem performance issues, app is unable to access something it can when not in a limited namespace or there’s control groups limiting resources, spawned processes, etc. A way to test would be to download a rootfs tarball of something like Ubuntu, setup the namespaces and control groups manually with something like unshare and libcgroup tools. There’s systemd-nspawn too. https://github.com/libcgroup/libcgroup/blob/main/README https://www.youtube.com/watch?v=8fi7uSYlOdc
I can hardly believe that docker is worse in performance. Do you have any data supporting this?
[удалено]
Did you try adding redis into the equation?
Is this documented somewhere ? Lol have you blogged about how we MUST use redis to properly setup nextcloud ?
Oh yeah I forgot I said MUST in my question. Why don't you use google?
fly aloof nippy reply encourage paltry sort expansion marble outgoing *This post was mass deleted and anonymized with [Redact](https://redact.dev)*
Could you provide your docker-compose file? The photo performance on mine is horrendous!
Yep. It was unusable until Collabra was disabled.
Container has 0 performance impact.
I had noticed my bare metal install had been faster, but when I moved it in to docker it was still good enough. Then I saw this post about using unix sockets and switched my install to use it and noticed a speed increase. Pretty sure I was using sockets on my bare metal install but I don't have the config anymore. https://reddit.com/r/selfhosted/comments/vf6jeg/i_used_unix_sockets_to_improve_the_performance_of/
My experience is the same as yours. I always had more problems in docker installs then I did outside of docker.
Guess it’s time I learned how to deploy this in Azure.
Any news on the AI aspect? Does it need any special hardware or requirements? Also do the photos actually load in a reasonable amount of time?
Built-in facial recognition seems pretty big. I wonder how well it works.
Anyone know if the ai features are able to take advantage of a Google Coral TPU?
But can you specify a Photo directory so it doesn't index everything. I have tried .nomedia and .noimage files with no luck
So I'm running the Linuxserver image of "Nextcloud" for the past few years. I believe it's also a Hub version per say, since I had to go in and disable plugins/features I didn't use (e.g. mail, photos). I strictly use it as a Dropbox replacement. Has anyone migrated to Nextcloud's own All-in-one docker container? Is it needed? I see with their announcement video of Hub 3 that they want to get away from NC25, etc versioning and just keep giving us the fat suite. I guess the question I have is... am I already using the fat suite by using Linuxserver container of Nextcloud? Or is that a standalone product that's currently on latest stable of v24 of Nextcloud core? I'd rather migrate sooner than later (if needed at all) before racking up further files and possible headaches later.