5 ms·

Why so?

eberkund 10y ago
You get all the Unix goodness you would get from Linux combined with the commercial polish you're used to from Windows (even more so).
- kxyvr 10y ago
  Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) Certain utilities like gdb will not run because System Integrity Protection disallows them. In theory, we can sign gdb through a somewhat circuitous series of steps, except that this doesn't work if we want to ssh into the box. This requires turning off SIP, modifying some files, and then turning SIP back on. Technically, it's all possible, but it's one series of aggravations after another. Developing on a platform should not be this difficult.
  - danieldk 10y ago
    On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) I use CMake and it's a walk in the park. I just install the dependencies using Homebrew. CMake adds all the necessary include/library flags and builds the application bundle. It's even much easier than Linux, where building a package on the next Ubuntu LTS is always a bit of a drag (updated dependencies, changed library paths, etc.). Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. So, the only reasonable way to compile the application is to get VC++-compiled versions of zlib, libxml, etc. Since everything does not have canonical UNIX paths, you end up a lot of paths manually in CMake. And then you have to deal with things such as VC's standard library not having getopt, etc. For me, macOS is the most comfortable development environment by far. Except that they should put out a Mac Pro with replaceable GPUs again. I use CUDA a lot, so the only practical option is Linux.
    - pawadu 10y ago
      > Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. Seems like the issue is with the particular project you are trying to compile and you are blaming it on the OS. Also, Visual Studio has its own package manager with tons of libraries and tools.
      - danieldk 10y ago
        I am not blaming Windows. It's just that Windows is a mismatch for projects that come from a UNIX tradition. I work in a field where most software is UNIX-first (ML/NLP), so Windows was virtually never a serious option as a development environment. Of course, much of changes now with Windows Subsystem for Linux.
    - kxyvr 10y ago
      I use Homebrew and CMake as well, but it certainly has not been as smooth as my CMake scripts contain a series of fixes for MacOS. I also like CPack, but there's been less consistency with MacOS. Bundles don't work for multilanguage libraries since things like mex files can't be packaged as a framework. PackageMaker was deprecated since Yosemite. OSXX11 is really X11 specific. DragNDrop sort of works, but it can't run any post install scripts to do things like set environment variables, which, again, the process for doing so changes from release to release and whether or not we're on the console. Conversely, the WIX generator on Windows allows me to package everything as I need it to. Though less nice, NSIS also works well. Certainly, that's not to say that everything is rosy and cherry on Windows. I just did a cold build from scratch on a new Windows license and it honestly went as well as it did because I know exactly which tools to get. Mostly, it's that after banging my head against both the Windows and MacOS ecosystems, I can build a new development system vastly faster on Windows and have few headaches. As a quick note, thank god for the Homebrew crew as that does make things much nicer. As a final note, some of these headaches would immediately disappear if I could virtualize MacOS since it would fix the console login vs desktop login problems. Also, I could actually fix problems when working on an airplane.
  - vetinari 10y ago
    I usually avoid MinGW, because it links your binaries agains msvcrt.dll. It really shouldn't do it - https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...
    - kxyvr 10y ago
      I haven't tried in awhile, but is the best option just to use VC directly at this point?
      - vetinari 10y ago
        Probably yes, but on the other hand, VC is incapable of building some FOSS packages (xz comes to mind).
      - tavert 10y ago
        If everything is using cmake, and you don't need any inline assembly or fortran for scientific code, then maybe. But you end up in a parallel universe where everything that touches MSVC is just needlessly different than every other platform. If mingw gcc is working for you, then it's much easier for dev skills to transfer between building for Windows and building for unix. If you do need inline assembly and/or Fortran (LAPACK anyone?) then it's easiest to pretend visual studio doesn't exist.
        kxyvr 10y ago
        Well, and that's the trick. Originally, I shied away from VC because I link into LAPACK. Even if I hook into a precompiled library from a manufacturer, they use the same name mangling scheme as Fortran. In order to figure that out, both autotools and CMake compile a small Fortran program and check, which means that I need a Fortran compiler. Technically, I could set a macro to the name mangling by hand since there's only four possibilities, but it's a little irritating. I suppose that I could use VC for the C++ pieces and gfortran for the Fortran pieces, but it's always been easier just to use MinGW.
