So there wasn't any actual problem with Docker, it was the OP's own problem that they "solved" by switching container platforms instead of just fixing their own buggy script?
This is an all too common problem in development and it's made me very skeptical of coworkers at times who use it "X technology doesn't work or X is garbage" as a justification to switch technologies or spend time prototyping several alternatives.
I'm not gonna say Docker is a perfect tool by any stretch either.
I know a lot of people in school who have to use a generally well regarded technology, but hate it because they had to use it in a class. For example, they might see someone on github and go “oh is that github? I hate using git” when in reality they had to use it in a group project with 4 other people who have never used it, and had no understanding of branches, merging, etc.
I have seen the same thing with LaTeX, Python, and Vim.
(ProTip: Maybe you hated it from school because it was used as a tool for teaching theory and beginner stuff, and you were given difficult homework assignments. Maybe you'd like it more if you learned how to use it practically, while you were working on things you actually wanted to do.)
To be fair, LaTeX, git, and Vim, beyond shallow use, have fairly steep learning curves and can initially seem like a huge inconvenient mess before one learns, through trial and error, enough of the basics to really unlock enough utility to justify their use.
In a perfect world we'd all first sit down with manuals/tutorials, absorb everything from the getgo, and hack away with bliss; but most people, myself included, do not have enough intrinsic interest to muster the will to sit through documentation while paying enough attention to absorb a bunch of seemingly irrelevant details about some involved tech tool, when we have one simple goal to accomplish now, so instead we piece everything together with a combination of Google searches and keyboard mashing until things work and then optimize on top of that later.
In my experience this can be one of the factors that define a so called 10x dev - the willingness and ability to plod through docs with a genuine interest before using a powerful tool. I imagine such crowd is overrepresented on HN but quite rare in the general population.
Vi predates keyboards with arrow keys and numpad. You can do most of what vim can do in any editor if you can use your keyboard effectively. Then there is the question of VI vs VIM. Some schools force students to use VI, which is really a different and antiquated beast.
LaTeX lost a lot of relevance since Office 2010, that added a great equations editor and better handling of sections/subsections.
TeX still renders equations better than Office does. Also it's programmable.
I think you are spot on with the intrinsic interest.
OP seems to run a lot of infrastructure on his "home servers" not because he directly needs it but as a learning/playground environment.
So here he's chosen to learn about some new tools rather than track-down and fix a misbehaving script. That seems reasonable to me.
(Though, I'm inferring here. If that's really was his thinking was, he could have stated it clearly and prevented the confusion.)
I encourage you to read the entire article, so you understand what was his actual thought process deciding to replace docker, and the pros of the new solution.
At a minimum it means he doesn't understand how his own code works which is going to be problematic if your career involves coding.
The "it's none of your business" argument falls flat the moment you decide to broadcast to the entire world what you're doing and then get it onto a the front page of a website known for debating the content of said articles.
Well, he didn't say that the reoccurring problem came back, so maybe it was Docker after all?
Either way, I agree somewhat #facepalm
I maintain the "duh fix your script dummy" is not the right attitude. The author clearly states it's used for a build farm. That is bound to fail ...
I read "Docker daemon was using 100% CPU" to be the recurring incident; not a given script. And when that happens, it ends up cascading and stuff get OOM-killed before you know it.
I look at each of those articles carefully and my takeaway every time is the same: there are great alternatives to Docker if you have unlimited time and are willing to accept lots of limitations.
I agree with the actual comments on Dockers design.
But I’m in infra and security so I’m biased.
It’s my job as a tech nerd to care about that stuff? Or maybe I’m leaning into the role too much.
Why even bother working in tech when this march forward is what everyone complains about but has been here forever?
Growing up means getting over this shit internally.
Why does Docker need a daemon at all?
Contrast with LXD. It has a daemon as well, but it tracks containers and state across multiple hosts, so the need is obvious. The single host LXC doesn't have a daemon.
You certainly could.
> systemd shouldn’t be a daemon too
A. False.
> and sysv init scripts are better too
B. Debatable, but the start is a false premise, SysV init was a daemon plus the scripts.
Is this gonna be another systemctl situation?
“It’s new! Hiss!!!!”