Ian Bicking: the old part of his blog

GNOME and the Managed Runtime

Havoc Pennington has been writing lately (quite often) on Java, Mono, or C++.

He is bringing up some important issues, which I think can be summarized with the question: what is the future of the free software development environment?

Historically, of course, the environment has been primarily C. As this has become less acceptable to software writers, efforts have diverged into a number of different areas. But the "core" efforts, the basic infrastructure upon which we build, has remained in C. Except KDE's C++, but that's really the exception that proves the point -- and certainly not an example of how we want to transition to a different core environment (speaking from a social/political point of view, not technically).

Even C has been a bit of an issue, as attempts to build up the environment in C have met some resistance from people who don't want to deal with a large number of dependencies. Of course, since I use Debian I don't mind a large number of dependencies, and I'm only even vaguely aware that dependencies exist. But apparently a significant number of people are using inferior operating systems where this is a problem.

Anyway, ignoring the issues of dependencies, the question of environment is a very important one, and I think Havoc is right to start to talk about it as a conscious decision. Anyway, my two cents:

I think many in the free software community -- especially those with a desktop orientation -- have had an inferiority complex. They've heard the message that free software can only play catch-up with proprietary software, and for some reason they've come to actually believe this.

We need to start appreciating what we ("we" in the most inclusive sense) have accomplished. Coming back to dependencies and Debian, I think this is something that is an under-appreciated example of success. Debian has something on the order of 10,000 packages in it, all inside an inclusive system of developer support, bug tracking, release management, and everything else that makes the operating system work. This is built on technical foundations in part, but also very much on social and political foundations.

I believe the result is simply the most maintainable, well-controlled system of software ever. Ever! I feel confident that no one has created a matching system, not inside a research facility, not on mainframes, not in any of the other major operating systems. Because you can't create something like that outside of a social structure, and Debian simply has no peers in this.

This isn't a minor accomplishment either -- it gets to the foundation of managing a computer system, as applicable to desktops as to servers. It does so through technical means (which can be copied by proprietary companies), but also through the incremental and cooperative efforts of the Debian maintainers and users (which cannot be copied). Obviously, robust software management isn't the complete solution to all our woes, but it's a very important part of the ultimate solution.

I don't bring that up because it directly informs the environment debate -- though it does relate in some ways (in terms of creating manageable eclectic environments) -- but because I see it as a strategic example. Debian wasn't competing with Microsoft. I don't even think people were comparing Debian to Microsoft at any time during development. Debian did not compete on Microsoft's terms. And as a result, they were able to create a system that excelled in a way Microsoft could not excel.

We need to be doing the same when we consider environments. Here we're looking at two proprietary environments -- Java and C# (and arguably even C++ is proprietary in spirit) -- and asking which one is best. That's a horrible strategy! Those environments were created with strategic goals in mind, and those strategies hinge around proprietary companies.

Instead we should be looking for inspiration from within our community. We should be looking for the successes we have come up with ourselves, based on a feedback cycle that includes free software developers, and based on software methodologies that makes sense for us (methodologies which are very different from proprietary development).

An example: I think Python's model of portability is superior to Java's -- Java is based on the idea that you can abstract away the larger environment, so that every program will see the same thing no matter what platform it is on. Python's model is that you expose the platform's differences when they exist, and allow developers to create portability layers at whatever level makes sense to them, or to use no layer at all.