- pimeys 10y ago
  For me "all the Unix goodness" is a proper package manager, an environment I can modify as much as I want and nowadays too an environment that doesn't have yearly big updates, but a rolling release. My desktop has stayed exactly the same[0] for almost seven years already. My configs follow me from job to job and from computer to computer. I don't want or need changes, just an editor and a proper *nix kind of operating system and no changes ever how things look or work. [0] http://i.imgur.com/aMHU8vu.png http://i.imgur.com/aMHU8vu.png
  - prewett 10y ago
    > rolling release That pretty much limits you to Debian unstable... Or Windows, if forcibly upgrading counts as "rolling." But wouldn't a rolling release be the exact opposite of what you'd want if you want no changes, ever? And if that's the case, just don't upgrade macOS until Xcode forces you to, that usually gives you a few years. I stayed on Snow Leopard for years until Apple put a gun to my head, but Mavericks and Yosemite gave me no problems; everything worked just like it did before. (I still miss Snow Leopard, though...)
    - pritambaral 10y ago
      Debian Unstable isn't the only rolling release distro. Another popular one I can think of Arch Linux. Typically, changes in rolling releases are easier to deal with. At any time, the change is smaller, so you don't have to be overwhelmed by a large number of changes all over the place, as is sometimes the case with versioned releases; and the changes are fresher, so your inputs to the developers who made the change are easier to apply.
      - pimeys 10y ago
        Exactly. And when your installation is quite minimal, there's a very small change the updates will mess anything up. My arch installation has been running without problems for years because I don't have any massive desktop environments installed and all the development services I need are launched through docker.
  - 10y ago

Why so?

You get all the Unix goodness you would get from Linux combined with the commercial polish you're used to from Windows (even more so).

kxyvr 10y ago
Paradoxically, I find it easier to port applications to Windows than MacOS. Due to the efforts from the Cygwin and MSYS groups, just about every build script ports naturally to Windows. As long as I use MinGW, the resulting application is native and can be distributed. On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) Certain utilities like gdb will not run because System Integrity Protection disallows them. In theory, we can sign gdb through a somewhat circuitous series of steps, except that this doesn't work if we want to ssh into the box. This requires turning off SIP, modifying some files, and then turning SIP back on. Technically, it's all possible, but it's one series of aggravations after another. Developing on a platform should not be this difficult.
- danieldk 10y ago
  On MacOS, there's a bunch of quirks that make it harder to port. Environment variables are different enough to require duplication in scripts (DYLD_LIBRARY_PATH instead of LD_LIBRARY_PATH, unless we need DYLD_FALLBACK_LIBRARY_PATH.) I use CMake and it's a walk in the park. I just install the dependencies using Homebrew. CMake adds all the necessary include/library flags and builds the application bundle. It's even much easier than Linux, where building a package on the next Ubuntu LTS is always a bit of a drag (updated dependencies, changed library paths, etc.). Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. So, the only reasonable way to compile the application is to get VC++-compiled versions of zlib, libxml, etc. Since everything does not have canonical UNIX paths, you end up a lot of paths manually in CMake. And then you have to deal with things such as VC's standard library not having getopt, etc. For me, macOS is the most comfortable development environment by far. Except that they should put out a Mac Pro with replaceable GPUs again. I use CUDA a lot, so the only practical option is Linux.
  - pawadu 10y ago
    > Windows, in contrast, has been hell. Some of the dependencies of one particular project only compile with Visual Studio on Windows, not Cygwin/MingW. Seems like the issue is with the particular project you are trying to compile and you are blaming it on the OS. Also, Visual Studio has its own package manager with tons of libraries and tools.
    - danieldk 10y ago
      I am not blaming Windows. It's just that Windows is a mismatch for projects that come from a UNIX tradition. I work in a field where most software is UNIX-first (ML/NLP), so Windows was virtually never a serious option as a development environment. Of course, much of changes now with Windows Subsystem for Linux.
  - kxyvr 10y ago
    I use Homebrew and CMake as well, but it certainly has not been as smooth as my CMake scripts contain a series of fixes for MacOS. I also like CPack, but there's been less consistency with MacOS. Bundles don't work for multilanguage libraries since things like mex files can't be packaged as a framework. PackageMaker was deprecated since Yosemite. OSXX11 is really X11 specific. DragNDrop sort of works, but it can't run any post install scripts to do things like set environment variables, which, again, the process for doing so changes from release to release and whether or not we're on the console. Conversely, the WIX generator on Windows allows me to package everything as I need it to. Though less nice, NSIS also works well. Certainly, that's not to say that everything is rosy and cherry on Windows. I just did a cold build from scratch on a new Windows license and it honestly went as well as it did because I know exactly which tools to get. Mostly, it's that after banging my head against both the Windows and MacOS ecosystems, I can build a new development system vastly faster on Windows and have few headaches. As a quick note, thank god for the Homebrew crew as that does make things much nicer. As a final note, some of these headaches would immediately disappear if I could virtualize MacOS since it would fix the console login vs desktop login problems. Also, I could actually fix problems when working on an airplane.
