I am a Linux developer and the single thing that stops me porting my apps to Windows is an easy to use deploy method. Is there some good way to handle this task without to spend months learning about Windows administration like installers, MSI, the registry, logging, services?
The non-flippant answer is to just provide the source and let the distros package it for you. It's a different model. Linux users want to get their software through an integrated package manager, and volunteers will take your software and do all the work needed to make that happen.
You can typically deploy a Windows binary to targets that use much older versions of Windows, and you cannot say the same for Linux distributions. There is significant backward-compatibility with Windows binaries, and it is intentional. It provides for a much better ROI for applications that need to be around for more than a couple of years.
> You can typically deploy a Windows binary to targets that use much older versions of Windows, and you cannot say the same for Linux distributions.
This has nothing to do with the OS. A statically linked linux executable will likely run on any kernel from version 1 to version 4. The issue here is dynamic linking, and windows DLL hell has a name for a reason
I'm referring to the Windows system APIs, which do not require any sort of special treatment for any executable that is linked against them. This includes everything that is included with Windows, from networking to file handling to crypto to UI.
Which libraries are you including in your description of a statically-linked binary on Linux ?
Finally, Windows DLL hell hasn't been a thing since the early 2000s, and even then, it was primarily only an issue with applications dumping shared libraries into the Windows system directories.
With something like AppImages you get pretty much eternal backwards compatibility. The kernel _never_ breaks backwards compatibility with userland, and the AppImage pulls in all other dependencies.
And it's very easy on Linux to provide a source tarball and let the distro packagers do all the work for you. Plus, you know, static linking exists on Linux too, it's not something that only Windows can do.
- You don't want to provide the source code to your app
- They don't find your app interesting enough
- They don't agree with your app's policies
Static linking is a much better response for actually getting the program running on Linux systems but this still leaves out the "is there a way I can package it once for Linux" problem.
Now if it's a CLI only utility/service type tool it's a different story.
Every night we have a job (run by jenkins I think) download the latest ffmpeg code, add some non-approved patched, and cross compile to static binaries for x64 linux, osx, and windows (we've dropped the 32 bit linux build)
It's not hard to make a static binary.
On the other hand most of the "software" I write - mainly shell scripts - includes things like apache configuration, requires other applications (like apache, iperf, tcpdump, lldp, etc)
I want to deploy these to multiple boxes, I want them versioned, I want them easy to update, I want to know what version is installed. All of this is handled by a 10 line config file in a .deb.
Except, if you need to pay rent and put your kids through college, shipping source tarballs is going to significantly reduce revenue for a small developer. (It's sad, but it does.)
A few years ago I tried to compile a C++ project into a static binary which would work on both Ubuntu and CentOS.
Long story short, it wasn't possible. Because the latest versions of Ubuntu and CentOS at the time used different versions of glibc which were mutually incompatible.
You would think so, but it's not true. I struggled with this for a few days before giving up (after finding articles which stated that this is really going where nobody went before)
> Static linking of glibc is not supported on Red Hat Enterprise Linux.
The non-flippant answer is to just provide the source and let the distros package it for you. It's a different model. Linux users want to get their software through an integrated package manager, and volunteers will take your software and do all the work needed to make that happen.