Slashdot Mirror


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

12 of 126 comments (clear)

  1. Source by Enderandrew · · Score: 3, 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.

    --
    http://blindscribblings.com - Tasty pop-culture in conceptual fashion.
    1. Re:Source by tenco · · Score: 3, Interesting

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

    2. Re:Source by Jason+Earl · · Score: 3, 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.

    3. Re:Source by thule · · Score: 3, 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.

    4. Re:Source by Schraegstrichpunkt · · Score: 3, Informative

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

      Press Ctrl-C sometime.

    5. Re:Source by ivan256 · · Score: 3, 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*).

  2. Will this FINALLY mean... by Anonymous Coward · · 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!

    1. Re:Will this FINALLY mean... by crow · · Score: 3, Informative

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

  3. And your point is what? by FranTaylor · · Score: 3, 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?

  4. GPL!!! by FranTaylor · · Score: 3, Informative

    The only Java implementation released under the GPL is 1.6.

    I think that's a pretty overwhelming reason.

  5. Re:GNU java is not java by Benanov · · Score: 3, Informative

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

  6. Re:Every language is an emulator by jlarocco · · Score: 3, Informative

    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.