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.
> 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.
GP also goes into some detail about the amount of discussion and updates to Alpine Linux, which are excellent metrics for code quality.