Comment by _euvw | Hacker News Reader

Comment by _euvw | Hacker News Reader

Parent Full thread

Why not? Let's run the numbers.

* http://wiki.alpinelinux.org/wiki/Special:ActiveUsers

14 active users. That is not a lot. In fact, that is tiny. Maybe their redmine has more? http://bugs.alpinelinux.org/projects/alpine says 16 users in the 'developers' group.

But maybe they're very pro-active on the mailinglist? Let's check their security announce list:

* http://lists.alpinelinux.org/alpine-security/

1 message. From 2009. Hmm. Well, their alpine-devel list then? 5110 messages in 10 years. 9 Messages per week. By comparison: the debian developers mailinglist had 492 messages in November 2015 alone.

So even though Alpine Linux looks nice and lean, it is maintained by a very small group of developers.

Now. If building your own container were very very hard, I'd sure understand grasping for something like Alpine.

But here's how you build an Ubuntu Trusty container:

     debootstrap --variant="minbase" --include="systemd-sysv" trusty ${TMPDIR} ${UBUNTU_MIRROR}
     chroot ${TMPDIR} 
     dpkg-divert --local --rename --add /sbin/initctl
     ln -sf /bin/true /sbin/initctl
     dpkg-divert --local --rename /usr/bin/ischroot 
     ln -sf /bin/true /usr/bin/ischroot

Just tarball it and throw it in 'docker import'. Your done.

Need to add or remove software? Use Ansible to configure specific containers with specific confgurations.

Need security-updates? chroot into the folder, apt-get update; apt-get upgrade.

Throw the new tarball into docker import again. You use long-term supported methods and systems. There are tens of thousands of packages. Bazillions of PPAs to use.

Edit: typo in codesnippet

OpenBSD is likewise developed by a small number of users. A Linux distribution is arguably easier to maintain for a smaller group because the core components are developed upstream.

Alpine does well at making security measures like SELinux accessible. Meta-distributions like Debian serve a different purpose.

Alpine Linux supporting selinux is only relevant in this discussion if you run Alpine as the container host. To the Alpine containers it is of no consequence.

OpenBSD has more than a great track record on security, maintainability, community spirit. As has Debian.

Alpine, after ten years, was simply not on the radar as a distro.

It is merely developers that do not seem to care about the actual systems these containers are built from that find Alpine interesting.

It's small, so even on a 3g connection you can download those containers and get the functionality a developer seeks. Fast. And that is fine. It gets alpha code out in a timely manner without too many resources.

Just do not pretend that this way of working will deliver sustainable, maintainable and consistent code that will work just as well inside as well as outside containers.

Maintained, secure, stable and proven distributions have served any purpose given in the past. From embedded systems to HPCs, from trading floors to satellites.

Saying any of the "old school" distro's are a bad fit for running in a container is a display of ignorance at best.

quantity-of-people-involved is a terrible, irrelevant metric for code quality.

Maybe, but it's a fantastic metric when guessing how many undiscovered bugs and security vulnerabilities there are.

GP also goes into some detail about the amount of discussion and updates to Alpine Linux, which are excellent metrics for code quality.

Nonsense, it's just a straight up ridiculously uncorrelated, terrible metric. Which would you say has been more buggy and broken, djbdns or php? nacl or mysql? qnx or openssl? windows 95 or ping? Which one of each do you think has had more "discussion and updates"? Which one of you think is better code?

Code quality has nothing to do with how much jibber-jabber there is on some mailing list, nor with how widely used a piece of code is. It has to do with the actual code.

