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

[mweather]

Well, there's always alien.

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

[pembo13]

Maybe it's time to merge .deb and .rpm and apt and yum, and finally do away with this mostly ridiculous difference.

Re:Source

[X0563511]

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.

Re:Source

[shaitand]

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

[FranTaylor]

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

[Cthefuture]

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

[FranTaylor]

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

[FranTaylor]

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

[Threni]

Ubuntu isn't as well suited for mobile devices as fedora is?

It's not very well suited for people who want to use java in the browser in 64 bit Ubuntu. I have no idea why this is so hard to achieve, but it's the main reason I can't use 64bit Ubuntu. Even Flash works, and that's not even open source!

Re:Source

[Draek]

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

[3p1ph4ny]

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

[HuguesT]

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 distribution works if you have a very good configure script, which is damn hard to do for any complicated application using more than a handfull of libs.

In my apps, the amount of work on the configure script is decidedly non-trivial. LSB still helps for source distribution because you can assume more of the destination platform.

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

[NekoXP]

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 bitch, but it's really no more difficult than debian's "rules" system. There is far more likelihood of dependency hell with apt than with RPM, too, because of the way dependencies are handled by apt itself (not the .deb packaging format, which is for all intents and purposes, well defined, just not used properly)

As for LSB, it should be hit on the head, and it's little fellow project FHS really needs to go the way of the Dodo. The current standard and the way current distros are built and maintained on that archaic, stupid layout is just redundant. The idea of dumping every app in /bin, /sbin/, /usr/bin, /usr/sbin, /usr/local/bin, /usr/local/sbin, /opt.. what layout your init scripts need to have and which functionality they need to adopt (this is a real chore considering we are all focussing on booting real fast now, and doing it in shell scripts for LSB compatibility is really not going to work) or whatever FHS/LSB says, along with is really quite retarded.

What we need is an LSB which defines a nicer way of working; Apple had the balls to move with the times, now you get "drop a folder on a system and it's installed" ease of use, directories with names that mean something to real people.. and still it's compatible with 99.9% of applications from the Unix world (and if you use autoconf, cmake, scons or any other build system it doesn't matter what layout you use as they will all pretty much install into the right places on each system anyway)

Without an ABI/API spec as included in LSB you'd have to rebuild your package for every Linux distro but guess what - even with LSB right now and Red Hat and others "conforming" to it, people still build their packages for every different distro, because of the HUGELY varying support inside those distros which aren't defined by LSB. On MacOS X every OS release brings some major new support for some major new functionality; and people rebuild their apps and implement support. And you get to download it for your new OS (it still works on the old one, though, it's really difficult to imagine that someone absolutely destroyed binary compatibility up the line.. but if they did they were due to use some new functionality anyway!)

Re:Source

[NekoXP]

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

[spirit of reason]

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

[aweraw]

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

[Undead NDR]

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.

What's more, Apt has been usable with RPM packages on RPM-based distros for quite some time.

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?

~# yum -C info apt
Loading "protectbase" plugin
Loading "kernel-module" plugin
691 packages excluded due to repository protections
Available Packages
Name : apt
Arch : i386
Epoch : 1
Version: 0.5.15lorg3.2
Release: 72.el5
Size : 952 k
Repo : atrpms
Summary: Debian's Advanced Packaging Tool with RPM support
Description:
A port of Debian's apt tools for RPM based distributions, or at least
originally for Conectiva and now Red Hat Linux. It provides the apt-get
utility that provides a simpler, safer way to install and upgrade packages.
APT features complete installation ordering, multiple source capability and
several other unique features.

Re:Source

[Schraegstrichpunkt]

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

[Schraegstrichpunkt]

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

Press Ctrl-C sometime.

Re:Source

[Draek]

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, therefore, using Ubuntu.

Re:Source

[NekoXP]

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 between the big 3 (Ubuntu, SUSE, Fedora) on which is the "best".

If I was giving a system to my grandmother it'd still be Windows XP/Vista though, none of them are really suitable for people who don't use computers as much as I/we do. Even I stumble over something braindead or frustrating sometimes in Ubuntu and I dread to think where that would go with someone who didn't know their way around a Linux distro.

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

Re:Source

[ivan256]

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

[multi io]

There is this magnificent front-end -aptitude- that runs circles around everything else.

http://user.cs.tu-berlin.de/~klischat/aptitude-hell-1.txt

http://user.cs.tu-berlin.de/~klischat/aptitude-hell-3.txt

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)

