ShittyKopper [they/them]

  • 4 Posts
  • 94 Comments
Joined 1 year ago
cake
Cake day: June 9th, 2023

help-circle

  • while i don’t have any specific opinions about this that other people haven’t addressed, i just want to flag up something;

    How this could be enforced? No voting from the All and/or Local feed. Seems easy and straight forward.

    this seems unenforcable. as in, you can’t really tell where someone discovered a post from. yeah you can just remove the buttons from those views clientside and it’ll probably work for the majority of cases, but alternate clients or modifications to lemmy-ui can simply put the buttons back in (or in cases of unmaintained or differently opinionated clients, just not remove the buttons at all). the backend can’t really differentiate which view a vote comes from. federation especially can’t differentiate which view a vote comes from.







  • (talking about microblog fedi here, Lemmy/threadiverse is it’s own thing)

    don’t do hashtags. hashtags (especially common ones like #memes) are overrun by repost bots and low quality garbage.

    the trick is to be on a small-to-medium instance you vibe with (1k active users seems to be the sweet spot. anything larger than 2k I’d avoid. do NOT join any flagship instances like mastodon.social), follow fun people from your local timeline, and see who they boost. and follow up the boost chain until your timeline is sufficiently fun.



  • I’m not entirely sure if such an instance exists, but just letting you know that in case you can’t find any, a reasonable compromise would be to join an instance that’s enforcing authorized fetch (and is blocking threads)

    this will make it harder for facebook to read your data through federation alone (i.e. even if a post of yours get boosted by someone with followers from threads, it won’t “leak” there)

    there are ways to bypass this of course but if facebook is found to do something of that sort they would out themselves as actively malicious which would definitely get a reaction even from the “wait and see” crew







  • TLDR of linked gist: wayland is not X therefore it is bad. end of.

    Wayland breaks Xclip: As you said it yourself, Xclip is an X11 application, so it doesn’t work on Wayland. Of course it wouldn’t work on Wayland. With Wayland, we’re trying to prevent what happened with Xorg from happening again, or am I wrong?

    also, https://github.com/bugaevc/wl-clipboard. perhaps all OP (of gist) needs is a simple shim that can convert calls to xclip to wl-copy/paste? that doesn’t seem too hard to make compared to keeping X.org alive I’d say (perhaps they should try making it if it’s that much of a problem)

    Wayland breaks screensavers: Yeah, that seems to be the case.

    from the dev of xscreensaver at https://www.jwz.org/blog/2023/09/wayland-and-screen-savers/ :

    […] Adding screen savers to Wayland is not simply a matter of “port the XScreenSaver daemon”, because under the Wayland model, screen blanking and locking should not be a third-party user-space app; much of the logic must be embedded into the display manager itself. This is a good thing! It is a better model than what we have under X11. […]

    […] Under X11, you run XScreenSaver, which is a user-space program that tries really hard to keep the screen locked and never crash. It is very good at this, but that it needs to try so hard in the first place is a fundamental design flaw of X11. […]

    other people can comment on the parts they know about, these are two i know of off the top of my head





  • One of the reasons I use containers instead of installing things directly is that i can completely uninstall a service by deleting a single directory (that contains a compose.yml and any necessary volumes) and running a docker/podman system prune -a

    or that i can back up everything by backing up a single “containers” dir, which i could have on a subvolume and snapshot if i wanted to

    systemd/quadlet on the other hand makes me throw files in /etc (which is where you’re supposed to put them, but ends up resulting in them being tangled together with base system configuration often partially managed by the package manager)

    The Solution™ to this is configuration management like ansible or whatnot, which needlessly overcomplicates things for the use cases i need (though they’re still useful for getting a base system “container ready” wrt ssh hardening and such)

    tldr: i want my base system to be separated from my services, and systemd integration is the exact wrong tool for this job


  • In Logseq, everything is a nested list. This feels like a limitation, but I’ve been preferring it. The decision is made for you: you’re going to jot this information down as a list. So then you just start writing it.

    Oh - this sounds interesting.

    Whenever I needed to jot down any notes I’ve been finding myself just writing plain .txt files with bullet points, and trying tools like Obsidian or TiddlyWiki I always ended up being overwhelmed with the amount of stuff I could do (and with all the customization options) that I never got around to actually writing things down. I’m definitely gonna look into how Logseq works.

    (Although I have to say, their website does look a bit “too hype-y” for my liking. IDK how to explain it, just a gut feeling. Still, at least it’s FOSS so it can’t be too bad)