Beta

Slashdot: News for Nerds

×

Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

cancel ×

126 comments

Source (3, Interesting)

Enderandrew (866215) | more than 5 years ago | (#25737547)

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 (2, Insightful)

NekoXP (67564) | more than 5 years ago | (#25737687)

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:Source (2, Insightful)

Enderandrew (866215) | more than 5 years ago | (#25737747)

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 (3, Interesting)

Jason Earl (1894) | more than 5 years ago | (#25738303)

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! (2, Insightful)

FranTaylor (164577) | more than 5 years ago | (#25739025)

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 (1)

Undead NDR (1252916) | more than 5 years ago | (#25745419)

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

squiggleslash (241428) | more than 5 years ago | (#25737797)

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 (1)

mweather (1089505) | more than 5 years ago | (#25737949)

Well, there's always alien.

Re:Source (1)

aweraw (557447) | more than 5 years ago | (#25743855)

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 (1)

X0563511 (793323) | more than 5 years ago | (#25738909)

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 (1)

Schraegstrichpunkt (931443) | more than 5 years ago | (#25745485)

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 (3, Interesting)

tenco (773732) | more than 5 years ago | (#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 (3, Insightful)

thule (9041) | more than 5 years ago | (#25739659)

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 (3, Interesting)

ld a,b (1207022) | more than 5 years ago | (#25741069)

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 (1)

spirit of reason (989882) | more than 5 years ago | (#25743337)

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 (2, Informative)

J.Y.Kelly (828209) | more than 5 years ago | (#25744615)

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 (1)

NekoXP (67564) | more than 5 years ago | (#25742943)

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 (1)

Threni (635302) | more than 5 years ago | (#25739929)

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 (1)

3p1ph4ny (835701) | more than 5 years ago | (#25740269)

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 (0)

Anonymous Coward | more than 5 years ago | (#25738879)

Look, the RPM package managers are slow as shit compared to DEB based systems. Just try running Fedora on a low-end laptop (266 Mhz or so) and then doing an update. It sits there and chunks along using tons of memory, 100% CPU and grinding the hell out of the drive.

Debian based systems run a lot smoother during an update on the same machine. In fact, except for the gzip phase it damn near runs at the same speed on any system.

Re:Source (1)

FranTaylor (164577) | more than 5 years ago | (#25739091)

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 (1)

Cthefuture (665326) | more than 5 years ago | (#25739155)

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 (1)

FranTaylor (164577) | more than 5 years ago | (#25739239)

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 (1)

FranTaylor (164577) | more than 5 years ago | (#25739297)

"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 (1)

shaitand (626655) | more than 5 years ago | (#25739079)

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 (1)

Draek (916851) | more than 5 years ago | (#25739973)

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 (1)

NekoXP (67564) | more than 5 years ago | (#25742951)

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 (1)

pembo13 (770295) | more than 5 years ago | (#25738367)

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

Re:Source (0, Redundant)

Abreu (173023) | more than 5 years ago | (#25739501)

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

Sigh... everytime this is suggested a holy war breaks out...

And your point is what? (3, Insightful)

FranTaylor (164577) | more than 5 years ago | (#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?

Re:Source (0)

Anonymous Coward | more than 5 years ago | (#25738903)

Java is just the tip of the iceberg. I ran the LSB test suite against my app and wrote about it on my blog:

http://realeyes-tech.blogspot.com/2008/09/my-app-fails-lsb.html

With FOSS source code, the LSB is basically irrelevant. I support distro package managers and think that even proprietary apps should be installed and have security updates provided under them.

Later . . . Jim

Re:Source (1)

HuguesT (84078) | more than 5 years ago | (#25740385)

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

Ed Avis (5917) | more than 5 years ago | (#25740345)

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.

As a C++ programmer... (1)

internerdj (1319281) | more than 5 years ago | (#25737611)

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

christoofar (451967) | more than 5 years ago | (#25737727)

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:As a C++ programmer... (0)

gbjbaanb (229885) | more than 5 years ago | (#25739791)

I think we've both been relegated to the carehome of 'old languages' by those upstart brothers C# and VB.NET and their backward cousin Mono.

Now get off my lawn, I have some programming to do using only the mouse and the '.' key :)

I have just one thing to say about that... (1)

Tetsujin (103070) | more than 5 years ago | (#25737737)

OBJECTION!

Re:I have just one thing to say about that... (2, Funny)

wbren (682133) | more than 5 years ago | (#25738941)

Don't you mean java.lang.Exception?

Re:I have just one thing to say about that... (0, Redundant)

X0563511 (793323) | more than 5 years ago | (#25738943)

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!?"

I got yer message body right here... (1)

Tetsujin (103070) | more than 5 years ago | (#25739951)

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:As a C++ programmer... (0)

Anonymous Coward | more than 5 years ago | (#25737969)

Don't worry: they're too busy warring with the C# overlords.

As a Java programmer... (1)

Gazzonyx (982402) | more than 5 years ago | (#25737977)

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] !

Re:As a Java programmer... (1)

mrwolf007 (1116997) | more than 5 years ago | (#25738173)

Linux already has Binary Kernel Support for Linux!

Dang, didnt know it was compatible with itself.

Re:As a Java programmer... (1)

Gazzonyx (982402) | more than 5 years ago | (#25738281)

D'oh! Freakin URL copy and paste!

Re:As a Java programmer... (1)

idontgno (624372) | more than 5 years ago | (#25739575)

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:As a C++ programmer... (0, Flamebait)

Hatta (162192) | more than 5 years ago | (#25737993)

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.

Every language is an emulator (0)

FranTaylor (164577) | more than 5 years ago | (#25738461)

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

Apparently you failed computer science.

Re:Every language is an emulator (3, Informative)

jlarocco (851450) | more than 5 years ago | (#25739049)

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 (2, Insightful)

FranTaylor (164577) | more than 5 years ago | (#25739157)

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

jlarocco (851450) | more than 5 years ago | (#25742689)

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 (1)

ADRA (37398) | more than 5 years ago | (#25742025)

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 (1)

jlarocco (851450) | more than 5 years ago | (#25742559)

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 (0)

Anonymous Coward | more than 5 years ago | (#25743835)

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.

Re:As a C++ programmer... (1)

rdean400 (322321) | more than 5 years ago | (#25738931)

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

As a multi-lingual developer... (1)

FranTaylor (164577) | more than 5 years ago | (#25738427)

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.

Re:As a multi-lingual developer... (0)

Anonymous Coward | more than 5 years ago | (#25744157)

Except .net obviously.

Will this FINALLY mean... (5, Informative)

Anonymous Coward | more than 5 years ago | (#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!

Re:Will this FINALLY mean... (0)

Anonymous Coward | more than 5 years ago | (#25737865)

My world for mod points...

Re:Will this FINALLY mean... (1)

Spand (980339) | more than 5 years ago | (#25738191)

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

Re:Will this FINALLY mean... (3, Informative)

crow (16139) | more than 5 years ago | (#25738409)

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

LDoggg_ (659725) | more than 5 years ago | (#25739035)

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

LDoggg_ (659725) | more than 5 years ago | (#25739069)

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

Cthefuture (665326) | more than 5 years ago | (#25739191)

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

Cyberax (705495) | more than 5 years ago | (#25739503)

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... (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25741865)

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

Ooo a standard! (1)

christoofar (451967) | more than 5 years ago | (#25737759)

---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! (1)

FranTaylor (164577) | more than 5 years ago | (#25738541)

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

$RANDOMLUSER (804576) | more than 5 years ago | (#25737799)

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

Nimey (114278) | more than 5 years ago | (#25737869)

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

Gazzonyx (982402) | more than 5 years ago | (#25738089)

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

$RANDOMLUSER (804576) | more than 5 years ago | (#25738125)

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

FauxPasIII (75900) | more than 5 years ago | (#25737937)

Is Java 1.4.2 freely redistributable the way recent versions are?

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

sjames (1099) | more than 5 years ago | (#25738061)

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

$RANDOMLUSER (804576) | more than 5 years ago | (#25738289)

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

csnydermvpsoft (596111) | more than 5 years ago | (#25738353)

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

sjames (1099) | more than 5 years ago | (#25739365)

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.

GPL!!! (3, Informative)

FranTaylor (164577) | more than 5 years ago | (#25738575)

The only Java implementation released under the GPL is 1.6.

I think that's a pretty overwhelming reason.

GNU java is not java (1)

FranTaylor (164577) | more than 5 years ago | (#25738591)

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 (3, Informative)

Benanov (583592) | more than 5 years ago | (#25738887)

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

Re:GNU java is not java (1)

FranTaylor (164577) | more than 5 years ago | (#25738925)

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

Re:GNU java is not java (0)

Anonymous Coward | more than 5 years ago | (#25739121)

Sun Java under GPL is NOT THE SAME THING as OpenJDK or IcedTea. It's .... Sun Java, but under the GPL!

Keep the base small (1)

Hatta (162192) | more than 5 years ago | (#25737897)

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 (1)

pembo13 (770295) | more than 5 years ago | (#25738441)

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

Features can be optional (1)

FranTaylor (164577) | more than 5 years ago | (#25738697)

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:Keep the base small (1)

gbjbaanb (229885) | more than 5 years ago | (#25739941)

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.

A pretty good idea (2, Interesting)

NaCh0 (6124) | more than 5 years ago | (#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.

Re:A pretty good idea (0)

Anonymous Coward | more than 5 years ago | (#25738893)

Laf. What's all this nonsense about when distro's can just add an install java checkbox to it's install procedure, or development task, or whatever they have.

Hey this office suite... everybody uses *that* one right? It should be in the default install! Sure most architects use some piece of software, let's install that by default too! Ooooh! The p2p program One-Day-Fly is the most popular right now! It must be installed! Any experienced user can just delete it!

Do I really need to pay for your convenience every time I decide to install?

Re:A pretty good idea (1)

FranTaylor (164577) | more than 5 years ago | (#25738991)

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

Re:A pretty good idea (0)

Anonymous Coward | more than 5 years ago | (#25743411)

I believe they mean in the sense that it will add unnecessary bloat. The default install should have basic functionality, and easy methods to add more as the user wishes. I disagree with this, I believe the default install should have more than a bare minimum, and should definitely include a JVM.

Re:A pretty good idea (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25741731)

*) 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 (1, Interesting)

Anonymous Coward | more than 5 years ago | (#25743905)

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

The Number one reason for Java as a Linux standard (1)

FranTaylor (164577) | more than 5 years ago | (#25738629)

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 Java and not Mono? (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#25738773)

Why Java? Why not Mono? The open source community already has a completely free virtual-machine environment to use.

I mean, if we're going to add a corporate-controlled, patent-encumbered virtual-machine environment to the Linux standard base, why not go with the one the community created?

Or, even better, let's just not include either! If you want to create a separate "this is the standard way for Java to work on Linux" spec for people to ignore, that's fine. (Which, if I'm not mistaken, already exists.) Don't try and shoe-horn something like Java into a "baseline Linux". It doesn't belong there.

Ther are no patent encumberances on Java (2, Informative)

FranTaylor (164577) | more than 5 years ago | (#25738951)

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 (0)

Anonymous Coward | more than 5 years ago | (#25743157)

You're wrong. Sun has already had to license patents from Kodak that cover Java concepts, so Sun's already been bitten by patents. Sun has received patents covering various aspects of Java. For example, the Java virtual machine instruction set is patented.

When Sun finally fails, and given that they don't make anything and give away basically everything they do, that's only a matter of time, those patents are going to be sold off to the highest bidder. And who knows if the new owner will be quite as willing to be as open with them as Sun currently is.

Re:Why Java and not Mono? (1)

FranTaylor (164577) | more than 5 years ago | (#25738973)

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.

Transmogrificator... (1)

CTalkobt (81900) | more than 5 years ago | (#25739711)

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

CTalkobt (81900) | more than 5 years ago | (#25739737)

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

Why? (1)

Yfrwlf (998822) | more than 5 years ago | (#25742019)

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.

Its about time... (-1, Flamebait)

Anonymous Coward | more than 5 years ago | (#25743085)

There were a lot of people who wanted Java to be GPL or LGPL (but mostly GPL) before they would touch it --I'm mostly talking about people in the Linux and Free Software circles. Windows people wanted to kill Java by making their own, then after Sun got grumpy for MS trying to wreck it by intentionally and for not good reason make it incompatible with anything else (much like they are trying to do with ODF). Sun finally jumped through enough hoops to do it, and Java was released into the wild. That was a few years ago.
    I'm no big fan of Java, its slow as hell no matter how many supporters say 'but the bytecode is so fast now...'. No, no its not. And its also extremely verbose. I like terse languages. A little bit gives you a little bit. With Java, you code a page to get 'Hello, World!'. Don't say you don't. I've seen people argue otherwise: then I type it up in C:
#include
void main(void){
printf{'Hello World/n'};
}
4 lines and I'm done, the whole thing. The Java folk always try to give me a code snippet. When you tell them 'lets see that go' they then start including everything else (and the kitchen sink) to actually make it go, and its always a page. A FULL PAGE!

So in spite of how I personally feel about Java, some people like it. Sun made it available and I do have some programs that need it to run. Its available, and its about time that its included in the standard base.

Load More Comments
Slashdot Account

Need an Account?

Forgot your password?

Don't worry, we never post anything without your permission.

Submission Text Formatting Tips

We support a small subset of HTML, namely these tags:

  • b
  • i
  • p
  • br
  • a
  • ol
  • ul
  • li
  • dl
  • dt
  • dd
  • em
  • strong
  • tt
  • blockquote
  • div
  • quote
  • ecode

"ecode" can be used for code snippets, for example:

<ecode>    while(1) { do_something(); } </ecode>
Create a Slashdot Account

Loading...