Editing Talk:1988: Containers

<!--Please sign your posts with ~~~~ and don't delete this text. New comments should be added at the bottom.-->

Pretty much a description of my social interactions ... [[User:Cosmogoblin|Cosmogoblin]] ([[User talk:Cosmogoblin|talk]]) 17:51, 2 May 2018 (UTC)
:Pretty much a description of all my "useful" programs.

I feel the thrust of this comic is partly “people use docker because they don’t know how to do things properly”; notably such people get tasks done easier and faster, but their work involves wasting a lot of computing reaources to do small tasks inside entire emulated systems.  Agree?  Disagree? [[Special:Contributions/162.158.62.153|162.158.62.153]] 18:59, 2 May 2018 (UTC)
:Agree. --[[User:Joshupetersen|Joshupetersen]] ([[User talk:Joshupetersen|talk]]) 15:55, 3 May 2018 (UTC)
:Agree! [[Special:Contributions/108.162.237.184|108.162.237.184]] 17:08, 3 May 2018 (UTC)
:... it's been four years, but it's worth noting that Docker doesn't emulate an entire system - you're thinking of virtual machines. Containers are just isolated userspaces (they share the host kernel and hardware like normal processes!). [[Special:Contributions/108.162.216.64|108.162.216.64]] 06:56, 30 April 2021 (UTC)

I don't know if its just docker, almost any time I've gone to build mobile anything the API needs new libraries, their "secure" connecting functions must be used, or some other blackbox MUST be /glued/ to my work. If I don't stay on top of every platform, this in and of itself is a head ache I can't imagine what it'd be like if I had to learn and comply with the content of these libraries. {{unsigned ip|172.69.90.40}}

When did any tablet with a browser not support <tt><nowiki><frame></nowiki></tt>s and <tt><nowiki><iframe></nowiki></tt>s? And for that matter why are docker containers with kubernetes better than server images with a load balancer? I asked one large-shop sysadmin who had transitioned to the former from the latter, and he said, "There really aren't many differences but I feel like I'm ready for microservices." [[Special:Contributions/172.68.34.52|172.68.34.52]] 22:50, 2 May 2018 (UTC)
:The issue as I see it is to get the two apps to both run simultaneously and appear side by side, which probably involves either writing code to control the window manager or getting the existing apps to output to an image that can be drawn on screen. I'm not a mobile developer, but my guess is that this would be quite difficult for a novice programmer.[[User:Probably not Douglas Hofstadter|Probably not Douglas Hofstadter]] ([[User talk:Probably not Douglas Hofstadter|talk]]) 23:13, 3 May 2018 (UTC)

For some reason, this really, really, REALLY feels like it's a continuation of 1987. Agree? Disagree? Also, the 'wasting a lot of computing resources to do small tasks inside entire emulated systems' does not feel like valid criticism, since they are just walled-in processes sharing the same kernel (and everything below). Firing up full-blown separate VMs for things that could just as well run in containers is the real wasteful choice IMHO. [[Special:Contributions/162.158.238.70|162.158.238.70]] 07:29, 3 May 2018 (UTC)
:Agree. 1987 shows how problematic Python can be due to its lack of a well thought out version control. How can you avoid this mess? Docker! It isn't the only way, but IMHO the most elegant solution. And yes, I have created docker containers where the sole purpose was to avoid contaminating an existing Python installation. [[User:Epsilon|Epsilon]] ([[User talk:Epsilon|talk]]) 05:12, 4 May 2018 (UTC)

The (en)light(ening)est (co)processes are started with fork() and exec(). [[Special:Contributions/172.68.34.52|172.68.34.52]] 22:20, 3 May 2018 (UTC)
: Don't get mobbed by the docker marketers!  I guess a lot of people use Docker today, but to me the comic reads as a criticism.  I feel the real joy of programming is diving deep into components to learn how they work and connecting them in the most elegant, efficient ways possible (real 'hacking').  Using scripts, macros, and containers does not demonstrate to me an understanding of the real function of the components being used, and working without this understanding is inevitably going to lead to unexpected behavior somewhere later (problems, bugs, vulnerabilities) because you don't really know what your pieces are doing.  I think the push for people to ignore these things is causing a 'dumbing down' of software workers that we should resist.  I think a great use of containers is security isolation or build environment testing ... not software design.  [[Special:Contributions/172.68.54.106|172.68.54.106]] 10:51, 4 May 2018 (UTC)

:: I agree about the "real joy" of getting to understand how some software works. Just like with mountain climbing. Using a helicopter to get to the top is much simpler and much more convenient. ''It also has a higher chance of success.'' But it sort of removes the joy. On the other hand, if you do programming for a living you might need to choose the helicopter. Your comment about "really know what your pieces are doing" is absolutely true. But note the wording here: ''what'' and not necessarily ''how''. If you need to know that module X and module Y are difficult to combine because they were built against different versions of library Z then you have gone too far. [[User:Epsilon|Epsilon]] ([[User talk:Epsilon|talk]]) 07:31, 5 May 2018 (UTC)
::: I like the helicopter analogy.  Similar to the comic, it somewhat plays to both camps.  The provider of the helicopter flight plans can tell people how to get to the mountaintop with little investment of effort to reach a high degree of success.  However, people using this service take on the increased burden of providing for an expensive helicopter and its fuel.  The provider of maps, instructions, and training to climb the mountain easily and reliably has invested in more effort, but the service they provide requires far fewer capital resources from the user to climb the mountain over and over.  A difference here is that helicopters are very fast, whereas spinning up containers to execute a task will actually be slower than the alternative.  Another thing those who code for the joy of it will talk about, is the value of investing one-time work up-front so that repeated tasks are made simpler later.  But obviously people who need to reach deadlines that have been set too early to "do the work properly" will not be able to do this.  Either module X or Y needs to be updated to work with the newer version of library Z.  The older version likely has bugs and vulnerabilities.  By not updating it, you are passing these problems on to your users.  [[Special:Contributions/172.68.54.22|172.68.54.22]] 10:55, 5 May 2018 (UTC)

Is it worth adding that "achieved enlightenment" is probably a reference to http://www.thecodelesscode.com/?

The idea behind docker is that you do ''not'' glue together small code snippets. Whether from StackOverflow or elsewhere. What you are gluing together is in effect entire machines with software already installed. You normally don't know or care about any details finer than that. Not even which operating system the code was written for, which computer language it was written in, or whether the software has some odd and specific requirements about what else is installed on that machine. It is true that many programmers that copy snippets from StackOverflow don't really understand what those snippets are doing. But if you view this comic as an explanation of what Docker is all about, a reference to "copying small code snippets" seems to miss the point. [[User:Epsilon|Epsilon]] ([[User talk:Epsilon|talk]]) 04:54, 4 May 2018 (UTC)

I've taken the liberty of removing the incompleteness notice and rewording some of the ''hail corporate'' passages. I don't think the explanation is too pro docker, it looks pretty neutral to me. [[User:Gir|//gir.st/]] ([[User talk:Gir|talk]]) 10:02, 28 August 2018 (UTC)