Swaroop C H

blog books about contact subscribe

Closed source on Linux is hard

22 Oct 2007

Update: Please read the article carefully before commenting. If you notice, most of the problems being described here is part of Eclipse, which is open source. So, usability issues are faced by open source programs as well, and not just proprietary programs on Linux. The reason I wrote that title was because this pain is usually felt by people who are making closed source packages that works on different Linux distributions. The real issue is about unneeded incompatibilities between different Linux distributions.



After working on the porting project to make Flex Builder run on Linux, I am starting to see why closed source software on Linux is hard.

There are just a handful of closed source products on Linux (counting only the famous ones) - Opera, Skype, Nero, Acrobat Reader, and Flash Player. Hmmm, I can think of just 5.

Why is that important at all? Because software developers who are not initiated to the FOSS philosophy will be scared off the platform because of its inherent complexities. For example, in this project, getting the software to run on the various Linux distros was, to put it lightly, troublesome.

There are a number of issues that we faced, which I'm certain is the reason others don't want to get into this as well.

Let's start with Eclipse. Eclipse runs fairly well on different platforms (let's ignore the memory-hogging issue here), but on Linux, it's a different ballgame. Somehow, the polishing of the UI is markedly lacking. Yes, we've filed bugs, but turns out it's not really Eclipse's fault, it's simply because different window managers work differently on Linux, and handling all of this is a nightmare.

Oh, and this gets better when it comes to distros. For example, the latest released Eclipse 3.3 won't run on the latest released Fedora version. You have to wait till Fedora 8! Because of this, we had to drop support for Fedora, and instead concentrated on other distros such as Suse, Red Hat and Ubuntu.

That brings up another problem - the number of distros. The QA effort required for the Flex Builder (FB) on Linux project was huge indeed. And yes, we found problems that occurred only on Red Hat but not on Ubuntu, and so on. For example, clicking on help links in Eclipse on Red Hat opens a new window every time whereas it properly displays in the same window on Ubuntu. Again, it's not really Eclipse's fault. Go figure.

Then, there's the issue of running Firefox. There's nothing wrong with Firefox itself, but what's with each distro trying to customize the Firefox startup script?! FB on Linux has to check whether the correct version of the Flash Player plugin is installed in the browser, and checking this is a long procedure - do we check in ~/.firefox/plugins/ directory or ~/.mozilla/plugins/ or $MOZ_PLUGIN_PATH or some Suse-distro-specific directory such as /usr/lib/browser-plugins/!

Life is simply too hard compared to other operating systems.

Isn't it a wonder that nobody wants to develop a closed source product for Linux? Even Microsoft is just handing over the audio video codecs to Novell and letting them to do the hard work of creating Moonlight on Linux. Microsoft is smart enough not to try to maintain a Linux version of Silverlight on its own (I'm considering only technical issues, let's set aside philosophical issues on this one).

If we really want to make Linux a good platform, then we need to stop messing around with the basics - at least please don't muck up the basic shell scripts and paths.

The way to get more people, in large numbers, to understand the open source and free software philosophies is by making their first steps easy. It cannot be an all-or-nothing approach. Closed source software on Linux is not practical. And that's a bad thing because if we can't convert software developers to use a different platform, how can we expect mom and pop to switch to Linux?

In spite of all this, I think we've done a good job of FB on Linux, and happy to see all the great response we've seen so far, including reports of success on various distros that we've never even heard before. So please keep the feedback coming!

Standard disclaimer: The opinions expressed here are my own, not Adobe's.

Comments

Devdas Bhagat says:

The standard solution to this is to let the distribution makers do that work. "This is the binary, these are it's dependencies, you figure out how to package it for your platform."

Alternatively, don't ship your product as a closed source one.

Mike, but wasn't the problem there that the accounting package was closed source and you couldn't port it to any other Unix?

Oh, and you missed out a few other major apps there. Websphere, Oracle, ...

Rob T says:

//This is, once again, related to my previous comment - the UNIX source-code ownership and the OSS paradigm are very good for business, that is - businesses that own and deploy many computer systems that can all run a system that can be completely customised for the business or for each intended task, and do not wish to be tied to a single supplier, to whom their survival is inevitably tied.//

Nick, let's say I build houses for a living. 500 years ago I had to know not only how to build houses, but also how to make hammers, saws, nails, etc... How many houses could I build?.. how well do you think they were constructed?

I want to build houses, not make hammers...

