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
    1
    ·
    1 year ago

    And what I forgot to mention, there’s the fact that it’s not async. So it adds up even more to the delay when fetching stuff.

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

      There are libraries which allow you to do stuff async in PHP ( https://github.com/amphp/amp ). It’s not all async by default like Javascript. A lot of common corporate languages right now are synchronous rather than asynchronous like python, java, c#, … By default, but allow you to run asynchronous code.

      It all has their place. I’m not saying making it async won’t improve some of the issues. Running a program that does 15 async processes might cause some issues on smaller systems like RPIs that don’t have a lot or compute capacity like a laptop/desktop with 20 cores.

      Having said that. I can’t back that up at all :D.

      Thanks for your insights though. I appreciate the civil discussion :)

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

        but also, most of these languages run a compiled executable, while PHP has to go through a parser. java is another exception with it’s vm, but you get my point.

        so, all in all… PHP has overhead, in many ways … sure it might be negligible (gosh, I always have to look up the spelling of this word) in some situation, but in other it adds up so much that it makes it unsuitable for the task.

        yeah, I like these type of convos where there’s no right or wrong… just "yes, but…"s

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

          I mean. There’s plenty of languages that have this overhead.

          A base Laravel or symfony installation shows a landing page in 30-50ms (probably).

          I’ve written ( in a lightweight framework rather that no longer exists ) a program to encrypt/decrypt strings using XML messages over http requests.

          The whole call took 40-60ms. About 40-50% of that was the serializer that needed to be loaded. The thing was processing a few hundred request per minute in peak. Which is a lot more than the average nextcloud installation. The server wasn’t really budging ( and wasn’t exactly a beast either ).

          I’m definitely not refuting that the JIT compiler adds overhead. But as in my example above, it’s also not like it’s adding 100ms or more per request.

          If you have a very high performance app to the point where you’re thinking about different transport than HTTP because of throughput you’re likely better off using something else.

          Circling back to the original argument my feeling remains that the same codebase in GO or RUST wouldn’t necessarily perform a lot better if you just calculate in php speed and the overhead of the JIT compiler.

          If you’d optimize it in rust/go. It likely will be faster. But I feel like the codebase could use some love/refactoring. But doing that is more difficult when you already have:

          • a large user base on various hardware
          • a large Plugin community which will need to refactor all their plugins
          • need some compatibility with all the stuff that is already there ( files, databases, migrations)

          You don’t want to piss off your entire userbase. Now I feel like I’d like to try it myself and look at the source though :'). ( I’m not saying I can do better though. It’s been a couple of years).