8 ms·

> If you think about it, in many ways the GNU project IMO ended up doing "embrace, extend, extinguish" with Unix. The "extend" phase from the Microsoft playboo

> If you think about it, in many ways the GNU project IMO ended up doing "embrace, extend, extinguish" with Unix. The "extend" phase from the Microsoft playbook is always something that competitors cannot duplicate. Either for legal reasons (patents) or technical reasons (having the "spec" depend on all of the Windows ecosystem). I don't think that's what GNU did.

stonogo 6y ago
No, this was pretty explicitly the reason GCC was not permitted to have independent front- and back-ends like llvm does today. Stallman was concerned someone would write proprietary extensions that way. So, if you wanted GCC, you got the whole GCC, GNU extensions to C and all.
- josefx 6y ago
  And you only got GCC. There was someone who tried to implement refactoring support for emacs based on gcc, since there already was a llvm based implementation and that obviously wasn't GNU enough. Stallman left him hanging for a year before telling him to stop because it would expose too many gcc internals. He ended up killing the discussion when too many people disagreed with his assertion that text base search and replace was good enough.
st_goliath 6y ago
GNU extensions are all over the place. The C library has all kind of GNU functions that are more convenient/practical than what Unix had, the command line programs (e.g. coreutils) have feature flags and extensions that the originals didn't have but that made them more convenient to use, and I already mentioned GNU extensions in the tar format. POSIX aside, Unix-like systems that are still around nowadays and not directly use GNU user space, have copied many of the GNU extensions out of necessity. People have become accustomed to those extensions and written programs & scripts depending on them, so you now need to implement many of the GNU extensions simply to stay compatible. Even if not consciously done and without malicious intents, this is IMO still fairly similar to how Microsoft played it: add extensions that are convenient, so people use them, eventually rely on them and become a de facto standard.
- vanviegen 6y ago
  But as you say, Unix vendors could just implement these features. That's not how Microsoft would have employed its infamous tactic.
  - pjmlp 6y ago
    I am yet to see Microsoft sue WINE for example. Any C compiler vendor (even commercial ones) does language extensions, mob => pushing the language forward. Microsoft does C compiler with language extensions, mob => get your pitchforks.
    - stinos 6y ago
      Similar for vendor lock-in. While very real, it wouldn't be the first time reading topics where the general sentiment is 'oh you poor Apple/MS/RedHat/Visual Studio/... user you're getting locked in, all hope lost' being written by people who don't recognize they are themselves following that principle merely by sticking to one particular OS/editor/debugger/...
- pjmlp 6y ago
  I used to be a Solaris fanboy (Linux was only the way I managed to have UNIX at home), and one of my regular tasks as Solaris admin was to install GNU from Solaris Packages repository due to software expectations.
- throw0101a 6y ago
  > GNU extensions are all over the place. On purpose and on accident: when Debian switched its /bin/sh from Bash to dash all sorts of things broke (for us) because GNUism were leaking into what should have been a standard language/feature set. We had to tell our users: change your code or change your shebang.
- rualca 6y ago
  > POSIX aside, Unix-like systems that are still around nowadays and not directly use GNU user space, have copied many of the GNU extensions out of necessity. That reads like a lack of interest to update POSIX to catch up with the de-facto sstandard I mean, I doubt that GNU would try to block the standardization process to avoid including their extensions.
blihp 6y ago
They pretty much did it with all of the utilities they produced... and I'm glad they did. I don't think it was nefarious, they just thought their extensions made sense at the time and/or filled gaping holes. Even in the early 90's it was painful to go from a machine with GNU stuff installed on it back to a vanilla System V system... they just felt so limited.
apotheon 6y ago
That's exactly what GNU did. GNU can take changes from software produced by others under copyfree licenses and wrap it in a copyleft license, then the projects from which it borrowed can't borrow-back the GNU changes because of license incompatibility that runs only one way. GNU licenses are very much embrace-extend-extinguish licenses.
- vanviegen 6y ago
  Perhaps the code itself couldn't be used by other vendors, but the ideas/protocols/interfaces could easily have been implemented by anybody who was so inclined. No trade secrets, no patents, and no dependencies on heaps of legacy cruft were necessary to be compatible. That's an important difference with "Embrace, extend, extinguish".
  - apotheon 6y ago
    Ideas, protocols, and (except perhaps in the post-Oracle-Java world) interfaces can still be copied. A lot of open source software actually does exactly that with ideas, protocols, and interfaces from closed source software. What makes open source software "open source" is the source code, which is subject to copyright law. Ideas, protocols, and interfaces are not subject to copyright; only their expressions are subject to copyright. The Embrace, Extend, Extinguish approach makes things incompatible with the way others do them to cement hold on a large user base that prevents those users from changing their minds later. Sometimes that takes the form of forcing people to reimplement everything in a cleanroom setting, because they can never keep up that way; that's where the GPL excels within the open source world for EEE. Other times, it's by diverging from norms in ways that others cannot follow without breaking their own ecosystems, which is where the GNU project has excelled with its plethora of subtle incompatibilities.

