Slashdot Log In
Java Trial Support Coming In Linux Standard Base
Posted by
timothy
on Wed Nov 12, 2008 02:40 PM
from the chai-unfairly-excluded dept.
from the chai-unfairly-excluded dept.
LinuxScribe writes "Java isn't in the LSB — yet. It's been a hard target to hit: which version gets standardized? How will test suites work? But the new version of LSB will take the first steps towards Java inclusion in standardized Linux development by introducing trial support for the language."
Related Stories
This discussion has been archived.
No new comments can be posted.
The Fine Print: The following comments are owned by whoever posted them. We are not responsible for them in any way.
Full
Abbreviated
Hidden
Loading... please wait.
Source (Score:4, Interesting)
The LSB still doesn't make much in the way for accommodations for source-based distros. And while I laud its efforts, the LSB also states that distros should standardize on RPMs where as the one distro taking off like a rocket is DEB based and unlikely to ever move over to RPMs.
Re: (Score:3, Insightful)
It took off like a rocket and then Intel dumped it for an RPM-based distro [desktoplinux.com].
Go figure.
It just goes to show that Ubuntu being popular has nothing to do with it's packaging system OR anything to do with it being any good as a distribution. Mark Shuttleworth really knows how to market things..
Re: (Score:3, Insightful)
I agree. These days I'm not sure an advantage truly exists going with .DEB over .RPM or vice-versa. I also don't believe that Ubuntu is any better than other distros. I too credit Shuttleworth's fantastic marketing skills.
My point is that while the LSB is a great idea (that I'd like to see gain more support) but I'm worried that the LSB will become less important as major distros like Ubuntu (and its derivatives) ignore it.
Re:Source (Score:4, Interesting)
The LSB is a horrible idea, and it needs to die a sudden, instant, and even immediate death.
You see, the original plan for the LSB was that it would be a installable binary platform that you could install on test hardware and actually use. Perens was involved, and so the original plan was to use Debian as the base for this distribution as it gave them an immediate code base to work with that had been ported to a large number of hardware platforms.
Unfortunately, Caldera didn't want an installable binary distribution, as it thought that an actual working distribution would cut into sales of its product. Red Hat agreed with Caldera mostly because the folks at Red Hat knew that if a binary standard wasn't produced then Red Hat would become the de-facto binary standard.
That's why we have the LSB, and that's why the LSB is about 7 orders of magnitude less important than CentOS, Oracle's Red Hat clone, or any number of Red Hat derivatives all of which simply treat Red Hat Linux as a binary standard.
The LSB is clunky to use, impossible to test against, and specifies so little software that it is basically a joke.
Parent
Fix it! (Score:3, Insightful)
We have nothing else. POSIX is insufficient. We need LSB. It needs to work. Even in its current state it keeps Linux from turning into a nebulous mess.
Re:Source (Score:4, Informative)
I'm laughing at the sheer incompetence the loudest mouthed RPM-bashers are exhibiting in this thread.
Now, who should we thank for attracting an audience of clueless amateurs into the Linux world?
People in glass houses... Etc, etc...
Apt is merely a tool. People misattributed the benefits of debian to the Apt tool, when the benefit was really in the repository. Apt "for RPMs" is basically useless without a unified repository. Or at least several repositories that are linked against the same libraries and share dependency hierarchies.
The benefits of DEB over RPM have nothing to do with the tool, either. They have to do with how the two formats handle configuration (Or in the case of RPM, how they *don't*).
Parent
Re: (Score:2, Interesting)
I think if it were anything like as unreliable as, say, Fedora was at the time I tried both of them out, Ubuntu would have ended up in the dustbin of "Populist Distros nobody takes seriously." Shuttleworth has some marketing skills, and has done a good job, but Ubuntu needed to be a good distribution for it to be popular. That alone wouldn't have made it popular, but it was a prerequisite for success.
Whether APT/DEB was a key component to its success is anyone's guess. More likely was the fact it was bui
Re: (Score:2)
Re: (Score:2)
And I would hazard a guess that, the whole reason Debian is so stable... is because of it's policies and processes. I would say that APT/DEB has very little to do with this stability.
Re:Source (Score:4, Interesting)
It took off like a rocket and then Intel dumped it for an RPM-based distro [desktoplinux.com].
Go figure.
Ubuntu isn't as well suited for mobile devices as fedora is?
It just goes to show that Ubuntu being popular has nothing to do with it's packaging system OR anything to do with it being any good as a distribution. Mark Shuttleworth really knows how to market things..
You think? I use Ubuntu because Debian stable is outdated most of the time. And for me one major reason for Debian is it's package managment system. Just look how many distros are based on Debian vs. how many are based on fedora or openSuSe (distrowatch).
Parent
Re:Source (Score:4, Insightful)
What if the number of debian-based distros is based on the deficiencies of debian. ;)
But seriously, I don't see that yum is inferior to apt. For me, RedHat/Fedora has always had things laid out pretty well. Fedora has forged ahead with new ideas with real code (e.g. NetworkManager). Related to this article, is RedHat funding development of IcedTea. I hope that Java does make it into the LSB. It might force some further thinking on how to manage java packages on a system.
Parent
Re:Source (Score:4, Informative)
But seriously, I don't see that yum is inferior to apt.
Press Ctrl-C sometime.
Parent
Re: (Score:3, Informative)
Dependencies in rpm can either be on a package name or a file - the packager can choose which makes more sense.
The main thing which makes yum seem slower than apt is that by default yum checks the server for an updated
Re: (Score:2)
And your point is what? (Score:4, Insightful)
Should we abandon LSB and embrace chaos, or should we try to make it work? Just because people are not adhering 100% to a standard, that does not make it useless or irrelevant. Look at SQL or even POSIX.
Anyone can whine about perceived problems. What do you think should be done to fix LSB?
Parent
Re: (Score:3, Interesting)
The LSB standard format is rpm v3 format, whereas all current distributions use a newer rpm (from one fork or another) and the old v3 archives are supported only as a legacy format for LSB. I think for political reasons they might rename it from 'rpm' to 'LSB package format' and make sure direct support for v3 packages is removed from rpm, then people wouldn't get so worked up about it somehow being unfair to Debian. No recent distribution actually uses LSB format packages natively.
As a C++ programmer... (Score:2)
I have just one thing to say about that... (Score:2)
OBJECTION!
Re: (Score:3, Funny)
Don't you mean java.lang.Exception?
As a Java programmer... (Score:2)
Fear not, fellow camel-caser, Linux already has Binary Kernel Support for Linux [mjmwired.net]!
Re: (Score:2)
As a multi-lingual developer... (Score:2)
I do not welcome any judicial overlords telling me which language to use or not use. I want EVERY language in common use to be available.
Re: (Score:2)
The JVM is not an emulator. It would be more realistic to think of it as a runtime compiler.
Re:Every language is an emulator (Score:4, Informative)
What? That's simply not true. An emulator is a program that imitates a piece of hardware in order to execute programs originally intended to run on the hardware. Which is exactly what the Java VIRTUAL MACHINE (JVM) does.
Programming languages hide hardware details using abstraction, but they don't emulate anything.
I guess he's not the only one.
Parent
Re: (Score:3, Insightful)
Perl is a program that imitates a piece of hardware, too. Just it because it doesn't happen to exist doesn't mean that it's not an emulator.
Will this FINALLY mean... (Score:5, Informative)
I can fucking run browser applets on 64-bit Linux?
So annoying... home is dual 32-bit so I can run TD Ameritrade with no problems---it flies.
Then at work which is quad-64 bit, in order to get any java applets to work I'd have to bastardize my browser down to 32-bit so nsplugin can launch them---and when OpenSuSE releases an update on YaST--it blows this setup away since it sees "aha, you're on 64-bit, buddy!"
Sun not supporting 64-bit applets in their runtime is a travesty. Fix it!
Re: (Score:2)
Though not the official plugin, the gcjwebplugin launches the 64bit JVM just fine.
Not sure which distro you're using but on fedora the package you want is java-1.6.0-openjdk-plugin which contains gcjwebplugin.so
This is compiled for x86_64 and has no trouble running applets in 64bit firefox.
Re:Will this FINALLY mean... (Score:4, Informative)
http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695 [sun.com]
Really? It looks like Sun has been sitting on this bug for several years, and is finally doing something, but doesn't expect it until JRE 6u12.
The only 64-bit Java plugin that I can get to run is Iced Tea.
http://www.iced-tea.org/wiki/Main_Page [iced-tea.org]
Unfortunately, that doesn't work with the one site that I've found that still uses Java (the horrid ADP timesheet site that my company just outsourced to).
Parent
Ooo a standard! (Score:2)
---based off N number of JREs (FOSS, IBM, Sun)...
---on N number of distributions
---who use N number of package management systems, that package software in
---N number of archive formats
Yeah, this is a cakewalk.
Ooo a standard indeed! (Score:2)
There IS a standard for Java functionality. It is rather inclusive. Developers can write Java applications using advanced features such as JNI without regard to the JRE's author. It matters not which JVM provides the functionality.
Standards can be written, and ARE written, so that there is both flexibility where necessary, and rigor, where required.
I probably don't get this, but... (Score:2)
Re: (Score:2)
I probably don't get it either, but why not a newer JRE like 1.6.10 or even whatever 1.5 is up to? Correct me if I'm wrong, but aren't most of the minor Java releases to fix security problems?
Re: (Score:2)
BTW, IIRC, we're at version 1.5.16 and 1.6.10.
Re: (Score:2)
Re: (Score:2)
Is Java 1.4.2 freely redistributable the way recent versions are?
Re: (Score:2)
So much for write once run anywhere! All you have to do to get the promise delivered on is to use an EOL version that the vendor has lost interest in.
Re: (Score:2)
Re: (Score:2)
Or you could use a newer JVM. With the exception of a few well-documented issues [sun.com], Java code written for any previous platform version is fully upward-compatible, both binary (byte-code) and source, to any newer release. That sounds like about as close to WORA as you can get.
Or were you thinking of running new code on an old JVM? If so... why?
GPL!!! (Score:4, Informative)
The only Java implementation released under the GPL is 1.6.
I think that's a pretty overwhelming reason.
Parent
GNU java is not java (Score:2)
GNU java is not java, it has not passed the tests. It does not even begin to work with the stuff I use at work.
Re:GNU java is not java (Score:4, Informative)
Sun Java 1.6 was released under the GPL. GP is not talking about GNU Java.
Parent
Re: (Score:2)
I was justifying my use of the word "only".
Keep the base small (Score:2)
They should really try to keep the linux base as small as possible. The point is to increase compatibility by creating a standard to which everyone codes. If they throw everything and the kitchen sink in the standard, that kind of defeats the whole point. Everyone will just keep on coding however they want, and a basic LSB compliant distro will become ever more bloated.
I know it's hard work to get everyone to agree on what really needs to be in the base, but if you're not going to do that hard work, why
Re: (Score:2)
Features can be optional (Score:2)
But the standard can stipulate how they are to be implemented IF they are implemented. Nobody is suggesting that a $5 linux chip HAS to have a full JVM installed on it.
A pretty good idea (Score:3, Interesting)
I see it from 2 angles:
*) Linux is so easy to develop for because it comes with a C compiler
*) Java is the language all of the schools teach
To keep new programmers interested in linux, java should be a standard (or at least easy) part of linux distros moving forward.
Experienced users can delete it if they don't want the bloat of it.
Next step, take the butt-ugly out of the java gui widgets.
Re: (Score:2)
How are you "paying" for anything here? Please explain.
The Number one reason for Java as a Linux standard (Score:2)
Third-party vendors really like it when there a real, Sun-certified java implementation available as /usr/bin/java. It makes installation and deployment MUCH simpler.
Java app vendors see Linux as just another platform. This puts Linux in the same league as Solaris as far as they are concerned.
Ther are no patent encumberances on Java (Score:3, Informative)
Unlike mono.
Java is standard in ways that mono will never be.
"Anonymous Coward" is a really accurate description of your attitude.
Re: (Score:2)
Yes, you are mistaken about there being a standard way to run java on Linux. This is EXACTLY what LSB is for.
If you, Anonymous Coward, want to put mono in the LSB, then get started and present a proposal.