Basically for many years now glibc has been knowingly doing the wrong thing just to keep malloc_set_state/malloc_get_state working. Which as far as anyone knows, is used only by emacs. Keeping this interface alive for the sole benefit of an emacs optimization when it is blocking the fixes for fairly serious bugs is a pretty big bar to meet for justification.
In the end this is largely a non-issue as an Emacs developer noted that their configure script probes for the special glibc malloc API and if it doesn't exist then emacs will use its own malloc implementation. The conclusion is that once the glibc devs get their changes up, everyone can meet up again to make sure existing emacs binaries still run and that the API detection in the emacs configure script works right.
So props to Paul Eggert for being the only sane man in the room and pointing out that the drama was all for nothing.
Actually, having a generic way of saving the program state into an executable that then runs from that point could be really useful, and some Unix versions had it (and Perl used a Unix utility called undump to implement a "Perl compiler" where it dumped core that could be "undumped" into a running program later; that's the same idea as "unexecing" program state into an executable.)
Approaches similar to unexec() are quite common in lisp-like environments, so emacs doesn't come as a "surprise" here.
There's no reason emacs needs to use the glibc's malloc implementation though, especially given emacs has it's own built-in (and probably neglected) malloc for other platforms.
Yep. Emacs builds and runs (and presumably unexecs) on many non-glibc platforms. This is more likely an optimization for it on glibc.
"According to Paul Eggert, making unexec more portable has been on the to-do list for a while, "and this will light more of a fire under it". Concerns that Emacs might not build using a new Glibc API (which has not even been written yet) that came up earlier in the thread are not a problem, he said. "Emacs should still build and run even if the glibc API is changed, as Emacs ./configure probes for the glibc malloc-related API and falls back on its own malloc implementation otherwise.""
I think it's wrong for any application to be this intimate with its host platform. In my opinion, Emacs should treat libc as a black box on GNU/Linux, just as it presumably does on Windows, OS X, and other proprietary platforms. But I admit that my opinion is shaped by being a user and developer of proprietary software, where binary compatibility is important. So I'm not surprised that RMS apparently disagrees.
The host platform has no reason to exist except to run programs. And then functionality that turns out to be widely useful goes into the standards.
So, it turns out that unexec has not made it into the standards, and now is causing more problems than it’s solving, and the glibc maintainers are going to remove it.
This would not be an interesting story, except that it involves Emacs, Stallman, and the appropriate use of mailing lists. Still, the conclusion of the article is that the process works and everything’s just going fine.
Binary compatibility is also important to glibc, which is why they go to the trouble of carrying stubs that implement the older ABI for any functions that change ABI. Binaries linked against older library versions will continue to work with newer versions, through the magic of symbol versioning.
This method will presumably be used to carry the old malloc implementation around for older emacs binaries that rely on it (whereas newly linked binaries will see the new API and ABI).
You aren't wrong given the current development landscape but Emacs is a very old piece of software and this sort of thing wasn't unheard of when it first was given life. (I wasn't really around but anecdotal stories from the time period seem to support this.)
This is just an example of technical debt handled well actually. The loan came due and now the emacs devs are doing the right thing and paying it off.
console video games are very intimate with their host platform, to the point where 6 years old GPU/CPU combo produces better results than lots of newer PC's.
I'm not advocating that this should be the norm, simply noting that there are cases where you need to be.
Otherwise you can't achieve smooth 60 or 30fps, without tearing, popping (audio, streaming, models), etc.
IMHO, the XEmacs approach of using a portable dumper is the better option. I prefer that one not only because it frees us from having to worry about the details of executable formats, but because the same machinery that lets us find and relocate all the intra-lisp-heap pointers would also let us write a compacting GC, which is important for long-running programs like Emacs.
From what I remember TeX dumps the processed macros into a binary file. Later, TeX loads those preprocessed formats quickly, without the need to parse again something as big as LaTeX.
I wonder if there is any project starting to re-write Emacs according to modern practices like we now have NeoVIM for VIM.
I really like editing in VIM but I moved to Emacs using Spacemacs to try and get the best of both worlds (org mode for scientific research seems a really cool approach).
Still I see Emacs as being quite more bug prone than VIM and VIM than NeoVIm.
Perhaps this is what's needed for someone to start a complete refactor of Emacs and bring it (I mean the code not the editor) to the modern age.
I don't really see that as being the case. Emacs development is very active, even at the low levels. The Guile scheme implementation now has an elisp implementation and there's a good chance that emacs will be moved to it eventually.
If you encounter bugs you should submit bug reports.
If you try scrolling down, you'll note you can actually read the article. LWN lets subscribers share (temporary) paywalled articles with anyone they like, even on public forums like HN. They are nice like that.
The following subscription-only content has been made available to you by an LWN subscriber. Thousands of subscribers depend on LWN for the best news from the Linux and free software communities. If you enjoy this article, please consider accepting the trial offer on the right. Thank you for visiting LWN.net!
So much for rms standing up to principle. When the chips are down, he resorts to a private mailing list to discuss and influence matters that impact multiple users. I though he was into transparency?
I found it interesting that RMS wanted to discuss the issue in private given his position as a almost religious defender of free software. Isn't a part of free software that it is developed in the open?
rms doesn't think "free software" has anything to do with a responsibility for collaboration or openness. Those are slogans of the open source movement. He sees software as an ethical exchange between two parties. rms doesn't have a problem with privacy, secrecy, or refusal to collaborate. As long as Bob has the freedom to do whatever he wants with the software the Alice gave him (except, perhaps, restrict the freedom of others), rms doesn't think that Alice has any further moral obligations.
Not necessarily. Read Eric Raymond's description of cathedral-style development in "The Cathedral and the Bazaar" and keep in mind that he had Emacs in mind. It wasn't until Linux that an open, public development process became closely associated with free software.
[+] [-] nuxi7|10 years ago|reply
https://sourceware.org/bugzilla/show_bug.cgi?id=6527
Basically for many years now glibc has been knowingly doing the wrong thing just to keep malloc_set_state/malloc_get_state working. Which as far as anyone knows, is used only by emacs. Keeping this interface alive for the sole benefit of an emacs optimization when it is blocking the fixes for fairly serious bugs is a pretty big bar to meet for justification.
In the end this is largely a non-issue as an Emacs developer noted that their configure script probes for the special glibc malloc API and if it doesn't exist then emacs will use its own malloc implementation. The conclusion is that once the glibc devs get their changes up, everyone can meet up again to make sure existing emacs binaries still run and that the API detection in the emacs configure script works right.
So props to Paul Eggert for being the only sane man in the room and pointing out that the drama was all for nothing.
[+] [-] _yosefk|10 years ago|reply
[+] [-] Freaky|10 years ago|reply
1: http://git.savannah.gnu.org/cgit/emacs.git/tree/src/unexsol....
2: https://docs.oracle.com/cd/E19455-01/806-0627/6j9vhfmop/inde...
[+] [-] johntb86|10 years ago|reply
[+] [-] protopete|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] tenfingers|10 years ago|reply
There's no reason emacs needs to use the glibc's malloc implementation though, especially given emacs has it's own built-in (and probably neglected) malloc for other platforms.
[+] [-] mcguire|10 years ago|reply
"According to Paul Eggert, making unexec more portable has been on the to-do list for a while, "and this will light more of a fire under it". Concerns that Emacs might not build using a new Glibc API (which has not even been written yet) that came up earlier in the thread are not a problem, he said. "Emacs should still build and run even if the glibc API is changed, as Emacs ./configure probes for the glibc malloc-related API and falls back on its own malloc implementation otherwise.""
And there's the dreaded autoconf doing it's job.
[+] [-] mwcampbell|10 years ago|reply
[+] [-] Decade|10 years ago|reply
So, it turns out that unexec has not made it into the standards, and now is causing more problems than it’s solving, and the glibc maintainers are going to remove it.
This would not be an interesting story, except that it involves Emacs, Stallman, and the appropriate use of mailing lists. Still, the conclusion of the article is that the process works and everything’s just going fine.
[+] [-] caf|10 years ago|reply
This method will presumably be used to carry the old malloc implementation around for older emacs binaries that rely on it (whereas newly linked binaries will see the new API and ABI).
[+] [-] zaphar|10 years ago|reply
This is just an example of technical debt handled well actually. The loan came due and now the emacs devs are doing the right thing and paying it off.
[+] [-] malkia|10 years ago|reply
I'm not advocating that this should be the norm, simply noting that there are cases where you need to be.
Otherwise you can't achieve smooth 60 or 30fps, without tearing, popping (audio, streaming, models), etc.
[+] [-] ma2rten|10 years ago|reply
[+] [-] quotemstr|10 years ago|reply
[+] [-] weinzierl|10 years ago|reply
If I remember correctly TeX uses the same trick. I don't know if it depends on unexec() though.
[+] [-] coliveira|10 years ago|reply
[+] [-] jbssm|10 years ago|reply
I really like editing in VIM but I moved to Emacs using Spacemacs to try and get the best of both worlds (org mode for scientific research seems a really cool approach).
Still I see Emacs as being quite more bug prone than VIM and VIM than NeoVIm.
Perhaps this is what's needed for someone to start a complete refactor of Emacs and bring it (I mean the code not the editor) to the modern age.
[+] [-] dmm|10 years ago|reply
If you encounter bugs you should submit bug reports.
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] fidget|10 years ago|reply
kinda shitty
[+] [-] lultimouomo|10 years ago|reply
[+] [-] tshtf|10 years ago|reply
[+] [-] chris_wot|10 years ago|reply
[+] [-] ma2rten|10 years ago|reply
[+] [-] jordigh|10 years ago|reply
[+] [-] mwcampbell|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]
[+] [-] camgunz|10 years ago|reply
[+] [-] roel_v|10 years ago|reply
[+] [-] mwcampbell|10 years ago|reply
[+] [-] camgunz|10 years ago|reply
[+] [-] unknown|10 years ago|reply
[deleted]