Qrux wrote:

> LFS is a great idea.  And, I think it's transcended it's original
> goals of being a "learning system" to being a true "clean system".

Yes, we try to do both.

> Similarly, BLFS is a great idea.  It's "LFS and More".  But, frankly,
> the implementation of both leaves a little to be desired,
> particularly for servers.  For example, few systems are usable
> without basic networking and related security SSL/SSH (its exclusion
> from LFS is a mystery), regardless of whether they are desktops,
> laptops, or production servers.

That's really up to the user.  My first action is to configure the lfs 
applications such as vimrc, inputrc, profile, bashrc, dircolors, etc.

For me, ssh is the first application, with bc and ssl as prereqs. 
Others may have different priorities.  That's the design of BLFS - to 
let the user decide.

LFS is purposely set up to provide users a static IP address for basic 
networking and even supplies a basic ftp client, but beyond that, it is 
the user that decides how to flesh out his or her system.

> Long story short...There seems to be a domain that LFS/BLFS is good
> for (production servers).  But, neither group seems to make a serious
> attempt to provide a "stable release" that shares a concordance
> between version of LFS & BLFS for servers.  

Yes, I use it for production servers, but users still want to be able to 
select what packages they need.  Do you use sendmail or postfix or exim? 
  proftp or vsftp?  mysql or postgress?  python?  ruby?

I agree that most servers do not need X, KDE, or Gnome.  Those three 
environments probably make up half of BLFS.

> BLFS probably needs to
> spend a large portion of time keeping packages like X stable.  X is
> (or, at least when I worked with it, used to be) a monster, so I
> understand that kind of time-sink.  But, servers (and their admins)
> require a more focused effort (even if software becomes replaced with
> a newer version) to keep a snapshot of LFS/BLFS stable.
> 
> TL;DR - BLFS seems too unwieldy to "keep stable" in its current state
> for servers (and server admins).  I see value in producing an
> "extended subset" of LFS/BLFS that's stable (i.e., known to build and
> work correctly).  In your opinion, how would you see that kind of
> project proceed?

I could see a document, or even a page in BLFS, that describes what 
packages are needed in different environments.  What's needed for a web 
server?  How about a desktop?  Version control system?  Software 
development system?

The hard part about splitting up BLFS is that most users will probably 
want portions of a server system and portions of a desktop system.  That 
would lead to almost everyone looking at a "server BLFS" and a "Desktop 
BLFS".

Please continue on blfs-dev.

   -- Bruce
-- 
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page

Reply via email to