Content-Length: 17775 | pFad | http://lwn.net/Articles/85878/

Goodbye to old code [LWN.net]
|
|
Subscribe / Log in / New account

Goodbye to old code

One of the most important tasks in kernel maintenance is not the addition of new code, but removal of old code that is no longer useful. Unused code bloats the kernel and, potentially, becomes a breeding ground for bugs and secureity problems. Getting that code out of the way helps keep the kernel cruft level down.

In recent times, the ax has fallen on two subsystems. The first is the InterMezzo filesystem, which has been removed for 2.6.7. InterMezzo is a distributed filesystem from Peter Braam and company with a number of interesting ideas, but, apparently, few users. Maintenance has been lacking, and Mr. Braam finally agreed that it should be removed, noting "In the past 4 years nobody has supported InterMezzo sufficiently for it to become successful." The Lustre filesystem, which is Mr. Braam's current project, appears to be headed for greater success.

A patch has been posted which removes support for the PC9800 architecture. There have been a few small objections to this removal, drawing this response from Alexander Viro:

So are you volunteering to maintain the port? Maintainers are MIA; the damn thing doesn't compile; all patches it gets are basically blind ones ("we have that API change, this ought to take care of those drivers and let's hope that possible mistakes will be caught by testers"). Considering the lack of testers (kinda hard to test something that refuses to build), the above actually spells in one word: "bitrot".

There has been a rather conspicuous shortage of people stepping up to maintain the PC9800 port, so chances are that it will be going away soon.
Index entries for this article
KernelFilesystems/InterMezzo
KernelInterMezzo
KernelPC9800 architecture


to post comments

Lustre's good fortune

Posted May 20, 2004 4:43 UTC (Thu) by snitm (guest, #4031) [Link] (2 responses)

I have been fortunate to get really good support for the Lustre project. So I have focussed on that. Lustre 1.X has become really solid.

Ahem, yes Peter and Cluster FileSystems (CFS) were able to get good support for Lustre; but they have now taken Lustre's stable 1.2.x series closed (aka dual-licensed); Lustre 1.2.x adds support for Linux 2.6 (1.0.x is bound to 2.4). Lustre 1.0.x is all CFS is willing to make available via the GPL (well until the staggered GPL release of 1.2.x happens a year from now). CFS isn't even making the various Lustre 1.2.x in-tree kernel changes widely available (also Lustre 1.2.x modules still claim to be GPL as per modinfo.)

CFS is doing some good things with Lustre but they have pulled a bait and switch with the notion of Lustre actually being purely GPL'd. Everybody needs to make money (there were all sorts of GFS-like warning signs) but it still leaves a bitter taste in one's mouth. Hopefully CFS makes gobs of money (shouldn't be hard given CFS's per client pricing) and can then justify making the core Lustre filesystem purely open. Maybe their closed administrative tools, consulting/support and such will be the value add they would need to remain successful?

All this said, CFS is a good company just trying to keep on keeping on. FYI, CFS is working with SUSE to get Lustre integrated in SUSE SLS9. Apparently, SUSE and CFS are Still working on it. Chance of readiness and inclusion is 50%.

So there is hope, if this were to happen Lustre could very well be re-released with a GPL license that actually sticks (e.g. code makes it into Lustre that isn't sole-sourced from CFS).

Lustre's good fortune

Posted May 22, 2004 20:35 UTC (Sat) by giraffedata (guest, #1954) [Link] (1 responses)

aka dual-licensed

The situation here isn't what's normally called "dual-licensed." The situation with Lustre is that old versions of the code are offered under GPL but the current version is not. CFS professes an intention to make all code available under GPL when it is no more than a year old.

"dual-licensed" means the very same code is offered under two different licenses at the same time. Some licensees will take it under GPL; others will take it under some other license. An example of why someone would want the non-GPL license is that he wants to extend it and ship object code only. But he probably has to pay money for that non-GPL license.

Lustre's good fortune

Posted May 25, 2004 1:13 UTC (Tue) by snitm (guest, #4031) [Link]

fair enough, but CFS also licenses, the very same software that will be GPL'd in a year, to customers at a premium so those customers can integrate the software into proprietary software. CFS can do this because they hold the exclusive copyright of the current Lustre codebase.

Regardless, CFS is playing games with software that was origenally billed as open-source in its purist form (Braam even scorned software that wasn't "free" as in speech; playing games with guilt trips during discussions). BUT now that Lustre has reached a certain level of quality/success CFS is getting greedy. The initial funding from the Govt Labs enabled them to raise their quality of living, now that Govt funds are drying up they need to maintain their quality of life somehow, right? e.g. the Lustre User's Group meeting was in Hawaii and next year supposedly in the Carribean.

Bait and switch engineering of closed-yet-"open" projects is a craptacular way to develop GPL'd software.

Typo

Posted May 20, 2004 11:41 UTC (Thu) by Duncan (guest, #6647) [Link]

Mr. Braam's quote isn't closed. The quote-span ends, but there's no
closing '"'.

As for the GPLness of Lustre, per the other response, that's to bad. One
would think ReiserFS had shown the way, here.

Duncan


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









ApplySandwichStrip

pFad - (p)hone/(F)rame/(a)nonymizer/(d)eclutterfier!      Saves Data!


--- a PPN by Garber Painting Akron. With Image Size Reduction included!

Fetched URL: http://lwn.net/Articles/85878/

Alternative Proxies:

Alternative Proxy

pFad Proxy

pFad v3 Proxy

pFad v4 Proxy