LFS Future Braindump

Tobias Gasser lfs at ebp-gasser.ch
Wed May 28 17:11:12 PDT 2008

>> 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.

100% agree

> 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?

i can't recall my thoughts why i implemented the mailserver with the 
packages i'm still happy with. i just remember to have installed quite a 
lot of source-packages to get a system with all my needs fullfilled. i 
guess the most important point is: i got enougth hints out in the net to 
get a system up and running stable with the packages i'm using now. and 
being able to reproduce the steps to set up the customers systems. (i 
remember to have stripped down a suse to my needs but wasn't able to 
reproduce the same steps with the next version)

>    * why I need a dependency? What is the additional value to the end
>      product? What are those extra steps and configurations I should
>      follow?

to many questions with a logarithmic number of answers.
setting up the mailserver i wasn't interested in getting answered your 
questions, i just wanted to get a reasonable number of packages to be 
installed to get the needed functions up and running.

horde is a grea tool. but toooo many dependencies. i.e. packages to be 
installed where as most of them i never heared of bevore - disqualified 
for my needs. my opinion: nice to play arround with on a big/fat distro 
like readhad, suse or ubuntu, but not for (b)lfs.

> 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.

100% agree

> 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?

advantage or disadvantage is not a thing you can explain easily. it 
always depends on your needs and prerequisites.

for me as a notorious smoker, to take a plane to get my cigarettes if 
i'd be stick somwhere on anatarctica would be absolutely reasonnable. on 
the other side i never would ever walk 2 steps to get access to a 
snooker table...
[grin on:] considering the time to get from anatarcica to the next shop, 
i guess i'd be nonsmoker meanwhile, and having a snooker table on hands 
while waiting for the plain maybe i'd even walk 10 steps next time...

comparing prices for hardware and manpower i never would argue with  a 
client about installing another 2gb of ram. if there is no more money 
for hardware i just charge some more time...

about making coffee: that's really a point for me. (but i know one of my 
customers prefers tea!!)

> 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).

for me it's not important to have leding edge software, i prefer to have 
a system suiting my needs. getting enought hints to set up "lesser" 
packages to suit my needs within a reasonable time is more important 
than to have the uppermost possible tool without any clue how to get it 
up and running.

i'm willing to spend time in reach an optimum, but if i can get the 
second best within half the time i myself really can live with it and 
even can convince my to customers to live with it too!!

usually my argument FOR a solution is: it's running.
most of my needs are covered by (b)lfs. the few i had to go further i 
just stopped my reasearches a soon as i got a running solution. (don't 
misunderstand my: i always tried quite some possibilities, but i started 
to stopp when the system is running withing the given parameters. as 
mentionned above: hardware nowadays is too cheap to search for the 
optimal sofware - i don't really like it, but otherways nobody is 
interessted in my knowledge as ibm360 assembler programmer today any longer)

> 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

[big grin]
yep. mee toooo. nice to have.

BUT: me and my customers just want to have a system suiting my/their 
needs. thus second best might be "better"... (really a good example as 
multibyte locales are getting an issue having customers with not only 
european but also russian and near east employees - btw: my 2year old 
doughter's paints seem to be more arabic than russian writings)

> 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.

marketing research: ask 100 people about ther opinion: 70 different 
answers and 20 dontknows. ask the same 100 people 6 months later and 
you'l get another 40 new answers and just another 30 with the same as 
last time (and the same 20 dontknows)

i really like the freedom to change my mind myself. give me a good 
reason to switch from postfix including how to implement it with my 
mailsystem and i'll follow... (wasn't easy to convince me to switch TO 
postfix as i really did know what i did before!!)

>>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.


i'm happy with my mailserver. an a couple of my customers are happy too.

the main reason i never published my "solution" is to be unable to 
answer the complaints about why i'm using this and not that package.

to write a hint how i set up my mailserver is not really a big effort. 
but to answer all the questions about WHY is quite a challange. as i 
menntionned, i really can't reproduce my thoughts as i tried to many 
combinations until a got "my" current configuration up and running. my 
best argument is: it's running stable for 18 months. THAT's what my 
customers like to hear: 18 months without downtime!! (ok, we once had a 
power faillure for 90min, and my ups gave up after 50min - but afterward 
the system restartetd without any complaints)

(b)lfs is a great thing, and i really appreciate the effort the people 
"behind" are willing to give to us for free. having a look at the 
current distros i never could convince a customer to use a linux server 
compared to a windows server. current distros install almost the same 
number of unwanted/unused services as any ms-server (or even topping it, 
as ms seems to have reduced the open ports recently in contradiction to 
some well known distros). and my main argument for linux is the absence 
of any unneeded service on a server. the best way to have a secure 
system is avoiding any service running which you don't need. thus only 
gentoo or lfs are a possible solution...

(ok, my last try to install an oracle server on lfs was a nightmare... 
but i got it up and running on another system with a running x-server 
and could transfer the needed components to a more or less bare 
lfs-system without x installed)

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


i don't remember when i wrote a mail this size last time (i'm shure i 
did). sorry for any misunderstandings as english is not my native language.


More information about the blfs-dev mailing list