Porting Open Source to Minor Platforms is Harmful

Tamerlan writes "Ulrich Drepper posted a blog entry titled "Dictatorship of Minorities". He argues that open source projects' attempts to support non-mainstream (read "non-Linux") operating systems slow down development and testing. While Ulrich may be biased (he is a RedHat employee) he has the point: if you ever read mailing list of any large open source project, you know that significant piece of traffic is about platform-specific bugs or a new release broken on some exotic platform."

Comments

Re:He is wrong on all counts.

[bani]

just FYI. mingw doesn't deal with api differences at all. mingw is just a gcc port which can emit win32 PE binaries. a good deal of mingw effort is spent writing free versions of win32 dlls to link against. but they don't abstract or translate APIs -- they're just free implementations of the win32 SDK.

cygwin does deal with api differences however. it's a completely different beast.

Debian's more about leadership attitudes, I think

[jesterzog]

But having a requirement that something work on a large number of platforms slows down the release cycle.

I'm not sure that I agree. To me, the Debain delays seems to be at least as much a political and leadership thing. In particular, consider how quickly Debian went into a freeze for a new release after a change in leadership. Granted that it's a week behind schedule, but the green line is now going down rapidly, and we're expecting a new release within a matter of days. If it was so difficult to support and release on multiple architectures, this likely wouldn't have been able to happen.

I'm not trying to imply that the old Debian leadership was necessarily bad or that the new leadership is particularly good. But a change in attitudes very quickly resulted in a new release. This suggests that support on lots of architectures has little to do with it, whereas leadership attitudes has a lot to do with it.

We'll have to wait and see just how reliable Debian Sarge turns out to be when it's promoted to stable, of course. (Disclaimer: I run debian sarge on my home workstation and laptop.)

Axe to grind

[Dan Berlin]

As a GCC developer (bias: I work for IBM Research), the only time i've ever seen David Edelsohn complain about something not working on AIX, it was broken on other significant platforms as well (Cygwin, etc), or was latently buggy and just working by luck.

Judge for yourself. Go read the gcc list. Count the number of patches backed out in the past year because they broke AIX vs because they broke some other platform.

It sounds like an unnecessary personal snipe, which, for people who know Uli, well, i won't bother finishing that.

So if this is the most "notorious case" Ulrich's got, then he's wrong.

Particularly the "GCC would be developed much faster".
That is in fact, the funniest thing i've heard all day.

GCC would be developed faster if there was less sniping and fiefdom's and more collaboration. Which, except for a few people, has been what is generally happening. Our development process is accelerating, not slowing down.

And It certainly isn't slowed down because people need to bootstrap on AIX, which they don't.

Nobody has ever required patches be bootstrapped on AIX unless it is very likely to have some material affect on that platform.

This is just the same requirement we pose for any wide ranging change: Test it by compiling it for the architectures it is likely to break on.

Note i didn't say running. We don't require anyone have AIX boxen around. Cross compiles work fine.

Though if you break some architecture, you are expected to at least try to help the maintainer of that arch fix it.

Logic Circuits Concur with OpenBSD's Findings

[jd]

Sorry, had to do a Blake's 7 Zen impersonation there. Seriously, a well-designed program for Linux should run just as well under any *BSD, or any Unix platform, with little or no modification. POSIX is POSIX, no matter what the label on the box, after all.

(The only exceptions would be things that use specific Linuxisms, such as some of the Netfilter calls, anything to do with a filesystem that is only available on Linux - XFS, JFS, Lustre for example. The network structures use different variable names, but that's not an excuse as you should be using an abstraction library in those cases.)

The title of this article is not correct.

[Nailer]

Wait a sec...

Porting Open Source to Minor Platforms is Harmful

What the fuck? Where'd you get that from? Read Ulrichs post. How about:

Delaying the development of features because of problems with minority platforms that can't be fixed by the bug reporters is Harmful

You may disagree, but unlike the title of this article, it does actually cover what Ulrich is talking about.

Re:Try a VM

[AndyL]

A quick glance at a changelog for a Java project, such as Azureus ,shows all sorts of "compatability fixes". Not just for compatability across diferent OSes, but also for compatability across diferent versions of the VM that's supposed to solve everyone's problems.

Re:Sure.

[Mad Merlin]

Here are some more results, everything is the same unless otherwise specified: Using 10,000,000 instead of 1,000,000:

neil@t40-n Documents $ time java primetest

real 2m41.851s
user 2m41.439s
sys 0m0.144s
neil@t40-n Documents $ time ./primetest

real 0m59.801s
user 0m59.618s
sys 0m0.056s

Using -O3 for gcc with 10,000,000 instead of 1,000,000:

neil@t40-n Documents $ time ./primetest

real 0m54.883s
user 0m54.755s
sys 0m0.047s

Using int instead of long with Java and 10,000,000:

neil@t40-n Documents $ time java primetest

real 1m6.386s
user 1m5.930s
sys 0m0.128s

Ah hah, well that would explain it. I guess you do learn something new every day. Certainly a far cry from the ~3x difference initially observed.

I didn't bother repeating the perl test with 10,000,000 however...

Re:Debian's more about leadership attitudes, I thi

[Trax]

Everytime somebody likes to say that about Debian, I like to remind them the NetBSD folks support an ... impressive array of platforms, and at the same time hack userland, kernel and protocols. While Debian developers mostly package upstream stuff.

I would have to say that Debian developers, for the most part, are also involved in the userland, kernel, and protocols. Take a look at developers such as Colin Watson, Joey Hess, Branden Robinson, Ben Collins, and others are doing in and around the Free Software community. Debian developers should not be pigeonholed as being upstream packagers just because that's what the public sees as the end product.

P.S. Do a web search on those developers to see their current and past involvements.

Re:/. subtitle not well chosen

[synthespian]

glibc is one of the main reasons why Linux application deployment sucks in major (read: heterogenous) installations.

This is what Marc Espie, an OpenBSD developer said about Ulrich on O'Reilly's OnLamp (commenting the proactive measures OpenBSD takes in C programming vs. Ulrich's "Linux programmers are geniuses" view):

"We have had a lot of success explaining the issues and getting a lot of people to switch from strcpy/strcat to strlcpy/strlcat.

Weirdly enough, the Linux people are about the only major group of people that has constantly stayed deaf to these arguments. The chief opponent to strlcpy in glibc is most certainly Ulrich Drepper, who argues that good programmers don't need strlcpy, since they don't make mistakes while copying strings. This is a very mystifying point of view, since bugtraq daily proves that a lot of Linux and free software programmers are not that bright, and need all the help they can get.

(Considering the shining, flaming personality of Drepper, and the fact that he is always Right, this is not that surprising, though)."