fishpen0

@fishpen0@lemmy.world

• ⁨Comment⁩ on ⁨What is Docker?⁩ ⁨⁨10⁩ ⁨hours⁩ ago⁩:

  This is why I said “most containers most of the time should”. It’s a bad practice to write to the inside of the container and a better practice to treat them as immutable. You can go as far as actively preventing them from writing to themselves when you build them or in certain container runtimes, but this is not usually how they work by default.

  Also a container that is stopped and restarted will not lose its internal changes in most runtimes. The container needs to be deleted and recreated from the image to do that

• ⁨Comment⁩ on ⁨What is Docker?⁩ ⁨⁨20⁩ ⁨hours⁩ ago⁩:

  Yes, technically chroot and jails are wrappers around kernel namespaces / cgroups and so is docker.

  But containers were born in a post chroot era as an attempt at making the same functionality much more user friendly and focused more on bundling cgroups and namespaces into a single superset, where chroot on its own is only namespaces. This is super visible in early docker where you could not individually dial those settings. It’s still a useful way to explain containers in general in the sense that comparing two similar things helps you define both of them.

  Also cgroups have evolved alongside containers at this point and work rather differently now compared to 18 years ago when cgroups were invented and this differentiation mattered more than now. We’re at the point where differentiation between VMs and Containers is getting really hard since both more and more often rely on the same kernel features that were developed in recent years on top of cgroups

• ⁨Comment⁩ on ⁨What is Docker?⁩ ⁨⁨20⁩ ⁨hours⁩ ago⁩:

  A million times this. A major difference between the way most vms are run and most containers are run is:

  VMs write to their own internal disk, containers should be immutable and not be able to write to their internal filesystem

  You can have 100 identical containers running and if you are using your filesystem correctly only one copy of that container image is on your hard drive. You have have two nearly identical containers running and then only a small amount of the second container image (another layer) is wasting disk space

  Similarly containers and VMs use memory and cpu allocations differently and they run with extremely different security and networking scopes, but that requires even more explanation and is less relevant to self hosting unless you are trying to learn this to eventually get a job in it.

• ⁨Comment⁩ on ⁨Annoyed Redditors tanking Google Search results illustrates perils of AI scrapers | "Spreading misinformation suddenly becomes a noble goal," Redditor says.⁩ ⁨⁨5⁩ ⁨months⁩ ago⁩:

  Boaty Mcboatface (2016) is slightly newer in the history of Reddit meming compared to “upvote this picture of foo so it shows up in google for bar”. Those go back as more than 11 years ago to when people were posting swasticas to make Office Depot look bad (2013) followed by the same meme being done to comcast 8 years ago also in 2016 which might be why you thought of boatface.

• ⁨Comment⁩ on ⁨Super hero movies should have more scenes of them accidentally maiming people just because of the sheer amount of power they weild.⁩ ⁨⁨6⁩ ⁨months⁩ ago⁩:

  The first incredibles movie was made before Pixar was bought by Disney

• ⁨Comment⁩ on ⁨Looking to move on from Unraid, need suggestions.⁩ ⁨⁨6⁩ ⁨months⁩ ago⁩:

  I was replying specifically in the context of the original question. Unraid already has their services tooling built out over containers so this person already is probably using containerized versions of the arr services. It would be overkill to go build vms for these services specifically for what you said. They don’t need to be windows or osx, they don’t need hardware passthrough, they don’t need a full kernel.

  That aside. You absolutely can run containers as a full isolated kernel and directly map hardware to them. CGroups absolutely allows for those use cases. You may not be using docker anymore but docker is more of a crutch for beginners who probably dont need those things.

  One example of this in the real world are COS and Bottlerocket which are literally distributions of Linux where even core is components are individually running under different containers via cgroups. COS runs on every GKE cluster in the world and bottlerocket on most EKS clusters.

• ⁨Comment⁩ on ⁨Looking to move on from Unraid, need suggestions.⁩ ⁨⁨6⁩ ⁨months⁩ ago⁩:

  I can break one container without breaking all of them? I can run them in isolated container networks and even isolated cgroups if I want to. Docker hides a lot of the core reasons tools like jails and chroot and eventually LXC were created but containers absolutely can do the things you are using vms for if you are willing to learn how they work

• ⁨Comment⁩ on ⁨Looking to move on from Unraid, need suggestions.⁩ ⁨⁨6⁩ ⁨months⁩ ago⁩:

  I built my recommendation around the likelihood this person is already using docker and therefore already has containers that would be extremely easy to run without unraid. There would be less lift to use the same config files and volume mounting they are already using.

  Operationally though I would never run vms and containers in the same orchatrated system. Look at what they are asking to do. Why would you run sonarr as a container and radarr as a vm. Obviously they are going to end up just doing one or the other

• ⁨Comment⁩ on ⁨Looking to move on from Unraid, need suggestions.⁩ ⁨⁨6⁩ ⁨months⁩ ago⁩:

  I legitimately don’t understand the trendiness of proxmox given that vms are overkill compared to containers. If you are migrating from unraid you are likely already using the docker version of all your arr services so going and spinning up vms feels like a step backwards.

  You can either use the exact same containers and use systemd to run them as raw services or use something like docker compose or dozens of other tools to orchestrate them. I use k8s but can’t recommend it with a straight face after taking down VMs for being overkill (very different kinds of overkill but still)