In the case of Alpine Linux (which I've never used), probably 50% of the code is the linux kernel itself, another 20% is musl and busybox, and the rest is random gnu utilities. Which of those things is 'low quality' and has 'undiscovered bugs and security vulnerabilities' that broken, random, low-quality high-politics tire fires like most linux distributions don't have?

But conversely, is it not intrinsically obvious that not having the grotesque pile of random freshman desktop apps and terrible init systems that other distros have, could reduce the attack surface to a point where a single organization could conceivably make sense of it?

You are correct on all points concerning the quality of code of Alpine Linux. I do not doubt it. But it is irrelevant to the discussion. The Linux kernel is not part of the containers that are based off of Alpine. That is the whole point of this level of virtualization: sharing the kernel.

Furthermore, the problem I have with Alpine-based containers is that using those as the basis of tooling used for building your own product, your own product will have a hard time becoming maintainable, sustainable an secure.

I've had developers doing make; make install in Dockerfiles just because Alpine doesn't have some library or version packaged.

Containerization brings all manner of sweetness to the table, but the current way it is used is a throwback to 1998.

Not having desktop software inside a small container does reduce the attack surface. Debian, Ubuntu, Centos can handle that requirement just fine. What is your point?

Your sentences don't make sense next to each other. If you're unable to point to any fault in the quality of Alpine Linux, then why are you trying to create FUD about how Alpine Linux is unmaintainable, unsustainable, and insecure? Could you maybe, instead of just repeating it over and over without evidence, provide some example of how Alpine is concretely any one of those things?

While you're at it, please show me the Debian, Ubuntu, or CentOS distribution that doesn't have desktop bus installed. I'll wait.

Appologies if I am unclear.

> why are you trying to create FUD about how Alpine Linux is unmaintainable, unsustainable, and insecure?

I never tried to make that claim.

What I am trying to say is that if YOU built YOUR software against Alpine, IT will be hard to maintain/sustain/insecure. Because your software will probably have dependencies. Dependencies not found in Alpine. And now you have to maintain and test those dependencies. You'll have to keep informed on all the security advisories of those dependencies. All the changelogs. And by then, you've started to reinvent wheels that the fine folks of Debian, Ubuntu, Centos have invented already.

That is a resource drain on companies that is inefficient and cumbersome with little to no added value.

> While you're at it, please show me the Debian, Ubuntu, or CentOS distribution that doesn't have desktop bus installed.

A container is not the same beast as a distribution. It does not have the same requirements. It is just a tarball. And you can throw anything into it, or out of it.

I'm just saying to use debootstrap to throw stuff in that tarball so you have the benefits of an enterprise-level, proven distribution, instead of using this something that has not yet proven itself. So if you ever need to take your software OUT of the container and run it on an AWS instance, or on your own hardware, you'll have no problem with it.

In short: I see no added value for Alpine. It does not address my operational concerns, and raises a bucketload of new ones when I compare it to Debian, Ubuntu or Centos.

That makes a little more sense, thanks. Although, I will disagree that your software will probably have dependencies that are not in Alpine; I tested it out and installed a large software stack and found no such issue. And I think you radically underestimate the crumminess and incompetence of the, e.g., debian package system. Nevertheless, good luck with your systems and Merry Christmas.

Who said anything about the quality of their code?

We took alpine, added the oracle jre, and use it as a base image for our clojure apps. Seems to be a reasonable choice for that use-case since you just need something that will start your jar.

I'd have thought the same would be true for apps written in Go.

You can actually take things way further in Go: https://blog.codeship.com/building-minimal-docker-containers...

You're probably right, but have you ever thought that maybe Debian has so much mailing list activity because it is such a huge project? There's something to be said for lightweight software. Of course, workaday devs should use the accepted best practices, but can't people experiment with better techniques until they have been proven out?

A huge community and installable packages does not mean you need to use all those packages. The smallest container I've built is about 90MB, using Ubuntu. That is pretty lightweight. Of course, the container doesn't actually do anything....

Another thing to consider: if you software works inside you self-built Ubuntu container you can be pretty sure it works on any Ubuntu install anywhere. Even if your company does not use containers everywhere, your developers can.

Edit: typo and sentence finishing.

Reply on news.ycombinator.com