Java Trial Support Coming In Linux Standard Base

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."

Comments

Source

[Enderandrew]

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:Source

[NekoXP]

It took off like a rocket and then Intel dumped it for an RPM-based distro.

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:Source

[Enderandrew]

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

[squiggleslash]

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 built on Debian, which is how it ended up with APT/DEB in the first place.

I do agree with the GP's point that the LSB looks increasingly ridiculous standardizing on a packaging system that isn't common to most GNU/Linux installations. The LSB will not be relevant unless the standards it promotes are actually adopted. Of course, it'd be nice to see the RPM people work with the DEB people and come up with some interoperability.

Re:Source

[tenco]

It took off like a rocket and then Intel dumped it for an RPM-based distro.

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

[Jason Earl]

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.

Re:Source

[thule]

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:Source

[Ed Avis]

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:Source

[ld a,b]

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 package management in RPM based linuxes leaves me wondering how can it be that nobody from inside has noticed it is broken. I don't know the technical details that make it so, but it is invariably either much slower, unstable, or both.

Once I checked M*** out. A nice system with a great Desktop. I asked why I couldn't browse the package description. A dev told me it was because they had optimized it out. Their benchmarks showed it was a bottleneck. Nice. Updating the sources still took ten times more than in Ubuntu(Which has one of the very best extensive repositories). BTW, downloading a single description on demand still took 10 seconds. FAmazing!

DEBs have never destroyed my system. I wish I could say the same for F***'s RPMs. Its users are just used to it. L*** T*** couldn't manage to install a flash plugin in His distro of choice and nobody in the RPM camp raised an eyebrow. FAmazing!

Some distributions have slowly fixed RPM so that it is beginning to be usable. So what? If they had made DEB the standard, instead of bending to the RedHat lobbying, by now we would have a much better Linux than we do.

Mod -1 as much you like, Truth won't go away.

Re:Source

[J.Y.Kelly]

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.

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 package list each time it is run, whereas apt has separate update and upgrade steps. If you run yum with -C (to force it to run from cache), it's about the same speed as apt-get.

Re:Source

[Schraegstrichpunkt]

But seriously, I don't see that yum is inferior to apt.

Press Ctrl-C sometime.

Re:Source

[ivan256]

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*).

Will this FINALLY mean...

[Anonymous Coward]

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:Will this FINALLY mean...

[crow]

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695

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

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).

A pretty good idea

[NaCh0]

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.

And your point is what?

[FranTaylor]

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?

GPL!!!

[FranTaylor]

The only Java implementation released under the GPL is 1.6.

I think that's a pretty overwhelming reason.

Re:GNU java is not java

[Benanov]

Sun Java 1.6 was released under the GPL. GP is not talking about GNU Java.

Re:I have just one thing to say about that...

[wbren]

Don't you mean java.lang.Exception?

Ther are no patent encumberances on Java

[FranTaylor]

Unlike mono.

Java is standard in ways that mono will never be.

"Anonymous Coward" is a really accurate description of your attitude.

Fix it!

[FranTaylor]

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:Every language is an emulator

[jlarocco]

For the virtual environment that it presents to the application developer.

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.

Apparently you failed computer science.

I guess he's not the only one.

Re:Every language is an emulator

[FranTaylor]

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.