BLFS-6.4RC1 or any

Mike McCarty Mike.McCarty at sbcglobal.net
Mon Feb 15 23:32:39 PST 2010


Simon Geard wrote:
> On Mon, 2010-02-15 at 13:59 -0600, Mike McCarty wrote:
>> Since I'm on the verge of starting in to build BLFS, it would
>> be helpful to know when the next release may be available. I
>> realize that can be very difficult to estimate when you do something
>> not full time. What I'm asking for is order of magnitude
> 
> If I were you, I'd not worry about official releases too much. I've
> always found the development books (for both LFS and BLFS) to be stable
> enough for use, and for the most part, development BLFS can build on top
> of any vaguely recent LFS.

The issue is trying to hit a moving target. I'm not going to try
to do that. If the book is still changing, there is a reason. I may
find out what that reason is, before the fix is in.

So, that's probably one of the reasons you are not I. That probably
wouldn't bother you as it does me.

To put it another way, my time is my life. Any time I devote to
something is a part of my life paid for it. I have been doing
software development and support professionally since 1980 or
thereabouts, and kernel and device driver support since 1982,
and hard real time kernel/driver/firmware/boot since 1986.

It is no longer something I do for "fun".

I want to build it, install it, and it works. If I could find
a standard distro which didn't contain not only the kitchen
sink, but 100 kitchen sinks, all in the bathroom[1], I'd just
use one of them. (B)LFS is not my first choice, it's my last
choice, but it looks to be the best choice, given the way
the standard distros "work". I have given up trying to
wrest control of my machine from the distro supporters, who
think they know better than do I what should be on my machine.

I'm not attracted to (B)LFS so I can learn how an OS works.
I know how they work. I wrote my first small multitasking
RTOS in 1984, for the 8085 uP on the S-100 bus, using the
RMAC macro assembler with CP/M as the development system.

I'm attracted to (B)LFS because, unlike with a standard distro,
I actually get to chose what gets put into it, and I like lean,
not fat laden.

[1] An example of that is spending several days trying to track
down why my main partition was suddenly tight on disc, and finding
out that the Open Office software had automatically "updated" and
installed a couple of GB (yes, gigabytes) of new fonts for
Czechoslovakian, Polish, Ukrainian, etc., none of which I use,
along with a couple of other packages which had "grown". When
I pared out the "updated" stuff I didn't need or want, I regained
about 3GB of disc. An example of endless arguments with distro
maintainers is whether to install SELinux, which I adamantly do
not want and consider to be a menace to my system's stability,
and PAM, which I don't see the need for on my single user system
behind a hardware firewall, and which the maintainers of two
distros I've sysadmin'd insisted was absolutely essential to
every Linux install on every system. I hasten to add that the
issue here is not whether anyone agrees with me about this,
the issue is that the distros do not give me the ability to
control what is on my machine. Even the "light" distros, like
Feather Linux, while not fat laden in the sense of many many
applications installed that I don't want, they still have SELinux,
and PAM, etc. in them, because the original distributions
(for Feather, this is Debian) have them built in, and the "light"
version is simply a smaller selection of apps with the fat built
in. SELinux, for example, affects, according to the official
information from Red Hat, forty (40) necessary applications,
along with the kernel.

Now I wonder whether I've spent too much of my life explaining this
stuff. :-)

Mike
-- 
p="p=%c%s%c;main(){printf(p,34,p,34);}";main(){printf(p,34,p,34);}
Oppose globalization and One World Governments like the UN.
This message made from 100% recycled bits.
You have found the bank of Larn.
I speak only for myself, and I am unanimous in that!



More information about the blfs-support mailing list