Slashdot Mirror
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."
I don't think they are talking about mac. Hell, this next release of Fedora on June 6th will be the first to support the Mac (most importanty the mac mini). I think this is referring to things like why should Suse or Fedora run on Arm processors? If these distros were targeting them specifically it'd be different, but Fedora and Suse target mainly X86 and X86_64 as far as I know. Why make programmers focus attention on platforms that will rarely be used? I myself am a programmer and find that after the top 3 or 4 platforms being targeted, your efforts on other platforms start to get stretched to the point of diminishing returns. It eventually cuts into you're regular work and I think it really does affect code quality. I look at it kind of like code optimization, 10% of a program in many cases will be used 90% of the time, and supporting platforms with little use or popularity usually wind up using up a large percentage of your time in testing and debugging. Please note that I'm not saying platform diversity is bad, it is indeed a good thing and very important and that is why its nice that some open source projects such as NetBSD target every platform under the sun. For best code quality though, its *usually* best to stick to as few platforms as possible. (Note: NetBSD does a surprisingly good job of keeping acceptable code quality while retaining support for many platforms)
Regards,
Steve
Clearly you aren't running on amd64. I've given up on running just about anything other than helloworld.java on this platform, using any JDK I can get my hand on (both Blackdown and Sun, stable and beta versions).
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.
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.
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.)
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.
(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.)
It's a small world and it smells funny; I'd buy another if it wasn't for the money; Take back what I paid (SoM)
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?
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.
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.
Incorrect. If you use the pre-september release (s10_44), then both the Ultra 1 CPU and the Lance chip are supported.
Very much incorrect. If you use the pre-september release (s10_44), then both the Ultra 1 CPU and the Lance chip are supported.
C++ long => 32 Bit
;)
Java long => 64 Bit
So you are comparing Apples with Melons
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...
Game! - Where the stick is mightier than the sword!
I strongly disagree here too. I use a lot of open source programs , but I'm working with Windows and Symbian. OO, Gimp, Axiom, Maxima, gcc (major component of Symbian SDK), Firefox/Thundedbird/Sunbird etc.
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.
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.
- you didn't seem to compile the c++ code with optimizations. i suggest compiling with -O2.
- for the kind of code you chose, you used a bad provider for java. i suggest the IBM 1.4.2, which is flat out the fastest x86 VM on the kind of code you provided.
- you didn't use the VM version for the java you chose. if you are going to run a sun-based VM, then, for the kind of number-crunching code you provided, you should use the "-server" option. the hotspot-based JIT is optimized for a different kind of code (UI, interactive)
on a 1.6GHz pentium-m running linux, i get:- c++: 2 seconds
- IBM 1.4.2 java: 2.4 seconds
- sun 1.5.0 -server java: 4.8 seconds
- sun 1.5.0 -client java: 7.7 seconds
(times are best of 4 consecutive runs using, as you did the "time" command) nickthe movement from glibc2.2 to 2.3 was particularly painful. ugh.
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
- 32-bit Windows
- 64-bit Windows (as a RC)
- 32-bit Linux x86
- 64-bit Linux x86
- 32-bit Solaris x86
- 32-bit Solaris SPARC
- 64-bit Solaris x86
- 64-bit Solaris SPARC
- 32-bit AIX POWER
- 64-bit AIX POWER
- 31-bit z/OS
- 64-bit z/OS
- 32-bit i5/OS POWER
- 64-bit i5/OS POWER
- IRIX
- OpenVMS Alpha
- OpenVMS IA64
- Tru64
- HP-UX PA-RISC
- HP-UX IA64
Is that enough platforms for you? No, it doesn't cover everything, but there certainly are a lot there.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)."
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
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.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)