- vetinari 10y ago
  I usually avoid MinGW, because it links your binaries agains msvcrt.dll. It really shouldn't do it - https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=1273 https://blogs.msdn.microsoft.com/oldnewthing/20140411-00/?p=...
  - kxyvr 10y ago
    I haven't tried in awhile, but is the best option just to use VC directly at this point?
    - vetinari 10y ago
      Probably yes, but on the other hand, VC is incapable of building some FOSS packages (xz comes to mind).
    - tavert 10y ago
      If everything is using cmake, and you don't need any inline assembly or fortran for scientific code, then maybe. But you end up in a parallel universe where everything that touches MSVC is just needlessly different than every other platform. If mingw gcc is working for you, then it's much easier for dev skills to transfer between building for Windows and building for unix. If you do need inline assembly and/or Fortran (LAPACK anyone?) then it's easiest to pretend visual studio doesn't exist.
      - kxyvr 10y ago
        Well, and that's the trick. Originally, I shied away from VC because I link into LAPACK. Even if I hook into a precompiled library from a manufacturer, they use the same name mangling scheme as Fortran. In order to figure that out, both autotools and CMake compile a small Fortran program and check, which means that I need a Fortran compiler. Technically, I could set a macro to the name mangling by hand since there's only four possibilities, but it's a little irritating. I suppose that I could use VC for the C++ pieces and gfortran for the Fortran pieces, but it's always been easier just to use MinGW.
pimeys 10y ago
For me "all the Unix goodness" is a proper package manager, an environment I can modify as much as I want and nowadays too an environment that doesn't have yearly big updates, but a rolling release. My desktop has stayed exactly the same[0] for almost seven years already. My configs follow me from job to job and from computer to computer. I don't want or need changes, just an editor and a proper *nix kind of operating system and no changes ever how things look or work. [0] http://i.imgur.com/aMHU8vu.png http://i.imgur.com/aMHU8vu.png
- prewett 10y ago
  > rolling release That pretty much limits you to Debian unstable... Or Windows, if forcibly upgrading counts as "rolling." But wouldn't a rolling release be the exact opposite of what you'd want if you want no changes, ever? And if that's the case, just don't upgrade macOS until Xcode forces you to, that usually gives you a few years. I stayed on Snow Leopard for years until Apple put a gun to my head, but Mavericks and Yosemite gave me no problems; everything worked just like it did before. (I still miss Snow Leopard, though...)
  - pritambaral 10y ago
    Debian Unstable isn't the only rolling release distro. Another popular one I can think of Arch Linux. Typically, changes in rolling releases are easier to deal with. At any time, the change is smaller, so you don't have to be overwhelmed by a large number of changes all over the place, as is sometimes the case with versioned releases; and the changes are fresher, so your inputs to the developers who made the change are easier to apply.
    - pimeys 10y ago
      Exactly. And when your installation is quite minimal, there's a very small change the updates will mess anything up. My arch installation has been running without problems for years because I don't have any massive desktop environments installed and all the development services I need are launched through docker.
- 10y ago