Linux standard at last?
I have often expressed my fear that desktop Linux is doomed by a weak standardization process, the many competing distros, and the lack of application portability. Apps are often not portable from one release to the next of the same distro, as I experienced recently with one of my own apps. The geeks in charge are mostly unconcerned, having the attitudes "choice is good", "Darwinian process will pick the best", "standards would inhibit innovation", "we don't care about peddlers of proprietary software", "developers should learn how to deal with the different systems", etc.
I also speculated about a year ago that Ubuntu might become the 600 pound gorilla that would fix the problem by setting de facto standards that the other distros would have to comply with - or get ignored by many software developers. The article referenced above goes in this direction. Shuttleworth is a businessman, not a zealot. I think he knows what he is doing. Hope so.
Linux Packaging Chaos
Ian Murdock (chief OS strategist at Sun, founder of Debian, former CTO of the Linux Foundation, former chair of the Linux Standards Base) wrote the following in his weblog (Dec. 2006, omissions noted with "..."):
How do ISVs handle this today? For the most part, they ignore the package systems on Linux and do their own thing. Trouble is, while doing their own thing gives ISVs the flexibility to work cross platform, it ultimately makes their products integrate poorly in the broader systems management context because the package systems know nothing about them ...Ian is working on a packaging standard for LSB in order to stop Linux from suffering the fate of UNIX. With people of this calibre working on the problem, there must be hope.
First off, we have to understand what ISVs want. The answer is simple: ISVs want to treat Linux as a single platform, which means they want to offer a single package for Linux, much as they do for Windows ...
The problem is that people (including software distributors) believe there’s such a thing as ‘Linux’ as a target platform, and that if you’re distributing software for ‘Linux’ then it won’t be simple to install it, ever ...
Well, then Linux is destined to suffer the fate of UNIX. I’m not ready to give up so easily.
The full article is here: http://ianmurdock.com/?p=391#comment-1018
Schizoid Linux
There are two opposing ways to see Linux, and both are true.
The Negative View:
+ Linux has lots of geeky technical issues.
+ Linux geeks are having fun. They don't care about us.
+ Freedom is next to Godliness - let chaos reign!
+ Documentation is boring and only for wimps.
+ Linux is for the high priests and Windows is for the masses.
+ Linux has thousands of great projects - and no management.
+ Linux market share is 1%.
The Positive View:
+ Linux is a fine operating system with a rich set of capable applications.
+ All this is completely free and can be modified as you please.
+ The geek community understands the problems and is rapidly improving.
+ Ubuntu is the new 600 pound gorilla and is setting standards.
+ Major PC vendors are starting to offer pre-installed Linux (Dell, WallMart).
+ Microsoft: quality, security and ethics issues are sending users to Linux (and Mac).
+ Linux market share has doubled in the last year.
Why I Advocate and Criticize Linux
I started with Suse Linux in late 2005. Before that I wrote software for Windows, and before that VAX. I had a hard time getting Suse to work properly, partly due to my ignorance and partly due to problems in Suse (drivers, bugs, poor documentation, etc.). I gave up after a month or so and tried Fedora, which worked better. I tried Ubuntu about a year later because it had such a good reputation and the user forums seemed better. It worked almost out of the box and I have been with Ubuntu ever since.
I got a book and started to write software for Linux. I found the support infrastructure to be quite poor compared to Windows and VAX. Technical documentation was scattered all over in many systems and places. Sometimes I had to resort to google searches and forums to get information, and I was not always successful. Much documentation is outdated or missing (or so hard to find that it might as well be missing). Some Linux heavyweights expect you to look at their code to get documentation. Diagnostics are mostly poor: cryptic messages in obscure places, or no messages at all: the function just exits or crashes. Eventually I figured out enough to write some basic programs. Fotox has been the most popular, followed by dkop. I chose to go with Gnome/GTK instead of KDE, and I still do not know if this was the right choice. I am horrified that one must choose at all. This choice should not exist: the two projects should join forces, but hell will freeze over before that happens. Let's hope that the LSB standards project will eventually make them reasonably compatible for applications (and the same goes for the many other desktop systems that are being developed).
The kernel is standardized somewhat, but technically inferior. I should be able to run my applications on any Linux system that has libraries installed with the functions that I use. As it is, I have to build on an old distro so that my programs have a chance of running on most newer distros, but this is not guaranteed. Rebuilding from source may still be needed, and the user may have to install some older libraries with redundant functionality (the autopackage web site explains the technical details). The lack of application portability (ABI compatibility) between distros and even between different releases of the same distro is a major problem. Users cannot change distros and take their software with them, unless they have source code and the knowledge and time to rebuild everything. Compare to Windows: programs written for Windows NT in 1993 still run on several generations of Windows later (this is not always the case, but Microsoft has made ABI a goal and has mostly succeeded).
Recently I had such a severe problem with Ubuntu 7.10 that I decided to go back to 7.04 and wait a few months for 7.10 to become more stable. Gnome was released with too many bugs (hangups, crashes). Growisofs no longer works reliably: some DVDs get written with directory entries pointing to garbage, and DVD reading is 1/3 as fast as before. Mounting a DVD has increased from 10 seconds to 30+ seconds.
I tend to tolerate and get around these kinds of things. The average PC user would not tolerate Linux for more than a few minutes. Now that Dell and others are starting to offer pre-installed and tested Linux, perhaps this will be a solution for the average user. But if that user starts playing with optional software packages, he will quickly dig himself into a hole and go back to Windows.
Many helpful Linux geeks are active in the forums, along with the arrogant ones who tend to be more noticeable.
I do tend to complain about problems more than I praise what is going well (like most people, I think).
It is hard to manage volunteers. This is one of the reasons (main reason?) why Linux chaos results.
Developers often ask for volunteers to do their documentation work, which does not get the documents written. I can document technology that I create ten times as fast as some other person, who must first understand everything I did - without documentation. Developers should know that documentation is part of doing a good job. I am thankful for the many volunteers that publish FAQs and How-Tos, trying to compensate for the lack of good documentation from the developers. But these helpful documents are scattered over all creation and not very easy to find, and they are only partly plugging the holes that should not be there.
I have installed Windows from scratch numerous times. I think that Ubuntu is about as easy to install as Windows, and faster. Synaptic is also a better update manager than Windows.
I recently tried to install gOS (an Ubuntu clone with mods) on an old Dell notebook. When I tried to configure the WLAN using their GUI, it kept ignoring or erasing my inputs and eventually hung up so bad that I had to reboot. I tried several times and gave up. I installed Ubuntu instead, and the WLAN functioned immediately. I find it incredible that such a crappy product like the gOS WLAN manager is offered to the world.
There are many outstanding examples of FOSS that show what the potential can be: Firefox, Gimp, OpenOffice, Gnome, KDE, etc. It is the problem projects that stand out and give Linux a bad name. Why did gOS need to replace the WLAN manager that came with Ubuntu? They only turned gold into shit. Linux is a mix of well-managed projects and badly managed ones. We can only hope that the Darwinian process will clean it up over time.
Interesting comparison: Windows and Linux directory structures. Both are in chaos. One comes from a single company that cannot control its own programmers.
Freedom of choice is good. Freedom FROM choice (i.e. standards) is also good. It is hard to know where the best tradeoff lies. For example, the many desktop systems for Linux are both a force for good and a force for evil. We want competition and freedom of choice, but not confusion, compatibility problems, and fragmentation of development resources. Are any of the many Linux desktops significantly better than Windows? Do we have many alternatives but no advantages for the users? The answer is not clear for me.
I am having lots of fun with Linux, even with the frustrations. But I am not like 99% of PC users who want a tool that works rather than a technical playground.
2007.11 DLL Hell, Linux Version
There are many different versions (distributions or distros) of Linux available, and each comes with its own set of application and utility programs that have been compiled for that specific Linux distro. Moving programs from one distro to another requires time and expertise: the programs must be rebuilt and repackaged according to the requirements of the target Linux distro. How to do this requires knowledge that is documented in hundreds of pages of dense technical details. Other documents specify the requirements of each Linux distro (if these documents exist). 99% of normal humans would never touch this.
Software providers wishing to make their programs easy and safe to install on many Linux distros have a problem: they must make many different kinds of installation packages, and this is not simple or fast. Understandably, most do not do this. They provide source code and expect the user to install the program, meaning that the user must have time and knowledge and be willing to assume some risk. To reduce this problem, many popular programs are packaged by the staff producing the Linux distro, so that the user has a simple job: basically a one-click install. This covers a minority of the available Linux programs, but a majority of the user's needs. If a user wants to change Linux distros and keep the applications he already has, he has a problem.
There is a project called "autopackage" which is aimed at making a universal program installer that works for most Linux distros. Providers must package their programs using autopackage, and users must install and use autopackage to install the programs. There is not widespread acceptance of this idea, for whatever reason (perhaps the complexity of autopackage).
The web site for autopackage does a good job of explaining why something like autopackage is needed. I would prefer that the Linux community decide on a single universal packaging system, and fix the other Linux problems that make ABI compatibility and application portability impossible. It will likely be a cold day in hell before that happens.
List of Linux issues preventing ABI compatibility and program portability:
variable file names and locations
variable package names and contents (package boundaries)
distro packages may use distro-specific scripts or macros
different desktop menu systems and interfaces
different documentation and help systems
programs linked with newer versions of glibc will not run with older versions, even if all referenced functions are available
an app is not guaranteed to run unless all libraries used in the entire dependency tree are identical for the build and execution systems
different methods to define file types and associations
I am not very knowledgeable myself about these issues, and there could be some errors or distortions in the above statements, but not enough to change the bottom line.
