After my private Gmail was leaked somewhere, I’ve started to receive an enormous amount of spam that came through into my inbox, which made me switch to Proton and a self-hosted SimpleLogin setup.

So I decided, I might as well dirch Google entirely, for private and work-related stuff.

While Proton already covers Mail and Calendar, I’m in search of alternatives for the following services to replace.

  • Meet: I like the idea of starting a quick meeting by simply sending a link to a customer, who can join instantly. What would be an equivalent software to do that? I tried Mattermost, but it seems more like a Slack alternative, with invites, etc. and is overkill for my case. Revolt chat looks like a Discord alternative.
  • Drive: In short, If possible, I’d prefer one consolidated place to access and edit files. Docs, Excel, PDFs, pictures, videos, etc… Is Nextcloud really the only option here, with the corresponding plugins for onlyoffice and memories (photos)? I tried running thst on an intel nuc, and it’s slow as hell.
  • adONis@lemmy.worldOP
    link
    fedilink
    English
    arrow-up
    6
    arrow-down
    3
    ·
    1 year ago

    Yeah… NC is really bad. I like the idea of the project, but the stack they chose to write it in, PHP, is just not suitable for such tasks

    • fluckx@lemmy.world
      link
      fedilink
      English
      arrow-up
      8
      ·
      1 year ago

      I think nextcloud suffers more from carrying along legacy code rather than blaming it on php. There’s tons of stuff written in php that performs well.

      It’s definitely not the right tool for every job, but it’s also not the wrong tool for every job. Which goes for most programming languages. I’ve seen it work fine on high traffic environments. It also carries a legacy reputation from php 5 and before. I haven’t kept up with it much in the last few years though.

      Which nextcloud tasks do you think php is unsuited for? (Genuine question)

      • adONis@lemmy.worldOP
        link
        fedilink
        English
        arrow-up
        4
        ·
        1 year ago

        I mentioned it in another topic regarding kbin, which is also written in PHP.

        If you run a node/go/rust server and you hit the endpoint /hello which returns a simple “hello world”, they will just return that. PHP however, has to initialize and execute the whole framework stuff, before returning a simple “hello world”.

        So there’s definitely some overhead, which to some degree can be limited by using caching like redis, etc.

        • fluckx@lemmy.world
          link
          fedilink
          English
          arrow-up
          2
          ·
          1 year ago

          I can follow that. I think most applications that keep running ( like a go webserver) are more likely to cache certain information in memory, while in PHP you’re more inclined to have a linear approach to the development. As in “this is all the things i need to bootstrap, fetch and get and run before I can answer the query”.

          As a result the fetching of certain information wouldn’t be cached by default and over time that might start adding up. The base overhead of the framework should be minimal.

          You ( nextcloud ) are also subject to whoever is writing plugins. Is nextcloud slow because it is slow, or because the 20 plugins people install aren’t doing any caching and a single page load is running 50 queries? This would be unrelated to NC, but I have no idea if there’s any plugin validation done.

          Then again, I could be talking completely out of my ass. I haven’t done much with NC except install it on my RPI4 and be a bit discontent with its performance. At the same time the browser experience on the RPI was also a bit disappointing so I never went in depth as to why it wasn’t performing very well. I assumed it was too heavy for the PI. This was 4 years ago mind you.

          My main experience with frameworks like Laravel and symfony is that they’re pretty low overhead. But the overhead is there ( even if it is only 40ms ).

          The main framework overhead would be negligible, but if you’re dynamically building the menu on every request using db queries it’ll quickly not become negligible