• 0 Posts
  • 257 Comments
Joined 1 年前
cake
Cake day: 2023年6月22日

help-circle


  • Now you make me feel old. In “the olden days” before streaming of media over the internet was as commonplace as it was now, that was the standard way that tech-savy people consumed media: Either on their PC or with some set-top box with built-in storage. I fondly remember my PopcornHour, which was basically a line of desktop-boxes that ranged from “basically a hard disk, video decoder and HDMI out” all the way to “can automatically rip your BlueRays”.




  • https://lemmy.world/post/12995686 was a recent question and most of the answers will basically be duplicates of that.

    One slight addition I want to add: “Docker” is just one implementation of “OCI containers”. It’s the one that broke through initially in the hype, but you can just as easily use any other (podman being a popular one) and basically all of the benefits that people ascribe to “docker” can be applied to.

    So you might (as I do) have some dislike for docker (the product) and still enjoy running containers.








  • Was about to post this, this works well for me.

    In my case I’m storing the DB on my Google Drive for now, but Keepass2Android supports many different systems, including “generic” things like WebDAV, so really anything should work.

    While Keepass2Android is integrated with the syncing and will always check for conflicts (i.e. check for latest version before saving), the same isn’t necessarily true for the desktop client. But since I rarely edit from both devices at the same time, anything that syncs to the Desktop in a somewhat realtime fashion should work just fine.

    And for the few (long ago) cases where updates were overwritten, the “previous version” feature of Google Drive was god-sent! (And KeepassX can simply merge the old overwritten version into the current one and you’ll get the correct merge).


  • I think the difference is at what level:

    • don’t implement your own storage redundancy system at the kernel level with a small team in a closed-source fashion, because that’s the kind of thing that needs many eyes, lots of experience and many millions of hours real-world usage to fully debug and make sure it work.
    • do build your own system by combining pre-existing technologies that are built by experienced teams and tested/vetted by wide/popular usage.

    I feel OPs critique has some truth to it. I personally would rather stay with raidz by zfs, exactly because of it’s open nature (yes, they too have bugs, nothing is perfect).




  • Do you have any devices on your local network where the firmware hasn’t been updated in the last 12 month? The answer to that is surprisingly frequently yes, because “smart device” companies are laughably bad about device security. My intercom runs some ancient Linux kernel, my frigging washing machine could be connected to WiFi and the box that controls my roller shutters hasn’t gotten an update sind 2018.

    Not everyone has those and one could isolate those in VLANs and use other measures, but in this day and age “my local home network is 100% secure” is far from a safe assumption.

    Heck, even your router might be vulnerable…

    Adding HTTPS is just another layer in your defense in depth. How many layers you are willing to put up with is up to you, but it’s definitely not overkill.


  • They are in fact the same image, as you can verify by comparing their digest:

    $ docker pull ghcr.io/linuxserver/plex
    Using default tag: latest
    latest: Pulling from linuxserver/plex
    Digest: sha256:476c057d677ff239d6b0b5c8e7efb2d572a705f69f9860bbe4221d5bbfdf2144
    Status: Image is up to date for ghcr.io/linuxserver/plex:latest
    ghcr.io/linuxserver/plex:latest
    $ docker pull lscr.io/linuxserver/plex
    Using default tag: latest
    latest: Pulling from linuxserver/plex
    Digest: sha256:476c057d677ff239d6b0b5c8e7efb2d572a705f69f9860bbe4221d5bbfdf2144
    Status: Image is up to date for lscr.io/linuxserver/plex:latest
    lscr.io/linuxserver/plex:latest
    $
    
    

    See how both images have the digest sha256:476c057d677ff239d6b0b5c8e7efb2d572a705f69f9860bbe4221d5bbfdf2144. Since the digest uniquely identifies the exact content/image, that guarantees that those images are in fact byte-for-byte identical.