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

387 comments

  1. Developers section red now ? by unity100 · · Score: 2, Funny

    what is this, moulin rouge ?

    1. Re:Developers section red now ? by MaskedSlacker · · Score: 3, Informative

      Looks blue to me

    2. Re:Developers section red now ? by nschubach · · Score: 2, Informative

      I think the red title might be a "new/hot off the press article" color. I saw it as well, but refreshing it changes it back. At least, that's my guess.

      --
      Every time I start to have faith in humanity, I ruin it by driving to work between 7 and 8 am.
    3. Re:Developers section red now ? by Anonymous Coward · · Score: 3, Funny

      64-bit Slashdot still has a few kinks to work out.

    4. Re:Developers section red now ? by Anthony_Cargile · · Score: 3, Funny

      I'm colorblind, you insensitive clod!

    5. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      It's blue. The BSD section used to be red, but doesn't seem to properly exist anymore.

    6. Re:Developers section red now ? by Anonymous Coward · · Score: 5, Funny

      Makes a change, most people around here are joke blind.

    7. Re:Developers section red now ? by Surt · · Score: 1

      I'm pretty sure most people would describe that color as green.

      --
      "Who is the Journal of Quantum Physics going to believe?" --Stephen Hawking
    8. Re:Developers section red now ? by thrillseeker · · Score: 4, Funny

      I don't get it.

    9. Re:Developers section red now ? by Hurricane78 · · Score: 1

      No. It's blue here too. If you were'n referring to the front page, you should go check your eyes.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    10. Re:Developers section red now ? by tomhudson · · Score: 4, Informative

      Well, if it were running on 64-bit java instead of 64-bit perl, it wouldn't - java ints are still only 32 bits in "64 bit java.

      Someone forgot to future-proof their language. 10 years from now, when you're running a 128-bit cpu with a quarter-terrabyte of ram, those 32-bit signed ints are going to look mighty quaint. "What do you mean, I can't store the [file size|number of inodes|ipv6 address|whatever] in a 128-bit int? What do you mean, 128-bit java doesn't have 128-bit ints? You're shitting me, right? This is 2018 ... what's gonna happen in 2038 - we gonna have a 2k38 java problem? No? Why should I believe you? You can't even right-size your ints ..."

    11. Re:Developers section red now ? by madhurms · · Score: 1

      I guess you are not new here.

    12. Re:Developers section red now ? by afidel · · Score: 2, Interesting

      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.
    13. Re:Developers section red now ? by mR.bRiGhTsId3 · · Score: 2, Informative

      Ok, but Java longs are 8 bytes, even in 32-bit whereas in C they are still often 4 bytes. Its not the end of the world, just something to be aware of if you might have to deal with big numbers.

    14. Re:Developers section red now ? by setagllib · · Score: 2, Informative

      jint == int32_t
      jlong == int64_t

      Deal with it. When 128 becomes an issue there'll be a jlonger, or something like that. (jquad may be used for quad precision float)

      --
      Sam ty sig.
    15. Re:Developers section red now ? by mcrbids · · Score: 1, Offtopic

      Nice piece of iron. As a data warehouser myself, I have a few questions:

      1) What made you decide to go with one big piece of iron rather than a cluster of lightweight systems?

      2) "Data Warehouse" implies semi-static storage, making the 16 cores you mention somewhat overkill. Are you warehousing in a DBMS? (EG: Oracle/DB2/MSSQL)

      3) 256 GB of RAM looks like it's maxed out - are you worried about future growth? What are your plans over the next 3 years?

      4) What's the growth rate of your data size?

      5) What's your expectation of uptime?

      6) What's your DR recovery plan? What happens if the building your big-ass server is in is melted into vapor by a nuclear bomb?

      In our scenario, we host data for clients, with over a hundred clients, growing by about 25% client base per year. It's part of our application suite, but since the types of data we host is increasing every year, our data growth rate is around 75% growth per year. I've responded by clustering our application, so that each client is hosted in a logically different (redundant) environment that may or may not be shared, controlled by local DNS. We're still small: now at 6 8-core 1U rackmount servers with U320 SCSI, 3.6 TB of storage total today, with physical room for 400% expansion without replacing any servers, average system load around 0.10 during business hours.

      One of the key concerns I've had is availability - we're specifically architected so that any single server in our cluster can fail, but cause 5 minutes of downtime, and that our primary hosting can fail completely (EG: mushroom cloud over our hosting facility) with 24 hours recovery to an off-site, off-network host.

      Since we're growing rather quickly, I'd be very interested in your responses!

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    16. Re:Developers section red now ? by ThePromenader · · Score: 1

      As far as my case is concerned, your comment is surprisingly on-topic - Have you tried HA or DRDB? You can cluster servers even over remote locations with an instant fail-over and fallback - zero downtime.

      The fact that I'm running 64-bit Linux is the very reason I'm not using it yet: Each of our (soon to be paired) servers are managing 14-terra RAID arrays, a capacity perfectly manageable by a 64-bit system, yet DRBD can only manage a disks/partitions no larger than 4 terra. This should change with the next version.

      It's all about the software; no point in buying a hydrogen-fuelled car until hydrogen fuel is available.

      --

      No, no sig. Really.

      ThePromenader
    17. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      So what...my cock is still bigger than yours!!!

    18. Re:Developers section red now ? by Profane+MuthaFucka · · Score: 2, Interesting

      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!
    19. Re:Developers section red now ? by Profane+MuthaFucka · · Score: 1

      Hahaha! I never get jokes, so it's easier to just laugh at the bit WHOOOOSH sound as they go over my head. Fart jokes are my favorite, just gotta remember not to look up when I hear one.

      --
      Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
    20. Re:Developers section red now ? by mcrbids · · Score: 1

      HA? I use heartbeat in a few situations. (EG: the load balancers) But it has its own limitations.

      DRBD masks the fact that you still have a single point of failure: the SAN itself. So I've avoided the expense of a SAN-based solution by distributing the load with an application-level distributed storage system, and glusterfs for the small number of cases where I wasn't able to use the aforementioned application-level storage system. Honestly, its performance is pretty weak, but its ease of use/setup, its reliability, and its distributed nature have compensated nicely. After major bombs when attempting to use NFS on a SAN and DRBD over TCP, GlusterFS is a pretty strong bet.

      Our distributed cluster is not 100% complete yet, but so far, the conservative, year-long rollout has been going without any major hitches. I'm anticipating 100% rollout in Jan of this year...

      --
      I have no problem with your religion until you decide it's reason to deprive others of the truth.
    21. Re:Developers section red now ? by afidel · · Score: 3, Interesting

      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.
    22. Re:Developers section red now ? by Nutria · · Score: 1
      --
      "I don't know, therefore Aliens" Wafflebox1
    23. Re:Developers section red now ? by thtrgremlin · · Score: 2, Insightful

      Can I mod the moderator +5 funny for modding the parent -1 off-topic?

      --
      Want Big Business out of government? Take away the incentive and start by getting government out of big business!
    24. Re:Developers section red now ? by ThePromenader · · Score: 1

      I see you, and thanks for the tip. Fortunately though, we are not using SAN - each server in a duo-cluster is directly attached to its own storage space, and only the server itself (and its dependencies) are mirrored through DRDB - should either a server or RAID array fail (enter recovery mode), DRDB will activate the failover. This method takes few CPU resources as far as I know, but I'm still in development myself ; )

      --

      No, no sig. Really.

      ThePromenader
    25. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      WHOOOOOOSH
      H
      O
      O
      O
      O
      O
      O
      S
      H

    26. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      It's spelt 'coloUr' in the Commonwealth, you insensitive clod!

    27. Re:Developers section red now ? by Ruediger · · Score: 1
      Java has BigDecimal and BigInt which make possible working with big numbers.

      The drawbacks of using these classes are performance (maybe it will be ok when running on future CPUs) and ease of use, since Java doesn't let the programmer overload operators you have to write stuff like:

      BigDecimal b1 = new BigDecimal("100.04");
      BigDecimal b2 = new BigDecimal("0.33");
      BigDecimal result = b1.multiply(b2);

      --
      "...personality goes a long way."
    28. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      jlonger? But I just met her!

    29. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      Nevermind.

      Wake me up when someone starts to shift 64-bit beer.

    30. Re:Developers section red now ? by m50d · · Score: 2, Insightful

      With today's standards, sure. But what about in the future when that file's just a high-quality movie, say?

      --
      I am trolling
    31. Re:Developers section red now ? by zergl · · Score: 2, Insightful

      Well, if it were running on 64-bit java instead of 64-bit perl, it wouldn't - java ints are still only 32 bits in "64 bit java.

      Someone forgot to future-proof their language. 10 years from now, when you're running a 128-bit cpu with a quarter-terrabyte of ram, those 32-bit signed ints are going to look mighty quaint. "What do you mean, I can't store the [file size|number of inodes|ipv6 address|whatever] in a 128-bit int? What do you mean, 128-bit java doesn't have 128-bit ints? You're shitting me, right? This is 2018 ... what's gonna happen in 2038 - we gonna have a 2k38 java problem? No? Why should I believe you? You can't even right-size your ints ..."

      Refactor your ints to long if you need bigger values?

      Apart from that, the link's criticism specifically refers to Arrays still using a 32bit int index without the capability to use a long instead but you might be able to work around that by using another datastructure instead should you really need that much Objects stored in one container.

    32. Re:Developers section red now ? by shutdown+-p+now · · Score: 2, Informative

      Deal with it. When 128 becomes an issue there'll be a jlonger, or something like that. (jquad may be used for quad precision float)

      The D programming language (the Digital Mars one) has already reserved a pair of types, cent and ucent, for future use as 128-bit signed and unsigned integers.

    33. Re:Developers section red now ? by ckaminski · · Score: 2, Insightful

      The idea of a data warehouse is that it gloms all the other data from your other systems, aggregates it, and generates lots of reports, extra BI data. Ideally, it can be completely lost, and it can be rebuilt from scratch the next day. Pain in the ass, but not particularly necessary to have fully redundant. But you want powerful, because all your business users will be hammering it for reports, and data mining.

    34. Re:Developers section red now ? by TheRaven64 · · Score: 1

      You are obviously a C programmer.

      The fact that int changes size depending on where you run your C code is one of the biggest headaches when porting old C code to a new platform ('but int is always 16/32 bits', the old programmers cry). With Java, int is 32 bits, long is 64 bits. A future version can introduce a long long type if 128-bit ALUs become common, or you can just use a BigInt.

      Or you could just use Smalltalk, where any number that fits in a pointer-sized variable is stored like that and anything that doesn't is transparently promoted to an object.

      --
      I am TheRaven on Soylent News
    35. Re:Developers section red now ? by danieltdp · · Score: 1

      public class HugeInt extends Integer {
      (...)
      }

      --
      -- dnl
    36. Re:Developers section red now ? by danieltdp · · Score: 1

      With the added bonus that both works on 32 and 64 bits.

      --
      -- dnl
    37. Re:Developers section red now ? by danieltdp · · Score: 1

      But he fits perfectly among the crowd.

      --
      -- dnl
    38. Re:Developers section red now ? by notany · · Score: 1

      Or you could just use Smalltalk, where any number that fits in a pointer-sized variable is stored like that and anything that doesn't is transparently promoted to an object.

      That's implementation dependent, but I think most good Smalltalk and Lisp implementations do it like that. If you reserve two tags for immediate integers (one for positive, one for negative), you lose only two bits. Having 64-bit system, and memory access as bottleneck, that's incredibly good solution. Completely future proof solution even.

      --
      Dyslexics have more fnu.
    39. Re:Developers section red now ? by TheRaven64 · · Score: 3, Insightful

      An hour of DV footage is 10GB. A 32-bit offset gives you 4GB of addressable space, so that's not enough. A 34-bit offset gives you 16GB, so that's fine. Maybe you're recording raw HD footage though, let's say 1080p, so 1920Ã--1080 pixels. You're editing, so let's say you want 32-bits per channel, three channels. That gives you around 24MB per frame. Let's say 30 fps, so 712MB per second, or 2.4TB per hour. Let's say a filming session is 10 hours, so that's 24TB per file.

      Take the base 2 logarithm of that, and you find you need just under 45 bits to represent any offset in it at byte granularity. If you double the horizontal and vertical resolution, you need 47 bits. If you double the frame rate, you need 48 bits. Go to double-precision floats for each channel, and you need 49 bits. If you use stereoscopic cameras, you need 50 bits. 64 bits still gives you a lot of space to play with. When your files are more than 16 exabytes, you should probably consider splitting them a bit. A filesystem more than 16 exabytes is likely to be needed over the next decade (hence ZFS), but 64-bit files are going to be fine for a very long time. Even today, very few files are over 4GB (mostly DV footage and DVD images), and we've had support for those for around a decade now.

      --
      I am TheRaven on Soylent News
    40. Re:Developers section red now ? by The_reformant · · Score: 1

      Actually java datatypes are machine independant so they can be serialised and unserialised across architectures. Altering the size of the primitive types simply because your happening to be running on a different wordwidth cpu is a bad idea for portability.

      --
      I have discovered a truly remarkable sig which this post is too small to contain.
    41. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      I'm already running computers with a quarter terabyte of ram you insensitive clod.

      Nice piece of iron. As a data warehouser myself, I have a few questions:

      1) What made you decide to go with one big piece of iron rather than a cluster of lightweight systems?

      Vista

    42. Re:Developers section red now ? by Anonymous Coward · · Score: 0
      Deal with it.

      No. Fuck you.

    43. Re:Developers section red now ? by Dr.+Smoove · · Score: 1

      long and int types are the same on my leenuckz systems, 4 bytes. Always had to use a long long for any semi-large numbers.

      --
      "If you plant ice, you're gonna harvest wind."
    44. Re:Developers section red now ? by Profane+MuthaFucka · · Score: 1

      No need to think too hard about it. You can tell I'm demented by the way I stand outside windows at apartment complexes masturbating.

      --
      Fascism trolls keeping me up every night. When I starts a preachin', he HITS ME WITH HIS REICH!
    45. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      Here's what will happen: they'll add a long long type to Java, which will be 128 bytes long.

      Meanwhile, the poor suckers writing C/C++ code will spend months cleaning up bugs caused by people assuming that "long long" is a 64-bit type.

    46. Re:Developers section red now ? by jason8 · · Score: 1
      C and C++ are the same way. In basically all 64-bit implementations, "int" is a 32-bit data type. In fact, in some of them, "long" is a 32-bit type too. The only thing that must be 64-bit is the pointer type.

      http://www.unix.org/version2/whatsnew/lp64_wp.html

    47. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      And java 'long' has always been 64-bit -- big deal. When the java language starts supporting 128-bit numbers, then the 128-bit primitive will just have a new name:

      short -- 16 bit
      int -- 32 bit
      long -- 64 bit

      this is actually very good coding style -- and a great language feature.

    48. Re:Developers section red now ? by Fujisawa+Sensei · · Score: 1

      Changing the Java int from 32 bits to 64 bits is stupid, its a virtual machine.

      Now allowing the indexing into an array using a long would be a good idea.

      --
      If someone is passing you on the right, you are an asshole for driving in the wrong lane.
    49. Re:Developers section red now ? by BitZtream · · Score: 1

      Or you know, just use the proper type for those longer numbers. You don't use a 'short' or a 'char' for holding an IP address now do you? Perhaps you use them to hold part of an address for some other purpose but you don't bitch about not being able to store the address in the wrong type for it.

      The language was future proofed when they allowed you to create your own data types. As long as internally its pointers are capable of dealing with changing size its fine, and its your fault if you're casting pointers to another datatype with a fixed size.

      Just because you use 64 bit addressing doesn't mean anything else changes.

      --
      Persistent Volume manager for Kubernetes - https://github.com/dwimsey/openshift-pvmanager
    50. Re:Developers section red now ? by tristanreid · · Score: 1

      That seems a bit silly. Java already has a 64-bit integer data type called a long, which works just fine. If a language changed the definition of an int every x years, it would break everything. All the existing code would have to be re-written, sometimes in non-obvious ways. The same applies to floats/doubles.

      -t.

    51. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      We're comparing it with Perl here, not with C. Perl of course doesn't distinguish between ints and longs. It just has numbers, which are normally floats, but can be made to be platform-native ints, or (for big numbers) bignums, which can be as big as your memory can hold.

      It sucks for number crunching, but so does Java. :P

    52. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      public class HugeInt extends Integer { (...) }

      Too bad Integer is final.

    53. Re:Developers section red now ? by Anonymous Coward · · Score: 0

      Are you serious? Do you know that 64-bit processors are nothing new. Actually, when Sun released Java, they were also selling UNIX machines with 64 bit SPARC processors... and yes, the machines ran Java.

      The size of the default integer matters not at all, and a larger integer would not have "future proofed" anything.

    54. Re:Developers section red now ? by Guspaz · · Score: 1

      Let's not forget high def rips, which typically clock in at just over 4GB for 720p.

      Just because they're not legal (which is itself debatable based on where you live and how you got it) doesn't mean that they aren't extremely prevalent.

    55. Re:Developers section red now ? by pbhj · · Score: 1

      Makes a change, most people around here are joke blind.

      I don't get it.

      He means people here can't tell when you're joking.

    56. Re:Developers section red now ? by toriver · · Score: 1

      That's Tarzan primitive pick-up line.

      The rest of us love that the language defines the size of primitives exactly (Java) instead of setting just minimum ranges but allowing implementations to go outside of them (C).

    57. Re:Developers section red now ? by rigelstar · · Score: 1

      Get a room!

    58. Re:Developers section red now ? by tomhudson · · Score: 1

      So you would propose that, unlike the other types, HugeInt not be a native type, but a class, with all the extra slowness that entails. Yuck.

    59. Re:Developers section red now ? by tomhudson · · Score: 1
      Where size matters, most c/c++ coders either:
      1. use things like int16, int32, int64, uint64, etc., rather than depending on the platform-dependent sizes
      2. use #defines that conditionally compile code for each platforms' native sizes

      It's no longer that big a deal. It's not like the whole shift from 16 to 32 bits - people are more aware of the problems nowadays.

    60. Re:Developers section red now ? by tomhudson · · Score: 1

      Sometimes a rewrite is good if it helps you take advantage of new instructions, or larger data sizes. eg: CMPXCHG

    61. Re:Developers section red now ? by WhiteHorse-The+Origi · · Score: 1

      The main problem was the java and flash plugins for firefox. Now people can run 64 bit firefox with all the plugins. You still probably can't decode certain codecs that are only 32-bit... sigh

    62. Re:Developers section red now ? by FrangoAssado · · Score: 1

      Well, saying "often" might be an exaggeration; the only major 64-bit compiler where a long is 32-bit is Visual C++. Every other 64-bit C compiler I've seen or heard of is LP64 (meaning a long is 64-bit) -- Linux (gcc), FreeBSD, Solaris, Mac OS X (also gcc), AIX, HP.

      As for Java, the real problem is that you simply can't index an array with a long, so you're limited to 31-bit indices. It might seem crazy to have arrays with more than 2 billion entries today, but when we start to have hundreds of gigs of memory, it will be useful. I wonder if Java will ever change this.

    63. Re:Developers section red now ? by m50d · · Score: 1

      When your files are more than 16 exabytes, you should probably consider splitting them a bit.

      Splitting a file which is logically a single piece of data is never a good thing. Yes, for anything that today would take up 16 exabytes, you probably want to split it up - it'd be a big database or similar - but it seems likely that we'll sooner or later get to a point when you have a 16 EB file that represents a single logical unit. Whether or not it happens with video (I think you were being very conservative in your resolution and especially framerate estimates, but accept the point that there's a lot of room), what about 3D formats? Or the next new technology we can't even think of yet.

      Even today, very few files are over 4GB (mostly DV footage and DVD images), and we've had support for those for around a decade now.

      And they're still causing trouble; I've lost count of the number of times I've found a useful little AVI utility only available in binary form, and broken it on my larger files. The problem here is mitigated by the fact that one can (in C, at least, where FILE is opaque) just recompile with the correct options. In Java that won't be available to us - the language is fundamentally limited to 64 bits, and unlike C it doesn't have any notion that different implementations may have different integer sizes. It's not an immediate problem, but it's one that bears considering.

      --
      I am trolling
    64. Re:Developers section red now ? by Fujisawa+Sensei · · Score: 1

      The C spec says that a long must be at least as long as and int. It also says that a short may not me longer than an int. They are all implementation specific. K&R even notes that according to spec, a short, int and long, may all be the same size. O_o

      --
      If someone is passing you on the right, you are an asshole for driving in the wrong lane.
    65. Re:Developers section red now ? by mR.bRiGhTsId3 · · Score: 1

      I was actually referring to 4-byte longs on 32-bit platforms. A 32-bit long on a 64-bit platform would violate the spec. I am not an expert in the vagaries of memory access, but I see no reason why a 2 dimensional array could not hold the same amount of data as a 1 dimensional array with a long index.

    66. Re:Developers section red now ? by FrangoAssado · · Score: 1

      I was actually referring to 4-byte longs on 32-bit platforms. A 32-bit long on a 64-bit platform would violate the spec.

      Oh, sorry about the confusion -- yes, you're right. But if you're just worrying about the size of integers, C99 has int64_t (and many compilers that don't fully support C99 have it, even Visual C++). But I agree that the situation is far from ideal.

      I am not an expert in the vagaries of memory access, but I see no reason why a 2 dimensional array could not hold the same amount of data as a 1 dimensional array with a long index.

      Well, it could -- but it your problem really wants a single-dimensional array, it's an ugly hack to use a two-dimensional array to "simulate" it. Imagine writing:

      array[(int) (index >> 31)][(int) (index & 0x7fffffff)]

      instead of:

      array[index]

      for every single array access. Yes, you could create a class to encapsulate such accesses, but array access REALLY belongs to the language, and not a library.

    67. Re:Developers section red now ? by mR.bRiGhTsId3 · · Score: 1

      Yeah. That would suck. But there is precedent in the java libraries. We already have BigInt and I think BigFloat (or similar). Using libraries to overcome limitations of the hardware/language isn't unheard of. Perhaps it's time for a BigArray. I guess its likely to be a problem as long as 32-bit compatibility is an issue. C and co. neatly sidestepped the issue with the fact their ints can just get bigger, but that isn't an option for Java, and frankly it is nice not having to worry about data sizes.
      The use cases for a 8-byte indexed array are still a little fuzzy for me at the time being. Sure, some applications can generate ridiculous amounts of data, but how often can that data be meaningfully broken down in records that are small enough to want more than 2 billion discrete entries.

  2. 64 bit Java? by Whiney+Mac+Fanboy · · Score: 5, Informative

    Linux has had 64 bit java for donkeys years... *rereads summary* - oh, Java browser plugin. A piece of the 90s I was hoping we'd all left behind.

    --
    There are shills on slashdot. Apparently, I'm one of them.
    1. Re:64 bit Java? by QuantumG · · Score: 5, Funny

      Someone has to be slower to load than the acrobat reader plugin.

      --
      How we know is more important than what we know.
    2. Re:64 bit Java? by glwtta · · Score: 1

      Yeah, I was just as confused, and then just as disinterested.

      Seriously, Java plug-ins are still around for some reason?

      --
      sic transit gloria mundi
    3. Re:64 bit Java? by Anonymous Coward · · Score: 0

      Why the hatred? What are the alternatives for things that you can only implement with a Java plugin?

    4. Re:64 bit Java? by Whiney+Mac+Fanboy · · Score: 4, Funny

      Someone has to be slower to load than the acrobat reader plugin.

      Not even Java can take that prize.

      Java Joke:

      Knock Knock.

      Who's there?

      ...

      ...

      ...

      ...

      Java!

      Adobe Joke:

      Knock Knock.

      Who's there?

      ...

      ...

      ...

      ...

      Crash.

      --
      There are shills on slashdot. Apparently, I'm one of them.
    5. Re:64 bit Java? by jmorris42 · · Score: 1, Insightful

      > Seriously, Java plug-ins are still around for some reason?

      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.

      Good riddence to java 32 and 64bit, Sun freed it about a decade too late for most people to give a crap. Can anybody name a good reason to develop new code in the environment? Yes a lot of legacy stuff was created in the 1990s while Java was the new shiny for people too blind to see (or with a PHB too blind...) the myriad problems but new projects? And when Java goes away can it take Microsoft's lame me too C++/Mono disease with it?

      --
      Democrat delenda est
    6. Re:64 bit Java? by crow · · Score: 0, Troll

      There is nothing that can only be implemented with a Java plugin. Javascript has reached the point where much of what plugins had been used for in the past can now be done directly. If you're using a Java plugin, you're doing it wrong.

    7. Re:64 bit Java? by Al+Al+Cool+J · · Score: 5, Funny

      That's not really a properly-formed knock knock joke. How about:

      Knock Knock.

      Who's there?

      ...

      ...

      ...

      ...

      Java!

      Java who?

      ...

      ...

      ...

      ...

      Java few minutes? 'Cause this might take a while.

    8. Re:64 bit Java? by doktorjayd · · Score: 4, Insightful

      you're confusing java applets circa 1997 with the java platform.

      take a look through the it job listings and see how much java comes up.

      much, if not most, server side *enterprise* work is done in java, which is a mature, robust, reliable, performant and scalable platform for which there are myriad commercial and open source libraries to give any project a great set of building blocks and frameworks on which to build.

      i check out language du jour a couple times a year, and every time it reaffirms java's benefits.

      the problem with applets is they were generally pretty hacky, but there are some good ones out there.

      ( check out the yahoo games website - my wife has been addicted to literati for years, and its a nice little java applet ).

      java on the desktop has a place too, however its the same set of rules for design and structure as applets: done well, nobody would know/care what language its written in, but done poorly without care for threading models and it'll quickly turn into a steaming pile.

      then theres j2me, and i'd wager if you have any tivo type device, or even set-top box for your cable service, or blu-ray player, or most mobile phones these days, then you have java working for you there too.

      not that i'm arguing for applets by any means, but the more people spread the same old rants as above, the more i'm inclined to correct them.

    9. Re:64 bit Java? by HeronBlademaster · · Score: 2, Insightful

      I hope you mean "C#/Mono disease"...

      Anyway, there are lots of reasons to use Java (though not in a browser setting) nowadays. Just my two cents. YMMV, not all languages are created equal, not every language is good for every project, etc etc etc.

      Disclaimer: I have a great dislike for Java, but the job offer I just accepted is almost exclusively Java work. Silly me.

    10. Re:64 bit Java? by jmorris42 · · Score: 1

      > I hope you mean "C#/Mono disease".

      [voice Homer Simpson]

      Doh!

      [/voice]

      --
      Democrat delenda est
    11. Re:64 bit Java? by tyrione · · Score: 2, Insightful

      you're confusing java applets circa 1997 with the java platform.

      take a look through the it job listings and see how much java comes up.

      much, if not most, server side *enterprise* work is done in java, which is a mature, robust, reliable, performant and scalable platform for which there are myriad commercial and open source libraries to give any project a great set of building blocks and frameworks on which to build.

      i check out language du jour a couple times a year, and every time it reaffirms java's benefits.

      the problem with applets is they were generally pretty hacky, but there are some good ones out there.

      ( check out the yahoo games website - my wife has been addicted to literati for years, and its a nice little java applet ).

      java on the desktop has a place too, however its the same set of rules for design and structure as applets: done well, nobody would know/care what language its written in, but done poorly without care for threading models and it'll quickly turn into a steaming pile.

      then theres j2me, and i'd wager if you have any tivo type device, or even set-top box for your cable service, or blu-ray player, or most mobile phones these days, then you have java working for you there too.

      not that i'm arguing for applets by any means, but the more people spread the same old rants as above, the more i'm inclined to correct them.

      You're too professional. People around here suffer from SADD and if something doesn't tickle their leg just right it flies right over their heads.

    12. Re:64 bit Java? by tyrione · · Score: 1

      Please. Do your worst to convert me and embrace the Ajax whore.

    13. Re:64 bit Java? by this+great+guy · · Score: 4, Informative

      Linux has had a full-featured 64-bit Java plugin that even includes LiveConnect support for at least months via IcedTea, a special build by Red Hat of the official OpenJDK source tree. For example Ubuntu 8.10 ships this 64-bit plugin as the icedtea6-plugin package, which I have been using for the past 2 months. And, no, I am not talking about the GCJ or Blackdown Java implementations which are significantly more buggy or incomplete (lacks LiveConnect support).

      What is new today is that Sun just released a development build of Java 6u12, build b02, which includes the 64-bit plugin. However technically we still have to wait for a couple months before 6u12 is officially released. But again you can already get a 64-bit plugin based on essentially the same source tree via IcedTea.

    14. Re:64 bit Java? by Anonymous Coward · · Score: 0

      There is nothing that can only be implemented with a Java plugin. Javascript has reached the point where much of what plugins had been used for in the past can now be done directly. If you're using a Java plugin, you're doing it wrong.

      Please write the image bulk upload utility used on Facebook with identical functionality using only javscript and then post the code for it here. After you've done this, perhaps we can talk.

    15. Re:64 bit Java? by glwtta · · Score: 4, Informative

      And this story is only important if somebody out there has a burning need to run a 64bit Java app... in a web browser.

      Actually, the way I understand it, it's for those who want to use the plugin with a 64-bit browser (I didn't realize that was not possible until now). There's no such thing as a "64-bit Java app", only 64-bit JVM implementations.

      Can anybody name a good reason to develop new code in the environment? Yes a lot of legacy stuff was created in the 1990s while Java was the new shiny for people too blind to see (or with a PHB too blind...) the myriad problems but new projects?

      You're joking, right? Java Applets are dead and buried - and with good reason, they were a horrible hack from the beginning - but Java itself is one of the most important languages we have.

      I know Java-bashing is a popular Slashdot pastime, and certainly it's not the most exciting and sexy language out there, but it's popular for a reason. It's got its share of problems (gasp! something that isn't perfect!) and more that its share of outdated myths (gasp! modern JVMs perform well!), but it strikes a pretty good balance between abstraction, performance, and complexity (much as I hate to use this argument, not every programmer out there is a rock star).

      I really want to hear what you would recommend as a wholesale replacement for Java. I'm pretty sure I don't know of anything that's as broadly applicable.

      (Plus, with projects like Scala and Clojure it's looking increasingly like the JVM isn't going anywhere any time soon, regardless of Java's fate)

      --
      sic transit gloria mundi
    16. Re:64 bit Java? by Skrapion · · Score: 4, Insightful

      Oh please. You're telling me you can implement a webcam viewer with Javascript?

      The only real alternative for Java applets is Flash. Of course, compared to Flash, Java applets have a lot of downfalls. The VM takes a ridiculous amount of time to start up, and it's really intrusive when it sits in your system tray and constantly announces its new updates.

      However, this is Slashdot, which means there's lots of open-source advocates around. So for all the OSS advocates out there, stop and think for a minute before you bash Java applets. They're not great, but they're the only open alternative to Flash right now.

      --
      The details are trivial and useless; The reasons, as always, purely human ones.
    17. Re:64 bit Java? by TheUser0x58 · · Score: 3, Informative

      Java applets are the only cross-platform technology that can do full 3D rendering in the browser.

      --
      -- listen to interesting music, support independent radio... WPRB
    18. Re:64 bit Java? by jmorris42 · · Score: 0, Flamebait

      > much, if not most, server side *enterprise* work is done in java,

      Yea and a decade ago that 'enterprise' stuff was steaming piles of VB. Now it's racks of big ass servers or blades groaning under badly designed layers and layers of Java 'middleware'. Not sure things have actually improved much.

      > which is a mature, robust, reliable, performant and scalable platform...

      If you have insane amounts of CPU and memory to throw at it to cover up the slowness you can keep a team of medium skill code monkeys permantly employed maintaining all that interfacing between the various middleware products from different vendors.

      > java on the desktop has a place too

      What? Must have missed it. Is there really a demand for slow bloated crap applications running on the local desktop instead of on slow overloaded webservers? Silly me, I thought the primary reason everybody rejected Java and Vista was the bloat and suck. Cross platform was the only possible reason why somebody might have been attracted to Java for a desktop app but until this year cross platform has basically meant Windows and Solaris. Mac on and off again and with an alien feel such that no Mac zealot would accept a Java app as anything but a temporary solution and the Linux situation so fudged up no sane vendor would depend on Java being available and stable. Ask the guys (Was it Borland???) who bet the company around the turn of the century on a Java based office suite and finally abandoned the unfinished projet too late to save themselves.

      > done well, nobody would know/care what language its written in..

      No, you notice when a small app starts sucking up all available memory. Java sucks memory so hard GNOME starts looking lean in comparison. Lools like they solve the sluggishness of garbage collection by not actually doing it until malloc returns ENOMEM. Ok, small exageration.

      > then theres j2me, and i'd wager if you have any tivo type device, or even set-top box
      > for your cable service, or blu-ray player, or most mobile phones these days, then you
      > have java working for you there too.

      That sort of thing was what Java was origionally created to do. Mixed results though. It's killing BluRay almost singlehandedly, even faster than Sony's own DRM stupidity is killing it off. All I had to do was see how goddamned SLOW a BluRay player was to lose all interest, and I'm not alone. They actually put players on shelves that take upwards of two minutes to go from tray close to anything useful appearing on the display. It is going to take Moore's Law longer to fix that much suck than BluRay is likely to be viable.

      Number one complaint you hear about the typical STB? Too slow. I've got a cheap crappy basic cell phone. You can almost see individual pixels draw on the darned thing... smell the Java! BASIC on my old Tandy CoCo outperformed this danged phone's Java. It literally could push more pixels per second.

      --
      Democrat delenda est
    19. Re:64 bit Java? by bucky0 · · Score: 1

      java SSH applets are the only things that come to mind

      --

      -Bucky
    20. Re:64 bit Java? by psetzer · · Score: 4, Informative

      I wait with bated breath for a hyperlink that I can click on to play an Ajax version of Quake 2. Until then I'll just have to make do with http://www.bytonic.de/downloads/jake2_jogl11.jnlp instead.

      --
      "Anyone who attempts to generate random numbers by deterministic means is living in a state of sin." -- John von Neumann
    21. Re:64 bit Java? by Anonymous Coward · · Score: 0

      That is so awesome. I haven't played Quake 2 in ages. I'm bummed it keeps crashing on me.

    22. Re:64 bit Java? by afidel · · Score: 1

      Hmm, well the interface for my brand new Brocade 5100 switch is a java app using java web start which requires the browser plugin AFAIK. Would you rather they have coded it as a Windows only app so you couldn't admin the switch from Linux?

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    23. Re:64 bit Java? by doktorjayd · · Score: 5, Insightful

      Now it's racks of big ass servers or blades groaning under badly designed layers and layers of Java 'middleware'

      so your premis here is the problem is the language/platform rather than the design at fault?

      If you have insane amounts of CPU and memory to throw at it to cover up the slowness

      either you need to replace the tandy coco you mention later as your primary pc, or you could actually _try_ it before you bag it. ( trying it again after 1997 might also be an idea..)

      Must have missed it.

      that tends to happen when you have HASUB* syndrome. it happens, dont worry about it. you probably havent noticed a lot of stuff.

      .. some rant about java and vista bloat related to java desktop. and then brings solaris and mac into it. pfft.

      yawn.

      No, you notice when a small app starts sucking up all available memory. Java sucks memory so hard GNOME starts looking lean in comparison

      i can malloc my way into something that smells the same in c too.. only in java you're less likely to leak.

      hey actually put players on shelves that take upwards of two minutes to go from tray close to anything useful appearing on the display

      huh? i drop blu-ray disks into my ps3 and its playing within a few seconds. you're smoking crack.

      I've got a cheap crappy basic cell phone. You can almost see individual pixels draw on the darned thing...

      unless you run an application on your cheap crappy phone, you're probably looking at just the cheapness and the crappiness of the phone, not java.

      i think what you really meant in the above post was more along the lines of 'get off my lawn'.

      i know this is slashdot, but occasional fact checking really cant hurt if you're going to go on a raving rant about your hatred of specific technologies.

      *HASUB syndrome: Head And Shoulders Up Bum syndrome

    24. Re:64 bit Java? by Samah · · Score: 2, Insightful

      Best.
      Joke.
      Ever.

      --
      Homonyms are fun!
      You're driving your car, but they're riding their bikes there.
    25. Re:64 bit Java? by Simon80 · · Score: 4, Funny

      I really want to hear what you would recommend as a wholesale replacement for Java. I'm pretty sure I don't know of anything that's as broadly applicable.

      Try C++, which seems to get much less attention than it should. It's undeniably faster than Java, but equally good at creating usable abstractions.

    26. Re:64 bit Java? by mR.bRiGhTsId3 · · Score: 1

      I still have to interact with Java web app every day. I die a little inside each time. The fact remains though, this was the result of a redesign that occurred less than 4 years ago. I'm convinced there is still more java out there than you believe.

    27. Re:64 bit Java? by mR.bRiGhTsId3 · · Score: 1

      Is there any theoretical reason why it couldn't be done? I mean, if you can write ajax chat clients, I'm sure you could do ajax file uploads.

    28. Re:64 bit Java? by timeOday · · Score: 3, Insightful

      Good riddence to java 32 and 64bit, Sun freed it about a decade too late for most people to give a crap

      I still think the failure of Java on the desktop is a tragedy and hope it will rise again (though I'm not holding my breath). What has replaced it for rich applications on the web? I see steaming, muddled heaps of web-specific "standards" and scripting languages which, individually, are too weak to do much. Give me a real language, for pete's sake. Yet, my experience with Java in the browser was as bad as everybody else's - they hardly ever worked. Either my JVM wasn't new enough, or it froze up.

      But what I see missing from this discussion so far is a reminder that, at the height of their power, Microsoft killed Java on the desktop very intentionally - they put a polluted "MS-Java" with embrace-and-extend hooks into Windows. So Sun sued them and in retaliation, Microsoft made sure Java on the desktop was a pain in the butt for everybody. It was still possible, but too much trouble to bother. This history is important because it means Java still might succeed if it were given a fair shake. And now that Microsoft is less dominant (and RAM is cheap :) maybe - just maybe - the phoenix can rise again?

    29. Re:64 bit Java? by Draek · · Score: 2, Informative

      Yea and a decade ago that 'enterprise' stuff was steaming piles of VB. Now it's racks of big ass servers or blades groaning under badly designed layers and layers of Java 'middleware'. Not sure things have actually improved much.

      If you had worked with either of them you'd know that yes, things have improved tremendously. Alas, it's evidently you haven't used Java for a real-world project of a respectable size so...

      If you have insane amounts of CPU and memory to throw at it to cover up the slowness you can keep a team of medium skill code monkeys permantly employed maintaining all that interfacing between the various middleware products from different vendors.

      Which is much better than C++, where you need obscene amounts of CPU and memory to throw at problems, or rather, to all of the "me too" libraries your medium skilled code monkeys used to build your nifty little problem-solver that only they can extend because the code is such a mess. Or were you suggesting Python, Ruby et al which, while excellent languages in their own right, can't beat Java's performance anywhere, anytime?

      What? Must have missed it.

      Yes, you did. Do you even work in IT? seriously.

      Silly me, I thought the primary reason everybody rejected Java and Vista was the bloat and suck.

      Silly me, I thought that nobody outside of the hardcore (read: fanatical) C coders rejected Java, but what do I know, I'm only somebody working in IT and looking at available job postings.

      No, you notice when a small app starts sucking up all available memory.

      And that's when you know the app was coded in C or C++, and the programmer sucked. Or was lazy. Or just a bit careless. Or had a bad day at home. Or one of the other million reasons a C/C++ app may leak.

      I've got a cheap crappy basic cell phone. You can almost see individual pixels draw on the darned thing...

      Try to find the problem. Hint: it's not Java.

      --
      No problem is insoluble in all conceivable circumstances.
    30. Re:64 bit Java? by Anonymous Coward · · Score: 0

      No, I'd rather they have it coded some telnet interface like a lot of other devices/daemons do. Or even a web interface, easy as shitting.

    31. Re:64 bit Java? by afidel · · Score: 1

      Lol, the web interface could never keep up with all the stuff that the JAVA interface does. There is telnet/SSH as well as SNMP and web services interfaces to perform management tasks, but for most configuration as well as non-detailed monitoring the JAVA GUI is by far the best tool. I wouldn't use it to diagnose serious problems, but if I just want to update a zone or monitor the storage and E ports it's just plain easier to do through the GUI. Not only that but the SAN maps that the GUI provides are the fastest way to show your configuration to someone not familiar with your environment as I found out while working with two outside support organizations last month.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    32. Re:64 bit Java? by julesh · · Score: 1

      Linux has had 64 bit java for donkeys years... *rereads summary* - oh, Java browser plugin. A piece of the 90s I was hoping we'd all left behind.

      Java applets are still useful for many tasks. I use them daily to access email (via hushmail), for example. I also use online share trading systems that use Java applets to display charts. For these reasons, I've had to stick to a 32 bit browser, despite being on a 64 bit OS.

      Of course, you could question how much need there is for 64 bit browsers...

    33. Re:64 bit Java? by amorsen · · Score: 1

      While it is true that Microsoft did all they could to kill Java, it is also true that Sun's Java implementation is ridiculously slow-starting and full of bugs.

      Also, Java pretends to be compatible with itself, but it isn't. When you make a new interpreter, you either a) make sure newer versions are perfectly backwards compatible (by far the best option) or b) make them completely incompatible and force parallel installs. Sun pretended to pick a) but actually picked b), but they failed to provide for parallel installs of the browser plugin. Microsoft picked b) for .Net, which may be a lousy solution, but at least it works.

      --
      Finally! A year of moderation! Ready for 2019?
    34. Re:64 bit Java? by amorsen · · Score: 1

      You're telling me you can implement a webcam viewer with Javascript?

      It's just streaming video. Why would you need Java to play video?

      --
      Finally! A year of moderation! Ready for 2019?
    35. Re:64 bit Java? by julesh · · Score: 2, Interesting

      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.

    36. Re:64 bit Java? by Anonymous Coward · · Score: 0

      Wow. Just... wow.

      So what is your language of choice o' wise one? C? Cobol? Assembly?

      A lot has happened since the 90s. You should really look into it...

      Silly me, I thought the primary reason everybody rejected Java and Vista was the bloat and suck.

      WTF? Comparing Java and Vista? Different companies, different people, different purposes, different... ugh, why am I feeding this troll?

    37. Re:64 bit Java? by julesh · · Score: 5, Insightful

      The only real alternative for Java applets is Flash. Of course, compared to Flash, Java applets have a lot of downfalls. The VM takes a ridiculous amount of time to start up, and it's really intrusive when it sits in your system tray and constantly announces its new updates.

      Down to less than 2 seconds on my system, these days. Each new release seems to take less time than the last. And the update announcements can be disabled, if they annoy you.

      Also, Java applets have a lot of upsides to flash as well:

      * Ability to access network services (not just via XMLHttpRequests), so live streaming data is a possibility
      * Signed applets can access local system resources that Flash cannot
      * Use useful APIs to do stuff that's beyond the capabilities of Flash (e.g. the Java port of OpenGL)
      * Don't have to design your user interface as a series of frames that you move between to show and hide aspects of it (yeuch... I've done one project of Flash UI design, and that was more than enough for a lifetime thanks.)
      * Much, much easier to support internationalisation
      * Acceptable calculation speed for CPU-intensive stuff

      I'm sure there're more. OK, Java applets are a heavyweight solution. But they are the only solution other than ActiveX for many problems.

    38. Re:64 bit Java? by Anonymous Coward · · Score: 0

      ...and requires rockstar programmers. C++ is just too difficult to get the abstraction right. typically programmers end up in a mess of virtual destructors, sliced objects and static_cast

    39. Re:64 bit Java? by Lennie · · Score: 0, Redundant

      phoenix that would be one of the earlier names of firefox, maybe it's better to have a different analogy.

      --
      New things are always on the horizon
    40. Re:64 bit Java? by Bootarn · · Score: 1

      I'd mod you +50 Funny if that was possible.

      Made my day!

    41. Re:64 bit Java? by Anonymous Coward · · Score: 0

      Hint: It is java. The CPU has 1000000x more power than old 8-bit computers and is unable to outperform them. It very fuckingly is ... ... ... java.
      Lookup the Wikipedia article for Stockholm syndrome.

    42. Re:64 bit Java? by m50d · · Score: 1

      You've been able to do applets in a much better, open language - TCL - for years. Since before you could in Java, in fact.

      --
      I am trolling
    43. Re:64 bit Java? by Anonymous Coward · · Score: 0

      Have you ever actually looked at Java? It doesn't just encourage bad design, it demands it with its verbless, embed-everything-in-a-class-no-matter-whether-it-makes-sense-or-not, statically-typed-but-whoops-we-cast-everything-to-object-all-the-time-and-have-no-expressivity (or use XML to get around the fact that we have a type system), utter ridiculousness. Most of the rest of the counters you give are valid, but sometimes, if you can't dance, there really is something wrong with the floor.

    44. Re:64 bit Java? by impaledsunset · · Score: 1

      That's interesting, but I've had a 64-bit Java plugin installed on my Gentoo for several months now, with the java-overlay and the icedtea JDK. I've not used it much, but I've accessed several sites using Java with it. They say that the plugin is missing functionality, but I've never had any problem, when I needed it.

      Now, if only Gentoo guys would fix OOo broken compilation with icedtea... :)

    45. Re:64 bit Java? by jonaskoelker · · Score: 1

      The VM takes a ridiculous amount of time to start up

      A quick test: On http://www.cs.ubc.ca/~harrison/Java/sorting-demo.html you'll find 16 applets [yay for algorithm animation]. It took "a few seconds" to load that page for me. Assuming _everything_ is JVM startup time, it's 0.25 seconds per applet. While that is slow, it's isn't exactly ludicrous speed; err... lack-of-speed.

      it's really intrusive when it sits in your system tray and constantly announces its new updates.

      Try the Linux version instead ;)

      So for all the OSS advocates out there, stop and think for a minute before you bash Java applets.

      I love them. In part for the prospect of 100% Free Software client side web applets. Also, I think they're just painful enough to code that you only do it if you have to*. At least, I haven't seen people do their entire site in a java applet.

      What I have seen is the sorting algorithms demo, and an app which shows move sequences on a rubik's cube. I think both are reasonable candidates for apps delivered in a browser.

      * whether that's an applet thing or a property of the core language, I don't know, but I have my own opinion.

    46. Re:64 bit Java? by Anonymous Coward · · Score: 0

      These jokes are so 1999. Java has good performance now days.

      I ran vista the other day and is was soooo slow. Its written in C so C must be slow right?

      Languages are tools. Not religions.

    47. Re:64 bit Java? by tsotha · · Score: 1

      You must be joking. Code takes easily twice as long to write in C++.

    48. Re:64 bit Java? by shutdown+-p+now · · Score: 1

      but it strikes a pretty good balance between abstraction, performance, and complexity (much as I hate to use this argument, not every programmer out there is a rock star).

      I wouldn't say the balance is still good by now - in 2008, not having first-class lambdas/closures in your language is downright embarassing; heck, even C++0x is getting them, while Java still doesn't plan to. That said, there certainly is a large target audience for which such features are not desirable and may even be harmful, and Java is a language that fits fine there. Given how much its development has stagnated recently, though, I think it has started its shift into COBOL of the 21st century.

    49. Re:64 bit Java? by shutdown+-p+now · · Score: 1

      I wait with bated breath for a hyperlink that I can click on to play an Ajax version of Quake 2.

      You will be able to, as soon as WHATWG will standardize 3D operations for the canvas element in HTML5 (it is still in HTML5, isn't it?). That demo you linked to still uses OpenGL as a renderer (native, not Java), and once you have the
      API, remaking it in JS won't be a big deal.

      Now if you can show a version which does software rendering in Java, then, yes, it will be impressive. I guess it's doable - there's a demo of Quake1 with software rendering on Silverlight around, and if .NET runtime can be fast enough, than so can Java VM.

    50. Re:64 bit Java? by pdusen · · Score: 0, Troll

      Only if you're an idiot...

    51. Re:64 bit Java? by thetoadwarrior · · Score: 1

      Let's not forget that the world's largest MMORPG, Runescape, runs in Java.

    52. Re:64 bit Java? by thetoadwarrior · · Score: 1

      Sounds like you computer must be as rubbish as your argument.

    53. Re:64 bit Java? by ggeens · · Score: 1

      Seriously, Java plug-ins are still around for some reason?

      Every once in a while, I come across an applet. They are still used, mostly for specific business applications. (Meaning, you only see it when you're logged in into a specific client/partner area of the web site. Or on an intranet.) But even then, they are pretty rare.

      --
      WWTTD?
    54. Re:64 bit Java? by ckaminski · · Score: 1

      Ah, another spineless AC Ruby/Python fan. :-)

      Sorry, been there, done that. I'll keep my statically typed languages, thank you.

    55. Re:64 bit Java? by danieltdp · · Score: 1

      Heretic. Burn!!

      --
      -- dnl
    56. Re:64 bit Java? by blinky · · Score: 1

      In the Java ControlPanel under the "Java" tab
      "Java Applet Runtime Setting" section
      "java Runtime Parameters" eg -Xms128M -Xmx256M

    57. Re:64 bit Java? by danieltdp · · Score: 1

      GP is sorta right. Java is here to stay, but applets dispeared. There has been a 64-bits virtual machine for a couple of year. What didn't exist was the java plugin for browsers, which are only good to run those useless applets.

      Nowadays, Java web apps uses Web Start technology, which are not browser plugins. They are desktop apps that take a descriptive text file from the net and use it to load web apps outside the browser.

      --
      -- dnl
    58. Re:64 bit Java? by ckaminski · · Score: 1

      And how exactly does Javascript get access to your local filesystem?

    59. Re:64 bit Java? by ckaminski · · Score: 1


      it's really intrusive when it sits in your system tray and constantly announces its new updates
      </quote>

      You can't really use this as a downside when Flash and every other application does the same damn thing.

      Something which isn't an issue in the Linux world anyway, with smart package repository technology... Are you listening, Microsoft? Extend Windows Update to everyone, please...

    60. Re:64 bit Java? by ckaminski · · Score: 2, Interesting

      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.

    61. Re:64 bit Java? by TheRaven64 · · Score: 1

      Java took the StrongTalk object model and introduced some painful compromises for efficiency, such as removing closures and adding non-object types, and introducing ugly syntax to make the C++ crowd happy. In Strongtalk (and any other Smalltalk dialect), you have two kinds of integers, SmallInt and BigInt. A SmallInt is a value that is small enough to fit in a pointer. If you perform an operation on a SmallInt that overflows, the result is a BigInt. You can use the two interchangeably.

      --
      I am TheRaven on Soylent News
    62. Re:64 bit Java? by Rolgar · · Score: 1

      I do know of 2 sites, Sam's Club photos uses java for the batch upload option (a few clicks to get all of the photos in a directory, instead of 3 clicks per photo), and the Yahoo live fantasy sports draft rooms, although I saw something on their site recently that indicated that they've changed that tech, so it might be non-java now.

      I just crashed my Debian install a few weeks back, and when I reinstalled, I happened to find openjdk-6-jre with the icedtea-gcjwebplugin, and the Sam's Club site worked. It looked ugly, but it got the job done.

    63. Re:64 bit Java? by LWATCDR · · Score: 1

      The problem with Java is that it is really easy to write a bad program that works.
      That and people think java is slow. Applets can be very good but they got a bad name thanks to people using them for things like hover buttons.
      There are some very good Java programs out there like JEdit, Netbeans, and Eclipse. Java FX could be a good replacement for Flash and Moonlight.

      --
      See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
    64. Re:64 bit Java? by nekokoneko · · Score: 1

      If I'm not mistaken, IcedTea does not support signed applets yet, which are run in untrusted mode. My bank uses them and I can't log into their website.

    65. Re:64 bit Java? by ketilwaa · · Score: 1

      Are those the useless applets that will make my internet banking actually work on 64 bit, without crappy workarounds? Not very useless to me... BankID, is the name of the "service". It is, afaik, used by all major banks in Norway. I'm sure we are not alone going through this stuff.
      The Java browser plugin and Flash was the main obstacles, that made me go back to 32 bit Ubuntu. Now, all I need is Mozilla Weave for 64 bit. (Actually, for it to actually work at all, these days)

      I'll give these apps half a year to mature and I'm back on 64.

      Today, I also read that Adobe Air will be out of beta for linux in short time. Article in Norwegian, no source, I'm afraid If that also comes in 64 bit, these are good times for 64 bit.

    66. Re:64 bit Java? by Flammon · · Score: 1

      James, is that you?

    67. Re:64 bit Java? by danieltdp · · Score: 1

      You are right. I forgot about banking applets. I guess its the only area were Java applets can be considered mainstream. Does anyone knows other cases besides banking were applets are common?

      --
      -- dnl
    68. Re:64 bit Java? by Just+Some+Guy · · Score: 1

      huh? i drop blu-ray disks into my ps3 and its playing within a few seconds. you're smoking crack.

      That's true. It was able to load "Men In Black" in only 43 seconds, which is nearly twice as fast as some other Sony gear. It might still take a while to load "Iron Man" the first time, but that's only because it's upgrading its firmware. In all, the PS3 is much better than your average cheap DVD player which can't even upgrade its firmware or run a cool virtual machine to keep you from stealing all your content, at least for another couple of months.

      --
      Dewey, what part of this looks like authorities should be involved?
    69. Re:64 bit Java? by ericrost · · Score: 1

      then theres j2me, and i'd wager if you have any tivo type device, or even set-top box for your cable service, or blu-ray player, or most mobile phones these days, then you have java working for you there too.

      I can't believe you would point out those unresponsive steaming piles to try and support your point. Cable settop boxes (especially the DVR's) are the WORST examples of badly implemented UI's and schedulers that I have run across. THE POINT OF THE DEVICE IS TO RESPOND TO REMOTE CONROL INPUT, AND RECORD PROGRAMMING. EVERY SINGLE ONE DOES NEITHER RELIABLY (I'VE USED MULTIPLE IMPLEMENTATIONS OF THEM FROM COX CABLE IN NEBRASKA, COMCAST IN NORTHERN CALIFORNIA, AND FORMERLY INSIGHT COMMUNICATIONS IN CENTRAL ILLINOIS)

    70. Re:64 bit Java? by quintesse · · Score: 1

      There was JQuake (http://fragisland.fragzone.se) but it doesn't seem to exist anymore unfortunately. And this was many years ago. Java has gotten much faster in the mean time. But your right of course that nobody is going to do software rendering when you have all that Gfx hardware, even in modern mobile phones.

    71. Re:64 bit Java? by ericrost · · Score: 1

      Web conferencing such as WebEx and Lotus Sametime. (My corp uses both and I can't get into the damned things from my home laptop before now. Yay teleconferences on the couch.)

    72. Re:64 bit Java? by moderatorrater · · Score: 1

      (gasp! modern JVMs perform well!)

      That's not my experience at all. Most java apps I run on the desktop require at least double the resources of a similar program that's not written in java. If it were just a few, or even half, I would think it was the programmer's fault. When it's every single one of them, then there's something wrong with java itself.

    73. Re:64 bit Java? by danieltdp · · Score: 1

      Are you sure those are not WebStart technology?

      --
      -- dnl
    74. Re:64 bit Java? by Anonymous Coward · · Score: 0

      People always sound like software grows on trees. Where I live people have to write software. That costs a lot of time. And because it is no trivial task you have to pay good money for the time of a skilled programmer.
      So if you are smart you let the developer do his work with the tools that are best fitted to the task, where support of the given task is best, with good frameworks that reduce the work to do, that eventually allow easy adaption to changed requirements, and that give less opportunities to make mistkakes.

      And then if the solution needs too much memory you just pull a dollar out of your wallet and buy some more RAM. Memory is cheap, developers are not.

    75. Re:64 bit Java? by ericrost · · Score: 1

      Yep, because they don't work on my Ubuntu x86_64 installation when it hangs on "Checking Browser Plugin". We use some webstart stuff internally. I use some java apps at home (none that use webstart, but stuff certainly works, and I know the failure modes for ff and webstart as I had to hack my work ff install to autolaunch java webstarts rather than save the text file to the desktop which is the default behavior in a lot of versions of the jre).

    76. Re:64 bit Java? by psetzer · · Score: 1

      After 1.6_10 and JavaFX, they're effectively one and the same. There's a JavaFX demonstration of an experimental feature where you can drag the Applet from its spot in the page and it becomes a regular JWS application with only the slightest pause as it spawns a new OS-level container. I'm pleasantly surprised to see all that Sun's done to improve Applets even after they've mostly failed in the market.

      --
      "Anyone who attempts to generate random numbers by deterministic means is living in a state of sin." -- John von Neumann
    77. Re:64 bit Java? by Ilgaz · · Score: 1

      You wrote too much. You should tell them to get Vuze and see that "1,500,000 users" written on status bar. They are Windows, OS X and Linux users combined running single professionally written open source code which uses native apps when in need.

    78. Re:64 bit Java? by Ilgaz · · Score: 1

      Kaspersky online AV checker (which is Win32 only) and Trend Micro Housecall both uses advanced/signed applets to do their job or monitor it. Trend's implementation is particularly impressive since it runs on Windows, OS X, Linux.

      Java Applet games are a huge business even scaling to full feature games like Runescape.

      They memorised the JVM 1.1 junk in 1990s and it gives them good karma. Besides pros who are out there to show everything except .NET/Mono as junk, it is the deal. It is ignorance.

    79. Re:64 bit Java? by danieltdp · · Score: 1

      Runescape is webstart, not applet. This kind of misconception is in the root of many problems regarding java. I worked on a large desktop application that used applet technology and it was an absolute nightmare. We eventually migrated to web start and things just started working smoothly.

      --
      -- dnl
    80. Re:64 bit Java? by mikehoskins · · Score: 1

      (Plus, with projects like Scala and Clojure it's looking increasingly like the JVM isn't going anywhere any time soon, regardless of Java's fate)

      ...and especially JRuby! www.jruby.org

    81. Re:64 bit Java? by Anonymous Coward · · Score: 0

      this joke needs reworking to reflect the fact that the delay in response is due to garbage collection

      it's the way I tell 'em

    82. Re:64 bit Java? by Anonymous Coward · · Score: 0

      Parent was modded "funny," which I can only assume is because it is being viewed as sarcasm.

      At least I hope so. C++ beats Java hands down in the "unusable abstraction" department.

    83. Re:64 bit Java? by nova_ostrich · · Score: 1

      Notes on your Java vs Flash upsides. * Flash also supports TCP sockets, not just HTTP requests. Also, AMF (also commonly known as Flash remoting) is a lightweight binary format available to Flash commonly used for live streaming data. The primary implementation for the server-side is written in (you guessed it) Java. * Correct, Flash doesn't support signing to add increased functionality. However, Flash Player 10 now allows the user to open and save files from the local file system. * Yeah, OpenGL would be cool. There is now limited 3D support in FP10. * Have you heard of Flex? No keyframes in sight. Many Java developers love it for building web UIs that integrate with Java backends. Macromedia started working on Flex for exactly the reasons you describe. Developers aren't animators and frame-based UI development doesn't make much sense. * I've not needed to internationalize any of my recent projects, so I can't respond to the current state of this one. * Yes, Java is faster. However, Flash's VM speed is much closer to Java than that of most JavaScript engines.

      --
      It's scary being a Flash and Flex developer on Slashdot. You guys are unnaturally rabid.
    84. Re:64 bit Java? by fm6 · · Score: 1

      Yeah really. Even if Java browser plugins still had much of a user base, what's the point of running them 64-bit? Tiny applications that run inside browsers are not to going to benefit from the extra power of the x64 world.

      The web actually is a decent way to deliver Java applications. Provide your users a Java Web Start link, and with one click they can download the application code and runtime (both kept up to date automatically) that they need to run the app. And of course, you can use a 64-bit runtime.

      That said, I'm afraid this was inevitable. I used to work in the Java SE group at Sun, and all the time I was there, the demand for a 64-bit browser plugin was incessant. It was inevitable that Sun would give in on this, even though it means them spending money they can't spare for no real benefit to anybody.

      (BTW, your sig and my sig need to get together and have a talk.)

    85. Re:64 bit Java? by petermgreen · · Score: 1

      And this story is only important if somebody out there has a burning need to run a 64bit Java app... in a web browser.
      Java code doesn't have a bitness in that sense (native code it calls into does of course but browser applets don't generally use custom native code because that requires the whole signing/permissions popups rigmarole).

      The reason this is important is because it should allow java applets to work properly in the geko based browsers that ship with 64 bit linux distros. There are third party plugins already but at least the one I have tried had some issues (it was lacking support for applets to interact with javascript in the browser, supposedly someone has written a newer one that solves that but I haven't tried it myself yet).

      I wonder if and when they will get arround to releasing the source for the official java plugin (last I heard they were working on it,if it has already happened please post a link).

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
    86. Re:64 bit Java? by Burz · · Score: 1

      IcedTea lacks decent JNLP (Webstart) support (supporting only 1.0 of the file format), thus some games and applications that use, say, v 1.5 will fail to start. JNLP is how most Java applications are started over the web now.

    87. Re:64 bit Java? by ToasterMonkey · · Score: 1

      LOUD NOISES

    88. Re:64 bit Java? by SunSpot505 · · Score: 1

      And while we're on browser based games with Java in the name....

      There's also this JavaScript version of Wolfenstein! not quite the same on either front, but hey the first part of the name is the same right?

      http://www.nihilogic.dk/labs/wolf/

    89. Re:64 bit Java? by doktorjayd · · Score: 1

      actually, this part of my original rebuttal was in relation to the troll's assertion that everyone had ditched java...

      there is a time and a place for everything, but if your penny-pinched cheap ass hardware cant run the software, then where do you lay the blame?

      certainly every mobile phone i've had in the last 5 years has run java applications which are responsive and stable ( i concede this is usually one golf game per phone, but still...), and i dont go for the top of the line bright and shineys...

    90. Re:64 bit Java? by alexj33 · · Score: 1

      Knock Knock.

      Who's there?

      SUDDENLY! (.0001 microsecond later)
      Java Fanbois: "JAVA IS NOT SLOW!"

    91. Re:64 bit Java? by Anonymous Coward · · Score: 0

      If this Q2 port represents the state of Java and gaming on Linux, I am really sorry. Give it a try! Fact-paced Quake 2 shooter completely freezes every time the screen has some action or there are more than one sound playing at the same time.

      I am not kidding. The game ran better on DOS in 1997!

    92. Re:64 bit Java? by Bert64 · · Score: 1

      A lot of management apps for various network devices use java applets...
      Programs like VNC have a java applet frontend too, which are very useful in virtual machine managers like proxmox... Having to load a fat client ala vmware is a lot more hassle.

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    93. Re:64 bit Java? by Bert64 · · Score: 0

      Twice as long to write, half as long to execute...
      Or do you only ever execute your code once?

      --
      http://spamdecoy.net - free throwaway anonymous email - avoid spam!
    94. Re:64 bit Java? by SunSpot505 · · Score: 1

      Why not play Wolfenstein 3D instead? (JavaScript) http://www.nihilogic.dk/labs/wolf/

    95. Re:64 bit Java? by Anonymous Coward · · Score: 0

      Javas Performance itself is great (compared to '99).
      The STARTUP of JVM is still... ... LOOOOOOOOONG pause ... ... What was the topic?

  3. 64-bit and 32-bit binaries by robo_mojo · · Score: 5, Informative

    For most people there is nothing to hold you back from running 64-bit Linux.

    Lack of 64-bit {Java,Flash,Wine} doesn't hold you back from 64-bit Linux. A decent Linux distro can handle both 64-bit and 32-bit binaries.

    1. Re:64-bit and 32-bit binaries by aled · · Score: 2, Informative

      I think there is a problem running a 64 bit browser with a 32 bit Java plugin.

      --

      "I think this line is mostly filler"
    2. Re:64-bit and 32-bit binaries by micheas · · Score: 1

      For me 32bit flash on amd64 is always on the top layer (on top of drop down menus) and crashes every few hours.

      (I assume that is what is causing it as my laptop that runs in 32bit mode has none of those issues.)

      Hopefully 64bit flash will fix those issues. (or GNASH will finally close the gap enough to work better than 32bit Flash. for youtube GNASH is better than Adobe Flash, but other than that one case GNASH fails so much more than Adobe Flash that it is hard to migrate. I wish I could spec GNASH with Midori and Galeon and Adobe Flash with Konquerer and Iceweasel, Hmm time to file a bug report, now if only I can figure out which packages to file it against...)

    3. Re:64-bit and 32-bit binaries by bobstreo · · Score: 2, Funny

      Yeah if only running wireless in 64 bit worked without the ritual blood sacrifice. Or ndiswrapper, or having to re-install with every kernel update.

      Stupid ath wireless.

      Then maybe I'd care about Java/Flash...

    4. Re:64-bit and 32-bit binaries by Froeschle · · Score: 2, Informative

      While it is true that you can run 32 bit binaries under 64 bit Linux, one problem I have had in particular is the combination of the two. I have a 64 bit system but I could only run the 32 bit version of the Java plugin under 32 bit Firefox, which of course breaks most other existing 64 bit plugins that would not work under a 32 bit Firefox installation. There are wrappers and such but the whole thing is just a major PITA. I for one welcome the new 64 bit Java plugin!

    5. Re:64-bit and 32-bit binaries by HeronBlademaster · · Score: 2, Informative

      Get a non-crappy wireless card.

      In all seriousness though, my wireless card (Intel 3945 ABG) didn't work with kernel 2.6.25 x64 (though it did in 2.6.24 x86), but then I upgraded to 2.6.26 x64... and it works flawlessly, without redoing any wireless configuration or reinstalling anything else. Even the LED blinks appropriately :) (I wasn't even trying to make the wireless work when I upgraded the kernel, I was trying to make my audio work. Still no luck there.)

    6. Re:64-bit and 32-bit binaries by AeneaTech · · Score: 1

      Can you explain what that problem might be? Since I'm running 64-bit firefox and 32-bit flash+java just fine...

    7. Re:64-bit and 32-bit binaries by aled · · Score: 4, Informative
      --

      "I think this line is mostly filler"
    8. Re:64-bit and 32-bit binaries by Eil · · Score: 1

      Lack of 64-bit {Java,Flash,Wine} doesn't hold you back from 64-bit Linux. A decent Linux distro can handle both 64-bit and 32-bit binaries.

      But firefox can't. :(

    9. Re:64-bit and 32-bit binaries by TheSpoom · · Score: 1

      You're almost certainly running IcedTea if you're running a Java plugin in a 64-bit browser.

      As a sibling pointed out, people have been bugging Sun to release a 64-bit plugin for years (including myself).

      --
      It's better to vote for what you want and not get it than to vote for what you don't want and get it.
      - E. Debs
    10. Re:64-bit and 32-bit binaries by Hurricane78 · · Score: 1

      Normally yes. But there's a wrapper for it. As is for flash. I used Firefox + nspluginwrapper + Flash for quite some time now. As soon as Flash 10 (64 bit) becomes stable (It's still slower and buggier here than Flash 9 (32 bit) with the wrapper.), nspluginwrapper becomes obsolete.

      --
      Any sufficiently advanced intelligence is indistinguishable from stupidity.
    11. Re:64-bit and 32-bit binaries by Skrapion · · Score: 1

      That's really a distro problem. If you have a 32-bit version of Firefox, your distro should make it easy to install 32-bit plugins.

      Of course, with 64-bit support taking off, it's a problem that may not need to be solved.

      --
      The details are trivial and useless; The reasons, as always, purely human ones.
    12. Re:64-bit and 32-bit binaries by Skrapion · · Score: 1

      "Doctor, it hurts when I use a 64-bit browser!"

      I think you can figure out the solution to the problem.

      Don't get me wrong, this is good news, but it's not a huge deal.

      --
      The details are trivial and useless; The reasons, as always, purely human ones.
    13. Re:64-bit and 32-bit binaries by j79zlr · · Score: 2, Interesting

      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.
    14. Re:64-bit and 32-bit binaries by rdnetto · · Score: 1

      If your browser really needs 4 GB of RAM, you're doing something wrong.

      --
      Most human behaviour can be explained in terms of identity.
    15. Re:64-bit and 32-bit binaries by AeneaTech · · Score: 1

      Actually, the links refer to 64-bit java and not using a 32-bit java plugin in a 64-bit browser... But, I don't come across many java applets and I might just have been lucky. Checked around, it does not always work, ah well, I thought it did (it did for as far as I know ;))

    16. Re:64-bit and 32-bit binaries by AeneaTech · · Score: 1

      Yes, I indeed am, and when checking up on it I read that not everything works so well for every user. Must have been lucky I suppose! (finally!)

    17. Re:64-bit and 32-bit binaries by amorsen · · Score: 1

      It sucks to have to bring in 32-bit glibc and all the other libraries just because a couple of stupid companies are living in the past. Welcome to 1992, Sun!

      --
      Finally! A year of moderation! Ready for 2019?
    18. Re:64-bit and 32-bit binaries by drspliff · · Score: 1

      The point being that you can use 64bit native for apps that matter, and 32bit for everything else.

      Ofcourse that means having two sets of libs installed which takes up more space, and people whine and bitch about not being "real 64bit" because their `ls` and `more` commands aren't 64bit native.

      From my perspective, running everything as 64bit is just a waste of memory which the apps which are worth running as 64bit native have less resources because of that.

    19. Re:64-bit and 32-bit binaries by eulernet · · Score: 2, Funny

      I really love the comment:

      Submitted On 07-FEB-2005
      The_Crusher

      Please fix for Tiger. We certainly won't appreciate having to wait 18 months for a fix that's probably trivial on Sun's part.

    20. Re:64-bit and 32-bit binaries by Anonymous Coward · · Score: 0

      > From my perspective, running everything as 64bit is just a waste of memory

      So, having all those libraries twice in memory (in addition to on disk) in 32 and 64 bit versions is not a waste of memory?
      Keep in mind that 64 bit also forces PIC for libraries (and it is far, far less of a performance issue than on 32 bit, so much that PIE executable might become the norm) so there is a much better chance that the code pages will actually be shared between processes.

    21. Re:64-bit and 32-bit binaries by JamesP · · Score: 1
      --
      how long until /. fixes commenting on Chrome?
    22. Re:64-bit and 32-bit binaries by Anonymous Coward · · Score: 0

      But this requires handling two lib directories and big trickery mess for developers. You have to provide tons of 32 bit libraries in 64 bit systems, too... that's a mess too.

      32 bit libraries in a x86_64 shouldn't be the common case.

    23. Re:64-bit and 32-bit binaries by ckaminski · · Score: 1

      Sure. libc get's loaded once in 32 bit mode, and once in 64 bit mode, and code pages shared amongst ALL running processes. I suppose if you had to load a 32bit Gnome AND a 64bit Gnome then you'd have some good argument...

    24. Re:64-bit and 32-bit binaries by Anonymous Coward · · Score: 0

      Use Konqueror if you don't have the plugin already. It'll use the JVM directly instead of needing it in the plugin structure, works great in 64bit envs.

    25. Re:64-bit and 32-bit binaries by Ilgaz · · Score: 1

      Watching the Linux (especially 64bit) community feedback for such a favour from Sun in disaster economy could be the reason why I hold back from Linux. I bet MS and their Mono/Moonlight puppets must be smiling now.

    26. Re:64-bit and 32-bit binaries by Anonymous Coward · · Score: 0

      It segfaults about every 3rd or 4th time I close a window with an active flash applet here on Debian/unstable. As Debian/unstable is generally pretty damn solid, I'm betting it's the plugin's fault.

    27. Re:64-bit and 32-bit binaries by Sj0 · · Score: 1

      I don't understand. "You can use both 32 and 64 bit apps in a good linux distro" is the sort of feedback keeping you from using linux?

      A little harsh, isn't it?

      --
      It's been a long time.
    28. Re:64-bit and 32-bit binaries by petermgreen · · Score: 1

      IIRC it doesn't work with the sun java plugin because the sun java plugin is an oji plugin not a npapi plugin.

      --
      note: i'm known as plugwash most places but i screwd up registering that here somehow in the past and now can't register
  4. Aw crap by j-cloth · · Score: 1

    I finally got things setup just the way I want them in my 32-bit install and now the only things that were keeping me from running 64 bit are fixed. Obviously, I now have to reinstall.

    1. Re:Aw crap by aled · · Score: 4, Funny

      obviously you need to reinstall... with 128-bits Linux...

      --

      "I think this line is mostly filler"
    2. Re:Aw crap by RiotingPacifist · · Score: 2, Funny

      Meh powers of 2 are for wimps, 100bit Gentoo is where its at!

      --
      IranAir Flight 655 never forget!
    3. Re:Aw crap by JYD · · Score: 1

      Yeah, I tried installing 128-bit Linux with a setup consisting of 2 AMD64's, but all I got was a 65-bit OS.

      On the serious side, I've been running 64-bit Linux without any problems. The transition from 32-bit Linux to 64-bit Linux was transparent. I can't say the same for the transition from 32-bit Vista to 64-bit Vista though, mostly due to video codec problems.

    4. Re:Aw crap by mqduck · · Score: 1

      Speaking of not getting jokes... How can two 64-bit CPUs give you a 65-bit machine?

      --
      Property is theft.
    5. Re:Aw crap by Haeleth · · Score: 1

      Speaking of not getting jokes... How can two 64-bit CPUs give you a 65-bit machine?

      2^64 + 2^64 = 2^65

  5. Most of my 3rd-party apps do not work with Java 6 by rminsk · · Score: 3, Informative

    Most of the 3rd-party applications my work run only work with with java runtime 5.0 and do not work with 6.0. Until sun provides a 64-bit version of Java 5.0 then I will be stuck on the 32-bit version with a 32-bit browser.

  6. About time! by jonesy2k · · Score: 1

    ...that is all.

    1. Re:About time! by INeededALogin · · Score: 3, Informative

      ...that is all.

      yup, very much about time. All of us sysadmins in Java shops have been hitting the 4 GB maximum for awhile. Java really does love the memory

    2. Re:About time! by glwtta · · Score: 1

      Wasn't the actual limit for 32-bit Java a lot lower, something like 1.4GB, or was that just on Windows?

      Anyway, I too have been enjoying being able to allocate 16GB Java heaps (hey, when you have 200GB of XML to parse/index, it helps).

      --
      sic transit gloria mundi
    3. Re:About time! by afidel · · Score: 2

      Dear god, the reason you didn't want to go over ~1.25GB of heap in Java x86 isn't that it can't go higher, it's that garbage collection times become significant enough that they cause user noticeable delay and possibly timeouts.

      --
      There are 4 boxes to use in the defense of liberty: soap, ballot, jury, ammo. Use in that order. Starting now.
    4. Re:About time! by pavon · · Score: 1

      Ugh, this. As much as I hate to say it, I am actually looking forward to the Vista rollout here at work because our Java desktop apps (data-crunching and visualization) will finally be able to use more than 1.3GB of memory.

    5. Re:About time! by shutdown+-p+now · · Score: 1

      All of us sysadmins in Java shops have been hitting the 4 GB maximum for awhile. Java really does love the memory

      You work in a shop which runs Java applets that hit the 4Gb maximum, and have been doing so for a while?

      I don't know how much they pay you for that hell of job, but whatever it is, it's nowhere near enough.

  7. 128 bit computing is around the corner by Anonymous Coward · · Score: 2, Interesting

    The time has come to begin discussing 128 bit computing.

    1. Re:128 bit computing is around the corner by Hal_Porter · · Score: 5, Funny

      64.0 bits should be enough for anyone.

      --
      echo -e 'global _start\n _start:\n mov eax, 2\n int 80h\n jmp _start' > a.asm; nasm a.asm -f elf; ld a.o -o a;
    2. Re:128 bit computing is around the corner by Anonymous Coward · · Score: 0

      Oh please no. I'm already using at most 5 bytes from each 8-byte pointer, and you'd like to increase pointer size to 16-byte already?

    3. Re:128 bit computing is around the corner by corsec67 · · Score: 4, Funny

      My Intel processor claims that 63.99 bits should be enough for everybody.

      --
      If I have nothing to hide, don't search me
    4. Re:128 bit computing is around the corner by FlyingBishop · · Score: 2, Insightful

      Who was the genius that modded this interesting? 128 bit computing is a joke. Even if we had anythin resembling the amount of memory you need to make 128 bit computing worthwhile (That's 16.8 million Terabytes of RAM,) it is likely that this hypothetical computer (if any possible use on the desktop could be conceived) would have something on the order of 2048 cores, if not many more.

      In those circumstances, I would prefer the architecture that restricted each core (or a subset of cores) to their own 64 bit domain of memory addresses. Anything beyond that could be handled by speaking between the different cores.

      I can accept that there could be some applications in a hundred years or so that might require 128 bit on the desktop. That said, while 64-bit might not be enough for anyone, it is almost without doubt enough for any individual processor.

      And we've just nearly finished porting everything to 64 bit. I'd rather emulate 128 bit on 64 bit hardware than do that again.

    5. Re:128 bit computing is around the corner by keeboo · · Score: 1

      My Intel processor claims that 63.99 bits should be enough for everybody.

      Man, that joke is really old.
      What next, jokes on writeback cache too?

    6. Re:128 bit computing is around the corner by bcrowell · · Score: 1

      What I'm really looking forward to is 256-bit addressing, because then I can have an in-memory relational database with a separate record for every atom in the planet.

    7. Re:128 bit computing is around the corner by MostAwesomeDude · · Score: 1

      Nope. Go check Moore's Law. We won't be switching until 2050 or so.

      --
      ~ C.
    8. Re:128 bit computing is around the corner by Anonymous Coward · · Score: 2, Interesting

      ~128 bits = 2km * 2km * 2km cube of silicon.
      ~168 bits = every atom on earth.
      ~190 bits = every atom in the solar system.
      ~262 bits = every atom in the universe.

    9. Re:128 bit computing is around the corner by makapuf · · Score: 1

      Yes, 128 bits addresses can be a joke. 128 bit data path has been present since a long time (PIII with SSE IIRC), and here 256 bits or more could be interesting.
      The number of 'bits' of a system is only defined when address == size of an integer word register == size of an instruction == size of a float register == size of a vector register == size of a memory word ... This is rarely the case and some of these sizes could (sometimes not very practical) be different.

    10. Re:128 bit computing is around the corner by johndmartiniii · · Score: 2, Funny

      Agreed, I'm so sick and tired of playing with this old in-memory relational database with a separate record for every atom in my house.

      --
      If you don't know what you're doing, you can't make mistakes.
    11. Re:128 bit computing is around the corner by Anonymous Coward · · Score: 0

      i just had mini-waking-nightmare when i noticed the recursivity on that..

      and then it hit me that some governement drone must be reading your post and think 'that's it, we cant finally hunt down the terrorists'

      i and thanks to your comment i now have to upgrade my tinfoil-hat to use anti-tin atoms, and the containment field calculations are killing me :S

    12. Re:128 bit computing is around the corner by jonaskoelker · · Score: 1

      And we've just nearly finished porting everything to 64 bit. I'd rather emulate 128 bit on 64 bit hardware than do that again.

      But we all learned the lesson in the progress, right? From now one, everyone uses proper typedefs in their code, right?

    13. Re:128 bit computing is around the corner by zoefff · · Score: 1

      probably the comment was meant as a joke (I'm afraid of being whoooshed ;-) )

      But on the serious side, could that not have some uses in data centers/cloud computing?

    14. Re:128 bit computing is around the corner by tyrione · · Score: 2, Interesting

      It took 30 years of PC use to roughly move from 8 bit to 64 bit and you're expecting it to take 100 years to move from 64 bit to 128 bit?

      It sure as hell won't take that long, not to mention the notion of Memory won't even be remotely the same as it currently stands.

    15. Re:128 bit computing is around the corner by ckaminski · · Score: 1

      Orders of magnitude difference... Not even comparable.

      64K to 4GB is a difference of 6.5536 x 10^4

      64bit to 128 bit is a difference of 1.84467441 &#215; 10^19 - nearly 15 orders of magnitude difference.

      Not comparable.

    16. Re:128 bit computing is around the corner by TheRaven64 · · Score: 1

      You are assuming a linear progression for no justifiable reason.

      With 8-bit addresses you can address 256 bytes. If you wanted to store more than a sentence, you needed (complex) indirect addressing modes (typically giving you 8bit+8bit addresses, or 64KB). The x86 PC was never an 8-bit platform though, it was a 16-bit CPU with support for 8-bit peripherals. A 16-bit CPU can address 64KB, although the PC architecture allowed for 1MB via indirection. Individual segments could be up to 64KB, which was enough for a long text document, but only a very small bitmap. The total space, 1MB, was enough for all but the longest text documents (my book was less than that), but quite cramped for images.

      Moving to 32 bits gave 4GB of address space; enough for large images, and even video. Any text document a user might want to edit, including rich text with full undo history, can be stored in a process's address space. Large raw images are only around 50MB, so 32-bits was enough for them too. The only things it couldn't fit were big videos and 3D scientific datasets. With 64-bits, you can address any dataset that currently exists. You have so much space that most implementations are really 40-bit or 48-bit and ignore 3-4 bytes of pointers when performing address translation. 48-bit addressing is enough for a 10-hour uncompressed, stereoscopic, 2160p, 60fps video.

      With 8-bit systems, a user could produce more data than the CPU could handle just by typing. With a 16-bit system, users could produce more data than the CPU could address by drawing. With a 32-bit system, you need a decent video camera or a 3D scanner. With a 64-bit CPU... well, no one's yet generating datasets that big, so we don't know. Even the LHC is only producing datasets of 1.5TB or so, which only needs 41-bits if you want to address it directly. It will be a very, very long time before 64 bit addresses seem small.

      --
      I am TheRaven on Soylent News
    17. Re:128 bit computing is around the corner by intheshelter · · Score: 1

      And quit discussing Linux as though it's ready for the mainstream public.

    18. Re:128 bit computing is around the corner by jbolden · · Score: 1

      128 bit may not have anything to do with memory. The Crays made use of wide vector pipes for rapid vector computations. As we move towards more 3D effects we may see the same sorts of moves. For example we already see the GTX 280 using a 512 bit bus.

    19. Re:128 bit computing is around the corner by ultranova · · Score: 1

      What I'm really looking forward to is 256-bit addressing, because then I can have an in-memory relational database with a separate record for every atom in the planet.

      But what about every possible combination they can form ?

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    20. Re:128 bit computing is around the corner by bcrowell · · Score: 1

      Agreed, I'm so sick and tired of playing with this old in-memory relational database with a separate record for every atom in my house.

      Yeah, I hear you, brother. I got to the same point, and I was getting ready to make the database of all the atoms in the computer with the database on it, but then my wife was like, "Honey, the computer's already way too big. I can't even get through the living room." We finally agreed to put the computer in the garage, because then the atoms in the computer don't count as atoms in the house.

      But seriously, if Moore's law holds, the size of the address bus you need only grows linearly with time. It's taken me about 25 years to go from owning a machine that filled its 16-bit address space to one that's roughly filling its 32-bit address space. At a rate of 16 bits per 25 years, it should be 2058 before we fill a 64-bit address space.

    21. Re:128 bit computing is around the corner by ultranova · · Score: 1

      Who was the genius that modded this interesting? 128 bit computing is a joke. Even if we had anythin resembling the amount of memory you need to make 128 bit computing worthwhile (That's 16.8 million Terabytes of RAM,) it is likely that this hypothetical computer (if any possible use on the desktop could be conceived) would have something on the order of 2048 cores, if not many more.

      Actually, I can imagine several game concepts where this would be extremely useful. Imagine a SimCity which actually simulates every resident and building (no, Societies doesn't count, I'm talking about something like SC4 on steroids). Or an RPG game where the whole world is always being simulated at full detail, guided by a complex AI for each character - the current ones are so limited in part because you have very little storage space and computing power per character.

      Heck, even for pure FPS games, this would allow proper physical simulation for the whole world. I, for one, welcome our new 10 Million Terabyte Overlords.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

    22. Re:128 bit computing is around the corner by ultranova · · Score: 1

      It will be a very, very long time before 64 bit addresses seem small.

      What if I have a database of IP6 addresses, and want it to scale linearly to all possible such addresses ? The most straightforward way to do that would be to simply translate the address to a memory location; for example, the pointer to a database record for a given address is given by the formula (base + address * recordsize). Since IP6 addresses are 128 bits long, even a 128-bit address space would be insufficient here.

      Granted, this is a pretty artificial example; however, the fact remains that a huge address space is useful in itself, even if the actual physical memory comes nowhere near to filling it.

      --

      Forget magic. Any technology distinguishable from divine power is insufficiently advanced.

  8. For most people by Anonymous Coward · · Score: 5, Funny

    For most people there is nothing to hold you back from running 64-bit Linux.

    Except the fact that Microsoft Windows is superior in every aspect.

    1. Re:For most people by kimvette · · Score: 2, Funny

      Why? 1.84467441 x 10^19 bytes ought to be enough for anyone!

      --
      The Christian Right is Neither (Christian nor right). See: Matthew 23, Matthew 25, Ezekiel 16:48-50
    2. Re:For most people by Anonymous Coward · · Score: 0

      Except that almost all Linux desktop applications are a compromise.

    3. Re:For most people by Anonymous Coward · · Score: 0

      For most people there is nothing to hold you back from running 64-bit Linux.

      Except the fact that Microsoft Windows is superior in every aspect.

      Unless of course, you're looking for stability, security, or efficient use of resources...

  9. Glad to have it by crow · · Score: 1

    My employer recently outsourced timesheets to ADP, and ADP uses a horrid Java plugin. Hopefully this will get it working in Linux (well, when the site is stable enough to work--I expected better of ADP).

  10. 64 bit this, 64 bit that... by girlintraining · · Score: 0, Offtopic

    Okay, on one hand, native 64 bit apps are good because they speed up data execution--in theory. On the other hand, is this really "stuff that matters"? This isn't new technology. I read slashdot so I can get news on stuff in the industry that has some kind of impact, not to hear about product feature announcements. In other news, a network admin noticed the linoleum in the corner of the slashdot server room curled slightly today. x_x

    --
    #fuckbeta #iamslashdot #dicemustdie
    1. Re:64 bit this, 64 bit that... by Per+Wigren · · Score: 1

      Ignoring the little detail that java applet support doesn't matter anymore then yes, this is "stuff that matters". The kind of news you seem to be looking for you can find on c|net. Slashdot is the "News for nerds" site.

      --
      My other account has a 3-digit UID.
  11. Pamplona: Running with the bits. by Ostracus · · Score: 5, Funny

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

    Owning a 32 bit computer might be an issue.

    --
    Shai Schticks:"You don't make peace with friends, you make peace with enemies"
    1. Re:Pamplona: Running with the bits. by Anonymous Coward · · Score: 1, Insightful

      Did you miss the most people part? Because you are not most people if you don't have a 64bit capable system...

    2. Re:Pamplona: Running with the bits. by Anonymous Coward · · Score: 0

      Owning a 32 bit computer might be an issue.

      Being a 2 bit user would be an issue too.

    3. Re:Pamplona: Running with the bits. by fuzzyfuzzyfungus · · Score: 1

      But when you need support, you'll have your own newsgroup.

    4. Re:Pamplona: Running with the bits. by TheRaven64 · · Score: 1

      Uh, what? 64-bit systems have only been around for a few years in consumer terms, and a lot of 32-bit systems are still being sold in the NetBook segment and the cheap laptop / desktop markets. If you have a 64-bit system, you've upgraded in the last couple of years, and haven't bought the cheapest system. That definitely puts you in a minority.

      --
      I am TheRaven on Soylent News
  12. Bloat-o-matic by Anonymous Coward · · Score: 0

    Buy and build a nice 64 bit system, just to load it up with bloatware... nice.

    Skip...

  13. Let me get this striaght... by Zadaz · · Score: 1, Troll

    So... the most desirable applications for 64 bit Linux are virtual machines to run applications meant for somewhere else?

    So much for the "mainstream" myth.

    1. Re:Let me get this striaght... by Anonymous Coward · · Score: 0

      Mod parent up +1

  14. Re:Most of my 3rd-party apps do not work with Java by Nicopa · · Score: 1

    It's not easy to find things that stop working with new Java releases. Those must be very crappy applications.

  15. About friggin time by einer · · Score: 1

    Not that it matters now. Sun has already lost. They have zero desktop adoption and aren't going to get any, because they treat their biggest evangelists and early adopters like crap (flash for linux? sadly, yes). As a developer, I haven't been using JavaFX at ALL. No browser adoption, doesn't run on my chosen platform, doesn't show any interest in making my platform a priority. Why the hell should I write an app that requires yet another 30 meg download?

    I get all the vendor lock in, it's not open source so it's evil arguments. Save them. This is about Sun totally missing the boat, and doing nothing to fix the problem.

    1. Re:About friggin time by Yfrwlf · · Score: 1

      Well there are several ways to make things cross-platform, Java is just one of many. APIs are another. It's funny that something you wouldn't expect to be cross-platform is to some degree (when Wine works), the Windows API. More cross-platform libraries and APIs, and you don't really need virtual machines.

      The OS companies and Linux distro companies don't want this to happen, but the trend is slowly creeping toward cross-platform/distro programs, and all it does is make the OS matter less, even though of course it's an essential part of the computer. Users just want to get to their software comfortably, safely, and as quickly as possible.

      "Oh, cool game/program! What operating system are you running?"
      "Operawhat?"

      --
      Promote true freedom - support standards and interoperability.
    2. Re:About friggin time by Nicopa · · Score: 1

      So the proof that the newly released JavaFX will fail is that you haven't been using it for building applications? Uhm...

    3. Re:About friggin time by HeronBlademaster · · Score: 1

      "Operawhat?"

      op-er-a - noun
      1. an extended dramatic composition, in which all parts are sung to instrumental accompaniment, that usually includes arias, choruses, and recitatives, and that sometimes includes ballet. Compare comic opera, grand opera.
      2. the form or branch of musical and dramatic art represented by such compositions.
      3. the score or the words of such a composition.
      4. a performance of one: to go to the opera.
      5. (sometimes initial capital letter) an opera house or resident company: the Paris Opera.

    4. Re:About friggin time by pallmall1 · · Score: 1

      So the proof that the newly released JavaFX will fail is that you haven't been using it for building applications?

      A high percentage of developers code on linux systems, and if you want that code to run on windows, you're primarily limited to java or browser-based applications (although GTK is starting to look appealing). Deploying java applet and webstart apps is a nightmare, but javafx is being trumpeted by Sun as a solution to this -- for windows and mac only. Note that you need to download javafx just to view the demos, so even though it was downloaded by a lot of windows/mac users doesn't mean that a high percentage of those downloads were by people wanting to develop javafx apps. So the problem isn't that the grandparent poster doesn't use javafx, it's that if you use linux, you CAN'T use javafx.

      And it appears that that will be the case for quite awhile, because Sun has been purging comments from their blog post about javafx support on linux and solaris (all comments from December 6 and 7th are now missing, along with some others), and the editor of the java.net site says that Sun has "better things to do" than release a linux or solaris version of javafx.

      That may not be "proof that JavaFX will fail," but it certainly doesn't help foster its adoption.

      Sun can still turn things around if they release a 64-bit linux port of javafx. The 64-bit plugin technology is related to javafx, so maybe if and when Sun ever releases a linux version of javafx, it will be for both 32-bit and 64-bit systems. But I'm not going to hold my breath.

      --
      3 things about computers: they're alive, they're self-aware, and they hate your guts.
    5. Re:About friggin time by Nicopa · · Score: 1

      BS. That blog article you mention starts with: "JavaFX for Linux and Solaris is coming. Chill."... Chill... take it easy... they have released what they have and they'll soon release the rest.

      More BS: You don't need anything to see the JavaFX demos, of course, you need at least Java 6u10 (I think). But JavaFX runtime is downloaded automatically.

  16. No debian lenny support by GPLHost-Thomas · · Score: 3, Interesting

    But they still don't ship a debian package for Lenny with 64 bits support, we have to get the old Java 1.4...

    1. Re:No debian lenny support by Rolgar · · Score: 1

      Late reply I know, but I reinstalled Sid a couple of weeks ago, and found icedtea-gcjwebplugin. It's got the same version in Lenny, and when I installed in on my system, I was able to run the Sam's Club batch upload which is Java. It wasn't pretty, but I haven't seen what it looks like on another system, so it might be the program instead of IcedTea, but at least it worked without having to boot into my 32-bit environment.

    2. Re:No debian lenny support by GPLHost-Thomas · · Score: 1

      gcjwebplugin is nice, but not 100% compatible with the java plugin from sun, unfortunately... Thomas

  17. Madwifi-NG by 8086ed · · Score: 2, Interesting

    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.

    1. Re:Madwifi-NG by dido · · Score: 2, Interesting

      Well, I have a laptop that has such a card, and well, I found a version of the MadWifi drivers that works well enough on my 64-bit Gentoo. I must admit though that the search was incredibly frustrating, but given the recent news that Atheros has gotten more open, the situation can only improve with time.

      --
      Qu'on me donne six lignes écrites de la main du plus honnête homme, j'y trouverai de quoi le faire pendre.
  18. no DEB files? by supernova_hq · · Score: 4, Insightful

    What is it with large corporations and only creating RPM files for their software? I got the .bin file, but it just extracts to the current directory, without listing where all the files need to be copied to...

    If anyone can post a quick tutorial (or list of folder locations), that would be awesome.

    1. Re:no DEB files? by atomic-penguin · · Score: 3, Informative

      What is it with large corporations and only creating RPM files for their software? I got the .bin file, but it just extracts to the current directory, without listing where all the files need to be copied to...

      The simplest thing you could do, is use the "alien" package to convert it to a .deb file. The alien package manager works, most of the time, and it beats using cpio to extract the rpm file and repackage it as a deb.

      As for where the Java files go, they usually go under /usr/lib/java or /usr/lib/jre if I recall correctly.

      --
      /^([Ss]ame [Bb]at (time, |channel.)){2}$/
    2. Re:no DEB files? by styrotech · · Score: 1

      In the case of a bin file extracting to the current directory, the best place is to just extract it in /usr/local or /opt. Don't move the individual parts to places like /usr/bin /lib etc - leave those system dirs to be managed by the distros package manager.

      You may need to do stuff like symlinking the browser plugin file(s) into your browsers plugin directory and maybe adding the java bin directory to your $PATH, but that should be about it.

    3. Re:no DEB files? by Anonymous Coward · · Score: 0

      alien

      You can pay me in jellybeans.

    4. Re:no DEB files? by tyrione · · Score: 4, Informative

      What is it with large corporations and only creating RPM files for their software? I got the .bin file, but it just extracts to the current directory, without listing where all the files need to be copied to...

      The simplest thing you could do, is use the "alien" package to convert it to a .deb file. The alien package manager works, most of the time, and it beats using cpio to extract the rpm file and repackage it as a deb.

      As for where the Java files go, they usually go under /usr/lib/java or /usr/lib/jre if I recall correctly.

      Alien is not going to fly as Debian is in the midst of moving Lenny out the door and this would first start in Experimental, then move to Unstable/Sid, which need to make sure they are lintian clean. I'm going to file a reportbug on this with the owners of openjdk-6 and get this moving into an update to the openjdk-6 all around.

    5. Re:no DEB files? by Anonymous Coward · · Score: 0

      Extract bin. Put it somewhere. Use it. How hard is that?

    6. Re:no DEB files? by sog_abq · · Score: 1

      depends on your linux set-up. For me, I put the javas in /usr/lib/jvm/ there is a symlink in this folder "java-gcj" which points to the default java to use. Thats the way it came installed, so I just manipulated the symlinc to point to the java that I installed. Which until tomorrow was sun jdk 1.6_10

    7. Re:no DEB files? by Anonymous Coward · · Score: 0

      That's why I run Gentoo!

    8. Re:no DEB files? by ADRA · · Score: 2, Informative

      1. Sun likes to 'default all java applications to /usr/java/jdk-version or /usr/java/jre-version so feel free to copy the files to any directory you please.

      2. Add my_java_path/bin to your .bash_profile or .bashrc file so that you can run java applications from the command line

      3. Link my_java_path/lib/amd64/libnpjp2.so into your Firefox plugins directory (forget where it is)

      Restart firefox and you should be able to load any applets. You could also set JAVA_HOME to my_java_path, but that shouldn't be necessary.

      --
      Bye!
    9. Re:no DEB files? by Anonymous Coward · · Score: 0

      Unless someone slipped up, there should also be (IIRC) both ZIP and tar/gzip distros in addition to the RPM one.

      Sun's RPM is a convenience for enterprise shops that like to have all their major software systems under unified package control. It actually just unpacks everything to /usr/java/xxxxxxx, where "xxxxxxx" is the specific release (such as jdk1.5.0_04).

      They don't bother with trying to strew components over the usual places (/bin, /usr/lib, /var and so forth), since Java's fairly self-contained. All you really need is for the Java bin directory to be in the PATH. It makes it easier to keep multiple versions active on the same box at the same time.

      Oddly enough, while they've done this rather tidy arrangement for Linux, the Solaris deployment of Java DOES splatter all over the filesystem, and that has led to issues where the primary version of Java has one filesystem arrangement, and the alternate version is crammed under /usr.

    10. Re:no DEB files? by Anonymous Coward · · Score: 0

      Actually it doesn't fully install to the current directory but it creates a subdirectory which you can then use for java. Personally I'd advice you to put the directory somewhere safe and sane (for example in /opt or /usr/local) and from there on use symlinks. SO, say you have the jre in /opt/jre-1.6.0_11, you then make a symlink in (for example) /usr (/usr/java) and then tell programs to use this location. You might even want to set JAVA_HOME to point here. The benefit? Normally a program will "link" to the official jre directory, but that one has a version number in it which is likely to change. Some programs can handle this, most don't. With this setup you'll have everything in /usr/java, even when jre versions change.

    11. Re:no DEB files? by m50d · · Score: 1

      They're following the LSB standard. Maybe you should get a distro that does.

      --
      I am trolling
    12. Re:no DEB files? by foo+fighter · · Score: 1

      Because RPM is specified by the Linux Standard Base.

      --
      obviously no deficiencies vs. no obvious deficiencies
    13. Re:no DEB files? by xSander · · Score: 1

      3. Link my_java_path/lib/amd64/libnpjp2.so into your Firefox plugins directory (forget where it is)

      I followed the installation instructions but that didn't work. But symlinking libnpjp2.so did the trick. WTF?

      By the way, the plugins directory usually is ~/.mozilla/plugins.

  19. OpenJDK already 64-bit by thule · · Score: 4, Informative

    The article implied that IcedTea (OpenJDK) is already 64-bit. My system reports the plugin as a 64-bit shared object. This release from Sun just makes it part of the official Sun Java download.


    $ rpm -ql java-1.6.0-openjdk-plugin-1.6.0.0-7.b12.fc10.x86_64

    /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so

    $ file /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so

    /usr/lib/jvm/java-1.6.0-openjdk-1.6.0.0.x86_64/jre/lib/amd64/IcedTeaPlugin.so: ELF 64-bit LSB shared object, x86-64, version 1 (SYSV), dynamically linked, stripped

    1. Re:OpenJDK already 64-bit by LDoggg_ · · Score: 1

      And this has worked fine for the few applets I've run since being 64bit linux.

      Still, it's nice to see the official version.

      --

      "If they have both, tell them we use Linux. And if they have that, tell them the computers are down." -Dave Chapelle
    2. Re:OpenJDK already 64-bit by ChunderDownunder · · Score: 2, Informative

      IcedTea != OpenJDK != Sun's JRE.

      Rather, in approximate terms...
      OpenJDK = Sun's JRE download - binary blogs - Java Plugin - Java Web Start
      IcedTea = OpenJDK + GNU Classpath replacements + gcjwebplugin + netx

      So the IcedTeaPlugin.so is actually cobbled together from gcj. Red Hat decided they couldn't wait for Sun, so they sponsored GPLed IcedTea replacements for applets and jnlp.

      Today's announcement is that the 'official' Sun plugin now supports 64 bits. NB It's a totally different code-base from the IcedTea plugin and still isn't GPLed, with no definite time-frame.

  20. More Java please? by recharged95 · · Score: 1
    "For most people there is nothing to hold you back from running 64-bit Linux."

    .

    Dang pesky 32-bit MacBooksPros!

    .

    Though a big Java fan, Java plugin into a browser ==fail. They should scrap it and get us a 64-bit javafx plugin.

    1. Re:More Java please? by Nicopa · · Score: 3, Informative

      I don't think you quite understand what JavaFX is... JavaFX is an alternative way of creating Java applets, which will run on Java Plugin.

    2. Re:More Java please? by Anonymous Coward · · Score: 0

      No, JavaFX is an alternate way of creating GUIs, which run on Java. This has nothing to do with the browser plugin.

  21. And here's your impetus to upgrade! by Wee · · Score: 2, Funny

    Seriously! This is great news. I'm buying new hardware right now!

    Be still my heart.

    -B

    --

    Ash and Hickory, straight-grained and true, make excellent bludgeons, dandy for the cudgeling of vegetarians.

  22. What is this Java you keep talking about? by Anonymous Coward · · Score: 0

    Been using 64 bit Linux for a while and never once had I needed this Java that you speak of.

    Please provide more information as it sounds useful. Is this some sort of Ad-blocking software, a browser accelerator, or a bookmark saver?

  23. Re:Most of my 3rd-party apps do not work with Java by Anonymous Coward · · Score: 1

    It's not easy to find things that stop working with new Java releases. Those must be very crappy applications.

    Many cisco router web-management applications are crappy java programs, and will work with one AND ONLY ONE ancient version of java.

    I think it's cisco's way of making newbies learn to configure routers from the command line.

  24. Nice troll by frieko · · Score: 1

    They're not the three most desirable apps on Linux, they're the three apps that hadn't yet gone 64-bit.

  25. Google Gears? by at_slashdot · · Score: 2, Insightful

    Just an example of something that doesn't work in 64 bit... not that it holds me back.

    --
    "It is our choices, Harry, that show what we truly are, far more than our abilities." -- Prof. Dumbledore
    1. Re:Google Gears? by Lennie · · Score: 1

      Is anyone actually using it for something useful ?

      --
      New things are always on the horizon
  26. IBM Java by Anonymous Coward · · Score: 2, Interesting

    IBM's 64-bit Java for Linux has been out for a long time...

    http://www.ibm.com/developerworks/java/jdk/linux/download.html

  27. already have other options by bcrowell · · Score: 4, Interesting

    What already works for me on 64-bit Ubuntu Intrepid Ibex is this:

    apt-get install openjdk-6-jre openjdk-6-jdk icedtea-gcjwebplugin

    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:

    • 3.1 Licensee may not duplicate Licensed Software other than for a single copy of Licensed Software for archival purposes only.
    • 3.3 Except as otherwise provided by law, Licensee may not modify or create derivative works of the Licensed Software, or reverse engineer, disassemble or decompile binary portions of the Licensed Software, or otherwise attempt to derive the source code from such portions.
    • 3.5 Licensee shall have no right to use the Licensed Software for productive or commercial use.
    • 6.1 This Agreement will commence on the date on which Licensee receives Licensed Software (the "Effective Date") and will expire twelve (12) months from the Effective Date, unless terminated earlier as provided herein.
    • 6.2 Either party may terminate this Agreement upon ten (10) days' written notice to the other party.

    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.

    1. Re:already have other options by jmorris42 · · Score: 2, Informative

      > Some of the contents of the license:

      Yes Sun laywers are a bunch of dicks but remember that this is prerelease software. Normal releases od java don't have some of those nasty bits in the license and we can hope that the license will get improve as they continue the Open Source process with java.

      A few posts above I slag Java pretty hard, just trying to be fair. :)

      --
      Democrat delenda est
    2. Re:already have other options by peppepz · · Score: 1

      It's Java 7 that has been GPLed. Java 6 still has the usual Java license, it's no surprise that it is not open source by any definition.

      IcedTea is derived from Java 7 and as such you can install it freely through your package manager without accepting any nasty license.

  28. push this button by fatmatt_oz · · Score: 2, Insightful

    All I need now is the ubuntu update manager to give me the option of a 64bit upgrade without a complete reinstall.

  29. bug was submitted in uhhhh... 2003 ? by goffster · · Score: 1

    sheesh

  30. Check me, please ... by Anonymous Coward · · Score: 0

    Check me, please ...
    Doesn't Java have just about the slowest memory management ever created? Why would I ever run a program written in Java that needs over 4GB of data segment **inside** a browser JVM?

    Seriously folks, why?

    While I'm at it, why would I need a 64-bit browser? I certainly won't have that much data and integers and pointers that are 2x the normal size isn't good for any browser.

    It isn't like 64-bit is twice as good as 32-bit. That's just something all the 64-bit crazy people who don't understand crap think.

    BTW, I previously worked porting C/C++ code to Dec-Alpha machines in the mid-1990s, some of the first 64-bit UNIX code created.

    1. Re: Check me, please ... by ckaminski · · Score: 1

      I did some of the same. Moving from 32bit to 64bit on the Alpha's of the day cost Pro/Engineer 10% of it's performance. Took a lot of work and some great engineering on both Parametric's and DEC's part to get all that back. DEC busted a lot of hump to get ProE running on their platform. We had two dedicated engineers onsite, and a small army that came through on a routine basis.

  31. Skype? Google Earth? by Hell's+Kitchen · · Score: 1

    So, when we're going to have a 64 bit Skype? And a 64 bit Google Earth?

    1. Re:Skype? Google Earth? by VincenzoRomano · · Score: 2, Informative

      Skype is there! Just google it as the company seems to shy to show it.

      --
      Maybe Computers will never be as intelligent as Humans.
      For sure they won't ever become so stupid. [VR-1988]
  32. Re:Most of my 3rd-party apps do not work with Java by Anonymous Coward · · Score: 0

    And thus is the problem with Java. The "run anywhere" just doesn't hold any water.

    Java is just 90's shit like practically everything from the dotboom era. I remember so many failed Java projects from back then. So many...

  33. Wrong question. by Anonymous Coward · · Score: 0

    The question is not "What is holding back 64-bit computing?"; the question is "What compelling reason is there for upgrading?". Short of hosting databases or crunching numbers, there really is no immediate reason. And if you are browsing the web on a database or scientific server, shame on you (although I don't see why you wouldn't just use a 32-bit browser build).

    1. Re:Wrong question. by jbolden · · Score: 1

      Other than processing masses of data and doing computations what reason is there for computers? That's like 99% of what they do. The compelling reason for upgrading is:

      1) do floating point computations faster
      2) be able to handle more data

  34. Works! But needs a minor fix by StarHeart · · Score: 3, Informative

    It includes a plugin and javaws support. The two major things sun java 64bit has been lacking for years. It is still lacking the rim.cgi, but I have never had a need for it.

    The plugin needs some polish. It doesn't properly declare it's version. Which makes a kvm application I use fail, because it tries to check the version.

    --
    Havoc Penington, the bane of my Linux desktop.
    1. Re:Works! But needs a minor fix by Anonymous Coward · · Score: 0

      The plugin needs some polish. It doesn't properly declare it's version. Which makes a kvm application I use fail, because it tries to check the version.

      Somebody probably left an extra ' in the code.

    2. Re:Works! But needs a minor fix by ADRA · · Score: 1

      Great the hear that it support 64-bit web start as well. We can all rejoice in ye bounty o' 64.. Damn that English(Pirate) language in Facebook.

      --
      Bye!
  35. Re:Most of my 3rd-party apps do not work with Java by FictionPimp · · Score: 3, Informative

    Yes, we have one we payed a few hundred grand for. SungardSCT can suck my balls. Not only does it only work with java 5, but it has to be the exact right version. Do the wrong patch and its all over.

  36. Re:Most of my 3rd-party apps do not work with Java by mabinogi · · Score: 2

    Except when you're talking about Java 6.
    I don't know what the hell Sun did with Java 6.
    I'd never had compatibility problems with any previous version, but 6 was full of them.

    However, I believe 6u10 is finally a Java6 release that's actually safe to use.

    --
    Advanced users are users too!
  37. The source was out there for years! by mi · · Score: 4, Interesting

    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.
    1. Re:The source was out there for years! by Anonymous Coward · · Score: 0

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

      I don't think it's that simple. IIRC the Sun browser plugin uses Just-In-Time compilation of Java code, and porting the 32-bit one to 64-bit is more like writing another compiler than "recompile everything", and takes longer (well, too long).

      As mentioned in several posts above, the IcedTea Java plugin has been supporting 64-bit platforms for a long time. Those who didn't want to wait for Sun's release have always had the option of IcedTea. According to my experience it works pretty well.

    2. Re:The source was out there for years! by Anonymous Coward · · Score: 0

      "Freedom to tinker" my behind

      That is one freedom I chose not to exercise.

      PS. Very fitting that my captcha is "appendix".

    3. Re:The source was out there for years! by mi · · Score: 1

      I don't think it's that simple. IIRC the Sun browser plugin uses Just-In-Time compilation of Java code, and porting the 32-bit one to 64-bit is more like writing another compiler than "recompile everything", and takes longer (well, too long).

      No, it does not. The plugin is, pretty much, a bridge between the browser and the separate process running JVM. Its job is to coordinate the GUI and, maybe, pass around values of variables. There is no in-browser JVM.

      As mentioned in several posts above, the IcedTea Java plugin has been supporting 64-bit platforms for a long time.

      Terrific. Why is this news, then?

      --
      In Soviet Washington the swamp drains you.
    4. Re:The source was out there for years! by Anonymous Coward · · Score: 1, Informative

      except ofcourse that we DID "tinker" ourselves, look at icedtea...

      perhaps you yourself should direct your "behind" towards the interweb and learn some facts, before you spew the crap out..

    5. Re:The source was out there for years! by Anonymous Coward · · Score: 0

      it does not tell us anything about linux devs. It tells us something about ./

    6. Re:The source was out there for years! by Britz · · Score: 1

      Java was not GPL'd by SUN, because they feared it might be forked. And they didnt want Java to be forked. So the first thing Linux developers should have done after SUN GPL'd Java was to create a fork?

    7. Re:The source was out there for years! by onefriedrice · · Score: 1

      FreeBSD was providing Java (with the plugin) for both i386 and amd64 for years now...

      Well let's be honest. Linux is now the darling of the "open source" movement, irrelevant of technical or developer merit. It's similar to Opera VS Firefox. Opera usually has more new features while Firefox takes the credit later when it finally introduces those same features. Firefox is the darling of browers. No, it's not fair, but it's just the way it is.

      --
      This author takes full ownership and responsibility for the unpopular opinions outlined above.
    8. Re:The source was out there for years! by StarHeart · · Score: 1

      IcedTea's plugin is worthless. It doesn't deal with signed applets.

      The only two things I use java for with a web browser are two different types of network kvm. One uses a java applet, and the other uses a java webstart application. I had to use 32bit sun java to get support for both at once.

      Now the only thing left 32bit is mplayer for win32 codecs. I will have to do much testing and see if I can now live without them and use mplayer.x86_64. If so I can pretty much go pure 64bit. I do run into x86_64 applications every so often that don't behave properly. The last example I can think of is rtorrent.

      --
      Havoc Penington, the bane of my Linux desktop.
    9. Re:The source was out there for years! by Ilgaz · · Score: 1

      You can easily understand why nobody bothered if you look at junk like feedback at this story from people disconnected from real life, Mono developers or just trolls.

      I still wonder why Sun, Adobe and Real Networks (Helix) spare their precious development time for a community like that.

      For example, Sun should prepare Cocoa Java 6-7 for OS X and keep it on a secure server just in case if they get MS treatment from Apple too.

      Satisfying couple of "pure 64bit 133t" nerds shouldn't be at first of list. Java Applet market happily runs 32bit browsers and they need better performing, more compatible Java applet support.

    10. Re:The source was out there for years! by Anonymous Coward · · Score: 0

      Sure, that worked. But since it wasn't "official", you can't get it into enterprise use. Welcome to politics.

    11. Re:The source was out there for years! by mi · · Score: 1

      So the first thing Linux developers should have done after SUN GPL'd Java was to create a fork?

      1. Fixing a bug and providing a 64-bit version of a plugin would not constitute a fork. Nobody, for example, would consider FreeBSD's doing so "a fork".
      2. Linux developers have created a fork — just look at the (angry) responses here about IcedTea.
      --
      In Soviet Washington the swamp drains you.
    12. Re:The source was out there for years! by mi · · Score: 1

      Satisfying couple of "pure 64bit 133t" nerds shouldn't be at first of list.

      It should not. Just give us the source-code. We'll make it build... Do you hear me, Adobe? That said, the "pure 64bit nerds" are far more than "couple". For example, FreeBSD's amd64 flavor does not even come with 32-bit binaries from FreeBSD/i386 (although it would run them, if you bothered to add them manually).

      There are very good reasons for "pure 64bit" — the main being: sizeof(size_t) == sizeof(off_t).

      --
      In Soviet Washington the swamp drains you.
    13. Re:The source was out there for years! by Anonymous Coward · · Score: 0

      A fairly small patch was required (long vs. size_t somewhere deep inside)...

      Definitely not. Linux compilers use the LP64 data model, so size_t and long have the same width (64-bits). I'm sure it was much more involved than hey - we need to fix the types we cast to.

  38. Doom 3 by Anonymous Coward · · Score: 0

    Doom 3 is still lacking a 64-bit binary.

    1. Re:Doom 3 by BrentH · · Score: 1

      Doom3 will be opensourced anytime now, so then you can build your own 64bit binary.

  39. webstart? by asv108 · · Score: 3, Insightful

    Does anyone know if Sun now supports webstart on 64bit linux?

    1. Re:webstart? by drspliff · · Score: 1

      For as long as a 64bit linux JVM has existed it has supported webstart through the `javaws` program which takes the URL of your jnlp file.

    2. Re:webstart? by peppepz · · Score: 1

      There's no javaws program in the current version of the 64-bit JRE.

    3. Re:webstart? by asv108 · · Score: 1

      No, javaws was not in previous versions of the 64bit JVM.

  40. Meanwhile... by Anonymous Coward · · Score: 0

    RealPlayer: Buffering...
     
    ...
     
    ...

    And this is from a joke earlier this month.

  41. that *is* sun java by sentientbrendan · · Score: 3, Informative

    >apt-get install openjdk-6-jre openjdk-6-jdk icedtea-gcjwebplugin
    >Sun has always made it a royal pain to use their java
    You are criticizing sun java, but that *is* sun's Java implementation. The only part that isn't is the icedtea-gcjwebplugin.

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

    Huh?
    For years I've been able to download and install sun java through ubuntu. Before they rebranded it as "openjava" you could still download it. The ubuntu package manager would *pop up* that clickthrough license that you are talking about.

    >, it's not open source under the Open Source Definition

    Not being open source doesn't stop it from being used on Linux... Most production Linux systems have proprietary software on them, especially proprietary drivers and firmware. You probably have some on your box and don't even know it.

    For that matter, it's impossible to have a completely open source system because the hardware itself is not open source. Stopping at the software layer is totally arbitrary. All Linux users have *some* level of comfort with proprietary technology.

    For that matter, Sun controls Java's language definition, so the language itself isn't really open. If you want an open platform, use C++, Python, Ruby, Javascript or any other language that is community controlled or standards based. Java is really an awful language, so I don't understand what your holdup is. You need to use Java, but not Sun Java? Use Java or don't, but don't Use Java and try to do it in a stupid way that will never work properly

    People widely use Sun Java in production environments because the alternatives are buggy as hell. The "openjdk" you reference is actually just sun java repackaged, not an independent effort, but I used the older open source versions of java back in the day, and they were all awful and buggy. GNU Classpath in particular just does not implement much of the java libraries.

  42. it's always the drivers by Anonymous Coward · · Score: 0

    "For most people there is nothing to hold you back from running 64-bit Linux."

    yeah apart from the lack of a native wireless driver that works properly on my laptop you insensitive clod!

  43. Let me know when Adobe Acrobat 64bit arrives by tyrione · · Score: 1

    So I can finally junk all the 32 bit stuff.

  44. Re:Java is a disaster in practice by doktorjayd · · Score: 1

    And to cap it all, the JVM is utterly non-portable, so much so that barely 1/4 of the highly varied boxes in my computer room complete the installation cleanly

    perhaps you need to take the 'how to double-click install.exe' course again?

    i call you an epic fail! :P

    [ i know i shouldnt feed the trolls, but i'm bored ]

  45. One thing I never got... by Junta · · Score: 1

    Why in the hell would you want to load PDF into your web browser session?

    Even when using Acrobat, I detest opening it in the browser. It puts limitations on the reader as well as blocking functionality of the browser enough for it to feel wrong (i.e. one window with two likely search dialogs, one of which has nothing to do with the actual PDF being read). If I forget and do Ctrl+F, I spend a couple of seconds confused that it found nothing before remembering that it was a pdf in a browser not normal content.

    Nowadays, I prefer Evince for day-to-day pdf reading (some special cases Acrobat still has features for, but when those are not needed, I prefer the clean Evince interface).

    --
    XML is like violence. If it doesn't solve the problem, use more.
    1. Re:One thing I never got... by tyrione · · Score: 1

      Why in the hell would you want to load PDF into your web browser session?

      Even when using Acrobat, I detest opening it in the browser. It puts limitations on the reader as well as blocking functionality of the browser enough for it to feel wrong (i.e. one window with two likely search dialogs, one of which has nothing to do with the actual PDF being read). If I forget and do Ctrl+F, I spend a couple of seconds confused that it found nothing before remembering that it was a pdf in a browser not normal content.

      Nowadays, I prefer Evince for day-to-day pdf reading (some special cases Acrobat still has features for, but when those are not needed, I prefer the clean Evince interface).

      Sorry, but Evince [I use along with Okular] doesn't support half of what Acrobat supports and I've configured all pdf document links in browsers to launch the lightest external pdf viewer, unless there are issues with PDForms and whatnot that only Acrobat manages correctly.

      Why the hell I would want to do with a 32bit layer for Acrobat [already large] and not a clean 64 bit version seems rather daft in the head, if you ask me.

  46. That's a good thing - trust me by Weaselmancer · · Score: 4, Informative

    Write some stuff in C#/.NET sometime. Especially the embedded version. You'll see why. Every time MS puts out some patch...stuff breaks. Why? Because they do crap like this.

    I have an embedded platform that has the .NET 2.0 binaries on it, as well as a 3.5 version. And I had to hack that one in from binaries from Visual Studio manually. The 2.0 binaries don't run on 3.5. The 3.5 binaries don't run on 2.0. It *sucks*.

    So - if you suddenly doubled the size of an int it would break backwards compatibility and do this sort of horrible crap to Java. People who use java 1.2-1.6 would need their 32 bit ints. If you wanted the same box to run your 64 bit int Java, you'd need two sets of binaries. And a way to switch between them.

    Trust me, you don't actually want this.

    --
    Weaselmancer
    rediculous.
    1. Re:That's a good thing - trust me by shutdown+-p+now · · Score: 1

      I'm not sure what all this has to do with size of int data type, because, just like in Java, it's fixed at 32 bit in .NET (and so are all other primitive types).

      Also, I've no idea about .NET CE - and it may work as you describe - but on the desktop, there isn't even such a thing as a "3.0" or a "3.5" binary. The .NET runtime is still at version 2.0, and so are the binaries - all the new stuff is in the compilers and the libraries. So you can happily run a 2.0 app in 3.5.

    2. Re:That's a good thing - trust me by thtrgremlin · · Score: 4, Insightful

      Either int will be a fixed size and longer ints will have another name, or you can explicitly state the size of int as a declaration. This has always been done and 'good coding' should include explicit declaration. It is when people cut corners and use "what works" that can quickly create regression bugs when backwards compatibility is integrated, but you didn't follow good coding guidelines. "That always worked fine suddenly stopped working" issue. This is also why a lot of those "bugs" don't get fixed.

      People need to follow proper coding guidelines, not try to stop things from progressing. Programming has always been progressive in this way, and just relearning the new way has never been much of a way to keep up.

      --
      Want Big Business out of government? Take away the incentive and start by getting government out of big business!
    3. Re:That's a good thing - trust me by Anonymous Coward · · Score: 0

      Either int will be a fixed size and longer ints will have another name

      You mean like ... "long"?

    4. Re:That's a good thing - trust me by benjymouse · · Score: 1
      Somehow I doubt that you have a lot of experience with C#. If you had you would know that:
      1. .NET 3.0 and .NET 3.5 are not really new versions, they are additions to the 2.0 platform. The 3.0 added stuff like WPF, WCF, WF, CardSpace. The 3.5 added LINQ. *ALL* of it still runs on the 2.0 runtime. Both additions leverage the extensible configuration of 2.0 to configure new modules. In other words your claim that it "Every time MS puts out some patch...stuff breaks" is totally and utterly bunk. Admittedly MS used a stupid versioning for this.
      2. Even .NET 1.0 and 1.1 assemblies continue to run on the 2.0, 3.0 and 3.5 versions (which are all just the 2.0 runtime, per above).
      3. There is no difference between .NET datatypes on 32 and 64 bit platforms. If you are calling native APIs you may want to check whether you use P/Invoke correctly.
      4. There is no such thing as "3.5 binaries". You should know that. There are some 3.5 specific assemblies (LINQ) which are 2.0 binaries.And yes they *do* run on 2.0.
      5. You need to find another explanation for why your stuff breaks. Stop blaming patches. It just shows your incompetence.
      --
      Reading slashdot one-liner: (irm http://rss.slashdot.org/Slashdot/slashdot).rdf.item | fl title,desc*
    5. Re:That's a good thing - trust me by owlstead · · Score: 1

      No, I don't think that that is the right way. You should either use no bounds at all (many scripting languages) or use a language where the bounds are clear. Java exactly does this by specifying the number of bits in an int/long. Otherwise you get code that cannot be maintained. Saying that developers should do something doesn't work. This can be because of deadlines, laziness or stupidity; it doesn't matter. You'll end up with something that doesn't compile or run on another platform. Let the JVM or other virtual machines care about the optimization and stick with byte/short/int/long depending on your actual *needs*.

    6. Re:That's a good thing - trust me by jonaskoelker · · Score: 1

      So the java solution is something like this:

      typedef int int32;
      typedef long int64;
      #ifdef bit32
      typedef int word;
      #else
      typedef long word;
      #endif

      Except that due to design reasons, you don't have typedef or ifdef.

      Did I get that right?

    7. Re:That's a good thing - trust me by shutdown+-p+now · · Score: 1

      Yes, except there is no "word" typedef (or analogue) in Java. .NET is exactly the same, but has "word" (an integer that exactly fits a native pointer). It's called "native int" in the CLR, and System.IntPtr in C# and VB.

      Both also standardize float and double as IEEE-format 32-bit and 64-bit, as far as I remember (C# certainly does that) - also unlike C/C++.

    8. Re:That's a good thing - trust me by shutdown+-p+now · · Score: 2, Informative

      Either int will be a fixed size and longer ints will have another name, or you can explicitly state the size of int as a declaration.

      The latter is precisely what you do in Java when you say "int" - you explicitly state that you want a 32-bit, two's complement signed binary integer. This is by design of the language, and expecting "int" to remain that way is certainly not an invalid assumption or a bug.

    9. Re:That's a good thing - trust me by tomhudson · · Score: 1

      Write some stuff in C#/.NET sometime. Especially the embedded version. You'll see why. Every time MS puts out some patch...stuff breaks. Why? Because they do crap like this.

      I was *going* to say that I stopped coding for Windows a LONG time ago, but it's more like an INT :-)

    10. Re:That's a good thing - trust me by Oberstille · · Score: 2, Interesting

      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.

    11. Re:That's a good thing - trust me by ckaminski · · Score: 2, Insightful

      I think you mean that long is always at LEAST 4 bytes.

    12. Re:That's a good thing - trust me by Anonymous Coward · · Score: 0

      Well, that is what we have MAX_INT defines for.

      On a 32bit system, MAX_INT is 2^32, on a 64bit system its 2^64... it works on bali, why shouldn't it work on java?

    13. Re:That's a good thing - trust me by Xphile101361 · · Score: 1

      I thought they already had a type for "longer ints", aren't they called "long"? Maybe its time for them to actually be used.

    14. Re:That's a good thing - trust me by Anonymous Coward · · Score: 0

      You are, of course, correct--this is true for pretty much everything I said. An int is always at least 2 bytes; along is always at least 4 bytes; and so on. If you want to be guaranteed a particular size, you can use the intNN_t types.

    15. Re:That's a good thing - trust me by Weaselmancer · · Score: 1

      1) Not Bunk. I wrote a program under the 2.0 binaries. It runs with 2.0 binaries installed. Remove the 2.0 binaries from Windows CE and add the 3.5 component and it does not run.

      Conversely, app dev team is writing under 3.5. If they use the 2.0 binaries, it does not run. If they use the 3.5 binaries that come with PB, it does not run. If they install the 3.5 .NET that comes with VS, it runs. You can use some exe (I forget the name at the moment) to check your version. It will look like 3.5.xxxx. The one in PB is 4xxx and the one in VS is 5xxx I think. So a minor revision breaks their stuff, and a major revision breaks mine.

      But I don't care - all I know is that it breaks. Not Bunk. I have seen this with my own eyes, and so has every single developer in the app team. That's about a half a dozen witnesses.

      2) Not my experience, but I'm happy it works for you.

      3) I agree. But the OP was talking about switching datatypes, and incompatibility would certainly be a result.

      4) A shortcut of speaking. Replace that with "compiled and run in an environment with 3.5 .NET being present".

      5) With all due respect, get bent.

      This stuff should just work. Backwards compatibility works just fine with Java, and it doesn't with C#/.NET. That's my experience.

      Get something running, add a patch - then it stops running. That would certainly imply it's the patch, Sherlock. And not every engineering effort has the time allocated to it to figure out exactly what the hell Bill and Company just loaded on your machine, and why it breaks stuff.

      No source code, minimal documentation, and a limited schedule = bogus crap like having to have two sets of binaries on your platform. Not my fault.

      Someone is certainly incompetent, I'll agree with that. But it's not me.

      --
      Weaselmancer
      rediculous.
    16. Re:That's a good thing - trust me by abjbhat · · Score: 1

      Set the runtime tag in app.config. Problem solved.

    17. Re:That's a good thing - trust me by Guspaz · · Score: 1

      Almost, but not quite. The .NET runtime is at 2.0 SP1.

      3.0 uses the 2.0 runtime, and 3.5 uses the 2.0 SP1 runtime.

      The service pack can make a difference for compatibility, so it's worth differentiating them. They probably should have just called it 2.1 like normal people would...

    18. Re:That's a good thing - trust me by shutdown+-p+now · · Score: 0, Redundant

      Actually, it's 2.0 SP2 now - you forgot about 3.5 SP1, which included that...

      And yes, there are differences in the runtime, though vast majority of .NET applications didn't see them. There weren't many in 2.0 -> 2.0 SP1 update, but there were several breaking ones in 2.0 SP2.

      Even so, those are all corner cases. The compatibility is not perfect, but it's close enough.

    19. Re:That's a good thing - trust me by Bob+Uhl · · Score: 1

      Either int will be a fixed size and longer ints will have another name, or you can explicitly state the size of int as a declaration. This has always been done and 'good coding' should include explicit declaration.

      A third option is a language which permits integers of any size. This works out pretty well in practise, although of course there are efficiency issues with bignums. Still, as long as they transparently are represented with platform words where possible, who cares?

    20. Re:That's a good thing - trust me by Anonymous Coward · · Score: 0

      Having native support for 64-bit hardware but being prevented from using a 64-bit buffer size or array index is certainly a bug. I'd say Sun wasn't thinking ahead, but Ada had comprehensively solved the same problem in 1983, so Sun just wasn't thinking.

    21. Re:That's a good thing - trust me by shutdown+-p+now · · Score: 1

      It's not a bug, it's a lack of a feature (which is, to be honest, something that one is very unlikely to need in a Java application - it's not a language in which you'd want to write code that manipulates 4Gb+ arrays of data). Even then, it's not a problem with "int", it's a problem with the array API. In .NET, for example, this is solved by providing a way to get & specify the array length as "long".

    22. Re:That's a good thing - trust me by AmaDaden · · Score: 1

      Bingo. It sounds dumb to any one who codes close to the metal but it's a well known and deliberate part of Java's design. Most likely when (and if) they change this it'll be done from one version to the next. That is typically when they like to break things. If you think this sounds like a mess look back at what they had to do for floats. http://en.wikipedia.org/wiki/Strictfp The internal headache they when through with floats makes this look like a cake walk. Remember Java is designed to be as cross platform as possible, Not as fast as possible.

    23. Re:That's a good thing - trust me by AmaDaden · · Score: 1

      That breaks programs that depend on the edge cases. It sounds stupid but that is why they are doing it. Java and C# are both designed to have a program work exactly the same way on any platform that it can run on. If you get an overflow bug on one system you should get the same exact bug on any other system you run it on. No mater how big it's native int is. Just look at how far they took this at first for floats. http://en.wikipedia.org/wiki/Strictfp

  47. Java is ruining the web by boudie2 · · Score: 0

    Wouldn't it be a better world without Java?

  48. Re:Most of my 3rd-party apps do not work with Java by ADRA · · Score: 1

    If so, I hope they use web start to keep their deployments in sync with the client's native system.

    The great thing about web start is that if you need 1.3, 1.4, 1.5, or 1.6 JVM's installed, you can run each independently using the application's JNLP settings without having to fiddle with getting the right JVM in the application's path.

    That said, Having done extensive work on Java Web Start for an enterprise app, Sun doesn't make the technology very easy for people to create web start apps without a lot of knowledge/work.

    --
    Bye!
  49. so basically the article says by GregNorc · · Score: 1

    So basically the article says2008 is the year of 64 bits Linux?

  50. Great stuff by Skiron · · Score: 1

    AFAIKT, this works great. The library plugin name isn't that obvious though - for firefox 64 bit, you need to symlink (in .mozilla/plugins directory):

    libnpjp2.so -> /usr/lib64/jre1.6.0_12/lib/amd64/libnpjp2.so

    My test site[s] work great.

    http://spaceflight1.nasa.gov/realdata/sightings/SSapplications/Post/JavaSSOP/JavaSSOP.html

  51. one liner by asamad · · Score: 1

    About bloody time

  52. Re:Most of my 3rd-party apps do not work with Java by amorsen · · Score: 1

    It's not easy to find things that stop working with new Java releases. Those must be very crappy applications.

    Of the things I need Java for, the only thing that survives Java 6 is Puzzle Pirates.

    --
    Finally! A year of moderation! Ready for 2019?
  53. Re:Java is a disaster in practice by Anonymous Coward · · Score: 0

    > perhaps you need to take the 'how to double-click install.exe' course again?

    Sure, try it. Install the 64 bit Windows JVM and seen if you can find any java applications that actually work with it.
    Azureus for example claims that no JVM is installed.
    Java has its uses (though in my very personal opinion the Desktop is not among them), but portability is not really among the things it provides.

  54. Wake me up... by lxs · · Score: 1

    ...When CS4 runs natively on 64bit Linux. Some of us need that shit for our education/jobs you know?

    1. Re:Wake me up... by peppepz · · Score: 2, Informative

      By that time, CS5 will be out, you'll need it, and it won't run natively :) .

  55. I enjoy running with Flash,Wine and Java plugins by Anonymous Coward · · Score: 0

    My 64-bit work environment never needs these plugins, I don't miss them. Web browsing is much better without them.

  56. The reasons why ints are 32 bits by MosesJones · · Score: 2, Informative

    The biggest reason of all is interop. A piece of Java code that runs in 32 bit mode successfully will wrap around and work exactly the same on the 64 bit platform. Perl will work differently. if a piece of Java calls a piece of identical Java and one is on 32 bit and the other 64 bit then they will work properly, Perl will behave erratically.

    Basically its the difference between a language that has been designed for longevity (Java) and one that just defaults to what ever is around (Perl).

    Defaulting to what the processor has is the opposite of future proofing as it ensures that your current code WON'T WORK PROPERLY IN THE FUTURE. Sorry to shout but it really is quite important. The Java code will work the same on 32 bit and 64 bit versions while the Perl will work differently, thus it will not be future proof.

    To really future proof your code what you need to do is plan for those things and assign your file size to be a long and guess what Java returns a long.

    Perl and Design go together in the same way as Illinois and Probity.
     

    --
    An Eye for an Eye will make the whole world blind - Gandhi
  57. Re:Most of my 3rd-party apps do not work with Java by FictionPimp · · Score: 1

    I wish they did. Then our support reps wouldn't have to go out and uninstall java updates when some tech accidentally updates java while he is out fixing another problem.

  58. 64bit??? by Anonymous Coward · · Score: 0

    OWWW now I have to switch to 128 bit just te keep up my elitist appearances

  59. nspluginwrapper got much better lately by Nicolas+MONNET · · Score: 1

    Gwenole Beauchesne has committed a lot of fixes in the past few weeks; the latest version is quite stable. In fact, it never crashes the browser for me, at worst the plugin instances die but a simple page reload fixes it.
    Separating the plugins in another process allows Fedora 9+ to isolate them in their own, limited SELinux context. Even if there's a performance price for it, it might well be worth it.

    1. Re:nspluginwrapper got much better lately by ckaminski · · Score: 1

      I think that should be the case for plugins period... Keep them out of process.

  60. Re:Java is a disaster in practice by ckaminski · · Score: 1

    Here's a clue for you buddy - you CAN'T just install the 64bit JVM. You need both the 32bit JVM and the 64bit JVM. :-) I run into this all the time with app servers where the 64bit JVM actually makes sense. Azureus surely doesn't need it.

    Portability? I can't count the number of times I've copied a jarfile from one platform to another and had it just work. Java suffers from dependency hell just as much as a the next platform, which is perhaps it's biggest deficiency...

  61. OK great, but why? by xdroop · · Score: 1

    For most people there is nothing to hold you back from running 64-bit Linux."

    Except the lack of a compelling reason to run 64-bit Linux on the desktop.

    Seriously, what can I do on a 64-bit desktop Linux computer that I can't do on a 32-bit Linux computer?

    --
    you should read everything on the internet as if it had "but I'm probably talking out of my ass" appended to it.
    1. Re:OK great, but why? by Abcd1234 · · Score: 1

      Seriously, what can I do on a 64-bit desktop Linux computer that I can't do on a 32-bit Linux computer?

      Nothing. Addressing >4GB of RAM would be a bit more efficient, and some CPU-intensive tasks would be faster (eg, audio/video encoding, etc, which benefit from the extra registers available, and the guarantee of things like SSE2 being present), but that's about it. And the larger pointer and opcode size actually means that performance might *degrade* due to the greater chance of data being evicted from your L1 cache.

      That said, I run 64-bit on my Laptop, partly because, bafflingly enough, suspend works better than it does on the 32-bit equivalent, and partly because... well... meh, why not? :)

  62. 64bit by motang · · Score: 1

    64bit computing is coming here slowly. I jumped on 64bit computing as soon as Adobe released Flash 10 and I am loving it.

    1. Re:64bit by CompMD · · Score: 0, Troll

      What are you talking about? 64-bit computing is coming here slowly? I jumped on 64-bit computing 10 years ago with a DEC Alphastation, and a Sun Ultra 10 after that.

      The kids these days have no respect for what brought them to where they are today.

  63. Re:Most of my 3rd-party apps do not work with Java by LWATCDR · · Score: 1

    What? I have written several Java programs. I have only had that happen once and it was because I did a really sloppy hack.

    --
    See my blog http://ilovecookes.blogspot.com/ for light hearted technical information.
  64. What we need now is a good Newsreader. by BenEnglishAtHome · · Score: 1

    That's a program that turns Usenet into human-readable form, not some sort of Web3.0/push/feed/buzzword thingie that beeps your cell phone whenever your girlfriend goes to the can. (Just thought I'd clear that up for you younguns.)

    Pan is 32-bit and OK but I find all sorts of nagging problems with it. The biggest is that if you try to get headers from a newsgroup with lots of messages (say, over a million) it just hangs.

    Running Windows Usenet clients in Wine is one solution, but I'd really like a FOSS solution.

    Anybody got any suggestions? I'm an old fart and won't give up my Usenet until they pry it from my cold, dead fingers.

    1. Re:What we need now is a good Newsreader. by ArsenneLupin · · Score: 0, Flamebait

      Running Windows Usenet clients in Wine is one solution, but I'd really like a FOSS solution.

      That must be the lamest troll I've seen in ages...

      Anybody got any suggestions? I'm an old fart and won't give up my Usenet until they pry it from my cold, dead fingers.

      Do you also go to the nearest Democratic convention if you want to get a gun? Do you got to a disco if you want to listen to classical music?

  65. Ahh.. by Junta · · Score: 1

    So not 32-bit for the plugin, but 32-bit for the app. At this point, I'm not overly bothered by the presence of extra libraries to run independent applications. I'm just bothered by circumstances like Firefox, where the browser requires some 64-bit to work, but the vendor provides 32-bit. And before everyone says 'nspluginwrapper', that helped, but flash was a lot more flaky than either the 32-bit install or the 64-bit native plugin.

    Sure, I agree that a 'pure' 64-bit environment sounds cleaner, but practically speaking it is of inconsequential functional impact, given how the distributions successfully provide both concurrently.

    --
    XML is like violence. If it doesn't solve the problem, use more.
  66. 64 bit Luxtrust cryptoki module by ArsenneLupin · · Score: 1

    Now, after 64-bit flash, and 64-bit java, we now only miss a 64 bit Luxtrust libgemsafe module... So, Luxtrust, when are you going to move?

  67. Go vote for official 64-bit FireFox releases! by Cow_woC · · Score: 1

    https://bugzilla.mozilla.org/show_bug.cgi?id=440964

  68. IcedTea does support signed applets by this+great+guy · · Score: 1

    I just tested this one.

  69. Re:Most of my 3rd-party apps do not work with Java by Anonymous Coward · · Score: 0

    From what I have understood, Jave 6 is *completely* compatible with Java 5. It ships with more integrated libraries and the performance has been improved, but all Java 5 code should run flawlessly on Java 6.

    The only reason why these Java 5 apps at your work refuse to run with Java 6 is because of a buggy version check within those applications. Instead of checking (version>=5) they are checking (version==5), which is simply a bug that should be fixed in said software. Complain to the companies that developed these 3rd party applications and file this as a bug report.

  70. Yea but Java sucks by Anonymous Coward · · Score: 0

    It sucks big time!

  71. ... and it only took them six years! by Anonymous Coward · · Score: 0

    The enhancement request asking Sun for this was submitted in January 2003.
            http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=4802695
    No more complaining about Microsloth being slow to deliver...

  72. BigInteger by Gastrobot · · Score: 1

    I suspect that when that time comes around someone will implement a JVM with a larger primitive than Java's long (think 64 bit int), but in the meantime use this:

    http://java.sun.com/javase/6/docs/api/java/math/BigInteger.html