1. 7
  1.  

  2. 3

    I wonder how long docker will remain at the “forefront” of containers.

    If not for Docker’s vendor adoption, would “podman for dev, and k8s for prod”, start becoming more common?

    1. 1

      I don’t know, I only hope we’d see container software that would work on more Unixes, like FreeBSD and OpenBSD (and maybe OSX[1]).

      [1] Yes, I know Docker kinda works on OSX.

      1. 2

        I dearly love FreeBSD, but reading the mailing lists sometimes makes me wonder how anything ever gets done. The amount of pushback occasionally seen for sometimes seemingly trivial improvements[1] …. and the historically long support lifecycle – major versions supported for 5 years!

        It’s no wonder that the wheels grind slowly sometimes, and things tend to have fairly clunky usability at times (for things like jails, bhyve, etc). Good tech, often saddled with middling interfaces that have to change somewhat glacially.

        Hats off to all the devs[2] who continue to “get things done” anyway.


        [1]: Wasn’t the term “bike-shedding” even coined on the FreeBSD mailing lists back in ’99 or so?
        [2]: Same goes for devs for OpenBSD, DragonFlyBSD, NetBSD, Linux, etc.

        1. 2

          Only those who are skilled in the ways of placating the hordes of angry greybeards shall be deemed worthy of a commit bit. /s

          1. 1

            sometimes seemingly trivial improvements

            I have problems with such things. Sometimes the improvements fix a problem that doesn’t need fixing.

        2. 1

          Docker itself will probably always have a place, but the current trend in devops is cutting Docker out of the loop and orchestrating containers at a lower level. The buzzwords for these lower-level components escape me because I’m not as entrenched in this area as I’d like to be.

        3. 1

          From the article:

          “.. Among those requirements is the need to take advantage of modern kernel features in Linux 5.0 and beyond, as well as dealing with different types of new workloads, including state-full workloads, which require a degree of persistence that is not present in stateless workloads. Edge workloads for deployments at the edge of the network, rather than just within a core cloud, are another emerging use case. Internet of Things (IoT) and embedded workloads in small footprint devices and industrial settings are also an important use case for Docker in 2019. ..”

          “ … Crosby is most interested in improving is the stateful capabilities of Docker, which in his view are currently relatively limited. ..”

          Not sure if others share same view, but

          I think operating systems did not particularly advance in managing applications across multiple hosts/nodes.

          So these gaps are being filled somewhat adhoc, by layers eg K8, Docker, etc – that essentially need to replicate similar algorithms, constraints, and security features – that OSs have to do when managing processes.

          There was a trend of so called ‘Single System Image’ ( https://en.wikipedia.org/wiki/Single_system_image ) , that, I was hoping would take of (it was even, once ,stated to be one of the main goals of DragonFlyBSD ).

          It seemed to have died, or at least it is not receiving no where near, similar effort as the K8/Docker/etc.

          My suspicion is because core teams managing fBSD, Linux and other BSDs simply do not believe it is high enough in priority.

          In the mean time, there is a re-invention of SSI going on via user-space tooling. May not be such a bad thing. But in terms of longevity, in 10-15+ years time, I think SSI efforts at OS level will overtake the adhoc distributed app management we are seeing today.