Slashdot Mirror
Debian Switching From Glibc To Eglibc
ceswiedler writes "Aurelien Jarno has just uploaded a fork of glibc called eglibc, which is targeted at embedded systems and is source- and binary-compatible with glibc. It has a few nice improvements over glibc, but the primary motivation seems to be that it's a 'more friendly upstream project' than glibc. Glibc's maintainer, Ulrich Drepper, has had a contentious relationship with Debian's project leadership; in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'"
Mod me down, boys.
My work here is dung.
This wouldn't happen to be THE Ulrich DrPepper of the legendary DrPepper clan, would it?
Mod me down, my New Earth Global Warmingist friends!
Why this and not uClibc?
http://www.uclibc.org/
I would hate the embedded version's maintainer to not want to fix a bug that was simply for 'for the sole benefit of this desktop crap.'
Wow, sent an e-mail as suggested when clicking on "use classic" banner, and got a fast response that addressed my msg
It might be "Egier" to use, but how far will it stray from the original project (that everyone else is currently using), or is it the first leak in the Dam before everyone jumps ship.
Its especially ironic given the push that netbooks have had over the past year, and the emphasis on Power savings that is pushing developers to consider using ARM chips, and by extension Linux (since Windows just plain won't run on them :) ).
If the OSS community doesn't support an opportunity to get our foot in the door (in a BIG way), by putting "our" OS on the "longest running and lightest" Netbooks/Notebooks that come out (or put our software out with known bugs), then we deserve to reap what we sow.
This space for rent. All reasonable inquiries will be entertained at proprietors discretion.
Speaking as a Debian user who has had some major upgrade problems directly caused by glibc, anything that's "more upstream friendly" is okay by me. I've had my system totally screwed by glibc problems before, so badly that the only thing I could think of to do was to reinstall (it was while installing on a new machine, so it was okay). Whenever I see that glibc in the upgrade list for apt-get upgrade, I get a little queasy to this day though, along with upgrading the locales package.
Gentlemen! You can't fight in here, this is the war room!
Drepper has had this coming for many, MANY years.
He has pissed off practically everybody in the FOSS world at least once.
Good riddance.
I hope this ends up like the gcc/egcs thing a while back. In the end the old gcc was shut down and egcs was renamed back to gcc.
It would be for the best of glibc if this Drepper dude got removed from the project.
I still think we should organize a mud wrestling match between Ulrich and Theo.
Since this is primarily over embedded systems, I assume it will also be more efficient?
What does this have to do with the Singularity?
He wasn't saying that embedded systems were inherently crap. It sounds to me like he has a disagreement with some specific set of design choices.
Not even an old program written from Loki Software Entertainment would run on a modern Linux Mint (2.6 kernel) for example unless in a chroot'd sandbox. Truly sadistic, that I even remember this happening even on the same kernel branch. Bruce Perens would address this better than I, but my time is worth more elseware.
There should be hybridized Elf Static binary that can address this issue. Link layer is realy sucking a nut when it comes with programming, and GNU would make quite an imrpovement to have an application base that allows you to have multiple compilations in the same binary with a link-layer "tree" to how it would execute and with whether internal libraries (static) or even multiple different sets of internal libraries that are even addressable from an advanced prorgaming implementation of sentience as would a rolling book shelf archival track.
Also should be able to run a program even if a certain library is not available and not immediatly used in what function the program is performing immediaty; control the execution branch to libraries that aren't used but in certain situations, even so far is creating that library interface to return a default value so as to "satisfy" that depencancy such as a routine IsItHotOutside() to return a value int 0 without even processing anything, or able to re-direct that to another routine or function in a competing library without having it conflict with the library already used (it might be the same library but different version).
Anyhow, thanks a lot toolchains, bintools, glibc and whomever gobblers can't implement a standard without ruining the binary compatibility image that should let everthing play together.
A bug is a bug, jackass. Just fix the damn thing.
downstream we have many, many distros now adays.
so, if this eglibc becomes the default, it'll end up being the default in pretty much all debian based distros like ubuntu, mepis, xandros, etc.
a repeat of the whole xfree86/x.org thing ?
What ? Me, worry ?
As the maintainer of GLIBC, he has to be the steward for the greater good of all users. And sometimes that means pissing off a vocal constituency.
the growth in cynicism and rebellion has not been without cause
Haha, these days I don't even bother trying to run old Loki games, I have much better luck getting the Windows versions running under Wine :P
I've been wishing for ages for maintainership to be taken away from Ulrich Drepper. Every single bug report I've seen submitted to him has been shot down for some stupid, insane reason, even when it's been accompanied by a patch. He's a bad maintainer.
One example, I submitted and update to an EBCDIC encoding used on IBM mainframes. The encoding had several choices for what should be encoded as the newline character. It wasn't clear which one should be used, but the z/OS system I was using had definitely chosen a particular one. Glibc had chosen a different one. I submitted a patch that changed it and Ulrich rejected it saying that there wasn't a standard and so my version was no more valid than the version that was in the library.
And, on another case, it was clear that the /etc/localtime was being read for each and every field that was being printed in strftime. This both caused things to be slow, and it also created a race condition if that file was changed. I recommended to the person who found the bug that he submit it. He did, and Ulrich rejected it for some bizarre reason I can't recall.
He is an awful maintainer, and I really hope the project is taken away from him by this fork.
Need a Python, C++, Unix, Linux develop
Devices like MP3 players, set top boxes, and mobile phones account for far more GLIBC deployments than desktops and servers.
Apparently to this date its system() call still freaks out when interrupted by signal, returning failure condition when the spawn in fact succeeded.
Both.
in 2007 the Debian Project Leader sent an email criticizing Drepper for refusing to fix a bug on glibc on the ARM architecture because in Drepper's words it was 'for the sole benefit of this embedded crap.'
And the developer has every right to make that call, just as eglibc has every right to make a fork that cares more about the embedded world, and Debian's maintainers have a right to switch.
That said, I have two main thoughts on this issue.
First, only a complete idiot would ignore the fact that one of Linux's primary strengths lies in the embedded market. Refusing to fix a relatively easy bug because it "only" affects that market sounds like something Microsoft would force on us "for your own good", such as DRM or the UAC.
Second, Debian (as a stock install, I don't include remastered lightweight Knoppix variants in that category) does not have a significant presence in the embedded device market. Such uses either involve a platform-specific lightweight distro where available, or the devs take a roll-your-own approach. Getting in a pissing match over support for an irrelevant feature doesn't inspire me with confidence in Debian's leaders.
Not too smart of a thing to do.
This will end up a mess. Just like everything else Debian attempts to fork because they _think_ they know better than upstream.
History is repeating itself once again here.
It seems to be a dick size war between him and Drepper. Not saying he's wrong to be pissed, but yanking your libc seems a bit much for a pissing match.
I think there is some shallow reading going on here.
eglibc has a number of features that are useful in general. It happens that embedded systems have a strong need for these features, but they are generally useful as well. I've discussed it with one of the Debian glibc maintainers, and he said that eglibc is basically a patchset atop glibc implementing new features and fixing bugs. I think of it similar to the relationship between go-oo.org and OpenOffice. Distributions have to fix these bugs anyway, because upstream won't. So why not adopt a standard patchset to do so collectively?
This has no implications for a change of focus away from the desktop or anything like that.
From eglibc's mission statement:
"Retain API and ABI compatability with GLIBC wherever feasible."
Yeah, that's going to end well...
I recall the brief and mild concern over the push to change from XFree86 to X.org. The reasons for doing so were pretty clear and obvious and most people (except for the XFree86 people themselves) that it was simply necessary as the needs of the community outgrew XFree86's visual range. In short, the people wanted more than XFree86 could collectively deliver. (XFree86 people? You were such dumbasses... what better way to show how useless you could be?)
But this story is different. Now we have a maintainer who doesn't believe in what the people and the market are interested in doing -- moving Linux into smaller and smaller devices. "Embedded crap?" Indeed! The future of computing is not more powerful single boxes, but smaller networked devices that work together and the operating system will eventually become less relevant if not entirely irrelevant. This "embedded crap" is where all devices are headed. Many popular consumer gadgets and some really high-end consumer gadgets are already utilizing embedded Linux as the means of making some really cool things happen. The community will not stand for one or a few pig-headed people to impede that.
Either GLibc needs to pull his head out of his ass or he will make himself and his project irrelevant. Worse, if your name and reputation were to be muddied because your project was killed off by the community because "you don't want to work and play well with others" then the odds of people wanting to work with you socially or professionally in the future are greatly reduced and your technical skills, wisdom and experience will have been wasted.
Would it surprise anyone to know that many ice cream sellers only like one or two flavors? Why, then, do they sell so many other kinds?! The reason is obvious.
> As the maintainer of GLIBC, he has to be the steward for the greater good of all users.
No, it needs to be correct code. If ARM happens to be the only platform that currenty exercises the bug it is still a bug. Goddamn people, I swear we are getting as blase about fixing bugs as a Microsoft shop. There is no such thing as a good bug, a less important bug, etc. If it is a bug and someone has a patch for it you APPLY THE DAMNED PATCH. If you have a problem with the patch you write a better patch. Not patching at all is never be the answer.
I really hate updating my systems these days, because for every bug fixed it seems you get a fresh new one. Make it shiny, we will fix the bugs later! Of course later never comes, eventually the crap piles up too high and somebody decides to just start over. Which explains the piles of discarded stuff and the new one that also doesn't quite work in most areas, especially in system administration.
Seriously, the Free Software world needs to call a timeout. Establish a core and devote every available resource into making that core bug free and secure. Then allow no change to be committed to that core without extensive peer review to prevent new bugs from getting in. The Linux kernel is hopeless, no chance of getting it to stop and clean up and x.org is currently in a period of upheaval, but the layer above each could be stabilized. Not just coreutils, but everything including the core widget sets, admin tools. Get things to a point where an ordinary userland package will (not might) work even it it wasn't built against the exact same release.
And finish hashing out the whole new /dev/, dbus, etc. and settle the API down enough to document the damned thing. I know UNIX, but this new stuff totally confuses me. WHere does one go to even find out how it is supposed to work? Which of course isn't how it currently DOES sorta work. How does one even know if a particular piece of documentation, sketchy and incomplete as it will certainly be, documents what was, what currently is or what is intended to be?
Democrat delenda est
The problem isn't GLIBC. The only problem is this idiot Ulrich Drepper. He demonstrates time and again that he is incompetent and has no business being in a position that is forced to interact with other people. This Ulrich Drepper character has the nerve to say stuff in bug report discussions like this such as:
anything handy and certainly have no interest in writing it up.
cannot order me around.
issue at hand. Otherwise you would have noticed that this code has been
entirely rewritten in the current code. It uses a very different implementation
which allows to handle this situation differently.
And this is from a single bug report alone. Why exactly does GNU tolerate such a thoughtless idiot in such a fundamental position in such an important project? Moreover, this idiot Ulrich Drepper even shuns support important architectures such as ARM apparently due to nothing more than whims. How can this be?
GNU is supposed to be a project for it's users by it's users. You don't go far if you rely on antisocial morons to handle PR stuff.
Slashdot, fix your code or at least hire someone who is competent at it to do it for you.
Won't someone explain this in terms of a car analogy!?
Car analogy ho!
"Toyota recently announced that it will be switching manufacturers of its most commonly used drive trains because the original manufacturer said that the changes Toyota requested were 'for the sole benefit of this hybrid/electric crap.'"
In other words, in three years time, glibc might be used only by RHEL6, and Ulrich Drepper will just be forking eglibc and calling it glibc.
The problem is that programming a libc is the worst kind of programming... you have to be compatible with N different standards that are incompatible with each other. A lot of the functions you have to implement are impossible to simultaneously be correct and not make you puke (see printf). And on top of that, nobody even cares since they're all using some high-level library to call your libc functions anyway.
I really wish somebody would come out with a decent libc for linux though. With glibc, you either compile statically and have a 1+mb binary that's still dynamically linked anyway because you used a socket or your program just doesn't run on some systems and you have dll hell far worse than on any Windows. If you've ever had to deliver a non-OSS binary for linux you know what I'm talking about.
Dietlibc is the most convenient alternative by far, but it has several bugs, is slow, and errno is not threadsafe. For instance printf("%2d\n", 222) prints nothing. But if you test your software you can use it really easily, just CC="diet gcc". The uClibc is better, but it's a pita to use, requiring its own entire toolchain.
Since nobody actually pays for developers to work on libc, you end you with whoever crazy people will actually work on it. So while the fork is a good thing, it's probably just going to be more of the same.
.. are very typical of opensource developpers. Try asking Wietse Venema (Postfix developper) for a special feature... That being said, this isn't a feature request, rather a bug (from the embedded perspective). A special module could be written for embedded devices, that way, the module can be enhanced, bug-fixed or whatever, without negatively affecting the main program. But wait! What if the module has a nifty feature eh????
TOP DSLR Cameras Reviews of the top DSLRs
Not even an old program written from Loki Software Entertainment would run on a modern Linux Mint (2.6 kernel) for example unless in a chroot'd sandbox. Truly sadistic, that I even remember this happening even on the same kernel branch. Bruce Perens would address this better than I, but my time is worth more elseware.
You can do it by installing the old libraries and using LD_LIBRARY_PATH and LD_PRELOAD. See the Gentoo Wiki archives for information and a tarball of the necessary libraries.
Not the most elegant solution, but it's easier than dealing with a chroot.
Don't leave your mind so open that your brain falls out. Don't close it so much that you cut off the blood.
as you wish...
it'd be like a car maker changing the tires supplier from firestone to goodyear because firestone refused to change the thread pattern.
What ? Me, worry ?
Actually you're wrong: The biggest cause of failure for linux games wasn't actually glibc, it was stdc++, followed by smpeg, followed by other C++ libraries.
I speak this as someone who during the gcc 2.96/3.x fiasco had multiple library toolchains installed in an attempt to keep my stack of ~5 linux games functional. The only one out of any of those that is still easily run is Quake3 (the rest having broken thanks to the coreutils retards deciding to get rid of 'cruft' like tail -xxx formatting, which all the loki install scripts use for extracting the compressed data!)
Honestly when I care about backwards compatibility I have to go create a fake root dir, and jump through all kinds of hoops. Reason I just reverted to a mostly full-time Windows Gaming Box (Usually Win2K, but it's about time I'll have to install WinXP to continue gaming. All this Windows Live crap isn't installable under Win2K, although pretty much everything else is!)
IMHO this is still a massive snafu for linux and is likely never going to see resolution. But hey, everybody needs their source right? :D
flaming aside
as the article says
--------- /* struct rtgenmsg consists of a single byte. This means there
--- check_pf.c.old 2007-04-25 19:05:18.000000000 +0300
+++ check_pf.c 2007-10-06 00:54:45.000000000 +0300
@@ -53,21 +53,18 @@ make_request (int fd, pid_t pid, bool *s
struct rtgenmsg g;
are three bytes of padding included in the REQ definition.
- We make them explicit here. */
- char pad[3];
+ We use pad as a mark for the size of the data we need. */
+ char pad;
} req;
struct sockaddr_nl nladdr;
- req.nlh.nlmsg_len = sizeof (req);
+ req.nlh.nlmsg_len = offsetof (struct req, pad);
usw
open source gets the job done, open source development processes use heated language as a community debates, lots of smoke and lightning, what is really new here
eglibc is I'm sure a fine thing for what it really brings beyond glibc (out of my expertise to be honest)...
Depends what you mean by efficient. UClibc is more efficient in space, but less efficient in size. The most telling indication of this is that uclibc does all 32bit math operations by converting to 64bit, performing the 64-bit maths, and then converting back.
That's never quick.
More efficient in space, but less in size? That makes no sense at all.
What's worse, you have absolutely no idea what you're talking about when it comes to uclibc's math library: first of all, most of the math in uclibc is done in hardware units (whatever the hardware size for float/double and int (16/32-bit)). This is the same for glibc. In many cases, the math has to be emulated, which makes it slower, but glibc isn't going to do a lot better in these corner cases either.
No, uclibc's real drawbacks are that it's not ABI-compatible with glibc, it's nowhere near as portable as glibc, and that it's threading, rpc and networking components are far inferior to the much larger glibc. On the other hand, uclibc can, compiled code-wise, fit entirely in the cache of many ARM microcontrollers, which translates into real speed gains on those machines.
Sadly, nobody really gives a shit about Linux binary compatibility.
BSD does.
(the rest having broken thanks to the coreutils retards deciding to get rid of 'cruft' like tail -xxx formatting, which all the loki install scripts use for extracting the compressed data!)
export _POSIX2_VERSION=199209
It seems that he was completely correct in this case, if you read what he says. Oh, but you didn't . . .
This is all just my personal opinion.
Hordes of basement-dwelllers have nothing better to do but to recompile the same software over and over again.
I can't remember the last time I had to compile from source. It was a long, LONG time ago.
"I don't know, therefore Aliens" Wafflebox1
From TFA: 1 2 3 4
Interested in open source engine management for your Subaru?
My copy of Railroad Tycoon II for Linux wasn't working at all, on Ubuntu 8.04, obviously 2.6.something [I did try Ubuntu forums, they didn't have a working answer either]. Well, at least I won't bother on 9.04 either...
Since that didn't work, I visited a certain Swedish website for the Windows version, and that worked just fine on my XP box.
I listen to both RIAA and non-RIAA stuff if I like the music, tangential business/politics nonwithstanding.
" Any change will negatively impact well designed architectures for the sole benefit of this embedded crap. "
[To be posted tomorrow, probably]
The Debian project has dropped the use of the GNU project's glibc C library, substituting the eglibc fork, as glibc maintainer Ulrich Drepper refused patches or bug reports for several architectures Debian relied on.
"Any change will negatively impact well designed architectures for the sole benefit of this embedded crap," said Drepper. "Famously good architectures like x86. Can you believe, these people wanted their C library to work in systems with shells other than bash! These people must think they're signing my pay check."
Drepper has, in retaliation, announced his own fork of Debian. It will be created in cooperation with Joerg Schilling and Tuomo Valkonen and be based on OpenSolaris with Ion running on XFree86 as the standard window manager. "Keith Packard ruined X," said Valkonen. The standard file system will be ext4, given its proven ability to cause data loss in user software the maintainers consider ill-written.
The project will be licensed under both the intersection and union of the GPL, LGPL, CDDL, MIT and the thing TuomoV wrote for Ion. This is not anticipated to be a problem in practice with real-life users, at least not until one exists.
"YOU!" said David Dawes of XFree86. "YOU'VE BEEN TALKING TO THEM, HAVEN'T YOU! YOU'RE CONSPIRING WITH THEM! THOSE GUYS! THEY STOLE IT ALL! THEY PUT A RADIO IN MY HEAD! LINUX/BSD WEENIES! I'LL SHOW 'EM! HELL YES!" "That means he's onside with us," said Valkonen. "Dave's been a bit terse since he finally lost it trying to fix his own broken modeline."
http://rocknerd.co.uk
[ ] You know that a lot of that answers were posted by Trolls that somehow smelled the fish.
(Tip: Move mouse over link after "From", look at href, know "mailinator.com", understand.)
Hopefully it'll stray as far as possible, given that the original project seems to have serious attitude issues with accepting their bugs and simply applying supplied patches! I know little about GLIBC internals, but even I can see how crack-happy the maintainers seem to be, and could probably do a better job myself. All I can say is thank god this is being forked away from those nut-jobs, and hopefully everyone else WILL jump ship too.
export _POSIX2_VERSION=199209
Doesn't work anymore with the latest coreutils. The required functionality appears to be gone for good...
He friends with Theo perhaps?
( its a joke, laugh )
---- Booth was a patriot ----
Did you actually read #3? strfry() is a joke function, an silly Easter egg that had been included in Glibc since time immemorial and unfortunately cannot be removed for fear of breaking compatibility.
Anyone with half a brain can see that fixing "bugs" in ancient Easter eggs is a waste of developers' time. If I were in Ulrich Drepper's position, my response would be similar to his, but with more insults.
Frankly none of that surprises me. RedHat devs have been acting this way for nearly a decade. They are on a mission to control and fork every major OSS project for the benefit of their most profitable customer base: large database servers.
It's funny though, because Oracle is set to ream them in the ass on that front. And the damage they have done by ignoring the rest of their potential Linux market (embedded, desktop, web and small file servers) will come back to haunt them.
I'd assert that the business model RedHat is following is the exact wrong way to support OSS. RedHat has clearly instructed their devs only to support the most profitable end-users, and to actively ignore everyone else, especially competitors. Notice that one of the bug submitters was from SUSE. From their perspective, every line of code costs money to maintain, and if a line of code isn't necessary for making RedHat money, it's worthless and should be removed.
This is all extremely stupid and short-sighted, especially for the market leader.
And it's the reason I switched to Debian several years ago. Debian mostly accommodates edge cases, doesn't try to actively thwart forks and competitors, and I feel is therefore generally the Linux distro that is most responsive to end-users.
Wow this should have not been modded as flamebait. We should have simply addressed the better ways to do what the AC suggested. Honestly Linux is pretty decent about being backwards compatible at the syscall level. What is a real PITA is how glibc and libstdc++ do not remain backwards compatible. The BSDs do a much better job of backwards compatibility, and Solaris does an exceptional job. I just simply think that the Linux people do not care so much about that sadly. There were some backwards compat issues that made sense (like teh move from COFF to ELF and the broken relocation types originally used in ELF) but others have not made sense:
Yet again changing the relocation types.
Various times the C++ library broke backwards compatibility.
Various times that glibc broke backwards compatibility.
Also what is up with changing the options to programs in /usr/bin willy nilly?!
Can we PLEASE get the moderation confirm button back!?!?!?!
In a galaxy far, FAR away?
GLaDOS for President 2016! "Well here we are again. It's always such a pleasure." -- GLaDOS, 2011
The LD_PRELOAD doesn't work on ol' bitch-ass libraries that are too skunk.
In a galaxy far, FAR away?
Vainly humorous as your comment is, the answer is "no". Been living in the same house since I started using Linux.
"I don't know, therefore Aliens" Wafflebox1
Somthing that would LD_PRELOAD by determining the heuristics of a binary is crap. What would be better is if each binary was treated like it's own chroot and just have internally the libraries it was compiled upon and then with flags the system would determine (on execution) if it would use anything outside of that. I remember when Sam Cuntinga was having his bitchboy or such Ryan "Cuntback" Gordon (http://icculus.org horseshit) jump between static and dynamic binaries. oh fuck their NNTP server with a hockeystick if you needed any help.
oh, and fuck you too.
and Solaris does an exceptional job.
Indeed. I have a client that is running an application on SunOS 5.10 that it wrote in 1994 for 5.3. That is one of the major selling points of Solaris. I am simply amazed that it is readily dismissed by the Linux camp.
Slashdot - The great and glorious cluster fuck of Internet wisdom.
I use eglibc, and I like it better. For instance, when I was a bit distressed to discover that glibc shipped with scripts which require bash or ksh (not a good fit for a TINY embedded system), I went and looked. The dependencies there could be EASILY removed with no significant harm done -- and the scripts would work. One of them took me all of twenty minutes to clean up to make it functional with any POSIX shell.
This isn't rocket science. It also isn't software engineering. I was first disappointed with glibc's performance somewhere around 1996, and it's never really won me over since. eglibc seems to me to be a much nicer approach.
(Full disclosure: I think $dayjob funds some eglibc development, and we certainly use it.)
My blog: http://www.seebs.net/log/ --- My iPhone/iPad app: http://www.seebs.net/seebsfrac/
He probably just said "Scheißminikistenprozessorendreck", which is really much friendlier.
I have an old Spreadsheet program from back in DOS 3 that I still use, and it still runs today in a DOS shell all through 3.1/9x/ME, NT 3.5/4/2k/XP/2k3 and now Vista!.
This is quality programming man!
Ever hear about Spectra GUI for DOS? Yea it works well to this day. FreeDOS and Spectra ontop is a beautiful scarlet bitch!
In a 2001 rant against RMS (on which I take no stand here) he wrote this:
Despite what Stallman believes, maintaining a GNU project is NOT a privilege. It's a burden, and the bigger the project the bigger the burden. I have no interest to allow somebody else to tell me what to do and not to do if this is part of my free time. There are plenty of others interesting things to do and I'll immediately walk away from glibc if I see a situation like this coming up again. I will always be able to fix my own system (and if the company I work for wants it, their systems).
I,m surprised that this isn't quoted by Microsoft as a "typical" example of cooperative open-source development.
Over the years I had many unfriendly answers from just being rude up to ignoring valid responses or even new bug reports. I still write bug reports but at a far less frequency and I avoid certain maintainers' packages.
Debian should start educating their maintainers in at least formal politeness and basic social correctness.
cb
The great thing about "embedded crap" is that working on it leads to a greater understanding of how to program for desktops.
In Soviet Russia, car analogy explains YOU.
Maybe not, maybe someone used that strfry function for some statistics demonstration code, and found out that it had statistical anomalies.
Instead of being glad that someone finds bugs in his code (apparently that person was using strfry) and even proposes the fix for him, he gets all snotty and offensive.
I think mr. Drepper should not be in a position as public leader of a project like this. Maybe they can put him in a cage with a high end computer or something, but the job of package maintainer also requires people skills, and an overall understanding of what the package is actually used for (including embedded and strfry apparently).
I mean seriously. The nastiest microprocessor architecture that anyone has ever come up with is x86. It's an Intel cultural thing, all their processors (afaik) suffer from this.
RHEL doesn't use vanilla glibc either.
http://rocknerd.co.uk
No, eGPL is not the license you're looking for... move along soldier... eGlibc is not related to ethical licensing scheme that will ruin the empire.
The BSDs generally have good backwards compatibility too. The FreeBSD kernel, for example, only changes interfaces with a new major version number, and in this case provides a compatibility module that exposes the old interfaces and provides a mechanism for using old versions of libc and so on. It uses the same set of techniques used to run Linux binaries on FreeBSD (somewhat ironically, it's often easier to run old Linux binaries on Solaris or FreeBSD than it is on Linux).
I am TheRaven on Soylent News
"(2) a different version of the fix that would actually speed things up on all architectures."
So submit that one.
Or is that too much work?
TdR was an arse about that. Dual licensed code, had GPL addition added under the GPL grant. TdR goes APESHIT.
Why?
Because GPL'd versions would be improved over the plain BSD one and the BSD version couldn't take the code.
WELL THAT'S WHAT HAPPENS WHEN SOMEONE CLOSES THE BSD CODE.
Oddly he doesn't have a problem with that.
Is an arsehoe is right. Is right when he's being an arsehole is wrong.
In my experience Glibc is a bloated, flakey, temperamental mess, at least as far as trying to compile it from source is concerned. Admittedly, the recent version used in Linux From Scratch gave me probably the single smoothest compile of it I've ever had.
There were times in the past, however, that were nowhere near as trouble-free; especially when the LFS people made the horrible mistake of using Glibc builds from Red Hat's CVS. It would need patch after patch, and 3-4 times stopped dead partway through the compile for reasons that hadn't been documented (or apparently foreseen) by the LFS people, meaning I'd have to Google the errors and pray to God that someone had uploaded diffs somewhere.
Debian isn't exactly my favourite distribution, to be totally honest; but although they seem to be even more offensive than I myself manage to be most of the time, (which is no mean feat, I might add ;)) this may perhaps be their first internal fork which is actually based on logical sense.
A new libc is something which Linux has needed for quite some time now, and getting one is only going to be a blessing for all concerned. It would be nice if said new libc were also BSD licensed; but one can't have everything, I suppose. ;)
All the world's got 32-bit twos-complement integers aligned on a 4-byte boundary, right?
That's exactly the kind of person I want supporting a portable runtime library. Not.
Ah. You write scripts, then?
[ ] You know that a lot of that answers were posted by Trolls that somehow smelled the fish.
(Tip: Move mouse over link after "From", look at href, know "mailinator.com", understand.)
Wow, Ulrich. I would have thought it almost certain that you'd have a Slashdot account.
Hi, by the way. ;)
I'm seeing lots of comments about how horrible a maintainer he is...but somehow he's still the maintainer. I have to assume that he's actually good at something or else he would have already been replaced.
Can anyone give some insight on what qualities he has that explain how he has managed to keep the position as glibc maintainer?
I'm just trying to see the other side of the picture here.
*sigh* back to work...
Speaking of switching, why haven't you switched to OS X yet?
Are you stupid or just slow?
For some of us, it's because we're cheap bastards who can't afford a Mac.
For me, it's because while I'd be a lot happier simply using FreeBSD, (it has a license I like a lot more, and it's better technically in just about every respect other than hardware support) that would be boring. I'm addicted to pain and suffering, so I need to single handedly try and write solutions for what I perceive to be Linux's problems, which probably nobody will ever use, rather than simply using a system where all of said problems are already solved instead.
For the rest, however, it's because they're card carrying members of the cult of the GNU. In some ways, Linux has less in common with an operating system, and more with the Church of Scientology.
New lines of netbooks or very cheap/low power desktops that some manufacturers are interested in making, which would be based on ARM and probably run Linux (or maybe *BSD). Support for ARM looks like it is very important for that market. Those are, arguably, mass market 'desktop' systems, which just don't happen to be based on x86 or PPC.
Then there's things like mobile phones and others.
I can't see for the life of me why a developer would dismiss the embedded market as not needing glibc to work correctly on it?
I know Red Hat employs Drepper (or something like that), but a move by Debian has little meaning without support from other sources. It's been shown that even Ubuntu doesn't always follow suit with its upstream Debian Sid (e.g. they ship Firefox, not Iceweasel).
This absolutely MUST gain traction. Somebody must bite. Nokia could put it in Qt Embedded, Fedora could use it by default (and thus pressure Red Hat), Ubuntu could take a real look at it, FreeBSD could make the move, the Free Software Foundation could make a statement, etc.
Otherwise, we risk yet another rift in an already fractured community.
Use my userscript to add story images to Slashdot. There's no going back.
Various people want various things out of him and he arbitrates somehow.
It's impossible for a lot of people not to be disappointed. I have experienced it - people can demand a lot of contradictory things from a maintainer and be cross when they don't get them.
His mistake is not to have trusted lieutenants - a posse to support him and also moderate him.
But I have little respect for the moaners on this thread. Fork and do the work yourself if you're not happy.
This is all just my personal opinion.
Funny that you read "basement-dweller" and automatically assumed the comment referred to yourself.
Business. Numbers. Money. People. Computer World.
Lokks like they did exactly that. Why so little respect?
Rethinking email
"But that doesn't make him an asshole. That makes him a typical geek!"
There is no contradiction between calling someone "asshole" and calling someone "typical geek".
What this says about typical geeks is left as an exercise for the student.
There are lots of comments on this thread from people who didn't take the responsibility of starting a fork.
One can't value their complaints all that highly because they didn't care enough to take up the burden themselves.
As for eglibc, good for them and we'll see how they get along.
This is all just my personal opinion.
Adding functions does not an ABI break.</yoda;>
He's refusing to break other architectures so that a fix for ARM can go in? Umm... okay.. it sounds to me like the fix was probably not up to snuff.
It sounds to me that to fix the problem rather than forking would be much easier. Right now I'm forced to wonder if the fork breaks other things. I'm also now concerned about possible incompatibilities with my project. I suppose since it's ABI compatible there should be no problem, but I've heard promises like that before. Only time will tell.
Why exactly is he being crucified for this and, also... why is he being taken massively out of context on slashdot?
GC
Gregory Casamento
## Chief Maintainer for GNUstep
Actually, for Windows applications that are written by rules, using all the proper types of things, then yes, a Windows C app should recompile for ARM without too much of a problem and actually work.
In fact with the old Embedded Visual C++, you could target multiple CPUs and it would compile them all out. For a dumb checkers game I wrote, I had a release for ARM and a release for some other weird PDA chip, and it all just worked.
The biggest problem that most people would have in Windows apps, me thinks, would be if they were using native SDK code and they had rolled their own stuff for unpacking LPARAM and WPARAM. But, if you used the SDK macros for everything, used the macro types like LPSTR and LPCSTR and WORD and DWORD and the Windows structures for stuff, I would fully expect a recompile would just work out of the gate.
This is my sig.
He's got some good points. He does express them in a way that's unnecessarily offensive and combative. But that doesn't make him an asshole. That makes him a typical geek!
So when do you think he's going to chop his wife up, accidentally lose the passenger seat to the car, and get caught trying to leave the country with $4000 in cash?
This is my sig.
What Ulrich Drepper was saying sounds bad in the quote, but it is pretty much correct, he could have said it nicer but if that is is opinion he has a right to voice it, ... that Politically Correct crap is for the birds. He does the base x86 version, another does the version ported to arm that is in the ports collection, so basically they just reported the problem to the wrong person then got upset when they were told he didn't care. So I do not see a problem with glibc in general, but in politics and/or general care and feeding of the Debian developers.