User: Password:
Subscribe / Log in / New account

Leading items

How would you shrink Fedora?

The Fedora hackers have a small problem: the current Fedora Core 4 distribution, as it sits in rawhide, is about 300MB too big to fit onto four CDs. For various reasons, the project is not interested in adding a fifth disk at this time. So that means that something has to come out and, presumably, be relegated to the "extras" repository. The project has taken the somewhat unusual step of coming out and asking its users: what would you remove?

The leading candidate, at the moment, would appear to be Java support, especially Eclipse. The Java packages are huge; getting rid of them would solve the space problems easily. They are also relatively easy to remove because they were not shipped in prior versions of Fedora. The distribution's users, one assumes, will complain less about losing something they didn't have in the first place.

People are complaining, however. Many developers feel that, if Linux is to have a hope of long-term success in large enterprises, it has to offer top-quality Java support. But, if the distributors do not support free Java implementations now, work on free Java stands a good chance of dying from neglect. Few people want to see a future where Linux is, at best, a platform for proprietary Java implementations. To avoid that future, the distributors should support free Java now.

Other possibilities raised include:

  • Getting rid of the games. Certainly games are not at the top of the list for many commercial environments, but games do serve as a gentle introduction to Linux for many people.

  • Dropping either emacs or xemacs (but not both).

  • Dropping exim and postfix. Except, of course, many people think that the distribution should drop sendmail instead.

  • Removing abiword and gnumeric, since, in theory, provides the same functions.

  • Removing KDE. Or removing GNOME. Neither of those look feasible, but it's possible that XFce will go.

  • Move epiphany to extras. Or firefox.

  • Go to GCC4, which will cut some redundancy. It appears that this change might just happen for FC4.

Various other ideas have gone around as well, but none of them are pleasing to everybody. It appears that the Fedora Project, which has to come up with an answer to this question in the near future, is almost certain to upset somebody, at least in the short term.

For future Fedora Core releases, there are plans to make the installer smarter so that it can transparently grab packages from multiple repositories. With a bit more infrastructure work, perhaps Fedora could take a cue from Ubuntu, and drop back to a single installation CD. In the end, it really should not be necessary to download every possible package (in ISO form) just to get a base system installed. For now, however, the project seems stuck with the need to remove packages that some of its users truly want.

Update: a list of removed packages has been posted. Victims include abiword, balsa, exim, gnumeric, koffice, octave, sylpheed, xemacs, and xfce. The Java packages appear to have survived. Second update: it seems that Fedora Core 4 will also be a five-CD distribution; that's how they kept the Java packages.

Comments (61 posted)

LWN goes to LinuxWorld

Your editor returned to the LinuxWorld Conference & Expo last week for the first time in five years. LinuxWorld has been an important conference since it began; there may be no better place to see what is going on on the business side of Linux. But the development-oriented conferences are much more fun. Still, LinuxWorld proved to be an interesting experience.

Attendance at the Boston LinuxWorld was on the order of 7,000 people. The east-coast version of the event is clearly quite a bit smaller than the San Francisco edition, but that is still a significant crowd. Attendees were heard to say that the show felt smaller than last year's event in New York. The organizers seem happy with the turnout, however, and plan to move to a larger conference center (still in Boston) next year.

There were some 140 exhibitors on the busy trade show floor. Of these, 24 were in the .Org area. By a conservative count, close to one third of the exhibitors were pushing some sort of proprietary software for Linux; backup software, configuration management, and databases all seem to be highly active areas. Security too, as could be seen by all of the attendees who were willing to accept - and wear - "virus free" stickers from one of the more in-your-face booths.

The design of the conference center caused the exhibit floor to be divided into two rooms. The conference organizers made use of that division to great effect: they separated the two communities in attendance at LinuxWorld. The larger room was dedicated to commerce; that's where all the large booths from the usual suspects (Red Hat, Novell, IBM, Sun, etc.) were to be found. The displays were flashy, the speakers charismatic, and "solutions" were flying by at high speed. But the community which creates the software that makes all this possible was nowhere in evidence. In early LinuxWorld conferences, it was common to find developers hanging out in their employers' booths. In 2005, those developers have found somewhere else to be.

[Jim Gettys]
Jim Gettys

The interesting thing is that a fair number of developers could, indeed, be found at LinuxWorld. They tended to prefer the other room, however, where the ".Org pavilion" was located. That side of the hall was far less flashy, but much more fun. The people who create Linux do still wander by LinuxWorld; you just have to know where to find them.

The early LinuxWorld conferences included a reasonable program of talks along with the exhibit floor. At the first LinuxWorld, your editor complained that talks by Jon 'maddog' Hall, Larry Wall, Jeremy Allison, and Miguel de Icaza had all been scheduled simultaneously. There are few such problems in 2005. Though the conference did offer some interesting speakers (among others: Jeremy Allison, Matt Domsch, Chris Wright, Jay Beale, and, inevitably, maddog), the conference program was fit into a mere three slots per day. The talks are clearly not the main attraction at LinuxWorld.

