Re: Latest Glibc from CVS has segmentation problems.

["Patrick J. LoPresti" <patl at users dot sourceforge dot net>]

"Alfred M. Szmidt" <ams@kemisten.nu> writes:

> No we cannot, since releases for GNU software are stable, making a
> random release whenever someone asks for it does not make a stable
> release.  Uli (and the rest of the crew) work hard at providing a
> stable piece of software.

So the authors are working toward making a stable release?  I have
seen nothing from Ulrich (or anybody else) to suggest anything of the
kind.

And now I point out, again, that the current "stable" release does not
even compile.

> You obviously do not know what it takes to maintain something as big,
> and critical as glibc.

Right, I obviously have no idea what I am talking about.  How could I?
I am just a "random person".

> And no, it is not like releasing a kernel as you noted in some
> previous mail.  A kernel can be down graded at a whim, or upgraded.
> A broken C library will cause far more grief then changing a single
> line in your boot loader.

Let's think your example through, shall we?

When I change that one line in my boot loader, I do not just select
the kernel.  I also select ALL OF THE ASSOCIATED MODULES, which
represent more files than all of glibc's shared libraries combined.
Those kernel modules all depend on each other, too.  Wow.  How does
that work?  Coincidence?  Magic?  Some mysterious property unique to
the kernel?

No, it works because somebody DESIGNED it that way.  The kernel
installation procedure is what we call a "competent design", to
distinguish it from, say, the libc installation procedure.

The Linux authors did not have to design it that way.  They could have
made kernel installation a subtle and error prone procedure for the
"distribution makers" to sort out.  But they didn't.  I wonder why?

Not that it matters.  Obviously it could never be so easy to change
the C library.  I mean, YOU cannot imagine how it might work, so that
makes it impossible, right?

 - Pat