This is the reason why Sklyarov was arrested.
They've been planning this for a while, using
eBook technology. Sklyarov was out at a very
bad time - just before the launch of this service.
It is sad. Luckily they won't have the huge popularity they'd expect; remember: Content Is Not King.
Come on. 6.0 doesn't need to be perfect. No first
release of a commercial product ever is.
Because we live in an open-source world, we are used to waiting through yet another 0.99pl6-94 revision in order to make 1.0 perfect but this is not how it works in the commercial sector.
There, you ship it today and then fix it tomorrow.
I'm finnish and these messages are quite widely used here too but not *quite* to such extremes described here. But the reason is clear: it's less asynchronous than email or physical letters but more asynchronous than calling. Most often in Finland the first words in a phone call are "can you talk?".
You ask whether there is a perfect game --- SURE there is - that's been known for finite zero-sum games for decades now.
What the actual MOVES in that game are is a different question (and probably there are several equivalent variations for both players at most moves) which will remain clouded for quite some time yet.
...to see if any Greek soldiers are lurking in there.
Really, the README says that only green threads are supported and running under SMP kernels is discouraged. Given the resources Sun has to do things right, this can mean only one thing: it's their way of saying "Linux is OK for single-user toy usage but for high-end SMP stuff just get Solaris, OK?". This is more a PR release "We do Linux, we want our stock to go up" than the REAL thing.
I hope IBM will bring out a SMP-supporting JDK2 SOON! Their 1.1.8 is wonderful and fast. Are you listening, IBM?
Well, to ask another way: Is the continuous nature of the magnetic medium of your hard drive a problem?
Your hard drive is on the lowest level an analog device - that's why you can read data that has been overwritten using several times if you have good enough equipment. This implies that the magnetic head is writing to the disk at a great redundancy in both area and magnitude.
There is no inherent "noise immunity" in the hard drive or your memory chips either, they have their own decay rates which are slow but existent.
You can do the same with any analog device: just store your thing with large enough pixels and volume and it will stay readable for a long period of time (provided the material won't decay).
Not really: there are so many different assumptions that might fail that generating code for all the combinations would be impossible.
Of course, the compiler could compile into some sort of intermediate format from which at run time the optimizations are done and discarded as the program runs... but then you've suddenly completed a full circle: that's exactly how the Transmeta CPU runs x86 and Java code and is not what you refer to as "running native"
One may argue that x86 assembly is not the optimal bytecode for something like this. However, given the existing body of software and compilers, it is an obvious choice.
We *may* see (if the speed advantage thus obtained is large enough) a special "transmeta byte code" in the future but it's not that likely.
I don't understand why everyone wants so much to run on the "native" 128-bit VLIW.
The point is, if you compile C code for the VLIW, it will likely run slower than the same code compiled for the x86 architecture and then run through the code morphing software. The reason for this is simple: read their tech whitepaper. In it, they talk about memory protecting for out-of-order loads and stores. If you have C code like
b=a[d]; *c=5; h=a[d];
then this code will run slower unless you can do the out-of-order check and run-time recompilation: if you compile it yourself for the 128-bit VLIW, you lose: your C compiler is NOT ALLOWED to perform the same optimizations since you could get incorrect results.
The really new innovation by Transmeta is those small bits of simple hardware that allow them to trap violations of optimization assumptions, not the 128-bit VLIW part: the latter could have been done by anyone at any time.
Well, stopping the rant now and beginning to wonder when I can get my hands on one;) With the cheap and non-heating parts, you could build a pretty big beowulf or SMP machine inside one tower case --- now that would be something.
Almost done... drivers: Since drivers are part of the OS company, the specs have to be published under an Open API, so that the Applications group and the Internet group can take advantage of them. For example, if TWAIN32 is part of the OS, then the WinAPI that talks to Twain32 has to be fully open so that the app group folks can use it.
Not so - ever heard of NDAs? The OS company can easily only give access to the internet company to those APIs in return for some remuneration.
Instead of being one company, being three but trafficking money as payments for services will work just as well, unfortunately.
The software, introduced in 1997, is called Aureka. The "Au" in Aurigin and Aureka stands for the periodic symbol for gold. (And, yes, the company name and product name are puns for origin and eureka. Who said lawyers don't have senses of humor?
Garbage collecting is my pet peeve... 1.2 has weak references possible, 1.1 you're stuck if you want to cache something but only if it's used by someone else as well.
The basis of GPL is that you can take the source and recompile and have the new version working. Just giving the source to the system but no ability (no root passwd etc) to put their modifications in is, IMO a really really fundamental violation of the whole underlying ideology of GPL. You should also provide (on request) the way to put the modified versions on the boxes.
#1 and #2 and the previous patents collide badly: the processor should be able to run self-modifying code. Naturally, it will be a lot SLOWER because of the retranslations... If it is in critical timing loops, then just maybe there is a problem but on the whole, I'd think this is a rosy herring.
On the contrary: Moore's law has applied to hardware BECAUSE of Parkinson's law has applied to software (Parkinson's law is "the costs will always grow to overtake the means".
If Microsoft and everyone else hadn't made sloppy software, there would have been no demand for the faster 386, 486, pentium etc. boxen and their price would not have come down and the manufacturers could not have made enough money to support development of new chips.
Ironically, we have to thank MS for having such fast commodity hardware available...
Lock contention with 4 processors is down to 2% (saw the number somewhere, done with SGI benchmarking for the kernel), and is expected to go down further.
Because their machines are getting a lot of hits from here, I really hope they'll post a picture with slashdot presence indicated graphically somehow;)
Slashdot Mirror
This is the reason why Sklyarov was arrested.
They've been planning this for a while, using
eBook technology. Sklyarov was out at a very
bad time - just before the launch of this service.
It is sad. Luckily they won't have the huge popularity they'd expect; remember: Content Is Not King.
Come on. 6.0 doesn't need to be perfect. No first
release of a commercial product ever is.
Because we live in an open-source world, we are used to waiting through yet another 0.99pl6-94 revision in order to make 1.0 perfect but this is not how it works in the commercial sector.
There, you ship it today and then fix it tomorrow.
Tuomas
I'm finnish and these messages are quite widely used here too but not *quite* to such extremes described here. But the reason is clear: it's less asynchronous than email or physical letters but more asynchronous than calling. Most often in Finland the first words in a phone call are "can you talk?".
You ask whether there is a perfect game --- SURE there is - that's been known for finite zero-sum games for decades now.
What the actual MOVES in that game are is a different question (and probably there are several equivalent variations for both players at most moves) which will remain clouded for quite some time yet.
No-one here recognizes core memory from the 60s? Little magnetic rings, turned on&off by wires running through them?
Maybe they're making a comeback but somehow I'm thinking that this is more of an april fools thing...
For relatively advanced students, I'd recommend writing their own simple filesystem.
/proc telling various things about the system state.
For beginners, a new directory on
Or re-develop an existing device driver.
Interesting idea: why can't such people become
;) ;) ;)
consultants, paid $1 per year, for the Linux vendors who get access to the specs?
At least that's one way around it.
Also, Linux companies could boast on their headcounts
Just how is having your own talk-show the ultimate
;) ;)
pinnacle of intellectualism?
Enquiring minds want to know
...to see if any Greek soldiers are lurking in there.
Really, the README says that only green threads are supported and running under SMP kernels is discouraged. Given the resources Sun has to do things right, this can mean only one thing: it's their way of saying "Linux is OK for single-user toy usage but for high-end SMP stuff just get Solaris, OK?". This is more a PR release "We do Linux, we want our stock to go up" than the REAL thing.
I hope IBM will bring out a SMP-supporting JDK2 SOON! Their 1.1.8 is wonderful and fast. Are you listening, IBM?
Tuomas
Your hard drive is on the lowest level an analog device - that's why you can read data that has been overwritten using several times if you have good enough equipment. This implies that the magnetic head is writing to the disk at a great redundancy in both area and magnitude.
There is no inherent "noise immunity" in the hard drive or your memory chips either, they have their own decay rates which are slow but existent.
You can do the same with any analog device: just store your thing with large enough pixels and volume and it will stay readable for a long period of time (provided the material won't decay).
Of course, the compiler could compile into some sort of intermediate format from which at run time the optimizations are done and discarded as the program runs... but then you've suddenly completed a full circle: that's exactly how the Transmeta CPU runs x86 and Java code and is not what you refer to as "running native"
One may argue that x86 assembly is not the optimal bytecode for something like this. However, given the existing body of software and compilers, it is an obvious choice.
We *may* see (if the speed advantage thus obtained is large enough) a special "transmeta byte code" in the future but it's not that likely.
The point is, if you compile C code for the VLIW, it will likely run slower than the same code compiled for the x86 architecture and then run through the code morphing software.
The reason for this is simple: read their tech whitepaper. In it, they talk about memory protecting for out-of-order loads and stores.
If you have C code like
b=a[d]; *c=5; h=a[d];
then this code will run slower unless you can do the out-of-order check and run-time recompilation: if you compile it yourself for the 128-bit VLIW, you lose: your C compiler is NOT ALLOWED to perform the same optimizations since you could get incorrect results.
The really new innovation by Transmeta is those small bits of simple hardware that allow them to trap violations of optimization assumptions, not the 128-bit VLIW part: the latter could have been done by anyone at any time.
Well, stopping the rant now and beginning to wonder when I can get my hands on one
With the cheap and non-heating parts, you could build a pretty big beowulf or SMP machine inside one tower case --- now that would be something.
Not so - ever heard of NDAs? The OS company can easily only give access to the internet company to those APIs in return for some remuneration.
Instead of being one company, being three but trafficking money as payments for services will work just as well, unfortunately.
(This bit made me groan...)
The software, introduced in 1997, is called Aureka. The
"Au" in Aurigin and Aureka stands for the periodic symbol
for gold. (And, yes, the company name and product name
are puns for origin and eureka. Who said lawyers don't have
senses of humor?
Garbage collecting is my pet peeve... 1.2 has weak references possible, 1.1 you're stuck if you want to cache something but only if it's used by someone else as well.
The basis of GPL is that you can take the source and recompile and have the new version working. Just giving the source to the system but no ability (no root passwd etc) to put their modifications in is, IMO a really really fundamental violation of the whole underlying ideology of GPL. You should also provide (on request) the way to put the modified versions on the boxes.
#1 and #2 and the previous patents collide badly:
the processor should be able to run self-modifying
code. Naturally, it will be a lot SLOWER because
of the retranslations... If it is in critical timing loops, then just maybe there is a problem
but on the whole, I'd think this is a rosy herring.
On the contrary: Moore's law has applied to hardware BECAUSE of Parkinson's law has applied to software (Parkinson's law is "the costs will always grow to overtake the means".
If Microsoft and everyone else hadn't made sloppy software, there would have been no demand for the faster 386, 486, pentium etc. boxen and their price would not have come down and the manufacturers could not have made enough money to support development of new chips.
Ironically, we have to thank MS for having such fast commodity hardware available...
Lock contention with 4 processors is down to 2% (saw the number somewhere, done with SGI benchmarking for the kernel), and is expected
to go down further.
Because their machines are getting a lot of hits from here, I really hope they'll post a picture with slashdot presence indicated graphically somehow ;)