Hacker News Reader

Comment by AtNightWeCode | Hacker News Reader

I have quit using Alpine. It caused to many issues in production. For some workloads in GO for instance you can use Scratch directly. But slim and distroless are my preferred base images.

View on HN

Personally I hate scratch images because once you lose busybox, you lose the ability to exec into containers. It's a great escape hatch for troubleshooting.

There are a few options that help here. With host access, I tend to just use nsenter most of the time to do different troubleshooting. It can be a bit of a pain doing network troubleshooting though since the resolv.conf will be different without the fs namespace.

And kubernetes has debug containers and the like now.

Yes we have experienced many issues with Alpine too. Ubuntu with 25MB compressed is ok.

Until it's not. Well working deb/apt is replaced by some self-sabotage called snap before up-to-date packages land there.

Are people actually using Snap in containers? It feels like a convenience feature for desktop users.

They don't give you the choice. Applications are only avaliable as either a snap or an deb. With many you might want to containerise (ie Chromium for CI) being snaps. I dont belive they can work in unpriviledged docker containers.

Which apps are you using via Docker, that are only available as a snap?

There are Chromium debs for Ubuntu 20.04 available from the Linux Mint repo.

To get it Chromium under docker, I'm using the following params:

  --headless --no-sandbox --disable-gpu --window-size=1920,1080 --disable-dev-shm-usage

I understand that, it's just my impression with using Snap that it's used to ship desktop applications in a consistent way.

you cannot use snap inside a docker or any other OCI container, first of all snap is a containerised package as well so it doesnt make much sense but what is more important it requires SystemD and as far as i know if systemd isnt PID 1 snap deamon wont run and its CLI will output it cant run.

Snap is horrible.

The software required for running a Snap Store instance is proprietary [0], and there are no free software implementations as far as I know. Also, the default client code hardcodes [1] Canonical snap store, so you have to patch and maintain your own version of snapd if you want to self-host.

Snapd also hardcodes auto-updates that are also impossible to turn off without patching and maintaining your own version of snapd / blocking the outgoing connections to Canonical servers, so snapd is also horrible for server environments. To top that, the developers have this "I know what's good for you, you don't" attitude [2] that so much reminds me of You Know Who.

[0] https://www.techrepublic.com/article/why-canonical-views-the...

[1] https://www.happyassassin.net/posts/2016/06/16/on-snappy-and...

[2] https://forum.snapcraft.io/t/disabling-automatic-refresh-for...

So,another systemd in the making... how long until snap takes over dns resolution...

Say what you want about systemd, but it is still Free Software.

Yep. I am trying my best to boycott Canonical and their closed source Snap which is akin to Apple Store or Play Store, but for desktop... for... LINUX. Goes against the philosophy in every way imaginable.

It's really sad especially given how Canonical introduced so many people to Linux through Ubuntu. I understand they need to monetize to survive but I wish it wasn't like this. I miss the "Ubuntu One" service, a simple Dropbox like alternative that you pay for. Completely optional and server side. Integrated into the UI.

That being said, I was wondering how many people actually find the Snap system and ecosystem useful. Reverse engineering snapd (which is licensed under GPLv3) and snap app format in order to create a compatible server would be a fun project.

> I have quit using Alpine.

As I said to the author of TFA a few days ago: Alpine delenda est.

What issues did you experience with Alpine and Go?

What go build options are recommended to have go output a static binary (that can run inside a scratch image)?

If you're using plain Go, you get static binaries for free. If you're linking against so C library you might be out of luck. You can try setting CGO_ENABLED=0 in your environment, but I've had mixed success in practice.

CGO_ENABLED=0 has always worked for me in production, but it did come with some tradeoffs, notably, network performance.

I’ve only had success with CGO_ENABLED. If you depend on a C library, then obviously it won’t work, but mercifully few ago programs depend on C libraries (not having straight C ABI compatibility is a real blessing since virtually none of the ecosystem depends on C and its jerry rigged build tooling).

Well this is not what I'm seeing. I need to add -ldflags "-linkmode external -extldflags -static" to the go build command otherwise the binary doesn't run inside a scratch image.

Reply on news.ycombinator.com