←back to thread

We Need to Talk About Docker Hub

(www.linuxserver.io)
128 points darthShadow | 2 comments | 24 Jan 25 11:40 UTC | HN request time: 0.407s | source
Show context
ilaksh ◴[24 Jan 25 12:36 UTC] No.42812516[source]▶
I think they have a valid complaint about that open source program Docker is running and lack of response, but the overall tone seems like they are scolding Docker for not giving away it's services for free.

I have always felt that was strange how quickly people started taking Docker for granted, while simultaneously relying on them completely but also somehow dismissing their core utility as a trivial and unsophisticated layer or something.

It's like they never really got credit from most people on HN or are worthy of getting paid, even though most everyone uses their technology.

replies(4): >>42812820 #>>42812835 #>>42812898 #>>42812940 #
bayindirh ◴[24 Jan 25 13:28 UTC] No.42812820[source]▶
FWIW, I have a personal Docker license, but I avoid containers where I can (because containerizing everything by default has its own set of problems). I use containers as "very fat, stateless" binaries which are run when I need to do something (generate a webpage, take backups, etc.).

People got Docker for granted because startups and modern sysadmins absolutely despised installing software on physical or VM servers. On tech side, Vagrant was making VMs easier, plus BSD had jails, and Linux needed something similar. So they found a legit gap in the stack, and timed it well.

Who wants to spend 3 hours to install a service while they can make it appear out of thin air in 40 seconds and deal with the shortcomings and consequences later, or containerize an application, disregard hard requirements and tell "just add an X container in front" (I'm not telling that this is good, BTW).

So Docker spread like wildfire and graduated to invisible/boring tech in 3 months straight. Then when the people demanded money from developers for what they built for them, people grabbed the forks, or created literal forks of the software. I support the latter approach, not the former one.

However, if they advertise a DSOS program, they should do what it entails. Be transparent, fair and open about it.

replies(2): >>42813360 #>>42813850 #
1. curt15 ◴[24 Jan 25 14:33 UTC] No.42813360[source]▶
Containers took off because it was the easiest way for developers targeting Linux to get a predictable runtime environment. It freed them having to worry about the differences between Debian's OpenSSL or Red Hat's OpenSSL libraries or even the differences between different versions of a distribution. You don't see nearly the same level of uptake among Windows developers because not only is there only one Windows API for everyone to target but also Microsoft is willing to bend over backwards to preserve backward compatibility.

Containers also predated "modern sysadmins"; prior to docker, Google ran its prod software in chroots for the same reasons as above:

>The software run by the server is typically run in a chroot with a limited view of the root partition, allowing the application to be hermetic and protected from root filesystem changes. We also have support for multiple libcs and use static linking for most library uses. This combination makes it easy to have hundreds of different apps with their own dependencies that change at their own pace without breaking if the OS that boots the machine changes.

https://www.usenix.org/system/files/conference/lisa13/lisa13...

replies(1): >>42814837 #
2. mikepurvis ◴[24 Jan 25 16:41 UTC] No.42814837[source]▶
Some have argued that the rise of containers correlates with the rise of Python, explaining that containers are particularly well suited to packaging up the dumpster fire that any moderately-complicated Python app quickly becomes.

Of course now we have Rust and Go, but being able to shove your statically-compiled binary into a tiny scratch container and have it cooperate with orchestration systems is still a pretty nice abstraction— just harder to say if it would have been worth it had we not had Django apps needing to be made deployable first.