Readers,
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
On 10 January 2012 13:04, e-letter inpost@gmail.com wrote:
Readers,
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
Why is this a bug? The bug comments mention that the latest CentOS 6 has 1.10.4 which is supported by the Icedtea people. I quote from the comments:
---8<------------------------------------ The newest version of IcedTea in CentOS6 (6.2) is 1.10.4:
http://mirrors.kernel.org/centos/6.2/os/i386/Packages/java-1.6.0-openjdk-1.6... ---8<------------------------------------
Thus ypgrade your CentOS to the latest point release as a minimum as suggested in the issue you raised. Again from the issue raised, the following link is pretty enlightening:
http://wiki.centos.org/FAQ/General#head-6e2c3746ec45ac3142917466760321e868f4...
On 01/10/2012 07:17 AM, Hakan Koseoglu wrote:
On 10 January 2012 13:04, e-letter inpost@gmail.com wrote:
Readers,
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
Why is this a bug? The bug comments mention that the latest CentOS 6 has 1.10.4 which is supported by the Icedtea people. I quote from the comments:
---8<------------------------------------ The newest version of IcedTea in CentOS6 (6.2) is 1.10.4:
http://mirrors.kernel.org/centos/6.2/os/i386/Packages/java-1.6.0-openjdk-1.6... ---8<------------------------------------
Thus ypgrade your CentOS to the latest point release as a minimum as suggested in the issue you raised. Again from the issue raised, the following link is pretty enlightening:
http://wiki.centos.org/FAQ/General#head-6e2c3746ec45ac3142917466760321e868f4...
This is the critical point ... you are using an unsupported version of icedtea 1.7.4 (or java-1.6.0-openjdk if you prefer that name).
However, if you do an update then you will have a supported version of icedtea (version 1.10.4). The only bug here is that you are not running updates :D
e-letter wrote:
Readers,
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
One *could* argue that Java is a bug, being a) so error-prone, b) so vulnerable to attack, and c) so huge and slow, and shouldn't be allowed....
mark "java; why did it have to be java?"
On Tue, Jan 10, 2012 at 8:47 AM, m.roth@5-cent.us wrote:
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
One *could* argue that Java is a bug, being a) so error-prone, b) so vulnerable to attack, and c) so huge and slow, and shouldn't be allowed....
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
On Tue, January 10, 2012 17:15, Les Mikesell wrote:
On Tue, Jan 10, 2012 at 8:47 AM, m.roth@5-cent.us wrote:
One *could* argue that Java is a bug, being a) so error-prone, b) so vulnerable to attack, and c) so huge and slow, and shouldn't be allowed....
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
So if I were to develop a CPU type and/or OS that didn't support Java then you would lock yourself out of the very language you appear to advocate?
On Tue, Jan 10, 2012 at 10:17 AM, Giles Coochey giles@coochey.net wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
So if I were to develop a CPU type and/or OS that didn't support Java then you would lock yourself out of the very language you appear to advocate?
Being locked out of some oddball thing is not at all the same situation as being locked into what only a single vendor provides. But try something like 'jenkins' (http://jenkins-ci.org/) with an assortment of cross-platform nodes to get the idea of how handy a language with remoting across many platforms can be. It's painless to install try, even if you only use it on a single box.
Les Mikesell wrote:
On Tue, Jan 10, 2012 at 10:17 AM, Giles Coochey giles@coochey.net wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
So if I were to develop a CPU type and/or OS that didn't support Java then you would lock yourself out of the very language you appear to advocate?
Being locked out of some oddball thing is not at all the same situation as being locked into what only a single vendor provides. But try something like 'jenkins' (http://jenkins-ci.org/) with an assortment of cross-platform nodes to get the idea of how handy a language with remoting across many platforms can be. It's painless to install try, even if you only use it on a single box.
I have a one-word answer: perl. A longer answer - are you suggesting system admin chores being done using some kind of java monstrosity? I mean, I don't remember what Spacewalk's written in, but it was a very large pain, and if it's not in java, then the java version would be a *lot* worse.....
mark
On Tue, Jan 10, 2012 at 10:47 AM, m.roth@5-cent.us wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
So if I were to develop a CPU type and/or OS that didn't support Java then you would lock yourself out of the very language you appear to advocate?
Being locked out of some oddball thing is not at all the same situation as being locked into what only a single vendor provides. But try something like 'jenkins' (http://jenkins-ci.org/) with an assortment of cross-platform nodes to get the idea of how handy a language with remoting across many platforms can be. It's painless to install try, even if you only use it on a single box.
I have a one-word answer: perl.
But which version, on systems where it isn't included?
A longer answer - are you suggesting system admin chores being done using some kind of java monstrosity? I mean, I don't remember what Spacewalk's written in,
Spacewalk's problem is that it is written as components in a bunch of different languages and tied to a specific DB interface. Java could have solved all of those problems, but Red Hat did about as much as any company could to kill java - by shipping something that didn't quite work and wasn't quite java back then.
but it was a very large pain, and if it's not in java, then the java version would be a *lot* worse.....
Yes, I would love to see a complete admin system in java, although you don't want to spin up a JVM for every command line you type - you'd want a long-running service with agents already running/connected everywhere. OpenNMS is excellent for the monitoring part of system administration. Jenkins is great for doing builds and maybe deployment (java or not). Jenkins can be expanded to do a lot more as a generic cross-platform distributed queuing/scheduling/scripting system but since it was designed as a continuous integration build system (compile/test across a matrix of platforms whenever a source change is committed), security isn't a real strong point. Both are painless rpm installs on linux if you let them run on their own ports with their embedded web servers. Try them before repeating misinformation about how bad things are. And then there are things like elasticsearch that might be possible in some other language but it just doesn't seem to exist (not particularly admin related, but if other languages are so great where is the equivalent?).
If you don't like the verbosity of java (and who does?), you can use groovy as a more modern dynamic typed alternative for scripting. It runs in the same jvm and can import/access any normal jars that are already compiled in java.
Les Mikesell wrote:
On Tue, Jan 10, 2012 at 8:47 AM, m.roth@5-cent.us wrote:
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
One *could* argue that Java is a bug, being a) so error-prone, b) so vulnerable to attack, and c) so huge and slow, and shouldn't be allowed....
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
No, I wouldn't. You argue wrongly. For one, by your first sentence, you deny all of my arguments, with no reasons for that denial. As someone who's worked more as a programmer than an admin, and both for a long time, in a lot of languages, I see almost all java programs as huge. I also know that *if* you write your code correctly, the code will compile and run on pretty much anything, unless you're writing windowing-system specific stuff.
Then there's java, that in everything I read from the mid-nineties through the mid-oughts, was presented as being free from memory errors, etc, etc, but as one huge counter-example, just about every time I see a tomcat app crash, the stack traces are 150-200 calls deep, and there are, indeed, memory errors.
Further, it's nothing more than a re-imagining (as they say) of Pascal p-code (quick: what other language besides java used the command writeln?). The difference between recompile and run on a vm that's compiled for that machine is? Oh, right, it is, in effect, another layer that sits on top of the o/s, like a pseudo-os, or windowing system.
I can go on... but I really need to get around to writing my article to be entitled, "The Failure of OOP in General, and Java in Particular".
mark
On Tue, Jan 10, 2012 at 10:32 AM, m.roth@5-cent.us wrote:
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
One *could* argue that Java is a bug, being a) so error-prone, b) so vulnerable to attack, and c) so huge and slow, and shouldn't be allowed....
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
No, I wouldn't. You argue wrongly. For one, by your first sentence, you deny all of my arguments, with no reasons for that denial.
The reasons are obvious. Java is common on phones, so there goes the 'huge' argument. OpenNMS can monitor thousands of nodes, so it's not slow. It's not more or less vulnerable to attack than anything else, so why even mention it?
As someone who's worked more as a programmer than an admin, and both for a long time, in a lot of languages, I see almost all java programs as huge.
So how do they run on phones? And what is huge these days anyway - an extra dollar's worth of RAM?
I also know that *if* you write your code correctly, the code will compile and run on pretty much anything, unless you're writing windowing-system specific stuff.
That's if you know every quirk of every target system - and have all the associated compilers, and take the time to compile on all of them.
Then there's java, that in everything I read from the mid-nineties through the mid-oughts, was presented as being free from memory errors, etc, etc, but as one huge counter-example, just about every time I see a tomcat app crash, the stack traces are 150-200 calls deep, and there are, indeed, memory errors.
You can write badly in any language, can't you? And why bring up old versions? You can take just about anything you were running in the 90's up to maybe a few months ago and realize now that it had horrible bugs. Unless maybe it was written by Donald Knuth...
Further, it's nothing more than a re-imagining (as they say) of Pascal p-code (quick: what other language besides java used the command writeln?).
That's a good thing, now that (a) processes are fast enough that you don't care about the interpreter speed and (b) there are techniques to use native libraries anywhere it does matter.
The difference between recompile and run on a vm that's compiled for that machine is? Oh, right, it is, in effect, another layer that sits on top of the o/s, like a pseudo-os, or windowing system.
Yes, if you don't like language abstractions you could code in assembly for a particular CPU.
I can go on... but I really need to get around to writing my article to be entitled, "The Failure of OOP in General, and Java in Particular".
There's something to be said for functional programming and message passing instead of objects in these days of distributed and multi-cpu systems, but nobody really thinks that way.
Les Mikesell wrote:
On Tue, Jan 10, 2012 at 10:32 AM, m.roth@5-cent.us wrote:
Would someone advise whether the distribution of an obsolete version of java should be reported as a bug; http://icedtea.classpath.org/bugzilla/show_bug.cgi?id=827
One *could* argue that Java is a bug, being a) so error-prone, b) so vulnerable to attack, and c) so huge and slow, and shouldn't be allowed....
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
No, I wouldn't. You argue wrongly. For one, by your first sentence, you deny all of my arguments, with no reasons for that denial.
The reasons are obvious. Java is common on phones, so there goes the 'huge' argument. OpenNMS can monitor thousands of nodes, so it's not
Really? And how much memory is in them? And is it optimized for the phones? Is it a subset of the full JVM?
slow. It's not more or less vulnerable to attack than anything else, so why even mention it?
Based on the reports, more vulnerable. And every bloody java app I've had to deal with ranges from acceptable to sloooowww.
As someone who's worked more as a programmer than an admin, and both for a long time, in a lot of languages, I see almost all java programs as huge.
<snip>
I also know that *if* you write your code correctly, the code will compile and run on pretty much anything, unless you're writing windowing-system specific stuff.
That's if you know every quirk of every target system - and have all the associated compilers, and take the time to compile on all of them.
Hah. You mean like gcc, that runs on everything I've ever heard of?
Then there's java, that in everything I read from the mid-nineties through the mid-oughts, was presented as being free from memory errors, etc, etc, but as one huge counter-example, just about every time I see a tomcat app crash, the stack traces are 150-200 calls deep, and there are, indeed, memory errors.
You can write badly in any language, can't you? And why bring up old versions? You can take just about anything you were running in the
Old versions? Only if you want to call crashes last year, on the current openjdk or Sun java on an updated CentOS "old".
90's up to maybe a few months ago and realize now that it had horrible bugs. Unless maybe it was written by Donald Knuth...
I dunno 'bout that. A lot of the C code or the perl, esp. if I, or people I respected based on evidence had anything to do with, did maintenance on it, didn't have more bugs than crap written today. (Btw, have you seen the report today on slashdot, about the FBI's Sentinel case management system, that LockMart was writing using Agile methodology, is way behind and delayed again...?)
Further, it's nothing more than a re-imagining (as they say) of Pascal p-code (quick: what other language besides java used the command writeln?).
That's a good thing, now that (a) processes are fast enough that you don't care about the interpreter speed and (b) there are techniques to use native libraries anywhere it does matter.
Sorry, but I've run into a lot of sites that are dog-slow, and it's *not* my connection.
The difference between recompile and run on a vm that's compiled for that machine is? Oh, right, it is, in effect, another layer that sits on top of the o/s, like a pseudo-os, or windowing system.
Yes, if you don't like language abstractions you could code in assembly for a particular CPU.
That's a non-sequiteur. All compilers can do that... but except for things like device drivers, very few folks have ever touched assembly.
I can go on... but I really need to get around to writing my article to be entitled, "The Failure of OOP in General, and Java in Particular".
There's something to be said for functional programming and message passing instead of objects in these days of distributed and multi-cpu systems, but nobody really thinks that way.
A friend who worked for (was it ArcInfo? Or Autocad?) back in the late seventies, or maybe it was early eighties, told me they were early adopters of OOP, and they had an orientation talk, and were handed cheat sheets: method == function, message passing == parameter passing, etc.
mark
On Jan 10, 2012, at 11:15 AM, Les Mikesell lesmikesell@gmail.com wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
You mean like Oracle?
-Ross
On Wed, Jan 11, 2012 at 5:42 PM, Ross Walker rswwalker@gmail.com wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
You mean like Oracle?
No, I meant like Intel or an OS that only runs on one or a few CPU types, or a language that only runs on one OS. Aside from the constraints/control the associated vendor might impose you lock yourself out of an easy move to any new alternatives that might come along or consolidation of apps on the platform of your choice.
On Jan 11, 2012, at 9:45 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Jan 11, 2012 at 5:42 PM, Ross Walker rswwalker@gmail.com wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
You mean like Oracle?
No, I meant like Intel or an OS that only runs on one or a few CPU types, or a language that only runs on one OS. Aside from the constraints/control the associated vendor might impose you lock yourself out of an easy move to any new alternatives that might come along or consolidation of apps on the platform of your choice.
I hear what your saying but corporate greed will always trump r
On Jan 12, 2012, at 12:25 AM, Ross Walker rswwalker@gmail.com wrote:
On Jan 11, 2012, at 9:45 PM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Jan 11, 2012 at 5:42 PM, Ross Walker rswwalker@gmail.com wrote:
But you'd be wrong on all counts. I'd argue the opposite - that you should only be allowed to use languages that work across CPU types and OS's so as to never be locked into a monopolistic single vendor.
You mean like Oracle?
No, I meant like Intel or an OS that only runs on one or a few CPU types, or a language that only runs on one OS. Aside from the constraints/control the associated vendor might impose you lock yourself out of an easy move to any new alternatives that might come along or consolidation of apps on the platform of your choice.
I hear what your saying but corporate greed will always trump r
Oops, dropped phone...
Corporate greed will always trump idealistic pursuits. As soon as a product has enough momentum there will be patent fights, copyright fights, licensing and revocation of openness. Soon platforms that contribute the most $$ will get preference and features over others and there goes the cross-platform dream.
Throw your weight behind nothing, use the best technology at the time for the solution. The only true cross-platform language is C.
-Ross
On Wed, Jan 11, 2012 at 11:32 PM, Ross Walker rswwalker@gmail.com wrote:
Corporate greed will always trump idealistic pursuits.
I'm still pondering how Sun's demise fits into this picture....
As soon as a product has enough momentum there will be patent fights, copyright fights, licensing and revocation of openness. Soon platforms that contribute the most $$ will get preference and features over others and there goes the cross-platform dream.
Throw your weight behind nothing, use the best technology at the time for the solution. The only true cross-platform language is C.
You can't be very agile working in C, though. Something called C with roughly similar syntax may work on a lot of platforms but that doesn't mean that you can actually compile and run the same code. Where with java you don't even have to recompile. Look at how jenkins is able to run in master/slave mode with slaves running on an assortment of platforms at once. What would you have to do to match something like jasper reports or the pentaho tools ability to connect to databases and do page layouts in C in a way that would work on such a wide assortment of systems?
On Jan 12, 2012, at 2:13 AM, Les Mikesell lesmikesell@gmail.com wrote:
On Wed, Jan 11, 2012 at 11:32 PM, Ross Walker rswwalker@gmail.com wrote:
Corporate greed will always trump idealistic pursuits.
I'm still pondering how Sun's demise fits into this picture....
As soon as a product has enough momentum there will be patent fights, copyright fights, licensing and revocation of openness. Soon platforms that contribute the most $$ will get preference and features over others and there goes the cross-platform dream.
Throw your weight behind nothing, use the best technology at the time for the solution. The only true cross-platform language is C.
You can't be very agile working in C, though. Something called C with roughly similar syntax may work on a lot of platforms but that doesn't mean that you can actually compile and run the same code. Where with java you don't even have to recompile. Look at how jenkins is able to run in master/slave mode with slaves running on an assortment of platforms at once. What would you have to do to match something like jasper reports or the pentaho tools ability to connect to databases and do page layouts in C in a way that would work on such a wide assortment of systems?
Of course C isn't very flexible by itself and often needs a library (or OS) to make it truly useful.
Don't get me wrong here, I'm not saying everything should be written in C.
What I was trying to say is that as a language C is both cross-plaform and open and it's the "openness" that prevents "lock in" as much as it being cross-platform.
Now if Oracle would fully open Java, then I would add that to my list of cross-platform languages, but until then it's a language I feel would "lock me in".
-Ross
On Thu, Jan 12, 2012 at 8:26 AM, Ross Walker rswwalker@gmail.com wrote:
You can't be very agile working in C, though. Something called C with roughly similar syntax may work on a lot of platforms but that doesn't mean that you can actually compile and run the same code. Where with java you don't even have to recompile. Look at how jenkins is able to run in master/slave mode with slaves running on an assortment of platforms at once. What would you have to do to match something like jasper reports or the pentaho tools ability to connect to databases and do page layouts in C in a way that would work on such a wide assortment of systems?
Of course C isn't very flexible by itself and often needs a library (or OS) to make it truly useful.
More to the point, the OS libraries have little in common. If you don't write on top of a compatibility library (cygwin/APR/wxWidgets, etc.) you have to rewrite everything to move to a different OS. And that defeats most of the other reasons you'd write in C (efficiency, control, etc.). Look at something as useful as rsync and after all these years there's still no native windows port.
Don't get me wrong here, I'm not saying everything should be written in C.
What I was trying to say is that as a language C is both cross-plaform and open and it's the "openness" that prevents "lock in" as much as it being cross-platform.
In most cases you need to look at the bottom line of hardware/os/software licensing/programmer time all at the same time where the dollars are all the same color. It may take months/years of programmer time and extra compiler licenses to make something in C run across platforms. That's not quite the same thing as just copying jar files around.
Now if Oracle would fully open Java, then I would add that to my list of cross-platform languages, but until then it's a language I feel would "lock me in".
You can never count on free future support or additions to anything and java isn't an exception, but how can anything that works now on current openjdk (which includes most open source java apps and libraries) be locked in?
On Jan 12, 2012, at 11:30 AM, Les Mikesell lesmikesell@gmail.com wrote:
You can never count on free future support or additions to anything and java isn't an exception, but how can anything that works now on current openjdk (which includes most open source java apps and libraries) be locked in?
Ok, I may be defending what is ultimately a losing argument here (there must be a word for that), but bear with me while I try and define my point better.
What I am trying to say is that developing on ANY platform, hardware specific OR software specific is by definition locking one's self into that platform. If that software platform isn't available on all hardware your locked out of that hardware.
For example Flash was thought of as a universal media platform, but then along came Apple with it's iPhone and all of a sudden those media applications weren't so universal.
-Ross
On Thu, Jan 12, 2012 at 5:52 PM, Ross Walker rswwalker@gmail.com wrote:
On Jan 12, 2012, at 11:30 AM, Les Mikesell lesmikesell@gmail.com wrote:
You can never count on free future support or additions to anything and java isn't an exception, but how can anything that works now on current openjdk (which includes most open source java apps and libraries) be locked in?
Ok, I may be defending what is ultimately a losing argument here (there must be a word for that), but bear with me while I try and define my point better.
What I am trying to say is that developing on ANY platform, hardware specific OR software specific is by definition locking one's self into that platform. If that software platform isn't available on all hardware your locked out of that hardware.
Oh, the horror of being restricted to windows, unix, linux, and mac platforms and a bunch of phones... Or having to recompile to run on android. Seriously, you may not want to do your own programming in it but there is a ton of free stuff available and now that CentOS finally inherits a working jvm from upstream there's no reason to avoid using it.
For example Flash was thought of as a universal media platform, but then along came Apple with it's iPhone and all of a sudden those media applications weren't so universal.
Nobody is forced to buy an iphone. Oracle vs. Google may play out in interesting ways though. Sort of reminiscent of lawsuits against Linux based on earlier proprietary work.
-
e-letter -
Giles Coochey -
Hakan Koseoglu -
Johnny Hughes -
Les Mikesell -
m.roth＠5-cent.us -
Ross Walker