LWN Weekly Edition
Front pageSecurity
Kernel development
Distributions
Development
Linux in the news
Announcements
Letters to the editor
->One big page
This page
Previous weekFollowing week
| |||||||||||||
LWN.net Weekly Edition for March 31, 2005Autopackage 1.0The Autopackage project hit 1.0 on March 26th. Autopackage is a "multi-distribution binary packaging framework for Linux systems." To put that in layman's terms, Autopackage is something like an InstallShield application for Linux users.Autopackage is not an attempt to replace native package management -- it doesn't replace RPM, dpkg or any other system of package management for Linux distributions. Instead, Autopackage is designed as a packaging system for projects and vendors that wish to ship applications for multiple Linux distributions without having to make packages for every variant of every distribution they wish to support. The Autopackage system is primarily designed for use with packages for desktop users, like Abiword, Inkscape, Gaim and others. The default front-end for Autopackage uses Gtk2, but there is a a Qt frontend available as well. It's worth noting that Autopackage is licensed under the Lesser General Public License (LGPL), which makes it suitable for free software and open source projects as well as proprietary software. The package format itself is a gzipped tarball with a "stub script" at the beginning of the file. It is, in other words, a sort of executable, self-extracting archive format.
The first package we tried to install was Abiword, which is available from
the Autopackage
downloads page or directly from Abisource.
We first tried to install Abiword on an Ubuntu Linux system. Unfortunately,
Autopackage complained that it failed to find the "enchant" spelling checker,
even though it was installed on the system in We tried the Autopackage for Inkscape next on Ubuntu, and found that it installed with no problems. We also tried removing the packages and re-installing them to see if there were any glitches or unwanted side-effects. The Autopackage system handled removing and re-installing the package just fine. We even used Autopackage to uninstall itself, and were able to do so without any problems. Overall, we were pleased with the operation of Autopackage. Autopackage does have a number of limitations, however. First, it's limited to x86 systems. Third parties that want to package applications for Linux on other architectures will not be able to use Autopackage, at least for the time being. The Autopackage system also does not integrate with the system's package management. This means that RPM or dpkg will not "know" about the existence of an application or libraries installed via a .package file. For some packages, this may not pose a significant problem. For example, if a user wished to install the Linux version of Yahoo! Messenger, it's unlikely they'd have other packages that depend on it or any need to manage the package via RPM or dpkg. Another drawback for Autopackage is the lack of support for package signatures. The Autopackage FAQ discusses the rationale for this. Since Autopackage is not a centralized source for software, unlike Red Hat, it creates some complications for package signing. Finally, since Autopackage depends on a working Network connection, it could pose a minor headache for users on dial-up who download their first Autopackage and then try to install the software when not connected to the Internet. We didn't actually try creating any Autopackage packages, but from the documentation, it doesn't seem that creating an Autopackage is much more difficult than creating RPM or Debian packages. The project is now working on bugfix releases in the 1.0.x series, and development towards the 1.2 release. The project TODO list provides an indication of where Autopackage is headed for future development. The Autopackage team has a Flash installation demo and 4-step tutorial that show how easy it is to use Autopackage. Overall, Autopackage is a very promising project. It makes it possible for third-parties to distribute software for Linux users without the need to create sets of RPMs and Debian packages suitable for many different Linux distributions. It's also easy to use, and should require little skill for users to manage. It's too bad that such a system is still necessary at this time, but it fills a necessary gap until the day that Linux distributions can settle on a standard base system and packaging format.
De.visi.ve?del.icio.us is an interesting site. In its simplest form, it provides a sort of centralized bookmark service. Bookmarks are stored in a flat structure, with any of a number of "tags" assigned to them. Since the bookmarks are stored on the server, they are available anywhere on the net. The tags and bookmarks are absolutely public, so anybody can see what everybody else is interested in. The site as a whole forms a sort of spontaneous index of the web, sorted by popularity. del.icio.us has attracted a great deal of interest as a collaborative guide to the net as a whole.It is not surprising that competitive sites would pop up. Still, many del.icio.us users were surprised by the debut of de.lirio.us, which differs in these significant ways:
Users of del.icio.us are somewhat annoyed. The creation of an outright clone strikes many of them as dishonest, and they would rather have seen the effort go into creating a better "folksonomy" at the original site. Most of them see little reason to put any effort into an imitation of del.icio.us when they have the real thing. The advent of de.lirio.us does raise some interesting questions, though. Does the open-sourcing of the code justify the creation of a clone site? Steve Mallett, the creator of de.lirio.us, seems to think so. (Steve is also, incidentally, the OpenSource.org webmaster and the editor of OSDir). The Linux kernel was created for very similar reasons; it was a clone which made an established interface available as free software. To the extent that the del.icio.us interface was successful, it made sense to copy it rather than invent something new, but less effective. The new site perhaps could have tried for a slightly different look, however. One del.icio.us user questioned the wisdom of making this sort of software free in the first place:
The biggest issue with open sourcing social software is that I feel
it's counterproductive: the issue of fragmenting the userbase into
a thousand pieces is the main problem.... my thoughts are that,
paradoxically, more openness in the software would result in such a
fragmentation that it would have the effect of closing the
community up into discrete little parts. I think a more "Leviathan"
approach than "invisible hand" might be better here.
This is an interesting variant on the fragmentation argument: social software must remain centrally controlled or its user community will split asunder. Whether this is true - or undesirable - is irrelevant, however. People have little interest in being forced into "communities" which do not appeal to them, and, on the net at least, they will find alternatives. Another event worth noting is that del.icio.us creator Joshua Schachter has announced his intention to make a business out of the site. Depending on where his plans take him, del.icio.us users could find themselves happier than ever. If commercialization takes the site in the wrong direction, however, many of those users who are currently upset about de.lirio.us may decide that the existence of an open source alternative is not an entirely bad thing after all.
A quick LWN updateWe occasionally get a request for an update on how LWN is doing. It seems about time for another one of those; it's been a while, and, besides, it's a relatively slow news week.Back when we started the subscription experiment, we set a goal of signing up 4,000 subscribers. The good news is that we seem to have done that. Between our individual subscriptions and the various group subscribers, the current count is almost exactly 4,000. This is a major milestone, one we are happy to have reached. Our thanks go out to every one of our subscribers; it is you who make this whole exercise possible. The bad news was probably pretty predictable from the beginning: 4,000 subscribers is not enough. Some of our costs (notably health insurance) have gone up significantly, and others (outside writers) had not been predicted at all. We also very much need to bring in another top-level editor so that we can expand our content and do things like attend conferences or take vacations without seriously straining the whole operation. So the push for more subscribers will continue. Exactly what form that effort will take is still being worked out; it will probably include more benefits for subscribers (without taking anything from non-subscribers), some attempt to expand the content mix, and a more focused sales effort. Making all this happen with the current staff will be a bit of a reach; we'll get there, but we ask your indulgence if LWN shows occasional signs of stress in the mean time. Thanks once again to all of you for supporting LWN; it is a privilege to write for such an outstanding group of readers.
Page editor: Jonathan Corbet Inside this week's LWN.net Weekly Edition
|
|||||||||||||
![[Autopackage screenshots]](/images/ns/autopackage-sm.png)