"Solar electricity can be produced by means of photovoltaic arrays (based on the photoelectric effect discovered by Albert Einstein) or by using conventional heat engines whereby solar energy is used to power a turbine. Solar heat is simpler still, requiring only a blackbody and a mechanism for storing and transferring heat"
Einstein didn't dicsover photoelectric effect, he has EXPLAINED it (and earned a Nobel Prize for it).
The problem is hard drives in miniature devices. Hard drives will never be as reliable as solid-state drives, mechanical drives also consume lots of energy (and that's crucial for small devices).
Even MORE devices with unreliable hard drives? Oh my God....
Re:I've been using for some time now
on
APR 1.0.0 Goes Gold
·
· Score: 3, Informative
APR and GLib have slighlty different design goals. GLib is the low-level of GTK (desktop environment) and APR is the low-level library of Apache 2 (server-side).
So APR was designed to work in servers: it has support for memory pools, filesystems routines, network lacking in GLib. But GLib has support for GObjects, signals which are used heavily in GTK.
So if you're writing a portable server-side application in C/C++ then APR is for you.
It'd be cool to have 12 high-end AMD processors instead of relatively slow Transmeta CPUs in this workstation. But I guess their total disspated heat will melt computer case:(
Atoms in a crystal of salt are held together by electomagnetic forces of outer electrons, these forces are million times weaker than it's neccessary to held such configuration together.
1. In such short distances quantum mechanics kicks in and you can't just use the word 'distance'.
2. There's no known methods to create stable configurations of particles of such a small scale.
The only drawback is: creation of muonic atom will consume more energy when it will be produced. Besides, nobody has yet succeeded in creation of stable muonic atoms.
JDK1.5 is not 100% backward compatible, because some new keywords were introduced.
And it's not hard to extend bytecode to be backward compatible AND effective (i.e. allow pointer arithmetic, fixed pointers, etc.). Look at J# in DotNET and IKVM in Mono, they can execute Java bytecode on a completely different platform.
Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2); new J2SE 1.5 (Java 5) is just a cosmetic change of language (yes, I consider current implementation of generics/annotations to be 'cosmetic').
It's quite OK to be conservative, but you can't conquer the world of IT being conservative. Java's position on server-side is still pretty firm, but desktop apps in Java (apart from Java IDEs) are non-existant.
And Microsoft's position on server-side is strengthening. So Microsoft will prevail if nothing changes in the recent future:(
CLR is stack oriented also. It uses generic instructions (ie. one 'add' instruction instead of
'add_int', 'add_float', 'add_byte'...), so that's why JBC is a subset of CLR.
Ansewer to question "to trust or not to trust" depends on circumstances. Remember, Java has native methods too (and you don't want to give permissions for execution of native methods to Java applet).
And I'm NOT a Microsoft friend. But.NET is a very well engineered system. And there are OpenSource implementations of DotNET. Right now I'm hacking Mono sources - it's a very well-written project.
Look at Retroweaver. This is a project aimed to make Java 1.5 features work on previous JVMs (by weaving bytecode). They have a nice explanation why JDK 1.5 is incompatible with 1.4 somewhere on their site.
Slashdot Mirror
Some of these pictures were taken from news sites (as the last message in this fourum says). See this for example.
So this story may be _partialy_ true.
Don't you know that 58% of statistics are made up?
Well, its obvious.
"Solar electricity can be produced by means of photovoltaic arrays (based on the photoelectric effect discovered by Albert Einstein) or by using conventional heat engines whereby solar energy is used to power a turbine. Solar heat is simpler still, requiring only a blackbody and a mechanism for storing and transferring heat"
Einstein didn't dicsover photoelectric effect, he has EXPLAINED it (and earned a Nobel Prize for it).
Please, wake me up when a New Super Extended Platinum 24h long Edition will be available.
And maybe it has never suiceded and it still flies around the Earth, threatening to bring destruction to peaceful USA cities?
:)
Now, that's a good plot for a film with Clint Eastwood
Well, you obviously don't know what does this word mean :)
Word 'Skif' is a direct transliteration of a Russian word. Correct translation is 'a skithian'. Have a look at: Scythia.
Smoking causes cancer!
So much noise about an ordinary Windows insecurity...
.NET core is the last Microsoft's chance to correct its public image as the 'most insecure software vendor'.
IMHO, Longhorn with
Another question: when will Longhorn be out before Duke Nukem Forever?
Why not just boost adoption of IPv6?
The problem is hard drives in miniature devices. Hard drives will never be as reliable as solid-state drives, mechanical drives also consume lots of energy (and that's crucial for small devices).
Even MORE devices with unreliable hard drives? Oh my God....
APR and GLib have slighlty different design goals. GLib is the low-level of GTK (desktop environment) and APR is the low-level library of Apache 2 (server-side).
So APR was designed to work in servers: it has support for memory pools, filesystems routines, network lacking in GLib. But GLib has support for GObjects, signals which are used heavily in GTK.
So if you're writing a portable server-side application in C/C++ then APR is for you.
PS: Subversion (the great VCS) uses APR.
It'd be cool to have 12 high-end AMD processors instead of relatively slow Transmeta CPUs in this workstation. But I guess their total disspated heat will melt computer case :(
JRE is about 7Mb.
Atoms in a crystal of salt are held together by electomagnetic forces of outer electrons, these forces are million times weaker than it's neccessary to held such configuration together.
Two erorrs:
1. In such short distances quantum mechanics kicks in and you can't just use the word 'distance'.
2. There's no known methods to create stable configurations of particles of such a small scale.
The only drawback is: creation of muonic atom will consume more energy when it will be produced. Besides, nobody has yet succeeded in creation of stable muonic atoms.
JDK1.5 is not 100% backward compatible, because some new keywords were introduced.
And it's not hard to extend bytecode to be backward compatible AND effective (i.e. allow pointer arithmetic, fixed pointers, etc.). Look at J# in DotNET and IKVM in Mono, they can execute Java bytecode on a completely different platform.
Notice, 1.2,1.3 and 1.4 only have different libraries and different JVM implementations. That's not what we call language development.
And J2SE 1.5 is just a frantic attempt to add some sugar into Java language.
It's just a marketing.
:(
Java language has stagnated in about 1999 with the release of J2SE 1.2 (dubbed Java 2); new J2SE 1.5 (Java 5) is just a cosmetic change of language (yes, I consider current implementation of generics/annotations to be 'cosmetic').
It's quite OK to be conservative, but you can't conquer the world of IT being conservative. Java's position on server-side is still pretty firm, but desktop apps in Java (apart from Java IDEs) are non-existant.
And Microsoft's position on server-side is strengthening. So Microsoft will prevail if nothing changes in the recent future
CLR is stack oriented also. It uses generic instructions (ie. one 'add' instruction instead of 'add_int', 'add_float', 'add_byte'...), so that's why JBC is a subset of CLR.
Look here, if you don't beleive me: IL instruction set
Mono will certainly have support for C# 2.0 by 2006. And it will mature enough to be used in serious projects.
Ansewer to question "to trust or not to trust" depends on circumstances. Remember, Java has native methods too (and you don't want to give permissions for execution of native methods to Java applet).
.NET is a very well engineered system. And there are OpenSource implementations of DotNET. Right now I'm hacking Mono sources - it's a very well-written project.
And I'm NOT a Microsoft friend. But
Look at Retroweaver. This is a project aimed to make Java 1.5 features work on previous JVMs (by weaving bytecode). They have a nice explanation why JDK 1.5 is incompatible with 1.4 somewhere on their site.