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."
Adverse Affect For Me (Score:4, Interesting)
But it was my understanding that the idea behind open source was to roll your own if your machine was not covered. If I want to keep the Sparc chugging along, I guess I'd better learn to port it myself.
NetBSD? (Score:5, Interesting)
Standard operating procedure from Ulrich (Score:1, Interesting)
He's curt to the point of being rude, and I'm surprised anyone wants to develop on anything he's involved with. I wonder if the more social glibc developers like Roland agree with his position?
Sounds like a Microsoft-ism (Score:2, Interesting)
Come on. While this is an excuse for a proprietary for-profic product with a small team, I don't see this as flying as well in open source land. If some guy wants to port Firefox or OpenOffice to something off the wall like AROS or some other nearly unknown platform, let him. He wouldn't be working on the Windows or Linux ports regardless, so why prevent him from doing something so crazy with his own time and money?
Hypocritical (Score:5, Interesting)
And, of course, you write your code to be portable because you make sure it runs on the big three: Windows, Mac OSX, and Linux.
Right?
Actually, I think a much larger problem is just that: Many OSS developers don't even try to support Windows. Yes, I know you hate the OS and don't want to support Microsoft, etc., etc.. But, how can you complain about major software not supporting Linux when you're writing your own software that doesn't support Windows? Isn't that entirely hypocritical?
My take: Port your software to every platform you can, especially Windows. This gives freedom of OS to your users. And if you're a Linux user yourself, you should understand just how valuable and important this freedom is.
Re:Ummmm . . . (Score:3, Interesting)
I've watched the GCC list; David Edelsohn has consistently worked with the other people on the list. He takes the time to work out a solution to the AIX problems. OTOH, when Ulrich Drepper thinks something is broken on GNU/Linux, he will fight tooth and nail for the solution he thinks is right, as long as it doesn't mean that he has to clearly explain why his solution is right.
Re:I call bad c code (Score:5, Interesting)
It's sad that whenever you build some GNU sources or the latest Linux app du jour you get tons of warnings. Some projects even compile their files with 2>&1 >/dev/null. How sad is that?
It's not just the Linux folks. OpenSSL is actually worrying me:
etc. etc.
And this in a project that's driving quite an amount of sites, authentication mechanism and what not?
Most if not all of the sources that are native to NetBSD, i.e. not imported like OpenSSL and GCC compile without any warning. You automatically get a good feeling about using it.
Something needs to change in coding land.
</rant>
Re:Adverse Affect For Me (Score:3, Interesting)
For the same reason I tried Linux in 1996: interest in alternatives.
Re:Ummmm . . . (Score:2, Interesting)
Re:OpenOffice is a Gateway Drug... (Score:2, Interesting)
Re:The OpenBSD project doesn't seem to agree. (Score:2, Interesting)
Just sounds to me like someone's a little greedy, because it only hampers the main platform (if it even does that). But, in the process, it raises these other platforms. This gives more variety, choice, options... all really obvious things.
Re:OpenOffice is a Gateway Drug... (Score:1, Interesting)
When my wife told that her company's thrift store could set me up with a PII 300 Mhz for $20, my eyes lit up, because by then I knew that OSS had an OS up to the job of making that old clunker the same usefool tool it was when it was put together. After actually getting my Bittorrent/FTP server running (and skirting a nasty argument with the wife about P2P on her/our machine), I know there's no way I'm going to get another machine that puts money into Micros**t's hands.
If keeping Xine or XMMS running on Win32 slows them down, screw it! Media Player Classic has saved me the evils of Real Player and WMP, and confirmed for me with personal experience what everyone says about OSS. I don't need to be enticed with keeping it when I run my real OS on a real computer, the point's been made. As far as Windows (not Cygwin or Mingw, I'm not throwing my ignorance around in that debate) is concerned, you can say the port should be its own project, and there's a lot we won't be left out on.
Re:Both sides are right, I think. (Score:3, Interesting)
If you slow down development to cover a broader set of platforms then you will be late with the latest new buzzword features (hyperthreaded keyboard support!). On the other hand, who gets to decide what counts as a minor platform? Do you decide based on age? (sorry, Amiga is too old) or based on number of units? (sorry, not enough IBM mainframes out there) or just interest level of the developers? Anything that you abandon is going to cause big problems to someone.
Re:Sure. (Score:4, Interesting)
primetest.cpp [dyndns.org]
primetest.java [dyndns.org]
primetest.pl [dyndns.org] (for fun, because I like perl)
Using Java Blackdown-1.4.2-01, gcc 3.3.5-20050130 and perl 5.8.5 on a 1.3 Ghz Pentium-M, I get these results:
neil@t40-n Documents $ javac primetest.java
neil@t40-n Documents $ time java primetest
real 0m7.809s ./primetest
user 0m7.700s
sys 0m0.033s
neil@t40-n Documents $ g++ primetest.cpp -o primetest
neil@t40-n Documents $ time
real 0m2.699s ./primetest.pl
user 0m2.676s
sys 0m0.007s
neil@t40-n Documents $ time
real 0m47.928s
user 0m46.207s
sys 0m0.138s
neil@t40-n Documents $
How about you? Sure it's a trivial benchmark, but it definitely shows Java way behind (by a factor of three!) C++ for number crunching. Of course we see Perl well behind both, but it's definitely not meant for number crunching, so no surprise really.
Re:The platform comes... (Score:4, Interesting)
I've actually done some fairly hefty optimizations (real-time array processing on an original Sparcstation, for a nuclear research facility) and know the sort of problem you are talking about. The best thing to do, once you have a working, solid, implementation is profile it and find the areas that - if accelerated - would offer the best improvement in performance.
The problem with having so little time - in your case a month - is that you can't optimize cleanly. You've got to hit the code in the best places first and dig your way through as far as you can in the time.
Typically, slow areas will involve moving lots of data, number-crunching and I/O. You can't do much with graphics I/O, unless you've some good specs on the hardware and know assembly. (That's one reason I learned assembly.) Number-crunching is tough, too - just do as little as possible, do what you can when the system is idling, try to merge operations, and stick to integer arithmetic as it is so much faster. Moving data is easy - don't, unless it'll absolutely kill you. Do everything in-situ, if you can. (I wrote a Mandelbrot generator that did ALL arithmetic inside the 80x87 coprocessor - nothing loaded, nothing saved, which meant no slow transfers. It was still slower than fractint, but it was a lot faster than any other floating-point fractal generator out there.)
Re:Portable code is robust code (Score:3, Interesting)
I have seen this phenomenon but it certainly doesn't have to be that way. One of the best kept secrets of having both cleanliness and portability is to eliminate #ifdefs from sources as far as possible. The obvious ideal is to have identical source and abstract platform differences by other means (e.g. macros instead of #ifdefs, and using identical APIs on different platforms, supplying only platform dependent implementations).
Keeping it clean probably also requires occasional refactoring and I guess some projects shun this as a matter of policy. The projects I would cite that achieve a high level of portability typically have no machine dependent code at all (TeX, for example). Not all code has that luxury but it's not as difficult as many people think - apparently including our friend Drepper.
Re:Logic Circuits Concur with OpenBSD's Findings (Score:1, Interesting)
I learned most of what I knew about POSIX from GNU manpages... Then when I first tried to code for OpenBSD, Solaris, Irix, what have you, I was in for quite a few shocks.
I've learned a lot about writing portable Unix software since then. Still, porting between Unices throws lots of curveballs, especially if your development platform is Linux. Linuxisms (or glibcisms) are a trap all too easy to fall into. It's much easier to make something portable when you're not using glibc.
Not true for some projects (Score:4, Interesting)
However, there is a non minor and weird platform which actually does generate a lot of trafic on the list, and is strange for most developers. Anyoen checking The GIMP bugizlla will find a lot of open bugs for Microsoft Windows Plataform. That however, doesn't slow the project either. It simply goes on, and the developers who work on Compiling and making the windows installer do what they can for the work arounds.
Re:He is wrong on all counts. (Score:3, Interesting)
I think before criticizing maintainers for other platforms where GCC is ported, he should look at how much special work his own project causes for GCC and see if he can do his own contributions to making GCC development easier by simplifying the glibc headers.
Marcel
Re:Straw man (Score:5, Interesting)
With a project as big and important as GCC, you'd think they'd have a server for each platform set up for all their developers to play with. Gentoo has Sparc, MIPS, PPC, etc. boxes for their developers to use for porting software.
It seems to me that a smart idea would be to have some kind of system where a developer could submit a patch, which would then be sent out to a server farm, where each server would try to compile GCC with the patch, then run a test suite. Doesn't Mozilla do something like this nightly?
"I don't have access to a [foo] box" should never be a valid excuse with larger projects.
Re:Java? (Score:3, Interesting)
I suspect that we have not yet seen the VM architecture in its full maturity.
Re:Porting assures portability, clean code, future (Score:3, Interesting)
I can easilly port between Linux and *BSD but the problem comes when users ask me to port my code to non Posix OS or claim to be Posix but really aren't Posix(win32). Or my latest peeve: sort of Posix but non ELF non GNU (OS X).
Re:Adverse Affect For Me (Score:1, Interesting)
Another good reason is that SPARC boxes laugh (ok, laugh isnt't quite the right word but you know what i mean) at the x86 virus/trojan binaries that script kiddies promulgate.
The x86 architecture is far from optimal. Motorola was right when they used the marketing phrase "A break with the past" when they brought out the 68000 series. But, the industry (end users?) wanted backward compatibility and so we're stuck with relic software (bugs and all).
Re:Apple (Score:3, Interesting)
it has a lot of ugly nextstep-isms though, including the heavy leanings toward objc and bundles.
and for a long time osx was missing even basic freebsd mechanisms like dlopen() (yes, i know someone wrote a wrapper, but it took a long time for apple to appropriate it as an official api).
No, Ulrich has a point (Score:4, Interesting)
People seem to be repeating a lot of "folk wisdom" about portability. Oh it's just bugs. Make your damn software clean you damn coder. Etc.
I can guarantee you that anybody who says this has never actually read the sources to glibc, binutils or gcc. Hell, they probably never even read the mailing lists! I have, and when Ulrich says an enormous amount of effort goes on supporting minority platforms he is totally correct. Hello, binutils isn't the GIMP people! Other platforms have totally different architectures and often need huge amounts of platform specific code from these projects. This isn't a case of sloppy coding, it's a case of massive amounts of work being done to support edge cases. Go read the sources to bfd sometimes. Adding support for one platform that uses different assumptions about basic things like memory layout can require huge reworkings of the code.
Essentially there are a lot of people spouting off here based on their experiences of compiling FooApp on FreeBSD or whatever. Have you written a C library? A threading library? No ... then you are probably not really qualified to judge how much work this generates for Ulrich.
Oh, and for the guy later on in this thread who says "AIX is not a minority platform, WTF?" - I say to him WTF. AIX most definitely is a minority platform. Maybe not in the world he lives in, but in the real world Windows is dominant, sometimes people think about Linux/Mac or even FreeBSD and everything else barely registers at all unless you administer high end servers or work on embedded software (most people do not).
I've been bitten by this mentality before. Back when exec-shield was first developed, it broke Wine (which I work on). So I set out developing a fix. Eventually, I wrote a GNU linker script that arranged virtual memory such that things would work correctly even when exec-shield was active. But it didn't work, because of a simple bug in the kernel. No problem, right? Just fix the bug, right? Well, actually, somebody did. A patch was written, submitted, got into Andrew Mortons tree ... and it didn't compile on Itanium. The original author didn't have access to such a machine, neither did I, and the person who reported the failure (who worked for Intel, IIRC) was overloaded with other work and couldn't fix it. So the patch was dropped.
In the end, a few months later, we had a different solution that was about a million times more complicated. Largely because a simple bugfix patch didn't compile for unspecified reasons on a platform nobody uses and this was grounds for it to be dropped. That mentality of "all computers are born equal" is why Debian has become a laughing stock and it cuts both ways.
Re:Adverse Affect For Me (Score:3, Interesting)
Was it ever, at least 6809 - m68k was understandable by mere mortals and had a certain elegance. x86, ( hell even the 4004-8080) has always seemed kludgey, inelegant and incomprehensable.