Monday, February 22, 2010

The Problem with FOSS Software on an FOSS Operating System

Earlier this evening I was cruising through the latest additions on (Linux gaming website) when I stumbled across JVGS. Its a nifty little platform based game that is loosely based on XKCD webcomic.

Its a newer game so it wasn't in the Ubuntu repositories yet. Not a problem, I've compiled more than my share of programs from source before. I download the source code in your standard .tar.gz package format, extract the contents, and open the README file in gedit. Fairly straight forward compile, grab the listed dependencies using apt-get, run cmake, and then make to build the package.

JVGS is not a graphically heavy game, I wanted to install it on my netbook to kill some time in-between my classes at school. I figured it would take a short bit to compile on my little Atom chip, so I run the make command and head off to do some other work for a little while. Ten minutes later I return to my netbook screen to see the compile has failed with several error messages.


I really just wanted to try the game, see if it was worth even playing. I was at work (where the computer all run Windows Xp) so I decided to download the Windows package for the game on my work system. Download the zip file, extract the folder, double click the jvgs.exe and poof! Lo-and-behold the game just runs. No complaints, no compile errors -

It just works.

Now I am sure I can debug the error the compiler is throwing on my Ubuntu system and get it working eventually - but this is my point:

Why should I have too?

Why should installing/using a piece of open source software be more painful on a open source operating system then it is on a proprietary operating system? Am I asking for too much here to want an equally easy install experience on Linux for FOSS software as I enjoy on Windows? If Linux is ever to gain any sort of real market share in the desktop market I feel this is some thing that must happen.

But maybe I am wrong. What do you think?

~Jeff Hoogland

