On Mon, Oct 17, 2011 at 08:58:07PM -0700, Qrux wrote: > > At the end of the day, if you're absolutely forced to link your stuff with X, > and have to build it--or, you don't mind deploying X to your server, then > that's your call. I don't care. I'm not suggesting there's no use case. > I've had to admin servers that happened to have X on them. I'm not saying it > doesn't exist. I don't think it should be there--and you seem to be saying > the same. I'm not sure what your gripe is. >
BLFS is about many things. Looking at questions on support, I get the impression that most users are putting it on desktops. If I thought otherwise, I would be even more worried about the lack of interest in vulnerabilities (see my posts on -dev about why I stopped contributing, probably at the beginning of this year). > 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. > > And no, I don't think that xorg has any place on a server, but even > > those of us using minimalist desktops (I prefer icewm) expect a bit > > more than what you are offering. > > > In case it isn't obvious, I don't see how your "minimalist server" > > build is going to satisfy most BLFS users. > > No one is asking you to run just the "Core". I was proposing a subset of > BLFS be identified as "this subset is sorta cruft-free". Then, you can pile > on as many layers of X, then Y, then Z, that you want to have, over it. I, > OTOH, will probably just install Xen or LAMP over THAT SAME "Core", depending > on whether it's in DomU or Dom0. > 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. > I emphasize "THAT SAME" because the point of this is to find a shared subset. > I don't care what you put over it. So, I say again: I'm looking at this > from a server perspective. Of course I understand that there are people who > use X as their main desktop UI. Fine. So, between those folks, and me (and > I'm sure others who might like to deploy LFS/BLFS as a server system, because > it seems particularly well-suited, at least in principle, for that task), I'm > fairly sure we can find some kind of overlap area of things that we would > both like, without having to have X on my side of the aisle. I don't care > what's on the other side of the aisle, or if there are other aisles, or > what's on their sides. Furthermore, I'm not--in any way--doing this to > prevent folks from running X. > > I do keep saying "common shared subset". Something about those words suggest > an ulterior motive to you? > Only the amount of things you put in it :) > I mean, I assume (perhaps tacitly, given your concerns) you're building LFS > before BLFS. Why not think of it as a 3 stage process, (something like LFS, > BLFS "Core", BLFS-everything-else, where some folks can choose to get off > after "Core" and do their own thing? Is that so onerous? Perhaps people would prefer a recipe that says "build a+b+c, then your choice of k,l,m,n,o and x+y+z". For myself, packages which don't earn their keep drop out of my builds - I'm around 400 packages on my desktops (of which the parts of xorg that I build, and the parts of gnome I use or need for certain applications, are the main constituents). So, adding anything to the basic list of packages is not something I'll lightly do. For me, it doesn't actually matter how the book develops - I'll go my own way whenever I have to - but I'm concerned whenever changes seem to make it something it can't really be (e.g. suitable for production servers - fine, if you monitor security issues, but for the moment very dangerous if you don't), or to limit its general usefulness. And yes, I do build LFS before the (mostly desktop) parts of BLFS that I use. I'm out of touch with current LFS (took a break just before 6.8), but reasonably up to speed on desktop packages. In fact, whenever I build LFS to test the book, or to test possible changes to it, I always build my normal desktop (to be fair, most of it is usually newer than what is in BLFS) - I expect to keep using LFS, so I have to make sure it works for me, and will be testing 7.0 once I've reinstalled my server (using 6.8). BTW - please don't treat this as an attempt to deter you from editing BLFS, I've spent enough time on that unpleasant task, suffer it if you wiah ;-) ĸ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
