"A senior OpenBSD developer has complained on a mailing list that upstream vendors of free and open source software are adding in changes without any thought of whether downstream users could adapt to the change. Marc Espie said this would hurt smaller players by not allowing them to keep up with the changes. Basically what is happening is that numerous changes are being made to Linux and smaller projects like OpenBSD cannot keep up with the changes. And, according to Espie, not all these changes are strictly necessary."

If you had read the article, you'd know that a big source of the problem is pointless changes, especially in build scripts, where things like GNU sed is required, even though the same thing could very easily be done with any sed in a widely-compatible way.

It is getting worse, as it seems (in the interviewee's view) that newer POSIX standards just seem to be rubber stamping in GNU tool chain features into the standard, with little or no consideration of non-GNU tool chains, even if they're doing really cool, innovative stuff.

If you had read the article, you'd know that a big source of the problem is pointless changes, especially in build scripts, where things like GNU sed is required, even though the same thing could very easily be done with any sed in a widely-compatible way.

It is getting worse, as it seems (in the interviewee's view) that newer POSIX standards just seem to be rubber stamping in GNU tool chain features into the standard, with little or no consideration of non-GNU tool chains, even if they're doing really cool, innovative stuff.

You both miss my point.

Yes, it makes it harder to port those programs to OpenBSD. But they're not OpenBSD's core environment. And the BSDers have a problem with GPL software (as mentioned in the article, which I have not only read, but comprehended) that means they'll have to write their own version anyway.

The point is that quite a few Linux developers seems to have acquired the mindset previously (and currently) held by many Windows developers: "It works on my primary platform, who gives a shit if it's portable?"

GNU sed is required, even though the same thing could very easily be done with any sed in a widely-compatible way.

Quoting the article:
"and no, gsed -i is not a valid excuse. Come on, you need half a line of shell script to do the equivalent of gsed -i"

Sure adding half a line of shell script (I assume 40 characters, right?) is "easy", but it cluters, and if you have to do it every time it becomes a pain. And people don't use the GNU extension because they don't bother to check, but because they are damn convenient.

Personnaly at work, I mainly use a Linux box, and I also have from time to time to use a Solaris box, and it is just a pain in the ass to have to write things like "find . | xargs grep 'somestring'" instead of just "grep -r 'somestring'" and so on. In the end I just end up using the GNU tools on Solaris as well.

GNU extensions were not created to make the system incompatible, they were created for convenience. And I don't see why it should be up to upstream to spend extra work on supporting other platform.

Quoting the article:
"and no, gsed -i is not a valid excuse. Come on, you need half a line of shell script to do the equivalent of gsed -i"

Sure adding half a line of shell script (I assume 40 characters, right?) is "easy", but it cluters, and if you have to do it every time it becomes a pain. And people don't use the GNU extension because they don't bother to check, but because they are damn convenient.

Personnaly at work, I mainly use a Linux box, and I also have from time to time to use a Solaris box, and it is just a pain in the ass to have to write things like "find . | xargs grep 'somestring'" instead of just "grep -r 'somestring'" and so on. In the end I just end up using the GNU tools on Solaris as well.

GNU extensions were not created to make the system incompatible, they were created for convenience. And I don't see why it should be up to upstream to spend extra work on supporting other platform.