Java Trial Support Coming In Linux Standard Base 126
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."
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.
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*).
Re: (Score:2)
I'm talking about install time options. Basic configuration of an application's essential options through an OS-unified interface.
With RPMs, you have to live with the initial configuration that the packager/builder chose (The pre/post installation scripts are required to be non-interactive). With DEBs, and other OS packages, you can tweak configuration settings at install time. And with DEB in particular you can choose to have it behave like an RPM and do what the package builder decided, or you can have it
Re: (Score:2, Interesting)
Re: (Score:2)
Re: (Score:2)
I've used alien - at least I tried to. IMO the results are not consistent enough for it to be genuinely useful. Some package worked after conversion (from RPM->DEB), but most did not.
Has any body had any experience with alien converting from DEB->RPM? Are the results any better than the failures I've experienced with RPM->DEB conversion?
Re: (Score:2)
I've never had an alien failure, over about six-ish years. Moderate usage.
I have had to track down dependencies a few times, though.
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: (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.
I'd say it's the reverse: Debian Policy is the reason why APT/DEB are so good. Because Debian Policy could say "thou shalt place a file in /usr/share/menu", stuff like the "menu" package (which centralized the management of various window managers' application menus) actually happened before any other distro had it.
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).
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.
Re: (Score:2, Interesting)
Well, yum is an apt clone wrapped around the useless RPM format, so it is only natural that it approaches now many years later its functionality.
However, nobody with a right mind uses apt in Debian or debian derived distros. There is this magnificent front-end -aptitude- that runs circles around everything else. Maybe Synaptic is what is leading you to believe that Ubuntu is as limited as your distro of choice. It is not, it's just that most options are hidden or made difficult to use by bad design.
Really p
Re: (Score:2)
I believe it's slower because RPM has finer-grained package management (which is probably useless to most people). Someone can correct me on this, but I think RPM's dependencies are handled by file name, rather than by package name. The dependency checks tend to take longer, consequently.
On a modern system, the difference seems hardly noticeable now (in YaST, at least).
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)
http://user.cs.tu-berlin.de/~klischat/aptitude-hell-1.txt [tu-berlin.de]
http://user.cs.tu-berlin.de/~klischat/aptitude-hell-3.txt [tu-berlin.de]
Advantages of RPM over DEB:
Re: (Score:2)
Bingo :)
I don't know why you focus on yum - it's absolutely terrible. Have you tried zypper in openSUSE? It's faaast, isn't broken like apt and with LZMA compression and delta RPMs, there's really nothing so wrong with RPM anymore from the user side.
Actually I never understood what the problem was with RPM anyway, or why users are so against it. As a developer, I can understand that writing specs and building RPMs is a bitc
Re:Source (Score:4, Informative)
But seriously, I don't see that yum is inferior to apt.
Press Ctrl-C sometime.
Re: (Score:2)
What if the number of debian-based distros is based on the deficiencies of debian. ;)
I'm sure you meant that as tongue in cheek, but I'm also sure that the number is based on the ease in which you can make a Debian based distribution. Hell, there's a package in the Debian repository that you can install and run to make yourself a custom distribution in just a handful of commands.
Re: (Score:2)
Well, I've got Java applets working on 64 bit kubuntu, I can't recall how I made it happen though.
Either way, mobile devices are rarely based on a 64 bit architecture.
Re: (Score:2)
I beg to differ. Although the success has little to do with deb, it certainly has a lot to do with the quality of the distro and the massive debian software repository it shares.
Re: (Score:2)
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..
Of course, but that doesn't mean it's not better.
Re: (Score:2)
It does mean you need to give a couple more reasons than "it's popular" and "it doesn't use RPM" to actually qualify it as being better.
I really don't see anything in Ubuntu that I don't also see in SuSE 6 months before or Fedora 6 months later.
Re: (Score:2)
For Ubuntu, well, it works :D so did Fedora last time I tried it, though, and haven't used SuSE in almost half a decade, so I can't say whether it's "better" than either of them, but I haven't seen anything that'd make me say it's "worse", either. .DEBs, though, were originally better than .RPMs in that the dpkg+apt combo was *way* more useful than rpm alone ever was, and though that changed with yum, inertia plus the more standardized naming format (inherited from Debian) have kept me in the .DEB camp and,
Re: (Score:2)
Each to their own. Since it's my job to make sure distros work on hardware we build, I have to try them all, but SUSE has been by far more comfortable in terms of support, features, and ease of use.
Zypper + RPM really is a pleasure. I never liked yum.. RedHat/Fedora and YellowDog are good distros but I do think package management lets them down (along with Fedora's "open-source-only" stance). Ubuntu is pioneering on bundling things users want to use but SUSE really does the same stuff. It's basically a tie
Re: (Score:2)
Why don't you read the "minimum system requirements" for an operating system before you bother to install it?
By your reasoning we should dump Gnome, compiz-fusion and Firefox, because they all run like crap on your old hardware.
Re: (Score:2)
I was just illustrating the crap programming in the RPM based systems smartass. Testing software on low-end hardware gives a good indication of the overall design quality.
Fact is, RPM based systems are a lot less efficient. It's slower on a fast machine too, duh!
Re: (Score:2)
RPM has nothing to do with the "efficiency" of my system. It spends approximately 0.01% of its runtime executing the rpm binary. I do not see any efficiency to be gained from using another program.
Re: (Score:2)
"Testing software on low-end hardware gives a good indication of the overall design quality."
What a bogus thing to say. Testing software on the hardware it is intended to be deployed on is the ONLY indication of overall design quality.
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?
Re: (Score:2)
Replace it with DFSG+DFHS [debian.org]... You could toss the Java and Menu policies in there too for good measure...
LSB lets third parties put their crap almost anywhere they want on your system and they're still compliant (Did that package you just installed land in /usr, /usr/share, /opt? Is it's data under it's own directory, or is it in /srv, /var, or /home/something? Are its configuration files in /etc, or somewhere else?). We essentially *have* chaos. Third party (commercial) software almost entirely abandons the
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.
Re: (Score:2)
package managers are not the answer. I've used EPM, which you mention in your blog, extensively. I've even patched it to the gills to suit my needs (relocatability for non-root installs and being able to go back in the wizard). EPM helps a little but the chuck of the work is being able to produce a mostly-static executable, otherwise you need a package for each distribution update, which is unmanageable. However, this is exactly where LSB comes in : provide a decent set of libraries I can rely on.
Source dis
As a C++ programmer... (Score:2)
Re: (Score:1)
What... having trouble bringing home the bacon on C++? Why not learn both so that way you won't be made irrelevant by the supreme Java PHB overlords.
I have just one thing to say about that... (Score:2)
OBJECTION!
Re: (Score:3, Funny)
Don't you mean java.lang.Exception?
I got yer message body right here... (Score:2)
1. Don't use your subject field as a discussion field. Use the post body. This goes for your parent as well.
2. Don't you mean "EXCEPTION!?"
1: I didn't.
2: No.
Re: (Score:2)
1. Yes you did. "I have just one thing to say about that..." was in your subject.
2. Humor fail.
Re: (Score:2)
1. Yes you did. "I have just one thing to say about that..." was in your subject.
2. Humor fail.
1: Right. The subject said I had something to say, the message body said it. Simple enough.
2: Really, what is it with this "X fail" crap? Like people can't make sentences any more? I could loan you a verb if you like...
Re: (Score:2)
Could you?! I've been running low, and have been trying to conserve.
(at this point I'm just yanking your chain)
Re: (Score:2)
Could you?! I've been running low, and have been trying to conserve.
Well, I just went over my stock and I think I could spare "immolate", "vilify", and "google". The last one might not actually be a real verb. I guess I won't be able to use the old "Immolation is the sincerest form of flattery" again until I stock up...
As a Java programmer... (Score:2)
Fear not, fellow camel-caser, Linux already has Binary Kernel Support for Linux [mjmwired.net]!
Re: (Score:1)
Linux already has Binary Kernel Support for Linux!
Dang, didnt know it was compatible with itself.
Re: (Score:2)
Re: (Score:2)
And there, you see, is the point...nay, the TRIUMPH... of the Linux Standard Base. Linux binaries which are compatible* with the Linux Kernel!
*for compatible hardware architectures, library file locations and versioning, configuration settings, and other dependencies... YMMV. Take only as directed. May cause drowsiness; please do not drive or operate heavy equipment while executing Linux binaries.
Re: (Score:1, Flamebait)
It is a pretty silly thing to put in the standard. The JVM is essentially an emulator. If you're going to include emulators, why not put Dosbox in the LSB? If I'm looking for a Linux native application, it's not going to be enough anymore to know that it's LSB compliant, which kind of defeats the whole purpose.
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.
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.
Re: (Score:2)
You're confusing programming languages with their implementations.
Your statement:
just isn't true.
A programming language is an abstraction that hides hardware details, while "emulator" is a well defined word meaning "a piece of software or hardware that executes programs meant for another piece of hardware".
Some language implementations use emulation, but it's not a requirement - it's an imp
Re: (Score:2)
Re: (Score:2)
Yes it is. There's a difference between "Java-the-platform" and "Java-the-language". Java byte-code and the JVM are part of Sun's Java platform - not part of the language.
There are Java compilers that do not emit bytecode for a JVM.
Re: (Score:2)
They are not part of Sun's Java platform. They are part of anything that can call itself Java (because Sun still controls the trademark, and using JVM bytecode is a requirement to use it). Which is why GCJ ,BEA, IBM and other Java implementations all also use the same bytecode format, and Java classes compiled by them all are interchangea
Re: (Score:2)
You're missing the point. There's a difference between the implementation and the language. Sun requires all Java implementations be compatible with theirs in order
Re: (Score:2)
Re: (Score:2)
Fine, think of it this way: I can build a processor that directly executes Java byte code, therefore it wouldn't require a software implementation of the JVM, and so wouldn't be running in an emulator. Making the OP's "Every programming language is an emulator" statement false, even for Java.
I don't even know why you're wasting your time arguing about this. The issue was the truth of the statement "Every programming language is an emulator," not whether Java requires a virtual machine. It's fairly obv
Re: (Score:2)
Every computer simulates a Turing machine.
Discuss.
Re: (Score:2)
Why your argument has no merit:
Java bytecode serves the same purpose as any typical CPU architecture's bytecode. An X86 C compiler is compiled into x86 bytecode, and 'Java' compiler's create Java bytecode. The large difference is that Java bytecode requires a lot more behind-the-scenes CPU constructs that must be implemented in software for lower level architectures.
By your presupposition, X86 C is an emulation, because a programmer doesn't see/control memory segments? Because memory mapped I/O is more or l
Re: (Score:2)
You're confused. I'm not arguing for or against Java in the LSB. I don't even care.
I was just pointing out that the statement "Every language is an emulator" is false. Every language is an abstraction layer over hardware, but the phrases "abstraction layer" and "emulator" are not the same thing.
If it's involved at all, emulation would be an (unnecessary) implementation detail.
Re: (Score:2)
Imagining a virtual machine helps explain the abstraction provided by the language. But that doesn't make the language an emulator. It doesn't even make sense that you'd jump to that conclusion.
It's not fucking rocket science.
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.
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:1)
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).
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: (Score:2)
No idea if there's a package in it's repo, but that's Suse's fault, not openJDK's or Sun's.
Re: (Score:2)
In a similar situation I would install the 32-bit version of another browser (Opera or something) and then run that browser solely for the purpose of running the 32-bit stuff I needed.
I actually didn't know that many people actually used Java applets in the browser these days. I thought those went out of style like 10 years ago when people realized scripting made more sense than compiled stuff. ;)
Re: (Score:2)
Try OpenJDK. It has 64-bit browser plugin and WebStart runner.
Use run "sudo apt-get install icedtea6-plugin" and enjoy 64-bit applets :)
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?
Re: (Score:2)
Because I would rather not demand that the world upgrade, particularly on embedded devices?
Mostly, it's just my cynical take on the JAva hype (starting with the JVM NOT being such a new concept when it was hyped as just that in the '90s).
If not for people drinking the cool-aid and then wondering why I say I can't use their whatever that requires the bleeding edge runtime, I wouldn't care at all since I don't do Java.
Re: (Score:2)
Or were you thinking of running new code on an old JVM? If so... why?
Because the maker of a given device either hasn't yet ported or declines to port the newer JVM.
GPL!!! (Score:4, Informative)
The only Java implementation released under the GPL is 1.6.
I think that's a pretty overwhelming reason.
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.
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.
Re: (Score:2)
Not necessarily, the LSB can have a standard for every language under the sun, you don't have to use all of it. I know that sounds like 'why bother then', but it means that if you want to code java, then you will have java in /usr/bin/java and you can code with that in mind. When you then install java using a rpm/deb you know where it'll end up being installed to.
That's what makes the difference. Windows is partly successful because you can code for it, and know what you'll be getting. OK, sometimes you nee
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.
Why? (Score:2)
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)
How do you know that?
How do you know that?
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.