As wonderful as binary is, it falls utterly in capturing the fuzzy analog nature of life and the real world. Our recent debate on whether Sedna (or Pluto) is a planet is but one example of how the real world fails to fit into simple binary categories. Even at the subatomic level, the wave-particle duality gives lie to the fiction of discreteness.
I'm not saying that binary is not great for doing all manner of wonderfully powerful proofs, logic, and computation. I'm only saying that it is a mere approximation to the real world and can thus fail when the real world is does not dichotomize to fit into Boole's logic.
Boolean Logic illustrates both the tremendous power and weakness of mathematical systems. On the one hand the power of proof guarantees that man-made mathematical system with certain axioms will undeniably have certain properties. On the other hand, math gives one no guarantee that the real world obeys those axioms.
There is an entire branch of astronomy that uses distributed observations to map the size and shapes of asteroids using occultations (eclipses with distant stars). When an asteroid passes in front a distant star, the star winks out and then reappears. Knowing the duration (start and stop times) of the occultation, the location of the observer, and the orbits of the Erath and asteroid lets people estimate the size and shape of the asteroid. International Occultation and Timing Association collects data from telescopes around the world (many in the hands of hobbyists) and uses the data to make these estimates.
It seems that the ultimate system would use at least two wifi cards with a search and load-balancer. One card would provide a connection while the other card searches other bands for the next connection. If both cards find an AP, the load balancer would provide twice thee bandwidth. When the first connection weakens, the system would do a hand-off to the second card. It may disrupt continuity of some internet services, that assume IP continuity, but it would let a user be ultra mobile -- skipping from wifi cell to wifi cell with little perceived break in connectivity.
If the U.S. government were so terribly concerned by gambling, it would ban the stupidity tax (aka state-run lotteries). While I personally don't understand why people gamble, it seems hypocritical for the government to both give citizens the right to gamble on a large scale (at atrocious pay-off odds) and yet prohibit online gambling.
Its interesting that the price of a new console (PS2, XBox, etc.) is less than the price of a highest-end graphics card for a PC. Given that most people have old PCs, buying a console is the cheapest way to get into gaming. Add to that the comfort of a couch and big-screen TV vs. a desktop, I can see why many go for consoles.
Re:Why PDF? (Bad for small screens) try HTML
on
Free Culture
·
· Score: 2, Informative
DON'T use pdf for book distribution!
Agreed! The problem with PDF is that it is based on page defintion -- defining exactly how to layout the letters. PDF has no conception fo words, sentence, paragraphs, headings, footnotes, etc. -- it all just a bunch of filled polylines sprinkled on a fixed-size rectangular space. PDF is totally incompatible with small screens. Its great for preserving the look of a page, but terrible for preserving the meaning.
If you want a universally readable light-weight format for text document, why not use HTML. If anything HTML is more widely used and readable than PDF. HTML can do a better job of semantically meaningful markup (H1 tags vs. Demi Futura Bold 28 Point) and has nice internal and multidocument navigation functions.
Thanks for your thoughtful reply. I suspect we agree, we only differ in how we measure "amount of software."
Consider an example. Assume that each company has 1 programmer and a 1000 employees, and there are 1000 companies, and each company programmer writes 50,000 lines of code. Then you have 50 million lines of written code scattered across the companies, and 50,000*1,000*1,000 = 50 billion person-code-lines of usage of those custom code lines. On the other hand, if SAP hires a 1,000 programmers, and each writes 50,000 lines (50 million lines in a massive application) and then SAP sells the application to 1000 companies with 1000 employees each, then we have 50,000,000*1000*1000 = 50 trillion person-code-lines of usage of those manufactured lines of code. In this example, we have a total of 2,000 programmers and a total of 100 million lines of code but the average employee is using only 50,000 lines of custom created code and 50,000,000 lines of manufactured code.
I'm only pointing out that most of the software used by any given person (it terms of lines of code) is manufactured software. In fact my understanding of why companies like SAP and Oracle are so successful is that its more cost effective to use manufactured software (with configuration) than it is to custom-create everything -- why reinvent the wheel.
In the manufacturing analogy, software engineers are like the engineers at a manufacturer -- they design once and the company replicates many. Big software companies attempt to invent the wheel once and then sell it many times -- a manufacturing model that seems increasingly popular. Yes, there is a service component to software (similarly there is a service component to manufactured goods in many B2B situations)
"Ease of use" - One law I've learned:
As software becomes 'smarter', the difficulty in using the software increases.
That is a very important and confounding point! The people that rail against the complexity of some categories of software (especially enterprise systems) have no appreciation for the complexity of the functionality required by these systems. Many applications are hard to use, in part, becuase the domain is hard.
My point is that bad design makes applications even harder to use and thus requires more support, maintenance etc.
Now that you mention this issue, it suggests another trend in software support. As the software becomes easier to use there is less need for technical support. But, as you correctly point out, the software tends to become more functional and complex in the domain. Thus, I suspect that helpdesk people will need to switch from being software experts (that solve IT problems) and becoming subject matter experts (that help users solve business problems).
So, after a massive effort of automating the installation and configuration process, those 5 pesky 5 minute questions went away...to be replaced by 20-45 minute questions on a variety of issues we never realized existed.
That's a funny story and very true, too. The question is: did total support labor drop and did total adoption and use increase? I'd wager that after that application became easy to install, more people used it and that support per user-hour-of-use actually dropped.
The BOMARC was a early ramjet-powered missle from 60s. You can see one in Dayton Ohio at the Wright-Patterson Air Forcebase Museum. One can walk up to the BOMARC and look up inside the ram jets which are nothing more than a hollow tube with a grid of fuel injection nozzles.
It would seem that the internet's anonymity, lack of authentication, and high-susceptibility to automation makes it easy for groups or issues to appear more poular and populous than they really are. There is no gaurantee that the "thousands" writing in support of some position aren't one person or even one non-U.S. citizen.
I wonder when some pressure group will use spammer's tricks (zombie machines and scripts that spew thousands of automated messages) to flood political forums, blogs, write-in campaigns etc.
I'm not saying that the internet is not a wonderous medium for publishing ideas and sharing insights into pressing issues, only that it represents a potentially corruptible, biased sample on popular opinion.
The two top arguments in the article for why software is a service were erroneous.
1. 19/20 jobs are for in-house programmers This ratio may be true, but the conclusion that most software is written at the point of use as a service is false. If that one-in-20 commercial software company programmer writes commercial code that that sells even one thousand copies, then commercial code becomes 1000/(1000+19) = 98.1% of the code instances in use.
Another way to look at this is to examine the code inside the average company server for the ratio of in-house versus chimerical code. You will find maybe 10 million lines of code in a commercial OS, millions of lines of code in commercial enterprise applications (e.g., SAP, Oracle, Exchange Server, etc.), and a comparative fraction of that in code written in-house (config files, business rule scripts, report generators, PERL scripts, custom applications, etc.). Look inside the average desktop and the ratio of in-house to commercial code is even more extreme.
2. Remainder bin software: This argument is partially tautological. People (and retailers) devalue discontinued items or items from defunct makers because of the often valid perception that the item (or maker) was discontinued for good cause. If something did not sell on the shelves and the maker goes bankrupt, there is probably a reason. I will grant that future value plays a role in buying software, but part of the discount for remaindered goods reflects the low present use value.
Enterprise Does Have a Service Component: I think part of the difference lies in the distinction between enterprise software and consumer software. Clearly, enterprise software requires much more configuration, maintenance, and support -- its much more service oriented. The Accentures, EDSs, and IBMs of the world have made a ton of money on service related to software and IT.
Consumer Won't/Don't Pay for Service: In contrast, consumer software is much more manufacturing driven. There is simply no way that a $49 retail piece of software can come with any service. Nor, judging by the income statements of software makers, do these makers provide much service. There is simply no room in a $49 price point to cover the costs of real on-going tech support. Even upgrades are hardly a service -- the upgrade price is software half or 2-3rds the full retail price and given that the software maker gets to keep a bigger cut by selling upgrades direct, upgrades are a massive profitable product sales.
I doubt consumers will move to a subscription model for software (see Microsoft's attempts to do this) and I doubt they would like a pay-as-you-go model either. Most people bitch anytime that have to buy service (fixing a car, hiring a plumber, etc.) because most people place a less-than-salary value on their own time while the cost of service is always a more-than-salary amount (to cover benefits, employers taxes, support costs, profit, etc.) Do-it-yourself retailers like Home Depot and AutoZone have gotten very rich on consumer's asymmetric valuation of service labor. Consumers only want free service and that means bundling service into the retail price of a saleable manufactured asset.
Rising Ease-of-Use == Less Service:But I even wonder about the service model in all kinds of software. I would further argue that as ease-of-use improves, the need for service drops. The more a piece of software "just works" the more it acts like a manufactured good.
Even in configuration-heavy enterprise software systems, better interfaces could reduce the amount of coding-labor required to configure, maintain , and support big enterprise systems. The move from all-in-house applications to commercial enterprise apps also reflects a move to manufactured software. And as the enterprise apps accumulate functionality (SAP has 27 different inventory management algorithms), it becomes harder to justify paying in-house programmers to write one-off application. Now I'm sure that enterprise system will continue to need lots of service, but I wonder if the amount of service (per function point) won't decline as the systems become more plug-n-play, point-n-click.
I wonder if HP and IBM will squeeze out service-only firms like Redhat and Novell as Linux improves in ease-of-use. If Linux becomes very easy to use, there will be less demand for service and support providers that configure and manage Linux systems -- users wil be able to configure and manage their own boxes. I'm sure there will stil be a role for systems integrators for big enterprise rollouts (which IBM and HP can do), but even there I'd bet that many companies will prefer to hire a few Linux techs to oversee these easy-to-use-boxes.
Perhaps profits-from-hardware will supplant profits-from-service as the OSS business model. Why buy support if the system is so easy-to-use that it does not need support? At the very least, service revenues will be inversely proportional to ease-of-use.
At 30 Frames/sec, a battery life of 10,000 pages is less than 6 minutes.
Its a "low power" technology only when slowly flipping through static pages. But for more active screen work, scrolling, its not going to have very good battery life -- even at 2 frames per second, its only going to get a hour and a half. Even animating the pointer will drain energy if done at too high a frame rate.
I expect that for PDA applications, this display wil be better than the current crappy generation battery-sucking machines, but not as good as the old Palms and Psions.
If (BIG IF, I know) this cuts down on spam to.ch addys, I wonder if safe-haven hosting services will spring up in Switzerland. I may not be able to get Swiss citizenship, but perhaps Swiss citizenship for my domain would help stem the tide of spam.
1. Professors are gods: All ideas come from them, even if you thought them up. Let the profs be the thought leaders and you will do OK.
2. Staff positions may be subject to the whimsy of grant-givers: Your position may be tied to long-term research grants or funding that can dry up.
3. Lots of smart people: Profs and grad students will, by and large, be smart and interesting. If you like thinking/talking about new ideas, you will have fun.
4. Slower pace: Universities don't operate on the same timescale as entrepeneural companies. "I need it soon" might mean "I need it next month."
5. YMMV: as with corporate life, specific situations or bosses might suck egregiously or be ludicrously enjoyable.
If they use the right encryption and safety measures, why won't that be secure?
There's no such thing as unhackable security, especially if you want cheap boxes that sit on all the thousands/millions of powerplants and distribution facilities in a big power grid. Sooner or later people will find a weakness in the software, firmware, or hardware of the little boxen on all those sensor and control nodes. Sooner or later a power company will fail to patch a hole (or it will take months to physically replace/patch defective hardware). Sooner or later, the keys to some part of the control net will get leaked or stolen. If the control and sensor boxes on are on the public net, they will become remotely hackable.
Just being connected to the net doesn't mean you're instantly going to get cracked. Look at microsoft.com - a server everyone and their dog wants to crack into
First, I doubt the power companies would or could replicate Microsoft's level of security (either in terms of money or skilled people). Regular corporations do get kacked all the time. Second, I'd bet Microsoft gets hacked too, but its not publically announced or even necessarily discovered.
The power distribution companies are just about the one group who really can afford to run private fibre. After all, they already HAVE cables connecting all the omportant sites, byu definition, and the technology to wrap a fibre around a power line is already well established.
Perhaps its a country-by-country issue. In the U.S., power transmission is a neglected, regulated industry -- its the people that generate the power, not the people that transmit the power, that make all the money. Transmission, at least in the U.S., is a commodity infrastructure and many regard it as underfunded.
But even if the power companies of some countries could afford their own fiber, why would they choose this? And if they do pay to install fiber, why wouldn't they lease unused capacity on this line? To the extent that they either choose the cheaper option (use other's fiber) or lease out their own fiber, they are insecure. Public packets and infrastructure control packets should not be corouted.
I would fear that a "new electricity net" would be less secure than the current control systems because the control nodes would inevitably be connected to the public internet with packets tunneled via a VPN to the central office. I don't see power companies laying their own independent fibers for connectivity. And even if they use their own BPL, there is a good chance the control nodes, sensor nodes, and ccentral office will be connected to what is a public-exposed BPL net. The cost efficiency of routing packets over the public net are just too tempting. Despite best efforts, I'm sure someone will figure a way to hack into the sensor nodes, control nodes, or the central office if it is connected to a public internet.
The current system is more secure (if unreliable and uncontrollable) because compromising it requires physical access.
I use plain Google (my wife uses Google advanced ) because its the most used page on the internet for us. I previously to use a customized Yahoo finance page (an Excite page before that) but they took too long to load.
With OSS, an intrusion, even a full bore compromise of the code base is more likely to be caught. I would hope that there are diligent OSS people that cross-compare their copies of the source to the CVS copies and look for disrepancies. A distributed analysis of all changes (including the officially sanctioned ones) would help uncover malicious code.
In contrast, the users of proprietary code have only the manufacturer's word on what changes occured, who made them, and what those changes do. We users have no easy way (short of reverse engineering the code deltas on the binaries) of determining what happened between version X and version X.1. The security of non-OSS code is in nontransparent hands and that makes it insecure.
Too many config files, control panels, etc. fail to adhere to the advice being given to NASA on this problem. If every programmer and software designer followed this advice, it would be impossible to misconfigure a computer or create a crash-prone system. Currently, its just too easy to mis-configure systems because the systems let the user enter improper/conflicting settings.
Perhaps when every config file has the equivalent of a "this side up" on all the fields and parameters, then we will have obtain the ease-of-use Holy Grail.
Although cool 3d interfaces are nice and do create a more intuitive user interface, the reasons that ease-of-use is so low (even on the Mac) is the problems of system configuration and the mismatch between command-oriented input systems (both GUI and CLI) versus goal-oriented users.
Better help systems (not wizards) and more explanatory error messages would go a long way to improving ease-of-use. If computers could explain WHY they can't perform some operation (rather than THAT they can't perform some operation), it would make them les frustrating to use.
It may not be glamorous, but translating all the system setups, command sets, and controls into something goal-oriented rather than technology oriented would be a major step toward ease-of-use (the average usuer should never need to know an acronym to configure their computer). This would mean contextual help that explains what to do in terms that reflect the goals of the user, not the minutae of the underlying technologies.
More eye-candy will not make the machines easier to use. Better user-centric documentation, configuration, and diagnostic messages will.
The biggest challenge to this type of tech is creating complex large-scale patterns. Its one thing to create a fully regular "crystal" of 1-bit memmory cells, its another to create the highly irregular, specific, chip-spanning structures of a CPU. If we are going to make complex nanocircuits, we need a way to ensure that the right bit gets connected to the left bit.
I wonder if 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)
Re:Physics vs. Software (nano, math, & patents
on
AT&T Labs' Brain Drain
·
· Score: 2, Insightful
Nano technology is the future and silicon is going to run out soon in terms of how much smaller can you get the circuits
I agree 100% with you. Nanotechnology is the future. But that does not make it a wise R&D investment. Recall that Drexler wrote his Engines of Creation: The Coming Era of Nanotechnology back in 1986. Anybody who patented stuff in that book got nothing for it -- 1986 patents expired last year. Despite nearly 2 decades of additional effort, we still don't have commerical nanotechnology. Someday, people will make money on nanotechnology, but I bet it won't be the pioneers.
Universities have been researching mathmatical algorithms for decades.
Yes they have, but not the ones that might make a different in business. The academic world places too much emphasis on analytic tractability -- professors and scholoarly journals like to see nice theories with closed-form equations. But many real-world problems don't reduce to equations that are tractable for the purposes of getting a Ph.D. or tenure. Companies like SAP and i2 (and Wal-Mart for that matter) make billions of dollars on applied math that most academics wouldn't touch.
But the real argument is you can not patent numbers of formulas so its unprofitable in case they do discover the ultimate algorithm.
For better or worse, you can patent software. But even if you cannot patent the software, you can still make money on it. If you embed the software in proprietary hardware (like a Lucent firewall or switch), use it internally to run the company, or offer it as a service running on closely-held binaries, then you don't need a patent.
I was at conference at Bell Labs/Lucent not too long ago and I think part of what is happening is a natural shift in what matters in corporate research. I got the sense that Bell Labs was shifting slightly from its physics/hardware roots to math/algorithms/software future. They still do physics, but they also do proportionally more R&D in the idea/software space. (Disclaimer: I didn't see any budget figures or top secret stuff, so who knows what they really goes on in Murray Hill)
I'm not saying that we should stop R&D on hardware, solid state physics and materials, only that new software and software-related tools would help everyone get the most out of the current portfolio of hardware technologies. Given that we just discussed "Why Programming Still Stinks" and have not discussed "Why Hardware Still Stinks," I would suggest that the bigger research opportunites are in software.
I also suspect that software is more commercialization-friendly. If you look at research advances in hardware/materials it takes 20 years before it makes it out of the lab. By the time a fundamentally new invention is in mass-production its is off-patent. I know BellLabs invented the transistor and the laser, but I wonder what fraction of semiconductor and laser industry's profits actually went to BellLabs/AT&T. In contrast, software can be more self contained and follow a much faster adoption curve.
In summary, I would say that scientists and engineers already have a reasonably good handle on atoms and that the real R&D opportunities are in getting better with bits.
Slashdot Mirror
As wonderful as binary is, it falls utterly in capturing the fuzzy analog nature of life and the real world. Our recent debate on whether Sedna (or Pluto) is a planet is but one example of how the real world fails to fit into simple binary categories. Even at the subatomic level, the wave-particle duality gives lie to the fiction of discreteness.
I'm not saying that binary is not great for doing all manner of wonderfully powerful proofs, logic, and computation. I'm only saying that it is a mere approximation to the real world and can thus fail when the real world is does not dichotomize to fit into Boole's logic.
Boolean Logic illustrates both the tremendous power and weakness of mathematical systems. On the one hand the power of proof guarantees that man-made mathematical system with certain axioms will undeniably have certain properties. On the other hand, math gives one no guarantee that the real world obeys those axioms.
There is an entire branch of astronomy that uses distributed observations to map the size and shapes of asteroids using occultations (eclipses with distant stars). When an asteroid passes in front a distant star, the star winks out and then reappears. Knowing the duration (start and stop times) of the occultation, the location of the observer, and the orbits of the Erath and asteroid lets people estimate the size and shape of the asteroid. International Occultation and Timing Association collects data from telescopes around the world (many in the hands of hobbyists) and uses the data to make these estimates.
It seems that the ultimate system would use at least two wifi cards with a search and load-balancer. One card would provide a connection while the other card searches other bands for the next connection. If both cards find an AP, the load balancer would provide twice thee bandwidth. When the first connection weakens, the system would do a hand-off to the second card. It may disrupt continuity of some internet services, that assume IP continuity, but it would let a user be ultra mobile -- skipping from wifi cell to wifi cell with little perceived break in connectivity.
Its ironic that a mission to the fleet-footed god of messages should take so long. I guess its revenge by those ancient Roman gods.
I'm just glad that the mission was not scrubbed.
If the U.S. government were so terribly concerned by gambling, it would ban the stupidity tax (aka state-run lotteries). While I personally don't understand why people gamble, it seems hypocritical for the government to both give citizens the right to gamble on a large scale (at atrocious pay-off odds) and yet prohibit online gambling.
Its interesting that the price of a new console (PS2, XBox, etc.) is less than the price of a highest-end graphics card for a PC. Given that most people have old PCs, buying a console is the cheapest way to get into gaming. Add to that the comfort of a couch and big-screen TV vs. a desktop, I can see why many go for consoles.
DON'T use pdf for book distribution! Agreed! The problem with PDF is that it is based on page defintion -- defining exactly how to layout the letters. PDF has no conception fo words, sentence, paragraphs, headings, footnotes, etc. -- it all just a bunch of filled polylines sprinkled on a fixed-size rectangular space. PDF is totally incompatible with small screens. Its great for preserving the look of a page, but terrible for preserving the meaning.
If you want a universally readable light-weight format for text document, why not use HTML. If anything HTML is more widely used and readable than PDF. HTML can do a better job of semantically meaningful markup (H1 tags vs. Demi Futura Bold 28 Point) and has nice internal and multidocument navigation functions.
Thanks for your thoughtful reply. I suspect we agree, we only differ in how we measure "amount of software."
Consider an example. Assume that each company has 1 programmer and a 1000 employees, and there are 1000 companies, and each company programmer writes 50,000 lines of code. Then you have 50 million lines of written code scattered across the companies, and 50,000*1,000*1,000 = 50 billion person-code-lines of usage of those custom code lines. On the other hand, if SAP hires a 1,000 programmers, and each writes 50,000 lines (50 million lines in a massive application) and then SAP sells the application to 1000 companies with 1000 employees each, then we have 50,000,000*1000*1000 = 50 trillion person-code-lines of usage of those manufactured lines of code. In this example, we have a total of 2,000 programmers and a total of 100 million lines of code but the average employee is using only 50,000 lines of custom created code and 50,000,000 lines of manufactured code.
I'm only pointing out that most of the software used by any given person (it terms of lines of code) is manufactured software. In fact my understanding of why companies like SAP and Oracle are so successful is that its more cost effective to use manufactured software (with configuration) than it is to custom-create everything -- why reinvent the wheel.
In the manufacturing analogy, software engineers are like the engineers at a manufacturer -- they design once and the company replicates many. Big software companies attempt to invent the wheel once and then sell it many times -- a manufacturing model that seems increasingly popular. Yes, there is a service component to software (similarly there is a service component to manufactured goods in many B2B situations)
"Ease of use" - One law I've learned:
As software becomes 'smarter', the difficulty in using the software increases.
That is a very important and confounding point! The people that rail against the complexity of some categories of software (especially enterprise systems) have no appreciation for the complexity of the functionality required by these systems. Many applications are hard to use, in part, becuase the domain is hard.
My point is that bad design makes applications even harder to use and thus requires more support, maintenance etc.
Now that you mention this issue, it suggests another trend in software support. As the software becomes easier to use there is less need for technical support. But, as you correctly point out, the software tends to become more functional and complex in the domain. Thus, I suspect that helpdesk people will need to switch from being software experts (that solve IT problems) and becoming subject matter experts (that help users solve business problems).
So, after a massive effort of automating the installation and configuration process, those 5 pesky 5 minute questions went away...to be replaced by 20-45 minute questions on a variety of issues we never realized existed.
That's a funny story and very true, too. The question is: did total support labor drop and did total adoption and use increase? I'd wager that after that application became easy to install, more people used it and that support per user-hour-of-use actually dropped.
The BOMARC was a early ramjet-powered missle from 60s. You can see one in Dayton Ohio at the Wright-Patterson Air Forcebase Museum. One can walk up to the BOMARC and look up inside the ram jets which are nothing more than a hollow tube with a grid of fuel injection nozzles.
It would seem that the internet's anonymity, lack of authentication, and high-susceptibility to automation makes it easy for groups or issues to appear more poular and populous than they really are. There is no gaurantee that the "thousands" writing in support of some position aren't one person or even one non-U.S. citizen.
I wonder when some pressure group will use spammer's tricks (zombie machines and scripts that spew thousands of automated messages) to flood political forums, blogs, write-in campaigns etc.
I'm not saying that the internet is not a wonderous medium for publishing ideas and sharing insights into pressing issues, only that it represents a potentially corruptible, biased sample on popular opinion.
The two top arguments in the article for why software is a service were erroneous.
1. 19/20 jobs are for in-house programmers This ratio may be true, but the conclusion that most software is written at the point of use as a service is false. If that one-in-20 commercial software company programmer writes commercial code that that sells even one thousand copies, then commercial code becomes 1000/(1000+19) = 98.1% of the code instances in use.
Another way to look at this is to examine the code inside the average company server for the ratio of in-house versus chimerical code. You will find maybe 10 million lines of code in a commercial OS, millions of lines of code in commercial enterprise applications (e.g., SAP, Oracle, Exchange Server, etc.), and a comparative fraction of that in code written in-house (config files, business rule scripts, report generators, PERL scripts, custom applications, etc.). Look inside the average desktop and the ratio of in-house to commercial code is even more extreme.
2. Remainder bin software: This argument is partially tautological. People (and retailers) devalue discontinued items or items from defunct makers because of the often valid perception that the item (or maker) was discontinued for good cause. If something did not sell on the shelves and the maker goes bankrupt, there is probably a reason. I will grant that future value plays a role in buying software, but part of the discount for remaindered goods reflects the low present use value.
Enterprise Does Have a Service Component: I think part of the difference lies in the distinction between enterprise software and consumer software. Clearly, enterprise software requires much more configuration, maintenance, and support -- its much more service oriented. The Accentures, EDSs, and IBMs of the world have made a ton of money on service related to software and IT.
Consumer Won't/Don't Pay for Service: In contrast, consumer software is much more manufacturing driven. There is simply no way that a $49 retail piece of software can come with any service. Nor, judging by the income statements of software makers, do these makers provide much service. There is simply no room in a $49 price point to cover the costs of real on-going tech support. Even upgrades are hardly a service -- the upgrade price is software half or 2-3rds the full retail price and given that the software maker gets to keep a bigger cut by selling upgrades direct, upgrades are a massive profitable product sales.
I doubt consumers will move to a subscription model for software (see Microsoft's attempts to do this) and I doubt they would like a pay-as-you-go model either. Most people bitch anytime that have to buy service (fixing a car, hiring a plumber, etc.) because most people place a less-than-salary value on their own time while the cost of service is always a more-than-salary amount (to cover benefits, employers taxes, support costs, profit, etc.) Do-it-yourself retailers like Home Depot and AutoZone have gotten very rich on consumer's asymmetric valuation of service labor. Consumers only want free service and that means bundling service into the retail price of a saleable manufactured asset.
Rising Ease-of-Use == Less Service:But I even wonder about the service model in all kinds of software. I would further argue that as ease-of-use improves, the need for service drops. The more a piece of software "just works" the more it acts like a manufactured good.
Even in configuration-heavy enterprise software systems, better interfaces could reduce the amount of coding-labor required to configure, maintain , and support big enterprise systems. The move from all-in-house applications to commercial enterprise apps also reflects a move to manufactured software. And as the enterprise apps accumulate functionality (SAP has 27 different inventory management algorithms), it becomes harder to justify paying in-house programmers to write one-off application. Now I'm sure that enterprise system will continue to need lots of service, but I wonder if the amount of service (per function point) won't decline as the systems become more plug-n-play, point-n-click.
I wonder if HP and IBM will squeeze out service-only firms like Redhat and Novell as Linux improves in ease-of-use. If Linux becomes very easy to use, there will be less demand for service and support providers that configure and manage Linux systems -- users wil be able to configure and manage their own boxes. I'm sure there will stil be a role for systems integrators for big enterprise rollouts (which IBM and HP can do), but even there I'd bet that many companies will prefer to hire a few Linux techs to oversee these easy-to-use-boxes.
Perhaps profits-from-hardware will supplant profits-from-service as the OSS business model. Why buy support if the system is so easy-to-use that it does not need support? At the very least, service revenues will be inversely proportional to ease-of-use.
At 30 Frames/sec, a battery life of 10,000 pages is less than 6 minutes.
Its a "low power" technology only when slowly flipping through static pages. But for more active screen work, scrolling, its not going to have very good battery life -- even at 2 frames per second, its only going to get a hour and a half. Even animating the pointer will drain energy if done at too high a frame rate.
I expect that for PDA applications, this display wil be better than the current crappy generation battery-sucking machines, but not as good as the old Palms and Psions.
If (BIG IF, I know) this cuts down on spam to .ch addys, I wonder if safe-haven hosting services will spring up in Switzerland. I may not be able to get Swiss citizenship, but perhaps Swiss citizenship for my domain would help stem the tide of spam.
1. Professors are gods: All ideas come from them, even if you thought them up. Let the profs be the thought leaders and you will do OK.
2. Staff positions may be subject to the whimsy of grant-givers: Your position may be tied to long-term research grants or funding that can dry up.
3. Lots of smart people: Profs and grad students will, by and large, be smart and interesting. If you like thinking/talking about new ideas, you will have fun.
4. Slower pace: Universities don't operate on the same timescale as entrepeneural companies. "I need it soon" might mean "I need it next month."
5. YMMV: as with corporate life, specific situations or bosses might suck egregiously or be ludicrously enjoyable.
Good luck!
If they use the right encryption and safety measures, why won't that be secure?
There's no such thing as unhackable security, especially if you want cheap boxes that sit on all the thousands/millions of powerplants and distribution facilities in a big power grid. Sooner or later people will find a weakness in the software, firmware, or hardware of the little boxen on all those sensor and control nodes. Sooner or later a power company will fail to patch a hole (or it will take months to physically replace/patch defective hardware). Sooner or later, the keys to some part of the control net will get leaked or stolen. If the control and sensor boxes on are on the public net, they will become remotely hackable.
Just being connected to the net doesn't mean you're instantly going to get cracked. Look at microsoft.com - a server everyone and their dog wants to crack into
First, I doubt the power companies would or could replicate Microsoft's level of security (either in terms of money or skilled people). Regular corporations do get kacked all the time. Second, I'd bet Microsoft gets hacked too, but its not publically announced or even necessarily discovered.
The power distribution companies are just about the one group who really can afford to run private fibre. After all, they already HAVE cables connecting all the omportant sites, byu definition, and the technology to wrap a fibre around a power line is already well established.
Perhaps its a country-by-country issue. In the U.S., power transmission is a neglected, regulated industry -- its the people that generate the power, not the people that transmit the power, that make all the money. Transmission, at least in the U.S., is a commodity infrastructure and many regard it as underfunded.
But even if the power companies of some countries could afford their own fiber, why would they choose this? And if they do pay to install fiber, why wouldn't they lease unused capacity on this line? To the extent that they either choose the cheaper option (use other's fiber) or lease out their own fiber, they are insecure. Public packets and infrastructure control packets should not be corouted.
I would fear that a "new electricity net" would be less secure than the current control systems because the control nodes would inevitably be connected to the public internet with packets tunneled via a VPN to the central office. I don't see power companies laying their own independent fibers for connectivity. And even if they use their own BPL, there is a good chance the control nodes, sensor nodes, and ccentral office will be connected to what is a public-exposed BPL net. The cost efficiency of routing packets over the public net are just too tempting. Despite best efforts, I'm sure someone will figure a way to hack into the sensor nodes, control nodes, or the central office if it is connected to a public internet.
The current system is more secure (if unreliable and uncontrollable) because compromising it requires physical access.
I use plain Google (my wife uses Google advanced ) because its the most used page on the internet for us. I previously to use a customized Yahoo finance page (an Excite page before that) but they took too long to load.
With OSS, an intrusion, even a full bore compromise of the code base is more likely to be caught. I would hope that there are diligent OSS people that cross-compare their copies of the source to the CVS copies and look for disrepancies. A distributed analysis of all changes (including the officially sanctioned ones) would help uncover malicious code.
In contrast, the users of proprietary code have only the manufacturer's word on what changes occured, who made them, and what those changes do. We users have no easy way (short of reverse engineering the code deltas on the binaries) of determining what happened between version X and version X.1. The security of non-OSS code is in nontransparent hands and that makes it insecure.
Too many config files, control panels, etc. fail to adhere to the advice being given to NASA on this problem. If every programmer and software designer followed this advice, it would be impossible to misconfigure a computer or create a crash-prone system. Currently, its just too easy to mis-configure systems because the systems let the user enter improper/conflicting settings.
Perhaps when every config file has the equivalent of a "this side up" on all the fields and parameters, then we will have obtain the ease-of-use Holy Grail.
Although cool 3d interfaces are nice and do create a more intuitive user interface, the reasons that ease-of-use is so low (even on the Mac) is the problems of system configuration and the mismatch between command-oriented input systems (both GUI and CLI) versus goal-oriented users.
Better help systems (not wizards) and more explanatory error messages would go a long way to improving ease-of-use. If computers could explain WHY they can't perform some operation (rather than THAT they can't perform some operation), it would make them les frustrating to use.
It may not be glamorous, but translating all the system setups, command sets, and controls into something goal-oriented rather than technology oriented would be a major step toward ease-of-use (the average usuer should never need to know an acronym to configure their computer). This would mean contextual help that explains what to do in terms that reflect the goals of the user, not the minutae of the underlying technologies.
More eye-candy will not make the machines easier to use. Better user-centric documentation, configuration, and diagnostic messages will.
The biggest challenge to this type of tech is creating complex large-scale patterns. Its one thing to create a fully regular "crystal" of 1-bit memmory cells, its another to create the highly irregular, specific, chip-spanning structures of a CPU. If we are going to make complex nanocircuits, we need a way to ensure that the right bit gets connected to the left bit.
I wonder if 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)
BTW, my post is a modified dup of a previous post of mine, but I thought it might be relevant.
Nano technology is the future and silicon is going to run out soon in terms of how much smaller can you get the circuits
I agree 100% with you. Nanotechnology is the future. But that does not make it a wise R&D investment. Recall that Drexler wrote his Engines of Creation: The Coming Era of Nanotechnology back in 1986. Anybody who patented stuff in that book got nothing for it -- 1986 patents expired last year. Despite nearly 2 decades of additional effort, we still don't have commerical nanotechnology. Someday, people will make money on nanotechnology, but I bet it won't be the pioneers.
Universities have been researching mathmatical algorithms for decades.
Yes they have, but not the ones that might make a different in business. The academic world places too much emphasis on analytic tractability -- professors and scholoarly journals like to see nice theories with closed-form equations. But many real-world problems don't reduce to equations that are tractable for the purposes of getting a Ph.D. or tenure. Companies like SAP and i2 (and Wal-Mart for that matter) make billions of dollars on applied math that most academics wouldn't touch.
But the real argument is you can not patent numbers of formulas so its unprofitable in case they do discover the ultimate algorithm.
For better or worse, you can patent software. But even if you cannot patent the software, you can still make money on it. If you embed the software in proprietary hardware (like a Lucent firewall or switch), use it internally to run the company, or offer it as a service running on closely-held binaries, then you don't need a patent.
I was at conference at Bell Labs/Lucent not too long ago and I think part of what is happening is a natural shift in what matters in corporate research. I got the sense that Bell Labs was shifting slightly from its physics/hardware roots to math/algorithms/software future. They still do physics, but they also do proportionally more R&D in the idea/software space. (Disclaimer: I didn't see any budget figures or top secret stuff, so who knows what they really goes on in Murray Hill)
I'm not saying that we should stop R&D on hardware, solid state physics and materials, only that new software and software-related tools would help everyone get the most out of the current portfolio of hardware technologies. Given that we just discussed "Why Programming Still Stinks" and have not discussed "Why Hardware Still Stinks," I would suggest that the bigger research opportunites are in software.
I also suspect that software is more commercialization-friendly. If you look at research advances in hardware/materials it takes 20 years before it makes it out of the lab. By the time a fundamentally new invention is in mass-production its is off-patent. I know BellLabs invented the transistor and the laser, but I wonder what fraction of semiconductor and laser industry's profits actually went to BellLabs/AT&T. In contrast, software can be more self contained and follow a much faster adoption curve.
In summary, I would say that scientists and engineers already have a reasonably good handle on atoms and that the real R&D opportunities are in getting better with bits.