|
|
|
|
|
|
by vu3rdd
3853 days ago
|
|
|
While what you are saying is very true, recent developments around systemd seem to have changed a few people to target linux-kernel based systems than the BSDs. As the autoconf files suggest, a lot of GNU software was written in the most general way possible, targeting even the macos/osx/windows/aix/hpux etc. In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs. |
|
|
GNU software originally ran on proprietary UNIX systems by necessity (because no non-proprietary UNIX systems existed), hence their portability; even after Free Software systems existed, having such software available on proprietary UNIX systems provided a great advertisement for GNU (especially since the GNU software typically worked better, and users could obtain tools for free with full source that they previously had to purchase separately in binary form).
More recent software (GNU and otherwise) doesn't typically include compatibility with obscure proprietary UNIX systems (especially long-dead ones), because such systems no longer particularly matter, and seem unlikely to gain new users. Portability to, for instance, HP-UX or Cray systems isn't even worth the time spent detecting and maintaining crazy build-time conditionals, or even the minor chance of introducing a bug. And, perhaps more importantly, the authors of the software don't particularly want to test on such systems, and a port you don't regularly test won't keep working.
Even a back-of-the-envelope order-of-magnitude estimate of the total amount of developer time, system time, and power consumed running ./configure scripts that autodetect conditions nobody seems likely to ever use again produces some scary numbers. ./configure takes an obscenely long time to run, often far longer than make.
> In this age of easy virtual machine installations, it seems odd that software authors of popular software are not targeting at least the BSDs.
That doesn't seem odd to me at all.
For most software, I wouldn't mind taking patches to support BSD, but that doesn't mean I'll go install a BSD system, try to figure out BSD conventions and policy, fix portability issues myself, and maintain continuous integration for BSD to make sure it keeps working. If I wanted to put time and effort into testing my software for portability to other systems, I'd first confirm that it built and ran on Fedora in addition to Debian; I've encountered issues with that due to Fedora's incompatible paths for 32-bit/64-bit libraries.
There are exceptions: I went out of my way to do exactly that as part of making sure XCB ran on the Hurd. I did that partly for novelty (I knew nothing about the Hurd, and afterward I knew slightly more than nothing), and partly because XCB needs to run everywhere X and Xlib can. Even then, though, the resulting port got maintained by actual Hurd users.
So while I'd take a patch to support BSD, I'd rely on the submitter of the patch to keep it working over time, and to let me know if it broke. (And if someone felt sufficiently dedicated to do so, I'd probably give them commit access to help maintain it.) But in the absence of a dedicated BSD developer interested in maintaining the port, I can definitely understand why people wouldn't go out of their way to target BSD.