Linked by Thom Holwerda on Wed 6th May 2009 17:41 UTC, submitted by diegocg
Debian and its clones Via LWN, we found a blog post of a Debian maintainer which announces a new package: EGLIBC, a compatible reimplementation of the GNU glibc which "which will soon replace the GNU C Library". Apparently the primary reason is the sadly famous bad maintainership aptitude of Ulrich Drepper, the main libc maintainer.
Thread beginning with comment 362153
To read all comments associated with this story, please click here.
NOt really sure what to think
by darknexus on Wed 6th May 2009 21:24 UTC
darknexus
Member since:
2008-07-15

I can't help but be a bit concerned about this. On one hand, yes it's good to get away from projects if their maintainers are unreasonable and/or are being assholes.
But on the other hand... This whole thing smacks of re-inventing the wheel yet again. I guess they've done it with every other component... why not the C library now. What, messing up the audio stack getting boring? They claim eglibc is binary compatible with glibc--personally, I'll believe that when I see it. How long until we encounter some function that behaves ever so slightly differently under an obscure condition that made it past the compatibility and regression tests--assuming they did any, of course? It's bad enough having to take into account all the different library versions and combinations we have already... and now we may end up having to add the C library--the most basic and what should most definitely be a relative constant--into that mix.
I know I'm going to get flamed by the Linux croud, but this is bloody ridiculous. This is why, from a commercial developer's point of view, Linux is often a laughing stock. They're replacing this, upgrading that, and forking the other on a near-constant basis... how the hell is anyone supposed to keep track and account for all these various combinations? Unbelievable, and rather pathetic when you come right down to it.

Edited 2009-05-06 21:28 UTC

Reply Score: 7

bnolsen Member since:
2006-01-06

I don't see how this is offensive...or how Linux isn't good for commercial development. An application can be compiled with a specific "max version" of symbols to use. elibc could provide compatibility with say (for example) glibc 2.4 symbols and probably be fine for most things.

Reply Parent Score: 1

Alex Forster Member since:
2005-08-12

It's bad enough having to take into account all the different library versions and combinations we have already... and now we may end up having to add the C library--the most basic and what should most definitely be a relative constant--into that mix.


Compile statically, for one. A multi-megabyte binary isn't a big deal when the average consumer has a half a terabyte at their disposal. Choosing what to link with will make up about 1/1,000,000,000th of your total development time. This really won't cause Adobe to abandon their Photoshop port.

Reply Parent Score: 3

wanderingk88 Member since:
2008-06-26

Many (most?) commercial apps usually are compiled statically anyways, so...

Reply Parent Score: 1

bnolsen Member since:
2006-01-06

If you're using lgpl libraries compiling totally static can be a PITA. Also compiling opengl statically isn't possible because of the different backend blobs provided by nvidia & ati.

That's why I believe some baseline glibc symbol compatibility to be the most effective way to handle basic compatibility. "apbuild" allows you to do this.

Reply Parent Score: 2

cycoj Member since:
2007-11-04

I can't help but be a bit concerned about this. On one hand, yes it's good to get away from projects if their maintainers are unreasonable and/or are being assholes.
But on the other hand... This whole thing smacks of re-inventing the wheel yet again. I guess they've done it with every other component... why not the C library now. What, messing up the audio stack getting boring? They claim eglibc is binary compatible with glibc--personally, I'll believe that when I see it. How long until we encounter some function that behaves ever so slightly differently under an obscure condition that made it past the compatibility and regression tests--assuming they did any, of course? It's bad enough having to take into account all the different library versions and combinations we have already... and now we may end up having to add the C library--the most basic and what should most definitely be a relative constant--into that mix.
I know I'm going to get flamed by the Linux croud, but this is bloody ridiculous. This is why, from a commercial developer's point of view, Linux is often a laughing stock. They're replacing this, upgrading that, and forking the other on a near-constant basis... how the hell is anyone supposed to keep track and account for all these various combinations? Unbelievable, and rather pathetic when you come right down to it.


Well first of all eglibc was not created recently, it's been around for several years. It's also not a classical fork, more of a patchset to glibc to achieve what they want. So they are often syncing to glibc. Also to all those people worrying about competability, most distros already heavily patch glibc, so this is more of an effort from debian to unify these efforts. Think about it more as a buffer between Drepper and the "mortals".

J

Reply Parent Score: 3