After a year online the free speech-focused instance ‘Burggit’ is shutting down. Among other motivations, the admins point to grievances with the Lemmy software as one of the main reasons for shutting down the instance. In a first post asking about migrating to Sharkey, one of the admins states:

This Lemmy instance is much harder to maintain due to the fact that I can’t tell what images get uploaded here, which means anyone can use this as a free image host for illegal shit, and the fact that there’s no user list that I can easily see. Moderation tools are nonexistent on here. It also eats up storage like crazy due to the fact that it rapidly caches images from scraped URLs and the few remaining instances that we still federate with. The software is downright frustrating to work with, and It feels less rewarding overall putting effort into this instance because it feels like we’re so isolated.

A few weeks later, in the post announcing that Burggit was shutting down, another admin says the same:

The amount of hoops that burger has to go to in order to bring you this site is ridiculous. To give you an idea of how bad this software is, there’s no easy way to check all the images uploaded to the site (such as through private messages). When the obvious concern of potential illegal imagery is brought up to lemmy devs, they shrug and say to plug in an expensive AI image checker to scan for illegal imagery. That response genuinely has me thinking that this is by design, and they want it to be like this. We can’t even easily look at the list of registered users without looking through the DB, absolute insanity.

The other thing is there’s no real way to manage storage properly in Lemmy, the storage caches every image ever uploaded to any instance forever.

Also the software is constantly breaking.

They also say that Kbin has many of the same problems, so I’m just curious to know if the admins of bigger Lemmy & Kbin instances feel the same way about these software.

  • nutomic@lemmy.ml
    link
    fedilink
    English
    arrow-up
    11
    arrow-down
    1
    ·
    9 days ago

    It would be interesting to investigate why Lemmy has high CPU usage. In principle it should be quite efficient as its written in Rust. Its also not doing anything particularly performance intensive, unless you are subscribed to lots of communities or have lots of users.

    • poVoq@slrpnk.net
      link
      fedilink
      English
      arrow-up
      7
      ·
      8 days ago

      Here it isn’t so heavy on CPU, but the database eats RAM like crazy. My guess would be that their server is constantly swapping out stuff from RAM due to insufficient surplus RAM and this as a result creates the high CPU load.

    • haui@lemmy.giftedmc.com
      link
      fedilink
      English
      arrow-up
      7
      ·
      9 days ago

      From other comments I read, the database seems to be the issue, not lemmy. Is uses postgres and that uses the resources. Lemmy itself is no problem.

      • nutomic@lemmy.ml
        link
        fedilink
        English
        arrow-up
        12
        ·
        9 days ago

        I suppose there is still room for database optimization then, but its hard to find people who know how to do this.

        • haui@lemmy.giftedmc.com
          link
          fedilink
          English
          arrow-up
          6
          ·
          9 days ago

          Hi there! Thanks for taking the time to answer my comment. You folks are doing incredible work and I wanted to say thanks! :)

          Sadly, I‘m not a database expert, otherwise I would help. So donations are the only form I can help with at this point.

    • douglasg14b@lemmy.world
      link
      fedilink
      English
      arrow-up
      2
      ·
      edit-2
      8 days ago

      The language it’s written in has very little, almost nothing, to do with how efficient larger applications are.

      This is almost entirely up to the design and day-to-day decisions of the developers. These almost always outweigh the efficiencies of the underlying languages themselves (within reason).

      A single location of poor data access patterns could negate the aggregate performance gains of your entire application, as an example. A framework that prevents you from making simple mistakes and drives you towards more efficient patterns goes much further than the language is written in.

      Between Rust, C#, Java, and Go you’re essentially even on performance for large applications (with C# pushing ahead of the pack). What you are not even on is engineering efficiency, it’s going to take considerably longer to build the same set of features in rust than any of the others listed. And the performance is likely the same, potentially even worse depending on the maturity of the ecosystem.

      Rust is a great systems design language and a great language to choose when developing high efficiency libraries & frameworks for I/O and data processing. It’s not really a great choice for application development due to how slow it is to actually get things done in.

      I fully expect to see alternate backends written in more operationally efficient languages over the next decade that will catch up to the official Lemmy codebase, and potentially even replace it. It actually sounds like a super fun project, funding is always a problem though.