Ugh.

Nico says:

Hello Swaroop, very interesting article, thank you. I can't help thinking that closed-source companies that make those programs that you cited are in a privileged position to help solve the problem.

If having a lot of incompatible distributions makes things difficult, having a lot of incompatible ways of overcoming this obstacle doesn't help either.

Since these companies know best than anyone (through painful experience) what could be done to make binaries that are compatible with several (and moving target) distributions, they could share their methods to get a uniform interface. And since you work for one of them, you might pass along this suggestion. That would ease the work for your future projects and for others trying to create programs for Linux. That would add value to your Linux efforts.

JavaScript is known to have a similar problem with different browsers. There are JS libraries that layer a high-level interface over the different incompatible ways of doing something. I think that something alike could be done for binary distributions: create a stable, versionable, linkable library that acts as an interface to changing libraries.

Daeng Bo says:

@Nick

No only is the Unix set up not portable-binary-friendly, the standard executable format (ELF) easily breaks based on differences in the kernel. The program could fail to run because it doesn't find the files it expects, or it could just core dump.

While businessmen may scream at this, it keeps the spread of viruses and worms to virtually zero.

Go figure says:

Primairly GNU/LINUX is about choice. What you are complaining about is just that: because different distro's do things differently, it's difficult to give support for all of them. Well welcome to freedom land. Sure it would be much simpler if every distro did everything the same (you have any idea many different directory structures there are?) but what would be the point of this? You would just limit everyone to what YOU or some other developer THINKS is best. What is best for you might not necessarily be best for me or a million of other users.

So if your complaint is that there is too much freedom within the Linux development, then I have to disagree. If your complaint is that it's just too hard then we're talking about something completly different and I hardly think that's the Linux developers fault...

Pádraig Brady says:

This is not Linux' fault, it's a fault with all closed source programs. You will have much the same issues getting a program running on all the flavours of windows for example. I.E. the API is much easier to maintain than the ABI, or in other words source compatibility is easier to maintain than binary compatibility.

I've summarised Linux binary compatibility issues here:
http://www.pixelbeat.org/programming/linux_binary_compatibility.html

CJ Silver says:

I think what the distros themselves do is their own problem. I am a slightly above average linux user (or at least I'd like to think so). I build a lot of software from source because there are plenty of times repositories don't have quite the right versions of things, or programs are linked to incompatible library versions. Compiling from source lets me pick where everything's going to go, what it's going to link against, and change any other particular compile-time options. Generally speaking, Mom and Pop changing to linux doesn't make any difference to me at all. Having more extensive commercial support is not really beneficial to me in particular. I'm sure there are business users that would benefit from having some software ported to linux. These businesses are using RedHat and SuSE. Target them.

Maintaining binary compatibility is not something the linux community at large is interested in doing. Linux is free. People can download it for free. People can use it for free. Nobody gets money for getting people to use linux or from using linux. So, there's no financial reason to attempt to make more people use linux in the first place. In the second place, maintaining binary compatibility invites companies to create binary blobs that we then must interface with that are beyond our visibility. The bugs contained in those binary blobs are not bugs we can fix. The energy spent working around these bugs would be better spent on just developing open software to begin with. The people that do the packaging for distros and deployment are generally volunteers that are similar to myself. They have no incentive to work with your package at all.

You make valid points, but nobody in the linux community really cares about them because improving the things you would like to see improved offers no benefit for the community.

Tired of the same says:

After reading the blog entry, I already knew what to expect in the comments: Linux defenders climbing the barricades and blaming the developer for not releasing it free/open source.

If Linux is ever to be a real competitor to Windows environment, developers must have the option of making closed source software. Expecting to get everything for free is just naive.

For a long time I have also wondered, why is it that so many people talk of "Linux" as one simple environment, when it is not the case. The problems you describe in your blog are real and they will not disappear until the developers of various linux distroes start working together.

BramDeStutter says:

[...]Primairly GNU/LINUX is about choice. What you are complaining about is just that: because different distro’s do things differently, it’s difficult to give support for all of them. Well welcome to freedom land. Sure it would be much simpler if every distro did everything the same (you have any idea many different directory structures there are?) but what would be the point of this?[...]

You should really read some articles on the benefit of standardization. The fact that every Linux distro has a different directory structure brings no benefits. So why not standardize that? Things like that do not have to do with 'freedom of choice'. Why did we introduce XML? Was the old way where every settings file or document was structured entirely different better because there was more choice? Should we stop efforts to standardize the OpenDocument format because it was more fun when every word processor had its own incompatible format?

James Ward says:

I think the best way around this is to do what the Flash Player team did with flashsupport

I would pick the top two distros (Ubuntu and Redhat). Certify on those and make sure that anything that could break or be different on the other ones follows a tactic like flashsupport.

BTW: Your blog title makes it seem as though you have given up on FB for Linux. I'm sure that's not the case so you may want to re-evaluate the title you used here.

BTW2: When I hit the subscribe button below I received a 404 error.

-James

Developing For Linux | iface thoughts says:

[...] has an interesting post why developing closed source applications can be difficult on Linux. A Linux distribution is like an assembly of various components, and each of them has alternatives, [...]

Swaroop says:

@James: Interesting, I'll read about flashsupport. Point taken, I've changed the title to make it more suitable to what I am talking about. Oops, the 404 is because I deleted that file in the last WP upgrade.

@Shaun: Because you would want as many people to use the product as possible, and Linux is already a small market share as it is.

@Mike: :)