Re:Source

[Undead NDR]

Apt "for RPMs" is basically useless without a unified repository.

It's not useless, it's mostly equivalent to Yum. Maybe a tad faster, but that's it. In both cases you need repositories that go along well dependency wise.

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

Not sure what you mean by "configuration". If you're talking about build options, you can rebuild an SRPM with a different configuration.

Re:Source

[ivan256]

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 prompt you at a specified level of importance. Better yet, you can re-run the configuration process at any time. Additionally, because of the implementation, you can remove a package without removing its configuration if you'd like, and install a new version of the same software that has incompatible configuration files, but still retain your configuration.

Those are basically the only differences between DEB and RPM... But they're significant.

Re:Source

[Count Fenring]

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

[Undead NDR]

Oh, OK. I remember from my Debian days the odd package offering an install screen. On RPM-based distros, different configurations are usually provided by different packages or metapackages.

As a C++ programmer...

[internerdj]

I for one do not welcome any new Java judicial overlords or any other sort of Java-based justice systems.

Re:As a C++ programmer...

[rdean400]

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

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

[Spand]

The Java 6u10 update fixed a bunch of issues with applets including 64bit support and faster load times.

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

Re:Will this FINALLY mean...

[LDoggg_]

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.

Re:Will this FINALLY mean...

[LDoggg_]

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.

Re:Will this FINALLY mean...

[Cthefuture]

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

[Cyberax]

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

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

Re:Will this FINALLY mean...

[Anonymous Coward]

64-bit support is deferred to a future release.
    xxxxx@xxxxx 2005-06-01 21:40:27 GMT
This RFE has fianaly been comitted to the dolphin (JDK 1.7) release.
Posted Date : 2007-01-16 22:20:04.0

We have not only commit this RFE to JRE 7, but also JRE 6 update release.

The date for JRE 6 update release which has this 64bit JRE support will be early 2009.
Posted Date : 2008-04-09 16:57:04.0

Just an update......
The development/testing of the 64-bit plugin is underway and will be added to JDK6, sometime after the 6u11 release. Stay tuned!
Posted Date : 2008-10-10 21:56:24.0

We are targeting to support this feature in JRE 6u12, we will support Java Plugin/Java webstart on AMD64 arch on both Window and Linux platform.

On linux, we will support Java plugin only on Firefox 3 64bit browser, due to 64bit Firefox is not available on Solaris OS yet, we won't support 64bit Java plugin and Java webstart on Solaris platform at this moment.
Posted Date : 2008-10-13 19:31:42.0

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

[Tetsujin]

OBJECTION!

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

[wbren]

Don't you mean java.lang.Exception?

Ooo a standard!

[christoofar]

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

I probably don't get this, but...

[$RANDOMLUSER]

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.

Re:I probably don't get this, but...

[Nimey]

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:I probably don't get this, but...

[FauxPasIII]

Is Java 1.4.2 freely redistributable the way recent versions are?

Re:I probably don't get this, but...

[sjames]

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:I probably don't get this, but...

[Gazzonyx]

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.

Re:I probably don't get this, but...

[$RANDOMLUSER]

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.

Re:I probably don't get this, but...

[$RANDOMLUSER]

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.

Re:I probably don't get this, but...

[csnydermvpsoft]

Or you could use a newer JVM. With the exception of a few well-documented issues, 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:I probably don't get this, but...

[sjames]

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:I probably don't get this, but...

[tepples]

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.

Keep the base small

[Hatta]

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 have a standard base at all?

Re:Keep the base small

[pembo13]

Fair enough, but a mature cross platform environment like Java seems like a necessary addition.

Re:Keep the base small

[gbjbaanb]

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 need to install an updated package but that's it, and once installed you're completely ready to go.

It not much of a difference from what we have today... except when I install an app on Centos it ends up in one directory, on Debian it ends up somewhere else. That's really not so good for development. As for minimum versions, that just means only certain releases of distros will end up supported, but that's no different from today anyway, if you get java 1.4 on Centos3 but the LSB mandates java 1.6, and Centos 5 supports it, then support for Centos3 will just fade away.

