4 ms·

> Consider that Docker and other container based systems also deploy images. Consider also that Docker was the only one to really get popular, perhaps because

by lmm 1y ago

> Consider that Docker and other container based systems also deploy images. Consider also that Docker was the only one to really get popular, perhaps because it promoted the idea of using a text-based "Dockerfile" as your source of truth and treating the images as transitory built artifacts (however false this was in practice).

cess11 1y ago
Arguably it goes back to chroot-stuff, and LXC predates Docker by some five years or so. I don't remember the details well but Solaris had similar containers, maybe even before LXC arrived. I'd say the clown popularised it outside of Linux and Unix sysadmin circles, rather than the Dockerfile format itself.
- lmm 1y ago
  > Arguably it goes back to chroot-stuff, and LXC predates Docker by some five years or so. I don't remember the details well but Solaris had similar containers, maybe even before LXC arrived. Solaris and FreeBSD had significantly better implementations of the containerisation/isolation piece from a technical standpoint. But they never caught on. I really think the Dockerfile made the difference.
  - throw0101a 1y ago
    > Solaris and FreeBSD had significantly better implementations of the containerisation/isolation piece from a technical standpoint. FreeBSD jails (first) and Solaris zones (later) were 'heavier weight' than containers: folks perhaps did not want to manage a "light VM" to deploy applications.
orthoxerox 1y ago
It's still mostly true in practice. You don't add one more layer to your image to build the next version, you rebuild it from the Dockerfile, which is the opposite of Smalltalk approach.
- igouy 1y ago
  Do you think "rebuild it" cannot be used with Smalltalk? See https://news.ycombinator.com/item?id=45838056 https://news.ycombinator.com/item?id=45838056
  - lmm 1y ago
    A theoretical capability is not enough; what matters is whether that's a practical workflow that's actually adopted by the community.
    - cbsmith 1y ago
      It's a practical workflow that's actually adopted by the community.
    - igouy 1y ago
      It's a practical workflow that was actually adopted. Next you'll be wondering whether changes were integrated continuously throughout the day — "This fine granularity of components enables highly concurrent development because changes can be tracked down to the individual method level …" 2001 "Mastering ENVY/Developer". https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=mastering+envy+developer&printsec=frontcover https://www.google.com/books/edition/Mastering_ENVY_Develope...
- cbsmith 1y ago
  That's where you're wrong. It's not the opposite of the Smalltalk approach.
p_l 1y ago
I remember early days of docker and how it was not really Dockerfiles early on, but people running image, editing in it, then committing this as new image.

by lmm 1y ago

cess11 1y ago

Arguably it goes back to chroot-stuff, and LXC predates Docker by some five years or so. I don't remember the details well but Solaris had similar containers, maybe even before LXC arrived. I'd say the clown popularised it outside of Linux and Unix sysadmin circles, rather than the Dockerfile format itself.

lmm 1y ago
> Arguably it goes back to chroot-stuff, and LXC predates Docker by some five years or so. I don't remember the details well but Solaris had similar containers, maybe even before LXC arrived. Solaris and FreeBSD had significantly better implementations of the containerisation/isolation piece from a technical standpoint. But they never caught on. I really think the Dockerfile made the difference.
- throw0101a 1y ago
  > Solaris and FreeBSD had significantly better implementations of the containerisation/isolation piece from a technical standpoint. FreeBSD jails (first) and Solaris zones (later) were 'heavier weight' than containers: folks perhaps did not want to manage a "light VM" to deploy applications.

orthoxerox 1y ago

It's still mostly true in practice. You don't add one more layer to your image to build the next version, you rebuild it from the Dockerfile, which is the opposite of Smalltalk approach.

igouy 1y ago
Do you think "rebuild it" cannot be used with Smalltalk? See https://news.ycombinator.com/item?id=45838056 https://news.ycombinator.com/item?id=45838056
- lmm 1y ago
  A theoretical capability is not enough; what matters is whether that's a practical workflow that's actually adopted by the community.
  - cbsmith 1y ago
    It's a practical workflow that's actually adopted by the community.
  - igouy 1y ago
    It's a practical workflow that was actually adopted. Next you'll be wondering whether changes were integrated continuously throughout the day — "This fine granularity of components enables highly concurrent development because changes can be tracked down to the individual method level …" 2001 "Mastering ENVY/Developer". https://www.google.com/books/edition/Mastering_ENVY_Developer/ld6E19QIMo4C?hl=en&gbpv=1&dq=mastering+envy+developer&printsec=frontcover https://www.google.com/books/edition/Mastering_ENVY_Develope...
cbsmith 1y ago
That's where you're wrong. It's not the opposite of the Smalltalk approach.

p_l 1y ago

I remember early days of docker and how it was not really Dockerfiles early on, but people running image, editing in it, then committing this as new image.