Advertisement
GStreamer Conference 2013, 22-23 Oct, Edinburgh
GStreamer, Embedded Linux, Android, VoD, Smooth Streaming, DRM, RTSP, HEVC, PulseAudio, OpenGL. Register now to attend.
| |||||||||||||
Big success - so congrats!Big success - so congrats!Posted Sep 30, 2013 1:38 UTC (Mon) by torquay (guest, #92428)In reply to: Big success - so congrats! by david.a.wheeler Parent article: 30 years of GNU
Perhaps at the level of kernel, glibc and Xlib calls, but not much else. At other levels, the plethora of Unix-like operating systems (ie. Debian, Fedora, Ubuntu, RHEL, Suse, Arch, etc) are at best quasi-compatible. Even within a particular vendor there are no guarantees of API and ABI compatibility of version N with version N-1. Having multiple open-source operating systems is certainly far better than not having them, but we're still in a pretty sad state of affairs. The API and ABI incompatibilities are an impediment to wider adoption.
(Log in to post comments)
Big success - so congrats! Posted Oct 1, 2013 0:33 UTC (Tue) by smoogen (subscriber, #97) [Link]
I think he was referring to being compatible to Unix not to being compatible with each other.
Big success - so congrats! Posted Oct 4, 2013 0:25 UTC (Fri) by wahern (subscriber, #37304) [Link]
As smoogen said, I think he was referring to Unix-like systems in general, including FreeBSD, etc.
RMS participated in the POSIX standardization process, especially by writing and steering GNU projects toward POSIX compatibility.
All modern Unix-like systems converge on POSIX. Yes, they all have their proprietary interfaces as well, but those tend to be bleeding edge and subject to change anyhow. Write the majority of your application for POSIX compliance, and you dramatically reduce your workload, including API worries. If some POSIX API isn't available today on a platform, it will be tomorrow.
As for ABI worries... pfftttt. ABI compatibility is mostly a problem for proprietary software, not open source software. If you're writing FOSS and worried about ABIs, you're doing it wrong. If you're writing proprietary software, perhaps you need to get with the program. Develop your application as-if it were FOSS (stick to the standards, including obsessing over a simple build stage) and just skip the part where you distribute source code. Target something like FreeBSD or OpenBSD, and you'll find that the differences among Linux distributions melt away into nothingness. It's a nice side-effect of portability. Being portable to non-Linux systems today means being portable to future Linux systems tomorrow.
Big success - so congrats! Posted Oct 4, 2013 10:30 UTC (Fri) by nix (subscriber, #2304) [Link] If you're writing FOSS and worried about ABIs, you're doing it wrong.Not if you're writing libraries. If you ship a new version of a library with significant use under the same soname and all its consumers break, people will be unhappy, even if they could 'just' recompile them all.
Big success - so congrats! Posted Oct 4, 2013 10:56 UTC (Fri) by mpr22 (subscriber, #60784) [Link] Write the majority of your application for POSIX compliance, and you dramatically reduce your workload, including API worries. My application is in C++ and uses terminal graphics (ncursesw). POSIX has virtually nothing to say about C++ (except by implication from saying things about C), and nothing conveniently usable to say about terminal graphics (it specifies termios, but not term{cap,info} or curses). At some point, it's going to acquire audio playback and bitmap graphics - both of which, again, POSIX has nothing to say about.
Big success - so congrats! Posted Oct 4, 2013 11:17 UTC (Fri) by dlang (✭ supporter ✭, #313) [Link]
but POSIX does say a lot about what the API to the OS looks like. If your program (or it's libraries) written in language FOO stick to using the POSIX system calls, then you are probably in really good shape. If they don't, then you are likely to have problems at some point.
|
|||||||||||||