5 ms·

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 i

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.

zaphar 11y ago
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.
ma2rten 11y ago
I think it's common for applications that are developed by same organization as the OS. Windows also has private APIs for some MSFT applications.
- afarrell 11y ago
  > I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it. http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html
- asveikau 11y ago
  Not sure about how it was in the pre-DOJ days, but in recent Microsoft history there is a company policy not to ship non-OS binaries that use private Windows APIs.
Decade 11y ago
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.
- xxpor 11y ago
  It may not be an interesting story from that perspective, but from the perspective of an emacs user, I had no idea that emacs did this. Reading about how it works has been super interesting (with a healthy dose of wat thrown in). I'm glad it was posted.
  - TheCondor 11y ago
    It's worth compiling emacs and understanding it all. It is interesting.
    - semi-extrinsic 11y ago
      So let me see if I get this. The build process runs a huge autoconf etc., then compiles from C code a proto-emacs, which is then executed and loads up a bunch of Lisp code, then a (self-described as) ugly hack is used to dump that running program (including the loaded Lispy-bits) as a new executable, which is your editor? Wow.
malkia 11y ago
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.
- mrob 11y ago
  That level of smoothness absolutely should be the norm. And not just 60fps, but ideally 120fps/144fps/higher (eg. new DisplayPort 1.4 240Hz monitors when they are released). Every dropped frame, every timing inconsistency, is a small attack on your concentration. When a tool acts quickly and predictably you can treat it as a part of your own body (see https://en.wikipedia.org/wiki/Body_schema https://en.wikipedia.org/wiki/Body_schema ). When it responds slowly or inconsistently this requires conscious effort that could be better spent on solving the problem. For example, every libvte based terminal emulator is capped at approximiately 40fps. 40fps isn't even an integer multiple/divisor of any common refresh rate! It annoys me every time I see it, and it's symptomatic of the casual attitude to UI responsiveness that has modern software running worse than some ancient MS-DOS software did on a 386.
caf 11y ago
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).

zaphar 11y ago

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.

ma2rten 11y ago

I think it's common for applications that are developed by same organization as the OS. Windows also has private APIs for some MSFT applications.

afarrell 11y ago
> I first heard about this from one of the developers of the hit game SimCity, who told me that there was a critical bug in his application: it used memory right after freeing it, a major no-no that happened to work OK on DOS but would not work under Windows where memory that is freed is likely to be snatched up by another running application right away. The testers on the Windows team were going through various popular applications, testing them to make sure they worked OK, but SimCity kept crashing. They reported this to the Windows developers, who disassembled SimCity, stepped through it in a debugger, found the bug, and added special code that checked if SimCity was running, and if it did, ran the memory allocator in a special mode in which you could still use memory after freeing it. http://www.joelonsoftware.com/articles/APIWar.html http://www.joelonsoftware.com/articles/APIWar.html
asveikau 11y ago
Not sure about how it was in the pre-DOJ days, but in recent Microsoft history there is a company policy not to ship non-OS binaries that use private Windows APIs.

Decade 11y ago

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.

xxpor 11y ago
It may not be an interesting story from that perspective, but from the perspective of an emacs user, I had no idea that emacs did this. Reading about how it works has been super interesting (with a healthy dose of wat thrown in). I'm glad it was posted.
- TheCondor 11y ago
  It's worth compiling emacs and understanding it all. It is interesting.
  - semi-extrinsic 11y ago
    So let me see if I get this. The build process runs a huge autoconf etc., then compiles from C code a proto-emacs, which is then executed and loads up a bunch of Lisp code, then a (self-described as) ugly hack is used to dump that running program (including the loaded Lispy-bits) as a new executable, which is your editor? Wow.

malkia 11y ago

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.

mrob 11y ago
That level of smoothness absolutely should be the norm. And not just 60fps, but ideally 120fps/144fps/higher (eg. new DisplayPort 1.4 240Hz monitors when they are released). Every dropped frame, every timing inconsistency, is a small attack on your concentration. When a tool acts quickly and predictably you can treat it as a part of your own body (see https://en.wikipedia.org/wiki/Body_schema https://en.wikipedia.org/wiki/Body_schema ). When it responds slowly or inconsistently this requires conscious effort that could be better spent on solving the problem. For example, every libvte based terminal emulator is capped at approximiately 40fps. 40fps isn't even an integer multiple/divisor of any common refresh rate! It annoys me every time I see it, and it's symptomatic of the casual attitude to UI responsiveness that has modern software running worse than some ancient MS-DOS software did on a 386.

caf 11y ago

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).