LFS Future Braindump

Ag. D. Hatzimanikas a.hatzim at gmail.com
Wed May 28 10:39:15 PDT 2008


On Wed, May 28, at 08:06 Thomas Trepl wrote:
> But here i think is the problem: This mail setup alone could fill up a book 
> because in that complexity it is not enough to simply show the build 
> instructions. They are almost the same as usual. But the real challenge is 
> the configuration of them (and maybe even some additional scripting) to make 
> the world go round. And, the configuration can only be as good as it is 
> described. I think that is basically what Robert has brought up initially.
>

What I believe - in my opinion - that (B)LFS should (probably) do, if it
really really wants to survive in the wild-wild meta ubuntu Linux era is; 
instead of maintaining packages like we currently do, is to try to
maintain specific jobs or modules (ala Alan terminology), like a how to run
a mail server? Some answers to this kind of questions:

   * why I should choose a specific solution/setup? Dis/Advantages with a
     competitive implementation?
   * why I need a dependency? What is the additional value to the end
     product? What are those extra steps and configurations I should
     follow?
       
While there are a ton of ready (click and run) implementations (that the
myriad distributions offer nowadays), or a ton of wikis or a great
upstream documentation (in some of the cases), I still believe that
the glue to all this material is missing.

Even if it is for a simple choice of a terminal emulator, we can provide
information about those choices. What is the real advantage to use
xterm instead of urxvt? Is there any performance issue? which one of them
is eating more memory than the other? Does it have tabs? Does it make
coffee?

That way, we can be a point of reference in the various Linux
fora/circles and quite possible will gain a significant new audience, by
people (users or developers) from other distributions, who will come
to read our documents wishing to learn by an independent source why they
should choose an application/implementation over the other (to install
in their distribution).

I read the other day the performance issue that grep has in multibyte
locales, and the huge advantages to use ack instead. Quite frankly this
is exactly the material I want to know. I want recommendations! From the
myriads of choices I need the jelly-belly!

http://blog.i-no.de/archives/2008/05/07/index.html

And one last thing.
I believe Robert's posts (both of them) were some of the best I ever read
in those mailing lists, as far it concerns development.
He touched those inner concerns that some of us have and I thank him.
Unfortunately the development never happens in LFS for the simple reason
that we are too many and we all have a different view of things. That is
not going to change soon or never for that matter.
>From now and on, I will encourage people to apply their ideas indepentently
of the opinions, and for that reason, I will please and ask the community
to give the supplies (e.g., svn access, an LFS account and the
permission to create a personal branch) to those people (with plans or a
simple desire) to work on their ideas.

If the end product is good enough maybe it can be mainstream.

-- 
http://wiki.linuxfromscratch.org/blfs/wiki/Hacking



More information about the blfs-dev mailing list