From what I understand, and can corroborate from my own experience, there is an annoying, often audible glitch that occurs due to periodically dropped sequences of 32 (?) frames during recording. It's subtle, but quite audible when it falls in a place on the waveform resulting in a very large difference between the remaining segments.
I'm currently working on software that will automatically remove some of the more audible resulting clicks, but I would much rather work on firmware that doesn't drop any samples in the first place!
Hackers also could use the codes to identify software flaws, making break-ins and virus-writing easier. Microsoft has shared parts of its source code with partners, but it has kept the vast majority of the data secret.
It appears perhaps the biggest fear is that the thieves will use the code to profit by creating additional security breaches for hapless users. This is really a big risk to take as a user, and I wouldn't be surprised if CFOs begin to recommend the move to open source primarily for security, especially if some people lose lots of money through this exploit.
I had thought that there was an error in the media, but perhaps you're right, and the simulation's requirements were met at the point the bridge hovers over the other side. This perhaps could be rationalized by allowing a straight, narrow pillar support it. But that ignores the resource cost of such a pillar.
Which leads me to agree that there should be an additional "touch the other side" requirement.
I wonder if a better base would be, say, apache/jserv/gnujsp for the display logic and a set of OpenSource e-commerce EJBs running on the Jonas EJB server?
I see a third "pocket", as you put it, in the form of web-based applications.
There are now a dozen applications engineers where I work who all live and breath Java. Most of the logic is in the form of Servlets, though EJBs will become very important soon as well.
Re:Eveything in Java is a pointer. But it is dead.
on
Quick Death for JavaOS
·
· Score: 1
> Thin Clients are dead.
My understanding is that in common parlance, the web browser is considered a "thin client". That being the case, I would have to dispute your above claim.
Also, in the web development industry, Java is all the rage for building applications in the form of Servlets and (presumably soon) EJBs. In that industry, Java is vital.
Slashdot Mirror
From what I understand, and can corroborate from my own experience, there is an annoying, often audible glitch that occurs due to periodically dropped sequences of 32 (?) frames during recording. It's subtle, but quite audible when it falls in a place on the waveform resulting in a very large difference between the remaining segments.
I'm currently working on software that will automatically remove some of the more audible resulting clicks, but I would much rather work on firmware that doesn't drop any samples in the first place!
It appears perhaps the biggest fear is that the thieves will use the code to profit by creating additional security breaches for hapless users. This is really a big risk to take as a user, and I wouldn't be surprised if CFOs begin to recommend the move to open source primarily for security, especially if some people lose lots of money through this exploit.
Check out the jakarta project for a real world example of a large scale Java project that runs on many different platforms/JVMs.
I had thought that there was an error in the media, but perhaps you're right, and the simulation's requirements were met at the point the bridge hovers over the other side. This perhaps could be rationalized by allowing a straight, narrow pillar support it. But that ignores the resource cost of such a pillar.
Which leads me to agree that there should be an additional "touch the other side" requirement.
I wonder if a better base would be, say, apache/jserv/gnujsp for the display logic and a set of OpenSource e-commerce EJBs running on the Jonas EJB server?
Another Java decompiler that I've found useful is wingdis
Can someone tell me exactly what a TPC-C query 5 is, what it measures, and what sort of real life kind of situation this sort of query might be run?
I see a third "pocket", as you put it, in the form of web-based applications.
There are now a dozen applications engineers where I work who all live and breath Java. Most of the logic is in the form of Servlets, though EJBs will become very important soon as well.
> Thin Clients are dead.
My understanding is that in common parlance, the web browser is considered a "thin client". That being the case, I would have to dispute your above claim.
Also, in the web development industry, Java is all the rage for building applications in the form of Servlets and (presumably soon) EJBs. In that industry, Java is vital.