shaun says:

Why not just pick one distro and support that only?
Ubuntu or Fedora would be reasonable choices as they
seem to be the distros often touted as "mainstream linux".

Many software companies that support Linux do this,
personally i think its reasonable approach. Eg.

"We support flex dev tools running on Windows, OS X and
Ubuntu Linux."

Easy.

If a software developer is not able to figure out how to
customize a couple shell scripts to get FB running on there chosen version of Linux, well, thats there problem.

IMO software developers should be considered more savvy than "Average Joe end-user" and if they are not then they should probably find another profession.

Developers should be able to perform basic maintenance
and updates on shell scripts if they are going to use
Linux - otherwise they should stick to using windows, or better yet go and work in the local fish and chip shop.

Mike Rankin says:

So it's the same issue we had with all the *nix flavors we had 25 years ago. I remember working with a version of unix that would only run ONE program and that was an accounting package for construction companies. You had to buy different computers to run anything else. I'd go into a company as a consultant and see two computers on every accountants desk. I remember thinking to myself, "what's wrong with this picture?"

Devdas Bhagat says:

Tired of the same, they do have the choice of writing closed source. They should just be willing to pay the additional maintainance costs of not being able to integrate into the distros by default.

Given that flash doesn't work on my hardware anyway, I don't especially care about Flex. It's just the whole "difficult to support bit" I have an issue with.

SHE, the point is that if anyone is interested in maintaining the package on that platform, they will do all the hard work of packaging it.

falcon says:

So you suggest that the biggest problem with GNU/Linux is that it is hard to port proprietary software to it? Make your software free, and the distro people will take a share of the work. I agree there is a lot of effort involved in supporting all these many platforms, and that there may be a better way, but not being able to port proprietary software is not a problem. The whole point the the GNU/Linux is to get away from proprietary software.

Now, you are certainly within your rigths in making proprietary software for GNU/linux. But Duh! Yes, of course, the free software world is not a place overly friendly to proprietary software. That's the whole point.

Pradeep says:

Some more comments here: http://programming.reddit.com/info/5ytjj/comments/

she says:

“This is the binary, these are it’s dependencies, you figure out how to package it for your platform.�

This will only work if people stop using the commercial distributions and instead focus on work. But even debian makes it a habit to cripple software by removing the headers, and you as a user first have to figure out how to de-cripple it.

Another problem is the FHS standard. It does more harm than good.
Look at Mac and Windows, they are more akin to self-contained directories than the spread-over-all-place install.
You could just remove the dir and be done with it (ok on windows you also have the registry, but actually their are standalone apps that just dont use the registry at all, and this is a good thing)

Nick Pollard says:

What you're complaining about is not a purely Linux problem, but a problem inherent in all Unixes. You will have problems with binary compatibility in almost all unix-derivatives (even of the same type, due to installation differences) because (and this is very important) BINARY COMPATIBILITY IS NOT WHAT UNIXES WERE DESIGNED FOR.

Let's step back in time for a moment to the earliest appearance of a UNIX-like OS in the late 60s. At this time, there were no large 'software companies' - in fact, the idea would have seemed ludicrous. Any organisation who had a computer also employed people to program it sepecifically for the tasks that they needed it to do. The owner of the computer would, therefore, also own the source-code and could easily upgrade to a newer computer or a different version of UNIX with minimal changes to the source code and a recompile. That is the purpose of UNIX - it is designed to adhere to a few basic standards that allow source code to be moved over to another computer and used as soon as possible, with a few modifications.

