Steve Jobs and Benny Hinn (rant)

Tue Feb 19 06:04:17 UTC 2008

On Feb 17, 2008 9:23 PM, Kip Warner <kip at thevertigo.com> wrote:
> As for the evidence, it's all over the place. Maybe mine is just out of
> date, but the last time I tried building GDB as one example under OS X
> (since the one that ships with XCode is old and doesn't come with
> gdbserver), there was no Darwin target. GDB is licensed under the GNU
> Public License, and since the XCode version is clearly GDB and is
> running under Darwin, it's obvious that mainline was not patched with
> their changes.

It is very difficult to get things into mainline on most projects
because the vetting process is quite intense, especially for critical
applications like GDB and the Linux kernel.  This is part of the
reason why Apple's changes are not in the GDB mainline.

The decision of whether to try pushing patches into mainline tends to
be a question of how much it's worth to a person or company.  If a
person or company doesn't want to worry about maintaining their
patches and they want to benefit from feature additions and bug fixes
to the project, then they will do their best to get their changes
mainlined.  However, if it is not important to the person or company
that their version of the code follows the mainline version, for
example if the mainline version doesn't tend to get a lot of feature
additions or bug fixes, then the person or company is more likely to
avoid the hassle of mainlining their code because it's not worth it.

The latter is what Apple chose to do with gas (the GNU Assembler).
They forked gas 1.38 [1], which was released January 4, 1991 [2], and
have not merged their changes back into gas since then (the latest
version of cctools [3] linked from the Apple open source page [4]
still uses gas 1.38).  This turned out to be a significant problem for
me when I tried to port GGNFS [5], which uses a lot of
highly-optimized assembly code, to my friend's Mac OS X machine.  The
assembly code contained several macros (such as ".rept") that are only
implemented on versions of gas newer than 1.38.  So I was somewhat
frustrated when I learned that Apple was stuck on gas 1.38 and had no
plans to upgrade (and it is nontrivial to patch OS X support onto a
new version of gas).  However, my situation is a bit of an edge case;
not many people port applications that use assembly code on a regular
basis.

It is understandable that Apple hasn't merged their changes as the
patch for adding Mac OS X support to gas [6] is almost as big as the
gas 1.38 source code itself [7] (936615 vs 1123106 bytes).  This is
because Apple's gas supports the Mach-O executable format, which is
much different from ELF, the executable format that most Linux
applications use.  Could Apple have submitted their patch to the gas
maintainers for mainlining?  Certainly.  Would it have been accepted?
Not without a lot of back and forth between Apple people and the gas
maintainers about things that need tweaking to match coding standards
and styles.  Is that worth it for Apple?  In their opinion, no.

Efforts have been made to add Mac OS X support to the latest version
of gas [8], but a working version has not surfaced as far as I know
due to the significant complexities involved in getting it to work,
which were likely a part of the reason Apple chose not to put a lot of
effort into mainlining it.

> This was not what Richard Stallman was thinking when he
> dedicated a significant amount of energy and personal time into sharing
> with us his work, along with everyone else who has contributed over the
> years.

Code is most nicely organized when it is always mainlined, but this
isn't always possible or practical.  Apple does try to merge their
changes into the respective mainlines [9] [10], but they can't merge
everything.  As a counter-example to the extreme case of mainline
deviation presented above with gas, Apple includes their version of
GCC 4.0.1 in the August 2006 Developer Tools.  GCC 4.0.1 was released
in July 2005, which makes Apple's version only a year old at the time
of its release.  When it is important to follow mainline (ie. when
people rely on a recent version of gcc), Apple can do a good job of
it.

An organization may choose not to mainline their code right away
because they want to get a product out the door.  For example, the One
Laptop Per Child project made significant patches to the Linux kernel.
 The version of the kernel they released to Give One Get One
recipients deviated from the mainline kernel by a 687830-byte diff
(between the 2.6.22-20071121.7.olpc.af3dd731d18bc39 OLPC kernel and
the 2.6.22 kernel.org kernel).  As of Feb 16, they had shrunk the diff
to 179234 bytes in their development branch [11] (with respect to the
2.6.25-rc1 kernel.org kernel).  So they are trying, but they still
don't have everything mainlined.  In fact, most projects will deviate
from mainline to some extent because there are always some patches
that they have just created but haven't made it past the mainline
screening yet.

As an example of why code might not be mainlined, consider a recent
patch sent to the GNU wdiff mailing list [12].  Being the maintainer
of wdiff, I have a responsibility to ensure that wdiff doesn't take on
too many features that are not central to the functionality (keeping
in line with parts of the Unix philosophy [13], such as "Make each
program do one thing well").  This is one of the main reasons I
rejected the patch, but is not the only one.  Other reasons include
making a patch on the incorrect version of the code and outputting
code that doesn't conform to HTML standards.

In conclusion, it is not always wise or important for everyone's
changes to be mainlined into a particular project.  While I do think
Apple could do more to mainline their changes (as shown by my
experiences with their version of gas), they are making an effort to
mainline when it is practical.

I'd be happy to answer any questions about mainlining code.  It is an
important part of the open source development model that interested
people should understand.

Denver

1. http://www.sourceware.org/ml/binutils/2005-02/msg00700.html
2. ftp://sourceware.org/pub/binutils/old-releases/
3. http://src.gnu-darwin.org/DarwinSourceArchive/apsl/cctools-622.3.tar.gz
4. http://www.opensource.apple.com/darwinsource/
5. http://www.math.ttu.edu/~cmonico/software/ggnfs/
6. http://membres.lycos.fr/schaffner/prog/binutils/gas-apple.ptch
7. ftp://sourceware.org/pub/binutils/old-releases/gas-1.38.1.tar.bz2
8. http://sourceware.org/ml/binutils/2004-04/msg00498.html
9. http://lists.apple.com/archives/darwin-development/2002/Jul/msg00239.html
10. http://sourceware.org/ml/gdb/2005-04/msg00102.html
11. http://dev.laptop.org/git?p=olpc-2.6;a=shortlog;h=master
12. http://lists.gnu.org/archive/html/wdiff-bugs/2008-01/msg00001.html
13. http://en.wikipedia.org/wiki/Unix_philosophy#Mike_Gancarz:_The_UNIX_Philosophy