On Oct 16, 2011, at 10:56 AM, Bruce Dubbs wrote:
> 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.
--==[ Skip to the bottom for a TL;DR summary. ]==--
Perhaps. But from the POV of a "vertical" (or "domain") like "production
server" that prefers--or even requires--a "release" structure of releasing
software (as opposed to being told to use the dev version out of SVN because
it's probably in better shape), BLFS is working hard--but not exactly
succeeding.
>
>> 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.
Yes, it's up to the user. Which is why I framed my example, by saying: "for
example". My point was--I don't care WHAT *you* decide to do--I care that
there isn't a "stable release". I was diplomatically--though, in retrospect,
perhaps too coyly--suggesting that BLFS is quite possibly too large to manage
as a "stable release", (which ought to be obvious to the most casual observer
from the never-ending-dev state that it's in), and that there might be a
different approach, like defining a subset that's useful to say, 90% of BLFS
users, and keeping that subset small enough to have "stable releases"...
> 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?
Obviously I'm not being clear. I'm suggesting (again) that BLFS is probably
too large to maintain with "stable releases" (and this issue has come up
before, regardless of whether the answer is that someone feels some particular
book maintainer is an a*shat, or whether there are too many dependencies, or
whether someone can't compile the book and that's their stated excuse for why
the book is hard to keep up to date). The point is, I believe strongly that
BLFS could be much more useful by supporting a "stable release subset" of what
is current BLFS, because this particular domain (i.e., production servers)
would be better served by a "stable release" mentality. And, I happen to
believe it's probably possible to figure out what that is...
So again, I use an example (try not to confuse this example with: "this is what
I feel is fact"): most platforms need SSL and SSH. So, such a "stable release
subset" that someone maintains in lock-step with LFS might include SSL and SSH.
And, be able to release concurrently with LFS (or, at least, within a very
short time after LFS is rev'ed). It would seem like it would fill a great need
to identify what that subset might include.
In essence, this would be defining something between LFS (largely unusable) and
BLFS (largely bloated for the domain I'm discussing, which is production
servers), for the purpose of defining a subset that most (if not all) domains
would *SHARE*. Even your examples (vimrc, inputrc, profile, bashrc, dircolors)
fall neatly into the category of "hey--this is probably useful for people in
multiple contexts, whether that context is desktop, laptop, or server." And,
because such a subset would be a...subset...it would be...smaller...and perhaps
easier to maintain as a concurrent stable release with LFS.
I'm not talking about "choice". I don't care if you use Postfix for Exim. Not
every system requires an MTA. Certainly not every system requires an RDBMS.
But, /etc/shadow? Surely we could make good case there. Sudo? Probably.
NSS? Can you come up with a good reason *not* to have NSS? Vim? Tcsh? PCRE?
libxml? hdparm? zip/unzip? cpio? Sysstat? Surely a reasonable case could
be made one way or another for those packages, right? On the flip side, every
X-related thing could be taken out of this subset. And, most scripting
languages (Perl, PHP, Python) are all reasonably "extraneous". Lots of "server
services" like samba or DNS or MTAs. Certainly big DBs, LDAP. Aren't we about
half-way to a consensus already?
> I agree that most servers do not need X, KDE, or Gnome. Those three
> environments probably make up half of BLFS.
Exactly. That's a 50%-labor reduction. Don't forget all the media stuff.
ALSA, imaging libs, DVD stuff, codecs, etc. All of X, KDE, Gnome. All
printing, scanning, and random hardware needs. And all those packages could be
maintained separately, and not contribute to the inability to create stable
releases that are shipped with (or nearly-with) LFS. Aren't we about 75% of
the way there to a consensus about a subset that could be maintained as a
"stable subset" that could be released in close timing with LFS?
>
>> 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".
>
I'm talking about a subset that's shared between what you see as different
"verticals". The point is, there has to be something between LFS (too little)
and BLFS (way too much in almost every context). Just looking at the SSL/SSH
example, there's been a recent conversation about ca-bundle. This is clearly
an area of overlap. Have I just stumbled upon the one example (SSL/SSH/certs)
of something that happens to be overlap? I happen to not think so. What about
man pages, for instance? That's something that could be used by everyone, with
reasonable rationale for most verticals.
The question is: do you--and the people who maintain BLFS--feel there's simply
too much fragmentation (or religious nonsense) between what people consider
"Server BLFS" and a "Desktop BLFS" (or whatever other verticals you consider
there to be) to come to some reasonable consensus of what would constitute
overlap? There are all sorts of things that are "infrastructure" that both
sides would want. And, with a certain amount of "maintainer license", some
knowledgeable person (BDFL) could say: "Well, we're not including that. Refer
to BLFS if you'd like to use it, and please understand that given the size of
BLFS, you may have to work in a dev version, where you may need to 'tweak'."
############################################################
#
# BEGIN TL;DR
#
I contend that it's possible to come up with what a good subset of BLFS might
be that would serve most folks--whether using BLFS as a server or laptop or
desktop platform, whatever--and that that "overlapping subset" can be kept
small enough to be maintained in a "stable release" paradigm and released often
enough to keep pace with LFS.
I mean, if you took out all of Sections 6, 7, 8, 9, 10, and 11, (X and all of
its associate bloat), you'd be removing around (just a quick visual estimate)
about 200 packages. Which would leave sections 2, 3, 4, and 5 (with maybe 170
packages, with a lot of "core" libraries). So, even if all one did was to trim
the book from having 10 software sections to 4, that seems like it would go a
long way to approaching a subset that could be maintainable. So, instead of
EUTSLFS (Everything Under The Sun), maybe we could have a BLFS that's "stable",
and a EUTSLFS that's maintained separately, and always a "work-in-progress" for
people who need to create systems that have their USB robots feed papers to
their scanners to create some random image input and have some crazy image
processing done to generate a random X screensaver that produces a pleasant
melody to go along with that OpenGL-accelerated screensaver that's managed by a
distributed Postgres cluster and produces pie chart a
nd bar graph reports in OpenOffice documents. While cool, that percentage of
the BLFS user-base is probably small...
#
# END TL;DR
#
############################################################
> Please continue on blfs-dev.
>
Done.
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