Binary compatibility has never been a hallmark of UNIXes and shouldn't be - UNIX / BSDs / Linux would have never even gotten to where they are today if they had to maintain binary compatibility - look at the mess that is the WinNT codebase (for example).

What you are complaining about is the very purpose of the OS and the philosophy behind the very first UNIX that has carried through - that it is expected that the owner of the computer has access to the source of the programs running on it, and it is up to him to fit the program to his needs and system.

So, yes, binary compatibility is hard. It's supposed to be - because you're trying to subvert one of the primary rules of UNIX.

Porkchop says:

You should try writing device drivers. At least, in the 2.4 days, kernel changes were reserved for bug fixes. Now I have to deal with multiple incompatible memory management systems, constantly changing APIs, and oh yeah, kernel bugs.

Did I mention I'm expected to support everything from RH7.3 through RHEL5? Plus Fedora? And every SUSE release from the same time frame? And the occasional special purpose distribution, like ROCKS?

My code is a spaghetti wasteland of #ifdefs and time bombs. The guys in the Windows group don't have these problems....

Steven McPhillips says:



The more I think of it, the less I think this has to do with closed source and the more I think your post has to do with supporting various Operating Systems. You seem to equate Linux with another OS, like Windows, OSX, Solaris. This isn't quite true, as you've found: Fedora Core, RHEL, Suse, Debian, Ubuntu: these are all different Operating Systems.

There are a few different ways to handle different OS's. Most UNIX-like systems take advantage of a "configure; make; make install" regime, which is a good lowest common denominator. Failing that, delivering a product in a cross-platform manner (like Java) can work, but as you mention in the Eclipse example, this only covers the installation.

