| |||||||||||||
Crowding out OpenBSDCrowding out OpenBSDPosted Nov 14, 2012 18:28 UTC (Wed) by jwakely (subscriber, #60262)In reply to: Crowding out OpenBSD by cruff Parent article: Crowding out OpenBSD
> a well defined common base, such as POSIX
Which release? I'm not sure all the BSDs are down with some of POSIX-2008 yet (though I have only looked at recent-but-not-current releases)
> only required some straight forward GNU make makefiles
Later in the thread Espie complained [1] that GCC requires GNU make, apparently even that requirement is too much ;)
But then he also complained that GCC major releases are a few years apart (which was true a few years ago, but not now) and that changes only go in the trunk not release branches (so what? push your changes upstream and maintain patches in the ports collection against old releases, then drop the patches when a new release comes out that already has the changes ... surely that's obvious?) The implication in [1] that GCC only builds on Linux is ridiculous, plenty of other OSs manage to keep GCC trunk building without herculean effort, if OpenBSD can't it's not GCC's fault. I've made sure NetBSD does myself, not because I ever use it, but just because I had access to a box.
(Log in to post comments)
Crowding out OpenBSD Posted Nov 14, 2012 18:49 UTC (Wed) by jwakely (subscriber, #60262) [Link]
Sorry, wrong link, [1] should be http://article.gmane.org/gmane.os.openbsd.tech/30747
Crowding out OpenBSD Posted Nov 14, 2012 23:54 UTC (Wed) by wahern (subscriber, #37304) [Link]
It doesn't matter whether every Unix supports all of POSIX. What matters is that they everybody aims for common or similar abstractions, and that people test, test, test. "Portability" is a process.
I wrote a C library, wrapped in Lua, which does O(1) polling, async file notification, async DNS, async SSL, wrapped almost all of OpenSSL's X.509 key bindings, async descriptor passing, and async thread management in just about one week's worth of man power. The only dependency is OpenSSL.
Not only that, but I wrote it and maintain it for Linux, OS X, Solaris, FreeBSD, NetBSD, and OpenBSD.
http://25thandclement.com/~william/projects/cqueues.html
I learned one very important thing doing that: the BSDs generally have the better abstractions (particularly in kqueue), though Linux has more comprehensive POSIX API support. But in any event, it simply wasn't that difficult to write all of that portably, and in a small amount of code. And with VMs, it's been trivial to maintain the build for all the present releases of those systems.
The reason why people have a problem with portability is because even the best programmers fall into the habit of cargo cult programming. They're new to some API and scour usenet (or more likely these days, stackoverflow.com) looking for descriptions and usage examples. Then they copy the examples and move on.
But if you take the time to study the APIs, to study POSIX, and to study the implementation code (thank you, open source), then portability just isn't that big of deal. And the end result is that your program is more robust, because not only are more code paths tested, you actually understand what the heck is happening, as well as understand how and in what direction the APIs will evolve in the future.
It's important to constantly test on different platforms, though, and not to let portability issues fester and metastasize. But that's, sadly, what is happening with most open source software these days. People not only just don't care, they openly reject the idea portability. And that's a damn shame.
As for GNU Make, writing portable make is easy, but I allowed myself that single convenience, mostly because GNU Make is readily available everywhere. The BSD makes are almost as powerful, and I've even begun writing a make parser+compiler to translate between them. Mostly because GNU Make is darned ugly, and some of the BSD make syntax features are easier to understand while remaining just as powerful; so I want to write in a subset of of my favorite features from the different makes and then translate to each accordingly.
Crowding out OpenBSD Posted Nov 14, 2012 23:56 UTC (Wed) by wahern (subscriber, #37304) [Link]
And FWIW, signal notification. Although, Solaris doesn't have a pollable signal facility.
Crowding out OpenBSD Posted Nov 15, 2012 2:52 UTC (Thu) by nix (subscriber, #2304) [Link] Later in the thread Espie complained [1] that GCC requires GNU make, apparently even that requirement is too much ;)Well, that's politics, isn't it. GNU Make is GPLed, therefore bad (even though it doesn't contaminate projects built with it), therefore all projects should work with BSD make as well. (That the program being compiled is both GPLed and a flagship GNU project itself apparently does not affect this policy in its case, though common sense says it probably should.)
Crowding out OpenBSD Posted Nov 15, 2012 14:57 UTC (Thu) by jwakely (subscriber, #60262) [Link]
Indeed it is politics, and common sense should indeed let the GNU compiler use GNU make.
My point is that espie@ seems to want to have his cake and eat it. If you refuse to work with upstream (for technical or political reasons) then don't be surprised if upstream forgets about you.
On the plus side, as he says he is happy to leave kettenis@ to deal with GCC, and he recently pushed a load of patches from OpenBSD to GCC, which were gladly accepted (although I did forget to apply one until reminded, but I'd hardly call that "a fight".)
|
|||||||||||||