4 ms·
> In Fomos, an app is really just a function. There is nothing else ! This is a huge claim. An executable for a Unix or Windows OS is extremely complex compared
by duped 3y ago
> In Fomos, an app is really just a function. There is nothing else ! This is a huge claim. An executable for a Unix or Windows OS is extremely complex compared to a freestanding function.
I'm curious what Fomos uses as a distinction between "process" and "executable."
On Linux a "process" is the virtual address space (containing the argv/envp pointers, stacks, heap, signal masks, file handle table, signal handlers, and executable memory) as with some in-kernel data (uid, gid, etc) that determine what resources it is using and what resources it is allowed to use.
An "executable" is a file that contains enough bits for a loader to populate that address space when the execve syscall is performed.
One of the distinctions is that you do not need an executable to make a process (eg, you can call clone3 or fork just fine and start mucking with your address space as a new process) and while the kernel uses ELF and much of the userspace uses the RTLD loader from GLIBC you don't need to use either of these things to make a process in a given executable format.
And finally, a statically linked executable without position independent code is "just a function" in the assembler sense, with just enough metadata to tell the kernel's loader that's what it is. But without ASLR to actually resolve symbols at runtime, it's vulnerable to a lot of buffer overflow attacks if the addresses of dependency functions are known (return to libc is one of those, but it's not unique).
I'm the first to point out the flaws in glibc and want an alternative to the Posix model of processes (particularly in the world where the distinction between processes, threads, and fibers is really fuzzy and that is clear even within Linux and Windows at the syscall level), but I'm curious what is going on in Fomos. Most of the complexity in "executables" in Unix is inherent (resolving symbols at runtime is hard, but also super useful, allowing arbitrary interpreters seems annoying, but is one of the strengths of Linux over Windows and MacOS, providing the kernel interface through stable syscalls is actually the super power of Linux and a dynamic context either through libc or a vtable to do the same thing is not that great, etc).
- duped 3y agoThinking about it for a few more minutes, one thing that I think is the great mistake is a homogenization of executable formats (everything on Mac is Mach-O, everything on Windows is PE, everything on Linux is ELF, etc). There's no reason we can't have a diverse ecosystem of executable/linkage formats - and an OS with a dirt simple model for loading in code is a great place for that.
- kukkamario 3y agoWhat 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 agoI 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.
- dee-bee 3y ago> providing the kernel interface through stable syscalls is actually the super power of Linux I thought that it was drivers? Linux isn't particularly unique for having a stable abi (and the utility of such a decision is highly questionable). The driver support however is extraordinary and undeniable.
- dejv 3y agoDid you take a look on how Zircon (Fuchsia) is handling this? It is quite interesting.