• 2 Posts
  • 343 Comments
Joined 6 months ago
cake
Cake day: June 9th, 2024

help-circle
  • Install it and use it?

    Their PDS is self hosted, but it does still rely on the central relays (though you COULD host that yourself if you wanted to pay for it, I suppose?).

    It’s very centralized, but it’s not that different from what you’d have to do to make Mastodon useful: a small/single user instance will get zero content, even if you follow a lot of people, without also adding several relays to work around some of the design decisions made by the Mastodon team regarding replies and how federation works for those kind of things, as well as to populate hashtags and searches and such.

    Though really you shouldn’t do any of that, and just use a good platform for discussion, like a forum or a threadiverse platform. (No seriously, absolutely hate “microblog” shit because it’s designed to just be zingers and hot takes and not actual meaningful conversations.)



  • Yeah, it doesn’t appear that PSSR (which I cannot help but pronounce with an added i) is the highest quality upscaling out there, combined with console gamers not having experienced FSR/FSR2/FSR3’s uh, specialness is leading to people being confused why their faster console looks worse.

    Hopefully Sony does something about the less than stellar quality in a PSSR2 or something relatively quickly, or they’re going to burn a lot of goodwill around the whole concept, much like how FSR is pretty much considered pretty trash by PC gamers.











  • two commands: dd and resize2fs, assuming you’re using ext4 and not something more exotic.

    one makes a block-level copy of one device to another like so: dd if=/dev/source-drive of=/dev/destination-drive

    the other is used to resize the filesystem from whatever size it was, to whatever size you tell it (or the whole disk; I’d have to go read a manpage since it’s been a bit)

    the dd is completely safe, but the resize2fs command can break things, but you’d still have the data on the original drive, so you could always start over if it does - i’d unplug the source drive before you start doing any expansion stuff.








  • good ideia to run restic as root

    As a general rule, run absolutely nothing as root unless there’s absolutely no other way to do what you’re trying to do. And, frankly, there’s maybe a dozen things that must be root, at most.

    One of the biggest hardening things you can do for yourself is to always, always run everything as the lowest privilege level you can to accomplish what you need.

    If all your data is owned by a user, run the backup tool as that user.

    If it’s owned by several non-priviliged users, then you want to make sure that the group permissions let you access it.

    As a related note, this also applies to containers and software you’re running: you shouldn’t run docker containers as root unless they specifically MUST have a permission that only root has, and I personally don’t run internet facing ones as the same user as all the others: if something gets popped, then they not only do not have root permissions, but they’re also siloed into their own data in the event of a container escape.

    My expectation is that, at some point, I’ll miss a CVE and get pwnt, so the goal is to reduce how much damage someone can do when that happens, rather than assume I’m going to be able to keep it from happening at all, so everything is focused on ‘once this is compromised, how can i make the compromise useless to the attacker’.