Sure, doing package management under Linux-based OS's can be difficult. It largely depends on what you're working with: what design decisions were made on the outset (and no offence, but I've seen some shockers. Contribute server comes to mind :o). But I would say that package management under Windows-based OS's is just as bad. Unattended installation (msi creation, all the rest) never seems to get any better under Windows systems - I really feel for my windows admins who struggle so much to roll out an updated custom application to hundreds of desktops when all I would need to do is push it out via the RHEL update service, or an "apt-get update", etc.

Anonymous says:

You realize this entire blog entry is pointless, because nobody is going to listen to you, right? OSS is apparently where the bright, deaf engineers who don't understand business end up. I quit trying to tell them anything years ago.

Nick Pollard says:

I would take issue with "Anonymous'" comment that OSS is "apparently where the bright, deaf engineers who don’t understand business end up."

This is, once again, related to my previous comment - the UNIX source-code ownership and the OSS paradigm are very good for business, that is - businesses that own and deploy many computer systems that can all run a system that can be completely customised for the business or for each intended task, and do not wish to be tied to a single supplier, to whom their survival is inevitably tied.

The UNIX / Linux security model encompasses more than just system security, it also means continuity - code that can be maintained, changed and fixed without looking to a third-party for permission, this is insurance from being held hostage by any one supplier of software.

Who the paradigm is not good for is: closed-source software developers, whose business model is based around 'vendor lock-in.'

Luckily, the first group of companies is a larger and more economically important than the second group, and will for ever be so - they are customers - they are insurance companies, banks, government IT infrastructure, investment companies, large recruiting firms, etc. Almost any large, established company will have at least some backend systems running a UNIX variant that is running programs that may have first been created 20 years ago (or more), specifically for the company, for which it owns the source. Usually, this software (often mission-critical) has been updated, changed and/or ported over the years by company employees or, perhaps, the data has been extracted and moved over to a different system entirely - all with minimal economic impact. If such programs were closed, with proprietary lock-in, it would be considerably more costly and disruptive.

Software developers should understand that the business model that works for them is not necessarily the best option for their customers, who may have been around for decades more and whose company lifespan is considerably longer than that of most software houses. That the 'vendor lock-in' model has proven relatively profitable thus far is more a testament to the recent business trend of relentless short-termism, rather than proof of its sustainability.

Bjorn says:

I had no idea Flex Builder was going to appear on Linux. This is making my day. I love Flex 2, and was working on it on Windows for a while, but I have gone the way of Ubuntu instead of Vista. If you make it, I will buy it. Don't give up!

P.S. I don't care if it 'looks' crappy on Linux, and I don't think most Linux developers would care either.

Anonymous says:

The comments were TL;DR, but incase it weren't mentioned, proprietary drivers like NVidia and ATI's video drivers are also closed source..

» If that last was to much for you.. says:

[...] source on Open source doesn’t [...]

Kinger says:

Your comments on this issue of supporting "commercial software" on Linux is going to join a chorus of similar voices that are rising from all over. I hope the noise is loud enough for the powers-that-be to start listening.

I had a similar experience when I installed Ubuntu on my laptop some months ago. I have some good experience with Linux, like I created a custom distribution derived from redhat couple of years ago at a different job. I like Windows and I happen to use systems because I like them and not because I have a need to look or sound like a geek. So when I heard so much being said about Ubuntu and after having seen the Compiz videos, I just had to have it.

After a huge amount of convincing my wife that I wont mess with her Windows install, I started the process of installing Unbuntu - Fiesty. Oh my god what a nightmare it was. It took me atleast 20 hours over several days. Not that any of this is the fault of the Ubuntu folks. In this case the primary culprit was NVIDIA. So I had install into text mode, compile and install the NVIDIA driver to make it all work. The irony was that after all that trouble they put me through, they shamelessly slap a banner into the boot process. Just unbelievable.

So, for all you who are screaming that mom and pop should get Linux pre-installed on their computers, hope you last name is Linus or Knuth. Please guys, when someone complains that they don't find Linux to be user-friendly, of course they are just saying that it does not work like Windows. But here is the secret, they were there before you and they have set the standards for user-friendliness. So tough luck, nobody owes you. So quit calling everyone who complains an idiot. And make comments like "Its just a few shell scripts", "It is just a compile".

And while you are at it please tell the car manufacturers that when they sell a car you can get it real cheap as long as you can assemble a part of the engine yourself. Well in our world that how we do it.

Sampo says:

This is only partially at OP and pointed at some other commenters as well.

I know this argument is getting old as well, but I don't really care whether mom and pop can ever use linux. I don't personally care whether linux will ever "defeat windows".

What I do really care about is that -I- retain the freedom (of choice) I found in linux. That may sound very selfish until you realize that my freedom is your freedom as well. If you don't care about freedom but just want your virus-free windows for free please go look for it somewhere else.

Still, I use linux on my desktop and my laptop because that what works best for me for what I do. All my paying job is done on linux as well.

Nick Pollard says:

"Nick, let’s say I build houses for a living. 500 years ago I had to know not only how to build houses, but also how to make hammers, saws, nails, etc… How many houses could I build?"

To Rob T:

Your analogy is disingenuous. No one is forcing companies to create their own software, you can contract that out to a company who will do that for you, or you can keep it in-house (as some companies still do with their accounting, HR, and legal departments - none of which are part of the core business either, but are of equal importance as systems & networks). The point is that the CHOICE is there for companies to create systems that suit them, and there are many companies and contractors that specialise in providing bespoke solutions for their clients, complete with source code.

A better analogy would be, as a house builder, that you build a house for someone. Under the UNIX / OSS philosophy, that house is now theirs and they may modify it in any way they choose. Under the closed-source model, the owners would have to ask you permission every time they wanted to do so much as redecorate, let alone build an extension.

Your argument could equally be "I want to build houses, not deal with legal issues," or "I want to build houses, not deal with staff," or "I want to build houses, not deal with accounts," and while there are many large companies who have outsourced all of that work, most of them have found the potential gains do not outweigh the eventual costs. Large companies are complex systems that have an entire support ecosystem built around the core business, every large company has to do things that aren't its core business, no matter how they would "just want to build houses," and this is a necessary thing for the security and stability of any large concern.

Furthermore, you - as a house builder - would be poorly served by a hammer that stopped working if the company who made it went bust, or that would only work with certain 'supported' nails. You don't have to make the hammers, just find someone who will transfer full ownership rights to you for said hammer (which is, thankfully, the norm when it comes to physical objects).

Swaroop says:

@Devdas: Waiting for distribution makers to do that work is a long-term solution. If we want to release it today, we have to do the work ourselves.


Alternatively, don’t ship your product as a closed source one.


As I said, it cannot be a all-or-nothing approach. Let people take the first steps.

Feedback

There's no comment box, but please do email me or tweet me your thoughts and criticisms, and I will publish the relevant ones here.