Porting Open Source to Minor Platforms is Harmful 709
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."
Re:Question (Score:2, Informative)
Regards,
Steve
Re:Try a VM (Score:3, Informative)
A VM is just another architechture. In theory we could just write everything for x86 and then run emulators on every other platform, and it would be about the same thing.
The problem is that Java works great as long as you only run it on an x86, or maybe a sparc or a mac. And java apps have their downsides as well.
Re:He is wrong on all counts. (Score:4, Informative)
cygwin does deal with api differences however. it's a completely different beast.
Debian's more about leadership attitudes, I think (Score:4, Informative)
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 [debian.org], 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 (Score:5, Informative)
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 (Score:4, Informative)
(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.)
GCJ isn't yet ready for prime time (Score:2, Informative)
Classpath, the runtime library used by applications compiled with GCJ, isn't nearly as complete as some of us would like. Or have you managed to get, say, Azureus working usably in GCJ?
The title of this article is not correct. (Score:5, Informative)
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:Logic Circuits Concur with OpenBSD's Findings (Score:3, Informative)
You do realize that XFS is a port from SGI's UNIX varient (IRIX I believe). That JFS is ported from OS/2 to Linux (and was originally written for AIX and the s390 Mainframe if I recall the details correctly).
Lustre might be Linux only. I believe it started out life as a Linux-only project. I believe that ReiserFS is fairly Linux only (I thought they had ports to other OS's, but I can't find anything on there website about it the last time I looked). GFS to the best of my knowledge is a Linux only filesystem. Ext2/3 is primarily a Linux thing (I believe several other *BSD's have the ability to mount them, and a few odd Win32 drivers). Not sure about the other oddities (JFFS,CramFS,RomFS,SquashFS).
Kirby
Re:Try a VM (Score:4, Informative)
Re:Adverse Affect For Me (Score:3, Informative)
Re:Adverse Affect For Me (Score:3, Informative)
32 Bit vs. 64 Bit (Score:2, Informative)
Java long => 64 Bit
So you are comparing Apples with Melons
Re:Sure. (Score:4, Informative)
neil@t40-n Documents $ time java primetest
real 2m41.851s ./primetest
user 2m41.439s
sys 0m0.144s
neil@t40-n Documents $ time
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...
WIndows, Symbian and other minor platforms (Score:3, Informative)
And I can't switch to Linux - all my projects for Windows and Symbian (and Nokia SDK windows-only, homegrown windows port require Wine anyway). And all the times I'm telling my clients and coworkers - look how much OO mre convinient then word, how Firebird is more safe, and Gimp have nice features, and Axiom and Maxima - well, you dont have to pay several thousand $/year for Mathematic. To drop support for "minor" platform would be a huge discouragement for people to use OSS. Don't forget that some OSS project are designed for mostly non-Linux platforms. Vincent OpenGL ES implementation is oriented for PPC/Symbian and don't have much sense for desktop Linux.
Re:Debian's more about leadership attitudes, I thi (Score:3, Informative)
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:32 Bit vs. 64 Bit (Score:3, Informative)
Java long => 64 Bit
So you are comparing Apples with Melons
Using my mighty +1 Karma Bonus Power...
Can somebody please mod the parent up?? The grandparent poster is apparently too clueless to create Java vs. C++ benchmarks.
Java primitives:
http://java.sun.com/docs/books/tutorial/java/nuts
C primitives:
http://www.phim.unibe.ch/comp_doc/c_manual/C/CONC
Let's see the benchmark with either int vs. long or long vs., er, long long (or __int64 or whatever).
And then, can't we all just get along?
Re:Sure. (Score:3, Informative)
Re:/. subtitle not well chosen (Score:3, Informative)
Re:Debian's more about leadership attitudes, I thi (Score:2, Informative)
All said dude, this discussion has actually presented quite an interesting contrast of opinion - heh, as so many do I guess ...
Yep. That's exactly why you have added this righteous paragraph about superiority of one platform over another. Insecurity? Zealotry? You name it. ;-)
Quite correct. To be perfectly honest, I was actually trying my best here not to prompt the 'zealot' label. Not saying you did call me a zealot directly, but I didn't call you a 'fanboy' either.
Installing software from ports tree is a breeze (when it is not broken, mkay). Supporting it in the long run is somewhat less of a breeze. Maintaing it so contents of /usr/local won't become a complete mess takes a lot of effort.
Especially when you are supporting not exactly that one server in your parent's basement.
Here, though, I don't much agree. I use *BSD servers for all my customers - never had a single call out in 4 years mind you - and to keep systems' ports updated is nothing harder than a couple of (well, literally 2) expect scripts with some SSH smarts. Using cron to trigger at 1800 on the last Friday of each month, said expect scripts are executed from my office machine (ie: don't need to track changes to update scripts on each of my prod servers). All this leaves me to enjoy my weekends. None of my intervention is necessary. What I think you might not know about here is that most of this is already scripted for me. 'portupgrade' (located in /usr/ports/sysutils/portupgrade ;-)) is a collection of ruby scripts that is a level above 'make install', 'make deinstall', 'make reinstall', etc. The software does all the upgrade management for you. I mention this (in a long digression) because I'm not too sure if you're familiar with these specific tools. It has kept all of my 4 years worth of clients' servers with up to date software, using upgrade procedures I don't even think about or have needed to modify radically in years. Not to say this couldn't be done with apt, (yam, rpm, etc.) but I do say it is certainly possible with ports. And that I am not just scoffing away the latest upgrades in my parents' basement!
Of course, we're adults and it's all up to you. It's been nice talkin' champ.
Your friend,
Raj
Re:Java? (Score:3, Informative)
Re:/. subtitle not well chosen (Score:5, Informative)
This is what Marc Espie, an OpenBSD developer said about Ulrich on O'Reilly's OnLamp [onlamp.com] (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)."
Big big BIG ditto (Score:3, Informative)
All of what dvdeug says here is true. I've done more than watch the list, I'm a maintainer, and David Edelsohn (an IBM employee) has always been willing to work with the GCC community. He even pushes the IBM developers and management to make each release of AIX slightly less bizzare than the previous release. Ulrich simply insults you if you disagree with him. He does not participate on the GCC lists; when he does send a message, it's a flame. I've never seen an explanatory email from him, on any topic.