language choice of alfs

Hui Zhou zhouhui at
Wed Dec 22 06:55:36 PST 2004

On Wed, Dec 22, 2004 at 11:50:52AM +0100, Joachim Beckers wrote:
>However I 
>still think that the backend should be written in a compilable language 
>for performance reasons. 

Performance is definitely not one of the concern. LFS builders used to 
very patiently wait on those auto tools and I have not 
seen any complaints on lfs lists so far. I will bet that alfs can use 
the worst performance (with bash scripts for example) and the user 
won't notice a bit on the perfomance as long as the tool is robust and 
user friendly. They will just be shadowed by the lengthy building 

One of the big concern is portability. Personally I would like to see 
alfs built on a barebone lfs system. One particular restriction of 
alfs is that at one stage it will have to be run withing a chroot 
environment at which point many runtime depency will be unavailible. 
With C, the app can be easily statified as long as all the function is 
achieved in native code or binary libraries. Perl can also be 
statified with just a bit more effort . Dynamic loading is fine actually
but for some applications they use runtime dynamic loading which may 
occur during the chroot stage. One of problem I hit before is the perl 
lwp module which seems to use dynamic loading to load functions that 
access individual proctocols. I nvever solved that issue and finally 
just moved those internet function to a front end. I never looked 
carefully at python on this issue, could be much worse or better.

There was opinion to use C on the backend and script languages on the 
front end because the backend is more complex. Actually I think many 
front ends or applications especially GUI apps choose Python or Perl not 
because they are less complex, but too complex in C. 486 or 386 can 
run servers well, but GUI applications typically need as spiffy 
hardware as possible, which make me think the front end in many case 
is more perfomance hungry.

Hui Zhou

More information about the alfs-discuss mailing list