3 ms·

What would be gained by making more different formats? Also #!/bin stuff is executable in sense and the most files in Windows that have default application set.

What would be gained by making more different formats? Also #!/bin stuff is executable in sense and the most files in Windows that have default application set. Dirt simple model works until it doesn't. Without address space separation there is no safety between executables and cooperative scheduling is the same. Running faulty binary or simply bit flip in ram can crash the whole system instead of just that process.

duped 3y ago
I mean there's value in being able to grok it without having read "Linking and Loading" and we don't want an Asimov scenario (I can't remember if this is Foundation or the Last Question) where we just truck on assuming things work without understanding how they work. And there's a lot of arcane knowledge in executable formats buried in mailing lists and aging/dying engineers on how and why decisions about these formats were designed. "How does loading work" has a simple answer: you map the executable into virtual memory and jump to the entry point. But the "why does XYZ format do this to achieve that" has a lot of nuance and design decisions - none of which are documented. Particularly things like RTLD, which is designed heavily around the design of glibc and ELF, while the designer of the next generation of AOT or JIT compiled languages for operating systems with capability based models for security might want to understand before they design the executable format and process model that may deviate from POSIX. There's space for design and research there, and a platform that makes that easy has a lot of value. While I would encourage the designer of such a platform to read the literature and understand why certain things are done the way they are, it's valuable to question if those reasons are still valid and whether or not there's a better way.
- KineticLensman 3y ago
  > I can't remember if this is Foundation or the Last Question Foundation. The Galactic Empire makes use of atomic energy and other technologies that were created in the distant past and the technicians can only (sometimes) repair but not create. 'The Last Question' has a question that remains unanswered throughout human history, which isn't quite the same thing.

duped 3y ago

I mean there's value in being able to grok it without having read "Linking and Loading" and we don't want an Asimov scenario (I can't remember if this is Foundation or the Last Question) where we just truck on assuming things work without understanding how they work. And there's a lot of arcane knowledge in executable formats buried in mailing lists and aging/dying engineers on how and why decisions about these formats were designed. "How does loading work" has a simple answer: you map the executable into virtual memory and jump to the entry point. But the "why does XYZ format do this to achieve that" has a lot of nuance and design decisions - none of which are documented. Particularly things like RTLD, which is designed heavily around the design of glibc and ELF, while the designer of the next generation of AOT or JIT compiled languages for operating systems with capability based models for security might want to understand before they design the executable format and process model that may deviate from POSIX. There's space for design and research there, and a platform that makes that easy has a lot of value. While I would encourage the designer of such a platform to read the literature and understand why certain things are done the way they are, it's valuable to question if those reasons are still valid and whether or not there's a better way.

KineticLensman 3y ago
> I can't remember if this is Foundation or the Last Question Foundation. The Galactic Empire makes use of atomic energy and other technologies that were created in the distant past and the technicians can only (sometimes) repair but not create. 'The Last Question' has a question that remains unanswered throughout human history, which isn't quite the same thing.