No, IBM has a completely clean implementation of the class libraries unpolluted by Sun code. In fact, IBM is cleaning house to have a completely independent Java implementation free from licensing issues....of anything relating to Java, it's probably the most complete, best candidate for an open source Java implementation...but somehow the community just wants to keep bashing Sun.
Hey the language specification and Java APIs are there. No one is preventing the community (or any other agent) from developing their own completely independent Java implementations....but it's just so much easier to cry, bitch, and moan about how evil Sun is.
Radars a big frickin' glowin' lighthouses screaming, "HERE IS MY RADAR TOWER!" What use are they if smart weapons launched from stealth platforms annihilate them in the first 24 hours, before real strikes begin?
You might be interested to know that Formula 1 race cars like the Indy 500 generate 3 times their weight in downforce due to aerodynamic effects. If you've ever seen one flip over in a crash, you'd realize just how much lift something the size of that fuselage can generate at > 200mph.
Granted an airplane has to lift the weight of its engine, weapons, and fuel, but its a good start, no?
"Indeed, unless SMP is being taken advantage of, a well-written single-threaded application will always be faster than an equivalent multithreaded application."
Two words: Blocking IO. You are correct that multithreading imposes an inevitable overhead on CPU intensive tasks running on a single processor machine, but most applications are not processor bound. The fact is that almost all applications that do anything besides scientific work have large portions of their execution times used by blocking on IO. Multiple threads allow the time spent waiting on IO in one thread to be spent doing something else "useful" in another thread--provided your OS supports native threads (if not, one thread can block an entire process).
"...but because writing unthreaded code (in the problem spaces where threads are useful) is harder, not because it's faster."
Isn't this almost a tautology? Restating: "In the areas where threads make things easier, it is easier to use threads than to not use threads."
one example, the speed of light might be faster than in vacuum.
No, the speed of light in the medium need only be faster than the speed of light in the surrounding medium--e.g. air.
Re:Good idea for nuclear waste?
on
Going Up?
·
· Score: 1
Perhaps this space elevator? I think it should be safe(r).
The problem isn't the safety of the space shuttle, heavy lift rockets, or any of that. It's the prohibitive cost of launching so much sheer tonnage of material into space. The US alone has hundreds of thousands (possibly millions) of tons of radioactive waste from decommissioned weapons, reactor waste, industrial waste, and medical waste. Launching all of it into orbit (alone) would take thousands upon thousands of launches. At a few tens of millions a piece, it's not exactly cost effective to even bother.
The safety would be an issue, of course, if they were planning to actually do it, but the sheer cost rules it out before safety is even a consideration.
9 ) Ok, within the java API the naming convention should be consistant. Outside of the API it's the programmers decesion. To dictate a style of writing would place an undue burden on programmers.
Bah. It's an "undue" burden to name something correctly. I work with several Polish/German/Swiss programmers. Let me tell you, a naming convention is damn important!
8) No, not on your life. You can take my primitives from my cold dead body. If you want to suggest that primative should not be used in most production applications that's fine, but their is a time and a place for priatives that are very important. Suggesting that we get rid of primatives severly hurts your credability.
Agree completely. Trying to force numerical and scientific applications to be object-oriented with their arithmetic is nonsense.
6) I can see some cleanup here. Threadgroups could go away and 99.9% of people would not care. As for the non-atomic nature of 64bit+ primatives that has alwyas been clearly documented in the spec. It does not guarentee atomic operations on anything longer than 32bits. Although this could be changed it was always a trade off between the smaller systems and the larger systems that java would be running on.
Running java on a machine with a looser memory model is a good way to find out how difficult it is for the language and VM to guarantee memory semantics. Several people, including Doug Lea, have worked on specifying what Java can guarantee. It boils down to things like double-check locking and hand-coded synchronization methods like Dekker's algorithm can't be guaranteed on machines with loose memory models.
5) No, please, no more bloat. XML is great, but to continue to add LARGER API's with memory hungry requirements to the system is a death sentance.
I agree. Java bytecodes are stack based for a reason: they are very compactly encoded. A textual representation could easily be 5x as big. The other reason is that the set of bytecode programs that javac can produce is much smaller than the set of bytecode programs that one can construct by hand--even correctly dynamically typed programs. Most VMs make assumptions about the bytecode structure and will fail to verify code that is oddly constructed. Similarly, the set of statically verifiable programs is not equivalent to either. Having a human readable (and editable) format is asking for trouble, as many people will run into problems with the bytecode verifier with amazingly obscure reasons.
The GC. Many programs need some feedback...
There is a System.gc() call that is supposed to yield the current thread for garbage collection, but there is no guarantee that the system will actually perform garbage collection. IMHO, I think control over the garbage collector is going to do nothing but make implementing a GC algorithm more complicated and less efficient. Besides, the particular GC algorithm employed in the VM you are running on is beyond your control. There are dozens of different possibilities with different performance and overhead requirements. A user program could not control the algorithm as efficiently as possible if it doesn't even know with algorithm is implemented.
G. Czajkowski, L. Daynes, "Multi-tasking without compromise: a Virtual Machine Approach", Proceedings of Object-Oriented Programming, Systems, Languages and Applications, October 2001, Tampa, FL.
G. Czajkowski, L. Daynes, M. Wolczko, "Automated and Portable Native Code Isolation", Proceedings of the 12th IEEE International Symposium on Software Reliability Engineering, Hong-Kong, November 2001.
It was the Ppro that introduced 36 bit physical addressing, also called PAE (physical address extensions). The page tables are extended to 64 bit entries to accomodate frame numbers greater than 2^20, allowing more than 4gb of physical memory to be addressed.
Of course it requires OS support, but however it is _not_ visible to user programs. The segmentation features of the x86 are _within_ the logical address space of a task. Segmentation is on _top of_ paging; that means the 4gb per process limitation still applies. Segmentation is not like it was on the 8086 line.
I have this horse. I've tried everything. Hoof massages, Pur commercials, desert heat, prancing ponies, sweet talking...but the damn thing just won't drink! What gives!?
I have not seen ONE PCI64 slot on any of these test boards!! I hope that this'll be worked out before release.
PCI64 has fuck-nothing to do with a 64 bit address space. It's a data bus. Since when did the register width of a processor have anything to do with the width of its memory and io buses? Hello, modern ia32 machines have 64 bit and 128 bit memory buses these days.
Well...considering the Itanium (predecessor to McKinley) dissipates 130W of power at 800mhz and the fastest Athlons probably dissipate around 70-80w, I think their choice of the McKinley processors is more likely to create a nuclear furnace than any AMD chip...
The point is that there are enough checks and balances to slow down the legislative process so that far-reaching, encroaching legislation doesn't show up overnight. How would you like the alternative? One day a group of lawmakers decide to outlaw mouthwash. Next day, it's a law, and people are getting thrown in jail for it. Then it takes years to overthrow it, people have their lives severely impacted, etc.
The whole structure of our government is to balance power to protect the people from harmful government interference. Part of this is slowing down the legislative process, allowing time for deliberation and compromise between the branches of government.
It really is more for your protection than you think.
Weird shit happens when you start throwing multiprocessors made out of aluminum cans. It takes a very precise cache coherency protocol to make the whole system behave in a deterministic way. If one processor has a slight modification to the coherency protocol (say an extra delay cycle) that the other doesn't, then you're in for trouble. The chances might be one in a trillion that the differences in the protocol cause memory to become inconsistent, but consider the fact that millions of trials a second happen, it won't take long for one slight memory mistake (which will occur in the operating system during synchronization on a spinlock, most likely) to eventually bring the operating system to its knees. First it starts with two processors taking a spinlock simultaneously. Next they screw up an internal queue of processes, pages, or IO buffers. Next an IO buffer gets used by two processes simultaneously. Then suddenly they are sending two different devices corrupt data. Next thing you know some kernel driver somewhere is throwing a fit, and soon the kernel panics.
Yes, having a processor, its memory, and its cache coherency protocol validated by the manufacturer is a good thing! It is not entirely overrated, and is quite crucial. Sure a hobbled-together SMP system might work for a couple days--until something funky sneaks into kernel memory because of an inconsistency in the coherency protocol.
Now, about frying processors. You apparently aren't aware of the fact that nowadays the voltage settings of the processor are configured into the chip at manufacture time. They are chosen based on the clockspeed, intended heat dissipation, and overall, the requirements of the processor. Suppose you change the capabilities of the processor core without supplying the correct voltage. Suddenly the processor won't perform correctly because it doesn't have enough voltage to completely change internal states fast enough between cycles. Suddenly it has mysterious bugs.
Or go the other way. Suppose you screw up and misconfigure the voltage, supplying too much. Power dissipation (and heat dissipation) are proportional to the square of the voltage. Suddenly a small increase in voltage results in a lot of waste heat. Heat that could fry the processor.
Yes, bad things CAN AND DO happen when you start monkeying with those L2 bridges!
I'm going to have to give this another go, because moderators didn't quite catch on. Your point number (2) is where you made a mistake. The DRM can not only make its decision based on the information content but on the DRM's execution environment. If it is able to find _any_ information that is unique to a particular machine (quite easy actually), then it can enforce copy protection through public key cryptography. When the transaction that grants a user a copy of the product in question, the producer can insert a watermark including this unique information and (unforgeably) digitally sign it. The DRM can then check that the signature is correct and matches the unique identifying information. So yes, DRMs can enforce copy protection--through cryptography.
Now, having said that, if the DRM itself is under attack, then it can be altered to not enforce signatures, or (as someone already suggested) run in a sandbox where all unique identifying information can be forged. This is a different problem.
From what I read of the paper, it stopped short of making claims about copy protection, and basically stated that it is impossible to obfuscate a program, not that it was impossible to sign data or verify its source. So, no, it's not obvious, and you are over simplifying an erroneous proof of a claim they didn't make.
Slashdot Mirror
No, IBM has a completely clean implementation of the class libraries unpolluted by Sun code. In fact, IBM is cleaning house to have a completely independent Java implementation free from licensing issues....of anything relating to Java, it's probably the most complete, best candidate for an open source Java implementation...but somehow the community just wants to keep bashing Sun.
Hey the language specification and Java APIs are there. No one is preventing the community (or any other agent) from developing their own completely independent Java implementations....but it's just so much easier to cry, bitch, and moan about how evil Sun is.
And the masses calling for open sourcing IBM's production desktop and embedded VM?
*crickets*
Exactly. This has always been and will always about looting Sun microsystems or [insert OSS bogeyman in possession of valuable technology here].
Particularly telling comment. Will tens of millions have to die for this horrific mistake too?
Radars a big frickin' glowin' lighthouses screaming, "HERE IS MY RADAR TOWER!" What use are they if smart weapons launched from stealth platforms annihilate them in the first 24 hours, before real strikes begin?
You might be interested to know that Formula 1 race cars like the Indy 500 generate 3 times their weight in downforce due to aerodynamic effects. If you've ever seen one flip over in a crash, you'd realize just how much lift something the size of that fuselage can generate at > 200mph.
Granted an airplane has to lift the weight of its engine, weapons, and fuel, but its a good start, no?
"Indeed, unless SMP is being taken advantage of, a well-written single-threaded application will always be faster than an equivalent multithreaded application."
Two words: Blocking IO. You are correct that multithreading imposes an inevitable overhead on CPU intensive tasks running on a single processor machine, but most applications are not processor bound. The fact is that almost all applications that do anything besides scientific work have large portions of their execution times used by blocking on IO. Multiple threads allow the time spent waiting on IO in one thread to be spent doing something else "useful" in another thread--provided your OS supports native threads (if not, one thread can block an entire process).
"...but because writing unthreaded code (in the problem spaces where threads are useful) is harder, not because it's faster."
Isn't this almost a tautology? Restating: "In the areas where threads make things easier, it is easier to use threads than to not use threads."
Patents and copyrights are about making money, NOT fostering innovation.
Bzzzt!
Patents and copyrights are about protection of an individual's ownership and reproduction rights of a produced work.
one example, the speed of light might be faster than in vacuum.
No, the speed of light in the medium need only be faster than the speed of light in the surrounding medium--e.g. air.
Perhaps this space elevator? I think it should be safe(r).
The problem isn't the safety of the space shuttle, heavy lift rockets, or any of that. It's the prohibitive cost of launching so much sheer tonnage of material into space. The US alone has hundreds of thousands (possibly millions) of tons of radioactive waste from decommissioned weapons, reactor waste, industrial waste, and medical waste. Launching all of it into orbit (alone) would take thousands upon thousands of launches. At a few tens of millions a piece, it's not exactly cost effective to even bother.
The safety would be an issue, of course, if they were planning to actually do it, but the sheer cost rules it out before safety is even a consideration.
There are a number of other one-way functions (such as elliptic curves)
No, no, no and no. Elliptic curves form a group, and the definition of a group guarantees that the group's operation is invertible.
Secondly, how do you plan to accomplish decryption of a one-way function? By the definition of "one-way" you can't.
9 ) Ok, within the java API the naming convention should be consistant. Outside of the API it's the programmers decesion. To dictate a style of writing would place an undue burden on programmers.
Bah. It's an "undue" burden to name something correctly. I work with several Polish/German/Swiss programmers. Let me tell you, a naming convention is damn important!
8) No, not on your life. You can take my primitives from my cold dead body. If you want to suggest that primative should not be used in most production applications that's fine, but their is a time and a place for priatives that are very important. Suggesting that we get rid of primatives severly hurts your credability.
Agree completely. Trying to force numerical and scientific applications to be object-oriented with their arithmetic is nonsense.
6) I can see some cleanup here. Threadgroups could go away and 99.9% of people would not care. As for the non-atomic nature of 64bit+ primatives that has alwyas been clearly documented in the spec. It does not guarentee atomic operations on anything longer than 32bits. Although this could be changed it was always a trade off between the smaller systems and the larger systems that java would be running on.
Running java on a machine with a looser memory model is a good way to find out how difficult it is for the language and VM to guarantee memory semantics. Several people, including Doug Lea, have worked on specifying what Java can guarantee. It boils down to things like double-check locking and hand-coded synchronization methods like Dekker's algorithm can't be guaranteed on machines with loose memory models.
5) No, please, no more bloat. XML is great, but to continue to add LARGER API's with memory hungry requirements to the system is a death sentance.
I agree. Java bytecodes are stack based for a reason: they are very compactly encoded. A textual representation could easily be 5x as big. The other reason is that the set of bytecode programs that javac can produce is much smaller than the set of bytecode programs that one can construct by hand--even correctly dynamically typed programs. Most VMs make assumptions about the bytecode structure and will fail to verify code that is oddly constructed. Similarly, the set of statically verifiable programs is not equivalent to either. Having a human readable (and editable) format is asking for trouble, as many people will run into problems with the bytecode verifier with amazingly obscure reasons.
The GC. Many programs need some feedback...
There is a System.gc() call that is supposed to yield the current thread for garbage collection, but there is no guarantee that the system will actually perform garbage collection. IMHO, I think control over the garbage collector is going to do nothing but make implementing a GC algorithm more complicated and less efficient. Besides, the particular GC algorithm employed in the VM you are running on is beyond your control. There are dozens of different possibilities with different performance and overhead requirements. A user program could not control the algorithm as efficiently as possible if it doesn't even know with algorithm is implemented.
G. Czajkowski, L. Daynes, "Multi-tasking without compromise: a Virtual Machine Approach", Proceedings of Object-Oriented Programming, Systems, Languages and Applications, October 2001, Tampa, FL.
G. Czajkowski, L. Daynes, M. Wolczko, "Automated and Portable Native Code Isolation", Proceedings of the 12th IEEE International Symposium on Software Reliability Engineering, Hong-Kong, November 2001.
Uh....Spafford's name isn't even in that link.
It was the Ppro that introduced 36 bit physical addressing, also called PAE (physical address extensions). The page tables are extended to 64 bit entries to accomodate frame numbers greater than 2^20, allowing more than 4gb of physical memory to be addressed.
Of course it requires OS support, but however it is _not_ visible to user programs. The segmentation features of the x86 are _within_ the logical address space of a task. Segmentation is on _top of_ paging; that means the 4gb per process limitation still applies. Segmentation is not like it was on the 8086 line.
Right. Confuse them with verbiage! Then our lawyers can claim it means whatever we want!
:-D
Dear Slashdot:
I have this horse. I've tried everything. Hoof massages, Pur commercials, desert heat, prancing ponies, sweet talking...but the damn thing just won't drink! What gives!?
Sincerely,
Steve, Stupid Rhetorical Questions Dept
I have not seen ONE PCI64 slot on any of these test boards!! I hope that this'll be worked out before release.
PCI64 has fuck-nothing to do with a 64 bit address space. It's a data bus. Since when did the register width of a processor have anything to do with the width of its memory and io buses? Hello, modern ia32 machines have 64 bit and 128 bit memory buses these days.
Then again, maybe they shouldn't fill it with tons of gold and mummies. Hmm...
Well...considering the Itanium (predecessor to McKinley) dissipates 130W of power at 800mhz and the fastest Athlons probably dissipate around 70-80w, I think their choice of the McKinley processors is more likely to create a nuclear furnace than any AMD chip...
No no...Microsoft would probably make them buy a separate license for every processor or something ridiculous like that.
The point is that there are enough checks and balances to slow down the legislative process so that far-reaching, encroaching legislation doesn't show up overnight. How would you like the alternative? One day a group of lawmakers decide to outlaw mouthwash. Next day, it's a law, and people are getting thrown in jail for it. Then it takes years to overthrow it, people have their lives severely impacted, etc.
The whole structure of our government is to balance power to protect the people from harmful government interference. Part of this is slowing down the legislative process, allowing time for deliberation and compromise between the branches of government.
It really is more for your protection than you think.
It's more like encryption with a one time pad. You aren't hiding the data, you're obfuscating it. That's what encryption is.
Weird shit happens when you start throwing multiprocessors made out of aluminum cans. It takes a very precise cache coherency protocol to make the whole system behave in a deterministic way. If one processor has a slight modification to the coherency protocol (say an extra delay cycle) that the other doesn't, then you're in for trouble. The chances might be one in a trillion that the differences in the protocol cause memory to become inconsistent, but consider the fact that millions of trials a second happen, it won't take long for one slight memory mistake (which will occur in the operating system during synchronization on a spinlock, most likely) to eventually bring the operating system to its knees. First it starts with two processors taking a spinlock simultaneously. Next they screw up an internal queue of processes, pages, or IO buffers. Next an IO buffer gets used by two processes simultaneously. Then suddenly they are sending two different devices corrupt data. Next thing you know some kernel driver somewhere is throwing a fit, and soon the kernel panics.
Yes, having a processor, its memory, and its cache coherency protocol validated by the manufacturer is a good thing! It is not entirely overrated, and is quite crucial. Sure a hobbled-together SMP system might work for a couple days--until something funky sneaks into kernel memory because of an inconsistency in the coherency protocol.
Now, about frying processors. You apparently aren't aware of the fact that nowadays the voltage settings of the processor are configured into the chip at manufacture time. They are chosen based on the clockspeed, intended heat dissipation, and overall, the requirements of the processor. Suppose you change the capabilities of the processor core without supplying the correct voltage. Suddenly the processor won't perform correctly because it doesn't have enough voltage to completely change internal states fast enough between cycles. Suddenly it has mysterious bugs.
Or go the other way. Suppose you screw up and misconfigure the voltage, supplying too much. Power dissipation (and heat dissipation) are proportional to the square of the voltage. Suddenly a small increase in voltage results in a lot of waste heat. Heat that could fry the processor.
Yes, bad things CAN AND DO happen when you start monkeying with those L2 bridges!
This attack looks pretty innocuous when you look at how it's possible to reconstruct the video signal via the EM signal your CRT generates.
_ gc i550525,00.html
http://whatis.techtarget.com/definition/0,,sid9
Forget closing the windows. Better build a grounded copper mesh encases your house.
I'm going to have to give this another go, because moderators didn't quite catch on. Your point number (2) is where you made a mistake. The DRM can not only make its decision based on the information content but on the DRM's execution environment. If it is able to find _any_ information that is unique to a particular machine (quite easy actually), then it can enforce copy protection through public key cryptography. When the transaction that grants a user a copy of the product in question, the producer can insert a watermark including this unique information and (unforgeably) digitally sign it. The DRM can then check that the signature is correct and matches the unique identifying information. So yes, DRMs can enforce copy protection--through cryptography.
Now, having said that, if the DRM itself is under attack, then it can be altered to not enforce signatures, or (as someone already suggested) run in a sandbox where all unique identifying information can be forged. This is a different problem.
From what I read of the paper, it stopped short of making claims about copy protection, and basically stated that it is impossible to obfuscate a program, not that it was impossible to sign data or verify its source. So, no, it's not obvious, and you are over simplifying an erroneous proof of a claim they didn't make.