language choice of alfs
zhouhui at wam.umd.edu
Wed Dec 22 06:55:36 PST 2004
On Wed, Dec 22, 2004 at 11:50:52AM +0100, Joachim Beckers wrote:
>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.
More information about the alfs-discuss