Folks,
I have debated broaching this subject for several weeks. Dont crucify me
too bad.
Although I have only been working with LFS for about a year, I have over
20 years in IT, 15 years as a unix System Admin, and 10 years dedicated
to automated system builds.
I know how difficult it is to do what you do and I understand that
choices have to be made. There is a lot of very hard work here
and I dont mean to belittle that by any means. I wouldnt be anywhere
near
where I am in my efforts today without the LFS approach and community.
I want to give back somehow.
Consider this as feedback and feel free to file it as you see fit.
Please forgive me if anything here is incorrect. I have never actually
executed nalfs
I do understand that many of these points I make are arguably just an
opinion.
The first thing I looked at in LFS was the automation (current tool and
proposed reqs). I found a few conceptual "concerns" that turned me away.
1. There is no end-to-end bootstrapping capabilities
2. It doesnt appear to allow for a well organized and self contained
working environment to create a pristine build
3. The tool cannot be used with a base LFS system.
4. XML may be a wave of the future, but it has nothing to do with basic
Linux and the
goals of LFS. Why should I have to learn and use it if wont help me
after the system is created? (I dont like Java or the "M" word either)
5. Any secondary "engine" required to parse commands denotes a
limitation.
What if it doesnt handle something exactly the way I want it to?
6. I dont see anything dealing with packaging, versioning, and layering
of the resulting builds.
7. (I personally dont like the licensing - but thats not a technical
issue)
Although in many applications I am sure this is nothing short of a
miraculous tool,
I cant use the current or proposed ALFS project approaches.
I am not suggesting that the current direction should not be continued.
Only wondering if I am the only one who would like to see an
alternative?
So I wrote my own. end-to-end, bootstrap to installable cd creation,
fully automated and menu driven, Nothing but Bash. (Just because its
bash doesnt mean its a novice approach, it can be maintained and tweaked
by a lot more people that way -
more available developers)
Im far past base LFS and currently working on various and asundry tools,
NON-LFS additions (web100/speech/etc), and BLFS application installs.
I have been through all this once under the 5.1 LFS release, Im
currently
upgrading to 6.1 (base LFS is done), making it a bit less tailored to my
specific needs, and general cleanup in anticipation of going public with
it sometime in the future.
Dont get me wrong - the stuff I have wont do cross compiles,
hasnt been tested with many architectures, doesnt yet easily provide for
tailored compiler options, and needs to be more generic in some of
its approaches. I am not a Linux internals expert, I am not an expert in
compiling software, but I do have extensive experience in managing
integration, releases, deployments, and build automation. There is a
lot of room for improvement in the code I have, but hey - Im just one
guy with 5 machines and a full time job.
I dont yet have the resources to look into making this code available to
the
general public (mostly those annoying licensing issues that I hate so
much but some coding too).
Seriously, Im not trying to knock whats been done already - Im sure its
a great tool
under the right circumstances, Im not trying to say what I have is
better,
but it is different.
Your software is out there for everyone to see and use - mines not
(yet),
You must be the pros. With all due respect - Im following in ground you
broke.
Is there any interest in looking at an entirely different approach to
automation?
Or is everyone pretty happy with the current direction?
Feel free to tell me to take my football and get out of your baseball
game.
:o)
Chuck
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
