Ken,
On Oct 17, 2011, at 7:38 PM, Ken Moffat wrote:
>> 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.
>>
> Ah, a minimalist early-1990s "desktop", from the days when xfree86
> was too difficult for mere mortals to build. I'm sure both of the
> people who don't use xorg on their desktops will be overjoyed by your
> plans.
No, I'm not suggesting that there aren't people who use X. Perhaps I wasn't
clear enough to qualify every sentence with "I'm looking at this from a server
perspective". So, from that perspective, X is a lot of bloat for an OS,
especially if the only reason it's there is because it's part of a long chain
of dependencies. I don't feel that "well, that's just the way it is, and I
can't help if the library I want to use happens to depend on a huge and complex
package like X+WM or X+KDE or X+Gnome" is a healthy way to approach a server.
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.
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.
> 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.
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?
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?
Q
--
http://linuxfromscratch.org/mailman/listinfo/blfs-dev
FAQ: http://www.linuxfromscratch.org/blfs/faq.html
Unsubscribe: See the above information page
