Turn Amish then. With a quad core processor 7-13% isn't a lot. I admit, even with Java this would normally take 1%. But honestly, who cares? As long as it trash my HDD and doesn't consume oodles of power, most users would be quite alright with that. Hell, most users even put up with trash like McAfee.
Besides that, the 486 was *just* able to play MP3 if I'm not mistaken. And you had to spring for an expensive 16 bit sound card, or you might as well skip it altogether. Of course, C/C++ decoders and sound capabilities have matured quite a lot within that time.
"The next group that will be threatened, as we have seen historically, are those whose mental faculties are greatly diminished, or who are not considered useful to society. When the economic considerations are at the forefront of government run-medical care, we will see people opening up to programs that are not very different from the ones used by the Nazis."
In my opinion those applications have more serious issues than memory use. The fact that they crash quite a lot, or lock up would come to mind. And that they are terrible pieces of crap regarding user experience. It's that I hate the K desktop so much that I don't switch, but it's the *only* reason.
Anyway, I'm currently on 22% used by programs, with 8 GB of memory. Before they've found and fixed all memory problems, 64 bit 8 GB will be the norm for desktop systems.
"The OS is in a position to make decisions and mediate in regards to the working set needs of processes, and the user's actual usage patterns. The OS knows which running process makes the most demand of its cache -- the other processes don't know much about each other."
And here lies the problem. Current operating systems/runtime systems are not very advanced at all. They provide way too little functionality. Heck, you cannot even disallow an application to take memory in any sane fashion. And they do not, for instance, provide applications with an OS assisted way of memory management (or thread management etc). One problem is, of course, that if you do add functionality and move into a runtime system that assist applications and users more, then the applications will have to be programmed to actually live in that environment. So portability would certainly suffer. In the end, I think we will move into a world though where this has to take place.
But currently we live in a world where applications still need to install *themselves*, then get rights for each and every document you own, take as much memory and CPU as they want, keyboards get locked out even to the operating system etc. And we have the GPU that has always been a horror to keep in line because of performance constraints. The place where we do see some (slightly squeamish) steps forward is of course mobile phones. Personally, I think that there would be a rather large market for a more secure and managed software environment, especially regarding things like nuclear reactors, submarines and such.
Yes, you may be right. Sometimes it is hard though to distinguish between the fans of the new fangled (scripting) languages and what's going on in the real world. The thing is that you need a certain amount of interest, otherwise it *will* become some kind of Cobol. Something that is *only* maintained because there is so much stuff written in it. You need a certain amount of inovation to keep bright minds interested.
Within our company, we are more and more migrating away from C/C++ because of this. The amount of Java devs has already surged. We've taken a look at C# and.NET, but we could not find a real advantage over Java (and Java was already being deployed). The disadvantage of C# is that you are pretty much stuck with visual studio as development environment, then comes the expensive stuff around it. Nowadays the tools and runtimes are probably more important than the language anyways.
Thanks, I'm pretty well versed in English, but it's not my native tongue. And with slashdot you can only spend so much time reviewing your article, It's approx. one hour before people start to loose interest.
Zenger claimed Google delayed Isys' trademark registration until it could launch its own Chromebooks last month, "thereafter demanding that Isys cease and desist using its ChromiumPC mark and abandon its application for registration".
So it seems that they are doing this as a reaction on Google. If they are right to do so, nah. Maybe Google should have reacted earlier on the ChromePC name though, you should protect your trademarks.
It is symptomatic of the JCP (Java *Community* Process -- in reality run by a committe of about a dozen international corporations)
Of course: those companies have a lot of people working on Java. They *are* a large part of the community.
that is filled with bureaucracy and childish infighting.
They are having serious issues regarding licensing. To call that bureaucracy and infighting? I presume that is rather subjective. Personally, I think it is rather a defining issue.
IMHO the writing is on the wall for Java because stuff moves way to slowly. Java has JPA which would have been a really nice ORM... about five years ago but technology moves faster than that. Compare that to C# whose development process is entirely controlled by a single company and you have Linq2Sql and the Entity Framework.
Java as a language is mainly build on being easy to maintain. A lot of people don't believe in Linq2Sql as it merges two languages together. It's rather questionable if that is the right road to take. It's certainly not the Java road, and never was. You can argue about that during language design, but that's how it is.
There is more api churn, but at least stuff is moving forward.
It was especially apparent with J2ME which went from market leader to an also ran player. All the companies invested in Java tried to stab each other in the back and abused the JCP to gain advantages on each other. The way several of the mobile JSR:s were specified, weren't so much dependent on what would be the best technical decisions but on compromises intended to make everyone happy and not give the market leader (who already had a working reference implementation) an edge.
Many Java API's, especially those in the Java standard edition are very well defined. Take a look at the collections API, the SmartCard I/O API, the way cryptographic providers work etc. etc. This is much less the case with the embedded Java forms, I give you that. Personally, I don't think that the fastest mover should always get the support. The best technical solution should be choosen, and I think this is one of the strengths of the JCP. Note that that might not always translate into the best marketing, that's true. But at least it is more or less fair, and it stops horrors like jPCSC from becoming an API standard instead of smartcardio.
That's why some of the JSR:s are so bizarre such as the Mobile Sensor api.To bad, I say. The Java platform had so much potential that will go to waste. It would have been hard enough for Java to complete if the CLR wasn't superior technology, but it is. The future looks fairly bleak for Linux on the server side without a competitive virtual machine.
IMHO the Java VM is pretty much compatitative, and it's getting better too. If linux fails, I would be very surprised if it is because of the performance of the Java VM (personally, I think they have much more urgent problems than that, and I'm typing this from an Ubuntu desktop...).
Or have they shortened it because *everybody* for whatever reason is running through the orange light right up to the end, making it almost* useless to begin with? I'm a rather sceptical guy, but sometimes you have to wonder if you are skeptical or paranoid - is there really a conspiracy to get you fined? Maybe you should check with the people that represent you what has been discussed before jumping into conclusions like this.
When I was living in Ireland, the orange lights were on for much shorter and the green light of the other car lane becomes green much quicker than in NL. It felt to me that people respected the orange/red light much more. The same thing happens with the doors of the metro - here (NL) people will always try and enter the metro at the last time possible. In 99% of other cities, when the doors close *the door close*. We on the other hand are stuck with dangerous situations and - of course - continuously broken doors.
* "almost" because it still warns you the red light may turn on quickly when you see the orange light
The idea of the summary is to get you to read the article. The article seems to have links to the past issues with Java, which have been discussed on slashdot since forever. Basically you are complaining that the *summary* does not have background info. Unfortunately, it's supposed to.
The problem is that Java is not free at all. The platform is open source (GPL2), but Oracle does not allow any compatability testing between different implementations e.g. with a more permissive Apache license. Basically, because of patents, it is open source as long as you keep your frickin' hands off of it. Google has a strong invested interest because it uses Apache classes (which cannot be validated as being Java) within its Android operating system. And they are getting sued over it. Google certainly uses Java a lot, although it would go way to far to name it a "Java shop".
The problem is that Java 7 has been long, long overdue. It's not that 1.6 is bad; far from it. It's just that people are starting to lose interest. For Java to stay alive, we *need* 1.7 and quickly - and if possible with as much buzz as possible. Java still is by far the best maintainable language. That is something we don't want to loose, especially since there are few competitors regarding stability, security and maintainability.
In the end, they are essentially choosing between progress and halting because of licensing issues. As halting it now ay come to stopping Java altogether. Personally I think that Oracle should immediately stop with the licensing bulshit around android, but this is a technical issue, and I would have voted yes myself.
Maybe it broke rules, but is that enough to be called "defective"? It did seem to work and work pretty well if you look at all the people that were using it. And then Apple sees it and thinks: whoops, we may have our strategy wrong about this, lets build exactly the same functionality. I'm far from an Apple hater (mostly because I can see the beauty in their designs) but this certainly reeks.
I'll stay with android though. It's not without its faults, but at least it's less scary than iOS.
By now when I see that Gartner is at one point of an argument, the other party immediately gains points for acting against Gartner. It's starting to be like Godwin's law; once Gartner chooses your side, you loose:)
Wake me up when they find a new element with a *lower* atomic number than the ones we are accustomed to now. Maybe one with zero protons called Hallucinatium (Ha!).
SHA-1 has not been broken in the sense that forging a signature takes a few mere hours. Actually, the attack is about in the order of 2^51 minimum, and no successful collision has yet been found. Even then, it is not broken for many uses such as specific key generation functions or pseudo number generation functions - although it is worrysome for signature verification as used in SSL/TLS. Actually, many CA's (see the certificate store in your browser) still deploy SHA-1, even for extended validity certs. Personally, I'm slightly worried about the state of many (non-PC) browsers and CA's that don't support SHA-256, SHA-512 or derivatives.
If SHA-1 is ever broken in the sense that collisions can be calculated for pre-existing signatures, you'll certainly hear it in the news. All CA's and SSL/TLS sites will be vulnerable. Before that I would focus on getting the most secure server, configuring it safely and keeping it updated, making sure that nobody (except you and your server) get hold of the private key. Actually, the askers case, you might want to sub-contract that part.
The attacks on AES-256 are rather specific - I don't think they are applicable to their usage in TLS. But never mind that, because AES-128 should be ample for normal TLS connections. Strangely enough (for people not knowing the internal design), 3DES can be more secure against side channel attacks. Most side channel attacks are much more easy to implement than the attacks on hashes on ciphers.
Slashdot Mirror
Turn Amish then. With a quad core processor 7-13% isn't a lot. I admit, even with Java this would normally take 1%. But honestly, who cares? As long as it trash my HDD and doesn't consume oodles of power, most users would be quite alright with that. Hell, most users even put up with trash like McAfee.
Besides that, the 486 was *just* able to play MP3 if I'm not mistaken. And you had to spring for an expensive 16 bit sound card, or you might as well skip it altogether. Of course, C/C++ decoders and sound capabilities have matured quite a lot within that time.
I invoke Godwin's law:
"The next group that will be threatened, as we have seen historically, are those whose mental faculties are greatly diminished, or who are not considered useful to society. When the economic considerations are at the forefront of government run-medical care, we will see people opening up to programs that are not very different from the ones used by the Nazis."
Thank you, you loose.
In my opinion those applications have more serious issues than memory use. The fact that they crash quite a lot, or lock up would come to mind. And that they are terrible pieces of crap regarding user experience. It's that I hate the K desktop so much that I don't switch, but it's the *only* reason.
Anyway, I'm currently on 22% used by programs, with 8 GB of memory. Before they've found and fixed all memory problems, 64 bit 8 GB will be the norm for desktop systems.
"The OS is in a position to make decisions and mediate in regards to the working set needs of processes, and the user's actual usage patterns. The OS knows which running process makes the most demand of its cache -- the other processes don't know much about each other."
And here lies the problem. Current operating systems/runtime systems are not very advanced at all. They provide way too little functionality. Heck, you cannot even disallow an application to take memory in any sane fashion. And they do not, for instance, provide applications with an OS assisted way of memory management (or thread management etc). One problem is, of course, that if you do add functionality and move into a runtime system that assist applications and users more, then the applications will have to be programmed to actually live in that environment. So portability would certainly suffer. In the end, I think we will move into a world though where this has to take place.
But currently we live in a world where applications still need to install *themselves*, then get rights for each and every document you own, take as much memory and CPU as they want, keyboards get locked out even to the operating system etc. And we have the GPU that has always been a horror to keep in line because of performance constraints. The place where we do see some (slightly squeamish) steps forward is of course mobile phones. Personally, I think that there would be a rather large market for a more secure and managed software environment, especially regarding things like nuclear reactors, submarines and such.
Yes, you may be right. Sometimes it is hard though to distinguish between the fans of the new fangled (scripting) languages and what's going on in the real world. The thing is that you need a certain amount of interest, otherwise it *will* become some kind of Cobol. Something that is *only* maintained because there is so much stuff written in it. You need a certain amount of inovation to keep bright minds interested.
Within our company, we are more and more migrating away from C/C++ because of this. The amount of Java devs has already surged. We've taken a look at C# and .NET, but we could not find a real advantage over Java (and Java was already being deployed). The disadvantage of C# is that you are pretty much stuck with visual studio as development environment, then comes the expensive stuff around it. Nowadays the tools and runtimes are probably more important than the language anyways.
Who in their right mind want to see Sarah Palin naked? Nobody sane would click that article :)
Thanks, I'm pretty well versed in English, but it's not my native tongue. And with slashdot you can only spend so much time reviewing your article, It's approx. one hour before people start to loose interest.
The last paragraph of the article reads:
Zenger claimed Google delayed Isys' trademark registration until it could launch its own Chromebooks last month, "thereafter demanding that Isys cease and desist using its ChromiumPC mark and abandon its application for registration".
So it seems that they are doing this as a reaction on Google. If they are right to do so, nah. Maybe Google should have reacted earlier on the ChromePC name though, you should protect your trademarks.
It is symptomatic of the JCP (Java *Community* Process -- in reality run by a committe of about a dozen international corporations)
Of course: those companies have a lot of people working on Java. They *are* a large part of the community.
that is filled with bureaucracy and childish infighting.
They are having serious issues regarding licensing. To call that bureaucracy and infighting? I presume that is rather subjective. Personally, I think it is rather a defining issue.
IMHO the writing is on the wall for Java because stuff moves way to slowly. Java has JPA which would have been a really nice ORM... about five years ago but technology moves faster than that. Compare that to C# whose development process is entirely controlled by a single company and you have Linq2Sql and the Entity Framework.
Java as a language is mainly build on being easy to maintain. A lot of people don't believe in Linq2Sql as it merges two languages together. It's rather questionable if that is the right road to take. It's certainly not the Java road, and never was. You can argue about that during language design, but that's how it is.
There is more api churn, but at least stuff is moving forward.
It was especially apparent with J2ME which went from market leader to an also ran player. All the companies invested in Java tried to stab each other in the back and abused the JCP to gain advantages on each other. The way several of the mobile JSR:s were specified, weren't so much dependent on what would be the best technical decisions but on compromises intended to make everyone happy and not give the market leader (who already had a working reference implementation) an edge.
Many Java API's, especially those in the Java standard edition are very well defined. Take a look at the collections API, the SmartCard I/O API, the way cryptographic providers work etc. etc. This is much less the case with the embedded Java forms, I give you that. Personally, I don't think that the fastest mover should always get the support. The best technical solution should be choosen, and I think this is one of the strengths of the JCP. Note that that might not always translate into the best marketing, that's true. But at least it is more or less fair, and it stops horrors like jPCSC from becoming an API standard instead of smartcardio.
That's why some of the JSR:s are so bizarre such as the Mobile Sensor api.To bad, I say. The Java platform had so much potential that will go to waste. It would have been hard enough for Java to complete if the CLR wasn't superior technology, but it is. The future looks fairly bleak for Linux on the server side without a competitive virtual machine.
IMHO the Java VM is pretty much compatitative, and it's getting better too. If linux fails, I would be very surprised if it is because of the performance of the Java VM (personally, I think they have much more urgent problems than that, and I'm typing this from an Ubuntu desktop...).
Please Mod parent up, instead of the dumbed down argument of the GGP.
Or have they shortened it because *everybody* for whatever reason is running through the orange light right up to the end, making it almost* useless to begin with? I'm a rather sceptical guy, but sometimes you have to wonder if you are skeptical or paranoid - is there really a conspiracy to get you fined? Maybe you should check with the people that represent you what has been discussed before jumping into conclusions like this.
When I was living in Ireland, the orange lights were on for much shorter and the green light of the other car lane becomes green much quicker than in NL. It felt to me that people respected the orange/red light much more. The same thing happens with the doors of the metro - here (NL) people will always try and enter the metro at the last time possible. In 99% of other cities, when the doors close *the door close*. We on the other hand are stuck with dangerous situations and - of course - continuously broken doors.
* "almost" because it still warns you the red light may turn on quickly when you see the orange light
The idea of the summary is to get you to read the article. The article seems to have links to the past issues with Java, which have been discussed on slashdot since forever. Basically you are complaining that the *summary* does not have background info. Unfortunately, it's supposed to.
The problem is that Java is not free at all. The platform is open source (GPL2), but Oracle does not allow any compatability testing between different implementations e.g. with a more permissive Apache license. Basically, because of patents, it is open source as long as you keep your frickin' hands off of it. Google has a strong invested interest because it uses Apache classes (which cannot be validated as being Java) within its Android operating system. And they are getting sued over it. Google certainly uses Java a lot, although it would go way to far to name it a "Java shop".
The problem is that Java 7 has been long, long overdue. It's not that 1.6 is bad; far from it. It's just that people are starting to lose interest. For Java to stay alive, we *need* 1.7 and quickly - and if possible with as much buzz as possible. Java still is by far the best maintainable language. That is something we don't want to loose, especially since there are few competitors regarding stability, security and maintainability.
In the end, they are essentially choosing between progress and halting because of licensing issues. As halting it now ay come to stopping Java altogether. Personally I think that Oracle should immediately stop with the licensing bulshit around android, but this is a technical issue, and I would have voted yes myself.
Trying to claim anything that starts with an i is much much much more generic in my opinion. You cannot defend the one and be against the other.
Maybe it broke rules, but is that enough to be called "defective"? It did seem to work and work pretty well if you look at all the people that were using it. And then Apple sees it and thinks: whoops, we may have our strategy wrong about this, lets build exactly the same functionality. I'm far from an Apple hater (mostly because I can see the beauty in their designs) but this certainly reeks.
I'll stay with android though. It's not without its faults, but at least it's less scary than iOS.
Well done, of course now I'll have to move to the next article.
By now when I see that Gartner is at one point of an argument, the other party immediately gains points for acting against Gartner. It's starting to be like Godwin's law; once Gartner chooses your side, you loose :)
First rule of having a meaningful discussion: argument your case.
Wake me up when they find a new element with a *lower* atomic number than the ones we are accustomed to now. Maybe one with zero protons called Hallucinatium (Ha!).
Please somebody mod parent funny or insightful or such!
As long as we agree that a good RNG is required to be in the mix (and that a constant value is an exceptionally bad RNG :).
SHA-1 has not been broken in the sense that forging a signature takes a few mere hours. Actually, the attack is about in the order of 2^51 minimum, and no successful collision has yet been found. Even then, it is not broken for many uses such as specific key generation functions or pseudo number generation functions - although it is worrysome for signature verification as used in SSL/TLS. Actually, many CA's (see the certificate store in your browser) still deploy SHA-1, even for extended validity certs. Personally, I'm slightly worried about the state of many (non-PC) browsers and CA's that don't support SHA-256, SHA-512 or derivatives.
If SHA-1 is ever broken in the sense that collisions can be calculated for pre-existing signatures, you'll certainly hear it in the news. All CA's and SSL/TLS sites will be vulnerable. Before that I would focus on getting the most secure server, configuring it safely and keeping it updated, making sure that nobody (except you and your server) get hold of the private key. Actually, the askers case, you might want to sub-contract that part.
The attacks on AES-256 are rather specific - I don't think they are applicable to their usage in TLS. But never mind that, because AES-128 should be ample for normal TLS connections. Strangely enough (for people not knowing the internal design), 3DES can be more secure against side channel attacks. Most side channel attacks are much more easy to implement than the attacks on hashes on ciphers.
And a real RNG of course, never forget the random number generator (like Sony forgot when trying to implement ECDSA).
They are doing pretty bad in western Europe too, it's certainly not just the US.