-------- Original Message --------
Subject: Re: New Blfs
Date: Mon, 17 Oct 2011 18:51:41 -0700
From: Qrux <[email protected]>
To: Bruce Dubbs <[email protected]>
On Oct 17, 2011, at 1:04 PM, Bruce Dubbs wrote:
> This is a good, thoughtful, discussion. However I won't quote the whold
> message.
I'm glad to see some traction on a fairly obvious issue. I have some
time coming up that I would like to devote to solving (or, even,
understanding better) the
"BLFS-is-too-big-for-it's-own-good-as-a-single-release" problem. I may
be interested in maintaining a subset of BLFS, but I think it needs to
be more concretely defined.
> that has been one suggestion. I've thought of splitting BLFS up into several
> books:
>
> BLFS-Base (including servers)
> BLFS-Xorg
> BLFS-KDE
> BLFS-Gnome
Yes, basically I'd like to start here. I'd like to take a step further,
and refine what you're calling "Base" into an even smaller subset. And,
like you suggested, take all the Desktop stuff, and bundle that together
(I don't pretend to know how to compile that complex array of software).
That can NIMBY for now, and remain an issue for some other hungry
maintainer.
>> 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...
>
> OK, you've made your point here. Now we need to get more general agreement
> about what exactly to do and probably more important, who is going to help.
I'm interested in examining a smaller subset of what I think you're
calling "Base" (which is essentially a pruned version of these sections):
II.3 - Duh
II.4 - Probably everything
II.6 - vi clone and 1 non-vi clone
II.7 - tcsh, ksh
III.8 - most of the stuff here
III.10 - bc, screen
III.11 - hdparm, zip/unzip, rar, pciutil, usbutil, pkg-config, cpio,
sysstat (unsure about D-BUS/HAL)
IV.13 - DHCP (I disagree about PPP, but maybe a case could be made
concerning VPNs)
IV.14 - cURL
IV.16 - inetutils, ncfp, net-tools, ntp, openssh, rsync (disagree about
Wireless)
IV.17 - all but wireshark
IV.18 - procmail, mailx
V.19 - openssh, nfsutils, xinetd
For the things I ignored...
II.5 - File Systems
If you need the user-land tools, well, that's the beauty in the choice
of the full BLFS. You can add user-land tools.
III.9 - Image Processing
I completely disagree with this. Some people run LAMP. Some LAPP.
Some are using Node.js. Some are using JSP. Some are doing CGI/Perl.
Some people are running NTP servers. Or Mail servers. Or DNS servers.
Or want a Xen cluster, without a bunch of userland. This is not a
basic need, and none of the stuff in the list above, which I'll call
"Core", for lack of a better name depends on these image libs. While
it's popular, it makes more sense for a LAMP person to maintain a
BLFS-LAMP, and a Node.js person to maintain a BLFS-NodeJS, both of which
can be built from "Core". A lot more on this "downstream proliferation"
below...
III.12 - Programming
Same argument as above. Not everyone uses the same language. I don't
need Perl and Java and GCJ/Boehm-GC cluttering up my install.
Personally, I would install "Core", and then deploy my own LAPP (Apache,
PostgreSQL, PHP) solution on top of "Core". I might even be willing to
maintain that. But, forcing everyone to have DejaGnu, Doxygen, the JDK,
PHP, Ruby, Python, and Tcl, again, seems excessive for "Core".
>> 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)
>
> I disagree here. LFS is like a cake out of the oven. You have to add icing,
> but it's a good stable foundation.
I think we're on the same page, if you take out the pedantry. All I'm
saying is that no one uses LFS without, as you say, the icing. So,
"Core" can be the icing, although, I happen to think painting is a
better analogy. I think of "Core" as "primer". What stuff you put on
top of it (LAMP, LAPP, Node, DNS, Xen, etc) is the "paint". It's all
about abstraction, right? LFS is the super-abstract base system.
"Core" could be a slightly less abstract system but still compact.
Can't do much, but the tools and infrastructure are there to build what
you want.
>> category of "hey--this is probably useful for people in multiple
>> contexts, whether that context is desktop, laptop, or server."
>
> The only thing I can think of that is laptop specific is wireless-tools. That
> should be a part of a base system along with dhcp.
I don't care enough about this issue...I disagree, but wouldn't let it
stop me from putting it in, if it was easy to do.
>> 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".
>
> This is where it gets tricky. php has a huge number of optional dependencies
> including Xorg, but it's not required. Php is a pretty fundamental program
> for a server using the LAMP paradigm.
And, getting back to the issue of what is "recommended" vs. what is
"choice". I realize these are the "rubber-meets-the-road" type
decisions, but I find it easy to say that application deployment
platforms are "choice". I don't think a text-editor is. So, use vim
from LFS, and put in a non-vi-clone (say, Joe, Pico, whatever, from
BLFS) to accommodate other folks.
> I recently was building a Qt4 based application on a server. I did not want
> any graphical parts, but found that I could not build Qt without Xorg.
X, IMHO--or, vain opinion, whatever you like--is the root of all
dependency evil. And, this is particularly true for server deployments.
We really need to find a "core" that compiles without all the bloat
and cruft that comes with X. LFS--and to some extent--the idea behind
BLFS is so great for a server deployment, due to the cleanliness, but
all that goes out the window when X is in the picture. I think a good
first goal is to find a "Core" that can be complete divorced from all this.
Let the desktop users decide how they want to recompile everything if
they want X support. Emacs builds fine (or at least, used to, back in
my day) without X. It also builds with X. Similarly, to the extent
that some packages depend on X, let's first try to excise them from
"Core", and, if not possible, to create a separate "build" (or build
instructions) that can be released without dependencies to X.
>> Lots of "server services" like samba or DNS or MTAs. Certainly big
>> DBs, LDAP. Aren't we about half-way to a consensus already?
>
> There are a lot of things we can agree about, but the details need to be
> ironed out. I'm afraid that any possible solution will have significant
> drawbacks. It all boils down to 'how do you handle dependencies'.
Agreed. As above, get rid of the monster that is X. Learn to break
those dependencies cleanly first, is the first good step toward having a
clean "unix-y" "Core", without all the heft of the Desktop and GUI.
>>> 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?
>
> Here's another issue. I needed to create images for display on a web server
> (capcha). I was able to do that without xorg with imagemagic, but it took
> research. The same can be said for other packages like jpeg and png. For a
> server based BLFS, those packages need to be included.
Sure. So, create a BLFS-LAMP. This leads back to what I had suggested
(perhaps not clearly enough) a few months back, the last time there was
a "discussion" on this issue. Surely someone who cares about
BLFS-LAMP/LAPP/Node.JS/DNS/Xen/whatever could maintain their parts, on
top of "Core". "Core" simply has to make those other packages
possible...Not to supply all their libraries, too.
I appreciate the idea behind choice, but often it becomes a litany of
painful choices. In general, there are a few "popular" ways of doing
things. Beyond that, people are already on their own anyway. For
example, very few shops that I'm aware of run both MySQL and PostgreSQL
concurrently on the same scale (sure, maybe someone embeds MySQL in a
blog, but few are hosting their apps across both databases). So, let
someone do LAMP, and someone else do LAPP (I'm abusing this example over
and over again, I get that, but it's easier than coming up with a new
example each time. Substitute your own version of religious leaning or
competing software). To the extent that there are conflicts among
dependencies, fork. And, people who have "unique" needs would need to
do their own "tweaking" anyway.
And, yes, while I realize that has the potential to create a lot of
"downstream" BLFS projects, that's also part of the "beauty" of choice.
Maintainers have a choice to say: "Look--this software isn't so
compelling that we need to keep spending countless man-hours making sure
it compiles. The alternative works, and it's not worth the hassle."
And, solutions that serve the 90% are the solutions that most of the
development effort should go toward. At the edges, if someone wants to
implement a PDP-11 simulator environment and write their web-app with
Fortran...Well, that's their choice--and their hassle.
It's probably okay, over the long run, that the maintainers shape which
packages they choose for inclusion in any part of BLFS, whether it's
this "Core" I'm talking about, the "Base" you refer to, or any
"downstream" packaging (like BLFS-LAMP). But, so? If, over time, the
hassle of maintaining LAMP and LAPP for those two maintainers exceeds
the value of either LAMP or LAPP, then is it a problem that one of those
"downstream" packages fades? No...It's just a representation of the
state of development and the value proposition of those platforms.
> However, I think your view of LFS and BLFS is not what we intend. LFS is
> designed to build a base set of packages upon which users can build custom
> systems...
This is not entirely true...I think my view is somewhat orthogonal to
the existing state of LFS/BLFS. I understand they are books--and that
choice lies at the center. But, it's also obvious that that choice is
precisely the morass in which all development has lost momentum. I like
that I can choose Postfix over Exim. And that it's not going to break
my install. But, that depends on those packages being somewhat
stand-alone. Like you say, each page in the BLFS book is intended to be
stand-alone. But, come on...Once we're looking at X, all those pages
are inextricably linked. That choice starts to become a serious
liability in the long-term maintainability of BLFS.
Let's focus on what we agree on; that BLFS is too large and no one is
working on it. Pruning it down to a "Core" subset, and choosing a few
popular "paths" or "downstream packages" like BLFS-LAMP, BLFS-LAPP, etc,
might make it possible to maintain. If I understand your concern
properly, I think you might be seeing my POV as turning BLFS into a
large collection of "domain-specific books". And, while I don't have
any personal qualms against that, I do see how that might give you pause.
Dependencies should be like onion layers, right? You can prevent all
the "domain-specific books" by bundling them together in "equivalence
classes". Like, all the Desktop/X stuff. Or, all the application
deployment stuff. And, still preserve the flavor that there's choice to
be had ("Oh, I can choose twm or mwm or WindowMaker or KDE or GNOME or
whatever-else-flavor-of-the-month WM is out there"). Like: "Hey, I do
web stuff, and I want MySQL and Node and the JDK," and that person can
find it in the BLFS-AppDeployment book. And, I do realize that
"Dependency Hell" is very real place. I just think that a survey to see
which parts of BLFS are shared by "most" users of BLFS could be gathered
into a separate, smaller, book, and thus be more easily maintained.
While I would personally be fine with book proliferation, (I believe
that the meritocracy of free software will prune those naturally), I'm
also fine with a view that tries to keep the number of books small. In
the end, I don't think there will be any difference. All that matters
is that someone maintains it. Whether it falls out of favor because not
enough people use it, or all the maintainers stop caring about it, or
whether it's simply poorly engineered with a ridiculous set of
dependencies...Just let those packages drop out naturally for being a
"bad citizen". What difference does it make whether that package is in
one book with everything else, or in 15 other books, and those books
don't get maintained?
Let's focus on getting that bottommost layer "refactored" and maybe
finding a maintainer or two. Worry about "downstream" stuff as it's
needed. Frankly, I think enough packages of the "downstream" variety
compile just fine with configure/make/make-install that some of that
will solve itself. But, the gaping chasm between having a system boot
with LFS and then having a "usable" system with "BLFS-version-unknown"
is too large, and, IMO, represents too large a hurdle and risk for many
to take the plunge, despite whatever initial attractiveness LFS/BLFS exudes.
>> 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.
>
> That's possible. But who is going to do it? The reason that BLFS has not
> done releases is a lack of maintainers. Look at the change log. One change
> in August and one in September. I've got some changes about ready, but I
> can't do what I do for LFS and all of BLFS too.
>
> We need to get input from others.
You're absolutely right here. What's the best way to attract more input?
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
