Some ideas about LFS project
shevegen at linuxmail.org
Mon Sep 22 20:27:24 PDT 2008
=== The LFS Project's Goals
First let me assure you that I think the LFS project is one of the
best AND most important projects to have within the Linux world.
Also please excuse any typos or grammar mistakes - english is not
my native language.
Now, let's quickly jump to LFS, and the project's goal. Why do
I regard LFS as important? Well, this is due to several reasons and
from multiple point of views.
I am rather unhappy with some of the bigger distributions out there.
In essence I believe Linux should focus much much more on ideas.
And one great idea is teaching, be it via wikis, or a project
I think smaller distributions (like GoboLinux or NixOS or SLAX) unite
MANY better ideas than the biggies do. But this also means that I am
often (more or less) on my own or have to wait for small projects
which lack in manpower.
Ignorant or even downright arrogant upstream developers and their
decisions can be really annoying as well, though
luckily the latter type is quite rare. (But it is annoying if they
maintain very important pieces of software. Very very central libraries
... ;> )
One reason why I appreciate LFS so much is because it actually bothered
to teach someone (in this case me) how things work in a quite distribution
I no longer build a real LFS from scratch though, it takes too much time and
effort, but I often use it as reference or to read up on stuff. Automated LFS
is unfortunately a bit too separate from "core" LFS IMHO.
Anyway, thanks for that teaching part so far! It was the first time I
used patch, diff and I think many many lines of sed due to LFS. :-)
Since not long ago there was a bit discussion about "Package management"
- I think I would like to add my point of view briefly.
To me, every component in a system should be as much self-contained as
possible. That means that I dislike the FHS approach of spreading files
around. I believe this FHS approach is less appealing because
(a) it violates a KEEP IT SIMPLE principle
(b) it basically FORCES a user to rely on upstream managers
Something akin to AppDirs are better in my opinion. Additionally, the
dissecting of packages done by so many distributions is really annoying
in my opinion. Stuff gets sometimes crippled and needs to be specifically
set on by the user. Is there an easy way to install all dev files
automatically if a user wants to? Or, install everything the package
"normally" comes with? (when a user compiles it)
I fear not.
But I am not fighting for people to share my point of view, after all
it is just my opinion that these things are wrong and distributions keep
on doing it, and people using it ... ;-)
On to Package Management.
=== Package Management
Someone else commented that it is (or may be) the PackageManagement or
lack of PackageManagement that drives users of LFS away. I am not sure
if this is a valid argument. I am using my own scripts to handle installation
and removal of files, compile it, install it, archive it etc..
LFS is a most valuable resource for me, not only providing high quality
information, but also collecting patches. This aspect, teaching others,
is an extremely important one. If not the most important one in LFS.
Now, what is there that PackageManagement teaches one? I fear not that
much UNLESS you would go deep down to the core (and explain how i.e.
rpm works in detail)
These users will normally rely on their big distribution to solve things
for them anyway. They use ebuilds or PKGBUILDs which one smart guy wrote up,
and then pretty much everyone will use it, or binaries. Which works in most
cases but sometimes can drive them users crazy. In essence though, the concept of
managing packages is trivial. It however is messy. What would be nice would
be for LFS to also include managing a all-into-one-directory approach. And
with this I actually mean one who MAINTAINS such a system on his own, and
NOT a few lines stating that this is possible and then finishing.
Granted the approach yields some other problems, but I'd love to see the
LFS project include this point of view and tests it a bit as well.
The target base is simply different from a "typical" Linux user.
Otherwise I agree that PackageManagement should stay optional rather
=== Unite LFS and BLFS
That being said I must also admit that I think it would be better
- from my point of view as an user - if LFS and BLFS would be closer
tied together, as a "whole package". I know that this is probably
too much work, and may have some other disadvantages as well. I am
not asking at all to present both LFS and BLFS as one project all
of a sudden, but from my point of view I think both projects are
immensely helpful and very very closely related, much more than
any of the other projects like Automated *LFS.
(These days BLFS is often more helpful than LFS to me, because it just
seems to unite more important information altogether, especially after
one has built a "base". There just seems to be a LOT of extra software
one can use.).
The basic thing LFS does for me (unless I fail at some stage ;> )
is to provide a clean system base. Coming to this point however
is also very boring and too error-prone IMHO. I don't think many
people will do a base LFS again and again. BLFs on the other
hand is a real fountain of knowledge. I also use it less often
these days, but this is mostly because I felt that in the past
the information is very LFS specific, but the versions lag behind
each other, or it may require you to have a 100% LFS system installed
or some other reason.
Thus from my point of view I would like to see the both united.
=== Hibernation of the LFS project
I do sometimes feel as if the LFS project seems to hibernate for a
really long time, with hardly any changes whatsoever.
I also admit freely that I find the LFS process is too slow.
Maybe I am too impatient as well but I think the process should be
extremely easy, streamlined - and fun. It was fun and interesting
for the first time when I did it but now it seems more tedious, even
though the process has improved over time. The whole procedure is
sometimes error prone.
Maybe it can be simplified so that errors are less likely to
happen. And releases be made faster or more "daily"I am speculating
and wishing here :)
You see, if both LFS and BLFS are delayed a lot, there is no reason
to keep them that separate. BLFS would probably lag much more behind
than LFS, but sometimes I really think the whole LFS project
grinded to a halt which is not necessary. People who like LFS
will not bother much if information is changed quickly.
And if something made LFS unusable these bug reports WOULD SO QUICKLY
trickle in if the project is alive and healthy.
I simply think the focus on ultra-stability for LFS is not that important.
Or should not be so important.
=== LiveCD / USB
Also, it would be really awesome if the project could cover LiveCD
and USB creation. Like a mini-howto "how to make your distribution
Okay, let me finish that I love LFS! And BLFS.
Yosemite Bug Rustic Mountain Resort
Relaxed, magical 50-acre property 25 miles from Yosemite Valley. Excellent fresh foods, tours, spa & stilted hillside cabins.
Powered by Outblaze
More information about the lfs-dev