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."
But I agree with the opinion if, as a developer and/or integrator, you are attempting to reach a mass market. Red Hat, then SuSE and others have abandoned the Sparc platform awhile ago. I bought an old Ultra 1 and am now limited to a few distros to keep my Sparc machine up to date.
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.
"Rocky Rococo, at your cervix!"
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.
Wasn't Java supposed to solve this problem? I was under the impression that you could run Java apps on any platform (albeit slowly) without worrying about compatability?
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!
In the mid 90s Redhat was a minority platform, where as slackware was more mainstream linux. That was until $$$ change things up.
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.
The development of netBSD to over 40 different platforms has brought a lot of good development to many different platforms that would have been dominated by mono-operating systems. A good instance is the handheld devices platforms (HPC,Palm PC, etc.), which would otherwise be dominated by Windows CE (except for the few Linux Palm PC's, but majority are WinCE). The development of netBSD for the majority of platforms has reached great maturity, and it is still developing well.
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!
:(){
Let's just eradicate them once and for all. A homogenous Linux monoculture will be easier to maintain and be to the benefit of all of us.
The point of open source is that the features that get added and the platforms that are supported are the ones that people put the time in to code. If a project supports platform x, it goes to reason that someone, somewhere, uses platform x and the given application, and has the skill to make them work together. This isn't a commercial project, where you have a marketroid telling you 'someone, somewhere wants feature x and for the application to work on platform y'.
"Because Science" is one step from "Because old book". Try "Because of my experiment testing my falsifiable assertion".
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."
This post was surely inspired from this message to libc-alpha.
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?
Which are the OS targets which should be supported? Support for proprietary OSes should be dropped. Free software should only support free OSes and even among those the group needs to be trimmed significantly (ideally to one).
Sounds like someone wants to take his ball and go home.
You know, that's what Apple has now. And in four years, Apple developed an OS that's stable, fast and incredibly easy to use, along with a software suite that integrates beautifully. Apple's already done this, while the Linux community is still trying after 20 years.
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?
However, there is some good PR value in some of these ports.
He is right though, a bit of strategic thinking would be Good. eg. Think about when dropping a port would merely force some lazy PHB to take the final bold step into the wonderful world of GNU/Linux and when keeping a port is winning valuable support and new recruits. eg. Dropping support for SCO was Good in several ways.
Let's all get things done a hundred times slower!
Progress!
And here I thought that getting rid of bugs was a good thing. Coding for portability makes for better code, so code that doesn't port easily is deficient. (Any high school freshling with VisualStudio can write code that works dependably on a single platform.) Ergo, testing on secondary and tertiary platforms makes for better apps and is simply another aspect of QA.
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.
Doesn't that sound like something MS would say? Don't waste your resources developing for small-time operating system like Linux or Mac when only the large market platform, ie. MS, is feasible for reaching your feature goals in a timely manner?
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?
A hundred times slower than what? Assembly?
This was in 1998
Please update your trolls.
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.
Ouch.
In the large software project I work on, I can attest that this is most definitely true.
Our product supports 13 platforms (usually both 32-bit and 64-bit for each of those) - several windows, unices, linuces... In general, we try to run our entire test suite on every platform for every release and every fixpak. In general it takes about a month to run all the test for each platform. Obviously, we run the suites concurrently on each platform.
Once we get close to the end of the release cycle, and the code gets frozen, every last minute fix has to be run on all these different platforms... what a hassle. It consumes large amounts of both hardware and human resources to perform all this testing.
Not to mention that in the normal development process, when checking in a fix you can't test your change on every possible platform... you'd never get any work done. So we test on the major ones and cross our fingers it doesn't break anything else. Sometimes there are compile errors on the rare platforms (HPIA64 is a beast for this) and others there are runtime problems that don't get discovered until much later.
So, I can attest that in the real world, even in a non OSS environment, supporting all those rare platforms is a huge PIA and definitely slows down development and reduces quality.
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.
a couple million web sites running an open source OS which is something Not Linux, and those that do run Linux are bailing out of RedHat to other things: SuSE, Ubantu, etc.
Yay unbiased sources!
In other news, Ben and Jerry report that ice cream is just as healthy as broccoli.
This is a reason we should be using languages other than C/C++.
Then we only have one (significant, sure) platform dependant application.
Dealing with platform oddities on every program is always going to be a far more difficult problem.
Yeah, of course one operating system is easier. While you're at it, it's also counter productive to support a myriad of hardware platforms too.
From now on, you will be allowed to use 1 specific CPU, with 1 chipset and one motherboard...
Heck, and why even let other people at the source code. They'll just come back and tweak things and report new bugs. Close up the source, I say!
Sheesh! The whole beauty of open-source is that anyone can and probably will port stuff to their own favourite platform. You may find some platform specific bugs, but they may be helpful. You may learn something that fails disastrously on some platform is actually showing up as a subtle bug in another (e.g. security issue).
You can't pick and choose about open-source. Either it's open to everyone, or not.
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.
It's the wave of the future. How come OpenOffice hasn't been released for it yet?!
As does IBM
the results show that Java server performance is competitive with legacy environments
Java servlets outperform CGI, and the Java platform is competitive with C or C++
Jvm optimizations such as efficient monitor and object allocation implementations have led to significant performance improvements, including better scalability that is vital for server workloads
What I see in mailing list is a lot of questions regarding how to port or how to install OSS in Mac OSX, so please don't port it to OSS. There are also several linuces, so lets settle down to only one to rule them all. (I am being sacarstic here!).
DNA in your Linux: DNALinux
I suppose the OpenBSD crowd should stop supporting those "other" platforms like Linux with OpenSSH.
I rarely criticize things I don't care about.
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 #!
Porting reveals bugs. Shouldn't we spend time finding bugs? It's not like the BSDs are lagging behind in features...
Can you find a source that doesn't have something to gain by proclaiming Java to be as fast as C++?
If you write your code to be portable in the first place, fixing platform-specific issues should be quick and easy.
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.
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..."
Sure, there are examples of "Gee, this would have been a major security problem if not for the Vax port". But most of what you see on this lists are just, "Waah, it doesn't compile on my Amiga." Well who cares? Assumptions were made, assumptions that cover 90% of the users. Go buy a PC and load Linux already.
I believe most of the problem with having to spend large amounts of time to port an app to different OSs could be fixed by each OS supporting the same basic API calls and command line and compile tools, as defined in things such as POSIX and Single Unix Spec, in order to assure source compatability, the ability to recompile an app on any OS with no modifications. It seems one of the biggest offenders in making portability difficult is Windows, and a lot of time has to be wasted to port to that platform.
Many OSs, as well, support each others binary formats as well. FreeBSD can run compiled Linux applications, which is possible since Linuxs libraries, etc, are open source and can be used to support such binary compatability on other OSs. FreeBSDs Linuix support is pretty fast too, with little or no performance hit.
...they are immunte to goatse, tubgirl, and lemon party.
I think its useful to point out that MS tries to be all things to everyone (with varying degrees of success) and it has not hurt them (yet). Furthermore, tinkering is what OSS is built on. To say that tinkering with obscure harware/software is harming OSS is really rather foolish.
Academics looking at the question
Java is now nearly equal to (or faster than) C++ on low-level and numeric benchmarks. This should not be surprising: Java is a compiled language (albeit JIT compiled).
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
...I can see where that would be a problem, but if the project is diverse enough to include people more skilled in Windows, BSD, Macs, or whatever than in Linux, I'm not sure you would gain much by forcing them to stick just with Tux instead of the Borg, the demon, or the fruit.
Is is just me, or did I first read his name as Ulrich Drpepper?
SYSOP ('sih-sop) n.: the guy laughing at your typing.
I philosophically support Free Software. (And no, I don't have to show you my Party Credentials.) But loose talk about purges of counterrevolutionary elements and collectivization of software development really freaks me out.
News flash: Communism rightly failed. Take Free Software down its path only if you want it to fail too.
Well, some neo-Stalinist Free Software chekist will probably downmod me. Is this how Leon Trotsky felt? (I mean, before he got the ice axe in the head.)
Keep Free Software FREE! Once you begin rounding up and interning the minorities, you are taking the first steps toward a new totalitarianism!
Welcome to the Panopticon. Used to be a prison, now it's your home.
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!
The problem with all of this "choice" is that to be able to compete with Windows, MacOS X or even Zeta in the long run, Linux distributions have to have all of their components that tightly integrated. That means that ideally the KDE, X.Org and Linux developers need to be all on the same sheet of music to make sure that their components work very, very well together. Most people cannot even tell you what GDI is on Windows, or Quartz is on MacOS X, so why should they have to know what X.Org is and why they need to care about it?
This is the painful reality for these developers. The average buyer doesn't want a distribution, they want a complete operating system. KDE + X.Org + Linux is a cobbled together setup, Windows, MacOS X, Syllable, BeOS, etc. were and are not. That's what they expect, and it may mean that some of the smaller projects have to take on a lot of work. So be it. If you want desktop Linux to work well, and be a true replacement for Windows, then it may mean that the KDE and/or GNOME guys have to go Linux only or that another project has to be started that creates a complete and pure Linux operating system that is a "total experience and environment" rather than a collection of packages.
The difference is fundamental, not symantic. It means that the projects must be coordinated together with one vision, one plan and a goal of one end result.
Click here or a puppy gets stomped!
'cause if his code is like his blog, it's pretty bug ridden.
...multiple configurations mean diverts energies....
...even to undeserving once like...
...more about winers who complain ...
Damned, ungrateful oenophiles!
Clear, Dark Skies
Ya! Lets kill all those pesky platforms. For instance, Windows has a 90% market share. Kill everybody else off, and have them expend their efforts on making that more secure. Oh wait, its closed source. In truth, basically everyone who works on open source does so because they want to, and not just do right by the community, but on a certain project. For instance, if Linux dropped DEC Alpha support, for the most part, the DEC Linux community would not all see the light and switch to maintaining x86 stuff, they would simply stop being participants, since their interest was not longer a platform. In the most extreme cases, all the jilted people get so angry they abandon the community and fork their own version of whatever software their are crazy about (cough cough BeOS).
As others have suggested, the users change over time. Assumptions can paint you into corners.
For example, the intel world is slowly moving to 64-bit platforms. Clearly we aren't there yet, but things are steadily moving in this direction. It will probably be similar to the slow migration to 32-bit code that happened in the mid-90s with Win95.
If you've built up something the size of OpenOffice with 32-bit assumptions all over the place, you'll end up getting left behind. On the other hand, if your code is already clean then you'll move right along. (Incidentally, openoffice is one of the few open source apps with poor 64-bit support.)
Assumptions are fine, however poorly understood assumptions are not. If you understand your assumptions then working around them usually isn't all that hard. If you don't understand your assumptions then sooner or later you'll get burned...
There are two reasons why this is wrong. First, many open source developers don't make use of existing cross-platform tools. Example: if you need a GUI, don't write different platform-specific code for every platform, just use FLTK. Need threads, use OpenThreads. That's what these libraries were designed for. If the Octave developers had done this, maybe it wouldn't take six months to get the latest version to compile for Windows.
/., but not in the real world.
Second, VC++ is not the Windows compiler. It amazes me when developers who use Linux don't even know about MinGW, or think that it is dead. Most Linux projects will build with MinGW with only minimal changes to the makefiles. From the article:
"Many of the GNU projects are ported to a wide variety of platforms, even to undeserving once[sic] like cygwin and mingw."
Guess what, Mr. Drepper, if the code was written properly in the first place, you wouldn't have to "port" the project to MinGW at all.
I would argue that not writing a cross-platform project that works with Windows and Mac, is harmful. And since when are Windows developers a "minority". Maybe on
Setting aside the argument that open source == linux, he does have a point - even within Linux itself.
My company sells custom hardware that runs on Linux. 75% of our effort is making sure that our drivers run on every !#$@%!@ variation and distro. We earnestly hope that someone's drivers for our type of hardware will end up part of the kernel - simply because then we can build our hardware to match the kernel and leave support of all the distros up to the lunatics who seem "tweak" the kernel APIs on every single dot release.
Clear, Dark Skies
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.)
Is Harmful? Not "Considered Harmful?"
Sigs are like bumper stickers.
...the official GNU core known as "the HURD"..???
GNU Libc is a GNU project. While Linux is the OS tha most commonly uses GNU Libc at the moment, why would he be proclaiming that things should be made for a different OS than his biggest project is intended?
Read "GNU" more like.
I think he should concern himself with what suits his interests, or what suits his business objectives, and let others be concerned with whatever appeals to them and suits their fancy. I think when it comes to open source developers, the phrase "whatever turns you on" should reign supreme. Some may say that regulation is better, but I think it's up to individuals to regulate themselves, and choose what gives them usefulness or pleasure. They're not paid, so why should they take orders, or even direction from others? It may be true there are instances, perhaps many, when his view has merit, but it's even more true that whatever brings on developers, turns them on, and doesn't turn them off and away, is likely to be ultimately far more beneficial.
Please find me an unbiased report stating that Java is faster than C++ in one of the following languages:
Thank you.
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?
I'm not sure I totally agree with this article - at least as far as Windows porting is concerned.
I second that. The first thing I do on a freshly installed Windows 2003 machine after hardening it for security is to install the GNU tools and vim. That may seem like a silly thing to do but I am familiar with the GNU tools and I think Microsoft made native commandline utilities really suck so it makes life on Windows a little bit more bearable.
obscure bugs are often found during a port to another platform. It leads to better code. You discover your wrong assumptions.
Just a thought, but wouldn't this suggest that Open Source be done mainly for Microsoft Windows? After all, I hardly think anyone can successfully argue that any other operating system is in fact the mainstream operating system.
Its the fact that Open Source developers do not use mainstream operating systems that they get involved in OS in the first place. If they used the mainstream OS they could just buy the software they wanted. A whole lot cheaper than writing code yourself any which way you look at it.
Multi-platform support is a strength of open source. It's not free -- it adds work to the development process. But it makes for cleaner code, and for more useful code.
The world isn't going to be x86 forever. It might be for a long time into the future, but eventually thigns are going to change. When that happens, it will be really, really hard for MS to make the change. It will be almost transparent for linux.
Benjamin Meyer ported KDE to run the Mac, and just got a job with Trolltech, presumably due to his Mac expertise. Not harmful to him, or KDE for that matter.
KDE runs on many platforms, but the releases are for linux. Ports are maintained by individuals or small groups.
Derek
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.
You are right: that sort of portability (supporting many types of platforms using [broadly] standard interfaces) does often help code quality etc.
:-) is not that, but rather the practice of trying to support completely alien systems that don't implement the common interfaces you normally depend on. This kind of "portability" often results in a huge festering pile of kludges and massive duplication of code. A popular example is MS-DOS; many packages end up with ".bat" files duplicating their makefiles, use painfully awkward filenames to avoid upsetting 8.3 filename restrictions, have special cases for MS-DOS scattered throughout the code, etc.
However I suspect that what Ulrich may be talking about (of course I didn't read the article
Of course if you really go all out, the effort may end up helping your package by forcing you to thoroughly refactor your code for maximum flexibility, etc. But in many cases the benefit is not worth the pain, and the developers instead go the lots-of-kludges route, and the net effect is negative.
We live, as we dream -- alone....
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.
- start with a wide variety of platforms to begin with, and
- maintain coding standards that spell out common problems with compilers
adding more is not really a problem. If someone requests a new platform be added, it's not supported until nightly tests are automated.http://www.livejournal.com/users/udrepper/7326.htm l
Can someone please explain to me the difference from platform specific software? Aside from port problems, including bugs and library/grammar problems; isn't this pretty similar to--say, a Win-centric software? Debugging and compatibility issues are usually about %60 of the development process. Extremely intricate and mathematically complex programs aside (usually used with supercomputers), most consumer software runs into most problems in relation to hardware and OS, same problem with OSS.
Can someone please explain to me how OSS is more difficult in this regard?
Of all the Universal Constants, here's one I know: Nice guys finish last
You chose to be
different, so you pay the price.
Bwahh haha ha!!
That is such a gem. Why can't those Linux babies just use Windows?
But seriously. I love my Omron Luna, and my Decstation, but mainline GCC support? Who are we kidding? GNOME 2.6 port? Personally I would never bother to use it.
I see no problems in prioritizing modern OS's and modern hardware. Since our community is so geeky, perhaps we could quantify how much effort is wasted on minority platforms, instead of bloviating until blue in the face?
I only support Solaris and HPUX and linux writing low level code. (ironically an os abstraction api so platform shifts are easier)
I find differences in the way these OSs handle things make my life more difficult..
ioctl calls are different, some socket stuff is different. (default multicast ttl, handling of empty buffers), threads. real time "quasi" OS code varies greatly for multi-proc machines.
However when/if you fully understand what your doing you can write good code with a minimum of #ifdefs. Its a bit more painfull than it should be sometimes, and its time consuming. Time many coders would rather spend adding functionality.
However the benifits of having code that works great on many including minor OSs are great. This shouldn't affect higher level processes. Noone wants to spend time debuging code for some obscure platform, its not fun, but it needs to be done.
One World, One Government, One Operating System
Vintage computer adverts: http://www.vintageadbrowser.com/computers-and-software-ads
(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)
Oh, right. I have a mental block against DOS whenever I'm not at work. I simply forget it exists on weekends and holidays. I'll have to deal with DOS network drivers tomorrow. It will make me sad. But,, when I get home, I will once again be complete unaware of its existence. I think it is some sort of psychosis. I refuse to have any DOS machines at home, but have damn near everything else.
:)
BTW, you are an evil fugly bastard for reminding me of it on a holiday. Jerk.
that the author of this stunning blog entry is the asshat who
argues that good programmers don't need strlcpy, since they
don't make mistakes while copying strings.
This man has done as much as anyone to reduce the security of
software written for Linux. However, it is nice that his comments
have generated a good discussion about why protable
programming is a vituous endeavor.
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.
Red Hat Enterprise Linux ships on 7 platforms already. x86, x86 64, Itanium 2, zseries, iseries, pseries, and something else I forgot. Fedora runs on the first two, plus ppc.
From the blog in question:
And there certainly should be more than one mainstream architecture to keep all the players real, so I welcome PPC in addition to x86/x86-64. But there is no benefit at all in supporting something like PA Risc, m68k, cris, etc as configurations of the generic code.
He also speaks about OS platforms: how complaints about things not working on AIX are stopping GCC development. In 2005, it's AIXs job to conform to the LSB (including GCC). Not the other way around.
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?
and was given to Scott in a dream.
McNealy: The lady of the lake, her arm clad in the purest shimmering samite....
H1B coder: Listen, you can't expect to write cross platform stuff just because some water tart threw a compiler book at you!
For example, is Linux in the majority or minority? Depends on what you class as Linux. If Linux is the kernel, then what group of kernels are you classing as the "Linux" of today? Surely you can't include them all, as the gap between 2.6.x and 2.4.x is staggering, never mind the gap between 2.6.x and 2.0.x, 1.y.z or earlier.
Now, are you counting the BSDs as one entity or many? Do you include ONLY the "free/Open Source" BSDs, or -ALL- BSD-derived kernels?
If you are dividing by standards, then does Linux count as a POSIX or Unix98 system, or are those part of the minority? But if they're part of the majority, then even those which are in and of themselves "minority" would surely have to be counted, as they are a part of the majority nonetheless.
Last, but not least, I suggest Ulrich retake Software Engineering, as although he is undoubtably bright and talented, he seems to have forgotten the basic rule of design -- the platform comes LAST.
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)
Java servlets outperform CGI
True, some people might have got Java technology to work fast on the server side. But do they outperform native code on the graphical client? And does Sun provide support for Java technology on anything beyond Windows, Linux, and Solaris on x86, itanic, and sparc?
"Not exactly a "minor" platform there now, is it?"
In the article he states that porting to Windows can cause issues due to case sensitivity, security, etc. The author appears (to me at least) to be putting Windows in that catagory. Not that it's 'minor' but that it's a pain in the ass. My contention is that I believe that, most of the time, it is worth porting OSS projects because it leads to greater acceptance to other platforms like Linux and the Mac.
"...Well, there's egg and bacon; egg sausage and bacon; egg and spam; egg bacon and spam; egg bacon sausage and spam..."
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.
Many software projects are unable to take advantage of modern C++ features because they want to support all sorts of old compilers.
I'd prefer to see some projects reduce their support to (for example) GCC 3.4+, the Intel Compiler, and MS VC 7.1+ (in strict mode). The three of these are very similar and all are highly conformant. Supporting just these three would be much, much easier than supporting a bevy of older and stranger compilers.
Well, it's certainly not harmful to those minority platforms, or their users/developers. Or the people who benefit indirectly, like app/kernel development by those people which get patched back into the kernel, or just compile/port easily to the majority platforms. It's a cost to people who have to work on development for them, but they do get some benefit. Without an actual accounting, counting the benefits for people who do even occasional work on the minority platform in a familiar environment, it's just whining. A fragmented platform is obviously bad, while a unified platform across architectures offers critical mass, diversity of innovation and insights, and is probably worth the extra hassle.
--
make install -not war
Since many n00b kernel hackers are intimidated by the sheer elitism of the "Core kernel hackers" on an open source project, I think that many people can (and have) learn a system by working on bugs related to obscure platforms.
It allows the person to solve a very domain specific problem, without getting trampled on by 10 other people working on the same issue.
If someone had a senior high school project, would you say "rewrite the kernel locking scheme", or "make this operating system run on a game boy". clearly one of those is more attratictive, and can breed future kernel locking scheme developers.
10 LET M$="Microsoft"
20 REM Please don't mention Penny Arcade until you try fitting "Microsoft" into the subject line
but rather the practice of trying to support completely alien systems that don't implement the common interfaces you normally depend on. This kind of "portability" often results in a huge festering pile of kludges and massive duplication of code. A popular example is MS-DOS; many packages end up with ".bat" files duplicating their makefiles, use painfully awkward filenames to avoid upsetting 8.3 filename restrictions, have special cases for MS-DOS scattered throughout the code, etc.
True, making an app portable between *n?x and Microsoft's "finest" used to take a lot of convoluted bullmanure to get right, but Windows 4.0 and up (95, nt4, 98, 2000, me, xp) have cleaned up. The file system supports file names longer than the Mac ever did. Developers can use MinGW+Msys, a reasonably complete port of the GNU compiler toolchain (yes, including GNU Make) to the Windows runtime library. And the popular Free GUI toolkits from *n?xland (wxWidgets, GTK+, and now Qt) are available on Windows as well.
if I read this correctly, we shouldn't let a minority opinion dictate terms. fine. so when a majority of senators want to vote, 40 shouldn't let them dictate. okay. i'm with that.
My problem? I was perfectly gruntled, until some numbnuts came by and dissed me.
Porting poorly written software is a problem, but the problem is with the software, not the port. Something like apache is a mess due to #ifdef _WIN32 shit for the windows port. That's because the core software isn't modularized enough, not because porting is bad. Hundreds of apache bugs were found thanks to the win32 port, some trivial, some that could cause remote root exploits.
The other thing I thought of is the compiler and binutils, Drepper's land. I've been a close follower of these projects for a long time and there is a certain viscosity that they have to put up with. Far fewer people hack on the compilers than do Linux; frankly, it's substantially more difficult in a lot of ways. Does anyone remember Chill? It was a langauge that some how got mainlined, they added it to main and then nobody ever supported it; GCC carried that monkey on its back for several big releases before it was pulled out. I don't even know if anyone ever really coded in Chill as part of GCC, plus there is a way to do this, you fork just like the Modula-3 guys did, look where they are at now.. Your project is given more street cred when it's accepted as part of a larger project but you need to maintain your project, that acceptance doesn't end your ownership of it. I think a good example would be the Ada guys, they did a lot of work to get gnat running in gcc 4.0, ACT is supporting their part of the compiler. Ada isn't super popular but I'll tell you what, it's a supported language as part of GCC (and it's not half as bad as you'd like to think it is either..) You have any idea how many platforms GCC has dropped support for? Popular chips in some parts of the industry but since nobody supports them, they have to pull them out or they slow down the rest of the work. Last list I saw had some almost shocking chips in it that were being dropped as I know that there is a ton of work being done on them all of the time still in the embedded world. It's also ironic that he singles out IBM and AIX because they have contributed some substantial pieces to GCC and both they and Apple seem to be pretty active in support of it.
glibc is no different. First off, it's not "sexy work" in the conventional sense, I know that they don't have hundreds of people providing patches like Linux does. There aren't that same handful of guys ready to take over if Drepper doesn't want to do something. Second, because it's so close to the kernel it creates a major test headache. Someone put glibc on BeOS, who cares? Should that code live with glibc now? It's prime for branching out on its own, it will live if someone wants it to. Should he hold up glibc 3.0 because it doesn't quite work right on EROS or Spring or beos or some other project with all of 10 users? I think the thing to do is to formally acknowledge that the branches to support minor platforms are just that and acknowledge that they aren't main stream. If you want to be mainline, then you step up and provide mainline support; you earn it, you don't simply get your code in and then orphin it.
When I first really recognized the power of opensource and how things were being developed, I was at IBM, I was learning OS/2 in the early 1990s and there are all of these really wierd tricks. OS/2 doesn't have a base 10 timer interrupt because DOS didn't because some PoS PIC back in the day ticked 18 tim
the basic rule of design -- the platform comes LAST.
"The platform comes last"? Tell me that when you develop a first-person shooter of the scale of Bungie's Halo 2 or Id's Doom 3 and are then told a month before release that you have to make it run in real time on a system comparable to the Game Boy Advance (16.78 MHz ARM7, 384 KiB RAM, 2D sprite acceleration, 32 MiB max ROM). Sometimes you need a little design-time optimization.
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.
By the same token, doesn't this indicate the need for the software is there?
Mod me down with all of your hatred and your journey towards the dark side will be complete!
only harms the project if the number of programmers is limited.
Which is not always the case with Open Source.
So by the logic of this article MS should not bother porting Office to Linux because it's a minority platform, same goes for Adobe Photoshop etc.
And web developers should not bother making their sites work with Firefox, because we all know IE is the only platform that matters.
I don't think this attitude is helpful. Maybe limiting the amount of porting might made development a little easier, but the language of the author was more elitist that a simple pragmatic argument.
I wasn't sure if he was arguing against porting software or against the Americans with Disabilities Act.
Writing portable code is good for the soul.
But is it good for the market? What is graphically feasible in a PC game isn't feasible in a game designed for a Palm OS device or a GBA system.
into functions or methods.
Makes things much easier to maintain.
That would be the case, if we were talking about higher level code. But Ulrich works on glibc, and at that level, you can't just write portable code to pretend the platform differences don't exist - he's the one who has to deal with those differences so that application developers don't.
Incidentally, OpenGL is a bad example, btw, since it's a specification, not a piece of code. It's ubiquitous because people have provided implementations (like Mesa) for many platforms, not because SGI's original codebase was especially portable.
Apart from the paid effort by programmers supported by companies, all effort on FOSS is volunteer.
;-)
It would be hard to convince a volunteer that decided he would fix the NetBSD on Alpha port of Evolution (I don't know if it's broken - it's an example) to work on fixing the more relevant Linux on AMD64 port (which I also don't know if it's broken).
Donated effort cannot be wasted.
I would suggest, instead, abandoning Red Hat, which is not my prefered distro, and diverting all resources from it to Debian, which is highly relevant to me, so we could all live together in happiness and not waste our efforts on that OS named after a hat.
OK. Don't shoot. Just kidding.
http://www.dieblinkenlights.com
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.
If your goal is to overtake the #1 application in use, you will want your project to be ported to multiple platforms.
If you want to provide a free quality product to as many people as possible, you will (again) want your project to be ported to multiple platforms.
The fact that 1 "minority" platform is troublesome might indicate:
- problem with code
- problem with platform
- problem with developer using platform
and it may very well mean that support for Windows or BSD or whatever is not feasible for YAOSA. (Yet another open source application).
Why? Because it's hurting FOSS and Linux. Sure some projects are also successful in windows, like Firefox. But how many users switched to Linux because of Firefox? Very few, if any.
/. 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?
Porting to windows hurts linux, and not just because of the development delays. The value of an OS is how many and what kind of apps run on it. Now if almost all FOSS apps run on windows, windows has an advantage over linux. It runs FOSS apps plus many exclusive apps for windows which cannot run on Linux.
So you talk to someone about 'x' FOSS app and you get "So what if you run 'x'? I run 'x' too on windows. Can you run my proprietary 'y' on linux?".
In a previous
I'm not suggesting FOSS projects to stop supporting other platforms. But maybe they should stop supporting proprietary platforms, like MS Windows. I think overall, by supporting windows, they are damaging FOSS and Linux and eventually their own projects without realising this is happening. I wish people stop thinking about short term gains(like quick adoption of their app) and sit down and think what's the big picture.
Obviously windows fans won't like this post and it might get modded down. Oh well...
VStrider.
"But is it good for the market? What is graphically feasible in a PC game isn't feasible in a game designed for a Palm OS device or a GBA system."
OTOH, the vast majority of Linux software is easily portable to all UNIXes.
For example, I strongly suspect most machines big enough to run AIX can handle GCC.
I rarely criticize things I don't care about.
In that case, perhaps they should only make a Windows version. Why bother with Linux? This is silly.
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.
If they can't run these awesome programs at home?
...) can be kept in their place. Compatibility is a new ball game. Being the overpriced player is a position they've always reserved for their competition.
Seriously, there have been hundreds of first-class programs that lost out to Microsoft not because they were bad but because people couldn't run them. Because they weren't installed. Because they cost too much money.
When people wake up to find that all the programs they use are free and they all run better on *nix, then they will feel comfortable enough to let the neighborhood geek/BigBucks computer company set them up with a libre OS.
MS is betting they can prevent this dream from occuring by locking down MSWindows before OSS gains public mindshare. They've proven for nearly 20 years that elite minorities (the fruit co, the star co,
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.
The bugs due to platform bugs -- well, knowing about them helps improve the platform.
...
Not if your platform is AIX, or HP-UX, or
There are some platforms that steadfastly refuse to do anything but suck.
If you want to keep Open Source portable, then you need people to actually try it on other platforms. I have the impression that portability has been a sinking ship during the last ten years, while OSs became more similar than ever.
If you want to use GNU on Windows for example, you are mot probably stuck with Cygwin. Cygwin however is not really porting the software to windows, but emulates all the features that Windows lacks. This however is slow and results in quirky program behaviour. Moreover their version of gcc breaks some stuff that is fine in the main branch which is quite sad, because gcc is designed portable enough to run on Windows without being lobotomized.
I think the support of minor platforms will enrich the software world. Having just another million devellopers who try to make Linux look like Windows will not.
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?
Not at all. For one thing, the "major software" people complain about is commercial software--people are being paid to design and write it--while most open source projects are simple free-time hobbies. Why should someone creating software for fun feel pressured to support a platform he doesn't want to?
For another thing, supporting Windows is in an entirely different class than supporting BSD/Solaris/m68k/x86-64/etc. For all their differences, BSD, Solaris, and all the other Unix-lookalikes share an overall operating paradigm with Linux--the "everything is a file" concept (device files, named pipes and the like), or the use of shells and pipelines, for example. Windows is very different, and supporting it properly (i.e., not using Cygwin or the like to immerse yourself in a Unixlike environment [*]) is something on a completely different scale than dealing with other flavors of Unix. Writing code to be that portable is an order of magnitude more work than writing it to work only with Unix-like systems.
I do agree that code which is intended to work on "any Unix-like environment" ought to be designed that way from the start, not relying on things like the size of an int or a particular filesystem layout. But "portablity at any expense", like every "X at any expense", is overdoing it.
[*] If being able to build on Cygwin is enough for you, then by all means add support for it, but I'm of the "if you're going to do something, do it right" belief.
You are right to some extent. Many previous slashdotters said that too. From my own experience - we have discovered many memory-related bugs quicker just because we had a Solaris port and memory layout is different.
As a submitter of this story I am partially at fault for misunderstanding, because I wrote about "bugs". I wrote more extensive blog entry on that, but main point is that there are two many differences even in close platforms. So to actually write a cross-platform code you _must_ know peculiarities of each platform.
I mean, just look at APR or NSPR. Several examples:
- Dynamically loaded libraries. Even Solaris and Linux different, let alone HP-UX and Windows
- Taking care of endianness independence presents additional burden
- Case-insensitive vs case-sensitive file names
- Different forms of line feeds (I am aware of 3 (three))
- Path separators, separation of path elements in PATH.
- Even Linux distros have different layout of configuration files and startup scripts. If your application has to deal with that - you are in trouble. Let alone Solaris, HP-UX, AIX, whatever.
- System utilities sometimes have different set of flags
If this is not enough, try to look at the output of some non trivial autoconfigure script!my sstream of consciousness
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".
Why should anyone support ports to Mac OSX or Linux? After all, they are a tiny fraction of the platform market.
The same goes for hardware platforms. Why support anything other than x86?
This redhat employee is sounding suspiciously like what I would expect a microsoftie to say.
...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
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, and perhaps more importantly, they keep a very stable version of it widely available. So if I ever came across an old UltraSparc or something, I'd just be a download away from having a working OS on it. (In theory.) Or if I want an absolutely-stable but not cutting-edge OS for a router or embedded system, I know exactly where to go also.
But this all occurs at the cost of development on the main-line branches: the Intel/AMD and perhaps PPC architectures with high demand are 'subsidizing' mostly inactive minor architectures. The question is whether the fringe benefits of those minor platforms--including the simple fact of being able to say that Linux supports them--is worth this diverted effort.
"Ladies and gentlemen, my killbot features Lotus Notes and a machine gun. It is the finest available."
>The file system supports file names longer than the Mac ever did.
This is not correct. Mac OS 9 and Mac OS X support filenames that are 255 Unicode character in length. Mac OS 8.6 and earlier had the 31 char filename limit.
Hyperbole is the worst thing ever.
Any effort to make the user interface and utilities unrelated to the underlying system will surely do this, to an end better than anything else.
Supporting different operating systems is a bitch, but the rewards are worth it no end.
OS/2 - because choice is a terrible thing to waste.
Grammar nazis are the most pathetic lifeform on the planet. Please go back under the rock you came from.
I never much liked this guy, from what I've read about him. He seems to go off in a lot of hissy fits and has some unusual opinions about the future of Linux, of glibc, and of what their priorities should be. Just an all around head case.
So, yes there is more work, but a lot of that is really just front-loading the process of bug-squashing that's better to be done at the front end anyways.
I think that, to an extent this is a case of confusing the symptoms and the underlying cause. Sometimes, for example, taking Tylenol 3's can cover up a headache. This may seem good, but if the end result is to hold up tracking the underlying problem (say, a brain-tumor) until it causes serious complications, the long-term result of supressing the symptoms is actually negative.
Free Software: Like love, it grows best when given away.
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.
A proposal for the new millenium that article was, wasn't it? "Let's not write portable code! Let's give up even trying!"
While the Linux Standard Group and the Open Group work together to solve any LSB and POSIX glitches, here comes this RedHat guy with the bright idea.
If you write software for Unix you should be OK, shouldn't you? People have been doing it for decades. At least, that was the impression little old me was under.
Now, I'm sure RedHat has this little strategist amongst their ranks. He wears a...red hat, because it gives him bright ideas. For instance, one of their strategic ideas is: not care about Mono, because it's SuSE's thing, so they can go after SUN's spoils using Java, a proprietary platform. And now this new one: let's break everything! Let's make thing go "bump" in the nightly builds!
After all, there's sooo much that was just Linux software, like OpenSSH, right? Oh! I forget! That was from OpenBSD originally! Gee!
Ah...these little strategists with red hats...
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
THIS THING CAN TURN ON A DIME, MACROSSZERO STYLE ALSO FUCK BETA, ~NYORON
If you bothered to find all the bugs in Linux and remove them, you'd have no part of Linux left. Good luck with that.
If Glib didn't support every architecture and every OS under the Sun, it wouldn't be such a joke, and might even be understandable.
As it is, GLibC is pretty much a joke - the pinnacle of crazy complexity.
I track development of The GIMP - it just compiles fine in all "strange minor platforms", and a recent chain of Bugs in Irix compiling was resolved overnight - a matter of the Irix user reporting the bugs, and the core developers commiting the fixes.
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.
-><- no
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
/* note: it seems all my today's comments will be titled BS :( */
:), fame :), appreciation from the "minority" users, etc. And think, Linux today, in some form, is ubiquitous, meaning realtime systems, embedded systems, pda's, development boards, general-purpose computers, control systems, etc. If you think all these don't mean portability, you're wrong.
As always: some big player (or at least thinks it is) starts bashing something other do but he doesn't have the capacity, will, resources, etc. to do. Support of "minor" platforms has always been one of the many strengths of Linux ! Now some pongo comes around and thinks better. Oh, get lost.
I can certainly understand the extra work and resources and knowledge needed to concurrently support multiple architectures - think debian as a classic example, though they also started dropping some -, still, the benefits can be huge: bug discovery, nicer design, easier portability (yes, given portability makes further portability easier
I am putting myself to the fullest possible use, which is all I can think that any conscious entity can ever hope to do.
Java also runs on Macs. Hell, there's even Java for Amigas and OS2, but don't let any FACTs get in the way of your FUD.
And since Windows, Macs, Linux, Solaris covers about 99% of the computing in the world, that's not exactly non-portable.
And ANYONE can produce a JVM - the spec is open for anyone to create. Sun don't have to do anything to allow that (you did notice that Apache are producing a FOSS JVM, didn't you?)
If you don't like Java, don't use it, but quit lying about it.
Porting code to other platforms often helps expose bugs, such as where a programmer assumed that a pointer will always fit in an int, or that a machine word is always an int. The reason that Windows XP took so long to port to AMD64/EM64T is presumably because there were a *lot* of those sorts of assumptions made in the Windows codebase.
C++ long => 32 Bit
;)
Java long => 64 Bit
So you are comparing Apples with Melons
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.
Time spent porting software to run on a gameboy may not be the most commercially viable opportunity but you must realize that this is of little concern to those who achieved it. Most open source software is born out of a "Wouldnt it be cool if..." concept. Some might say this is a very narrow view but think of it as it relates to some major projects and you can see it has far more depth than it would orginally seem. For Example: Wine: Wouldnt it be cool if all this windows software would just work on linux Firefox: Wouldnt it be cool if we could make a supperior browser and make the internet based on standards Gaim: Wouldnt it be cool if we could talk to all of our friends which happen to be using 5 different pieces of IM Software Bash: Wouldnt it be cool if we added some functionality to this 20+ year old shell so people dont have to type so much stuff Now admitedly some open source projects cant fit this mold but a great many do. I developed a modified version of the vnc java applet with a lighter interface on the rational that: Wouldnt it be cool if clients didnt have to see lots of garbage they done need. I later merged that with a ssl enabled version because I thought it would be cool if it could be easy and secure instead of the original tightvnc applet which despite being a quality piece of code is insecure and too compilicated for the average user Im not sure if anyone will even read this because the story isnt top anymore but ill check back 2mor0
This article trys to talk about something that not necesary happens always. A couple o months ago in some thread there was a discusion about the release cicle of Debian and how it seems afected by the multiple plataforms that it's supports and somebody else name NetBSD and how it support more plataforms and has a short release cycle.
As NetBSD, there is OpenBSD, and the filosofy of "porting is bad because it leave an open door for bugs", thats the why of the -p releases.
>Linux is not user-friendly.
It _is_ user-friendly. It is not ignorant-friendly and idiot-friendly.
NTFS has supported filenames 4095 characters (UNICODE characters, not bytes) in length since version 3.0
If you write your code to be portable in the first place, fixing platform-specific issues should be quick and easy.
Bull. This guy is one of the main GCC hackers. GCC is a compiler, damnit. It doesn't get much less portable than that. Yet GCC runs on a huge number of platforms.
But that has not come quickly nor easily. Or are you claiming that GCC isn't written with portability in mind?
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..
Lack of windows support in GCC has little to do with hating windows and a lot more to do with a lack of developers on windows.
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?
And where did Ulrich complain about major software not supporting Linux?
My take: Port your software to every platform you can, especially Windows.
Yeah, it's easy to tell others what they should do when you're not doing the work yourself.
I hate to break the news to Mr. Drepper, but Linux is a "minority" operating system! It's not mainstream. This isn't a troll, it's the truth.
If the goal is to replace one monopoly with another, then he would be correct. But that's not the goal folks! The phrase "word domination" is joke, and you're too stupid to get it! One of the chief attributes of Free and Open Source software is choice. But Mr. Drepper doesn't want choice. Democracy is nothing without a choice of candidates. Freedom of religion is nothing without a choice of belief. What good is freedom of speech when there's only one microphone?
I'm a longtime user and advocate of FreeBSD, and his article suggests to me that Linux cannot compete anymore with other Open Source operating systems. Is that really what he thinks? Wouldn't you Linux advocates rather Linux stand on its own merit?
What is it with Redhat that it ends up with all these arrogant people? I haven't used Redhat in six years, and with the way things are going, it will be at least six years before I even consider trying it again.
Don't blame me, I didn't vote for either of them!
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.
Microsoft think portability its for canoes.
Hes wrong.
Portable code its often much better than non-portable for a good reason:
- Can't use system dependant hack's to work.
-Woof woof woof!
Considering this guy is the maintainer of glibc, arguably the most important userland package on Linux, I think it's fair to question: is this guy's C really any good? Because honestly, the guy has some messed up opinions on software.
> non-mainstream (read "non-Linux") operating systems
Ha ha! Linux as 'mainstream'! Oh man that's too much! I needed a laugh!
Whilst it wasn't formed very well, I got the impression he may have been talking about some distros and software projects' goal to have everything running on many different platforms BEFORE any single platform gets it working and released. I think there's something to be said for independent groups to maintain platform-specific bits and merge it into the core of the project or distro after being rigorously tested... The end result being 1. a release may support a feature on x86 weeks or months before it's supported on ppc (but at least we get that feature) and 2. the software stays stable while the ppc stuff is written and tested away from the official or stable releases.
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.
Yes, because they package a truckload of upstream stuff. You know, a truckload of stuff that works.
Not just some obscure barely usable BSD lookalike base system with half working ports.
Alright now, BSD zealots, mod me into oblivion, but I've really been there. ;-)
Just one nitpick: you don't have to "pay microsoft $$$$" to get a compiler. Just download it, it's free.
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.
I agree, there are also some problems with openssl using the wrong method for guessing which architecture it is running on, which means you can't compile it under UML 32 bit guest on a 64 bit host (it tries to build it for 64bit guest). /proc filesystem is restored in 2.6 uml), not nice!
That forces me to use a linux32 chroot and take the virtual machines down for the upgrade (at least until the fake
TODO: 753) write sig.
The last time I heard a programmer talk about a subtle bug he used the word to hide the fact that he _should_ have seen that bug way before the product even reached integration testing....
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.
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.
In the bad-old-days, there were a zillion hardware manufacturers, each with a tiny little quirk in their own hardware. Software had to get around this. Even when they were given common, standard protocols, they would put in their own quirks. Over time all of these minor annoying quirks got squashed. Now, box x works extremely similarly to box y (even down to very picky details). The point is that extremely well written software works above the hardware detail. The hardware detail is in the architecture support layer. Each chipset (SiS/Intel/VIA/) manufacturer makes theirs work in most cases much like other verdors, with speed/performance being the major difference. So in some respects we've gained, and in some we lose. Drivers for common hardware are much more reliable as there are fewer quirks to deal with. On the other hand, radically different hardware (non-PC), is still a challenge.
Lets say we are on gcc version x and that it just happens to work everywhere.
Everyone is happy and all the platforms are working as they can.
So, gcc re-ups to version x + y and some things break.
It takes time for all the software to get recompiled, the version x of gcc is still there for everyone to use, etc....
So everybody that has an interest in gcc for their particular platform does their testing, patching, etc...
In the end, those that really need to use the compilier can either build on the stable version, or put some elbow grease into the latest version. Whatever floats their boat.
Of course there are going to be special cases, but the code is open right? Those that really need the latest features are empowered to do what it takes to use them just as those that don't care can sit back and deal.
As long as there are people willing to contribute to gcc for their platform of choice, support for that platform will continue to exist in some form or another.
It all comes down to interest. If hyperthreaded keyboard support (LOL) is the shit, you can bet folks are going to get the work done to put it into action. Those applications that can benefit are going to change as well.
Another posted talked about the m68k support. There is plenty of interest there if you are an embedded developer. Older platforms like this are stable. They can use stable gcc versions for longer than newer platforms and applications can.
My point being, there is plenty of time for everything to work out.
Blogging because I can...
That comparison is useless
- the testcase is much too short to measure performance rather than startup time.
- you forgot to use any optimization/tuning options
- you compared one C++ compiler against one Java
implementation. You would have to try multiple
vendors' compilers, and multiple vendors' java
implementations, to exclude implementation
specific performance issues.
Thomas
Usually platforms like CATS or coruso get pushed back to the developers that really care about that arch while the majority of the work gets distributed to the general purpose developers.
Porting to minor platforms is good because it allows them to compete more fairly against monopolies. Here is my blog post on this.
Please do not port software to Windows!
Why don't open source projects just concentrate on producing something for one or two operating systems, and let the people who use and program for the non-mainstream operating systems write an emulator, much like Wine?
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
You should go take a look. A good 30% of the code is written in pre-processor. It's like a bad episode of When Macros Attack!
One of the reasons " NetBSD does a surprisingly good job of keeping acceptable code quality while retaining support for many platforms" is that this forces them to write clean code with well defined interfaces.
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]
Ah yes, the minority is considered harmful. Tyranny of the majority, or is the elite really calling all the shots?
OpenSSH is one project where the coders won't fix a problem that's pointed out to them. Unless one is able and willing to produce a patch against the exact current software for four years in a row (therefore doing all the work for them), the problem will never be fixed. As the elite (or as they would like to call themselves, the "majority") would have it, those in the non-elite or "minority" who find the problems could just go to hell. The coders can't be bothered.
This couldn't possibly be a case of payback time could it? Judges with a political axe to grind? As for boycotting Indonesia; I never did, and still do not, have any desire to ever visit that place. Does that constitute a boycott?
Because the earth physically cannot support our continually buying and throwing away computer parts. There're more costs than monetary ones to computer parts. There's a finate quantity of resources to keep producing new motherboards and CPUs. Maintaining software support for older and exotic technology is actually the cheaper option.
Umm sorry, what?
i) Ports (as in architectures):
NetBSD has never put its name to an architecture it didn't fully support. This is probably because there is still integrity in BSD OSes - the name, BSD, actually means something, not like the vast multitude of splintered, disparate efforts (distros) that have homeopathically watered down the quality of the product. 3 BSD distros. 1 for performance, 1 for portability, 1 for security. These aren't virtues carefully pinpointed to selected user spectra by the marketing department of some company that continually puts business ahead of technology. Contrast with e.g. Xandros OS, RedHat, Mandrake or (although not directed by a big business) Scientific Linux. No, believe me, if you were referring to this definition of the term 'port', you can bet that NetBSD wouldn't brand as supported some architecture it would not fully stand by 100% in a grab for 'customers'.
ii) Ports (as in software):
If you have ever even used a BSD OS, the ports tree is nearly idiot-proof. Everything works in the most logical, clean and consistent manner out of any software distribution system I have ever seen. Not just me, but anyone else who uses a BSD OS be they programmers, admins, engineers, scientists, financial analysts, academics or security people would all agree.
Alright now, BSD zealots, mod me into oblivion, but I've really been there.
And here is where you are wrong again:
iii) There really aren't any "BSD zealots". We're all resigned to the fact that slashdot doesn't give us the same air-play as any Linux news and that ignorant people give us the old "Netcraft confirms it". It really doesn't matter, we have more important stuff to do, and the superior tools to do it that we couldn't give a shit. Our stuff works, we don't need to defend it, we don't lock our users into any odd legal traps and our system is not encumbered with the unrealistic promises of some cult of hyper-caffeinated teenagers excited about Free Software.
Umm sorry, what? i) Ports (as in architectures):
Yes. The name implies existance of some base system which is somewhat similar between different BSD branches. Good if you want to make a router out of some toaster in case of NetBSD, nothing much of anything else.
Debian on the other hand provides a truckload of packages which actually work on supposed architectures. This is a lot of work which grandparent so easily dismissed.
If you have ever even used a BSD OS, the ports tree is nearly idiot-proof.
Sorry, you are wrong or trolling. I am using and have used different branches of BSDs on servers, and QA of ports tree is nothing compared to Debian quality.
It is somewhaot alike Debian's unstable branch and I'm actually being kind here.
Everything works in the most logical, clean and consistent manner out of any software distribution system I have ever seen.
Well, then you didn't see a lot, did you? I'm supporting, uh, some number of servers. Debian machines constantly give me less trouble, are updated more easily (keeping software installed from ports up-to-date tree is a nightmare, thank you very much).
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.
iii) There really aren't any "BSD zealots".
Yep. That's exactly why you have added this righteous paragraph about superiority of one platform over another. Insecurity? Zealotry? You name it. ;-)
Look, BSDs have their strong points, e.g. making a router of a toaster is NetBSDs best job. Debian or other linux distributions have their weak and strong points too.
For example, lack of coherent "base system" comes to mind, but it is more of a difference for some guy with BSD background, actual weakness is arguable here.
And pretty please, don't try to label me as a Linux fanboy. Or Windows fanboy. Or whatever fanboy. I work with different unixes on a daily basis, Linux is just one of the tools to make the job done.
I have entered this discussion only because of grandparent highly dismissive opinion about Debian project's efforts which was modded up to eleven, maybe by those zealots which you say don't exist, I don't know. I showed him another opinion, which was somewhat dismissive too. The truth, as usual, is somewhere in between.
Well that Redhat guy can whine all he wants about that but it is one of the great aspects about Linux. I don't use any of the "non-mainstream" hardware but if I did, I would be concerned (somewhat) about this guys rant. Ok so maybe he does have a point there about lesser known hardware having more updates than say, the x86 platform. Big deal, so what? Maybe it's because the x86 platform code is pretty much up to snuf and the others are just catching up. So what or who gives this guy the right to instigate (it's what he's really doing) the dropping of non-mainstream support? He is certainly free to speak his mind but that mean he is right. Seems to me he is starting to suffer from the corporate mentality. Close off all that does not support them.
My karma is not a Chameleon.
I mean, really, every time I've installed a new Linux box where it's mattered what version of Linux it is, it's HAD TO BE Red Hat. Not just that, it's HAD TO BE some particular version of Red Hat. And every version of Red Hat (or Fedora Core, or whatever it is these days now that Red Hat itself isn't free software any more) has required a new learning experience. Sometimes the installer hasn't worked because I was using "minority" hardware like Adaptec SCSI controllers and Red Hat only used Buslogic internally. Most recently, I have had to hover over a RHES install so I can whack the "reset to factory defaults" and "recalibrate" button on the flat panel displays we've been using in our equipment racks because their GUI installer starts up in some nice high-quality display mode that these LCDs don't *quite* support... so until I get to X11 configuration and reset to 1024x768x60 Hz every time they restart X11 the display freaks out.
I mean, OK, 85 Hz looks better, and having the installer load drivers from the CD lets you make the installer kernel a little smaller, and RPM... no, don't get me started on all the different extensions to RPM and the contrast between the BSD ports system and the RPM scavenger hunt.
It sure would be convenient for Red Hat if open source software people stopped supporting minority hardware (though there are more people running UNIX on Power PC desktops than any of the myriad x86 almost-compatible ones), minority operating systems (though this is the first time I've seen Windows described as a minority), and next I'm sure it'll be nice if they quit bothering about minority open source platforms like BSD and Darwin (even though there are more people running THOSE now), or minority versions of Linux like Gentoo and Slackware... and, hey, who needs Suse and Debian...
And then this:
Companies like Sun and HP have for far too long survived without providing a decent compiler in the default configuration since there was always gcc.
I don't get this at all. GCC is not a bad compiler, but it's not great. It produces good code these days on x86, but native compilers produce better code on most platforms. That's why I've only ever installed GCC on Tru64 when I've had to for some particular program. And I've never had any difficulty writing code that ports between C compilers... I've got code that I wrote on the PDP-11 in the early '80s that compiles and runs on just about anything today.
But then I don't use incompatible non-C extensions that were added to GCC and act as a Microsoftian "barrier to entry" to other compilers, like "a = b ?: c;". Oh, it's a perfectly logical extension to C, but only GCC accepts it.
This article... change a few words around, and I can imagine it sitting on "Monoculture Central" -- Microsoft.COM. It's the same argument that commercial software developers have used for years to explain why they don't support Linux. Now a few of them are supporting Linux, but only Red Hat. If I want to support a software monoculture with a good UNIX environment, I sure wouldn't pick Red Hat as my monoculture of choice, not when both Apple and Microsoft give me one for free on their proprietary but well supported platforms.
Whilst Red Hat surely want all open source developers to concentrate on Linux, lets
not kid ourselves. Windows is more "mainstream" than Linux, so shouldn't all open source development be concentrating on Windows?
Of course, you could recognise this for the load of crap that it is, and continue porting software to whatever OS you wish to use it in....
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!
So you talk to someone about 'x' FOSS app and you get "So what if you run 'x'? I run 'x' too on windows. Can you run my proprietary 'y' on linux?".
That's a perfectly good argument. And one you're not going to counter by declaring that "we" (whoever "we" is) should quit supporting Windows. Because the argument that supporting "minor platforms" is a waste cuts both ways.
That's also the argument that I've been given for using Linux rather than BSD, because there's more proprietary software available for Linux than BSD. And for that matter, using Red Hat rather than Gentoo or Debian, because Red Hat supported the proprietary software, or the proprietary software vendor only supported Red Hat.
You can't have it both ways. If the added value of Red Hat is that it does a better job of supporting proprietary software, and supporting proprietary software is hurting FOSS, then Red Hat is hurting FOSS software by being an easy monoculture target for proprietary software.
Meanwhile, I'll keep using my minority-platform BSD based minority-platform Mac with its minority-platform PPC processor that's got more free software than Windows and more commercial software than Linux.
The API differences on Windows are mostly handled by Cygwin and mingw.
Or by Interix.
Interix is the best sign so far that Open Source has won. Microsoft is shipping, for free, a UNIX subsystem based on Open Source software... including GCC... that provides an environment closer to standard UNIX than any UNIX emulation under Win32 can. Because it IS a subsystem.
Let's repeat that. Microsoft is shipping a package specifically to let people run Open Source software better under Windows. Microsoft is shipping the "evil", "viral" GCC.
"First they ignore you, then they laugh at you, then they fight you, then you win." -- Ghandi
Open Source has won, people. Oh, you never win "for good", you can't stop just because you won, but... damn.
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.
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
But is it good for the market?
Absolutely.
Because portability doesn't just mean portability to "minority platforms", it means portability to newer and older versions of your own software as well.
One of the reasons I use FreeBSD instead of Linux is because I can depend on FreeBSD being careful to avoid breaking things, and I can depend on Linux deliberately breaking things. And I can depend on Red Hat being in the forefront of the breakage.
We're not talking about the difference between a Palm and a PC here, we're talking about the difference between systems that are all using the same basic API with the same basic display and hardware. Even the difference between Windows and Linux pales by comparison with the difference between the platforms I started working with.
If the small amount of care that's required for portability between different versions of UNIX is too much work, then we might as well give up and embrace the monoculture and switch to Windows today.
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.
Actually open source should be for all !
Chris ,
Php Programmers.
What, and what some codemonkey inside of freakin' RedHat says is supposed to be "right"?
- it is NOT our fault their code is *CRAP*.
- it is NOT our fault their code is developed on a POS OS made by amateurs for amateurs -- Linux
- it is NOT our fault that they're too lazy to fix the bugs and that they don't HAVE ENOUGH KNOWLEDGE to write BETTER CODE on PROFESSIONAL PLATFORMS.
His arguments is a pure excuse! Another FREAKIN' AMATEUR POSING AS A PROFESSIONAL.
I'm so sick of these actors. That's why professional system engineers have to work overtime, cleaning up after somebody else's mess.
Damn amateurs.
I call BULLSHIT!
Seconded!
My first job, ever, was porting software from one version of COBOL to another. I was working for the company who'd written both COBOL compilers, and manufactured the hardware both ran on, and both operating systems, and there was only one section (a check digit routine) that wasn't simply a matter of the original code depending on some laxness in the original compiler and simply cleaning up the code fixed all the problems. One routine needed to be rewritten, the rest were already bugs in the original code.
And this was in an environment where the differences between the operating systems were so radical that they made Linux and Windows look like twins.
This has been my experience ever since then, no matter what the language, no matter what the hardware. Most portability problems are bugs that haven't been found yet. My first C porting nightmare was porting my own code from the PDP-11 to the VAX and discovering that (long) wasn't always longer than (int). Porting Elm to Xenix-286 was mostly a matter of finding all the places the authors had forgotten that integers weren't always 32 bits wide.
As others have pointed out, my experience also supports that porting finds subtle bugs, undocumented assumptions and generally is a -great way- to improve product quality.
Besides, as the long-time user of minority platforms, Open Source has been part of the antidote to the computing monoculture of incompetence that wafts from Seattle Suburbs...
dave
Also, unless you use things like cygwin, your app which compiles and runs on multiple unixes quite happily will require extensive modification to run on windows, the graphical interface especially is very different from X11.
That's why I write so much code in Tcl/Tk, because the same code runs the same way on every platform. When you write code for Windows that uses Cygwin, you're doing the same thing... but at a lower level.
You could probably eliminate most of the problems with locked files and case sensitivity by porting to Interix instead of Cygwin. Microsoft's actually trying to make it easy for open source software to run on Windows without modifying it for Windows. They're actually reducing the amount of Windows-dependency yu have to add to your application... why not take advantage of it?
Don't be too harsh on him. He probably just read some dated Chomsky material in his dorm room.
Trolling is a art,
More snappily we would say "tail wagging the dog".
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.
And its a piss poor argument. If the people at RootHat were better coders, they would start off writing portable code, the bug complaints would be less.
Wonder how he'd feel if code existed which was under patent protection and featured a license that said 'BSD Licensed for all platforms EXCEPT Linux as the ever changing Linux environment is hard to support'? Would he be saying "Oh, that is cool and not harmfull."?
Ulrich Drepper may want a world with just one Operating System environment - but how is that different than what Bill Gates wants? Oh, yea. Ulrich Drepper 'wants that one environment to be Linux' so that makes his wants OK.
*mumbles about how when one fights evil, one should be careful not to become that very evil you fought*
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.
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?
Are there any easy tools to do CPU emulation for something like that? I realized it'd probably be damn slow (you'd have to reverse the endianness of everything, do 64bit ops on a 32bit machine), but just so for testing?
Live today, because you never know what tomorrow brings
>If preserving the rights/benefits of the minority >becomes to high for the majority, the losses must >be cut
Yes, off to the code-cremetoria AIX
>Free software should only support free OSes and >even among those the group needs to be trimmed >significantly (ideally to one).
I guess Linux is turning into a racially pure blond haired OS, huh? I am guessing that the Jew Bill Gates is running a cabal to control all computers, huh?
I guess I wouldn't be as upset if Ulrich Drepper wasn't a German spouting this type of garbage.
By avoiding platform specific libraries and techniques I write better code.
You have libraries to choose from, good and bad. By restricting yourself to only the cross-platform ones, how can that subset be any better? Same with coding techniques. How can a subset of techniques be better? Yes, you write easily portable code, but the reasoning is circular: It is good to port software because it helps you build portable code so you can port software.
Certainly, with time spent porting you will find bugs. But you probably would have found more if you spent the same time reviewing the code. That is really the crux of it. For commercial software, it costs money with relatively little gain. For OSS software, it is extremely boring. Porting it may be a means to indirectly find and fix bugs without actually making the activity bug hunting, that is all.
Kjella
Live today, because you never know what tomorrow brings
I've never heard of Debian guys hacking on TCP stack, SSH, or creating somethiong like CARP to subsitute Cisco routers, or BSD sockets. Debian has thousands of so called developers.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
I didn't to a search on them but I've never heard of Debian guys hacking on TCP stack, OpenSSH (*), or creating something like CARP to subsitute Cisco routers, or BSD sockets. Debian has thousands of so called developers.
(*) Question is, did you write the original code and start the original project?
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
Unless you're one of those rare folks who jumped through the hoops required to return the license of windows that came with your computer.
Here's my computers and the operating systems that came with them:
Apple II, AppleDOS.
Atari 800, AtariDOS.
Tandy model 2000, MS-DOS 2.11.
Amiga 1000, AmigaDOS.
Amiga 3000, AmigaDOS.
Clone, System V/386.
Macintosh, Finder 4.something.
Compaq Deskpro, MS-DOS 3.something.
Amiga 1200, AmigaDOS.
Generic clone, used, no operating system (or even hard disk).
Biostar U8068 motherboard, no operating system.
Biostar U8668 motherboard, no operating system.
Powermac 7200, Mac OS 8.1
Powermac 7600, Mac OS 8.6
ASUS Motherboard (upgrade), no operating system.
Powermac G3, Mac OS 9.0
ASUS Motherboard (upgrade), no operating system.
Powermac G3, no OS or hard drive.
Mac Mini, Mac OS X 10.3
I do have a Windows laptop provided by work, and I've done some development on that, but I didn't get the copies of Windows on our "game" machines for "free" with the computer.
Use cygwin
No thanks, Interix works better.
Perhaps he meant users of a certain API?
Compilers are much greater "grammar nazis" than any human. Are they even more pathetic?
Since Win32 is "more mainstream" than GNU / Linux, lets just drop support for the latter in favor of the former....
I don't think this guy gets it. The developers write a program for a particular platform because they feel like it. If they don't want to support a certain platform, well, then they won't: as free software developers, they aren't obligated to.
AIX might not be important in your bedroom, but it is really important at the hospital I work at - it was a big part of the 200 million dollar investment they made to move to an electronic patient record.
This guy seems to think that Open Source guys should only work to support the platform. Unless your project is explicitly tasked to support the platform, then this couldn't be farther from the truth. The goal of almost every Open Source project is the project itself. Whether it is a program, dataset, compilation, whatever..... People have an idea, and they work toward fostering that idea. Not only does the platform not matter, but the more platforms on which the idea can be delivered, the better.
Maintaining a focus entirely on Linux x86 is as moronic as staying forever in WindowsLand.
There really aren't any "BSD zealots". We're all resigned to the fact that slashdot doesn't give us the same air-play as any Linux news (...) Our stuff works, we don't need to defend it
Exactly. And let me explain myself here: my comment was about the majority of Debian developers. This is not to say that Debian isn't a good distro. But they need to get their act together.
What angers me is people using the "so many platforms" excuse for the mishandling and mismanagement of Debian, because you look at any BSD project, and you see a lot more systems programming (and done right!) than in Debian.
These are the facts.
And BSD people know this. That is why you don't hear much about BSD. They don't care to advertise much, while Linux gets all the hype, because of the huge corporate backing. They also get a lot more of kernel exploits per year. Why management doesn't see this says a lot about management.
Debian, OTOH, is allowed to get away with ridiculous excuses. Once upon a time we, 3 guys and me, started a local Debian LUG. One of them was a Debian developer. To this day, I can't get over the moronic things this guy used to say. He couldn't even program a linked list in C, but his ego was so big you had to get out of the room.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
In the interest of promoting a good idea I hadn't seen explained in detail before, "strlcpy and strlcat - consistent, safe, string copy and concatenation".
At that point, it has everything you need except a good editor.
:)
hawk, noting that *someone* had to say it
The average buyer doesn't want a distribution, they want a complete operating system.
That's one reason I prefer FreeBSD. It's a complete operating system. KDE and Gnome run on it, too.
another project has to be started that creates a complete and pure Linux operating system that is a "total experience and environment" rather than a collection of packages.
That would be FreeBSD again.
So basically, while Red Hat and others have often vaunted the idea that Open Source can save you from your vendor if they orphan your machine (hmm... PA-RISC looks like it fits, as does M68K), now Ulrich says that those cause too many problems and shouldn't even be supported. So we'll be open and free and without proprietary hardware allegiences as long as we like the platforms.
The sad part is he uses the GCC model and sequence as one of the talking points, and that team and process was so badly flawed and restrictive that it has forked a number of times over the years to varying degrees. Which I think is good, as it was groups of developers trying to move forward in various ways when the process broke.
I'd venture here that in some cases, IF the main development team is OK with supporting as a tier-1 platform a new architecture or operating system, then by all means let them do so, and if that puts a few bumps in the road, that development community has to judge if the additional time, effort and coordination is worth it. Otherwise, there are a number of secondary-platform models as well. OS X has fink which has some dedicated crews modifying the trees with compliant (usually) patches that get things working on OS X and Darwin. At one point, the GNU tools didn't work on Linux well, only Solaris/SunOS and other variants.
Let the developers allocate their time where they want to. If Ulrich thinks it's wasting his time, then don't contribute to those projects if the majority of the developers think it's worthwhile.
Then the rant of his attacks Sun and says it should be dropped due to proprietary considerations. Except that the world changed when he was buried in Linux, and Solaris is open source, the chip itself is to an open specification (not so with Intel chips OR bios). The GCC platform spawned on those machines, and with Sun catering to educational institutes, his compiler wouldn't be here either, as it would probably be evolving at the speed of Hurd.
Unfortunately for him, I'm not one of the violent minorities, but then any generalization will miss a few. I use Windows, Linux, Mac OS X, and even a bit of Solaris here and there. Each platform has strengths and weaknesses. Save us from the tyranny of the plain, simple vanilla majority that would paint the world a non-offensive and uniform beige.
Obvious this is what GCJ is for, a *free* Java implementation
It should have read Porting Drepper's Monolithic, hacked, unportable glibc considered harmful
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)
At least, most of the time.
Your argument holds only as long as you ignore cross-compilers... which by a useful coincidence happens to be the major strong point of the project being discussed. :-)
We require that patches which might affect a particular platform be tested by building a cross-compiler for that platform, and then running regressions tests. Some tests are looking at the generated assembly, some of them try to "run" the code if you have a simulator installed.
It's rather rare that the code needs to be executed on actual hardware to expose a bug in a proposed patch.
You cannot apply a technological solution to a sociological problem. (Edwards' Law)
Cygwin, MinGW et al are harmful to the cause of Open Source in the same way that textured vegetable protein "burgers" are harmful to the cause of vegetarianism. Making TVP actually is less efficient in terms of land and energy usage than traditional m**t farming, yet vegetarians -- and probably the ones that eat TVP -- incessantly trumpet the notion that vegetarianism is "more efficient".
.....
If we go out of our way to make Open Source software available on closed platforms, then we are making a rod for our own backs. Open Source applications on Open Source operating systems must come first. We can tempt people to switch with our own coolness. It's not worth delaying the Linux release of foo because some feature doesn't work in the Windows version.
Well-written software should compile on any properly-specified architecture. On the flipside, software which will not compile on certain architectures may be badly-written. {Not every program need be fully portable -- if it makes use of specific hardware features, for instance, portability is quite unnecessary.} Alternatively, the architecture may be improperly-specified
Je fume. Tu fumes. Nous fûmes!
That's what regression testing is for. It is not unreasonable for any large system to contain a constantly growing testsuite that tests core features of the system. In fact, GCC does have a testsuite, although I don't know how versatile it is. For a compiler suite a reasonable testsuite would contain programs of varying complexity in the source language as well as object files for each valid combination of optimization/feature level and a platform (not a very difficult thing to produce).
The testsuite would then handle each such program in the following manner:
The only challenging part of this process is to "seed" the testsuite with canonical object files: someone would have to either trust a stable compiler version or to proof-read each .o/.s file. After that, all discrepancies would be considered failures by default. If the new compiler version produces different object code, it has to be either explained (and incorporated into the testsuite) or the compiler has to be fixed.
Combine the above with a distributed build system (like Tinderbox or CruiseControl) and you've got an automated regression testing system. After that, every applied patch would have to go through this ordeal to ensure that it doesn't break the compiler.
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.
But what was graphically feasible in a pc game 10 years ago would be feasible on a modern palmos or gba device, and what's feasible today in pc games will be feasible on portable devices in the future...
http://spamdecoy.net - free throwaway anonymous email - avoid spam!
Why would you want to do floating point math when using this algorithm? Why do you calculate the square root before you definitely need it? Why do you use complex square root instead of real?
bool isprime(int a)
{
if(!(a & 1) && a != 2)
return false;
int u = sqrt(a);
for(int i = 3; i <= u; i += 2)
{
if(!(a % i))
return false;
}
return true;
}
Please try the following exercise. Write a program to solve a practical problem using 100% Pure Java. Now without using GNU Classpath, attempt to run this program on Windows, GNU/Linux, FreeBSD, OpenBSD, NetBSD, AIX and Solaris, each on x86, x86-64, PPC, SPARC and StrongARM hardware if supported by the operating system. Let's see if you still think Java applications will run on any platform when you're finished. (Hint: you won't.)
Extra credit: write the same program using Python, Perl, Tcl, Ruby, Scheme, Common Lisp or any other language completely implemented by free software. (Using Java with the subset of libraries supported by GNU Classpath is permitted.) Try to run the program on the same machines used above. Explain the reason this was so easy. Contrast your experience with Sun's claims that without their iron fist Java would fragment and no longer be portable.
Not all those who wander are lost.
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)
Point me to the webpage that lists the "standard" portable includes.
- Conventional portability issues, which people here generally agree are important
- Portability to be compilable on lame outdated compilers. Some portable projects (MAME comes to mind) are extremely portable, but will not compile unless you have a modern (as in support for 64-bit integer, and ANSI support) compiler. On the other hand, Info-Zip needs to be compiled with compilers that were written fifteen years ago.
- Hyper flexibility - With Info-Zip, you can do some really arcane things, such as customizing the memory allocators that the project uses. While malloc() and free() are good for 99% of the people out there, it isn't always acceptable, especially in embedded environments.
While #1 may always be "good for the soul", #2 and #3 can be annoying, and may make the programmer feel like a luddite at best, or a torture victim at worst.Which might not show if he had a different hat.
The limit of this is that people will only write OSS for MS-Windows. NOBODY wants that!
Hey what happened to those silly image thingies? Did /. managlement listen to the whines of the readership? (Falls to ground, quivers)
.. paranoid crackpot leftover from the days of Amiga.
Interesting; I didn't know that, after six years of not being able to afford to keep up with Macintosh computers. If I take a file with a 42-character name from Mac OS X to Mac OS 8.6, does the file have a funny ~1 at the end of its name?
So, sure, F/OSS means you have the source to modify if you want something supported but it doesn't guarantee that you have the knowledge/skills.
If, say Linux, decides not to support your platform anymore, that may leave you out in the cold... and it's no more or less cold than if a proprietary system did the same.
I guess you *could* hire some folks to keep your port up to date, but that would be just as expensive. Besides, in proprietary software, smaller companies will at least give you a code escrow so if they go under or whatever, you will have the code just the same.
The only point I fully agreed with is that Debian took on more platforms than they could cope with. I've always thought Debian should release on a couple of major platforms (x86, AMD64, PPC) and follow that up with a portability release for historical/quirky platforms as soon as they could pull it together.
The only case where I'd be tempted to drop a minority platform is where it lacks a crucial feature, such as proper atomic operations. If it were possible, I'd drop all platforms lacking NX protection (which should have existed ten years ago), but perhaps that's not practical just yet.
For the remainder of the differences, clean code goes a long way.
This seems to be going around a lot lately.
He seems to have forgotten when the ix86 was a 'minor platform'..
Once upon a time the 65xx was king of the hill.
If you become singleminded, you only serve to hurt the future, and perhaps prevent something else thats better from coming along..
Besides, i bet if you count them there are more ARM and MIPS CPUs out there. Remember there are a LOT more embedded processors then desktops..
---- Booth was a patriot ----
The NetBSD have an impressive list of platforms, longer than anyone else's, in part because everyone else lists PPC, M68K, ARM, MIPS, SH, etc. only once. Sure, they list both MIPS-BE and MIPS-LE, SPARC and SPARC64, and PPC and PPC64, but that doesn't come near the splitting in the NetBSD list.
at the same time hack userland, kernel and protocols. While Debian developers mostly package upstream stuff.
And how fast does that evolve? How does the work the NetBSD people put into the (relatively static) userland and kernel compare to the work the Debian developers put into X and GCC and the kernel?
...given that Linux itself is a minority platform.
Well, Debian runs on a number of platforms and has a slow release schedule.
What about NetBSD? It's got far more platforms and a faster release schedule. Maybe Debian needs to add more platforms.
You can't blame Java for most of the platforms in the world being closed. Go and bitch somewhere else, perhaps at HP or IBM? Or perhaps you could try Microsoft? They might listen to your gripes.
Karma: It's all a bunch of tree-huggin' hippy crap!
"Most platforms" these days are mobile phones, which pretty much all support Java.
So I can say that with a fair degree of certainty that you're the one smoking crack here, as I haven't seen a phone made in the past four years which couldn't run Java. And that's many more platforms than you'll ever see on the desktop or server. :-)
Karma: It's all a bunch of tree-huggin' hippy crap!
So why not blame Sun for all the broken third-party VMs? Sounds like a plan to me. Oh wait, what does "third-party" mean again? I think I've forgotten.
Karma: It's all a bunch of tree-huggin' hippy crap!
Unfair comparison.
If you're not allowed to use a free implementation of Java to run a Java app, then let's level the playing field:
You're not allowed to use a free implementation of Python, Perl, Tcl, Ruby, Scheme, Common Lisp or any other language. Commercial implementations only, please.
Papers will be collected at the end of the lab.
Karma: It's all a bunch of tree-huggin' hippy crap!
Virtual Machines aren't new technology...just new to the PC world. It's not that it hasn't been done right. It's just asking too much for a PC to do the job of a Mainframe. PC's aren't that powerful...YET.
I notice you didn't refute a single one of his arguments, You just namecalled. Hypocrisy. It's fun for the whole family.
Wow. Just wow. You have missed the point on an epic scale. And the funny part is you're actually proud enough of your dumb little argument to decorate it with rhetorical immitations of mine. Allow me spell out what should have been obvious to you (in smaller words you'll be more likely to understand): there is no *complete* free software implementation of the current Java specification.
This is why the post I replied to said, "The linux crowd by and large won't use it because it's not quite their flavour of 'free'." This is also why I included Java with the subset of the library supported by GNU Classpath in the second paragraph.
The point is that languages completely implemented by free software can usually be used on any platform without compatibility problems while those that are not are constrained to the platforms the vendor chooses to support. (Unless one sticks to a subset supported by free software which, strictly speaking, makes it a different language.)
Come on now, try a little harder. This is not rocket science.
Not all those who wander are lost.
"Java specification" was a simple shorthand for the specification of the virtual machine, language and libraries. No doubt the first two are rather adequately implemented by GCJ and other free software Java projects, but the last is a vast sprawling mess so GNU Classpath has not managed to completely implement it yet.
Yes the API is actually specified. Look over here.
Not all those who wander are lost.
He doesn't accept patches for glibc to support the BSD buffer-overflow-protected string functions(e.g. strlcpy() and friends) because programers are supposed to be smart enough not to write buffer overflows (his arguement). As a result of his policy, many open source apps have been forced to roll their own functions or else use the error prone posix ones.
That is not true. The BSD source code could be dropped directly into anyone's app. There is no need to roll your own, there is not licensing conflict.
But in order to port to windows you need to own a windows box and a suitable compiler, which costs money you as a developer may be unwilling to spend..
.NET 2003 Professional!
Untrue, MS makes the compiler freely available:
"Q. What is the Visual C++ Toolkit 2003?
A. The Visual C++ Toolkit is a free edition of Microsoft's professional Visual C++ optimizing compiler and standard libraries--the same optimizing compiler and standard libraries that ship in Visual Studio
Q. Are there any restrictions on how I use the Visual C++ Toolkit?
A. In general, no. You may use the Toolkit to build C++ -based applications, even commercial applications, and you may redistribute those applications in accordance with the terms of the End User License Agreement (EULA). "
http://msdn.microsoft.com/visualc/vctoolkit2003/
FOSS' mission is not to help Linux, it is to help users. To help users get something useful done and to be able to deal with problems themselves if they have no recourse. FOSS is bigger, and older, than Linux.
and your point is?
Cthulhu loves you.
For me GIMP is one of the most crash-prone pieces of software currently around. At least in its Windows incarnation. I don't have an axe to grind either way, its good when it works, just a bit surprised to hear it spoken of as stable really. The funny thing is I can't remember the last time a piece of software crashed on my WinXP box, the GIMP aside. Certainly Win32 used to be bad that way but if you've been away for a few years (ie. pre-WinXP SP1) you might be surprised in the event you went back to it (possibly with a gun to your head or something, I dunno!) I'd say the thing about Windows apps being prone to crashing is a meme thats rapidly looking a bit creaky and anachronistic. Whatever else they've buggered up (DRM, activation etc.) there has been some progress in that particular area.