stonogo 6y ago

No, this was pretty explicitly the reason GCC was not permitted to have independent front- and back-ends like llvm does today. Stallman was concerned someone would write proprietary extensions that way. So, if you wanted GCC, you got the whole GCC, GNU extensions to C and all.

josefx 6y ago
And you only got GCC. There was someone who tried to implement refactoring support for emacs based on gcc, since there already was a llvm based implementation and that obviously wasn't GNU enough. Stallman left him hanging for a year before telling him to stop because it would expose too many gcc internals. He ended up killing the discussion when too many people disagreed with his assertion that text base search and replace was good enough.

st_goliath 6y ago

GNU extensions are all over the place. The C library has all kind of GNU functions that are more convenient/practical than what Unix had, the command line programs (e.g. coreutils) have feature flags and extensions that the originals didn't have but that made them more convenient to use, and I already mentioned GNU extensions in the tar format. POSIX aside, Unix-like systems that are still around nowadays and not directly use GNU user space, have copied many of the GNU extensions out of necessity. People have become accustomed to those extensions and written programs & scripts depending on them, so you now need to implement many of the GNU extensions simply to stay compatible. Even if not consciously done and without malicious intents, this is IMO still fairly similar to how Microsoft played it: add extensions that are convenient, so people use them, eventually rely on them and become a de facto standard.

vanviegen 6y ago
But as you say, Unix vendors could just implement these features. That's not how Microsoft would have employed its infamous tactic.
- pjmlp 6y ago
  I am yet to see Microsoft sue WINE for example. Any C compiler vendor (even commercial ones) does language extensions, mob => pushing the language forward. Microsoft does C compiler with language extensions, mob => get your pitchforks.
  - stinos 6y ago
    Similar for vendor lock-in. While very real, it wouldn't be the first time reading topics where the general sentiment is 'oh you poor Apple/MS/RedHat/Visual Studio/... user you're getting locked in, all hope lost' being written by people who don't recognize they are themselves following that principle merely by sticking to one particular OS/editor/debugger/...
pjmlp 6y ago
I used to be a Solaris fanboy (Linux was only the way I managed to have UNIX at home), and one of my regular tasks as Solaris admin was to install GNU from Solaris Packages repository due to software expectations.
throw0101a 6y ago
> GNU extensions are all over the place. On purpose and on accident: when Debian switched its /bin/sh from Bash to dash all sorts of things broke (for us) because GNUism were leaking into what should have been a standard language/feature set. We had to tell our users: change your code or change your shebang.
rualca 6y ago
> POSIX aside, Unix-like systems that are still around nowadays and not directly use GNU user space, have copied many of the GNU extensions out of necessity. That reads like a lack of interest to update POSIX to catch up with the de-facto sstandard I mean, I doubt that GNU would try to block the standardization process to avoid including their extensions.

blihp 6y ago

They pretty much did it with all of the utilities they produced... and I'm glad they did. I don't think it was nefarious, they just thought their extensions made sense at the time and/or filled gaping holes. Even in the early 90's it was painful to go from a machine with GNU stuff installed on it back to a vanilla System V system... they just felt so limited.

apotheon 6y ago

That's exactly what GNU did. GNU can take changes from software produced by others under copyfree licenses and wrap it in a copyleft license, then the projects from which it borrowed can't borrow-back the GNU changes because of license incompatibility that runs only one way. GNU licenses are very much embrace-extend-extinguish licenses.

vanviegen 6y ago
Perhaps the code itself couldn't be used by other vendors, but the ideas/protocols/interfaces could easily have been implemented by anybody who was so inclined. No trade secrets, no patents, and no dependencies on heaps of legacy cruft were necessary to be compatible. That's an important difference with "Embrace, extend, extinguish".
- apotheon 6y ago
  Ideas, protocols, and (except perhaps in the post-Oracle-Java world) interfaces can still be copied. A lot of open source software actually does exactly that with ideas, protocols, and interfaces from closed source software. What makes open source software "open source" is the source code, which is subject to copyright law. Ideas, protocols, and interfaces are not subject to copyright; only their expressions are subject to copyright. The Embrace, Extend, Extinguish approach makes things incompatible with the way others do them to cement hold on a large user base that prevents those users from changing their minds later. Sometimes that takes the form of forcing people to reimplement everything in a cleanroom setting, because they can never keep up that way; that's where the GPL excels within the open source world for EEE. Other times, it's by diverging from norms in ways that others cannot follow without breaking their own ecosystems, which is where the GNU project has excelled with its plethora of subtle incompatibilities.