Before anyone has visions of nimble fighters, we must remember that ion engines have extremely low thrust. A quick calc based on the numbers in the article, which I hope I did correctly, suggests that the thrust is only about 0.3 Newtons (1 ounce for you Imperialists). What makes these engines exciting is that they can sustain that thrust of years. Estimated fuel consumption is only about 14 grams per hour.
I wonder if DRM and trusted computing technologies can be used to prevent virus, worm, and ddos attacks. If only "trusted" executables would run on a computer, then malware would be much harder to perpetrate. DRM for your harddisk could prevent unauthorized executables from reading your e-mail address book, corrupting crucial system files, copyng your files, or logging the keyboard. DRM for personal and system files would prevent them from being copied or modified except by a trusted executable.
I would invision a scheme in which executables must be registered by the creator with a trustworthy third party in a non-anonymous fashion. Code that has not been registered in a publically traceable way would be denied access to system resources or run only within a tightly controlled sandbox. Once a piece of code has been validated, it would be locked in an execute-only state.
Given that most users are too willing to run any old app that comes over the internet, stronger controls on what can and cannot run may be warranted.
Add a cheap means of hoisting the goodies from the surface and we have the first interplanetary mining operation. The lead might be especially valuable in space for radiation sheilding. I wonder what other yummy metals (arsenic, gallium, indium, etc.) might be found on the surface? Perhaps an orbital station around Venus might be a good for manufacturing semiconductors or superconductors from freely available materials from the surface.
Only minor detail....creating an elevator cable that can handle the high temperatures.
Drop the pair with the superball immediately above the basketball. When the basketball hits the ground, it rebounds, hits the falling superball and sends the superball into orbit. (Caution: do NOT stand over the pair of balls when they hit, because the superball bounces far higher than the falling height).
It's a fun demonstration of transfer of kinetic energy.
The problem with "biocomputers" is that typical electronic equipment and biological macromolecules have very different properties. Proteins get their "shape" from very specific conditions, including *temperature*.
Good point. Many proteins (such as those in the human body) are very sensitive to temperature, pH, salinity, etc. Yet I suspect that many organisms have thermally robust proteins -- most bacteria, plants, and cold-blooded animals have proteins that must hold their shape over a wide range of temperatures. I agree with your point about electronic-biologic compatibility. The interface between a biocomputer and any electronics would need to respect the temperature range of the proteins involved. More advanced versions of this technology might leverage research of themophilic bacteria or even replace the polypeptide system with a polyimide system or a polysilane system (silicon based artifical life!) for higher temperature tolerance.
The reason tRNA have specificity for their *exact* amino acid specificity is because of incredibly precise interactions with the enzyme that links them, and the amino acids.
Yes, but we can design new tRNA binding sites to accomodate new amino acids. I know of at least one successful attempt to add an artificial amino acid to the proteosynthesis system in E coli. In theory we could have as many as 64 amino acids. Moreover, Japanese researchers are working on extending the genetic code to have DNA with 6 base pairs, providing the potential for 216 different "amino acids" with a 3-codon encoding scheme. Thus it is feasible to modify the tRNA system to bind other artificial amino acids and synthesize proteins that have these unusual components.
You never know when an already assembled subunit will turn around and bind something that it shouldn't, or when a temperature change will denature a binding site and ruin the whole process.
Binding site specificity is an issue. It will take some clever lock-and-key protein folds to create high specificity -- perhaps single-stranded DNA might provide a suitable high-specifificy binding site. Limitations on specificity and the intricacy of docking sites is why I suspect the technology will be limited to fairly simple electronic circuits. I agree that temperature will need to be controlled during synthesis, but operating temperatures might be at least as variable as those found in temperate climates.
Re: The question is.... Is history applicable?
on
In Search of Stupidity
·
· Score: 2, Insightful
In other words, is it useful either to pick out really smart things companies have done, or really dumb things companies have done, and say "Do this, and you'll succeed; do that, and you'll fail"?
The core assumption made by the student of history is that tomorrow will be like yesterday. The core assumption made by readers of business books like In Search of Excellence is that my company is like their company. Too bad these assumptions are so often wrong.
They say that those who don't learn from history are doomed to repeat it because the blindly repeat the failures) But it is also true that those who do learn from history are doomed to repeat it because they blindly repeat the successes. The point is that context is important and context is different in different companies and in different times.
Since (let's assume) Microsoft wrote it, paid for it, and owns it, it is their business how they handle it.
Good point. I am not saying that Microsoft has no rights to keep its source code secret, only that their exercise of those rights has consequences for the trustworthiness of their product. I also fear that Microsoft's interests are not well aligned with the interests of computer users and that opaque code helps them maintain that imbalance.
Microsoft is in the business of selling software -- the more copies they sell and the less they spend on developing that software, the better the company will do financially. One strategy is to be innovative (it costs more) and secure (also costs more) and sell a truly superior product. But a second strategy is to leverage a near-monopolistic position that forces ongoing upgrades (e.g., by refusing to sell more licenses to old versions to expanding businesses), preventing competitors from gaining a toe-hold (by creating proprietary, closed platforms and regulating who gets prefered pricing or access to technical documention), capturing more of the revenues of add-on functionality (by bundling applications into the operating system) and by pushing for the use of non-backwards compatible formats and interconnection architectures. I fear that Microsoft is using the second strategy more than the first strategy and that software quality is less important under that strategy.
I have no doubt that within microsoft they have a coherent source control system, and they are quite careful that nobody can slip in a back door.
I'm sure that you are right about this. But such controls only work to a point. They do nothing to prevent coercive changes to the code (i.e., Microsoft acceding to a government demand to add some bit of code). They do nothing to prevent internal saboteurs. Moreover, I also suspect that Microsoft would not let a major launch date slip, even if a last-minute hack were discovered in the finalized code. I suspect that would ship the hacked code, and then release a service pack, but not reveal the true level of vulnerability that its customers faced.
Microsoft has every right to be opaque, and consumers have every right to be sceptical of opaque systems.
Were I in control of this style of circuit manufacture, I would look into creating artifical neurons -- a small CPU core would provide the basic multiply-accumulate-threshold logic on the neuron. Other multiply-accumulate circuits at the synapses or dendrites would provide long-term adaptation functionality needed for learning.
The advantage of a neural net appraoch is that it can work with an inexact network. Standard digital electronics are logically fragile for the most part (i.e., they break if you replace an OR gate with an AND or swap two data lines). Digital electronics depends on highly repeatable manufacturing processes that create exact interconnect topologies. In contrast, neural nets are robust to any-to-any connection topologies and use various long-term adaptation schemes to reinforce or attenuate the connections that are needed.
Thus, you could create a soup of neural node cores, dendrite fragments, axon fragments and synapse units that would self-assemble into a gelatinous brain-mass. Plop the mass on top of a set of electrical interconnects and then train the blob to do what ever you want it to do. Moreover, these nano-fragment brains would be about roughly 10-100 times smaller in each dimension (about a thousand to a million times smaller in volume) than their cellular equivalents.
It could get interesting if we can create human-brain level neural net blobs that fit in a 1 cubic centimeter volume. Neural gel-packs, here we come.
I doubt that Microsoft (or any commercial software company) would publically annouce that it had been compromised. The source code processes at Microsoft are opaque -- nobody knows exactly who is putting what into the source code. If hackers, goverment officials, RIAA, etc. are modifying Window's source, nobody would be the wiser. In contrast, the openness of open source development creates an audit trail of who did what to the code (assuming the version tracking and submission system is not compromised).
A better process would be to adapt the proteosynthesis process for creating micro-polypeptide clusters that are circuit elements with highly specific binding sites for self assembly. A DNA sequence would encode an mRNA sequence that is passed to a ribsome-like micro-factory. An alphabet of tRNA units would carry heavily modified amino-acids and provide both the electrical and structural of properties of the polypeptide. Different polypetides might make transistors, autonomous clock circuits, chemical-to-electrical battery subunits, wires, tees, etc.
Part of the DNA sequence would encode binding sites that are highly specific. Each electrical component would have a unique code on each terminal that only binds with the component that it connects to in the circuit. By labelling all the terminii of the components with these specific binging patterns, you the potential for self-assembly. To make a complex circuit, you make separate batches of each component, then mix the batches together and they self-assemble into the circuits. Thus, a soup of appropriately labeled transistors and wires would self-assemble into a soup of full-adder circuits.
The use of larger-scale binding sites would enable hierarchical self-assembly of self-assembled micro-components (e.g., a soup of 1-bit full-adder circuits might self-assemble into a 8-bit full-adders, or 8-bit full-adders might bind to a gated accumulator registers, etc.)
I doubt this technology would let you create a 64-bit processor - the binding-site combinatorics get too ugly. But it might let you create RAM, RFID circuits, or small CPUs (e.g., the Intel 8080 only needs 6000 transistors)
What made Apple successful (if you can call it that) a strong set of UI guidelines that everyone is supposed to follow. Thus there are two key questions:
1. Does the Linux community have a set of UI guidelines?
2. Do Linux app developers follow them?
If the answer to either question is "no" then Linux is not likely to take over the desktops of average (= your grandma) users.
Old Apple laptops make great picture frames such as this Duo hack described on Applefritter. All but the earliest Powerbooks supported color images and have some form of built-in networking.
The problem is that all the best names are already taken.
So true! The problem with hoping that you won't face a C&D or trademark infringement lawsuit is that such lawsuits are not too pleasant and tend to distract customers and investors. That's why we get companies named LoudCloud, Accenture, and Agilent -- 100% unique, made-up names that the creators hope provide a cool and meaningful brand image.
The history of Wintel suggests that top-rated raw CPU performance is not the best predictor of adoption. Compatibility with market-dominating software platforms is a greater determinant of CPU sales. We might hope that advances in compiler design adn flexible cores can help any CPU run x86 code, but there are always the little nts that prevent true compatibility and drive computer buyers toward the dominant platform.
I'm always shocked at these types of naming farces. It is so easy to run a search on any name and determine prior uses. Besides a search engine, other good sources of prior uses of name include any online yellow pages, whois, and the USPTO Trademark Search. A bit of searching before deciding on a name can help prevent these types of trademark infringement problems.
Router-based virus filtering is unlikely to work if too much traffic is over VPNs or in encrypted e-mails. Viruses in encrypted transmissions would pass unfiltered through all the intermediate routers. Overlapping VPNs (such as when multiple companies interconnect in a supply chain) create a potentially unfiltered path for viruses to spread far and wide.
VPN and encryption users could protect themselves with other virus filters (or virus filtering on internal routers that handle plaintext). But, we all know about the low rate of patch adoption.
Ironic that one type of security measure, VPNs, makes another security measure, filtering routers, less effective.
If enough users install router-based virus blocking, then everyone will receive protection. This protection will be especially strong if routers at ISPs and in the backbone contain the filters. At the very least, a virus-hostile infrastructure will slow the spread of viruses - the doubling time for infected machines will be inversely proportional to the fraction of unfiltered virus messages.
Mac users and *nix users need not worry as long as enough routers are configured and maintained to filter viruses.
U-238 is barely radioactive, with a halflife of about 4500 million years. U-235 on the other hand is way more radioactive, and thus the part they are interested in using for reactorcores.
Not true. The half-life of U-235 is 710 million years -- enriched uranium is NOT too hot to handle.
Pu-239 (half-life 24400 years) and Pu-240 (half-life 6580 years) are hotter and are the reason spent fuel needs to be sequestered for so long. But the really nasty, ultra-hot radioisotopes are all the neutron-rich fission byproducts from splitting U-235 or Pu-239. Byproducts like barium-140, cesium-134, cesium-137, and iodine-131 have half-lives in the days to only a few years that make them intensely radioactive (thousands of times more radioactive than Plutonium and millions of times more radioative than U-235). Worse, these byproduct elements will chemically react with ordinary matter, form water-soluable compounds, and lodge in living tissue if injested.
Fact: Spent fuelrods from reactors are a major enviromental problem.
Extremely true, but not because of U-235.
Proving you can get ROI from IT
on
Does IT Matter?
·
· Score: 1
Whether a company has enough IT or needs more depends on whether the IT staff can convince the business people of the ROI of IT projects. The prior ROI of recent projects will determine how much cred the IT staff have with the business side. The projected future ROI of proposed IT projects will determine what the business should do, assuming they take the advice of IT department. There are four combinations for the prior ROI of IT and the future ROI of IT. They are:
1. High prior ROI, high future ROI: An IT-intensive company that derives huge competative advantage by staying ahead of the IT curve.
2. High prior ROI, poor future ROI: An IT-saturated company that can stay with what it has.
3. Poor prior ROI, high future ROI: An IT-bungled company that wil have an uphill battle convincing executives that IT is now worth it.
4. Poor prior ROI, poor future ROI: A company that needs no IT, has PHBs, or a company with an incompetent IT staff.
The investment side of ROI is not too hard to measure using capex and TCO data for IT. But the return side of ROI is where many people miss the boat -- both in upfront estimation and in delivery. If the IT department wants respect, they need to measure business performance and be able to say how business performance will improve with any new IT projects. Then, the IT people need measure the before and after so they can prove that the project was successful from a business standpoint.
The bottom line for IT is the bottom line for the company. Create a good track record of providing return on IT investment and then propose more new projects that provide good ROI. Unless the company is totally under the influence of petty PHBs, any smart CFO is going to greenlight a project that has high ROI.
Mining (with importation to the Earth) will only be feasible if energy is cheap enough. Otherwise the cost of delta-V (the delivery cost of getting the materials from the destination to the Earth) will make the materials not cost effective. It takes energy to boost materials from the Moon, move materials to low-Earth orbit, bring them down to Earth, etc.
Platinum might be a very valuable metal (until the market is flooded by extra-planetary platinum), but I would expect that extraction costs would be extremely high in space and delivery costs would chew up any remaining profit (and not cover the amortized costs for R&D and initial launch of the space mining colony).
The real value for space mining will be in self-sustaining colonies.
What exactly are these contests trying to prove anyway? When the computers gain a clear victory over the humans, what have we learned?
A very worthy question, spectral. The contests prove the power of software to encapsulate and augment human thinking processes. As a software engineer I only need create and develop an algorithm in my head once (and slowly). By writing that algorithm in software I can then execute that mental process very quickly, multiple times, and multiple places. And with team efforts and software reuse, we can create massive software systems that represent the combined (and replicated) intellegence of all the contributors. As you point out, its not surprise that a massive team of chess experts can't defeat a grandmaster. The cool part is that the team need only encode its toughts in software once, and then everyone can have access to the power of that team even after the team is gone.
A computer is to the human brain what an electric motor is to the human arm. Both can do what a person does (to some level of sophistication) and do it repeatedly without need for the person. The electric motor augments (and replaces) human muscle power in many applications and the computer augments (and replaces) human mental power in many applications. Like the computer, an electric motor is faster and more tireless than its human counterpart. Like the computer, an electric motor is less dexterous than its human counterpart.
Nobody feels bad that they can't out-power an electric motor on a range of performance tests. Nobody should feel bad that they can't out-power an computer on a range of performance tests. The difference is that computers are getting better and better on a wider and wider range of performance tests. Driven by Moore's Law and the increasing number of mental tasks that have been encoded in software, computers will continue to gain in equivalent mental power.
I'm sure someone will mention Go, just because it's always said that it's much harder to get a computer to do.
Computers play chess well because of the massive amount of human effort that people have expended in creating Chess programs. Although brute force computing explains some of the rise in performance of chess programs, the sophistication and efficiency of the algorithms has also improved.
When Go recieves the same level of programmer's effort, I'd bet that Go programs will get much better. Then there's Moore's law and the simple fact that computers are increasing in performance much faster than are people.
Extremophile bacteria are found in all sorts of extreme places. Some can live in jet fuel (they corrode the tanks and require antibiotics in jet fuel). Others live in the acidic high-temperature hotsprings in Yellowstone. And entire ecosystems thrive around the 600 degree F "black smokers" in deep-sea thermal vents.
Some miniscule tax (pennies/email) is not going to kill spam and does not even funnel the money to those most affected by it. I say make the sender pay money to the recipient and let the recipient set the payment level. And if the email is from a friend or proves to be worthwhile, let the recipient refund the money back to the sender.
If the recipient values their time, they can demand $3/email. If the recipient values doesn't value their time or wants to maximize payments from spammers, they can demand $0.10/email. In either case, it is the recipient that is in control and it is the recipinet that gets paid for the labor of dealing with spam.
The current e-mail system is broken. The unrestricted low-cost of sending email provides too much incentive to send emails that are worth nothing.
The parent post does a great job of explaining why the Strouhal Number is the same across a range of organisms that use flapping for propulsion. Yet a glance at the graph shows considerable variation among creatures -- a 3:1 range between leaf-nosed bats and gulls. Most of the soaring air-based animals have Strouhal's of around 0.2, whereas the water-based animals have Strouhal's of around 0.3.
It would be interesting to understand not why Strouhal Numbers are constant, but why they vary. I would assume that wing (or fin) shape would affect the optimal Strouhal Number because the Number is calculated on the wing tip, whereas the optimal flap is based on integrating over the wing surface. Wings of different designs, articulations, and flap movement trajectories would have different ratios between the tip-amplitude and the average area-weighted amplitude across the wing surface. I would expect that area-weighted Strouhals to have even less variation across animals that the tip-based number.
Other factors might explain remaining variation. For example, sinusoidal wing beats would have a different Strouhals than square-wave wing beats. Perhaps the Reynolds number might affect Strouhals - explaining the difference between "flight " in air vs. water. Finally, some animals that only fly short distances may have sub-optimal Strouhals because the wings are optimized for other purposes such as courtship.
Slashdot Mirror
Before anyone has visions of nimble fighters, we must remember that ion engines have extremely low thrust. A quick calc based on the numbers in the article, which I hope I did correctly, suggests that the thrust is only about 0.3 Newtons (1 ounce for you Imperialists). What makes these engines exciting is that they can sustain that thrust of years. Estimated fuel consumption is only about 14 grams per hour.
Slow and steady wins the race.
I wonder if DRM and trusted computing technologies can be used to prevent virus, worm, and ddos attacks. If only "trusted" executables would run on a computer, then malware would be much harder to perpetrate. DRM for your harddisk could prevent unauthorized executables from reading your e-mail address book, corrupting crucial system files, copyng your files, or logging the keyboard. DRM for personal and system files would prevent them from being copied or modified except by a trusted executable.
I would invision a scheme in which executables must be registered by the creator with a trustworthy third party in a non-anonymous fashion. Code that has not been registered in a publically traceable way would be denied access to system resources or run only within a tightly controlled sandbox. Once a piece of code has been validated, it would be locked in an execute-only state.
Given that most users are too willing to run any old app that comes over the internet, stronger controls on what can and cannot run may be warranted.
Add a cheap means of hoisting the goodies from the surface and we have the first interplanetary mining operation. The lead might be especially valuable in space for radiation sheilding. I wonder what other yummy metals (arsenic, gallium, indium, etc.) might be found on the surface? Perhaps an orbital station around Venus might be a good for manufacturing semiconductors or superconductors from freely available materials from the surface.
....creating an elevator cable that can handle the high temperatures.
Only minor detail
Drop the pair with the superball immediately above the basketball. When the basketball hits the ground, it rebounds, hits the falling superball and sends the superball into orbit. (Caution: do NOT stand over the pair of balls when they hit, because the superball bounces far higher than the falling height).
It's a fun demonstration of transfer of kinetic energy.
The problem with "biocomputers" is that typical electronic equipment and biological macromolecules have very different properties. Proteins get their "shape" from very specific conditions, including *temperature*.
Good point. Many proteins (such as those in the human body) are very sensitive to temperature, pH, salinity, etc. Yet I suspect that many organisms have thermally robust proteins -- most bacteria, plants, and cold-blooded animals have proteins that must hold their shape over a wide range of temperatures. I agree with your point about electronic-biologic compatibility. The interface between a biocomputer and any electronics would need to respect the temperature range of the proteins involved. More advanced versions of this technology might leverage research of themophilic bacteria or even replace the polypeptide system with a polyimide system or a polysilane system (silicon based artifical life!) for higher temperature tolerance.
The reason tRNA have specificity for their *exact* amino acid specificity is because of incredibly precise interactions with the enzyme that links them, and the amino acids.
Yes, but we can design new tRNA binding sites to accomodate new amino acids. I know of at least one successful attempt to add an artificial amino acid to the proteosynthesis system in E coli. In theory we could have as many as 64 amino acids. Moreover, Japanese researchers are working on extending the genetic code to have DNA with 6 base pairs, providing the potential for 216 different "amino acids" with a 3-codon encoding scheme. Thus it is feasible to modify the tRNA system to bind other artificial amino acids and synthesize proteins that have these unusual components.
You never know when an already assembled subunit will turn around and bind something that it shouldn't, or when a temperature change will denature a binding site and ruin the whole process.
Binding site specificity is an issue. It will take some clever lock-and-key protein folds to create high specificity -- perhaps single-stranded DNA might provide a suitable high-specifificy binding site. Limitations on specificity and the intricacy of docking sites is why I suspect the technology will be limited to fairly simple electronic circuits. I agree that temperature will need to be controlled during synthesis, but operating temperatures might be at least as variable as those found in temperate climates.
In other words, is it useful either to pick out really smart things companies have done, or really dumb things companies have done, and say "Do this, and you'll succeed; do that, and you'll fail"?
The core assumption made by the student of history is that tomorrow will be like yesterday. The core assumption made by readers of business books like In Search of Excellence is that my company is like their company. Too bad these assumptions are so often wrong.
They say that those who don't learn from history are doomed to repeat it because the blindly repeat the failures) But it is also true that those who do learn from history are doomed to repeat it because they blindly repeat the successes. The point is that context is important and context is different in different companies and in different times.
Since (let's assume) Microsoft wrote it, paid for it, and owns it, it is their business how they handle it.
Good point. I am not saying that Microsoft has no rights to keep its source code secret, only that their exercise of those rights has consequences for the trustworthiness of their product. I also fear that Microsoft's interests are not well aligned with the interests of computer users and that opaque code helps them maintain that imbalance.
Microsoft is in the business of selling software -- the more copies they sell and the less they spend on developing that software, the better the company will do financially. One strategy is to be innovative (it costs more) and secure (also costs more) and sell a truly superior product. But a second strategy is to leverage a near-monopolistic position that forces ongoing upgrades (e.g., by refusing to sell more licenses to old versions to expanding businesses), preventing competitors from gaining a toe-hold (by creating proprietary, closed platforms and regulating who gets prefered pricing or access to technical documention), capturing more of the revenues of add-on functionality (by bundling applications into the operating system) and by pushing for the use of non-backwards compatible formats and interconnection architectures. I fear that Microsoft is using the second strategy more than the first strategy and that software quality is less important under that strategy.
I have no doubt that within microsoft they have a coherent source control system, and they are quite careful that nobody can slip in a back door.
I'm sure that you are right about this. But such controls only work to a point. They do nothing to prevent coercive changes to the code (i.e., Microsoft acceding to a government demand to add some bit of code). They do nothing to prevent internal saboteurs. Moreover, I also suspect that Microsoft would not let a major launch date slip, even if a last-minute hack were discovered in the finalized code. I suspect that would ship the hacked code, and then release a service pack, but not reveal the true level of vulnerability that its customers faced.
Microsoft has every right to be opaque, and consumers have every right to be sceptical of opaque systems.
Imagine what the possibilities are here.
Were I in control of this style of circuit manufacture, I would look into creating artifical neurons -- a small CPU core would provide the basic multiply-accumulate-threshold logic on the neuron. Other multiply-accumulate circuits at the synapses or dendrites would provide long-term adaptation functionality needed for learning.
The advantage of a neural net appraoch is that it can work with an inexact network. Standard digital electronics are logically fragile for the most part (i.e., they break if you replace an OR gate with an AND or swap two data lines). Digital electronics depends on highly repeatable manufacturing processes that create exact interconnect topologies. In contrast, neural nets are robust to any-to-any connection topologies and use various long-term adaptation schemes to reinforce or attenuate the connections that are needed.
Thus, you could create a soup of neural node cores, dendrite fragments, axon fragments and synapse units that would self-assemble into a gelatinous brain-mass. Plop the mass on top of a set of electrical interconnects and then train the blob to do what ever you want it to do. Moreover, these nano-fragment brains would be about roughly 10-100 times smaller in each dimension (about a thousand to a million times smaller in volume) than their cellular equivalents.
It could get interesting if we can create human-brain level neural net blobs that fit in a 1 cubic centimeter volume. Neural gel-packs, here we come.
I doubt that Microsoft (or any commercial software company) would publically annouce that it had been compromised. The source code processes at Microsoft are opaque -- nobody knows exactly who is putting what into the source code. If hackers, goverment officials, RIAA, etc. are modifying Window's source, nobody would be the wiser. In contrast, the openness of open source development creates an audit trail of who did what to the code (assuming the version tracking and submission system is not compromised).
Transparency is a prerequisite for trust.
A better process would be to adapt the proteosynthesis process for creating micro-polypeptide clusters that are circuit elements with highly specific binding sites for self assembly. A DNA sequence would encode an mRNA sequence that is passed to a ribsome-like micro-factory. An alphabet of tRNA units would carry heavily modified amino-acids and provide both the electrical and structural of properties of the polypeptide. Different polypetides might make transistors, autonomous clock circuits, chemical-to-electrical battery subunits, wires, tees, etc.
Part of the DNA sequence would encode binding sites that are highly specific. Each electrical component would have a unique code on each terminal that only binds with the component that it connects to in the circuit. By labelling all the terminii of the components with these specific binging patterns, you the potential for self-assembly. To make a complex circuit, you make separate batches of each component, then mix the batches together and they self-assemble into the circuits. Thus, a soup of appropriately labeled transistors and wires would self-assemble into a soup of full-adder circuits.
The use of larger-scale binding sites would enable hierarchical self-assembly of self-assembled micro-components (e.g., a soup of 1-bit full-adder circuits might self-assemble into a 8-bit full-adders, or 8-bit full-adders might bind to a gated accumulator registers, etc.)
I doubt this technology would let you create a 64-bit processor - the binding-site combinatorics get too ugly. But it might let you create RAM, RFID circuits, or small CPUs (e.g., the Intel 8080 only needs 6000 transistors)
What made Apple successful (if you can call it that) a strong set of UI guidelines that everyone is supposed to follow. Thus there are two key questions:
1. Does the Linux community have a set of UI guidelines?
2. Do Linux app developers follow them?
If the answer to either question is "no" then Linux is not likely to take over the desktops of average (= your grandma) users.
Old Apple laptops make great picture frames such as this Duo hack described on Applefritter. All but the earliest Powerbooks supported color images and have some form of built-in networking.
The problem is that all the best names are already taken.
So true! The problem with hoping that you won't face a C&D or trademark infringement lawsuit is that such lawsuits are not too pleasant and tend to distract customers and investors. That's why we get companies named LoudCloud, Accenture, and Agilent -- 100% unique, made-up names that the creators hope provide a cool and meaningful brand image.
The history of Wintel suggests that top-rated raw CPU performance is not the best predictor of adoption. Compatibility with market-dominating software platforms is a greater determinant of CPU sales. We might hope that advances in compiler design adn flexible cores can help any CPU run x86 code, but there are always the little nts that prevent true compatibility and drive computer buyers toward the dominant platform.
I'm always shocked at these types of naming farces. It is so easy to run a search on any name and determine prior uses. Besides a search engine, other good sources of prior uses of name include any online yellow pages, whois, and the USPTO Trademark Search. A bit of searching before deciding on a name can help prevent these types of trademark infringement problems.
Router-based virus filtering is unlikely to work if too much traffic is over VPNs or in encrypted e-mails. Viruses in encrypted transmissions would pass unfiltered through all the intermediate routers. Overlapping VPNs (such as when multiple companies interconnect in a supply chain) create a potentially unfiltered path for viruses to spread far and wide.
VPN and encryption users could protect themselves with other virus filters (or virus filtering on internal routers that handle plaintext). But, we all know about the low rate of patch adoption.
Ironic that one type of security measure, VPNs, makes another security measure, filtering routers, less effective.
If enough users install router-based virus blocking, then everyone will receive protection. This protection will be especially strong if routers at ISPs and in the backbone contain the filters. At the very least, a virus-hostile infrastructure will slow the spread of viruses - the doubling time for infected machines will be inversely proportional to the fraction of unfiltered virus messages.
Mac users and *nix users need not worry as long as enough routers are configured and maintained to filter viruses.
U-238 is barely radioactive, with a halflife of about 4500 million years. U-235 on the other hand is way more radioactive, and thus the part they are interested in using for reactorcores.
Not true. The half-life of U-235 is 710 million years -- enriched uranium is NOT too hot to handle.
Pu-239 (half-life 24400 years) and Pu-240 (half-life 6580 years) are hotter and are the reason spent fuel needs to be sequestered for so long. But the really nasty, ultra-hot radioisotopes are all the neutron-rich fission byproducts from splitting U-235 or Pu-239. Byproducts like barium-140, cesium-134, cesium-137, and iodine-131 have half-lives in the days to only a few years that make them intensely radioactive (thousands of times more radioactive than Plutonium and millions of times more radioative than U-235). Worse, these byproduct elements will chemically react with ordinary matter, form water-soluable compounds, and lodge in living tissue if injested.
Fact: Spent fuelrods from reactors are a major enviromental problem.
Extremely true, but not because of U-235.
Whether a company has enough IT or needs more depends on whether the IT staff can convince the business people of the ROI of IT projects. The prior ROI of recent projects will determine how much cred the IT staff have with the business side. The projected future ROI of proposed IT projects will determine what the business should do, assuming they take the advice of IT department. There are four combinations for the prior ROI of IT and the future ROI of IT. They are:
1. High prior ROI, high future ROI: An IT-intensive company that derives huge competative advantage by staying ahead of the IT curve.
2. High prior ROI, poor future ROI: An IT-saturated company that can stay with what it has.
3. Poor prior ROI, high future ROI: An IT-bungled company that wil have an uphill battle convincing executives that IT is now worth it.
4. Poor prior ROI, poor future ROI: A company that needs no IT, has PHBs, or a company with an incompetent IT staff.
The investment side of ROI is not too hard to measure using capex and TCO data for IT. But the return side of ROI is where many people miss the boat -- both in upfront estimation and in delivery. If the IT department wants respect, they need to measure business performance and be able to say how business performance will improve with any new IT projects. Then, the IT people need measure the before and after so they can prove that the project was successful from a business standpoint.
The bottom line for IT is the bottom line for the company. Create a good track record of providing return on IT investment and then propose more new projects that provide good ROI. Unless the company is totally under the influence of petty PHBs, any smart CFO is going to greenlight a project that has high ROI.
Mining (with importation to the Earth) will only be feasible if energy is cheap enough. Otherwise the cost of delta-V (the delivery cost of getting the materials from the destination to the Earth) will make the materials not cost effective. It takes energy to boost materials from the Moon, move materials to low-Earth orbit, bring them down to Earth, etc.
Platinum might be a very valuable metal (until the market is flooded by extra-planetary platinum), but I would expect that extraction costs would be extremely high in space and delivery costs would chew up any remaining profit (and not cover the amortized costs for R&D and initial launch of the space mining colony).
The real value for space mining will be in self-sustaining colonies.
What exactly are these contests trying to prove anyway? When the computers gain a clear victory over the humans, what have we learned?
A very worthy question, spectral. The contests prove the power of software to encapsulate and augment human thinking processes. As a software engineer I only need create and develop an algorithm in my head once (and slowly). By writing that algorithm in software I can then execute that mental process very quickly, multiple times, and multiple places. And with team efforts and software reuse, we can create massive software systems that represent the combined (and replicated) intellegence of all the contributors. As you point out, its not surprise that a massive team of chess experts can't defeat a grandmaster. The cool part is that the team need only encode its toughts in software once, and then everyone can have access to the power of that team even after the team is gone.
A computer is to the human brain what an electric motor is to the human arm. Both can do what a person does (to some level of sophistication) and do it repeatedly without need for the person. The electric motor augments (and replaces) human muscle power in many applications and the computer augments (and replaces) human mental power in many applications. Like the computer, an electric motor is faster and more tireless than its human counterpart. Like the computer, an electric motor is less dexterous than its human counterpart.
Nobody feels bad that they can't out-power an electric motor on a range of performance tests. Nobody should feel bad that they can't out-power an computer on a range of performance tests. The difference is that computers are getting better and better on a wider and wider range of performance tests. Driven by Moore's Law and the increasing number of mental tasks that have been encoded in software, computers will continue to gain in equivalent mental power.
I'm sure someone will mention Go, just because it's always said that it's much harder to get a computer to do.
Computers play chess well because of the massive amount of human effort that people have expended in creating Chess programs. Although brute force computing explains some of the rise in performance of chess programs, the sophistication and efficiency of the algorithms has also improved.
When Go recieves the same level of programmer's effort, I'd bet that Go programs will get much better. Then there's Moore's law and the simple fact that computers are increasing in performance much faster than are people.
Extremophile bacteria are found in all sorts of extreme places. Some can live in jet fuel (they corrode the tanks and require antibiotics in jet fuel). Others live in the acidic high-temperature hotsprings in Yellowstone. And entire ecosystems thrive around the 600 degree F "black smokers" in deep-sea thermal vents.
Some miniscule tax (pennies/email) is not going to kill spam and does not even funnel the money to those most affected by it. I say make the sender pay money to the recipient and let the recipient set the payment level. And if the email is from a friend or proves to be worthwhile, let the recipient refund the money back to the sender.
If the recipient values their time, they can demand $3/email. If the recipient values doesn't value their time or wants to maximize payments from spammers, they can demand $0.10/email. In either case, it is the recipient that is in control and it is the recipinet that gets paid for the labor of dealing with spam.
The current e-mail system is broken. The unrestricted low-cost of sending email provides too much incentive to send emails that are worth nothing.
The parent post does a great job of explaining why the Strouhal Number is the same across a range of organisms that use flapping for propulsion. Yet a glance at the graph shows considerable variation among creatures -- a 3:1 range between leaf-nosed bats and gulls. Most of the soaring air-based animals have Strouhal's of around 0.2, whereas the water-based animals have Strouhal's of around 0.3.
It would be interesting to understand not why Strouhal Numbers are constant, but why they vary. I would assume that wing (or fin) shape would affect the optimal Strouhal Number because the Number is calculated on the wing tip, whereas the optimal flap is based on integrating over the wing surface. Wings of different designs, articulations, and flap movement trajectories would have different ratios between the tip-amplitude and the average area-weighted amplitude across the wing surface. I would expect that area-weighted Strouhals to have even less variation across animals that the tip-based number.
Other factors might explain remaining variation. For example, sinusoidal wing beats would have a different Strouhals than square-wave wing beats. Perhaps the Reynolds number might affect Strouhals - explaining the difference between "flight " in air vs. water. Finally, some animals that only fly short distances may have sub-optimal Strouhals because the wings are optimized for other purposes such as courtship.