Hacker News Reader

Comment by sjburt | Hacker News Reader

It's hard to see what Docker is adding here since qemu is being run inside Docker. You could get almost identical functionality out of a bare VM image and not deal with the hassles of docker.

View on HN

Aren't you being a little too harsh? The Dockerfile automates the installation of libvirt and custom components to launch the VM so while the title might be misleading it is hardly "not adding" anything.

Docker is not adding anything whatsoever. The "dockerfile" could be converted with a simple macro into a plain bash script and it would literally be the same thing. The container is not abstracting anything here; you are using KVM of the host system.

You even have to install more packages in the host than in the container.

You could even just run the original script the Dockerfile is wrapping directly which will even autoinstall the packages for you.

Yes, Docker is effectively acting as the supervisor process for this container, only managing its process lifecycle and allowing easy removal/persistence.

... but you don't need a container.

My (linux) desktop has a macOS icon on it. I click on it. That starts a QEMU/KVM process which runs macOS. When I quit out of that, it is gone. When I click on it again, it runs again.

I suppose there are a few files floating around that persist between runs, and are not utterly trivial to manage. Just ... trivial to manage.

Yeah, but at that point, why not just run Vagrant?

It's a hammer problem. Docker is the new hammer and now everything starts to look like nails.

Yep. We know it's not a nail though. It's a screw. And they duct taped a screwdriver to the hammer and called it "Driving screws with a hammer".

It's the hammer problem because management and IT have locked up all of the other tools, so you're damned right I'm gonna try to use the hammer.

Spooling up a docker image is low friction at a lot of places. Doing anything else can take an act of Congress.

> Doing anything else can take an act of Congress.

Does fiddling with BIOS parameters and installing kernel modules fall into "anything else"? Because this project doesn't work until you've done that on your docker host.

Not in this case, but in qayxc's more general statement.

I often wonder what it is that perpetuates hammer problems. When I look at a problem, all technologies are options. If I'm doing the work, I'll obviously try to choose from those I'm more familiar with or choose what seems like the best established/mature hammer.

It often seems like someone wants to use a specific hammer and tries to tailor/turn/reshape problems into nails. Some of it may be resume driven development, perhaps choosing comfortable technologies, etc. Perhaps hammers are the only tools they're familiar with and risk aversion in business leads us to only use our hammers.

Something is amiss because I keep seeing hammer problems and it never seems to stop.

Luckily, a lot of the things are nails. The number of applications you can keep neat and tidy with a fleet of containers is so great. Even a relative novice can get some great things working by poking about a few guides. And when it all breaks you can start again without too much collateral damage.

I'd argue that I was able to do the exact same thing 20 years ago using VMWare Workstation - download a VHD image with OS and app(s) pre-installed and configured, optionally map to a drive on the host OS and get started instantly...

Maybe I'm too old to get the appeal of "a fleet of containers" in place of a single (and potentially throw-away) VM image along with maybe even a vagrant-script to make it easily reproducible... ¯\_(ツ)_/¯

Running multiple containers is faster and more efficient than multiple VMs. Running a container on the same kernel as the host is faster and more efficient than a VM. If you're trying to run an app across different OS kernels, you still have to use a VM unless you can compile your app on that kernel natively. This project really doesn't do much beyond what a VM gets you, and you still have to configure the host outside the container to enable virtualization.

The difference is tooling, particularly "just works out of the box" tooling.

Yeah, tooling/workflows are the (possibly only) reason that Docker is popular. It's like how the FreeBSD folks will say that they've had containers (jails) long before Linux, which is true but misses the point that without the ability to pull and run images trivially they're losing, badly, on usability.

I’m going to look at this, thank you.

Docker is the old hammer. The new one is called podman.

It's just another packaging format, and if I had to choose just one then Docker is the least worst for me.

Least worst is obviously subjective but for me it includes running a bunch of random stuff in roughly the same way across Linux, OSX and Windows. The launch and manage UX is significantly better than vms also (not intrinsically, for any good reason, but in practice).

I get that this container is not actually portable tho.

Looks like a package for those who have no package manager. Highly insecure - do they review Dockerfile on each installation? Does it store and display pulled git hash?

Looks like work in progress:

    $ git clone https://aur.archlinux.org/yay.git
    $ cd yay
    $ makepkg -si

... and never used.

Makes sense as a wrapper for PKBUILD

    pkgname=qemu-osx
    pkgver=10.14.6
    depends=(qemu libvirt dnsmasq virt-manager bridge-utils flex bison ebtables
             netctl libvirt-dbus libguestfs)
    ...

New way of `./configure && make && make install` and `curl | sh`. Why can't all distribution have easy to define package [1]? And publish it [2]?

[1] https://wiki.archlinux.org/index.php/PKGBUILD

[2] https://aur.archlinux.org/

I know it's against the HN rules to complain, but this comment really feels so generic. Like every time a JS project is posted, 'oh npm is so bloated'. Everytime there is a new app, 'oh electron is so inefficient'. Everytime something is packaged in a docker 'whats the point of containerizing this'.

It's really making me sad to browse HN sometimes.

It's just nerds being nerds, nothing new. Dropbox as ftp and rsync yadda yadda. Other tribes have "is that even lifting" and stuff like that. Take it as small talk (pun intended) and just collapse the thread, you can do that these days.

I sympathize with what you're complaining about, but I don't think GP is an instance of that. GP is (rightly, IMO) complaining that the linked article proposes something with extra steps that are not needed, as in: it could be easier than suggested. The typical HN gripes you describe are sort of the inverse of that: complaints that easy-to-use things (electron, npm) are flawed in comparison to their harder-to-use counterparts.

Reply on news.ycombinator.com