So the LSB is a sensible thing, that shouldn't cost anyone much at all.

As a Java programmer...

[Gazzonyx]

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!

Re:As a Java programmer...

[mrwolf007]

Linux already has Binary Kernel Support for Linux!

Dang, didnt know it was compatible with itself.

Re:As a Java programmer...

[Gazzonyx]

D'oh! Freakin URL copy and paste!

Re:As a Java programmer...

[idontgno]

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.

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.

Re:A pretty good idea

[FranTaylor]

How are you "paying" for anything here? Please explain.

Re:A pretty good idea

[Anonymous Coward]

*) Java is the language all of the schools teach

That is because most of the schools suck, and the coders they put out are idiots.
Any decent CS major should have exposure to C and ASM, in addition to Java.

Don't get me wrong, I love Java & use it a lot, and it is really nice for teaching a lot of concepts. The problem is that if you ONLY learn Java, you program in this idealistic dream world that says you don't have to worry about platform differences or available resources.

When I give interviews for coders, I give them a couple of tests. The Java-only CS grads can deliver when they have a question that says "Write a robust program to do X, which can be updated with Y without changing X, and still allowing the possibility of adding Z in the future".
When I tell them to do it in a situation where they only get 1 meg of ram, and 1kbps of network capacity, they have no clue where to even start... because they were taught that it doesn't matter what the target hardware or OS is, because Java is cross-platform.

