Forgot your password?
typodupeerror
This discussion has been archived. No new comments can be posted.

Java Trial Support Coming In Linux Standard Base

Comments Filter:
  • Source (Score:4, Interesting)

    by Enderandrew (866215) <enderandrew@gm[ ].com ['ail' in gap]> on Wednesday November 12, 2008 @02:44PM (#25737547) Homepage Journal

    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)

      by NekoXP (67564)

      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)

        by Enderandrew (866215)

        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)

          by Jason Earl (1894) on Wednesday November 12, 2008 @03:36PM (#25738303) Homepage Journal

          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)

            by FranTaylor (164577)

            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: (Score:2, Interesting)

        by squiggleslash (241428)

        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

        • by mweather (1089505)
          Well, there's always alien.
          • by aweraw (557447) *

            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?

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

        • by X0563511 (793323)

          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.

          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.

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

        by tenco (773732) on Wednesday November 12, 2008 @03:12PM (#25737951)

        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)

          by thule (9041) on Wednesday November 12, 2008 @05:20PM (#25739659) Homepage

          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)

            by ld a,b (1207022)

            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

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

                by J.Y.Kelly (828209)

                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

            • by multi io (640409)
              There is this magnificent front-end -aptitude- that runs circles around everything else.

              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:

              • much faster for many queries (cf. rpm -qf vs. dpkg -S)
              • better, more systematic and more powerful command line syntax (grouped options)
          • by NekoXP (67564)

            What if the number of debian-based distros is based on the deficiencies of debian. ;)

            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)

            by Schraegstrichpunkt (931443) on Thursday November 13, 2008 @08:02AM (#25745489) Homepage

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

            Press Ctrl-C sometime.

          • by ivan256 (17499)

            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.

      • by shaitand (626655)

        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.

      • by Draek (916851)

        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.

        • by NekoXP (67564)

          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.

          • by Draek (916851)

            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,

            • by NekoXP (67564)

              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

    • by pembo13 (770295)
      Maybe it's time to merge .deb and .rpm and apt and yum, and finally do away with this mostly ridiculous difference.
    • by FranTaylor (164577) on Wednesday November 12, 2008 @03:42PM (#25738377)

      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?

      • by ivan256 (17499)

        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)

      by Ed Avis (5917)

      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.

  • I for one do not welcome any new Java judicial overlords or any other sort of Java-based justice systems.
    • 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.

      • Re: (Score:3, Funny)

        by wbren (682133)

        Don't you mean java.lang.Exception?

    • Ahhh, jealous of the garbage collection, and tempted by the C-like syntax, are we? :)

      Fear not, fellow camel-caser, Linux already has Binary Kernel Support for Linux [mjmwired.net]!
      • Linux already has Binary Kernel Support for Linux!

        Dang, didnt know it was compatible with itself.

        • by Gazzonyx (982402)
          D'oh! Freakin URL copy and paste!
        • by idontgno (624372)

          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)

      by Hatta (162192)

      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.

      • by rdean400 (322321)

        The JVM is not an emulator. It would be more realistic to think of it as a runtime compiler.

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

  • by Anonymous Coward on Wednesday November 12, 2008 @02:55PM (#25737709)

    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!

    • by Spand (980339)
      The Java 6u10 update fixed a bunch of issues with applets including 64bit support and faster load times.
    • by LDoggg_ (659725)
      This has been working 64bit openjdk for some time.
      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.
      • by LDoggg_ (659725)
        oh, you just said you're on OpenSuse :)

        No idea if there's a package in it's repo, but that's Suse's fault, not openJDK's or Sun's.
    • 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. ;)

    • by Cyberax (705495)

      Try OpenJDK. It has 64-bit browser plugin and WebStart runner.

      Use run "sudo apt-get install icedtea6-plugin" and enjoy 64-bit applets :)

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

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

  • If you're looking for a locked down, certified, guaranteed lowest-common-denominator Linux platform, why not go with Java 1.4.2? Even though (because) it's end-of-lifed, it's not going to change, Sure, it's got language incompatibility issues with 1.5, but it's a well-known item. Test and certify your Java app for LSB on 1.4.2 and you know the platform isn't going to change under you.
    • by Nimey (114278)

      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?

      • by Gazzonyx (982402)
        I don't think EE is up to 1.6 yet. Although SE 1.7 is getting ready to roll, so EE 6 can't be far behind.

        BTW, IIRC, we're at version 1.5.16 and 1.6.10.
      • Yes, the minor dot releases are typically bug fixes. There were, however, major additions to the language/compiler itself with the 1.5 release. The 1.4.2 release can be thought of as the "last" Java 2 release, which is why I'm suggesting it.
    • by FauxPasIII (75900)

      Is Java 1.4.2 freely redistributable the way recent versions are?

    • by sjames (1099)

      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.

      • That was unfortunate hype from the 1.0.2 days. Compare to the x86 instruction set, which is backward compatible, but 486s don't know what to do with the new instructions. Ever notice the i386 bit in many Linux RPMs? Same thing.
      • 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?

        • by sjames (1099)

          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.

        • by tepples (727027)

          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)

      by FranTaylor (164577) on Wednesday November 12, 2008 @03:57PM (#25738575)

      The only Java implementation released under the GPL is 1.6.

      I think that's a pretty overwhelming reason.

  • 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

    • by pembo13 (770295)
      Fair enough, but a mature cross platform environment like Java seems like a necessary addition.
    • 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.

    • by gbjbaanb (229885)

      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)

    by NaCh0 (6124) on Wednesday November 12, 2008 @03:20PM (#25738077)

    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.

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

  • by Yfrwlf (998822)
    The LSB really needs to change it's position as a pre-installed program enforcer to a normal standards body. Standards bodies should not try to make users have certain programs installed by default, they should promote and help out with the APIs for software that is common, has great potential, and popular, or otherwise where it's needed. They should be vying for program interoperability. Then, if I need a newer version of Java to be installed, or another simultaneous version to be installed, or whatever

"If that makes any sense to you, you have a big problem." -- C. Durance, Computer Science 234

Working...