Re: state or future of LFS?

[Wouter Klouwen <dublet%acm.org@localhost>]

matthew sporleder(msporleder%gmail.com@localhost) said 2009.04.13 15:13:21 
+0000:
> This thread is an interesting deadlock between two parties:
> Users who think LFS is a really good idea and want to see it thrive
> versus Developers who have worked on LFS as it exists right now and
> been frustrated/burned/otherwise made unwilling to continue working on
> it
> 
> However, the sheer number and caliber of developers who fall into the
> second camp says a lot about the current implementation of LFS, so
> maybe some middle ground would be a good place start.

I don't want to throw oil onto the fire, but..

AFAICT, the LFS implementation is suffering from trying to tie it into FFS.
Given the fact it's a completely different concept to FFS, that was probably
not a good thing to do.

> I'll WAG a suggestion, but my own abilities really limit the amount of
> weight I can put behind it:
> Start an LFS-lite filesystem as a new project to help solve the
> problems expressed by frustrated developers and targets the main ideas
> keeping the LFS user community passionate about defending it.  (the
> 90% solution?)

Perhaps starting from scratch would be a better idea, relatively speaking,
as one of the developers suggested, starting with Sprite LFS. This should be
relatively quick, no?

Is it not possible to have some sort of modular framework for file systems
(perhaps as LKM), which provides for some of the basic FS operations?
This could be used to maximise code sharing and minimise bugs, yet avoid
trying to tie different FSes into a commonality they don't have. 

For instance, it seems rather silly to me that FFS over NFS works fine, but 
LFS over NFS throws panics all over the place.

Right, that's about a year's worth of OPEC production.
 
> Matt
        --Wouter