8 ms·

I am a windows developer and the single thing that stops me porting my apps to linux is an easy to use deploy method. Is there some good way to handle this task

I am a windows developer and the single thing that stops me porting my apps to linux is an easy to use deploy method. Is there some good way to handle this task without to spend months learning about linux administration like shell scripts, finding the best place for configs, logs on different linux distros, daemons setup, etc. Something simple and distro independent would be fine...

rwmj 8y ago
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.
- RcouF1uZ4gsC 8y ago
  It is very easy on Windows to create a statically linked executable that you can just copy to wherever you want.
  - rwmj 8y ago
    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.
    - isostatic 8y ago
      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.
    - zamadatix 8y ago
      Distro packagers do nothing for you if: - Your app isn't licensed in the way you like - 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.
      - isostatic 8y ago
        Fine, build your own package. # dpkg-deb --build ./src/ mydeb.deb Stick your dependencies etc in ./src/DEBIAN/control Or just distribute a tar with your application. I used to have to distribute a cross platform java progam. It was horrendous creating the MSI on windows. The linux and osx versions were trivial
        MaxBarraclough 8y ago
        Java? Shouldn't that just be JAR + JVM?
        isostatic 8y ago
        Called native executables too, launch icons/shortcuts etc, jvm version detection Deployed by apt/yum/mdm andslme crappy windows thing. The latter was the problem.
    - jwatte 8y ago
      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.)
    - 21 8y ago
      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.
      - tathougies 8y ago
        If you statically link, it doesn't matter what version of glibc is on the target machine, because it's not used.
        21 8y ago
        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. https://developers.redhat.com/blog/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux/ https://developers.redhat.com/blog/2016/02/17/upgrading-the-...
        isostatic 8y ago
        I don't pretend to know a lot about linking files, but I just checked an old static ffmbc binary I had lying around :/tmp$ file ffmbc ffmbc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=...., stripped :/tmp$ ldd ffmbc not a dynamic executable It runs on the following libc versions: ldd (GNU libc) 2.12 (Centos 6.9) ldd (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 (ubuntu 14.04) ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 (Ubuntu 16.04) I'm fairly sure it ran on distributions as old as ubuntu 8.04
      - Spivak 8y ago
        You're supposed to bundle a fixed version of glibc with your application.
- TimJYoung 8y ago
  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.
  - eikenberry 8y ago
    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.
    - bennofs 8y ago
      Not if you need to communicate with other user space services, such as: * systray icons/application indicators * newer fontconfig versions support new config options which results in fonts being broken for apps that use older versions * I think there is some issue around glibc locales handling if you use a different glibc * systemd/logind/... DBus apis Those were just some external interfaces that came to my mind. I'm sure there are many more.
  - tathougies 8y ago
    > 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
    - TimJYoung 8y ago
      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.
- AnIdiotOnTheNet 8y ago
  > just provide the source and let the distros package it for you. And then sit and scratch your head over why software vendors don't sell a version for your OS.
  - rwmj 8y ago
    I work for Red Hat so ... I'm not scratching my head. We sell $3bn+ of operating systems and other software annually.
juliangoldsmith 8y ago
Is your application open source? If so, I wouldn't worry about packaging for every distro. Just make sure that your application isn't difficult to build, and most things (paths, etc.) are configurable. The config path can be handled with a command line switch. Once you've gotten your application so that it can be built easily, I'd only really worry about packaging it for your distro of choice. If people are interested in your application, it'll get packaged for their distros. If your application is proprietary, I wouldn't even worry about packaging it yet. Getting most Linux users on non-essential proprietary software will be an uphill battle.
shock 8y ago
AppImage⁰ seems to be what you're looking for. XARs maybe, but I don't have experience with them to recommend them. ⓪ - https://appimage.org/ https://appimage.org/
jwatte 8y ago
What you want is snapcraft.io
- eikenberry 8y ago
  IMO AppImage is better for his needs. Snap, like Flatpak, are as much distribution systems as they are packages and they are not widely enough adopted yet to make packaging for each worth it vs just providing the binary to download yourself.
sjellis 8y ago
For desktop applications, Flatpak does this. Otherwise, containers or the new "portable services" feature of systemd. Thanks to systemd, there are standardised ways of doing a lot of things, but yeah, distributions do vary, so you really need an abstraction, or target just a few of the popular distributions.
nvivo 8y ago
I must say as a long time windows developer, .net core on linux is much simpler than on windows. I'm moving everything I have from windows to Linux and the experience, simplicity, speed, stability, etc are much better on linux. I guess of you're working with gui that's a different story. But for .net websites and background servers, simply use docker on linux and never lool back. And it's much simpler than docker for windows too.

