once you have virtualized OS support embedded in a wrap like docker why do you need the definition of the sysctl() calls as a spec? Ok so clearly the people who write virtualization need some equivalent, but basically, virtualbox or parallels or vmware plus docker == "I run a miniature clone of the real underlying OS" so the premise behind the ABI spec in POSIX which made it possible to write code depending on runtime calls into systems libraries is somewhat moot. I suspect that a minority of programs tickle things which are POSIX+/- later and they never work well. LSB sort of works. Sort of. WINE manages to handle an amazing number of things, with no formalized POSIX equivalent boundary definition. So this is a view from the "I want to run this binary I have been given" world view, which is mostly the consumerist take. "I want a roughly plausible story to compile this code on a different OS" is a different take. I recently had some code which had to compile a C to Python shared library to extend the python core, with OpenSSL calls. its well written. It works on FreeBSD from its porting base in Debian, and the author is not stupid, and writes code in wide public support (I won't out him but he's an old school MIT graduate and really can code very well) it simply doesn't work as-is on OSX. So clearly, something in the API/ABI space as compiled up for OSX, for this source mashup gets outside the boundary of what I believe POSIX tries to do. So.. how did POSIX help? Did it avoid the problem? Nope. Did it make the problem surface smaller? Probably. -G On Thu, Feb 15, 2018 at 6:53 AM, Clem Cole <clemc(a)ccc.com> wrote:

Purely from my own perspective, and perhaps a little round about … As an ISV, the best customer experience comes from having your software provided in the distribution’s repositories. That implies that your product be both gratis and libre (to some definition). At that point, it’s an ‘apt’, ‘yum’, etc away. Second best is in the distribution’s secondary repositories (Universe, Extras, EPEL, etc). A customer potentially has to fiddle with their enabled repositories, but that’s a one-off, and afterwards plain sailing. This mostly requires source availability unless your product is something that’s very widely demanded, and the source not feasibly made available (eg. Adobe Flash player browser plugins, or similar). Note that for some customers, they are not permitted (by their internal compliance people) to enable eg. EPEL. Third best is where you host package repositories yourself for a selection of distributions you care about. This is basically the best customer experience possible for commercially-licensed binary-only distribution. The end-user has to import your repository definition, approve your certificate, etc, but that’s a one-off thing, fairly simple to do, and thereafter they can install and update anything you publish with minimal effort. Compliance-wise, this is actually easier than the vendors’ secondary repos, because it’s limited to one company with whom there’s a contractual relationship. In that context … POSIX matters largely as an historical artefact: it means that Linux and macOS are mostly compatible. But new features are added relatively frequently, and there’s apparently minimal value placed on compatibility with others. The bulk of your application code is compatible (ie. all the POSIX stuff), but corner cases need compatibility handling. The UI, the filesystem, etc, often ends up being entirely different. LSB had numerous issues: * It was too minimal, not including much beyond basic POSIX. IIRC, it didn’t include even OpenSSL, for example (at least in earlier editions) * It was often an optional package, needing to be installed before LSB-based applications would work * It then had different versions, and vendors were late to implement the later (more broad) requirements, so in practice you could only rely on the base set * After all of that, an LSB-based package was still typically installed and maintained differently from everything else on the system, so the end-user’s experience was pretty bad In my experience, you were actually better off just building on glibc and making a minimal (POSIX-ish) set of assumptions about installed utilities and filesystem layout). That way at least you avoided the issues of needing to install LSB-compatibility packages, versioning of the LSB packages, etc. Implicit in all of this is that the market for commercial Unix and the BSDs is negligible, and has been for basically 10 years. Aside from a brief uptick for Solaris 10, that was pretty-much true from about Solaris 7 onwards. RHEL3+ and SLES9+, and then later Ubuntu LTS, and perhaps Darwin/Mac OS X/macOS covered enough of the market. Today, macOS is the worst to support, since it doesn’t have a system package manager so you have to handle the patching/update process yourself, AND it’s a different kernel, C runtime, and vendor userland libraries. RHEL/CentOS and Ubuntu LTS cover most customers. SLES still has a few niches, but it's dying. macOS is used only as a client, and mostly that doesn’t matter since applications are using a web UI on a Linux backend anyway. I think the bigger question is really … is there really still a market for commercially-licensed installable software packages? The set of things that cannot be delivered via the web, and are not available as Free/Open Source is ever-shrinking. The operating system as we know it has become a substrate. Linux has won, and the battle has moved on to the services layer. d