LFS Future Braindump
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.
> 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
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.
> 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
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
[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!
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