Docker Multi Arch (esp. ARM) builds: Improving Build File

[activenode]

@knadh I have reopened the PR to simplify the process. I can copy over the Description but I'll just have a reference link here for now and a tl;dr.

Reference Link: #1414
tl'dr: Now multi-arch for Linux works, the Utsname had to be replaced for building so.

@Thunderbottom @mr-karan fyi

[Thunderbottom]

The project removed support for machine info in this commit: 104c4fc as it was just a visual "feature" and not really necessary. Personally, I do not feel that there's any reason to add it back since the multi-arch image should work now without any issues. We can take a look at the contributions for other features as mentioned in the previous PR though. Have reviewed this just for brevity and clarification on the changes.

[activenode]

@Thunderbottom will rework the PR now with the added information and ping you afterwards

[activenode]

@Thunderbottom completely cleaned up now

[activenode]

What should I be changing for this to be merged? @Thunderbottom @knadh ? Could you please tell me? Feel free to bring back the commented archs (which we agreed on is not useful) but at least the org-ifying part is very much useful for forking and building it.

[Thunderbottom]

looks good to me, thanks!

[knadh]

Thanks @activenode. One last question: What's the reasoning behind removing Windows, Net/FreeBSD etc. from the build list? There are in fact users of these OSes who download and use the pre-built binaries.

[activenode]

Feel free to undo that if you think it helps / it is troublesome.

My thought: Are there really people using an .exe File? Like for real? Because looking at the build this is what happens. Like would you want to deploy a Windows Server (Question 1) and IF would you then not rather abstract it into "Linuxified" Docker containers instead of actually running an .exe file?

Maybe I'm missing something but my reasoning is: Everybody can use Linux+Fitting Arch even if their base Arch is not Linux. Which is a normalized approach that should make everyone happy.

But again: Maybe I'm missing a point, happy to hear your POV.
Personally I would get rid of it and see if someone complains and comes up with proper reasoning.

[knadh]

My thought: Are there really people using an .exe File? Like for real?

Yep, people are, although they're a minority :) I have also heard from people pulling pre-compiled listmonk *BSD bins.

There's no additional overheard or complexity in making these builds available to the tiny minority of users who use it. Zero-cost, no downside. Easy trade-off to have them on.

[activenode]

And shouldn't the minority be evangelised to simply use Docker? But I mean yeah I don't have an issue with that. You wanna do that or should I remove it?

[knadh]

And shouldn't the minority be evangelised to simply use Docker?

Why? I'm not very familiar with the intricacies of Docker myself. I'd like to keep the project as widely accessible as possible. If a few auto-built bins on the releases page enables that with no downsides, why even think twice.

Let's bring those builds back please.

[activenode]

Sure, no worries, fixed.

[activenode]

But just to add up to the WHY discussion:

Having more stuff means more build time and more potential failures. We had that, remember? When the OS specific code was triggering problems with other builds?

Unifying "Usage" can hence lead to less maintenance as the focus shifts and no one would be prevented from using it since Docker easily allows to spin up listmonk, no matter if Windows or not.

It's kinda like the same why for USB-C: Making Hardware that supports Lightning, USB-C, USB-A, Micro USB, etc. would have different base technologies with different points of failures and wouldn't allow to focus.

So same thought here. But I mean sure, as long as it's building fine we can take that route and also have longer builds, should be fair.

[knadh]

True cross-platform applications have always been a quest in computing. Docker does enable it to some extent (via abstractions, tooling, and UX). I agree.

However, in listmonk's scope, it doesn't make sense to force or evangelize any one method over the other, especially when it's only a tiny minority of people who use, say the Windows build. Somebody who wants to use it should just be able to use it. It's not listmonk's goal to force them to learn a new technology (eg: Docker) just to be able to run what's a simple binary when it can be made available. USB-* (competing standards that supersede previous versions), and platform native binaries are not a fair comparison.