I'm going to add this on here since it appears many people have missed my main point here which is simply this: Why is it that FOSS developers tend to compile Windows binaries but they rarely (if ever) compile Linux binaries (.rpm, .deb, .bin, I'll take any of the above)? I understand that this is fully the developer's responsibility, but as I said before it seems to be a common trend. Also I'd like to mention I am in no way saying having to compile from source bad I am simply saying it should not be the only install option for Unix operating systems.


  1. The problem is with the devs who haven't provided a working package. This is easy and trivial for most projects and can generally be automated.
    Beyond that, compiling for a single target is much easier.

  2. besides the comment about people supplying packages as well as windows installers and src. What did you think would happen when you ran the compile most likely not having all the dependancies? When you go to compile anything, always assume it will most likely be a pain in the ass.

  3. You're getting a free piece of software. This software is at a version below v1, so do not expect the developers to spend a lot of time on packaging.

    This being free software, you can package it yourself and contribute it. Probably would've taken shorter time than writing this article...

  4. The problem of providing pre-built Linux applications is that you need to use an older glibc/libstdc++ to link to in order to make sure it works with all newer distros.

    Most people are not willing to take the time to do something as annoying as that, so quite often, Linux apps are only available in source code form.

    On Windows, multiple versions of the C/C++ CRT are available by default, and MinGW currently targets the oldest version of the CRT to ensure maximum compatibility.

  5. It makes me wonder -- why can't SourceForge (or something like it) provide a suite of tools for automatically building packages and releasing compiled versions targeted for various GNU/Linuxes? That way, all you'd have to do is commit the latest versions to the repository, hit the "Build" button, and within half an hour binary packages are available to download in .deb, .rpm, etc.

  6. @Pharaoh Atem
    It's called static compiling, while generally a bad practice if you're compiling something for just your system or for a distribution package, it works very well when you're distributing a tarball with a binary in it. Anyway before compiling something you should always look at the build dependencies, on Debian based systems if you want to compile software that's in the source repo's, you can just run apt get build-dep. The problem isn't with the lack of a unified install system, there are plenty of ways to make one package or installation script for every distribution, it's with the distributes not providing pre-build packages. Also you'd be surprised how fast many software packages compile on underpowered hardware, it's mostly just more complex stuff like ffmpeg that will take a while. Anyway part of the problem may be the OS, I found Ubuntu horridly slow on hardware more powerful than an atom's, due to the unnecessary gtk libs included, slower than a fresh install of xp even, that's a lot of the reason I usually use Debian or Arch Linux. (I'm using Arch Linux now, a recent dist-upgrade to the 2.6.32 kernel in debian testing broke a bunch of stuff, including fan speed control, there was a command line switch for the kernel that was supposed to fix it but it didn't, the driver used with the 2.6.32 kernel doesn't support fan speed control for my asus p7p55d le unfortunately, so I thought if I had to deal with that, I might as well switch to something more stable and with fewer problems, I was having a bunch of trouble with debian then.)

  7. I expect that if the Windows version was offered as source only, you would not have had a good experience there either.

    The problem is not Linux, but instead, not offering compiled packages.

    Look at it another way. Linux has good enough compilers that are readily available enough that it actually is possible to distribute it as source or compiled. That is one win for Linux, and one loss for Linux software distributors.

    Ideally, we would see a .deb, a .rpm, and source.

  8. At least with Linux you get source packages if there's no binary, with Windows if a package is Vista / Win 7 only and you have XP you can't recompile. The other way round may work, to a degree.

    Generally it's better to wait for a binary or just compile, it's usually not that hard to install dependencies unless you get problems with different versions of libraries like libc6

  9. I do know what you mean!

    When I was trying out MakeHuman (a FOSS editor for creating human 3D mesh models) and needed the Aqsis renderer to run it native, I battled all day with *gigabytes* worth of compiling code that I failed to get running anyway. The Windows binary was about 6 MB, installed in a minute with Wine, and runs to this day with no sweat.

    When I told this story on my blog, the original Aqsis developer showed up to say basically that Windows compatibility was their primary concern, end of line!

    Part of this was due to a dependency on Boost and that it is done in C++, of course. I'm sorry, but when your program has to spend *all* *day* compiling *one* library, you have not only reinvented the wheel, but re-defined the atomic bonds of every atom of matter in the universe, and it's a surprise that you didn't reinvent binary as well.

  10. Thank you, thank you for your post!!
    I have been saying this ever since I began my journey into learning Linux in 2005.

  11. Easy enough to instal for Archers. It's in the AUR.

  12. If you are compiling firefox or openoffice or downloading the packages for them from the source site and not expecting some manual configuration then one has to ask "Why are you compiling anything or downloading from the source sites?". Every single decent distribution out there has firefox, thunderbird, seamonkey, openoffice, dozens or hundreds of games, etc etc just as easy to install or quite frankly easier just by going into their Add/Remove Software tools and using them. Fedora (System->Administration->Add/Remove Software. If you want a fair comparison then try this... Try downloading the source for anything and compile it on a typical Windows box (or even OSX for that matter). Good luck without MASSIVE configuration issues and a complete lack of a compiler that itself isnt some obscure installation routine. When you compare any two distinct systems you have to at least try to make the comparison on some level of equivalency. Next time be familiar with the system, use its tools and then make a judgement.

  13. Some heretical (sensible, natch) thoughts on static compilation:

  14. Even if there was an .rpm file or a .deb file, we're not sure where it would install. Is that .rpm for Fedora? Red Hat 7? Red Hat Enterprise 5? is the .deb for Debian as it should be, or for the *buntu distros that break package formats with each release? (*buntu needs their own packages, call them .ubu, it would still work with aptitude etc and save everyone headaches that rpm has developed).

    The software is Free, so people mix and match it to their heart's content, creating incompatible distros because they want it to work one way, while others want the software to work another way. This is a part of that Freedom in Free Software, but it doesn't make it any easier.

    LSB was hoping to fix that but no one can agree on what the LSB standards should be. Until there is One Distro (please make it Debian), we all have these problems together.

  15. Sounds like classic "Waah, I want, I want!" even when your skill level isn't near sufficient enough to compile extremely unfinished software.

    Try this. If there isn't a native binary and the software doesn't compile, the software simply doesn't exist. Saves a lot of whining and headaches.

    Come back and visit when the project has released something that is worth your time.

    Blathering that there is a Windows binary and therefore it should be the same on Linux will do you as much good as complaining that iWorks doesn't run on Windows 7.

  16. I think many commenters are missing the point. In the IDEAL (which is what we should be striving for) FOSS world, all software is delivered in tarballs and can be auto-compiled without configuration. Without debate, we are not there yet. And the question is what are the best steps to take to get there?
    Is it developer's responsibility to give magical universal source packages (Granted, this is not necessary for Pre-Beta software)? Is it the user's responsibility to know how to configure all software in the world (Obviously no, it isn't the responsibilty of the average car driver to know how to fix a broken transmission)? The greatest strength and the greatest weakness of the FOSS world is it's heterogeneity (i.e. The Bazaar). I vote for a Gobolinux + .deb package support.

  17. @Robert - Thank you for seeing my point here :)

    Also, I love the idea behind Gobolinux however I must admit I have yet to play with it at any length thus far.

  18. Installing this game in Ubuntu GNU/Linux could be made very simple if the developer would provide it in .deb package format. We could ask him to do that.. but perhaps the dev doesn't use a Debian based GNU/Linux! Maybe he uses an RPM based, or even a self-built version (e.g., LFS). Simply put, the developer provides the bare essentials of what you need to enjoy his work, for free!

    I don't think this makes windows better... in fact I think it shows just how much more powerful and awesome GNU/Linux is.

    So now we just need the developer or someone else to contribute the work required to build a .deb package with the jvgs game to make it easy to install in Ubuntu GNU/Linux.

    I plan to learn how to do this myself, but in the meantime...

    Here's how to make it work, starting from LiveCD Ubuntu 9.10 GNU/Linux installion:

    #Install the required dependencies for compiling jvsg from source
    sudo apt-get install build-essential cmake swig libfreetype6-dev zlib1g-dev liblua5.1-0-dev libsdl-mixer1.2-dev libsdl1.2-dev

    #Download jvgs

    #Extract the archive and cd into the created directory
    tar xvf jvgs-0.5-src.tar.gz
    cd jvgs-0.5-src

    #Run cmake, check for errors
    cmake .

    #Run make

    #Play the game in Fullscreen mode according to README.markdown


    #Play the game in windowed mode
    ./src/jvgs main.lua --width 800 --height 600

    #JVGS will remember the most recent video mode, to put in fullscreen again
    ./src/jvgs main.lua --fullscreen yes

    Humans enabled with GNU/Linux - that's what GNU/Linux is all about!

    Shannon VanWagner

  19. I did end up building and installing jvgs on my netbook yesterday actually.

    I guess the real point my post is this: Why does it seem that those who develop FOSS software tend to compile the Windows binaries but they almost never compile and Linux binaries? Seriously, .rpm, .deb, .bin, I'll take any of the above. It just seems to be a trend that FOSS developers compile their software for Windows but not any Linux distros...

  20. This comment has been removed by the author.

  21. I agree with your point to some extent, in terms of how it would be nice if FOSS software more often included pre-made distro-specific installers. That would be nice.

    But often times, I think the developers of FOSS may be using a different GNU/Linux distro than one might expect (Arch Linux for instance), and so it creates a lot of extra work for the developer to make distro-specific installers.

    In that regard, I don't blame the developer for not using his own time to serve the needs of each and every distro. After all, the program is open source, and installable with free tools... why should a developer use his precious time to cater to specific distros.

    What I'm saying is let someone else build a .deb package to install the JVGS game, and have them share it with the game author. I'm quite certain that he will be willing to share it, just as he/she is already sharing their work.

    So is there anyone out there who would be willing to build a .deb(/any-other-distro-specific) package for this? If so, chime in.

    Shannon VanWagner

  22. Not to descract from the point of the blog, which I agree with, but this is pretty easy to get going.

    It is the responsibility of a software distributor to include proper documentation. Source code gives power, binarys give ease. This program dscided not to build for any linux binaries, which takes away the ease, but we still have the power. In this case, they gave a document with all the depenancies, which I found easily in synaptic. Only liblua_dev is missing from that document, and adding it gave me the program.

  23. As a long term Linux user, I couldn't agree with your point more. It is frustrating to find an application which sounds interesting and then to have to do lots of boring manual work to compile it just to see if it works or not. I believe the situation is better on Windows because Microsoft places great importance on backwards compatibility (and doesn't update so often). If I understand correctly Solaris also prides itself on binary compatibility for much older versions.

    I dislike the argument that it's "the developers fault" for not spending hours of their time creating binary packages for every version of every distro. Surely they should be spending their precious time improving the application itself? Suse's build service sounds like a nice solution (it automatically creates binaries for a large selection of distros) although I believe it still takes a large amount of time to set up initially.

    To my mind there should be a software solution which takes the pain out of creating a single package for all platforms and for installing that package, without compromising the host system. It should also be possible to easily go back to an earlier version if something went wrong. It should also be possible to install new software by clicking on a link on a website, and for a non-admin user to install software without compromising the system.

    The good news is that such systems exist, although they have not been widely adopted yet. I have been happily using the nix package manager (part of nixos ... on top of Debian stable to easily install new versions of software that hasn't made it into Debian backports. It doesn't yet have every package I would like, but I hope to learn how it works and contribute too. The other one I'm aware of is gobolinux (as already mentioned) which also has all of the above features, and does some other nice things too. I chose nix over gobolinux just because the packages were fresher at the time.

    As a concrete example: one package I would like to install is the latest Kdenlive video editor. There are packages available for more recent distro releases but the instructions for compiling on Debian require running Debian unstable to get the relevant development libraries. The other alternative offered is a virtualbox image or live cd. I much prefer the developers to continue working on improving the software than trying to make binary packages for everyone, but this is the situation we are in. Sadly, Kdenlive isn't currently available as a Gobolinux or Nix package.

    For those who think that the solution is to upgrade your system every 6 months (Hey, it's not like it costs anything!) I disagree. I have gone through this cycle many times already and got tired of fixing things which broke with. I reckon I spent about 5 full days every 6 months fixing things after the upgrade, which is more time than I want to spend.

    I would really like a stable system on which I can easily and safely upgrade any parts that I care about, and install new software without breaking things that work perfectly well already. Why most people seem to be satisfied with rpm/deb/arch/configure && make && checkinstall etc. I just don't understand.

  24. This comment has been removed by the author.

  25. Here's the applicable portion of the response I received from the Author of jvgs - Jasper Van der Jeugt at
    Hey Shannon,

    I'm an Archlinux user myself, but I'm not that into packaging (frankly said, I find it a boring and annoying task). Nevertheless, it needs to happen. I will put the Ubuntu dependencies in the README, since Ubuntu is probably the most popular linux distribution anyway. The thing is that JVGS can never sit in the Ubuntu repositories, because the music falls under a creative commons license which does not allow commercial uses - this is against the Ubuntu guidelines. However, it would be perfectly okay to create a deb that is downloadable from the site, and I also think this would be a good thing. If you know a debian packager who's interested, be sure to let me know :-)

    Kind regards,
    Jasper Van der Jeugt

    So it seems that Jasper has a very good reason indeed to not have his software be the Ubuntu repositories. Jasper also recognizes the value of having a .deb package. The invitation is open at this point. If someone would be willing to build a quality .deb package for this cool game, not for Ubuntu repositories, but to be available at Jasper's site - sounds like it would help make things easier for others.

    This is why we need a program in Ubuntu, perhaps the Software Center that we can just feed a source package and have it spit out a working program, complete with start shortcuts and all... lol

    Shannon VanWagner

  26. Jeez.. I really do need to use the "review your post" opportunity when posting to this site. If I could clear the chaff, I would. lol

  27. They tend to compile Windows Binaries because that is what the rest of the masses tend to use. Sorry to break it to you but until Linux starts standardizing their shit it is NOT going to replace Windows on the Desktop. I believe that Linux right now has way to many people doing their own distros that it makes it hard to get anything done without mass complications.

    When you have programmer A and programmer B working on their own distros separately one programmer might prefer an older version of a package while the other one may use the latest and greatest. See where the problem lies? As many issues as Windows has it is pretty consistent across versions and platforms. I never had to go "Oh crap my x64 Windows program won't work on my x86 Windows platform". It's almost not an issue now.

    Bottom line is that Linux is a server OS and still just a hobby OS on the desktop platform.

  28. Linux on desktop isn't that much bad, you just have to do some custom compiling here and there. This is a problem that comes with the freedom it offers(put down this or 'standardize' this and the whole Freedom thing goes down too)

    Linux is meant to be changing and it'll be, as a (new)user you'll have to expect challenges like this. Even though Linux is being getting recognized everywhere now, you'll have to respect the fact that Linux is not what the developers are targeting(even when they develop in Linux). Even though we think that Linux is an OS it is not it is just the Kernel, the OS really is the distribution. Things do change between them but not much.

    Being not STANDARD is whats called freedom to customize from a different perspective, they have the FREEDOM to change you have the FREEDOM to use it and here we have different flavors of the same system everywhere, this is not a bad thing dont blame that. It is the sense of standardization you are lacking, if you are eager to compile programs from source DO NOT ever expect it to build without errors! This is not about beta or alpha software it is true to some stable releases of source too. So main thing is to get hold of it(compiling, dependency hell:D) and if you can not just wait for a stable release :) or you can always use Windows, its not dead nor you should try to be 100% Linux when you really have to learn a hell of a lot too. Just give it sometime there are tools for almost everything these days..