As a result, when you tell them "I have X dollars to buy equipment, and Y dollars to pay for the internet connection, and we need to support Z users" they can't even comprehend how to approach the problem. Because they were taught that such constraints don't matter (& in CS theory they don't) but in the real world they matter very much.

Re:A pretty good idea

[Anonymous Coward]

You can't uninstall it. Well, you could, but it would make your life difficult. The point of having it in the LSB is not so much for the end user, but so that other packages can assume it is present. Try installing closed source (binary) packages - that's what the LSB is really meant for. Maybe that's why it is more of a Redhat than a Debian thing.

Not that I'm against including Java in a standard manner...

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?

Re:And your point is what?

[ivan256]

Replace it with DFSG+DFHS... 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 standard due to its deficiencies, and does whatever it pleases using a myriad of third-party installers. Even Microsoft got with the picture and made MSI, turning RPM into a further embarrassment.

Alternatively, LSB could be scrubbed of the stupid political concessions and re-written by an independent body with no ties to any of the big corporate distributions. It should include strict filesystem guidelines (one place for configuration files. one place for libraries, etc), and a packaging format that allows for interactive installations as well as scriptable installations.

As a multi-lingual developer...

[FranTaylor]

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.

Ooo a standard indeed!

[FranTaylor]

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.

GPL!!!

[FranTaylor]

The only Java implementation released under the GPL is 1.6.

I think that's a pretty overwhelming reason.

GNU java is not java

[FranTaylor]

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

[Benanov]

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

Re:GNU java is not java

[FranTaylor]

I was justifying my use of the word "only".

The Number one reason for Java as a Linux standard

[FranTaylor]

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.

Features can be optional

[FranTaylor]

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.

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.

Re:Ther are no patent encumberances on Java

[shutdown -p now]

Ther are no patent encumberances on Java

How do you know that?

... unlike mono.

How do you know that?

Re:Why Java and not Mono?

[FranTaylor]

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.

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.

Transmogrificator...

[CTalkobt]

From vi,
    1,$s/\(.\)\(.\)/\2\1/g

will yield a copy of your file which looks disturbingly different.

Doing the command again, will yield the original file.

For even more confusion, try :
    1,$s/\(.\)\(.\)\(.\)/\3\2\1/g

Repeat and rinse as necessary...

Re:Transmogrificator...

[CTalkobt]

Ack thppt - ignore above - I got topic switched...

I got yer message body right here...

[Tetsujin]

I have just one thing to say about that... OBJECTION!

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:I got yer message body right here...

[X0563511]

1. Yes you did. "I have just one thing to say about that..." was in your subject.

2. Humor fail.

Re:I got yer message body right here...

[Tetsujin]

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:I got yer message body right here...

[X0563511]

I could loan you a verb if you like...

Could you?! I've been running low, and have been trying to conserve.

(at this point I'm just yanking your chain)

Re:I got yer message body right here...

[Tetsujin]

I could loan you a verb if you like...

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

Why?

[Yfrwlf]

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 I want, I can do that using dependencies and and as long as I have the freedom to easily install any Java package I want to. Then, why bother making it's existence a standard? If it is good, and it's something users want, they will come.

The LSB should really take a chapter from the pages of the Free Desktop, W3C, or other standards bodies that actually function well and help provide that program interoperability.

What's that? I ran iotop but it's not installed, but I can run apt-get install iotop to get it? Gosh, that's difficult, I dunno if I can handle doing that with all those letters and commands and shit. If you want a certain program to come default in your installs, that's what rolling your own "distro" is for, not that there aren't a hundred other methods of software deployment you can use.

Re:Every language is an emulator

[ADRA]

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 less magic to the non-kernel developer?

LSB is all about determining the standard development and runtime standards so that for instance my C program's "long long" is always going to be 8 bytes.

LSB adopting a standard for java implementations means that the java runtime (or native coprocessor) supported by the an OS will implement the runtime in the same way as any other Java LSB implementer.

Sun all but controls the java spec, so there's little worries of implementation divergence, but its a nice symbolic gesture to say hey, we think of Java as a first class citizen of the OS, and not some tack-on afterthought that many distributions (read: all of them) implement poorly today.

Finally, LSB covers a large number of architectures, but I'm pretty sure that most of the member groups don't support or care about many of them, like the S390 for instance. Just because Java is mentioned in the spec, it doesn't mean that every LSB implementer will use java. What I 'hope' it'll mean is that every Java implementer will do it in a compatible way.

Re:Every language is an emulator

[jlarocco]

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

[jlarocco]

You're confusing programming languages with their implementations.

Your statement:

Every language is an emulator ... For the virtual environment that it presents to the application developer.

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 implementation detail. It's not even a requirement for the two languages you mentioned. There are Java compilers that compile straight to native code, and there are ways of getting native code from Perl.

Re:Every language is an emulator

[shutdown -p now]

Java bytecode format is also specified, and that spec is an integral part of the whole Java-the-platform thing. It's not an implementation detail.

Re:Every language is an emulator

[jlarocco]

Java bytecode format is also specified, and that spec is an integral part of the whole Java-the-platform thing. It's not an implementation detail.

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

[jlarocco]

Note: even experts on C occasionally discuss the implications of the C standard in terms of "the C virtual machine" - you can find the evidence by searching comp.lang.c on google groups.

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.

Re:Every language is an emulator

[shutdown -p now]

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.

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

GCJ working in a native mode is not a Java compiler. It's a compiler of a language that is 100% Java-compatible, but it's not a Java implementation (because Sun says so).

Re:Every language is an emulator

[jlarocco]

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

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 to use the "Java" trademark. And their implementation uses a virtual machine (emulator). But there's nothing inherent in the Java language itself that requires using a virtual machine. It's a purely artificial requirement put on by Sun in order to use their trademark. It's an implementation detail.

It's irrelevant anyway, because even for Sun's Java platform, the virtual machine is the emulator, not the language itself. So the OP's statement is still stupid. If he had said "Any language can be compiled to run on an emulator," or something like that, I would never have even said anything. But his statement "All languages are emulators," is simply incorrect.

GCJ working in a native mode is not a Java compiler. It's a compiler of a language that is 100% Java-compatible, but it's not a Java implementation (because Sun says so).

Now you're just being ridiculous. Just because "Sun says so" doesn't make it not a Java compiler. They can't legally call it a Java compiler, but that doesn't change the fact that it is one. If Sun told you the sky was green, would you believe that too?

Re:Every language is an emulator

[shutdown -p now]

Java-the-language is specified in the Java Language Specification. Part of that specification covers runtime behavior - and that part explicitly uses terms such as "Java virtual machine", "verification", "class loader" etc. So, yes, the Java language specification mandates certain library and runtime facilities - such as class loaders - that must be able to e.g. dynamically load a Java class from a stream with bytecode in proper (specified) format.

Re:Every language is an emulator

[jlarocco]

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 obvious that you recognize that the JVM is the emulator and not the actual language itself.

Re:Every language is an emulator

[MasterOfMagic]

Every computer simulates a Turing machine.

Discuss.