Sun Microsystems is grappling with applying an open-source philosophy to its Java software as the company weighs risks and benefits over whether it should jump in further or not. But some experts are suggesting a middle ground.
Sun Microsystems is grappling with applying an open-source philosophy to its Java software as the company weighs risks and benefits over whether it should jump in further or not. But some experts are suggesting a middle ground.
SUN doesn’t want that java will be fork. Now, java is the only “compiler” or library that HAVE many forks! kaffe, gcj, IBM java and so on…
If it had been open-source, all this forks wouldn’t have exist!
SUN sould open-source java NOW, if they want to hit .net and microsoft with the help of the FLOSS community.
Made me laugh when I saw what you wrote, not that I’m laughing at you, but that it just makes a lot of sense.
GCJ and Kaffe are not forks: they are clean-room open source implementations of the Java standard. Dunno about IBM Java…
Anyway, people should get rid of their irrational fear for open source Java. Open source implementations already exist! To you naysayers I ask: where are the thousands of forks for GCJ and Kaffe? Actually, where are the thousands of forks for Perl and Python? GNOME and KDE?
Furthermore, forks will not kill Java.
1. There are already open source implementations – they haven’t killed Java did they? Nor did they create large incompatibilities, did they?
2. Incompatible forks cannot legally call themselves Java. They have to be officially certified before they can do that.
3. Java is a standard. Open source software *usually* have the reputation of trying to be standards-compliant.
4. If Sun’s JVM forks, then you don’t have to use the fork! Nobody’s holding a gun to your head and forcing you to use the fork!
5. There’s absolutely no guarantee that the fork will be incompatible.
6. Why would anybody use an incompatible fork? Can you guarantee me that suddenly half of the community will switch to the incompatible fork?
Also, forks are not necessarily a bad thing.
1. The fork might become better than the original (examples: XOrg and Inkscape). Or are you against innovation?
2. And if people disagree and fork, then that may mean that the original project’s leadership sucks. Do you want a software project to be forever stuck with a bad leader?
3. Forks are not necessarily incompatible!!
Again: all the zealous fear for open source Java is irrational.
Like Sun’s JAVA, I’m not native (speaker)…
” GCJ and Kaffe are not forks: they are clean-room open source implementations of the Java standard. Dunno about IBM Java… ”
IBM Java is based on Suns standards. They have undergone the compatibility testing and is a certified Java runtime. Mind you the only place you see heavy use of IBM Java is on the PowerPC machines. With their Intel based machines, Suns Java is shipped.
” Anyway, people should get rid of their irrational fear for open source Java. Open source implementations already exist! To you naysayers I ask: where are the thousands of forks for GCJ and Kaffe? Actually, where are the thousands of forks for Perl and Python? GNOME and KDE? ”
Find me any real usage of Kaffe or GCJ. No one uses it, once again all you see is Suns Java implementation. You might see some Blackdown Java deployments but they are far and inbetween. GCJ is incompatible with the main Java standard and the only vendors that are working with GCJ is Red Hat and they have only one project with which they use it. It might also be fair to note that GCJ is not a Java VM, it is a library to be used with GCC
” 1. There are already open source implementations – they haven’t killed Java did they? Nor did they create large incompatibilities, did they? ”
AS I stated, no real usage. Until its actually deployed we wont know exactly how these forks will behave.
” 2. Incompatible forks cannot legally call themselves Java. They have to be officially certified before they can do that ”
If Java is Open Sourced then yes, they will.
” 3. Java is a standard. Open source software *usually* have the reputation of trying to be standards-compliant. ”
True, but by which standatd. Half the fear is which implementation will be the standard?
” 4. If Sun’s JVM forks, then you don’t have to use the fork! Nobody’s holding a gun to your head and forcing you to use the fork! ”
But, if the content and application providers decide to use different forks and implementations then we will have to use specific JVM’s because of the “features”. It also makes life difficult for the developers because then we would have to test our applications on all the JVM’s which is a waste of time. Developing for Linux I have to make sure my applications work well on KDE, WindowMaker, CDE and GNOME and that the user experience doesnt get shotty. Believe it or not thats one of the reasons I like developing for Windows. The API is the same across the board. I dont have to worry if my users deploy KDE, WindowMaker, CDE or GNOME or the little inconsistencies i weite it once, usability is the same across the board. Thats also a reason why I like Java. Everything is the same.
” 5. There’s absolutely no guarantee that the fork will be incompatible. ”
There is no guarantee that it will be compatible.
” 6. Why would anybody use an incompatible fork? Can you guarantee me that suddenly half of the community will switch to the incompatible fork? ”
In the Open source community there is a lot of politics and religon that plays and when people build forks then it ussually has something to do for one or the other.
” 1. The fork might become better than the original (examples: XOrg and Inkscape). Or are you against innovation? ”
Better, sure, incompatible yes. NVidia and ATI are having a hard time with the ports of their drivers because like with Linux distributions, there is just enough difference to be a royal pain. Am I against innovation? No, but dont make my life as a developer harder just because you are having a tit for tat argument over licensing and unfortunately, seeing as how politics and religon play a course its likely to get ugly.
” 2. And if people disagree and fork, then that may mean that the original project’s leadership sucks. Do you want a software project to be forever stuck with a bad leader? ”
Just because you think Leadership sucks doesnt mean that I think it sucks. Just because you have a problem with a catch in the licensing doesnt mean that I have a problem with it.
” 3. Forks are not necessarily incompatible!! ”
Forks are not necessarily compatible.
I dont see why everyone wants it open sourced there is no possible benefit and itonly takes away the licensing catch.
First of all, I like java. It’s pretty nice. I’ve been playing around with a SWT project at work. The IDEs are top-notch(IDEA and Eclipse) and GCJ is pretty cool too. I just happen to like c# and its libraries better. They just seem more natural to me
I like this quote from Gosling – “”I love Linux to bits, but they’ve got the same problem all over again. They’ve got all these distributions, and they’re really close, but they’re just different enough to be a pain in the butt.”
So true.
Java’s slow development, the swing “blunder”, and high memory costs have probably been the biggest problems with java – at least on the client side. Maybe open sourcing it can rectify some things, but there’s such a mindset against java on the client who knows if that can be changed..
Can Sun ever recoup its development costs by selling J2EE licenses. Probably not. Maybe if they opened it up the core, then they could focus on higher-level business solutions instead of getting bogged down on implementing low-level stuff on multiple platforms.
I don’t buy the incompatiblity argument. As another poster said, where’s the numerous forks of Perl, Python, etc…
Microsoft is unafraid to make changes to the VM and to the language itself. Sun has been really conservative in that area. e.g, Java generics is a compiler trick. With the 1.0 release of Mono, I’m hoping it takes off in a big way.
…big announcement at JavaOne 2005: Java is officially open-sourced. The timing would be symbolic; by then Java has been under Sun’s stewardship for 10 years. (It was originally announced in the spring of 1995.)
I think that if OSS Java is, indeed, going to happen, then it’s going to happen next year or not at all. (Or when it’s too late and Java is no longer relevant. But that is at least several years off.)
…..and while it sleeps, .NET and MONO (some would place C#, QT# here too) march on. By the time SUN wakes up, it might be too late to stop the momentum of these two. SUN and M$ should understand that like Linux, MONO cannot be stopped. If I were SUN I would have taken a decision long time ago. This debate has been going on for sooooooooooo long.
“Find me any real usage of Kaffe or GCJ. No one uses it, once again all you see is Suns Java implementation. You might see some Blackdown Java deployments but they are far and inbetween. GCJ is incompatible with the main Java standard and the only vendors that are working with GCJ is Red Hat and they have only one project with which they use it. It might also be fair to note that GCJ is not a Java VM, it is a library to be used with GCC”
Then your fields of endeavor probably don’t include research, embedded systems, or work on and with free software.
Gcj is shipped by every linux distribution I know, Kaffe is a close second. Kaffe is shipped by the BSDs, and is one of the cornerstaines of bringing java applications and libraries top debian’s main software pool. Kaffe has been ported to more than 70 platforms, altogether. These days people use free runtimes without realizing they don’t use Sun’s non-free products.
Gcj is not just a library. It’s a full runtime environment.
There is no Java standard, so there is nothing to be incompatible with. There is a set of specs, and half-written API docs from Sun, and we all try to be compatible with these.
cheers,
dalibor topic
…..”Believe it or not thats one of the reasons I like developing for Windows. The API is the same across the board.”
http://www.joelonsoftware.com/articles/APIWar.html
You have too many expectations for the client. Maybe your experience is related to client applications. The problem is: the client has been dominated by the web browser and by the web designers/developers.
>The problem is: the client has been dominated by the web browser and by the web designers/developers.
You cannot fit everything in an HTML interface and you cannot always rely on a client/server architecture. There’s still plenty of room for “traditional” GUI applications.
Java has a proprietary design, it is not the best technical design. Java is a platform for a product line, it’s in the interest of customers who want to continue to use their investment that Java become open source, however, it’s in the interest of quality software to settle for Java. I don’t think that open source and Java oppose each other however, but open source should not be content with Java, it can do better.
…by that I do not mean C#. Java and .Net/Mono are no different.
The client/server architecture has been outdated with the web.
The three-tiers (multiple-tiers, actually), architecture of the web can up-scale and down-scale as much as one wants.
The traditional client apps should adapt or disappear.
MS’s Avalon should be a shot at trying to keep some relevance for the client apps, buutttt, at the cost of making MS relevant again.
Its too late. Anyone who tried Mono, knows that Java won’t have a bright future. Mono has all the advantages of Java but doesn’t have the disadvantages (slowness, non-native look, etc).
Well, I was talking about web applications when I said “client/server” applications. I see web applications as relying on client/server architecture.
Declaring client apps as outdated or irrelevant is a bit farfetched I think. There are plenty of networked apps that run outside the browser. RSS readers or the iTunes store, for instance. As a user, I wouldn’t want to work predominantly with HTML form-based interfaces. Web apps just aren’t as responsive as traditional GUIs.
RSS Readers, if proved to be useful to society, can gain some attention by google. I would love to use it thru a clean Interface with a google style.
The client apps may become a niche market.
oh please dont call java slow again.. FUD FUD FUD..
[i]Mono has all the advantages of Java but doesn’t have the disadvantages (slowness, non-native look, etc).[i]
Oh yes mono looks really native of my Mac.
Am I supposed to use SWF or GTK#. Its not GTK# because I’d have to use X11, its not SWF because I’d have to use Wine or whatever the new take on SWF is going to based on.
AT least Java has a GUI API that has no dependencies.
It is slow
You wrote:
” 2. Incompatible forks cannot legally call themselves Java. They have to be officially certified before they can do that ”
If Java is Open Sourced then yes, they will.
Not necessarily. Certain open source licenses (like Apache) allow only the use of the code, not the name. If someone bases a product on Apache and changes any of the Apache code, they lose the right to call the product Apache. They can say it’s based on Apache, but that is not the same thing as calling it Apache.
It’s all in the license, and I personally think it would be stupid for Sun not to open source Java with that same license restriction.
You wrote…
” 3. Java is a standard. Open source software *usually* have the reputation of trying to be standards-compliant. ”
True, but by which standatd. Half the fear is which implementation will be the standard?
Under IBM’s proposal, Sun would still hold the keys to the TCK. Therfore, any implementations of the standard would still be forced to hold up against the official Sun standard. Anything that doesn’t pass can’t call itself “Java”, just like things work today.
The most compelling reason for open source is economy of scale. J2SE is infrastructure plumbing. The ROI from trying to competitively differentiate implementations of J2SE and still remain standards compliant is not there. Why, then, force all the different vendors, and the open source communities to create their own implementations of the same thing? If it were open source, then the different vendors could cooperate on creating a bug-free standard implementation and focus their time and energies on making Java better.
They don’t seem to realise that mono is going nowhere, as Gnome et al are about as likely to adopt patent-encumbered mono, especially with Red hat and Sun (the main backers of Gnome) opposing such a move vociferously, as well as the original license-and-patent obsessed people who founded Gnome in the first place.
At my company, funnily enough, mono does have a place.. We are migrating everything to java on linux, as the best serverside solution we are aware of, and mono is kind of useful for temporarily hosting legacy ASP solutions (the relatively simple ones it can handle).
I don’t see mono as particularly going anywhere tho, its too risky, bottom line.
Actually, where are the thousands of forks for Perl and Python? GNOME or KDE?
I ask you this, Where is the $120 billion ecosystem around Perl / Python/GNOME/KDE?
Where are the above said technologies other than on linux and UNIX based systems, may be Perl on windows as well?
My cellphone runs Java apps, infact two of my previous phones did as well. I can’t see perl scripts being used on my devices but java is prevelant.
The reason there are no forks of any of the things you mentioned is because there is no profit for companies in forking Perl/Python/GNOME/KDE.
IBM/Oracle/BEA would love to lock thier customers into thier own developer suites for thier Middleware. They now have to be compliant with the J2EE stnadard so they do, if java is fully free they can do anything they want and they will. Reason being there is money involved.
You must not use anything recent. Java is no longer slow. Still a pain to develop for the Windows desktop, maybe, but not slow. At least Jave does not have the specter of Microsoft looming over it that MONO does.
There are two related questions in my mind. First, are we talking about Java on the desktop or Java on the server? Second, are we talking about Java-the-platform or simply Java-the-language?
It seems to me that, if one is interested in Java server applications, then it only makes sense to consider Java as a platform—including the VM, the runtime, and all the attendant alphabet soup of Sun-sanctioned “enterprise” standards, such as J2EE etc. Here, it seems to me that Sun is pretty much in control: they decide whether implementation X conforms to the J2EE standard, etc. Note that these standards involve much more than the Java runtime, which is itself conceptually separate from Java-the-language.
But many of us are really interested in Java on the desktop. Here the situation seems more… open (pardon the pun). For the purposes of developing next-gen desktop apps, Java-the-language can be an interesting alternative to, say, C and C++ (just like C# can be), regardless of whether one is compiling to a VM or to native code.
Moreover, the Java runtime itself can also be useful, but (here’s my main point) there exist GPL/LGPL alternatives today: the GTK+/GLIB object model and framework, the Qt object model, the OpenStep / GNUstep framework, etc.
So, questions:
1. To what extent does Java control “Java-the-language”? And, in any case, how important is this? Is there anything that prevents one from building and distributiong, under GPL or LGPL licenses, a Java language compiler, regardless of whether or not this language is actually referred to as “Java”?
2. How important is it for Java to open-source their implementation of the VM and runtime? Is it technically and/or legally feasible to substitute the Java runtime libraries / framework / object model with GPL/LGPL alternatives?
M
“It is slow”
I agree. Why does it seem like the only people that think java is fast are java developers?
You wrote:
IBM/Oracle/BEA would love to lock thier customers into thier own developer suites for thier Middleware. They now have to be compliant with the J2EE stnadard so they do, if java is fully free they can do anything they want and they will. Reason being there is money involved.
You need to look no further than Linux to know that argument is patently false. IBM, Oracle, Sun, and others could take Linux and produce totally incompatible versions, but they know that their competitive advantage is not in the software, but in the service and support they provide to help their customers implement the software.
” .”Believe it or not thats one of the reasons I like developing for Windows. The API is the same across the board.”
http://www.joelonsoftware.com/articles/APIWar.html ”
Just because one developer doesnt like the Win32 API, or thinks Microsoft lost the API war doesnt mean that I cannot enjoy or like the Win32 API
You need to look no further than Linux to know that argument is patently false. IBM, Oracle, Sun, and others could take Linux and produce totally incompatible versions, but they know that their competitive advantage is not in the software, but in the service and support they provide to help their customers implement the software.
Linux is a great example of why java wold fragment, Linux is already incompatible. Try 2.4.21-mdk or 2.4.21-redhat or any of the variations, not to mention 2.6 or myrad of library versions for any given app. There are no linux binaries or even packages that will install and run iniversally on any distro.
Try installing a Redhat RPM on SUSE, you can’t. You can’t just load any linux driver on any kernel. There is no compatibility among linux distros. Vendors have to support specific distros and even specific versions of distros.
ISVs support mostly Redhat and SUSE only, If you are an enterprise you can’t just move from one the the other or any vanilla distro , just because it is linux.
Thanks for making my point for me.
Yeah, and browser applications absolutely suck.
http://www.bea.com/framework.jsp?CNT=index.htm&FP=/content/products…
Just read bea’s JRockit overview.
“BEA invites ISVs to self-certify on WebLogic JRockit
If you are an ISV and running your application on WebLogic JRockit, you are now eligible to self-certify on WebLogic JRockit. By endorsing WebLogic JRockit, you can further promote your solutions to the BEA community of customers, partners, investors and employees. Through the BEA and Intel alliance, we hope that not only are you taking advantage of the superior performance of this Java Virtual Machine, the only one that is optimized for Intel Architecture, but you also make full use of all the resources that are provided specially for you.”
Once BEA has enough ISV support for JRockit what is to stop them from adding incompatible features to it and deviate from the Java standards.
this is just another advert for sun….
either way put up or shut up…
either do it or dont stop lets stop boring ppl with these adverts for sun….
but still control the specification. And if sombody forked the implementation in such a way that it didn’t conform to the specification, then they wouldn’t be allowed to call it java.
They could even require that any extensions available in such forks should be documented as being extensions to get to use the java brand.
By doing this, they would make sure that java stays even if Sun goes to meet its maker. We could also expect that java would be used a lot more than mono in opensource project as many open source developer are suspicious about Microsoft related technology.
The only thing Sun would risk by doing this is that somebody will create a faster JVM than them. Meaning that Sun could concentrate on being making the fastest JVM for Solaris/sparc, and let the open sorce developers do x86 and other platforms.
They don’t seem to realise that mono is going nowhere, as Gnome et al are about as likely to adopt patent-encumbered mono, especially with Red hat and Sun (the main backers of Gnome) opposing such a move vociferously, as well as the original license-and-patent obsessed people who founded Gnome in the first place.
The problem is that Gnome developers need some object oriented way to develop applications, or they will not keep up to speed with KDE. They also need a framework that makes it easy to port to windows. Porting free applications to the windows desktop is the key to the succes of the Linux desktop. Even if Sun is one of the major contributers to Gnome they do not control it. For one thing, Novell owns ximian and they are going to have a lot to say as well.
There’s no such thing as “a little bit pregnant”. Similarly, software is either free to use, copy and modify or it isn’t. The current licensing scheme for Java is supposed to be a middle ground – and it isn’t.
“Linux is a great example of why java wold fragment, Linux is already incompatible. Try 2.4.21-mdk or 2.4.21-redhat or any of the variations, not to mention 2.6 or myrad of library versions for any given app. There are no linux binaries or even packages that will install and run iniversally on any distro.”
Jup. That’s because “Linux” (rather glibc, gcc afaik) is progressing instead of staying conservative to changes. Anyway, you said binaries. Try to compile and run any GPL software on these versions, and most will simply work (version of software might differ). You also have both the changes and the source to change in either of these OSes; which mostly wasn’t available in the UNIX world as we knew it the past decenia. Rhetoric questions: Did the fragmentation helped the UNIX worlds’ markets? Did, just because X was an open protocol, it lead to incompatible versions? Are there incompatible versions of the open, widely documented TCP/IP protocol available?
Btw sometimes the changes concerning a binary are as simple as a library which exists in a different place. Solution: compile statically, use rld/rpath, etc. The static compiled Opera, for example, runs on about every “Linux” distribution.
The solution *should* really be quite simple: Sun should simply, plainly, and with legal authority say, “We are not open-sourcing our Java implementation. That is our competitive advantage. However, *you* (the Free-software community) are free to implement your own Java. Please do (GCJ/Classpath is looking great so far!). We welcome the competition. However, if you want to actually *call* your implementation “Java”, you’ll have to pass a freely-available compatibility test suite. Welcome!”
However, they do not seem to be doing that. Interesting. The reason seems to be patent-related. Sun has got to hold all sorts of Java-related patents, and perhaps an offer like the one above would be contrary to existing patent law/practices. Dunno.
It’s a pity. Java is one of those “could take over the world” technologies, but only if done in a truly Free way.
You make some good points and I’ll expand on it by saying that Gnome adopting Mono as an official runtime gives that desktop a competitive advantage. Not only do they have a kickass language, C#, to use, but it also makes it easy to port applications to windows and vice versa.
No matter how much the fanboys hate it, Microsoft still has 95% of the desktop and its not going to be going away any time soon.
That’s because “Linux” (rather glibc, gcc afaik) is progressing instead of staying conservative to changes.
Sure it is but not all distros are moving at the same pace. But with Java all progress is at the same pace, thus lesser chances of incompatibilities. Mind you I am not saying that a slow pace of change is a good thing. Java debuted in 1995 and has progressed quite well and captured quite a bit of market and yet various different implementations have been compatible (barring Microsoft’s attempt at it).
Anyway, you said binaries. Try to compile and run any GPL software on these versions, and most will simply work (version of software might differ)
Really, even if the binaries are compiled dynamically with shared libraries that might not be available on all distros????
Are there incompatible versions of the open, widely documented TCP/IP protocol available?
We can go all day back and forth with useless examples of incompatible and compatible versions of technology.
TCP/IP are two seperate protocols and there is no incentive to make incompatible versions. Once Java reaches the ubiquity that TCP/IP has where communication on the internet can’t happen without it, no one will have incentive to make an incomatible version. Becuase the ubiquity will insure compatibility.
Btw sometimes the changes concerning a binary are as simple as a library which exists in a different place. Solution: compile statically, use rld/rpath, etc. The static compiled Opera, for example, runs on about every “Linux” distribution.
Surely you aren’t claiming statically compiled binaries are a solution to incompatibilities caused by projects that just want to do things differently.
Statically compiled binaries defeat the use of shared pages for libraries increasing the RSS of a process, a horrible solution IMO.
In an open source environment, you would need the source code of every library revision that some one decided to statically compile. It kind of deafeats the purpose doesn’t it and soon becomes very ugly to maintain.
I don’t understand why java is slow for some people. I find it pretty fast even using swing.It was slow4 years ago when one would try to use Java3D , but not anymore. Then I had a P2 @ 300Mhz and 64MB ram, today I have P4 @ 2.8 Ghz and 2 GB ram (at home).For me everything runs pretty fast. And I have this config through succesive upgrades,no sweat for the house budget.At work I have a slower machine ( 512 MB ram ,P4 @ 1.4) and is also fast. I believe is slow for P2’s and P’s , that is , not for P3&P4’s
I think IBM’s new Rich Client strategy using the Eclipse platform demonstrates a commitment to a Java based desktop. Bud is right Java is running fast enough on todays machines. It’ll probably run faster with the 1.5 JVM and GCJ compiled apps load faster. Even on my slow 700GHz PIII at home Java apps run quite reasonabbly on the 1.4_02 JVM.
Look at couple desktop apps available now that appeal to the general user not just geeks:
RSSowl: http://rssowl.sourceforge.net/ is a news aggregator that though written by a small group led by a student at Humboldt University in Berlin is already implementing the IBM approach and building a SWT application utilizing the Eclipse workbench as a basis. It is an attractive and functional application that of course looks native due to SWT.
iRATE: http://irate.sourceforge.net/ is an innovative client/server mp3 player/downloader featuring collaborative filtering. It uses SWT with GCJ to give a fast loading native GTK application.
I think these applications demonstrate that there is a future for Java on the desktop.
>They don’t seem to realise that mono is going nowhere, as >Gnome et al are about as likely to adopt patent-encumbered >mono, especially with Red hat and Sun (the main backers of >Gnome) opposing such a move vociferously, as well as the >original license-and-patent obsessed people who founded Gnome >in the first place.
This is a non-issue for GTK# applications. The only patent-encumbered part is in the .NET stack which no Gnome developer will use. The rest is based on standards.
Bud: I believe is slow for P2’s and P’s , that is , not for P3&P4’s
Well, on my P4 it’s fast, but on my P3 it ranges from being fine (rarely) to being really slow. Meanwhile, .Net and native apps run fine on both.
“Really, even if the binaries are compiled dynamically with shared libraries that might not be available on all distros????”
Examples?
“We can go all day back and forth with useless examples of incompatible and compatible versions of technology.”
I see no difference: customers don’t want incompatible Java versions either. Customers don’t want incompatible C/C++ versions either.
“Surely you aren’t claiming statically compiled binaries are a solution to incompatibilities caused by projects that just want to do things differently. Statically compiled binaries defeat the use of shared pages for libraries increasing the RSS of a process, a horrible solution IMO.”
Ofcourse they are a solution; just not [i]the solution. Depends on the situation. For example it’s worth to consider it, when dynamic compiled version isn’t a (suitable) possibility. It solves a problem then; is it a solution? Yes.
“Really, even if the binaries are compiled dynamically with shared libraries that might not be available on all distros????”
Examples?
Hunh? I didn’t think you would need examples to understand that basic concept. If you compile any binary and dynamically link it with shared libraries the runtime linker won’t be able to resolve any of the symbols in the libraries that are missing.
Anyway to convince you I typed “linux ld” in googles search field and this gave me.
http://www.linuxquestions.org/questions/showthread.php?threadid=199…
One user asks:
” I am using a Debian-Knoppix system.
After installing a “.DEB” package, an attempt to run the program gave the following error:
relocation error: /usr/local/canvas7/canvas7: symbol _dl_global_scope, version GLIBC_2.0 not defined in file ld-linux.so.2 with link time reference
I am pretty sure that glibc is installed OK.
Any ideas on the “not defined in file ld-linux.so.2 with link time reference” ”
The other responds:
“It’s probably that you’re using a version of libc that isn’t compatible with what that program was compiled against.
“not defined in file ld-linux.so.2 with link time reference”
Translation:
“I can’t find this in ld-linux.so.2 even though I was compiled so that I have to get it from there when I run”
Try getting the source package and building it from that or get a different binary package.”
I meant examples of binaries which are are compiled dynamically with shared libraries that are not available on the distribution in question.
If it is FLOSS, it is practically impossible. If it is not FLOSS, it is proprietary, and such situation is both unlikely and stupid.
I meant examples of binaries which are are compiled dynamically with shared libraries that are not available on the distribution in question.
If it is FLOSS, it is practically impossible. If it is not FLOSS, it is proprietary, and such situation is both unlikely and stupid.
Which distritbution was in question? MPlayer for one is a pain with out the right libraries. I tried it when Redhat 9 was out and I had to get every damn library under the Sun to make it work.
Why is is it practically impossible in FLOSS? I never said it isn’t possible to make it happen it is just a damn waste of time.
I think we are on a Java topic and some one brought out linux to be the epitome of compatibility and open source, it is not. In fact, the linux ecosystem is the prime example of why Java should not be open sourced. With Java an App written with standard classes say for 1.4.2 is garunteed to work on any vendor’s 1.4.2 JRE (IBM/SUN/BEA, if it doesn’t it is a bug!!!).
There is no such thing as a linux app. You have Apps compiled with X libraries on X distribution that will work on X distribution. You have to be lucky or do a lot of work to make it work on Y.
Linxu elitist and OSS zealots claim that to be a great advantage, sorry end users disargee. I am all for Open Source and freedoms but it shouldn’t be this complicated to come up with a standard set of things one can expect to have and write code to, constantly changing APIs are not a good thing.
This constant change and incompatibilites will force customers with large Apps to pick one vendor and stick with them becuase change costs money and millions invested in an environment can’t just be ignored. Open Source might not be as free as people hope becuase of said incompatibilities.
“Which distritbution was in question? MPlayer for one is a pain with out the right libraries. I tried it when Redhat 9 was out and I had to get every damn library under the Sun to make it work.”
A lousy example, because MPlayer is recommended to be build from source because of its huge -including non-free- dependancies. What one distributor supports as flags might not be be in the interest of the user. Instead of getting a binary one is better of compiling it after which it is able to run flawless on all the other systems with the same hard- and software. What would you see as the solution for this problem: static binaries, no libraries at all? All worse than the current “problem”. Any better examples?