On Tue, Oct 18, 2011 at 12:04:50AM -0700, Qrux wrote: > > On Oct 17, 2011, at 9:42 PM, Ken Moffat wrote: > > > On Mon, Oct 17, 2011 at 08:58:07PM -0700, Qrux wrote: > > Perhaps. But, being "everything to everyone" is probably contributing to the > fall-off of maintenance. That may be the case, that it's about many things, > but maybe that's part of the problem. > > You have a view of the users that I don't, since I'm not looking at the > support issues. OTOH...There is such a thing as a vocal minority. And, > given the complexity of the X-and-friends build (this is a sign of respect > for the complexity of X/KDE/Gnome/etc, not a sign of derision) I would > suspect there would be support issues. Heck, even with LFS, there are a fair > number of folks asking questions that just aren't reading the book carefully > enough. I could only imagine for X. Plus, if someone is learning Linux, and > finds the idea of building a whole setup from source, aren't the chances > pretty high that that person is going to run into issues? > Actually, xorg is now so scripted that it doesn't have a large user support visibility. There *are* always people using old/obscure hardware (like me, for the moment) who get issues in video drivers / Mesa. Actually, looking back at recent times, there is very little on blfs-support, other than for things beyond BLFS. Maybe all the users have already left :-(
> As for why you stopped contributing...It seems like a variant of the issue > we've been discussing. If there were a smaller "Core", wouldn't it be easier > to track the vulnerabilities? It would at least be easier to say: "Well, > we've 'audited' this subset. It seems okay." > I long since gave up logging vulnerabilities for packages I don't care about. The problem is that updating a random package sometimes breaks one of its users. The case I remember most was a libxml2 vulnerability which broke abiword (I use both packages, ISTR that in that case I moved to a development version - not suitable for the book, and the book stayed with an old, possibly broken, version of abiword. Also, I don't pretend to audit the packages - I read the vulnerability reports I become aware of, and sometimes decide "better safe than sorry", or other times (e.g. application crash) decide that the risk *seems* low to me. > >> I'm also not saying to remove X from BLFS. I'm suggesting that there's an > >> area of overlap (this is getting to be a unfortunately repost, > >> essentially, of a prior message) between both desktop users (yes, this is > >> a legitimate use, I never said it wasn't; I've used X on my desktop > >> before) and server users, and that there ought to be an identifiable > >> "Core" that's usable by both modalities. > >> > > The common ground between desktops and servers is, in my opinion, > > regrettably tiny: pkg-config (when not in LFS), which or a variant, > > maybe pcre, maybe cd/dvd writing, openssl, openssh (server vs > > client), perhaps pcre, ntp, maybe mail, maybe rsync, maybe nfs, > > and perhaps docbook and python. There are other things I always > > build, but many of them don't really belong on *production* servers > > (e.g. strace etc - essential for an editor expecting things to break > > when the toolchain is updated, but probably yet another attack > > vector on a production server). > > > So, I don't think that putting these, plus the other packages you > > care about, into a 'core' is helpful. > > Well, "production server" means many things to many people. For some, (and I > might infer you're in this category), they might think of the ideal as being > a mathematically-provably secure machine with exactly no more attackable > surface area than the application/port/protocol/IP/MAC you've defined, with > provably secure code everywhere else. For us mere mortals, we typically have > to rely on commercial distributors to update their software, whether it's a > commercial Linux distributor or a Win/Mac/Other situation, or we are Linux > admins, and try to do our day jobs while still trying to keep our machines > from being totally porous. > No, I'm a mere mortal - for me, a production server is publically visible. Fortunately, I don't have to support anything like that. > > > >> > > But, your core already appears to contain things that I have no > > interest in, nor need for. The strength of BLFS has always been > > that you can pick the things you want. The idea of a 'core' implies > > it should always be built. > > What's the big deal? Just take out what you don't want. You're the one > inferring "always". I'm saying "this is a useful subset". You read it as: > "You must use these things." No one is saying that. > > I think Bruce made the point succinctly when he said that even with LFS, > you're free to strip out packages when you're done building. You're free to > take things out of "Core", if you're even more minimalist. It's not like > using "Core" is a contract that says you can't use '/bin/rm' or maintain the > system however you want. I'm not sure what the complaint is. I'm just > talking about identifying a subset of the book that could make the claim: > "Hey--if you build these things, you get a hugely more usable system, even as > a bootstrap to build the apps or services you need, because...umm...you can > log into it from another machine, have accurate civilian time-keeping, be > able to basic network-y things, share files, and make backups." This is not > worthless. > > Yes. The idea of a "Core" is that you SHOULD build it. And, along with > that, it will provide features. I think we covered that twice. Just like > with LFS, you should build a bunch of it, if not all of it. Do you have to > keep it? Nope. Do you have to keep what's in this "Core"? No. > I'll prefer not to build core items that I don't want (if there are any), but if it makes getting a release easier (to be honest, I don't think it does - see my previous post re starting from a clean slate, and deprecation), maybe it's worth doing in thebook. > > Not sure what point you're making here...I can't help but feel a bit trolled > here...which is unfortunate, since I'm making a genuine effort (is that not > cool these days?) to understand the issues that BLFS is having. Who is > adding anything? ATM, I don't think the proposal is more than a > reorganization of the packages so that those not building Desktop platforms > can have a set of packages that's divorced from X. If you're building a > Desktop...Who cares? Run 4,000 packages. Or 400. Or 40. > My impression of the current -dev book is that you don't need xorg for the server packages (with the exception of cups, which you might want on a server), although there are cases where optional dependencies do bring in xorg. So, slimming the book down implies, to me, throwing something away. And I'm not trying to troll, but I do have a lot of baggage from my past experiences editing BLFS. > [ snipped most of your reply because (a) I have no interest in degenerating into a flame-fest when you are attempting to contribute, but it seems I've upset you enough that we could easily do so, nor am I interested in the minutiae of hair-splitting, nor counting the angels on a pin head (a number as close to zero as makes no difference), and (b) your long lines make it too awkward to reply to points within them - I can't even get the next line onto the screen, and (c) I don't have the time. ] > Come on...This is pedantry. I've been an editor, I suspect it goes with the xml ;-) ;-) Someone earlier today made good points about what is wrong with the phrase "core". I would like to see a released (but reasonably current, and useful) BLFS. If the discussion helps toward that, all is good. ĸen -- das eine Mal als Tragödie, das andere Mal als Farce -- http://linuxfromscratch.org/mailman/listinfo/blfs-dev FAQ: http://www.linuxfromscratch.org/blfs/faq.html Unsubscribe: See the above information page
