Comment by wahern | Hacker News Reader

Comment by wahern | Hacker News Reader

Parent Full thread

Which distro? Which libc? Which minimum kernel version? Which minimum version of GNU Make? Which specific version of GCC or clang?

Linux isn't a static environment. The closest thing to static is POSIX, and by and large every Unix environment, including various Linux environments as well as BSD environments, asymptotically approach POSIX compliance.

If you want to maintain a project long-term (5+ years), attempting to minimize deviations from POSIX is a solid strategy in terms of avoiding bit rot and long-term maintenance burdens. Sometimes it's unavoidable, but the point is to weigh your options carefully and don't undervalue the benefit of POSIX compliance. If you want to maximize the chance that your software will compile and execute correctly on a Linux distro 5+ years from now, a good first step is making sure it builds and runs natively on some of the BSDs.

There's a trend to discount the value of POSIX and to even actively break POSIX compliance in a way that makes it very difficult to support both POSIX semantics and some feature du jure. Developers should be wary of those who do this because if such projects and their maintainers don't see any value in POSIX they're not likely to see value in the long-term maintenance and stability of whatever feature they're selling you on today.

Else thread somebody says that they see Linux as the new SunOS. I agree.[1] But where is SunOS today?

[1] Except that Sun put much more emphasis on backwards compatibility. The Linux kernel developers emphasize backward compatibility, but the distros don't, and if the distros rip something out then inevitably it gets removed from upstream. OTOH, while the kernel developers rightfully have said they won't compromise sane design for POSIX, it turns out that such situations have been exceedingly rare and in general they take POSIX compliance seriously.

maintainers don't see any value in POSIX

The problem is that POSIX only provides a tiny subset of the API surface that an application might need today. Just to give two random examples: how can an application inhibit system sleep or use a webcam? The best one often can do is rely on some widely-used library and hope that they (will continue to) support multiple platforms.

But where is SunOS today?

Comparing apples and oranges. For a large part of its lifetime, SunOS was a proprietary UNIX that only worked with Sun hardware. If we include SunOS 5/Solaris, they open sourced Solaris way after Linux already had a stronghold in the market.

Linux is now so dominant in mobile phones, servers, network devices, and IoT, that even it will take much longer to disappear than SunOS.

The other problem is that POSIX is horrible. See eg:

- http://www.daemonology.net/blog/2011-12-17-POSIX-close-is-br... It's impossible to reliably close a file if you have active signal handlers that might be triggered.

- https://www.sqlite.org/src/artifact/c230a7a24?ln=994-1081 (discussed at https://news.ycombinator.com/item?id=17601581 "POSIX advisory locks are broken by design.")

- Seemingly anything to do with terminal devices or job control. (Allocating ptys, sending control sequences like ^D or ^Z, adding processes to a group that will all recieve terminal signals together, etc.)

- 'Basic' regular expressions (as in `echo baaar | grep 'a+' || echo WTF`).

- The existence of hard links as anything beyond a destination cache for symlinks.

Most operating systems have problems like these, but POSIX proceeds to enshrine them as unfixable 'features' rather than "DEPRECATED: DO NOT USE". (On the plus side, F_SETLK(W) and close seem likely to be fixed at some point and close doesn't tend to get maliciously exploited the way eg integer overflow does by C compilers.)

Every implementation of close, except on HP/UX, will close the file descriptor before returning upon a signal. But POSIX has actually approved posix_close, which will guarantee the proper, desired semantics. See http://austingroupbugs.net/view.php?id=529

The semantics of POSIX advisory locks were inherited; they codified the most widely used existing implementation. The ergonomics suck, but they offer one distinct advantage: you can query the PID of the lock holder, something not possible when a lock can be inherited. This can be useful for PID file locks where you can query the PID directly rather than trying to write and read it from the PID file; there's no loaded gun lying around, although there's still the TOCTTOU race between querying and kill'ing. In any event, "file-private" advisory locks are likely to be standardized and are already implemented by both Linux and FreeBSD. See http://austingroupbugs.net/view.php?id=768 The semantics are not coincidentally very similar to BSD flock, and the types similar to POSIX. Which is noteworthy because it's an example of how paying attention to POSIX and portability issues can help you triangulate the evolution of Linux interfaces down the road.

It's not like Linux is without its warts. The kernel's implementation of setuid & friends is per thread. That's not only horribly inconvenient semantics for 99% of use cases, it's a security nightmare. And glibc and musl must implement an obscenely complex dance to get process-wide, atomic behavior. There are also many legacy Linux interfaces that the project is committed to supporting because of its commitment to backwards compatibility. I don't understand the logic of pointing out all the anachronisms of POSIX (e.g. advisory locks) while ignoring the anachronisms of Linux.

I never said POSIX was perfect, and I'm not arguing to only stick to POSIX. There's no substitute for using your own good judgment. I'm simply saying that too many people don't appreciate the benefits of POSIX and portability more generally, which are substantial. The benefits aren't just the standard itself or the ability to use an alternative OS like FreeBSD--if you didn't care before you're almost certainly never going to--but the fact that every Unix vendor tracks the standard and, to a lesser extent, avoids gratuitous incompatibilities with other POSIX environments. Standardization signals important information about the stability of an interface, and the process of standardization channels the evolution of interfaces long before they become standardized (if ever). POSIX and the BSDs matter to Linux development; and they should matter to Linux developers even if they'll never run code outside of a Linux environment.

It's also worth mentioning that Red Hat basically steers POSIX, now, judging by the Austin Group Bugs issue tracker. So while some teams are rather antagonistic toward POSIX (e.g. Poettering and systemd team), others put considerable effort into it.

> If you want to maximize the chance that your software will compile and execute correctly on a Linux distro 5+ years from now, a good first step is making sure it builds and runs natively on some of the BSDs.

Like everything, this is a trade-off: what you are advocating is that people use a more or less frozen sub-set of features, and avoid improvements that are already de-facto standard.

I looked at what would happen if my employer standardised shell scripting on "sh", rather than "bash", and quickly concluded that it was a bad tradeoff for us: Bash is, has has been, the standard shell in every place that we would want to run non-trivial shell scripts: if we ran Alpine Linux containers, we could just treat those as a special case.

Using bash instead of sh is ok enough (some people won't agree), but what's bad is writing bash script and using #!/bin/sh

Reply on news.ycombinator.com