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."
Of course it is... And by that logic, developing software at all is harmful - takes time, money, and all the same stuff it takes to port it.
http://imcommunity.net/cgi-bin/u.cgi?u=38
Are they referring to Mac OS here ? I highly value the open source ports made to Mac OS X, such as firefox.
Furthermore, at least on OSX, the Fink project makes many programs OS X buildable, but puts the maintenance onus mostly on the Fink people, not the original authors. Of course this can have it's own problems.
I'm a fan of Debian, but I think that Debians effort to support the myriad of architectures out there is hurting it.
It does a great service to the rest of the Linux community though, because it helps keep things portable.
But having a requirement that something work on a large number of platforms slows down the release cycle.
The Internet is full. Go Away!!!
There are many instances where OpenBSD developers indicated that a bug found in one port led to discovery of problems that affected several other platforms. It seems in this case that multiplatform support is beneficial, and the larger the number of platforms, the greater the likelihood that such bugs will be found and fixed.
Software developers should only develop for Windows, because supporting Linux/Mac/BSD is diverting resources away from the (vast) majority of users.
PS: These graphic word things are nearly unreadable!
I'm not sure I totally agree with this article - at least as far as Windows porting is concerned. Programs like OOo are gaining acceptance in the Windows world and that foothold has led my own organization to 'embrace and extend' that success. For instance, for the first time we will be purchasing Apples - running NeoOffice of course - and we already have a few Linux terminals here for public use.
I like to think of OSS/GPL stuff as a 'gateway drug' - to use an analogy. Using it may not automatically make people go to Linux, but it certainly makes it an increasing possibility.
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
First off, everyone will complain about this. The thinking goes that Open Source == Freedom, so the more choice in platforms you have, the more Freedom you have and thusly you actually help Open Source more.
I think this is incorrect.
First off, Open Source, despite its close engagement with Freedom ought to also stand for what is best in the Software Engineering world. This means clean, lightweight, portable code. For better or worse there is a standard which is POSIX. Linux, to the extent that it uses the GNU system, is basically POSIX-compliant. Open Source projects ought to target POSIX and keep themselves free of proprietary entanglements.
This can be achieved by focusing efforts on programming for Linux, the premier Open Source operating system. Only by keeping the code clean can a project be easily ported, but a project that isn't even near completion ought not be ported at all. Such non-mainline work results in incompatibilities and divergences from the main trunk of code that cannot be easily fixed down the road.
A very good example is the Symbian/Nokia gcc compiler which has many special extensions and cannot be used to compile for any other targets or operating systems. Well, they are doing away with their special version of the compiler and finally going back to the main line gcc tree. Unfortunately, all that work to specialize gcc for their platform is tossed out the window now. Work to no avail, essentially.
The key here is not to focus on Linux, specifically. Rather, it is to focus on a standard and program to that. That Linux is one of the best of the standard bearers, it makes sense to complete programming there first rather than start porting to esoteric platforms right away.
A proper engineered solution to this problem was developed some time ago: a VM.
There are 1000s of Java projects on SourceForge that will never have this problem.
Overall the arguement is mostly bogus. For example many linux developers have trouble writing code that even compiles under any of the *bsds. That is just sloppy coding. If everyone got in the habbit of at least writing code that doesn't use system specific includes (linux developers seem the worst at this) and compiled with gcc -strict -Wall or something similar it wouldn't be much of any issue. While I can see that a request to make something work on OpenBSD VAX might be better ignored I fail to see how supporting at the very least linux/*bsd (Open, Net, Free) on ppc, sparc, sparc64, and x86 is supporting a minority. Overall OSS users/developers ARE a minority and to argue over which minority beats who is silly. Also, to only bother to support linux is no better than only bothering to support windows!
:(){
Porting Open Source to Minor Platforms is Harmful
I would say that an article about someone's blog entry on the front page is harmful.
"For Great Justice."
The bugs due to platform bugs -- well, knowing about them helps improve the platform.
If you think fixing these bugs is a pain in the neck, fine. If you think it's a waste of time, however, think again.
Am I part of the core demographic for Swedish Fish?
Let's all get things done a hundred times slower!
Progress!
Keeping your code portable helps eliminate stupid assumptions, which make your software useless when the dominant platform changes. Once, all the world was a VAX, and people did stupid things. Then, the world changed. They kept doing stupid things.
Think, for example, about 64 bit cleanliness. A piece of software which supported Alpha, UltraSPARC64 and SGI's MIPS64, and so on, wouold have been fairly trivial to port to IA64, and AMD64, and PPC64 when they started to become significant. OTOH, code which assumed it was running on a 386 would have been a pain in the ass to port to even just AMD64.
Also, by supporting a broad spectrum of compilers, you will probably be able to understand what is going wrong when you compiler of choice changes. Witness code breakage on gcc3. Devs who had already ported their software to a variety of compilers were better able to respond to any issues, and fix their code.
Many monoculturalists make stupid endian-ness assumptions. Now, Mac OS X is becoming a significant market. If you have stupid endian-ness assumptions, then you may wind up having to basically rewrite in order to gain access to those millions of potential customers/users.
Imagine if OpenGL only supported SGI and 386. Or libtiff only worked on i386. People just wouldn't use them. Things like that get used because they are ubiquitous, and you can build them anywhere.
Of course, you can overdo it. Take a look at InfoZip for example. No, seriously, take a look at it. It works on every platform you can think of, but the price is that the code is almost unreadable. The biggest problem is all the cruft needed to maintain 16-bit compatibility. It desperately needs updating to handle non-ASCII filenames intelligently, but the last thing that code needs is another layer of #ifdef's.
There comes a time when you just have to say "fuck the Amiga".
fish and pipes
Sometimes, we use hyperbole to make a point.
Unfortunately, I don't think that Ulrich is doing that.
AIX is not a minority platform. What The Fuck. Okay, so the AIX guys are asshats in the way they treat GCC, fine. But GCC's claim to fame is that it it is the cross compiling, multiplatform compiler du jour. I think Ulrich loses a lot of credibility to say that GCC needs to not support AIX because it's a minority platform.
*nix applications which run primarily in userspace should port to the various BSD's and Linux easily, and if they don't then 99% of the time it's a bug. And in many cases, it's a bug that will affect the working platforms eventually (relying on nonstandard behavior of system calls, linker oddities, assumptions about file placement, etc). And if a closed Unix platform has paid developers to assist in the porting, then it should run on that platform too. And if the paid devs are dickbrains, then a good project leader should say so. Behave, or fork and get your whining ass out of my tree.
These AIX GCC guys shouldn't be saying "This patch breaks AIX, kill it", they should be saying "This patch fixes *blank* on AIX", at least most of the time.
Porting reveals bugs. It also forces you to rethink short-sighted decisions. Furthermore, most of the problems I run into with porting have to do with cross-version incompatibility on Linux - the BSDs actually have comparitively stable APIs.
This line of thinking is a lot like how I presume Microsoft thinks of things: if we just port to this one API, it doesn't matter how bletcherous it is. But as Microsoft has discovered, this kind of thinking actually turns into a straitjacket, which prevents them from being responsive when they need to be.
"IMO the most notorious case is how the gcc development is held hostage by Edelsohn and maybe IBM as a whole by requesting that everything always works perfectly well on AIX. How often has one seen "this patch breaks AIX, back it out". It cannot reasonably be expected that everybody tests on AIX. It is an proprietary OS running on proprietary and expensive hardware which not many people have access to. The overall development speed could be significantly improved by dropping the AIX requirement which, in some form or another, has been agreed upon by the steering committee. AIX is irrelevant in general today, i.e., the situation changed. And the people in the steering committee are too nice to just tell the very small minority causing the problem to take a hike."
GCC is the de facto standard because it runs on more platforms than anybody else.
If it ceases to run on all these platforms, it will either:
a) fork a project that will support them
b) another compiler will take its place as the de facto standard
c) people will be forced to use whatever the default cc is on their OS.
In any of these cases, the portability concerns will get an order of magnitude worse.
I rarely criticize things I don't care about.
Porting to other platforms/architectures often reveals bugs in your primary target platform. it is often worth the effort to port to other platforms on this basis alone.
also, if it takes you a lot of effort to keep architecture-nimble, there is something fundamentally wrong with your design. this in itself should be a warning.
But there is no benefit at all in supporting something like PA Risc, m68k, cris, etc as configurations of the generic code.
ulrich obviously has no clue whatsoever about embedded systems, and should therefore stfu on this point. one of the most popular embedded platforms is a 68k variant (coldfire) -- it's probably second behind ARM. by dumping support of 68k you castrate linux in the embedded marketplace. there's much more to 68k linux than sun3 and atari/amiga.
his rant against mingw as "undeserving" is stupid. mingw is an enabler -- it means people can develop for win32 without having to pay microsoft $$$$ for the privilege of doing so.
his 'dictatorship of the minorities' argument is actually self-defeating on this point because microsoft users are in the majority. by his own arguments, we should be concentrating on supporting win32 as the primary target for gcc and primary architecture for linux.
utterly ridiculous.
bug-eyed rants like his just serve to reinforce the stereotype that all open source advocates are completely unhinged. it is not helpful in the least.
There are bugs that just don't get flushed out until you port to: non-x86; 64-bit; bigendian; Win32; OS X; etc, etc, etc. Drepper should know better: All the world's not a VAX, etc. (though a VAX port is a fine start :-)
Also, every port makes the process of porting itself easier. It's no coincidence that the most reliable and defect-free software is typically the most-ported software. This has always been true: TeX and METAFONT (where the monetary bug bounty doubled for every bug report, so assured was Knuth of its quality); Apache; Linux itself; NetBSD; GCC and friends; etc.
you had me at #!
The bugs one finds on "minor" platforms usually end up being bugs on the "major" platforms you just haven't found before. Of course, for those of you still intent on/forced to write code in C/C++, you're likely getting your just desserts.
007: "Who are you?"
Pussy: "My name is Pussy Galore."
007: "I must be dreaming..."
It is rare that I can say someone is wrong on all counts, but I have not found one defensible statement in there. (Though I guess one could be hidden and I missed it)
His first mistake is thinking GNU is everything. Maybe for him it is, but for most people we use what works. When the boss sets me down on a AIX machine I want it to work - I'm not allowed to install Linux (though I'd install *BSD if I could wipe the OS), I'm supposed to get work done.
Minorities are useful despite the cost of working with them. Bugs that are 1 in a million may happen every time on AIX. 1 in a million bugs are very hard to find. I've spends days looking at a partial crash trace wondering why it broke, and if it will happen again. With no known way to duplicate the bug it is really had to fix, and hard to be sure the 'fix' works. When it fails every time the bug is easy to fix.
Good programmers should have no problem writing cross platform code. When your code breaks on AIX, it is a sign of bad code - even if the breakage is because AIX doesn't have a function you expect.
Cross platform compilers (gcc) are much easier for me to work with. Because gcc is cross platform I can compile my stuff at home and debug it, than bring it to work and compile it and assume it works. Particularly with gcc 2.95, the support for C++ was so bad that you could not count on code written for that to work on a better compiler.
Speaking of gcc 2.95, other vendors have had better compilers for years, while gcc is only arriving. Even today, gcc isn't a great c++ compiler. (though 4.x is much better) There is no point in throwing stones at other vendors - their compilers may have been expensive, but they at least worked close to right.
The upper/lower case differences with Windows are a non-factor. You should never have any word that differs by case only - it leads to many bugs if you do.
The API differences on Windows are mostly handled by Cygwin and mingw. Those areas that are different are places where you should have your code modular anyway. Mostly we are talking about device and networking code. IPv6 is on the way (has been for 10 years now...), you need some difference code to support that. There is no standard for device code - what works on OpenBSD won't work on linux, or FreeBSD.
True almost nobody cares are VAX - but it is interesting anyway. If you code is modular like it should be, then supporting those weird things isn't a big deal - you write you code, and let those are care about it test.
A short summary: There should be only one OS that anyone runs: RedHat Linux enterprize edition on x86. (not x86-64) Not Fedora core, much less gentoo or those other non-redhat distributions. You FreeBSD people can go to hell.
He wants to take his ball and go home, I don't care, we are better off without people like him in the open source world.
Porting software to different platforms has two distinct benefits:
1) identifying subtle bugs
2) preparing software for future platforms
- Subtle Bugs -
As stated in the parent post, porting software to various platforms help uncover bugs that may not surface during routine testing in a mono culture.
- Future Platforms -
Making software portable prepares software for the future. As computer technology advances, software that has been developed to be portable will be the first code running on the new hardware. I could go on and on about this, but I think the recent articles regarding Intel's Itanium already make this point loud and clear.
-rd
As you say, there are examples where porting has helped a project. I know that in porting one of my games to four platforms (Classic Mac OS -> Windows -> Linux -> OS X) has helped eliminate bugs that I never knew were there. Also, I learned things that have made my later projects easier to port since I more able to write them "correctly" to begin with. By avoiding platform specific libraries and techniques I write better code.
Lasers Controlled Games!
Hypocrite... (software should be free! So I'm holding mine hostage until you release yours!)
And let's imagine what would happen if the vendors of those proprietary OS's decided to play the same way...
Say goodbye to NFS, NIS, Rendezvous, Mono. Perhaps Sun would close Java (which would make the conspiracy theorists happy, but nobody else.) Goodbye to the largess of many large vendors (where do you think organizations like FSF get their funding?).
And that crack about "ideally to one". Linux is a nice OS and all, but believing that it is the one for all purposes from PDAs to supercomputer clusters, data warehousing to real-time control is silly.
Am I part of the core demographic for Swedish Fish?
Compiling and testing code on multiple platforms is a wonderful way to smoke out bugs. Of course if people solve problems w/ #ifdef rather than rewriting the code to honor the language and operating system standards it doesn't actually help. I'd bet most "bugs" are really demonstrations of the phrase "implementation" defined".
Sort of reminds me of people complaining that their named COMMON blocks were getting stomped on because they didn't read section 8.3.5 of the FORTRAN 77 standard.
Not supporting device drivers on exotic systems is reasonable, but generic applications have no reason for being so tightly coupled.
I visited two websites today that wouldn't work. One told me to download Mozilla 1.x (I'm using 1.4). The other, a government site w/ a help desk told me I had to use IE which is tough to do if you don't have a Windows machine.
The real problem is sub-p programmers who think if it appears to work they know how to program. Real progammers keep a copy of the language standards next to the keyboard and reference them regularly.
Users don't care about 90% of the users. They care about themselves. Why should they spend money to buy a new PC just because other people can't take the time to think ahead in their designs?
Also, I hope you don't think 90% is a good cut-off. If you're happy with assumptions that only hold 90% of the time, I sure hope none of your software is running on my system.
Besides, if you're talking about assumptions that cover "90% of the users", you certainly aren't talking about Linux!
Am I part of the core demographic for Swedish Fish?
Second, platforms are not stagnent. Code that only works on 386 linux may some day have to deal with a x64 only world. Who knows what may happen in the future. Making decisions because you reject portability means you reject the future for your code as well.
Third, different compilers are very useful for finding less obvious bugs. Ideally this means having a choice beyond gcc, if one is talking about C/C++, for example :). Using a single compiler means bugs your compiler doesn't itself know will likely be retained. Even using different versions of gcc can help. Different compilers often are good at finding completely different sets of bugs in source.
Finally, pointer/integer size and endian prejudices are evil in C/C++ code. You will find these things very quickly if you spend your whole life exclusivily on i386 and one day try to port to ppc.
Writing portable code is good for the soul.
It makes you read the docs. It forces you to use a standard API when byte order is important. It keeps you from hardcoding values (eg sizeof(void*)). It keeps you from making platform dependant optimizations that might not even be supported by the next version of the platform you're on, or if you do it forces you to make them modular.
It forces you to figure out what behavior you can rely on. Bug compatability with older versions relies on the magnanimity of the maintainer, and cannot be assumed even if you're staying on Linux.
I rarely criticize things I don't care about.
Consider this discussion of Kim Il Jong of North Korea given in this blog:_ support.html a /transcript.html
http://mansei.typepad.com/dogstew/2004/10/popular
Especially the PBS interview mentioned in the blog:
http://www.pbs.org/wnet/wideangle/shows/northkore
Basically the Dear Leader uses both violence and mind control.
I am a Macintosh programmer from long ago. In the Pre-OS X days I worked extensively with the mac ports of libxml, libxslt, and TCL. I played with other open source software on the mac as well like MacPerl and the early mozilla builds. The mac port was generally a point release or 2 behind the main development. I assume the blogger udrepper is talking about people like me. The usual situation I encountered was that mac programmers had to support the macintosh port with little input from the non-mac programmers. The project "owners" would include the mac support files in a subdirectory of the project source tree. Everybody on the project understood that the contents of this subdirectory was only of interest to mac programmers.
This was quite a reasonable situation. No mac-specific configuration options affected the rest of the project. It is no longer the case. Now the OS X (usually spelled "darwin") build is another option in the makefile.
Over-dramatic; leads to fragmentation which leads to redundant work. I think you would do better to revert to the platform-specific sub folders and let the programmers of that platform update their patches at their own pace. This saves the "minority users" the problem of maintaining a new website and CVS system. You get the benefit of some contributions to the main development since a new feature or two usually must be added by the minority platform programmers.
If you really want to support exactly one platform with few options, then be sure to use a scripting language (any of the P* languages will do), or maybe java and/or mono.
The leadership of any substantial group of people is always a minority. How many bosses do you have? How many people work for him?
You can have it good, fast, or cheap. Pick any two.
His tactics once again leave a bitter taste for people that aren't GNU zealots. There is somewhat diminishing returns at some point, but its the same old idiocy in the way he puts it. It might have been RMS spewing.
Minorities can certainly always wreak havoc on the freedom of others.
That's the first sentence and it only get worse.
So the question is: why are there all these configurations? One answer is: because of violent minorities supporting such configurations.
Violent, eh? People are getting beat up.
The fight for saving the software world from the evil of proprietary, IP-enforced, non-transparent software has only started.
Evil? Yeah, ok. I thought him and Stallman weren't getting along. Sounds like he just got back from a GNU re-education camp.
Support for proprietary OSes should be dropped.
Windows isn't the minority. Try again.
There are undoubtedly people who will want the flame me to death. But these people are almost certainly all members of said violent minorities who want to force their opinions on the majority.
Violent again.
Once again, people like him and Stallman do far more harm than good by acting like a complete nut.
Keep these extremists down in the basement coding.
I coordinate a certain OSS project that will remain nameless, and while I would not say that "Porting OSS to minor platforms is harmful", I have seen first hand some of the problems that he is experiencing.
I've been in situations similar to Drepper's AIX situation, where there is a situation where either myself or someone else wants to make an improvement, and finds themselves breaking a minor platform or derivative project that we might not have the development resources to fully investigate. And usually, it is because of a legitimate error on the part of the contributor. But whether the error is legit or not is beside the point; the point is who is actually responsible for preventing breakage?
The dilemma comes down to the idea that even in the OSS world, developers are not free, and if such a breaking change is introduced that only manifests itself on a minor platform, what is the best way to move forward? Should anybody that makes a submission be responsible for tesitng that submission on every port and derivative project?
It all comes down to a balancing act. Is it worth it to you that GCC releases get released a week later so that AIX can be supported? Or should the AIX people (or the GCC VAX people, or the GCC C64 people) have their own separate fork and their own release schedule, so they can handle their own regression testing? The answer is suprisingly not always obvious, and the wrong decision may have political costs in the amount of people working on the project.
In a previous /. article, several people didn't even want to reckognize Gimp and Gaim as Linux applications. Hell, not even GTK! They preferred them called "open-source", and not Linux applications or in the case of GTK, Linux API. Their argument? It works on windows! Now, how is this helping Linux?
Does Gimp and Gaim work on Solaris, or the BSDs? Linux does not own these apps or Gtk+.
Linux is a kernel.
And you, nor anybody else, is in a position to say "must be dropped".
Drepper is right about build and configuration being the fundamental issues. This is where Java is the clear winner. I know others have pointed out the advantage of Java (or gasp, C#) here, but I have to say that advantage is real and growing, even if as others have pointed out there are legitimate issues with GUI. I will grant that some issues still exist with GUIs, but
.xml and figure out why.
a) They aren't as bad as people make out. I have used and developed many apps that work fine under all 3 major platforms, perhaps not with all of the finer distinguishing platform features intact, but quite functional and not fugly.
b) So much of what is developed has no GUI component at all. And note that there are non-Java GUI solutions that work very well with Java.
But ulitimitly the reason that Java works is that there are strong, simple common build solutions such as Ant that make configuration and build easy and, critically, transparant. I have had much experience with make and much more with Java tools like Maven and Ant, and I would pick a Java based solution any day based on that. Typically with Java, the build just works, and if it doesn't it is very easy to scan the ant
OTOH, when make fails there are nearly always odd dependency issues, switches that need to be discovered, etc. etc. And this is where I disagree a bit with Drepper -- often these are not because of obscure platform issues but have to do with use of different very common distros, slight differences in lib version and so on. And these problems do reach expontential complexity very quickly
I will certainly not claim to be a *nix expert but for me and I think many other developers this all makes Java a joy to work with -- at the risk of sounding like a cheerleader, "it just works".
...adapting your application to architectures as diverse as x86, ppc, MIPS and Sparc at different word-widths is a great way to uncover subtle and long-standing bugs.
To be sure, robustness may be as optional for you as it was for Microsoft (and would still be, absent competition from Linux), but in the long run it seems to pay off.
Most of us Linux users would not regard, forex, The GIMP as particularly robust, but compared to the typical WIn32 app it's a paladin of reliability. My sister-in-law routinely leaves it open (and unsaved) for weeks on end, confident that it will still be there when she gets back (but a recent hard-disk failure of mine seems to have put the fear of God into her WRT reliability). She also happily browses everywhere fearlessly, knowing that she can't damage anything on her own machine, and nobody either I or her know of have ever been burnt by malware while browsing in Linux.
MS users just don't do that - not more than once or twice, anyway.
Got time? Spend some of it coding or testing
why even bother using such old hardware?
For the same reason Ulrich Drepper is wrong. An Ultra 1 is super cheap, now, and it gives a programmer the chance to test code on a big-endian 64-bit architecture. Are there lines of code with endian dependencies? Are there lines of code that assume 32-bit CPUs?
The same goes for testing on Linux, as well as NetBSD, Solaris, etc. Does the code really use POSIX intelligently? Is the program abstracted well from the kernel services?
This whole article is just a Red Hat employee tooting his company's horn. His advice is inappropriate, in that it promotes bad programming, just as Windows fanboys writing to Win32 can shoot themselves in their feet so often.
Of course the headline Slashdot reported is not what he said. Uli is abrupt, but he is practical, and not stupid. He's not always right, but when he's wrong he's interestingly wrong. If you think he's arguing for something stupid, you aren't paying attention.
What he said was *not* that Glibc, or Gcc, and whatnot shouldn't be ported to AIX, m68k, and whatever. What he said was that he does not care to *maintain* those ports, and should not be expected to. IBM (or IBM's customers) can certainly afford to maintain a port for AIX. Let them. Likewise, all those embedded-system houses dependent on m68k targets are welcome to step up and supply their own patches to keep their ports working.
If a patch to mainline breaks the AIX port, it's the job of the AIX maintainers to figure out how to fix the patch, not him, and not whoever contributed the patch (but has no access to AIX targets).
He's not even saying he would reject patches needed to support minority targets. Whoever's maintaining the m68k port doesn't need to maintain a fork. They are entirely welcome to send along whatever patches they need installed. They need only be sure their patches don't break any supported targets. This certainly makes more work for users of less popular targets, but it spreads the work around, instead of piling it up on those doing mainline development. The mainline maintainers have plenty else to worry about.
Java DOES solve that problem. The linux crowd by and large won't use it because it's not quite their flavour of 'free'.
I'm really torn about what to think of Debian.
On one hand, I really like the concept--that they keep Linux available on a wide range of architectures
Everytime somebody likes to say that about Debian, I like to remind them the NetBSD folks support an acorn26 acorn32 algor alpha amd64 amiga amigappc arc arm32 atari bebox cats cesfic cobalt dreamcast evbarm evbmips evbppc evbsh3 evbsh5 hp300 hp700 hpcarm hpcmips hpcsh i386 iyonix luna68k mac68k macppc mipsco mmeye mvme68k mvmeppc netwinder news68k newsmips next68k ofppc pc532 playstation2 pmax pmppc prep sandpoint sbmips sgimips shark sparc sparc64 sun2 sun3 vax x68k xen impressive array of platforms, and at the same time hack userland, kernel and protocols. While Debian developers mostly package upstream stuff.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
He thinks that when people program they don't make mistakes while copying strings, that, in fact, programmers are infallible.
Or at least that is what he says when people propose these APIs for addition into his glibc.
I am more of the opinion that he is stubburn and does not want anything from OpenBSD, cause they are obviously an insignificant speck not worth a breath.
It's like he's Poul-Henning Kamp and Scott Long combined and ported to Redhat.
Porting and generally most other open source development happens on a needs basis. Developers decide "I need/want this, so this is what I'll work on." If someone needs a specific port of Linux, they will put forth effort into developing one, effort that might not go into OSS development otherwise. You can't believe that if you get them to stop, that energy will be focused on what YOU want them to work on.
If there's a problem with developers being bossed around into doing niche work with no compensation, and they don't like it, they need to stand up for themselves. For example, if IBM wants gcc to work well on AIX, they should either make it happen themselves or pay the gcc developers to better look out for their interests. If, on the other hand, the gcc developers are well compensated for fixing AIX problems (I don't know what the situation is), then there's no problem, except in the eyes of bystanders who don't understand the situation.
There are probably a few valid reasons, I think. Here are mine:
- Not everything requires the latest hardware. Keeping machines running, that are still fully functional (component wise), keeps them out of landfills.
- Sentimentality, I like the Sun SPARC hardware and want to keep using it. Even for trivial tasks like shell accounts for mates and some types of testing.
- Diversity is a useful thing of itself, an x86 monoculture can't be good for us long term.
Open Source is always about developer, not user headcount.
Half the Linux distro's have less developers than the avg BSD. Let's kill them off.
Not possible and thats kinda the point. Free software is worked on for the most part by volunteers in their spare time. If somebody wants to spend their time porting the latest OSS app to Windows thats down to them.
Its true to say that porting OSS apps to windows improves the Windows experience by providing Windows users with some good quality software for nothing, but this IMHO is a good thing. For me, OSS software is about improving software for everybody and that includes Windows users.
"XML is like violence. If it doesn't solve your problem, use more." - Anonymous Coward
The way to resolve the problem is to have two lists of supported platforms, primary platforms and secondary platforms. Primary platforms must work, there should be no releases that break the primary platforms, and new features must be developed with all the primary platforms in mind.
For secondary platforms, patches that make the application work on those should be accepted and encouraged, but releases won't get delayed, and new features can be accepted even if a solution for the seocndary platform has not been found. In general, users of the secondary platform should not rely on the official releases of the platform, but get their code directly from the maintainer of the secondary platform (or from a cvs branch).
Which platforms are primary and which are secondary should depend on the application. For easy-to-use end-user stuff like ForeFox, IA32 GNU/Linux, IA32 MS Windows and MacOS X would be a good set of primary platforms. For the GCC/binutils/gdb the set need to much more varied, and include popular embedded platforms. The strength of GCC has always been portabiblity and cross-compilation. It has only rarely been the best compiler for native compilation on popular platforms.
No, no, the title is correct. Read the article yourself:
"additional indirection to resolve the differences in APIs the code gets bigger and slower"
This is not a case of minorities slowing down release process (ala debian), but really a stance like "we should not even accept patches that enable multiple APIs".
This is soo stupid. Blaming windows port for bloat ? Free software community didn't need anyone to let Ghome beeing bloated to death.
The path he proposes is very dangerous: soon you'll drop support for non mainstream arch, then non-mainstrean devices, then non-mainstream usage pattern.
But sure, it looks like it would make his work easier. And, if don't get satisfaction, he can always point onto that 'other' minority for the problem he have developping software...
If he's stuck with one particular release then he 'can't keep his ultra up-to-date'. That's what the original poster said. he doesn't want just an OS or a distro. He wants one that still supports his chip, releases updates to it and so on and so forth.
Support for non-mainstream platforms (alpha, 64bit sparc/mips) and fixing of the associated 64-bit bugs made porting to amd64 a lot less painfull than it would have otherwise...
Aside from that, support for non mainstream platforms is a major strength of open source, many of these non mainstream platforms are and always have been much better than the mainstream platforms, but they're dying out because of the prevalence of proprietory software which can't be ported to these platforms.
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
I am deeply convinced that porting assures portability, and portability is one aspect of clean code where bugs and wrong assumpsons are noticed, resolved and corrected.
Surely porting to platforms such as the Alpha and UltraSparc was a very good basis for porting to platforms such as AMD-64. This is a crucial advantage for free software, where we can be sure that we will be able to support new platforms and make interesting platforms mainstream.
On the other hand, the premisis that the main maintainers can not be responsible for all the porting effeorts is reasonable. Debian is thinking along the same lines, and for good reasons.
I think it is wrong and bad to assume porting is a bad thing and avoid it. Even apparently futile projects such as porting free software for closed commercial platforms gives a large amount of flexibility in design and portability and helps projects such as embedded graphical environments.
Portability is just one facet of advantages of free software and as such is a precios thing that we have to cultivate. But it sould be just another part of the free and open collaboration development process, not an obligations for the main developers.
Just my 2 cents.
-Kvorg
Seriously, isn't this the same Ulrich Depper who can't even bother to get glibc right? glibc incompatibilities -- even in patch versions -- is a major headache on Linux. Compare that to those ``obsolete'' platforms like AIX and Solaris where I can still run binaries that I have compiled in the early 90s or even the 80s. glibc is one of the main reasons why Linux application deployment sucks in major (read: heterogenous) installations. Kernel differences are actually not as problematic, but glibc is biting ourselves all the day.
He has shown already that he won't bother for people who run computing centers. Here's he, spouting more hobbiest opinions. Nothing new, move forward.
Joachim
People don't write Manifestos any more -- what's going on in this world? [Frank Zappa]
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?
Hmm... let's see: the major software costs money, and I'm giving my work away for free. If they port, they get extra sales. If I port, it means I waste my valuable personal time doing something I don't want to do. Since I give my code away, anybody who really wants my application ported can do it themselves or pay somebody else to do it. Since the major software doesn't come with source and isn't freely redistributable, we are utterly dependent upon its developers for a port.
They are simply two completely different scenarios. No hypocrisy.
What amazes me is that he is in minority, in the OSS world. Am I mistaken, or is he the only one complaining so loudly and so veemently about such things? If he were part of the majority, surely the problem he talks about wouldn't even exist, as the majority would have adopted his line of thinking already.
So he basically got into a paradox: he complains about the whining minority, yet he is the whining minority!
I have a real problem with attitudes like "we do not support non-free operating systems". Of course, software should be free IMHO. But dropping support for non-free platforms takes away the ability to use at least free application software from users who aren't in a position to decide which os they want to use, be it at work or due to limited technical skills.
Even more important, this type of attitude (( flame me, but I'd call it bunker mentality )) harms collaboration between open source projects, and also between commercial software vendors and open source projects. (( if you don't know what I'm talking about, take a look at the copyright notices for g++'s STL headers ))
To make the point clearer, let's take Ulrich's ideas a bit further. From a BSD purist's point of view, GPL licensed software does qualify as "non-free".
What if e.g. the OpenSSH guys decided to drop support for non-free operating systems such as Linux, particularly commercial distributions like Redhat that include proprietary code?
"Of course, you Linux guys may always maintain a separate tree that includes supports for those exotic systems."
So we'd have X people who could be working on something way more useful, trying to keep a forked tree in sync with the original project. Great.
While MHz/Watt is not good for old computers, most of the time you don't use anywhere near the full power of a new machine. If a 386 running at 100 Watts and it does what you need, why should you switch to a 350 Watt p4? You'd get better MHz/Watt but more Watts overall.
This post written under Gentoo-linux with an SCO IP license.
If you read what was actually said, most replies
... and lack of platform access
make no sense; to paraphrase:
Mainstream developers, using common architectures,
which will change over time, should not hold
themselves hostage to proprietary, minority or
legacy platforms
makes this impractical in any event.
This makes complete sense, if, as is actually the
case HP, IBM & SUN have, by incompetance or greed,
placed themselves in a position where their
platform _depends_ on GNU tools they need to spend
some support revenue on the tool-chain, and
provide gratis platform access. This is how it
used to be before Red Hat bought Cygnus.
Finally, no one is going to deprive legacy
platforms, they have to do work, pay or resign
themselves to a feature freeze.
If there's a bug in the main source code base that only manifests on a particular platform, it's still a bug.
autopr0n is like, down and stuff.
Assuming we're talking about the same thing, bundles are a compromise between the need for easy installation of applications and "flat" file systems. What would you have preferred under those requirements?
Also, do you have a more objective criticism than "ugly"? I'm not saying you don't, but many times it's just another word for "unfamiliar to me".