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 kerneldevelopers 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.
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.
- 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.)
- 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.
Isn't that the history of computing? the word UNIX points at the disdain its makers had for Multics. They broke every rule IBM had.
PCs were these toys for people who had no acces to real computers, until they were the standard. Microsoft provided toy OSes until they wiped out almost anybody else. Java, MySql and subversion are other examples.
I've read somewhere that every succesfull product has a phase where the world laughs at it. If that hadn't happened, it would have been smothered in the cradle by the behemots of its time. Being laughed at gave it time to grow.
They break the rule these days by actually giving a shit about security instead of doing what many of us are guilty of doing: dumbing it down for the lowest common denominator user to make money.
Has created some incredible UI paradigms and elements, but...
I think of linux as the new SunOS 4.x. I remember back in the day when random crap you got would work fine on SunOS, but was a pain on HP-UX, AIX, or whatever other weird unix you had around. Now linux is like SunOS 4.x was back then.
The analogy isn't used correctly : BSD was initially a codebase clone of UNIX, in other words, BSD is a fork.
GNU/Linux was initially developed from scratch to behave like UNIX to a certain extent (hence the name "Unix-like"). In other words, it's a rewrite inspired from a model.
"BSD is what you get when a bunch of Unix hackers sit down to try to port a Unix system to the PC. Linux is what you get when a bunch of PC hackers sit down and try to write a Unix system for the PC."
UNIX is a trademark, so you may not call something UNIX unless you are allowed to use that trademark (which costs several 100k USDs to get certified). Apple paid that price for macOS, so (certain versions of) macOS are UNIX.
macOS has a marketshare in server market segment of around 0% (client of around 5%, iOS substantial though), and Linux is the defacto standard in that area. Which OS do people learn nowadays? Linux distributions. So it makes sense to see it from that PoV. Because chances are that you're going to use that defacto standard. And even if you prefer UNIX(tm) or BSD or Solaris you'd rather use Linux than Windows or OpenVMS. Cause the latter are aliens from outer space.
