Image size is extremely large

[Iristyle]

So I was just taking a look to determine what the differences might be between this container image and the linuxserver image published at https://github.com/linuxserver/docker-nzbhydra2

I assumed that b/c this container is arch based that it would be smaller. Unfortunately, that doesn't seem to be the case. It's quite the opposite in fact:

• the linuxserver container image is 401MB
• this container image is 1.03GB

Also FWIW, the linuxserver folks having a very automated process and a large community -- maybe worth thinking about combining efforts on this image rather than maintaining a separate image?

[binhex]

I assumed that b/c this container is arch based that it would be smaller. Unfortunately, that doesn't seem to be the case.

Arch linux is a rolling distro, this makes keeping the size down difficult as packages frequently update.

Alpine on the other hand (base distro used by LSIO) is not rolling and is extremely small by design, thus the smaller docker image sizes.

My question to you is, does size really matter?, yes the download of the image takes longer, and yes it is larger on disk, but is that a real issue?, you can still pack over 20+ containers into a 20GB docker.img file (assuming no sharing of layers) and the download of the image on a mediocre connection will still be down within a couple of minutes at most.

For the additional size i get a large library of packages via Arch Repository and a VAST library of tarballs from Arch User Repository, and of course up to date package versions. This all leads to making my code simpler and easier to maintain, whilst being able to easily create a docker image for pretty much any linux app i want.

Also FWIW, the linuxserver folks having a very automated process and a large community -- maybe worth thinking about combining efforts on this image rather than maintaining a separate image?

im well aware of LSIO, we have been friendly rivals for a long time (years) and i know they are automating their builds via CI tooling such as Jenkins. I also automate my builds via custom python scripts, and have so far have got away with steering clear of the additional complexity and cost of running a VPS with Jenkins (i use jenkins for work).

Im not ready to throw in the towel quite yet, as long as somebody carries on using my images then i will carry on sharing my work, obviously you have made your choice to go with the LSIO image and i completely respect that.

[Iristyle]

Yeah, I think part of it for me is bus factor. I've been using your image for a while, but almost all the other apps I run are provided by LSIO, so having a larger org with more traction backing them is useful b/c I know they won't just disappear one day.

They also have a way of managing ENV vars (and user mgmt) that is consistent across applications, which makes management simpler IMHO (this container maintains a pretty similar setup, but a lot of others don't). I run my apps on a Synology with a lot of space, so the container size isn't as important, but it's still something I keep an eye on.

Their base for nzbhydra2 is actually bionic, so it's backed by a fuller distro. I help maintain a number of images for Puppet, and we typically ship on bionic as well b/c it's base size is well suited to containers + it has a real libc which makes running major platforms / runtimes reliable. I do work on a couple of Alpine based containers as well... and I know how challenging it can be, b/w their weird packaging policies, musl, DNS problems, etc, etc.

Anyway - I didn't mean to be trolling about the image size in particular and probably could have worded my issue better. I think when I originally setup nzbhydra2 your container was the only one available? But now that I see that LSIO is actively maintaining, it was an easy switch for me to make. That's not to say I'm not appreciative of the work you've invested to ship! Thanks a ton for all you've done!

This was more of a note to see if there was anything that you felt really differentiated what you have or not -- because maybe there isn't a need for multiple variants of the same thing? I've helped maintain a lot of open source projects over the years, some of which I've abandoned -- I know it can be tough work and we all have limited cycles. At one point I owned about 60 Chocolatey packages, but the work became too burdensome and I just passed all of them off basically...

GH actions are great if you haven't used them yet... no need to use Jenkins for most things at this point. Recently, I've even been spinning up / testing k8s distros in that environment -- so there's a lot you can get away with using the public runners.

Thanks again for all your effort!