My company does this, and we do distribute our software as "frozen" executables. This compiles everything needed to bytecodes and produces a single executable that is statically linked with the interpreter.
Not exactly like Java bytecodes + JNI + JVM, but close enough. Unless you know what you're looking for, the end result is indistinguishable from a compiled C/C++ app.
The guy in charge of Software at my company analyzed the bytecodes and concluded that reverse engineering them is nearly as hard as for Java, although there are definitely some ops that are less primitive.
PS: Look for freeze.py in the python distribution.
1) Exit polls are usually correct.
2) Bush supporters assume that GeeDub has no chance, so they may decide to punt.
3) Gore supporters assume that their candidate has it locked, so they may decide to punt.
4) Many of the above go and vote anyway because they are already on the way from office or school to the polling place.
I don't think this is a top problem. I think that it has something to do with the way X allocates memory, particularly with SHM extensions and mmap'ed video RAM. I've seen this myself.
Is there anyone that can explain X memory usage in Linux???
> 1) More parts (thus, higher cost)
Wrong. You use fewer parts to get the same bandwidth.
On the other hand, there is more logic on the die, so the cost is higher. It *should* be a very tiny fraction, though. The reduced cost of the packages due to lower pin-counts *should* offset this. We're all waiting on that....
> 2) Only access 1/2 the banks of memory at a time.
This is a minor issue, considering that you still have 4 times as many banks as in PC100/133 SDRAM.
The memory controller needs to be smarter, though.
Speaking of which, why aren't any of these PC-hacker news sites looking at why the Intel DRAM controllers suck so badly, and always have. Intel has traditionally optimized the price/performance of their chipsets for the desktop and value markets. Studying the specs on their SDRAM controller is considered a good baseline. As in, "Well, at least it's more efficient than Intel's." This isn't surprising to me, because everyone at Intel knows that MHz sells new {boxes|chipsets|CPUs}. I, on the other hand, would shell out money for a new chipset that increased DRAM efficiency by 20%.
-bitMonster, who designs memory controllers for fun and profit. Well, mostly for profit.;-)
Slashdot Mirror
My company does this, and we do distribute our software as "frozen" executables. This compiles everything needed to bytecodes and produces a single executable that is statically linked with the interpreter.
Not exactly like Java bytecodes + JNI + JVM, but close enough. Unless you know what you're looking for, the end result is indistinguishable from a compiled C/C++ app.
The guy in charge of Software at my company analyzed the bytecodes and concluded that reverse engineering them is nearly as hard as for Java, although there are definitely some ops that are less primitive.
PS: Look for freeze.py in the python distribution.
This is totally illogical.
Here's my logic:
1) Exit polls are usually correct.
2) Bush supporters assume that GeeDub has no chance, so they may decide to punt.
3) Gore supporters assume that their candidate has it locked, so they may decide to punt.
4) Many of the above go and vote anyway because they are already on the way from office or school to the polling place.
I don't think this is a top problem. I think that it has something to do with the way X allocates memory, particularly with SHM extensions and mmap'ed video RAM. I've seen this myself.
Is there anyone that can explain X memory usage in Linux???
Wow. Well said and sobering.
The change in the nature of the internet over the past 1/2 decade is already staggering.
We're already charged for routable addresses (most of us). Just wait 'til we're charged per *upstream* bit.
You obviously have no idea what source synchronous clocking is.
You obviously have never heard of a wave-pipeline either.
You obviously should not be posting to this thread.
-bitMonster
Go back and try to read more of it.
;-)
> 1) More parts (thus, higher cost)
Wrong. You use fewer parts to get the same bandwidth.
On the other hand, there is more logic on the die, so the cost is higher. It *should* be a very tiny fraction, though. The reduced cost of the packages due to lower pin-counts *should* offset this. We're all waiting on that....
> 2) Only access 1/2 the banks of memory at a time.
This is a minor issue, considering that you still have 4 times as many banks as in PC100/133 SDRAM.
The memory controller needs to be smarter, though.
Speaking of which, why aren't any of these PC-hacker news sites looking at why the Intel DRAM controllers suck so badly, and always have. Intel has traditionally optimized the price/performance of their chipsets for the desktop and value markets. Studying the specs on their SDRAM controller is considered a good baseline. As in, "Well, at least it's more efficient than Intel's." This isn't surprising to me, because everyone at Intel knows that MHz sells new {boxes|chipsets|CPUs}. I, on the other hand, would shell out money for a new chipset that increased DRAM efficiency by 20%.
-bitMonster, who designs memory controllers for fun and profit. Well, mostly for profit.
You failed to consult the oracle.
Mt. Pinatubo erupted in 1991. Krakatau erupted in 1883 and had the effects that you described.
Stacks of LCDs are lame, really expensive, and immovable.