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)
But they still don't ship a debian package for Lenny with 64 bits support, we have to get the old Java 1.4...
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.
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.