Please do not take my phrase that "Apache+JServ is *much* faster than Apache+mod_perl" as true. In the environment I work (a e-commerce site) the bottleneck of the production server is the database performance, so, perl-based solution must have lost to java-based solution due to less efficient database connection or related stuff. Sorry for a misleading statement.
The rest of my posting still seems to hold some truth:-)
When properly used, Java may be faster than C++ in server environment. If you try to see benchmarks on, say, XML/XSL parsers around, you may se that Java implemetations top the lists.
Javacan be a wasting of resources to serve a wab page if you need to serve 5-10 pages per hour:-) If you take a heavy-load web site (where I currently happen to work), Apache+JServ is *much* faster than Apache+mod_perl. And, it seems, the bottleneck in our case is database performance, not Java servlets. Once servlets got loaded (and, possibly, JIT-ted), there's not much performance penalties on running them. Most code of any other server is loaded once and run many, many times, so, server-side Java technologies thrive (several big application servers and frameworks, EJBs, servlets, etc). I seriously doubt that writing web server apps in 'truly compiled' language can gain noticeable performance improvement over well-crafted pseudocode implementations (such as Java + JIT or PHP4 + Zend). And anyway, ever-popular mod_perl is very much the same 'interpreted language':-)
Returning to the old Soviet computers (Soviet Union died about 9 years ago) -- in the USSR of 50s - 80s military designs *were* superior to most of the civilian ones. Just because about 30% of Soviet budget was military. And military had been able to get the best hardware, fabs, and heads. The Elbrus project (quite advanced for 70s -- tagged memory, parallel architecture, high-level 'assembly language') had lots of military applications and some of parts, IIRC, were classified. Several other military-inspired designs were classifed, too; it covers not only computers, but a whole lot of more or less advanced researches and designs in any area.
Z Corporation actually sells 3D-printers that use powder-gluing process to create [optionally colorful] 3D-models of pretty much anything (small enough). Models take several hours to produce, though they have decent volumetric resolution (about 0.1 mm) and can be created of wide range of materials (metals included, imho). Material has to be glueable and powderable. The powder then is put as a thin layer on a piston, an ink-jet head is used to put [colored] glue on it, forming a section. Then the piston is moved a little downwards, and a new thin layer of powder is put above; then the process continues. It allows to create models with 'dangling' parts. Models can de imported from CADs and even VRML.
The sad part of the story is that the device costs about $67k %-)
Some time before, as one can remember, another technology was proposed. It employed liquid polymer that can be made solid by laser light. But it was impossible to create dangling parts with it (something like several connected chain rings), because some parts of such things have to 'float' during layer-by-layer creation process. In liquid, they sank. In powder, they're firm.
There's a some-years-old, commercailly-approved [color] organic display technology: CDT aka LEP. The best thing about LEPs is that one can use ink-jet process to produce them (no joke):-) So, they're relatively cheap and will only become cheaper as the technology matures. Mostly such screens are used in digital cameras' viewfinders and cellphone displays, though bigger screens were demonstrated.
Does the original article talk about this thing, or some another development?
Of course, those LCD panels you can see in watches and Palms draw quite small electric power. Unfortunately, such LCDs have very limited maximal brightness (let alone color). This is because they use polarisation properties of liquid crystals. Incoming light goes thru a polarizing plate, then thru the liquid crystal layer, then reflects from a mirror and goes backward (to the observer). Liquid crystals rotate light polarization when voltage is applied, so reflected light may come out (we see gray) or not, when liquid crystals change its polarization to orthogonal to such of the polarizing plate (we see black). Since ambient light has rays of all polarization directions, the polarization plate can only allow to pass not more than 50% of light, so, we can only see gray colors (50% or darker). Also, such displays require external light and are useless in the dark.
That's why notebook screens are backlit by a white lamp, that allows to display bright shades/colors, and this lamp does draw a lot of power. An LCD(TFT) matrix that lies above the lamp only makes certain areas darker (up to black). A LED screen of comparable size would draw definitely less power, due to higher efficiency and because darker areas would require less power.
Many mobile devices, like watches and cell phones, use LEDs to backlight LCD displays. LED backlight is nice and battery-friendly, but it is colored (green, or amber, or red). Lack of reliable blue LED material effectively prevents white LED light sources from creation; same applies to full-color LED displays. Current blue LEDs last orders of magnitude less that red/amber/green LEDs.
Many modern PDAs have very fair RAM capacity, CPU speed, flash mem capacity, etc. I don't speak about Palms -- more about WinCE-targeted devices, like iPAQ. No wonder that linux kernel can nicely work there (especially when you build it right). But most current GUIs that linux uses were developed with desktop in mind and are not so great on a PDA. That is, when a decent PDA-oriented GUI becomes available for linux, it will be a very viable PDA OS choice:-) Porting existing (not still ideal for PDAs) linux distros to PDA platforms must help in developing a PDA-oriented GUIs and other tools for linux, so, Debian did a useful (not just 'cool' or such) job, IMHO.
Organisms that can eat plastic don't know that they're only supposed to eat it in landfills. After 'decomposing landfills completely' they gladly will eat plastic everywhere they find it (including your computer case) %-) Biotechnology should be used accurately, lest it become bio-hazard.
To make fungi (or bacteria) mutate by using strong radiation, one does not have to use space station; gamma guns, etc, are readily available on the Earth and, AFAIK, are widely used to generate mutations in bacteria. Same applies to vacuum pumps. One has a good chance to find both things in any decent bio lab.
But the whole story about fungi growing in vaccum seems pretty... err.. fantastic. Fungi spores are known to survive space vacuum and radiation; but live species are known to die at such levels of radiation and such temperature leaps. More, things that get sent to space stations undergo severe decontamination, and it includes steriziation of pretty much everything. (My parents worked at a space launch facility, so I know it not from books only %-)) So it seems quite unprobable for some fungi to come unnoticed to a space station, not to say to proliferate there.
Here at Russia, 5-7 years ago, there was a notable move to using natural gas (methane, propane, butane etc) as fuel for trucks. Motor modifications are minor, liquid gas tanks are somewhat cumbersome, but seem to fit well for trucks. (Anyway, trucks need not very good acceleration, which is unachievable with methane motor.) Methane is much cheaper than gasoline. The downside is, there's not so much refilling stations around, since building and maintaining them takes money, while 'user base' is limited to a fraction of trucks. Now, AFAIK, most of the methane-powered trucks are in rural areas and are used for short-range traffic only, where there is a number of refilling stations; long-distance trucks still use diesel fuel. Though, in some cities, majority of local buses are known to use methane/propane fuel, especially in regions where it abounds, like near oil-drilling areas. <br> <br> Hey, anybody could say something about that wood-spirit powered cars in Brazil? I heard methanol fuel prevails there.
Minimal EXE would not let you tell 'truly compiled' from 'pseudocode+interpreted' approach: runtime may weigh too much. This is the case if you use Delphi: all that mechanics to load forms, etc takes a couple of hundreds of kilobytes (unless you don't use anything Delphi is designed for, that is, RAD features). But it's not of importance, since exe size grows slowly as code is added. Good pseudocode + good interpreter for it can de pretty fast, at least, for a GUI frontend:-) VB has disadvantages more important than the performance, IMHO... But it's a good glue if you have something to glue:-)
Slashdot Mirror
The rest of my posting still seems to hold some truth :-)
When properly used, Java may be faster than C++ in server environment. If you try to see benchmarks on, say, XML/XSL parsers around, you may se that Java implemetations top the lists.
:-) If you take a heavy-load web site (where I currently happen to work), Apache+JServ is *much* faster than Apache+mod_perl. And, it seems, the bottleneck in our case is database performance, not Java servlets. Once servlets got loaded (and, possibly, JIT-ted), there's not much performance penalties on running them. Most code of any other server is loaded once and run many, many times, so, server-side Java technologies thrive (several big application servers and frameworks, EJBs, servlets, etc). I seriously doubt that writing web server apps in 'truly compiled' language can gain noticeable performance improvement over well-crafted pseudocode implementations (such as Java + JIT or PHP4 + Zend). And anyway, ever-popular mod_perl is very much the same 'interpreted language' :-)
Javacan be a wasting of resources to serve a wab page if you need to serve 5-10 pages per hour
Returning to the old Soviet computers (Soviet Union died about 9 years ago) -- in the USSR of 50s - 80s military designs *were* superior to most of the civilian ones. Just because about 30% of Soviet budget was military. And military had been able to get the best hardware, fabs, and heads. The Elbrus project (quite advanced for 70s -- tagged memory, parallel architecture, high-level 'assembly language') had lots of military applications and some of parts, IIRC, were classified. Several other military-inspired designs were classifed, too; it covers not only computers, but a whole lot of more or less advanced researches and designs in any area.
Z Corporation actually sells 3D-printers that use powder-gluing process to create [optionally colorful] 3D-models of pretty much anything (small enough). Models take several hours to produce, though they have decent volumetric resolution (about 0.1 mm) and can be created of wide range of materials (metals included, imho). Material has to be glueable and powderable. The powder then is put as a thin layer on a piston, an ink-jet head is used to put [colored] glue on it, forming a section. Then the piston is moved a little downwards, and a new thin layer of powder is put above; then the process continues. It allows to create models with 'dangling' parts. Models can de imported from CADs and even VRML.
The sad part of the story is that the device costs about $67k %-)
Some time before, as one can remember, another technology was proposed. It employed liquid polymer that can be made solid by laser light. But it was impossible to create dangling parts with it (something like several connected chain rings), because some parts of such things have to 'float' during layer-by-layer creation process. In liquid, they sank. In powder, they're firm.
Does the original article talk about this thing, or some another development?
That's why notebook screens are backlit by a white lamp, that allows to display bright shades/colors, and this lamp does draw a lot of power. An LCD(TFT) matrix that lies above the lamp only makes certain areas darker (up to black). A LED screen of comparable size would draw definitely less power, due to higher efficiency and because darker areas would require less power.
Many mobile devices, like watches and cell phones, use LEDs to backlight LCD displays. LED backlight is nice and battery-friendly, but it is colored (green, or amber, or red). Lack of reliable blue LED material effectively prevents white LED light sources from creation; same applies to full-color LED displays. Current blue LEDs last orders of magnitude less that red/amber/green LEDs.
Many modern PDAs have very fair RAM capacity, CPU speed, flash mem capacity, etc. I don't speak about Palms -- more about WinCE-targeted devices, like iPAQ. No wonder that linux kernel can nicely work there (especially when you build it right). But most current GUIs that linux uses were developed with desktop in mind and are not so great on a PDA. That is, when a decent PDA-oriented GUI becomes available for linux, it will be a very viable PDA OS choice :-) Porting existing (not still ideal for PDAs) linux distros to PDA platforms must help in developing a PDA-oriented GUIs and other tools for linux, so, Debian did a useful (not just 'cool' or such) job, IMHO.
Organisms that can eat plastic don't know that they're only supposed to eat it in landfills. After 'decomposing landfills completely' they gladly will eat plastic everywhere they find it (including your computer case) %-) Biotechnology should be used accurately, lest it become bio-hazard.
To make fungi (or bacteria) mutate by using strong radiation, one does not have to use space station; gamma guns, etc, are readily available on the Earth and, AFAIK, are widely used to generate mutations in bacteria. Same applies to vacuum pumps. One has a good chance to find both things in any decent bio lab.
But the whole story about fungi growing in vaccum seems pretty... err.. fantastic. Fungi spores are known to survive space vacuum and radiation; but live species are known to die at such levels of radiation and such temperature leaps. More, things that get sent to space stations undergo severe decontamination, and it includes steriziation of pretty much everything. (My parents worked at a space launch facility, so I know it not from books only %-)) So it seems quite unprobable for some fungi to come unnoticed to a space station, not to say to proliferate there.
Here at Russia, 5-7 years ago, there was a notable move to using natural gas (methane, propane, butane etc) as fuel for trucks. Motor modifications are minor, liquid gas tanks are somewhat cumbersome, but seem to fit well for trucks. (Anyway, trucks need not very good acceleration, which is unachievable with methane motor.) Methane is much cheaper than gasoline. The downside is, there's not so much refilling stations around, since building and maintaining them takes money, while 'user base' is limited to a fraction of trucks. Now, AFAIK, most of the methane-powered trucks are in rural areas and are used for short-range traffic only, where there is a number of refilling stations; long-distance trucks still use diesel fuel. Though, in some cities, majority of local buses are known to use methane/propane fuel, especially in regions where it abounds, like near oil-drilling areas.
<br>
<br>
Hey, anybody could say something about that wood-spirit powered cars in Brazil? I heard methanol fuel prevails there.
Minimal EXE would not let you tell 'truly compiled' from 'pseudocode+interpreted' approach: runtime may weigh too much. This is the case if you use Delphi: all that mechanics to load forms, etc takes a couple of hundreds of kilobytes (unless you don't use anything Delphi is designed for, that is, RAD features). But it's not of importance, since exe size grows slowly as code is added. Good pseudocode + good interpreter for it can de pretty fast, at least, for a GUI frontend :-) VB has disadvantages more important than the performance, IMHO... But it's a good glue if you have something to glue :-)