Roundcube is on a whole other level in terms of stability and robustness compared to Nextcloud.
I'm also glad that the current Nextcloud client will be replaced, because it's not very good right now.
no company in the world is going to maintain 2 separate software products that compete with each other. They will be merged, my prediction is 12 to 18 mos
OT: please (re)read the HN Guidelines. https://news.ycombinator.com/newsguidelines.html
You said "i'm happy running it on my ...vps."
And now "Then I wouldn't use Roundcube either." So you're not running roundcube then?
Also, love how you said you loved roundcube because it works on "lightweight el cheapo VPS", and then backtracked once you found out it uses PHP.
Both start with coll/cooll, I've got to increase my zoom apparently.
7.0 had some issues so bad it's almost impossible to find anymore. Seems like they tried to erase it from the internet. The language itself is an attack vector.
"Neither will Roundcube replace Nextcloud Mail or the other way around. ... Nextcloud Mail will evolve as it is, focused on being used naturally within Nextcloud."
We just swapped out our old webmail system (made from twigs, mud and spit) for a nice and elegant Roundcube install with custom plugins and I was already dreading having to change it.
Some bugs I encountered in a few hours of testing and trying to make it work.
The Mac auto-update installs an incompatible version to my OS; the website offers only the new incompatible and an old version that also doesn’t work (OS can not scan the app). The solution is to find a suitable version from a hidden FTP, user-unfriendly.
Some files had modification timestamps on 1.1.1970 that causes obscure sync issues on Mac. Either run some arbitrary database scripts to fix this or a simpler solution is to ‘touch’ all affected files.
The Windows Client consistently shows random minus bytes, hangs, and freezes.
The Windows Client is stuck in a loop of calculations and transmissions. Also a reinstallation is impossible as AppData folder isn’t deleted during uninstallation.
A successful complete reinstall downloads all the existing files individually, creating conflicts with identical(!?) local and server files. Why is the file hash not checked before the download? It’s frustrating and seems poorly designed.
All bugs have open GitHub issues I didn’t bother to include. Some have open PRs for years. The last bug is open for 5 years now.
I was able to recover a 13 year old photo I took with a D70s which was extremely noisy. By using what I learnt and state of the art software (which is Darktable), I was able to extract a very nice photo out of it.
Also, as your style improves and experience piles up, you look to your "bad" photos and say "Aha, there's a nice angle here. Let's process this".
You can see some of my "Remastered" photos at [0].
[0]: https://www.flickr.com/photos/zerocoder/albums/7215770242956...
https://www.dxo.com/fr/technology/deepprime/
I have a license for some older version, if you want to throw a .nef at me
Contributors send in calibrated RAW files per camera, taken at every ISO setting possible, so Darktable denoises your file according to your camera's profile at particular ISO. The result is pretty impressive.
I have uploaded that particular image to [0]. Taken in 2006 and processed in 2020, after 14 years!
[0]: https://www.flickr.com/photos/zerocoder/53363865806/in/datep...
Edit: EXIF says 2005, but it should be 2006.
Almost after every shoot, people come back "remember that one photo, where I smiled at sth? I'm very sentimental about that, cause it's [some important thing to them]", which necessitates the need to hold on to every photo taken on the session. So no real deletes here, even if it came out technically wrong (blurry, blown out, etc.).
Those requests lessen, but don't die down completely. Especially with cyclic events, organizers have this habit of a asking for things done exactly year ago.
Some just say: "hey, I remember you taking a photo of me then and then" for their dancing portfolio in my case.
Especially for videos, which can be a constant flow of editing requests, for supercuts and etc.
Now, if I were really smart, I'd just have some good way to archive after two years, and delete after - let's say three years. In practice though, there are so many unforseen circumstances that a habit of "never delete anything" forms really easily.
It's just a lot easier and cheaper to buy another drive instead of culling 10k of photos every once in a while, especially if external confirmation is involved.
[0] https://aws.amazon.com/s3/glacier/pricing/#Retrieval_request... <- under "Bulk"
I guess I could reinterpret your original comment as "Have fun paying a fortune if you need to get those files [out of AWS] again."
instead of my original interpretation "Have fun paying a fortune if you need to get those files [out of Glacier] again."
Agree!
Despite constantly crowing at researchers in my past life that they will lose all their data ... it only happened once or twice, and both times was related to theft and not drive failure.
I wonder if you could sell a type of "archive protection plan" as an add-on to your work. It's like $70 a year to store 500GB on Glacier. I am sort of assuming each shoot is 500GB? You could guarantee access for those customers who want it.
If we're being honest with each other, I would do the exact thing you're doing and focus more on my business. :)
Linux has davfs2, android has foldersync.
Apache2 is super streamlined for this, and has done dav stuff for at least 16 years.
And apache2 is a very well established implementation of it.
Clients handle partial snags.
I wouldn't rely upon anything that syncs like this, without backups. Any protocol at all.
Of course, the same may be said for anything at all. Backups are king.
That's pretty cool.
The only thing I'd really want for Syncthing is some kind of simple interface for my desktops (all running SwayWM.) There's a GTK app that I use on my Pinephone, but it's a little janky. I mainly just want to be able to know that I'll get notifications when there's a conflict or error. (Dropbox style file emblems in file explorers, showing the state, would be nice, too...)
My wife and I had such a setup for years with Resilio Sync. But life is busy enough to maintain yet another thing, so we are happy to fork over the monthly fee for Dropbox Family.
Ideally I'd switch over to some other sync solution, because Dropbox is somewhat overpriced. But we've had bad experiences with Google Drive and OneDrive for local sync in the past.
But that's the thing. Especially notable compared to NextCloud, Syncthing is not like most "self-hosted" software. Because a node is a node is a node, and because it's relatively lightweight, it literally doesn't matter what you use. You can use a Raspberry Pi, an old phone or laptop, anything you can connect sufficient disk and a network to can be a Syncthing node. And if it catches on fire, it doesn't really matter since every node is equal. You can just add another node at any time.
So a lot of people think Syncthing is another thing you'll have to worry about and maintain, but it's not. It's one of the few pieces of software that I expected to have to deal with a lot of extra work to use, but then it wound up being dramatically easier and more flexible than I expected. I worry about robustness when it comes to something as complex as cross filesystem syncing, but Syncthing has never lost my data. I have backups turned on on most nodes for the important folders, but I've never consulted them before, because I've never needed to.
Surely it is possible to lose data with Syncthing, or otherwise create a headache. However, from my point of view, it certainly seems to be among the most reliable and lowest effort ways to sync stuff across devices. I haven't had to spend almost any time maintaining Syncthing, and I don't have to worry about limits. I just need one device with a big enough disk, then I can create however many shared folders are needed to get the granularity I want.
Syncthing also has a pretty cool encryption feature. It is considered "beta" still, so I only use it in "trusted" scenarios, but it works great.
When I started using Syncthing, I only intended to share some document files between my desktop and my laptop. Now I use it to sync my Keepass database, files between some servers (think seedbox etc.,) multiple different documents folders including some for collaborative projects, and even a couple of other things. So it really wound up over-delivering for me.
I'd strongly recommend people, even people who already feel like Resilio Sync wasn't a good fit, to just try to set up Syncthing before resigning to Dropbox. Comparatively, I think Syncthing is simpler to use and more robust than basically any other solution that isn't Dropbox.
It works well enough in a backup system, where the issue explained on the page isn't relevant.
I'm saying that you can disregard the warning in the case of a backup system (as opposed to the normal use which is full sync between two devices that both modify files).
I have been using Maestral for Dropbox sync on Mac for years now and it works great. The primary downside is that it doesn't have block-level sync because it's not supported by the API. The flip side is that you don't get the memory-hungry Dropbox app that embeds a web engine for some unfathomable reason.
I wish that Dropbox would bring back their old client that just did sync and not all the crap that I don't need.
Just a month ago there was news of a RoundCube XSS zero-day that was widely exploited (https://cyberpedia.medium.com/state-sponsored-cyberattacks-l...).
Don’t use RoundCube!
All software has vulnerabilities. The trick is to install it in a way which mitigates most of the typical ones: use VMs, SELINUX/APPARMOR, containers, chroots, user separations, etc.
It's more of "outsource to someone else" than "who won't fuck it up".
Everything you mentioned is about protecting things the app should not have access to. Many vulnerabilities are about intent (did the admin user really mean to truncate the db they have permission to truncate) or target (did the user really mean to export all my emails in an archive to h4x0r@yahoo.com).
If you at all store any sensitive data within the application either serverside or clientside you need to consider the security of the application itself, not just the sandboxing/isolation.
Edit: Yep that's the official position as per this post on the roundcube github https://github.com/roundcube/roundcubemail/issues/6030#issue...