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?
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.
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.
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...
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..."
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.
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
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!
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).
Hypocrite... (software should be free! So I'm holding mine hostage until you release yours!)
And let's imagine what would happen if the vendors of those proprietary OS's decided to play the same way...
Say goodbye to NFS, NIS, Rendezvous, Mono. Perhaps Sun would close Java (which would make the conspiracy theorists happy, but nobody else.) Goodbye to the largess of many large vendors (where do you think organizations like FSF get their funding?).
And that crack about "ideally to one". Linux is a nice OS and all, but believing that it is the one for all purposes from PDAs to supercomputer clusters, data warehousing to real-time control is silly.
Am I part of the core demographic for Swedish Fish?
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"..???
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.
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.
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.
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
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.
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.
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.
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.
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.
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.
> The average buyer doesn't want a distribution,
...so why should they have to know what X.Org is
...one vision, one plan and a goal of one end
> they want a complete operating system.
The average buyer can't tell the difference, so long as the bloody thing WORKS. Which most Linux (and even some BSD) distros do OOTB these days.
>
> and why they need to care about it?
Gee. I run Linux and FreeBSD and I don't really care about X.org when using either.
> KDE + X.Org + Linux is a cobbled together setup,
> Windows, MacOS X, Syllable, BeOS, etc. were and
> are not.
Windows sold zillions of copies back in the 9X days and its being a GUI shell on top of DOS didn't stop that from happening. MacOSX is -- guess what? -- a GUI shell running on top of BSD (Darwin). It seems to be selling pretty well these days. As for Be, I have nothing against it, but it looks kinda dead to me.
> If you want desktop Linux to work well, and be a
> true replacement for Windows...
But I don't want it to be a "true replacement for Windows"; I quit using Windows because I came to realise that Windows fundamentally sucks and I hate it. I wanted something better than Windows. This is why I switched to desktop *nix. Which -- unlike Windows -- works well.
> 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.
Huh? Just how much of that MS Kool-Aid have you been drinking there, matey? This is simply absurd -- as if you don't have to install apps on Windows? And sometimes have to download DLLs so they'll work? And sometimes have them overwrite other DLLs and break stuff?
>
> result.
How is this different from Ein Volk, Ein Reich, Ein Führer? Sorry - trick question. It isn't any different. It's unthinking dogma.
Feel free to stay out of my way whilst I use stuff that works fine for me and do not discourage the folks who are nice enough to develop it for me because they fail to pass some cockeyed ideological purity test.
And the fact that there are people who would suggest that such a test is required for FOSS to enjoy success quite frankly scares me.
Thank you.
Il n'y a pas de Planet B.
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.
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
KDE + X.Org + Linux is a cobbled together setup,
Yes. Linux is a legion. *BSD is a tighter platform. They're not so much a bunch of assembled parts.
Main difference between the BSD license and the GPL license: one is from California and the other is from Massachusetts
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.
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!
> non-mainstream (read "non-Linux") operating systems
Ha ha! Linux as 'mainstream'! Oh man that's too much! I needed a laugh!
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.
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.
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.
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...
Porting to minor platforms is good because it allows them to compete more fairly against monopolies. Here is my blog post on this.
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
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]
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.
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".
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
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
And what OS would you run it on?
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.
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)
I don't think that it is a bad idea for Free Software developers to support non-Free platforms, but I do understand an idealogical postion that would. In some cases, Free Software on non-Free platforms might reduce the need for people to switch to the Free platform, which might hurt the Free platform, so I don't think it's necessarily hypocritical to avoid non-Free platforms entirely.
Also, I don't think your mention of NFS, Rendezvous (which is an implementation of zeroconf, AFAIK) and Mono makes sense. There are Free implementations of NFS (such as in Linux) and zeroconf. Mono is a Free implementation of DotNet stuff. Are you saying that Sun implemented the Free Linux NFS or that Apple and Microsoft implemented Free versions of Rendezvous and DotNet? Was Sun's, Apple's or Microsoft's porting efforts useful to any of the Free implementations?
Although I agree with you that one platform is not ideal (there should always be diversity and choice), your argument against Linux being the one isn't very strong, since it is actually used for all the purposes you mention.
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!
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.
As far as the everything-should-run-Linux argument, I didn't express myself clearly. It's possible to run the same OS on all of those platforms, but it's a silly, stupid, short-sighted idea. People who believe that one OS is right for everything are only an iota better than the one-language-for-everything folk.
Am I part of the core demographic for Swedish Fish?
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.
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.
And you are assuming that he already has Windows.
There're more costs than monetary ones to computer parts.
Yes, and one of those costs, a very large one in fact, is the cost of electricity. Older computers tend to not be very power-efficient, so you might just save yourself some money by buying a newer system, and also save some fuel from being consumed.
As for the earth, a few slashdotters are not going to have a significant effect on the number of computer parts in landfills. I tend to think the effect of electronic trash is much less on the earth, overall, than other things that people are doing to it, such as air pollution (like from power generation), global warming gas production (some from power generation), cutting down rainforests to support ever-expanding populations, etc.
I understand that Sun, Apple, and Microsoft have released specs and reference implementations, which is certainly very useful to any implementor, for Free or proprietary. However, I don't think it's relevant to the question of whether it's a good idea for Free software to be ported to non-Free platforms.
For one thing, unlike proprietary software, anyone may port a piece of Free software to any platform they choose without help from the orignal author. When the author of a proprietary package says, "we will not port it to Free platform X," they generally also mean that no one else can do it either. However, when the author of something Free says, "I will not port this to non-Free platform X," he's not stopping someone else from doing it.
Also, any implementor of something originally implemented in Free Software (whether they're writing Free or proprietary code) can always look at the orignal source to discover the protocol or method it uses. This may not be as useful as a well-written spec, but it's far better than trying to reverse-engineer a proprietary, closed package.
I strongly agree that it's short-sighted to think that one OS or one language is the right tool for every job. However, I do believe that a Linux-based OS is a good choice in more circumstances than any other particular OS (however, that doesn't mean it's a good choice in most situations).
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?
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?
That's pretty easy to figure out. That energy is all easily represented by the system's total cost, which also accounts for a healthy profit margin which we'll ignore because the end cost is more important to the end user.
Find out what your current rate for electricity is, in dollars per kilowatt-hour. Then decide what kind of new system you're interested in, and find out what the average power consumption for it is (idling, not peak, of course). Find out what your current system's average power consumption is. Subtract to find the difference, and then using the cost of the hypothetical new system and your current electric rate, calculate the amount of time before your break-even point.
This is simple high-school math, and I'm rather shocked you even had to ask.
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!
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.