| |||||||||||||
A turning point for GNU libcA turning point for GNU libcPosted Mar 28, 2012 16:38 UTC (Wed) by nix (subscriber, #2304)Parent article: A turning point for GNU libc
In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs.Bwahaha. I suspect more significant here was that Emacs already existed (and was the trigger for the whole thing). Everything else released early on was pretty crucial infrastructural OS-core stuff.
(Log in to post comments)
A turning point for GNU libc Posted Mar 28, 2012 17:50 UTC (Wed) by jzbiciak (✭ supporter ✭, #5246) [Link]
It's classic middle-out design: Start with EMACS. Build an entire OS userland on top of it while building a kernel and runtime libraries under it. ;-)
Now only if that system had a decent editor. ;-) ;-)
A turning point for GNU libc Posted Mar 29, 2012 12:44 UTC (Thu) by nix (subscriber, #2304) [Link]
Hey, it could be worse. At least nobody tried to put unexec() into glibc!
A turning point for GNU libc Posted Mar 30, 2012 22:32 UTC (Fri) by flewellyn (subscriber, #5047) [Link]
Being able to dump and rerun a memory image of a program would be a hugely useful thing for C programs, though. Maybe not something to put in the C standard library, but having it available would be nice.
A turning point for GNU libc Posted Mar 30, 2012 23:48 UTC (Fri) by nix (subscriber, #2304) [Link]
Yes, but... but... do it right (which probably means with kernel as well as deep libc help). Don't do it the way unexec() does it. *shiver*
A turning point for GNU libc Posted Mar 31, 2012 0:20 UTC (Sat) by flewellyn (subscriber, #5047) [Link]
To be fair, I don't know how unexec() does it. What is it that's so ugly?
A turning point for GNU libc Posted Apr 5, 2012 8:26 UTC (Thu) by nix (subscriber, #2304) [Link]
Let me count the ways... (this is unexelf.c: the non-ELF unexecs are rather neater, probably because they don't need to cater for the requirements of more than one platform).
... dependency on section names and ordering. Dependency on symbol names (it knows the name of the sole symbol in a special object file linked in last of all). Inverse runtime linking, with a short, ugly, and inadequate hardwired list of relocations. Massive platform-specific ifdeffery. Special-cases throughout the source code for things that will be dumped into the executable and stay read-only ('pure space') versus those that will not. All the signs of code that was neat when it was written (if you believe the (C), in 1985) but has evolved since then in the ugliest imaginable fashion.
Quite like a lot of the rest of the insides of Emacs, really. (Parts of it are neater. None is uglier.)
Ew, I shouldn't have looked at that so early in the morning. I feel quite queasy now.
A turning point for GNU libc Posted May 16, 2013 15:12 UTC (Thu) by karya (guest, #71446) [Link]
Couldn't you use some checkpoint-restart package like DMTCP (http://dmtcp.sf.net/) to achieve the "unexec" functionality? Simply create a checkpoint image and restart it later.
A turning point for GNU libc Posted May 21, 2013 14:24 UTC (Tue) by nix (subscriber, #2304) [Link]
Well, yeah. That's the 'deep kernel and libc help' I was thinking of. I suspect DMTCP could do it for Emacs now, actually, since a dumped Emacs has almost no dependencies on runtime state (it can't, since unexec can't deal with them).
A turning point for GNU libc Posted Mar 30, 2012 13:04 UTC (Fri) by civodul (subscriber, #58311) [Link]
>> In its early days, the GNU project was forced to focus on a small number of absolutely crucial projects; that is why the first program released under the GNU umbrella was Emacs.
> > Bwahaha. I suspect more significant here was that Emacs already existed (and was the trigger for the whole thing). > > Everything else released early on was pretty crucial infrastructural OS-core stuff.
Indeed.
It should be mentioned that FSF-paid developers, including Roland, were initially developing libc for the GNU operating system, aka. GNU/Hurd. The Linux "port" came later with the work of Ulrich Drepper and others.
A turning point for GNU libc Posted Mar 30, 2012 13:17 UTC (Fri) by nix (subscriber, #2304) [Link]
The biggest 'other' definitely has to be HJ Lu.
|
|||||||||||||