rwmj 8y ago

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.

RcouF1uZ4gsC 8y ago
It is very easy on Windows to create a statically linked executable that you can just copy to wherever you want.
- rwmj 8y ago
  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.
  - isostatic 8y ago
    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.
  - zamadatix 8y ago
    Distro packagers do nothing for you if: - Your app isn't licensed in the way you like - 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.
    - isostatic 8y ago
      Fine, build your own package. # dpkg-deb --build ./src/ mydeb.deb Stick your dependencies etc in ./src/DEBIAN/control Or just distribute a tar with your application. I used to have to distribute a cross platform java progam. It was horrendous creating the MSI on windows. The linux and osx versions were trivial
      - MaxBarraclough 8y ago
        Java? Shouldn't that just be JAR + JVM?
        isostatic 8y ago
        Called native executables too, launch icons/shortcuts etc, jvm version detection Deployed by apt/yum/mdm andslme crappy windows thing. The latter was the problem.
  - jwatte 8y ago
    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.)
  - 21 8y ago
    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.
    - tathougies 8y ago
      If you statically link, it doesn't matter what version of glibc is on the target machine, because it's not used.
      - 21 8y ago
        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. https://developers.redhat.com/blog/2016/02/17/upgrading-the-gnu-c-library-within-red-hat-enterprise-linux/ https://developers.redhat.com/blog/2016/02/17/upgrading-the-...
        isostatic 8y ago
        I don't pretend to know a lot about linking files, but I just checked an old static ffmbc binary I had lying around :/tmp$ file ffmbc ffmbc: ELF 64-bit LSB executable, x86-64, version 1 (SYSV), statically linked, for GNU/Linux 2.6.15, BuildID[sha1]=...., stripped :/tmp$ ldd ffmbc not a dynamic executable It runs on the following libc versions: ldd (GNU libc) 2.12 (Centos 6.9) ldd (Ubuntu EGLIBC 2.19-0ubuntu6.14) 2.19 (ubuntu 14.04) ldd (Ubuntu GLIBC 2.23-0ubuntu10) 2.23 (Ubuntu 16.04) I'm fairly sure it ran on distributions as old as ubuntu 8.04
    - Spivak 8y ago
      You're supposed to bundle a fixed version of glibc with your application.
TimJYoung 8y ago
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.
- eikenberry 8y ago
  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.
  - bennofs 8y ago
    Not if you need to communicate with other user space services, such as: * systray icons/application indicators * newer fontconfig versions support new config options which results in fonts being broken for apps that use older versions * I think there is some issue around glibc locales handling if you use a different glibc * systemd/logind/... DBus apis Those were just some external interfaces that came to my mind. I'm sure there are many more.
- tathougies 8y ago
  > 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
  - TimJYoung 8y ago
    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.
AnIdiotOnTheNet 8y ago
> just provide the source and let the distros package it for you. And then sit and scratch your head over why software vendors don't sell a version for your OS.
- rwmj 8y ago
  I work for Red Hat so ... I'm not scratching my head. We sell $3bn+ of operating systems and other software annually.

juliangoldsmith 8y ago

Is your application open source? If so, I wouldn't worry about packaging for every distro. Just make sure that your application isn't difficult to build, and most things (paths, etc.) are configurable. The config path can be handled with a command line switch. Once you've gotten your application so that it can be built easily, I'd only really worry about packaging it for your distro of choice. If people are interested in your application, it'll get packaged for their distros. If your application is proprietary, I wouldn't even worry about packaging it yet. Getting most Linux users on non-essential proprietary software will be an uphill battle.

shock 8y ago

AppImage⁰ seems to be what you're looking for. XARs maybe, but I don't have experience with them to recommend them. ⓪ - https://appimage.org/ https://appimage.org/

jwatte 8y ago

What you want is snapcraft.io

eikenberry 8y ago
IMO AppImage is better for his needs. Snap, like Flatpak, are as much distribution systems as they are packages and they are not widely enough adopted yet to make packaging for each worth it vs just providing the binary to download yourself.

sjellis 8y ago

For desktop applications, Flatpak does this. Otherwise, containers or the new "portable services" feature of systemd. Thanks to systemd, there are standardised ways of doing a lot of things, but yeah, distributions do vary, so you really need an abstraction, or target just a few of the popular distributions.

nvivo 8y ago

I must say as a long time windows developer, .net core on linux is much simpler than on windows. I'm moving everything I have from windows to Linux and the experience, simplicity, speed, stability, etc are much better on linux. I guess of you're working with gui that's a different story. But for .net websites and background servers, simply use docker on linux and never lool back. And it's much simpler than docker for windows too.