Slashdot Mirror
64-Bit Java For Linux
LWATCDR writes "First we got 64-bit Flash; then the beginnings of 64-bit Wine; now Sun is providing a 64-bit Java plugin. For most people there is nothing to hold you back from running 64-bit Linux."
← Back to Stories (view on slashdot.org)
The time has come to begin discussing 128 bit computing.
But they still don't ship a debian package for Lenny with 64 bits support, we have to get the old Java 1.4...
For most people there is nothing to hold you back from running 64-bit Linux.
Except madwifi-ng drivers. I can't even count how many times people have bugged me about their Atheros cards not working in Linux, only to find that they were running a 64-bit distro.
IBM's 64-bit Java for Linux has been out for a long time...
http://www.ibm.com/developerworks/java/jdk/linux/download.html
What already works for me on 64-bit Ubuntu Intrepid Ibex is this:
Sun has always made it a royal pain to use their java. For years they've always wrapped everything in click-through licenses, so you couldn't just download it and install it using your distro's packaging system. This version seems like more of the same, or maybe even worse. I went to the java.net page linked to from the article, downloaded the file. It's a shell script, and when you run it, the first thing it does is print out a license and ask if you agree to it. Some of the contents of the license:
So in other words, it's not open source under the Open Source Definition.
I think it's great that Sun has GPL'd their implementation of java. Three cheers for Sun for doing that. But they've proved over and over again that any open-source project they control will have a closed development process, will ignore their user community, and will be a massive pain to install and work with. So the really good thing about Sun GPLing their version of java is that now, finally, we've gotten to the point where people other than Sun -- people who Get It about open source -- can take the ball and run with it.
Find free books.
Unlike Flash, Java source-code was perfectly open and available for years (it has even been GPL-ed for a while, but before that was still available). Why did anyone have to wait for Sun to release the 64-bit plugin instead of compiling one? A fairly small patch was required (long vs. size_t somewhere deep inside)...
FreeBSD was providing Java (with the plugin) for both i386 and amd64 for years now...
What does the fact, that this is news, tell us about Linux developers? First they holler at Sun to release the source, that's already available for download under GPL. And then they still would not touch it, until Sun gets around to it... "Freedom to tinker" my behind.
In Soviet Washington the swamp drains you.
I'm already running computers with a quarter terabyte of ram you insensitive clod.
Seriously, the data warehouse server I'm implementing this week is an HP DL585 G5 with 4x AMD 8378 and 256GB of ram using 2x Brocade 815 8Gb HBA's =)
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
64-bit flash did fix those issues. You can download the alpha version here. I've been running it on Gentoo for a few weeks without issues.
I'm not not licking toads.
If you're using a file that requires more than 64 bits for the file pointer, you may be happier using a database.
I'm just sayin'
Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
The 256GB monster is actually non-production, due to the quirks of the management in our software side they wanted to have "identical" testing capabilities vs prod. Since we are CPU licensed the cheapest way I could get them two non-prod environments to match prod was to match the prod CPU count and double the ram. This way we have room to go prod if we need to. Our DR scenario is currently to either move the prod HBA's into the non-prod server or zone the prod disks to the non-prod HBA's depending on the failure mode, the app is currently not covered by our DR SLA, but should that change then we will begin either log shipping to a like DR box or buy a second SAN for DR and use SAN replication. Oh, and to answer your questions directly:
1)Cost, Oracle RAC is expensive per transaction, it's more of an availability tool then a performance one.
2)Data transform tool and the fact that the best way we have found to maintain decent I/O performance without turning down Oracle's data integrity options is to throw more log writers at the problem, one I/O writer per core.
3)Like I said prod is only 128GB and since our OLTP DB is currently only about 60GB uncompressed I don't forsee us outgrowing a maxed box before the 3 year hardware cycle is out.
4)Currently our primary table is growing about 1.2M rows a month, but we are adding addition capabilities about twice a year so data growth is hard to quantify over a long period of time.
5)Our SLA is something like 95% during SLA hours, hardly hard to achieve with decent equipment. We recently experienced some of the worst downtime in my career due to prematurely outgrowing our old Cisco 9140's (they fell over at ~1.7Gb max traffic, very pathetic), but it was a total of about 4 hours of user visible downtime and even less for the financial systems.
6)DR is talked about above.
Other)Storage, we use a Xiotech SAN, we have 36TB of raw space over 224 spindles which is utilized for file storage, SQL Server, Lotus Notes, and multiple Oracle installations as well as for some boot from SAN application servers. Our next move will probably be to their Emprise 7000 line which will probably suck in all of the data in our current until as well as host document archiving for ediscovery. The Emprise is a beast of a system, scalable from 1TB to 1EB, the bigger limitations are the connected servers (248) and LUN's (1,024).
There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
Can't recall seeing a big gaping hole on a page where a Java Applet would be in at least a year. And this story is only important if somebody out there has a burning need to run a 64bit Java app... in a web browser.
Which you can't do, because Java runs all applications with a memory usage limit, which for an applet there's no way of changing, so you'll get the standard limit.
Actually, it's important if someone wants to run a 64 bit web browser and use Java, because 64 bit browsers can't interface with 32 bit plugins.
IIRC, there's now also a 64 bit flash plugin available (another recent release). This might mean that 64 bit linux distros no longer need to install 32 bit compatibility environments by default, which would be a welcome improvement.
They should do what the C standard did to solve this problem. A C int is generally of whatever size the architecture is most easily capable of manipulating. On nearly all modern architectures, this is four bytes, but this is not mandatory. On certain embedded systems, I've seen two (and even three, on a 24-bit DSP) byte integers. The long type (or, in C99, the int32_t type), however, is always 32 bits or four bytes, and that's why both long and int are valuable as distinct types.
Java applets as a technology was hurt by a myriad of factors,
1. The rapid evolution of the language
2. The poor VM performance (before Hotspot)
3. Poor browser support
4. No default installations, except the MS JVM.
5. MS introduced incompatibilities and extensions
Sun should have laid off the "Java replaces the desktop" rhetoric, and paid Microsoft to ship the JVM on Windows. It would be as ubiquitous as Flash is today.