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
management:
* An easier way to maintain several very similar machines in the lab
simultaneously. (This is probably the only reason others have as
well).
* 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
time)
(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.
Thanks,
Pantelis
____________________________________________________________________
http://www.freemail.gr - äùñåÜí õðçñåóßá çëåêôñïíéêïý ôá÷õäñïìåßïõ.
http://www.freemail.gr - free email service for the Greek-speaking.
--
http://linuxfromscratch.org/mailman/listinfo/alfs-discuss
FAQ: http://www.linuxfromscratch.org/faq/
Unsubscribe: See the above information page