Java's model makes sense for proprietary development, because you may test on only one platform, but a user can use it on another platform with no changes. Python's model is superior for open source software, because if the user has problems on their platform (which won't necessarily happen, but can), then they can report the problem, suggest whatever pragmatic fix is necessary, and it will work on the next upgrade. Because there's a feedback loop, and because the user is empowered through the presence of source code, Python can make context-sensitive decisions about portability. The Python program can then make full use of the platform it runs on, instead of using the lowest common denominator, or creating entirely alternate layers (like Swing).

I'm not familiar enough with desktop programming, or with Java or C#, to come up with a lot of examples like this, but I suspect many exist. Ultimately a solution equivalent to Java or C# isn't going to come out of the free software community. But I think alternative solutions already have come into existence, we just haven't always recognized them because they don't map one-to-one to the proprietary technologies.

Ultimately I've already made my choices, so it should be no surprise I think Python is part of that solution. But only part. The larger environment that favors Python is probably one built on C libraries. This is in no small part because Python needs all the help in terms of speed that it can get (at least for the desktop). Though the dumb procedural libraries that C encourages also maps well to Python and other environments, where we would prefer to be given a low-concept library that can serve as the foundation of a higher-level library in the native language (and this applies to all the high level languages). Mapping a library from Java will be slightly less comfortable, I think, due to almost-but-not-quite mappings. But I don't have a lot of experience in this area, so maybe it works better than I expect.

I've been happy reading about some of the projects like D-BUS which seem to carry on in the tradition of low-concept libraries. Perhaps what's need is a way of understanding and appreciating this model of development -- layered, procedural, decoupled -- rather than supplanting it with something more "advanced".

(Of course, I don't program in C, so maybe it's flippant for me to say that I'm happy others are working in C, because those other people might not be so happy to be in that environment.)

Created 28 Mar '04
Modified 14 Dec '04

Comments:

I've only just recently started migrating to Debian. The packaging system seems to be both powerful and user hostile at the same time.

For a start everything is still firmly rooted in the commandline. There are programs like aptitude that try to hide some of this but it seems pretty obvious that this stuff was designed for commandline users.

The other thing that struck me is how many dependencies I need to bring down just to update one package. Sometimes I'll do an update and get 50 other packages along with it. Some of these seem to have nothing to do with the one I actually wanted.

The windows packaging system may have a lot of technical problems but at least it's easy to comprehend. You download one bundle. Run it and everything you need is bundled.
# Anonymous

The Debian system is certainly written with the technical user in mind, though I think the foundation they provide doesn't preclude an easier system. I don't really want to debate the particulars of what it accomplishes, as it's an aside to this article, but it should be noted that it is extremely robust. And while it isn't necessarily easy for a novice user (novice with respect to system administration), it is actually superior to Windows in many respects that relate to usability. Most importantly: you can't mess it up. You can't remove a dependency without removing the packages that depend on it, so you won't leave things in a broken state. A lot of the less meaningful installation options are left out. The configuration is centrally located, and typically configured with reasonable defaults. Security updates are easily acquired and can be safely applied. Updates are always provided in the proper order. Major operating system upgrades can be performed safely. And the software will never spy on you.

Windows software can be easy to install, but is very hard to trust. I think the proper compromise -- even for the most novice user! -- is a trustworthy computer. Ultimately I don't think it's a necessary compromise -- robust system administration isn't exclusive with easy system administration -- but even if it was, I think Debian makes the right compromise.

But anyway, now I've done what I said I wouldn't -- go into debate about the particulars. The general idea was that Debian has done something truly novel, something that truly advances the state of the art, and soemthing that proprietary software hasn't and can't match. It's not the destination, but it's a solid step in the right direction, and something that we can build on. And the kind of success we can try to replicate.
# Ian Bicking

Oh, and actually the Debian package system _is_ quite easy to understand. All data formats can be hacked, viewed, sliced, diced as you want - they are all standard stuff (ar archives, tar.gz files and simple text files). Not as some other packaging systems where you need special tools to drill in. And the mechanism that apt-get builds on is quite simple - just the package files which contain the dependencies and hints. Even the tools to build packages are standard stuff - you can still hack your package yourself without using any special tools (although the special tools do make life much easier).

And let's be honest: doing a whole system update by just "apt-get dist-upgrade" on a life machine without taking it down is allmost as cool as doing your first "make world" on a BSD box ;-)
# Georg Bauer

I don't doubt the Debian package system is a technically robust system. I would like to see more emphasis making it more approachable to end users. I think Lindows got this point right with their click-and-run system - although they screw up other bits - so it obviously is possible to put a friendly front-end on apt. click-and-run works well for web-distributed products but we shouldn't stand alone packaging either.

The biggest issue isn't debs at all but the fact that Linux distributions are completely fragmented when it comes to package management. Right now you can't create a package that can be installed on any linux system without falling back to tarballs or building for all the separate packaging systems.

I guess we're diverging from the original discussion a bit aren't we?
# Anonymous