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

help-circle
  • surfrock66@lemmy.worldtoLinux@lemmy.mlTop 5 Features Coming to GIMP 3.0
    link
    fedilink
    English
    arrow-up
    122
    arrow-down
    5
    ·
    7 days ago

    I’m super happy and excited for GIMP 3.0. I hate that this info was presented in a youtube video. I can gleam what I want to know from an article with bullet points (which I could find) but I’m sick of half the information I search for being returned in a video, with a fixed time commitment and imprecise “scrolling” to skip. I feel like in search and link aggregators, more and more content is video instead of text and I’m not here for it.


  • Lego parts are incredibly precise, and the manufacturing tolerances have been consistent for decades. It’s nearly impossible to replicate that precision on any modern printers.

    That being said, different parts are more tolerant of wiggle room. Grabbing a stud is hard, grabbing a 2x4 is not. If you were going to print a minifig head, trying to replicate the neck barrel is gonna be tough, but making a larger hole with 2-3 ridges which taper to grip might be easier. If you plan what you’re doing and are realistic about what you can print, it’s definitely not out of the question.

    Lego is ABS if I’m correct.
















  • I have never seen those questions answered because it’s a secret sauce that the streaming platforms would patch immediately if it were published. In general though, my understanding is it’s older versions of apk’s on rooted android devices with exploits that allow for harvesting the actual cached files, or in some cases the apk is deconstructed to get access to the API keys so that the files are downloaded directly, though that’s risky as it gets easier to detect a single key doing a giant pull of files faster than someone could reasonably watch the shows.






  • I’m not an expert, but I’ve been using TrueNas Scale since I cut over from TrueNAS core, and before that Freenas, since about 2010. I have a bunch of lessons and assumptions, but someone can correct me if these are misguided, they’re my tl;dr of knowledge.

    1. Your data drives should be in sets of 3 for a raidz1, or 5+ (I use 6) for a raidz2. While technically the minimum is 2 or 4 respectively, best performance and protection comes in sets of 3. This is a good synopses: https://superuser.com/a/1058545 In that case he points out that a 3-way mirror also works but then you lose a lot of the data integrity checking that comes with ZFS. I keep an offline spare; in your situation putting 3 drives in with a RAIDZ1 and keeping one in the drawer would give you ~8TB of capacity protected against bit flipping and drive failure. This is a better description of the raid levels: https://calomel.org/zfs_raid_speed_capacity.html
    2. In terms of just storage, that system will be fine, though ideally you get ECC RAM; that’s often a bigger swap, so if you can’t change that, so be it. It does matter in terms of integrity checking. The more containers you run, the tougher it gets to spec out. I have a separate proxmox hypervisor and routinely have 4+ jellyfin streams going at a time, so it wouldn’t be enough in my case, but you’ll have to experiment and scale. I will say, even though a separate proxmox box comes with a lot of headaches, it was more important than any schooling I ever did in terms of my IT career. Networking, monitoring, access control, suddenly I have a solution to every IT problem I encounter and I have experience with it.
    3. Personally, I do a 2-disk mirror for the OS, and then multiple 3 or 6 disk vdevs for data. If you lose the OS drive and it’s just 1, that’s fine if you have backups to just restore, but I find swapping in a cheap ssd is better. I use cheap-as-dirt 64G SSD’s as the boot drives, and if one dies, you can swap it and replace it in the UI, no problem. You can technically use 2 mis-matched sized disks, but it’ll fuss at you.
    4. Start with TrueNAS Scale as just a storage device; ideally that needs to be close to the hardware and not virtualized. In the beginning, especially since you’re likely dealing with 1 pool, just make 1 vdev for everything. You can make folders in there, or datasets, and play with partitioning data, sharing data to other computers, etc. I use NFS sharing AND iscsi luns to my proxmox, and ultimately I’m in 1 big dataset with multiple vdevs in it. Add your things like homeassistant one at a time; going through it will show you how you sort storage, how you provision it, etc. Over time, things grow; this will not be your final configuration, most people expand over time. You may decide “I want bulk storage in one vdev, I want containers and vm’s in another.” When you expand, that’s when you split things off and make more nuanced decisions. That will come from better assessing your needs.

    You mention Jellyfin…my struggles with that were never storage. My struggles there were networking; it was a big part of why I decided to upgrade my server networking to 10G, which supported running Jellyfin on another hypervisor and having all that go over the network.