Project scope ?

Jay Bennie jay at
Wed Nov 14 07:09:08 PST 2001

Hi Markus, 

It appears that we share some very similar views about how the alfs project can be expanded. :)
I would like to discuss your ideas further and extend you bgALFS "Vision document" - before doing so I think we ought to request a news group for the guys at ALFS, so as not to pollute the ALFS list with these concept issues 

firstly can I address the point you raise in you document:

binary handling - this really goes beyond ALFS: As I already plan to track the files that were created, why not store them and use the binaries for another machine, too? bgALFS should then be able to "import" the binaries and have no problem with dependencies. That gets close to known DEB or RPM packages and should probably support them, too. Maybe you can think of bgALFS as a distribution builder: we could implement rules on how to generate DEP or RPM packages. 

Then again I ask myself: where is the advantage of bgALFS then? isn't LFS meant to build a system from scratch? Here the cat bites in its own tail (sorry for that (most probably) horrible translation).

the advantage is simple to define. 
Currently the creation of pkg & rpm relies on the developer building for a known arch (I.e SPARC, PPC or i386), this is a reasonable restriction at the moment as there is no real alternative. 

A project which provides a method to deploy exactly the same software platform to multiple hardware platforms, would be a significant, improvement particularly when upgrading becomes an issue.  Some may argue that this is a non problem at the moment, but they should consider that in less than 3 years we will have a plethora of hardware platforms to choose from. 

On reflection you are right in suggesting that someone may just use the current lfs project to build a distribution. But I would not expect that person will want to then X-compile that for all his hardware platforms, not to mention installing his 10+ network, ok, I accept that you can just image the disks. The problem as ever is the time you spend performing these tasks.

Envisage this scenario.

the Sys-admin of a 10+ office, has to look after 2 G4's, 8 PIII's an E250 and a cobalt cube. The cube is treated as a network appliance and is not included in this review, except that it provides DHCP,DNS, IMAP Email and Routing/NAT/VPN services over the DSL connection.

The basic software on each of the remaining systems is fairly similar, each have a wordprocessor, text editor, web browser and email client. The PIII are used for software and Multimedia development and the G4's are the funky receptionist machines and are not used for much. The E250 is used to host an E-commerce application written in java and perl. 

A problem with this env is that the PIII accumulate software and versions which adversely affect the deployment of stable software so it is appropriate to manage some king of platform version control. 
it is also a concern that the two G4's are so poorly utilised. 

Proposed solution. 
The E250, need not be introduced at this point
an audit of the software requirements allows the sysadmin to generate a list of required software and the versions. 
the G4's only require to wordprocess, print, email and browse. and look nice in the reception. 

use the G4 no.1 as a master node for the bgALFS env . This env will have an X server. 
Assemble the PIII profiles and down load the SRC in to the repository. 
Build the target image for the PIII's
Assemble the receptionists profile which is a subset of the PIII profile (i.e no requirement for dev stuff) and build the target image for the G4's
using G4 no2 as a slave node for bdALFS install the img. Create user accounts for the receptionists and map shares to network storage( this could even be on this mac) 
using G4 no1. setup the user account for the receptionists so that when they log in to this machine they run as a thin client of G4 no.2, i.e export X 

Deploy the PIII machines and configure for site 

return to G4 no1.and "Grab" the configure information for each deployed G4 and PIII, these are mapped and stored in the repository, hence creating a backup snapshot of the clean env. 

Some questions to help explore this problem
a) How simple would it be to a. introduce the E250 in to this arrangement? (assume sufficient storage on G4 no1)
b) update the packages and configuration of the PIII network and the G4 subset (assume that the profiles are some how linked: below is what i envisage, I expect it will eventually be done is XML, but all we really need is a simple definition of what we want)

// Sub Profiles


// Master Profiles
PIIIDev_Profile {
<Target arch=i386>

<Target arch=ppc>

c) consider that some of the development machines need to be down graded, for a maintenance contract?

d) do these really need to be separate images on a disk, surly an objective is to minimise replication of built and source. - how about introducing an <arch> type tag which defines which architectures the src is suitable for. this would mean that some code can be built for specific architectures or generic. 

e) how do we deal with, packages which are not available as src, but have pkg/tgz/rpm distributions for limited arch's?

f) Imagine that the deployment scope is not for a small office, but provided as an internet service which can service 000's of clients, and is applicable to more than just Linux? - (assume that by the point that development gets to this stage we can begin to look at ways of distributing the server aspects and providing binary caching to reduce compiling overheads) 

g) referring to the technology used in the novell file systems- and I think that some of the guys working on the Ressierfs project may know what to do. partial img segment replacement: the extraction and replacement of parts of a file (binary//txt is irrelevant) at a disk level: theory only sent the bits in the file that actually change, rather than replace the whole file. apply this theory to the update/down grade process.

h) The fundamental aspect of my theory is control, not dictatorship over the env. Personalisation is also important and it should be a point that the aim is to provide a standardised global image(not package) delivery platform that can (limited only by information supplied) build a conforming, personalised system. Packages would still be appropriate for non standard and proprietary software, and care should be taken to design a system which appreciates that the usr is free to use software on this system that takes advantage of the standardisation we would provide. 

J Sorry i got a bit carried away :)
ijklmnopqrs? xyz.


  ----- Original Message ----- 
  From: Markus 
  To: alfs-discuss at 
  Sent: Wednesday, November 14, 2001 9:39 AM
  Subject: Re: Project scope ?

  Hi ALFS group

  Not too confident with ALFS as it is today, I began to think about it myself. As Jay Bennie, I would like to include some more features (especially his points c, d and e, but I'm not sure if I understand everything clearly). Dreaming of the perfect ALFS I began to write some xml profiles and some C source. I called the whole thing bgALFS. And I feel it's time to publish it as it is NOW. Please take a look at: 

  You will mainly find some thoughts and proposals for new features and some xml files... Feel free to ignore it, but every other reaction is appreciated, too! Especially creative critism.



  (P.S. My native language is german, so please excuse all the minor and major errors you will find. Also my naming sheme probably isn't too clever.. But at least I'm always ready to change to the better solution.)
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <>

More information about the alfs-discuss mailing list