Permanently Deleted

  • degenerate_neutron_matter@fedia.io
    link
    fedilink
    arrow-up
    1
    ·
    2 months ago

    List of blocked words in community names:

    shit
    piss
    fuck
    cunt
    cocksucker
    motherfucker
    tits
    memes
    piracy
    196
    greentext
    usauthoritarianism
    enoughmuskspam
    political_weirdos
    4chan
    

    Seems like one of the PieFed devs has some opinions about the kind of content they dislike, and are unilaterally forcing that on every PieFed instance. I can somewhat understand filtering out curse words, but specific communities should not blocked by default, and definitely not hidden in a hardcoded list in the source code.

    Edit: Important context here: https://lemmy.world/comment/21323475 Seems this blocklist is more limited in scope; it’s not blocking federation entirely, just blocking (from what I can tell) their appearance in search and automatically federating with them when adding an instance. Still problematic to exclude specific communities in a non-configurable way with little justification IMO.

    • Zoot@reddthat.com
      link
      fedilink
      arrow-up
      1
      ·
      2 months ago

      Damn this should honestly be spread and talked about more. I don’t think many people know this is a thing?

      • 4am@lemmy.zip
        link
        fedilink
        arrow-up
        0
        ·
        2 months ago

        Considering PieFed users won’t shut the fuck up about how much better and less politically opinionated it is, yeah we should probably shout this from the rooftops.

        Reminds me of Brave browser users a bit

        • pivot_root@lemmy.world
          link
          fedilink
          arrow-up
          0
          ·
          2 months ago

          One of PyFed’s selling points was that it was easier to work with than Lemmy. It’s going to be amusing when that takes a 180 turn and people start complaining.

          Python is great for prototyping and iterating on small projects or as glue for modules written in C and C++. What it isn’t great at is linearly scaling on a single node. When the day that throwing more powerful hardware at the problem stops being an option, Kubernetes is going to walk through that door and fuck any semblance of simplicity up.

          • mushroomman_toad@lemmy.dbzer0.com
            link
            fedilink
            arrow-up
            1
            ·
            2 months ago

            I think Lemmy has some in-memory data structures that limit the backend to a single node, too. Also postgres is great, but Lemmy really fucked up their database performance somehow.

            But yeah large python codebases turn into spaghetti really quickly.

            • orca@orcas.enjoying.yachts
              link
              fedilink
              arrow-up
              1
              ·
              2 months ago

              but Lemmy really fucked up their database performance somehow.

              Can confirm. I spent like 4 hours one day configuring auto vacuum and other shit on my Lemmy DB because it was bloating to hell and eating up resources. Runs much smoother now but it was a massive PITA to get there.

                • orca@orcas.enjoying.yachts
                  link
                  fedilink
                  arrow-up
                  2
                  ·
                  edit-2
                  4 days ago

                  I can’t remember exactly what I did but enabling autovacuum was one of the big ones. I’ll try to provide some info below:

                  Walks through VACUUM and autovacuum - https://oneuptime.com/blog/post/2026-01-25-use-vacuum-analyze-postgresql/view

                  How to see if autovacuum is already enabled (these are commands you’d run while in sql):

                  SHOW autovacuum;

                  View current settings:

                  SELECT name, setting FROM pg_settings WHERE name LIKE '%autovacuum%';

                  Monitor which tables need attention:

                  SELECT schemaname, relname, n_dead_tup, n_live_tup 
                  FROM pg_stat_user_tables 
                  WHERE n_dead_tup > 1000 
                  ORDER BY n_dead_tup DESC;
                  

                  I wish I had documented it at the time because info about this for Lemmy specifically is pretty lacking. I was in kind of a dire situation though because my disk space had filled up quickly and my system was struggling. A lot of what I did was basic PostgreSQL maintenance stuff, so you should be able to find some general guides for that.

                  EDIT: I had Claude help me corral some optimization stuff into a PDF. This is along the lines of what I did to get my db back under control. Make sure to always backup first! https://u.orca.casa/1771250081