Your editor got a chance to try out booth duty, giving a talk from the O'Reilly booth. For the morbidly curious, O'Reilly's Greg Corrin has posted a picture of the event.

[Bruce Perens]
Bruce Perens
The only talk your editor attended was, interestingly, not on the conference program. Bruce Perens gave his "state of open source" talk, instead, in a press conference format - complete with free food. The core of the talk was concerned with software patents - in Europe, and in the U.S. The community has, says Bruce, no defense against patent suits, and free software developers cannot count on assistance from large corporations when an infringement suit comes around. He was apparently recruited to be an expert witness for "the defining Linux patent infringement case," only to be dropped when the (anonymous) party realized that Bruce would not testify in a patent holder's favor. According to Bruce, the solution to the software patent problem can only lie in "clean-up" legislation at the Federal level.

Bruce also touched on Sun's situation (from which the company has "no good exit"), the SCO suit (interesting things may come from the turmoil at Canopy), and the need to emphasize the "free" part of free software. A focus on freedom will help the community to occupy a moral high ground which will help when trying to obtain friendly legislation. Bruce has posted his speaking notes for those who are interested.

One notable absence this time around was any mention of BSD. The BSD branch of Unix was well represented at early LinuxWorld shows; the booth staff tended to stand out in the crowd of Linux folks. BSD remains an important part of the free software world, but its distance from Linux appears, sometimes, to be growing.

LinuxWorld reflects the commercial side of Linux; that side is an important part of the greater Linux ecosystem. This conference is also where new users tend to start. So it is an important event. It's important that the community be there; we can help guide users toward the heart of the free software movement.

Comments (7 posted)

Cutting back license proliferation

February 23, 2005

This article was contributed by Joe 'Zonker' Brockmeier.

The number of open source licenses in use today would be a good example of "too much of a good thing." Taken individually, each open source license represents the freedom to use, modify and redistribute code. However, many of the licenses are incompatible, and present a hurdle for open source projects that may want to incorporate code from other projects.

At LinuxWorld last week the Open Source Initiative (OSI) board made it known that they are looking at ways to reduce the number of open source licenses in use. We invited Russ Nelson, president of OSI to respond to questions about reducing the number of open source licenses in use.

LWN: What's so bad about license proliferation?

Two problems:

  • A company reasonably should take a good look at the license before they modify a piece of open source software, even for internal use. "A good look" means a legal analysis. Every new open source license makes it that much more expensive. Some companies want to do this even if they only *use* open source software (but no open source license restricts use in any way).

  • What happens when you want to combine software from two different packages, but they're licensed under software with conflicting terms?

LWN: Realistically, what can be done about the problem? How can OSI "trim" the number of licenses, or influence companies and developers that use one-off licenses or less popular licenses that are incompatible with the "main" open source licenses such as the GPL or BSD license?

Say "no" more often. But it's not enough for us to say "no". We have to have community support for saying "no", so that the community won't use software that isn't OSI Certified.

LWN: OSI has approved quite a few licenses - how many of those licenses are one-offs or used by a handful of projects?

The vast majority. Before we can address license proliferation, we need to understand the problem better. How many companies think they need to study a license before they can use open source? How many before they make internal modifications? How many before they publish modifications? We need to understand how many licenses are actually being used, and how widely. Lots of study needed before we take action.

LWN: Is there any consideration being given to changing the Open Source Definition - for example, to disallow licenses that are specifically tailored not to be compatible with the GPL?

We would have to discern intent to do that. But yes, we've changed the OSD in the past; we may do it again.

LWN: It's been well-publicized that version 3 of the GPL is in the works. (Well, has been for some time, but much noise has been made about it being ready this year.) What needs to be in version 3?

Depends on what your goal is. If you went into a code tree to refactor it, there's always changes you would make. If you want to add features, you would make different changes. I expect that some community members would like the GPL to be a contract rather than a copyright license. I expect that others would like to see copyright provisions address "public performance"; that is, web services.

LWN: In one story, Sam Greenblatt was quoted as saying "there should be three licenses: the GPL, a commercial version of the GPL and...the BSD." What would a "commercial version of the GPL" look like?

CDDL. Or more properly, the MPL, since it already has traction in the community (clearly, since Sun wrote the CDDL based on the MPL). A lot of licenses are derived from the MPL. If we can figure out why they derived the MPL rather than using it, we can fix the problem in the MPL that caused them to do that.

LWN: Thanks, Russ.

Comments (5 posted)

Page editor: Jonathan Corbet
Next page: Security>>

Copyright © 2005, Eklektix, Inc.
Comments and public postings are copyrighted by their creators.
Linux is a registered trademark of Linus Torvalds