• 0 Posts
  • 190 Comments
Joined 1 year ago
cake
Cake day: June 22nd, 2023

help-circle


  • 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.


  • rentar42@kbin.socialtoSelfhosted@lemmy.worldDocker or podman?
    link
    fedilink
    arrow-up
    8
    arrow-down
    1
    ·
    edit-2
    6 months ago

    I personally prefer podman, due to its rootless mode being “more default” than in docker (rootless docker works, but it’s basically an afterthought).

    That being said: there’s just so many tutorials, tools and other resources that assume docker by default that starting with docker is definitely the less cumbersome approach. It’s not that podman is signficantly harder or has many big differences, but all the tutorials are basically written with docker as the first target in mind.

    In my homelab the progression was docker -> rootless docker -> podman and the last step isn’t fully done yet, so I’m currently running a mix of rootless docker and podman.






  • 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.