5 ms·

POSIX only defines source-code level compatibility. However, all OSes are free to implement their system calls any way they want. In order to run binaries comp

POSIX only defines source-code level compatibility. However, all OSes are free to implement their system calls any way they want. In order to run binaries compiled for a specific OS, you need to emulate that OS's (i.e. kernel's) ABI. There's no way around that. The only way to achieve true binary compatibility would be to use a system-level virtual machine, ala Inferno [0] or PhantomOS [1]. [0] https://www.inferno-os.org/ https://www.inferno-os.org/ [1] http://phantomos.org/ http://phantomos.org/

jay-barronville 3y ago
I don’t think the point was about ABI compatibility across operating systems—that’d be unreasonable. It’s more so about using POSIX API’s as much as possible to enable portability rather than relying on Linux-specific API’s that make compiling the code an unnecessarily frustrating experience. Sometimes, using Linux-specific API’s is inevitable, but in the overwhelming majority of cases, POSIX API’s work just fine and would make the code instantly more portable.
- bheadmaster 3y ago
  Even on the source level, there are certain limitations to POSIX, e.g. linux uses epoll() which is more performant than poll(), but isn't defined by POSIX. So application writes sometimes have to choose between making code more portable or making it more performant.
  - woooooo 3y ago
    Anyone know why we can't get a new POSIX with some epoll/kqueue equivalent, maybe baking in some of the lessons learned from epoll's interface? It's insane in 2023 that people are typing things like EPOLL_ONESHOT and it's actually the best option.
    - pjmlp 3y ago
      Linux wars replaced UNIX wars, and POSIX moves slow.
rollcat 3y ago
What's funny is we've tried so many different, "better" solutions to build once, run anywhere. I truly love Inferno - learned SO much reading the dis VM bytecode spec; JVM was and still is a thing; there's even .NET IR which was built with the specific, explicit goal of getting JIT'ted for the target CPU. The two de-facto solutions ended up being: - win32/wine; - Linux emulation - the kernel itself has an incredibly stable interface, but you basically need to ship an entire RHEL/Ubuntu installation on top. My sincere hope is that APE/Cosmopolitan takes off and eats everyone's lunch AND the table. It even recently got some funding - turns out it's the easiest way to ship LLM models (finally something good may come out of this hype cycle).
- AshamedCaptain 3y ago
  The kernel does _not_ have an incredibly stable interface. It is in the fact part of the reason older statically linked versions of glibc no longer work. I personally count at least two breaking changes, and only one of them got an option in Kconfig (which was related to ASLR iirc, so distros rushed to enable the "break compatibility" option). . Yet another example dynamic linking almost always makes things easier for your future users, despite the preconceptions. Just grep your kernel's Kconfig for "ancient" -- the euphemism every developer uses to refer to stuff they don't care about and want to break. Also, stuff in /proc, /sys, or the like is moving every other day, and some programs depend on it (sigh).
- pjmlp 3y ago
  Cosmopolitan only works for basic C APIs, for example working with 3D API, talking to game controllers over LE Bluetooth. JVM is doing quite alright across desktop, servers, embedded and 80% of mobile phones. .NET less so due to Microsoft's strategy error to bind it to Windows. Still nowadays my .NET workflow is exactly like my Java one. Work on Windows, deploy where needed. I don't think in POSIX since 2006.

jay-barronville 3y ago

I don’t think the point was about ABI compatibility across operating systems—that’d be unreasonable. It’s more so about using POSIX API’s as much as possible to enable portability rather than relying on Linux-specific API’s that make compiling the code an unnecessarily frustrating experience. Sometimes, using Linux-specific API’s is inevitable, but in the overwhelming majority of cases, POSIX API’s work just fine and would make the code instantly more portable.

bheadmaster 3y ago
Even on the source level, there are certain limitations to POSIX, e.g. linux uses epoll() which is more performant than poll(), but isn't defined by POSIX. So application writes sometimes have to choose between making code more portable or making it more performant.
- woooooo 3y ago
  Anyone know why we can't get a new POSIX with some epoll/kqueue equivalent, maybe baking in some of the lessons learned from epoll's interface? It's insane in 2023 that people are typing things like EPOLL_ONESHOT and it's actually the best option.
  - pjmlp 3y ago
    Linux wars replaced UNIX wars, and POSIX moves slow.

rollcat 3y ago

What's funny is we've tried so many different, "better" solutions to build once, run anywhere. I truly love Inferno - learned SO much reading the dis VM bytecode spec; JVM was and still is a thing; there's even .NET IR which was built with the specific, explicit goal of getting JIT'ted for the target CPU. The two de-facto solutions ended up being: - win32/wine; - Linux emulation - the kernel itself has an incredibly stable interface, but you basically need to ship an entire RHEL/Ubuntu installation on top. My sincere hope is that APE/Cosmopolitan takes off and eats everyone's lunch AND the table. It even recently got some funding - turns out it's the easiest way to ship LLM models (finally something good may come out of this hype cycle).

AshamedCaptain 3y ago
The kernel does _not_ have an incredibly stable interface. It is in the fact part of the reason older statically linked versions of glibc no longer work. I personally count at least two breaking changes, and only one of them got an option in Kconfig (which was related to ASLR iirc, so distros rushed to enable the "break compatibility" option). . Yet another example dynamic linking almost always makes things easier for your future users, despite the preconceptions. Just grep your kernel's Kconfig for "ancient" -- the euphemism every developer uses to refer to stuff they don't care about and want to break. Also, stuff in /proc, /sys, or the like is moving every other day, and some programs depend on it (sigh).
pjmlp 3y ago
Cosmopolitan only works for basic C APIs, for example working with 3D API, talking to game controllers over LE Bluetooth. JVM is doing quite alright across desktop, servers, embedded and 80% of mobile phones. .NET less so due to Microsoft's strategy error to bind it to Windows. Still nowadays my .NET workflow is exactly like my Java one. Work on Windows, deploy where needed. I don't think in POSIX since 2006.