New design, what is the Goal here?

pak_lfs at pak_lfs at
Mon Nov 28 14:11:55 PST 2005

Mark wrote:
> I've been trolling the ALFS threads since September so I might have
> missed something or just plain got lost in the communications.  But what
> is the overall goal of the new design being suggested?

My general feeling is that there are at least two goals that most agree on:

1. remote management/builds (don't just think entire LFS builds, you may
    just want to update a package (think apache/openoffice).

    Personally, I find several interesting reasons for having remote
         * An easier way to maintain several very similar machines in the lab
            simultaneously. (This is probably the only reason others have as

         * Building/installing on embedded devices (think the netgear access
           point in the MIT roofnet project).

         * Building (parts of) LFS in UML/qemu (for educational purposes).

     If you have no use case for a client/server system that's fine, maybe
     if a large majority steps up and says "I don't like the complexity of
     client/server systems, I want it standalone", we can build it in a way
     that you can choose if you want it standalone or client/server at compile
     (I know of at least one system having this ability -- comterp command
      interpreter from ivtools). 

2. It should be *much* easier to maintain the profiles. Thus, we probably
need a new profile language with this property. I don't see us having yet 
reached an agreement on exactly how it should look like, but I 'm confident
that we are getting close. 

> It sounds like to me a Client/Server system is being purposed that would
> allow us to setup LFS installs on a remote computer.  Sounds neat, but
> why?  I've setup 5 computers now with ALFS.  I did my first install
> under a RedHat distro, after that  I did 3 install with the LFS Live
> CD.  The other 2 systems are only Pentium processors and they can't boot
> off CD (really old, but work great).  So for those, I installed the
> drives in my builder system and did a cross build.  Once I had the drive
> setup for boot I then reinstalled it in the other computer.  Worked great.
> They only reason I could see doing a Client/Server like install would be
> if I wanted to do more then one computer at a time.  But then why
> wouldn't I just build one drive and then copy the image to each drive on
> the other systems?  I can see flaws with my suggestion, like the trouble
> of removing drives or using a tool like Norton Ghost for the images.
> But there are a few problems with remote builds also.

Believe me, this "hard copy" method of copying the whole drive/image,
is not scalable as the number of systems grows. Again, if that's not
an issue for you that's fine, we are a community and we should try to
cater for all members needs, as long as they are reasonable and within 
our abilities/resources.

> I'm not trying to be negative about the project and the suggestions.
> I've really enjoy using LFS and all it's sub-projects, and would like to
> contribute to the project.  I just don't understand the goal and overall
> benefit of the suggestions.  

I hope to have helped a little with the goal part. If you don't care much
about remote builds, It would be nice to contribute your ideas on how
the new profile language/format should look like :)

> I've only seen technical suggestions on implementation at this time, not
> about design concepts. 

On, the contrary modulo the discussions about how to establish a socket
connection between a client and server in C, (every project needs a "seed"
proof of concept code in SVN), it 's all been about the design. But a good
design should be implementable as well, so its natural for everybody
contributing ideas to also think about how they could come to life.


____________________________________________________________________ - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ. - free email service for the Greek-speaking.

More information about the alfs-discuss mailing list