« July 2004 | Main | September 2004 »
August 31, 2004
How can society build software that lasts decades?
The following are only a few lines of excerpts from an extremely important argument about the "culture of design" surrounding software. It is a critical aspect of any effort to design "software that works the way society works," to cite the credo of the decentralized software architecture crowd.
It may have an important impact on how CommerceNet Labs refines its own mission, too...
In many human endeavors, we create infrastructure to support our lives which we then rely upon for a long period of time...By contrast, software has historically been built assuming that it will be replaced in the near future (remember the Y2K problem). Most developers observe the constant upgrading and replacement of software written before them and follow in those footsteps with their creations...
In accounting, common depreciation terms for software are 3 to 5 years; 10 at most. Contrast this to residential rental property which is depreciated over 27.5 years and water mains and brick walls which are depreciated over 60 years or more... I can go to city hall and find out the details of ownership relating to my house going back to when it was built in the late 1800's.
[Dan Bricklin] will call this software that forms a basis on which society and individuals build and run their lives "Societal Infrastructure Software". This is the software that keeps our societal records, controls and monitors our physical infrastructure (from traffic lights to generating plants), and directly provides necessary non-physical aspects of society such as connectivity.
What is needed is some hybrid combination of custom and prepackaged development that better meets the requirements of societal infrastructure software.
How should such development look? What is the "ecosystem" of entities that are needed to support it? Here are some thoughts:
* Funding for initial development should come from the users...* The projects need to be viewed as for more than one customer... Funding or cost-sharing "cooperatives" need to exist.
* The requirements for the project must be set by the users, not the developers. The long-term aspects of the life of the results must be very explicit...* ... Impediments such as intellectual property restrictions and "digital rights management" chokepoints must be avoided...
* The actual development may be done by business entities which are built around implementing such projects, and not around long-term upgrade revenue...
* The attributes of open source software need to be exploited. This includes the transparency of the source code and the availability for modification and customization... The availability of the source code, as well as the multi-customer targeting and other aspects, enables a market for the various services needed for support, maintenance, and training as well as connected and adjunct products.
* The development may be done in-house if that is appropriate, but in many cases there are legal advantages as well as structural for using independent entities..
* Unlike much of the discussion about open source, serendipitous volunteer labor must not be a major required element. A very purposeful ecosystem of workers, doing their normal scheduled work, needs to be established to ensure quality, compatibility, modifications, testing, security, etc... The health of the applications being performed by the software must not be dependent upon the hope that someone will be interested in it; like garbage collecting, sewer cleaning, and probate court judging, people must be paid.
The ecosystem of software development this envisions is different than that most common today. The details must be worked out. Certain entities that do not now exist need to be bootstrapped and perhaps subsidized. There must be a complete ecosystem, and as many aspects of a market economy as possible must be present.
Posted by rohit at 10:22 AM | Comments (0) | TrackBack
August 28, 2004
Subscribe Is The Foundation Of The Now Economy
Jeremy Zawodny sees a tipping point for feeds coming soon:
Real-time pings mean that we don't have to wait for a full polling or crawling cycle before getting the latest content... Once this feed stuff hits the tipping point (I think we're close), things will get really, really interesting. Suddenly these feed sources will be the thing people care about. The model of "search and find" or "browse and read" will turn into "search, find, and subscribe" for a growing segment of Internet users and it will really change how they deal with information on the web. What's that gonna be like? Will the "web search" folks be ready? What about the browser folks?
The ability for a person or program to subscribe (and then get told when things happen, and take action as needed) is the foundation of The Now Economy. RSS and Atom can provide semi-structured data on which to take action -- for example, for use in catablog-style commerce interactions.
Through John Battelle we discovered Rick Skrenta's post on the subject of information feeds. Says Skrenta, "The proliferation of incremental content sources, all pumping out new material on a regular basis, is what the mainstream Internet user will consume."
This in turn reminds us of Phil Windley's recent observation that subscription-based information routing (such as that of mod-pubsub and KnowNow) allows applications to receive such streams of semi-structured information and then do something with them (such as filtering, aggregating, displaying, further routing, or taking action based on rules).
Such programming models will be ripe for exploration in the coming years as the applications of The Now Economy are discovered, developed, and deployed.
Posted by adam at 12:07 PM | Comments (0) | TrackBack
August 27, 2004
75% don't have processes in place to take advantage of real-time info...
There are some great little infographics in the article quoted at length below. I found it in a binge of reading on Business Intelligence/Analytics, which yielded a few urls (del.icio.us anyone? ;-)
Great picture: http://www.insightful.com/products/iminer/Mortgage-screenshot_800pixe.gif
http://www.xmethods.net/ -- you should visit in general if you haven't already
http://www.sas.com/apps/whitepapers/whitepaper.jsp -- needs registration :-(
http://www.sas.com/solutions/sci/index.html -- supply chain intelligence
http://www.sas.com/industry/auto/warranty/index.html -- failure correlation
http://www.insightful.com/products/splus/unix.asp -- the company that sells S+ now
http://www.insightful.com/products/iminer/default.asp -- cleanup and merge
http://www.dmreview.com/portals/portal.cfm?topicId=230009 -- analytics articles (also needs reg :-(
http://www.informationbuilders.com/ -- customer highlights seemed interesting
When asked which method has proven more effective in achieving real-time operation in their companies, only 16% of the 52 business and technology executives surveyed by Optimize Research cited investments in new, specialized technology solutions, such as grid or utility computing, which enable more distributed, flexible computing.By comparison, nearly half of the respondents said the more effective method has been to increase the efficiencies of existing IT solutions. Another 19% said both methods have proven equally effective, and 17% said neither has been
effective....
But not many companies in the survey are doing much real-time monitoring or data collection. Executives were asked which processes or data types their company monitors in real time rather than by batch processes. The only response selected by a majority of the executives—58%—was Web site traffic/E-commerce activity. Fewer companies monitor real-time data on sales, customer interactions, inventory, customer shipments, output (products/services), and performance of individual software applications. Fewer than one-third collect information provided by business partners, data on incoming supplies, or product pricing information in real time. Only 19% of the executives rated their companies as extremely effective at monitoring real-time operations, while 75% said they were somewhat effective, and 6% not at all effective.
Companies that are collecting and acting on data in real time are seeing benefits. Aerospace manufacturer Lockheed Martin Corp. in Bethesda, Md., had been relying on a mostly manual process of gathering data from multiple legacy applications for the procurement of materials for certain products, says CIO Joseph Cleveland. The cycle time for gathering data and making a procurement decision took weeks, and sometimes months, he says. To speed up the process, Lockheed Martin deployed EAI software to integrate the multiple systems used for materials management. Because workers can access and act on relevant data more quickly, the same process now takes only days.
Posted by rohit at 02:19 PM | Comments (0) | TrackBack
August 26, 2004
This Blog = Google("Now Economy")
In only a few weeks this blog has become the #1 entry in Google search for Now Economy.
On the other hand, we're not even in the top 20 entries of Yahoo! search for Now Economy, though we are #2 in the Yahoo search for "Now Economy", and we are #1 in the AlltheWeb search for "Now Economy".
And, we're not even in the top 20 entries of MSN search for Now Economy, though we are #7 in the MSN search for "Now Economy".
The biggest hit for Now Economy that isn't us is this Line56 piece by Max More on the Now Economy, followed by the earliest reference we can find to the Now Economy (namely, the GBN report from January 2001). I did also find this FoRK article by Rohit Khare in March 2002 about the "Now Economy", as being pushed by McKinsey:
>it's time to say hello to the "now economy." Never heard of it?
>You're not alone. Even technology gurus sing different tunes when
>describing the newest buzzwords.I will continue to egotistically arrogate the neologism "now economy"
to myself and track its adoption :-)This is particularly cool to see in the McKinsey Quarterly. One of
the class act aspects of the firm is that they track down even people
who turn down a job offer and send out issues of the McK Q. Of
course, now, it's a lot cheaper favor that it's electronic...
Posted by adam at 02:57 PM | Comments (0) | TrackBack
Shopping Cart Services + PubSub Services
Internet News talks about Amazon's forthcoming release of Amazon Web Services 4, pointing out the utility of shopping cart web services:
The Amazon shopping cart in AWS 4.0 now permits application users to add items to the Amazon Save for Later cart. Shopping cart abandonment continues to be a major problem for the e-commerce industry. A recent DoubleClick study showed that 57 percent of all carts are abandoned by shoppers and only 26.5 percent of them will come back to actually make a purchase.
What might come in Amazon Web Services 5? Mod-pubsub speculates "PubSub Amazon Web Services", citing ZapThink senior analyst Jason Bloomberg:
Amazon Web Services 4 is still entirely request-reply in structure, which is adequate for supporting Web interfaces, but would not be sufficient or incorporating into more general business processes, or more broadly, into Service-Oriented Architectures, which require asynchronous Services.
Shopping Cart Services + PubSub Services = ?
Posted by adam at 08:33 AM | Comments (0) | TrackBack
August 25, 2004
UPC Database
Last night we stumbled on the Internet UPC Database, a hack that offers a public database of products and their Universal Product Codes. Anyone can submit new codes or search the database of codes. For example, here's Diet Cherry Coke. Even more interesting is that a Google search for Diet Cherry Coke's UPC number points you to the upcdatabase.com item. Which is even more astounding when you realize that the guy launched the service just seven months ago, and already has some extraordinary statistics:
Known Manufacturer Entries: 1058
UPC Entries: 805229
Distributable UPC Entries: 486416 (60.4%)
Unique Mfr ID's Represented: 44333
Average Items per Mfr ID: 18.2
Total size of database (approx.): 53.5 MB
Update Requests Pending: 139
Too bad there's no web service interface so we could start doing some interesting hacks...
Posted by adam at 12:55 PM | Comments (2) | TrackBack
August 24, 2004
The patchwork of medical privacy laws
The introduction to the paper below has a lengthy and illuminating rant about the pre-HIPAA patchwork of laws and regulations around medical records privacy. I'd definitely want to read the original NRC report...
Security Measures Required for HIPAA Privacy
Margret Amatayakul, RHIA, FHIMSSThe state of security in healthcare is no less diverse. In 1997, the National Research Council released a landmark work: For the Record: Protecting Electronic Health Information. This report of a field study revealed that healthcare organizations did very little to counter security threats. Although it could not document the actual volume of threats, it did identify mistakes, improper use of access privileges, unauthorized use for spite or profit, unauthorized physical intrusion, and technical break-in as not uncommon occurrences. Likewise, organizational and even simple technical mechanisms such as authentication, auditing, access controls, and cryptography were rarely in place. Most healthcare organizations relied on corporate culture and closed networks to protect the private information of their patients and providers.
Posted by rohit at 01:45 AM | Comments (0) | TrackBack
August 23, 2004
MD5 dead; SHA-1 on life support
Some new attacks against the commonly-used SHA-1 and MD5 secure hash algorithms were announced at a rump session at the Crypto 2004 conference on Tuesday, as well as some less-commonly used secure hash algorithms, including the original SHA (now called SHA-0 to avoid confusion), RIPEMD, HAVAL-128, and MD4. Although these attacks in their present form probably won't enable any system compromises, they have algorithm, protocol, and system designers looking around anxiously for alternatives.
As background, secure hash algorithms are intended to fulfill two requirements: first, that it be computationally infeasible to find two strings that hash to the same hash value ("collision-resistance"), and second, that it be computationally infeasible to find a string that hashes to a given hash value ("preimage-resistance"). Collision-resistance is clearly a stronger requirement, since you can construct a collision once you can find a preimage, but producing collisions does not necessarily imply that you can find a preimage for any given hash. Most systems don't depend strongly on the collision-resistance property. Even without finding a flaw in the algorithm, there's a property known as the birthday paradox that means that finding a collision by brute force takes a lot less work than finding a preimage by brute force.
None of the attacks provide a way to find a preimage for either SHA-1 or MD5, but collisions have been found for the first time in MD5, in a reduced-round version of SHA-1, and in SHA-0. I'm not sure whether collisions had previously been found in the other algorithms, but I don't think so.
It was just becoming possible to find an MD5 collision by brute force, and there was a $10 000 bounty for a successful collision and a project to find a collision and claim the bounty through massively parallel distributed computing. The attacks presented at Crypto 2004 require substantially less computational work than the brute-force attack used in this project.
It was also strongly suspected that there were weaknesses in SHA-0, and some weaker attacks had been found on MD4 and MD5 in the past, making the breakage of those algorithms somewhat unsurprising.
So the only algorithm left standing is SHA-1, and even it looks weak, and there isn't an obvious replacement, although Tiger, longer-hash versions of SHA-1, and AES-CBC have been suggested. Bruce Schneier has called upon the National Institute of Standards and Technology to initiate a search for a replacement algorithm, and Hal Finney thinks that at least the technique Joux used against SHA-0 could be used against a wide variety of secure hash functions.
The first version of the MD5 paper had some minor errors, which have been corrected in the current version (main page, PDF). Markku-Juhani O. Saarinen posted some thoughts and the extracted data files from the paper: 1, 2.
It's interesting that none of the three papers presented at this conference were presented by a citizen of the United States; the MD5 (etc.) paper was published by a Chinese team headed by Xiaoyun Wang, the attack on SHA-0 was presented by French cryptographer Arnold Joux, and the attack on SHA-1 was presented by Israeli cryptographers Biham and Chen.
Cryptographic research in the US has suffered somewhat from the Digital Millennium Copyright Act. For example, Ian Goldberg, a prominent cryptographer who worked at the University of California at Berkeley before the Digital Millennium Copyright Act was enacted, explains why he left the United States in his comments on proposals to tighten Canadian copyright restrictions:
On an individual note, I have personally been involved in the mess that is the US DMCA; some of my own work as a cryptographic researcher, as well as that of my colleagues, has come under question as to whether merely publishing an academic paper is a violation of its anticircumvention provisions. Canada has developed a strong cryptographic industry, partially as a result of a more restrictive US legal regime in this area, and this industry, as well as our high quality of research and education, would be directly threatened if DMCA-like provisions were introduced here. I will not live or work in a country that imposes such restrictions on scientific inquiry. We must not allow academic speech to be chilled, stifled, and censored by any person, group of people, or industry.
Other cryptographers in the US have also scaled back their research to avoid running afoul of the DMCA. Who can say whether one of these attacks would have been discovered by an American cryptographer in the absence of that law? Our national security depends in part on our ability to deploy cryptographic algorithms, such as secure hash functions, before the intelligence services of other nations find a way to crack them. The DMCA may therefore be putting our national security in peril if, for example, Israel's Mossad has progressed farther than Biham and Chen on cracking SHA-1.
(I took some other notes for this post.)
Posted by kragen at 01:21 PM | Comments (0) | TrackBack
August 21, 2004
DIY Industrial Design: "MyPod"
The Now Economy is a meme of many trends, not least of which is the import of mass customization and rapid prototyping's role in the manufacturing cycle. In the middle of this Slate article is an excellent example of this vision:
Made to Order - How industrial design became a weekend hobby. By Clive Thompson
Do-it-yourself design will get really interesting when inventors are able to sketch something out and then hold the thing in their hands within a matter of minutes. Today, rapid-prototyping technology—that is, 3-D printers that can instantly crank out a physical copy of anything you design on a computer—is available only to elite design firms. It'll get cheaper within years. Meanwhile, "original design manufacturing" companies overseas are becoming expert at quickly and cheaply cranking out MP3 players and laptops to specs set by brand-name firms like Virgin or Sony. Put those trends together, and it's easy to envision an offshore service that will take my personal design for a music player and crank out 10 copies. Presto: the Clive brand MP3 player! Think of it as vanity electronics—casemodding on a superfast, global scale.
Posted by rohit at 11:52 AM | Comments (0) | TrackBack
August 19, 2004
Solve Just Enough To Be Useful
A technology doesn't have to solve every problem. Just enough problems to be useful. Two examples come to mind which hammered this home to me; Tim Berners-Lee's World Wide Web and collaborative filtering which sites like Amazon use...If you read the descriptions of the Xanadu model you'll notice it has certain lofty goals. Some of these include the ability to create bi-directional links, links that do not break, and built-in version management. To me it doesn't seem feasible to implement all these features without ending up building a closed system. It seems Tim Berners-Lee came to a similar conclusion and greatly simplified Ted Nelson's dream thus making it feasible to implement and adopt on a global scale. Tim Berners-Lee's Web punts on all the hard problems. How does the system ensure that documents once placed on the Web are always retrievable? It doesn't. Instead you get 404 pages and broken links. How does the Web ensure that I can find all the pages that link to another page? It doesn't. Does the Web enable me to view old versions of a Web page and compare revisions of it side by side? Nope.
Despite these limitations Tim Berners-Lee's Web sparked a global information revolution. Even more interestingly over time various services have shown up online that have attempted to add the missing functionality of the Web such as The Internet Archive, Technorati and the Google Cache.
Here at CommerceNet we are grappling with the problem of solving just enough about decentralization to be useful in many commerce settings. More on that to follow in coming months...
Posted by adam at 12:14 PM | Comments (0) | TrackBack
August 18, 2004
The Marketplace Manager
Paul Ford wrote a compelling vision two years ago:
The Marketplace Manager, or MM, looked like a regular spreadsheet and allowed you to list information about yourself, what you wanted to sell, what you wanted to buy, and so forth. MM was essentially an “logical statement editor,” disguised as a spreadsheet. People entered their names, addresses, and other relevant information about themselves, then they entered what they were selling, and MM saved RDF-formatted files to the server of their choice - and sent a “ping” to Google which told the search engine to update their index.When it came out, the MM was a little bit magical. Let's say you wanted to sell a book. You entered “Book” in the category and MM queried the Open Product Taxonomy, then came back and asked you to identify whether it was a hardcover book, softcover, used, new, collectible, and so forth. The Open Product Taxonomy is a structured thesaurus, essentially, of product types, and it's quickly becoming the absolute standard for representing products for sale.
Then you enter an ISBN number from the back of the book, hit return, and the MM automatically fills in the author, copyright, number of pages, and a field for notes - it just queries a server for the RDF, gets it, chews it up, and gives it to you. If you were a small publishing house, you could list your catalog. If you had a first edition Grapes of Wrath you could describe it and give it a lowest acceptable price, and it'd appear in Google Auctions. Most of the smarts in the MM were actually on the server, as Google interpreted what was entered and adapted the spreadsheet around it. If you entered car, it asked for color. If you entered wine, it asked for vintage, vineyard, number of bottles. Then, when someone searched for 1998 Merlot, your bottle was high on the list.
Now imagine taking that vision -- and decentralizing it... that would assuage some of Paul Ford's fears:
See, I get worried about Google. They're beginning to control a space that is essential for open dissemination of information. So far they have only demonstrated excellent intentions, but the invisible hand of the market is quite a thing, and you often find it stuck right up your ass, or in your pocket looking for your wallet. Google is there to make money. There is nothing evil about that, but corporate money making is not necessarily in the people's interests, and even companies that appear to have great intentions are forced to make difficult decisions that ultimately screw the consumer. When companies have power - and Google is getting real power over the way that information is disseminated - they need to be watched carefully.Not that Google isn't sweet.
In some ways I wish there was an effort to create a P2P hugely-scaleable redundant spidering tool - exactly what Google has, but with a few million nodes on shared computers. Even better, if I could run an indexing algorithm against my own site, store the data locally, and report an overview (word list) via metadata - well, that would be snazzy, if a bit difficult to implement. Then, every relevant query via the P2P-based search mechanism could query my local server for full results...
I'm telling you, if you'd only listen, that spreadsheets are important to the future of the Internet. Not the gunky ones we have now, but super-futuristic ultra-spreadsheets. Say I wanted to sell my books, and put an ISBN number into a spreadsheet, and then applied a Semantic Web-based function. So I have ISBN 2884838483, and I enter item.book.isbn(2884838483) as the function. This goes out talks to the Library of Congress, which spits back a nice MARC record, and an XSLT script converts that an RDF descriptions according to the Open Products Hierarchy, and fills in title, author, publisher, number of pages, just like that in the spreadsheet. And each of those items can be related to other information, because there's a standard way to define data interchange (XML) and the actual structure of the data (RDF). Web-as-spreadsheet is fun to think about, I swear.
Posted by adam at 04:16 PM | Comments (0) | TrackBack
August 17, 2004
Agoric Systems Reading
This is all very old school - 1988! - but it's always refresing to take another look at the basics. While a survey paper from U. Florida says that the concept can be traced to Ivan Sutherland auctioning timesharing slots in 1968, the likely origin of the term "agoric systems" (from the greek agora, or market) is Mark S. Miller and K. Eric Drexler's chapter in The Ecology of Computation.
Like all systems involving goals, resources, and actions, computation can be viewed in economic terms. Computer science has moved from centralized toward increasingly decentralized models of control and action; use of market mechanisms would be a natural extension of this development. The ability of trade and price mechanisms to combine local decisions by diverse parties into globally effective behavior suggests their value for organizing computation in large systems.This paper examines markets as a model for computation and proposes a framework-agoric systems-for applying the power of market mechanisms to the software domain. It then explores the consequences of this model at a variety of levels. Initial market strategies are outlined which, if used by objects locally, lead to distributed resource allocation algorithms that encourage adaptive modification based on local knowledge. If used as the basis for large, distributed systems, open to the human market, agoric systems can serve as a software publishing and distribution marketplace providing strong incentives for the development of reusable software components. It is argued that such a system should give rise to increasingly intelligent behavior as an emergent property of interactions among software entities and people.
Posted by rohit at 10:03 AM | Comments (0) | TrackBack
August 16, 2004
Best Practices Trump Decentralization
Jon Udell wrote in Infoworld this week:
In the end, scalability isn’t an inherent property of programming languages, application servers, or even databases. It arises from the artful combination of ingredients into an effective solution. There’s no single recipe. No matter how mighty your database, for example, it can become a bottleneck when used inappropriately.It’s tempting to conclude that the decentralized, loosely coupled Web architecture is intrinsically scalable.
Not so. We’ve simply learned — and are still learning — how to mix those ingredients properly. Formats and protocols that people can read and write enhance scalability along the human axis. Caching and load-balancing techniques help us with bandwidth and availability.
But some kinds of problems will always require a different mix of ingredients. Microsoft has consolidated its internal business applications, for example, onto a single instance of SAP. In this case, the successful architecture is centralized and tightly coupled.
For any technology, the statement “X doesn’t scale” is a myth. The reality is that there are ways X can be made to scale and ways to screw up trying. Understanding the possibilities and avoiding the pitfalls requires experience that doesn’t (yet) come in a box.
Decentralization is not a hammer that can hit every nail. Experience is still the mother of good judgment.
Posted by adam at 02:38 PM | Comments (0) | TrackBack
August 13, 2004
Amazon CTO: "We've Just Scratched The Surface"
Sometime in the next few weeks, Amazon.com is scheduled to release Amazon Web Services 4.0, the next version of the electronic retailer's toolset for developing applications that tie into its Web site. It's the next step in Amazon's strategy is to create a "programmable" Web site. Over the past two years, 50,000 developers have downloaded earlier versions of Amazon Web Services. InformationWeek senior editor-at-large John Foley asked Al Vermeulen (pictured right), Amazon's chief technology officer, about how the model works.
The whole interview is great. I love this quote from Al Vermeulen:
There's a host of [services], probably 15 or 20, maybe more, and they range from components like personalization and search applications, to fulfillment applications, supply-chain services, and on and on. The basis is, let's think about everything we do at Amazon.com and about how we break it up into individual pieces, smaller pieces. What we try to do is break apart a piece of the business. From a technology point of view, that becomes a service. From an organizational point of view, it becomes an autonomous team with their own mission, and then we work on defining the interface to get to that service. We try to solidify that interface and make it permanent and robust. It's kind of a bottom-up, decentralized way of building your technology, as opposed to a top-down way where you try to make all the technology look like one piece.
It's very exciting to see where Amazon is going with this...
Posted by adam at 03:06 PM | Comments (0) | TrackBack
August 11, 2004
E-commerce turns 10
Alorie Gilbert of CNET writes:
in August 1994, online retailing was on the cusp of a breakthrough. Advances in Web security that year started the trickle that has become a significant chunk of the economy. But that didn't "solve" the problem of transaction security. Many data security battles are still being fought, against such foes as "phishing" and Trojan horse viruses.Despite these dangers, U.S. shoppers will spend $144 billion online this year, according to Forrester Research and Shop.org, a division of the National Retail Association for online merchants. That's 27 percent more than they spent online last year and 6.6 percent of total retail sales across the country, according to their joint study, released in May.
Though CommerceNet is not mentioned directly in the article, we are proud of the fact that we had a hand in 1994 in enabling early e-commerce efforts by bringing together the pioneers to create safe methods for collecting payments online. CommerceNet also celebrates our 10th anniversary this year.
Posted by adam at 04:36 PM | Comments (0)
August 10, 2004
Interplanetary IP -> Disruption-Tolerant Networking
There's a lot of great things going on with the continuing evolution of Interplanetary IP into IETF's Delay-Tolerant Networking group into a DARPA BAA on Disruption-Tolerant Networking (already closed on 9 July, unfortunately).
Proposers Day Announcement - Disruption Tolerant Networking (DTN)
The Disruption Tolerant Networking (DTN) Program will develop and field technology that will provide network services when no end-to-end path exists through the network. The primary goal is to provide disruption tolerance by organizing information flow into bundles. These bundles will be routed through an ?intelligent? DTN network that can manage the delivery of the bundles. This method will allow messages to pass through the network with successive responsibilities, rather than the traditional end-to-end acknowledgement scheme. DTN will result in the opportunistically leveraged connectivity and the use of multiple routes while relieving the delivery node of final acknowledgement.
The second goal of DTN is to provide dynamic network naming and routing. This method uses a late-binding of bundles (or packets) technique to specific nodes or delivery path. This avoids forcing all parts of the network to be aware of all other parts of the network. The result will be a network that matches the tactical unit deployment needs for mobility and stealth.
The Proposers' Day Workshop will be held on 21 January 2004 at the George Mason University
Posted by admin at 11:44 AM | Comments (0) | TrackBack
More on that Toyota fire
Toyota Manages Quick Recovery from Fire
Wall Street Journal
8 May 1997
Page A-1
by Valerie Reitman staff reporter
Toyota Motor Shows Its Mettle
After Fire Destroys Parts Plant
KARIYA, Japan -- No one knows what sparked the fire that roared through Aisin Seiki Co.'s Factory No. 1 here before dawn on Saturday, Feb. 1, leveling the huge auto-parts plant. But one thing is clear: The crisis-control efforts that followed it dramatically illustrate one reason Toyota Motor Corp. is among the world's most admired and feared manufacturers.
Wall Street Journal
8 May 1997
Page A-1
by Valerie Reitman staff reporter
Toyota Motor Shows Its Mettle
After Fire Destroys Parts Plant
KARIYA, Japan -- No one knows what sparked the fire that roared through Aisin Seiki Co.'s Factory No. 1 here before dawn on Saturday, Feb. 1, leveling the huge auto-parts plant. But one thing is clear: The crisis-control efforts that followed it dramatically illustrate one reason Toyota Motor Corp. is among the world's most admired and feared manufacturers.
The fire incinerated the main source of a crucial brake valve that Toyota buys from Aisin and uses in most of its cars. Most Toyota plants kept only a four-hour supply of the $5 valve; without it, Toyota had to shut down its 20 auto plants in Japan, which build 14,000 cars a day. Some experts thought Toyota couldn't recover for weeks.
But five days after the fire, its car factories started up again. Only recently have Toyota and its suppliers revealed how they did it.
Model of Cooperation
The secret lay in Toyota's close-knit family of parts suppliers. In the corporate equivalent of an Amish barn-raising, suppliers and local companies rushed to the rescue. Within hours, they had begun taking blueprints for the valve, improvising tooling systems and setting up makeshift production lines.
By the following Thursday, the 36 suppliers, aided by more than 150 other subcontractors, had nearly 50 separate lines producing small batches of the brake valve. In one case, a sewing-machine maker that had never made car parts spent about 500 man-hours refitting a milling machine to make just 40 valves a day.
"Toyota's quick recovery," says Yoshio Yunokawa, general manager of Toyoda Machine Works Ltd., a Toyota-group maker of machine tools and steering systems, "is attributable to the power of the group, which handled it without thinking about money or business contracts."
That is a common approach in Japan's keiretsu, the almost tribal groups of companies that supply and support behemoths such as Toyota. Japanese auto makers' blood pacts with their suppliers largely explain how they can slash their costs to the bone and stay globally competitive.
No Foreign Help Required
And the fealty the parts makers paid to Toyota during its crisis helps indicate why Japan's auto companies return the loyalty -- often to the detriment of U.S. and other foreign parts makers seeking market share here. Toyota and Aisin didn't bother to approach any foreign companies during the crisis, a Toyota spokesman says, because "there were no foreign suppliers in a position to help us."
Aisin (pronounced "eye-sheen") is an archetypal supplier in Toyota's group. Founded during World War II to make aircraft engines, it is based in Kariya, an industrial warren occupied by many other big Toyota suppliers. Toyota holds 23% of Aisin's stock. Aisin's president is Kanshiro Toyoda, scion of the Toyoda family that founded the auto maker.
Long a supplier of engine and brake parts, 80% of which it sells to Toyota, Aisin has won almost all of Toyota's contracts for brake-fluid-proportioning valves -- "P-valves" in industry parlance. The fist-sized valves control pressure on rear brakes and help prevent skidding.
For most parts, Toyota has at least two suppliers. But over the years, it turned to Aisin to produce all but 1% of its P-valves because of Aisin's high quality and low cost. The supplier shipped parts to Toyota plants under a just-in-time inventory system: several times a day, just enough valves for a few hours of production.
Calculated Risk
Depending on a single source and holding essentially no inventory is a calculated risk, concedes Kiyoshi Kinoshita, Toyota's general manager of production control. But it also is what keeps Toyota's production lean; Aisin gets major economies of scale that it passes on to Toyota in lower prices.
Toyota acknowledges that it didn't figure in the risk of fire. Aisin executives speculate that sparks from a broken drill bit may have ignited wooden platforms. Just after 4 that morning, flames swept through an air duct and ignited the roof. Graveyard-shift workers escaped as 36 fire engines arrived, mostly from nearby Toyota-group companies.
Even as the fire burned, Aisin officials organized a committee to assess the damage, notify customers and labor unions and, following Japanese custom, visit neighbors to apologize. A subcommittee ordered 320 cellular phones, 230 extra phone lines and several dozen sleeping bags for executives who were expected to live at headquarters in the coming days.
At 8 a.m., Aisin asked Toyota to help. Kosuke Ikebuchi, a Toyota senior managing director, was tracked down at a golf-course clubhouse; he left his wife there and rushed to Toyota headquarters to help set up a "war room" to direct the damage-control operation. Toyota quickly sent more than 400 engineers to Aisin. In reacting to such a crisis, Mr. Kinoshita says, "we're like the U.S. military."
When the last embers died just before 9 a.m., the damage at Factory No. 1 began to grow clear -- along with an apparent Achilles' heel in Toyota's lean corporate physique. Most of the factory's 506 highly specialized machines, which make other brake parts as well as P-valves, were charred and useless. Toyota estimated that more than two weeks would be needed just to restore a few milling machines to partial production, and six months to order new machines. That was too long: Auto plants were on overdrive to meet strong domestic demand and serve the brisk-selling U.S. market.
Moreover, a Toyota shutdown would damage local economies. Firms supplying the 20,000 parts in the average Toyota, along with hundreds of businesses such as utilities and trucking companies, would be hurt without Toyota orders. Each day Toyota is down, a state agency calculates, cuts Japan's annual industrial output by 0.1 percentage point.
Prospects for a quick comeback seemed to dim as the Saturday wore on. Toyota production officials were dismayed to learn they needed 200 P-valve variations. And chances that anyone else would quickly take up production looked distant: The valves have many complex tapered orifices that require highly customized jigs and drills. The production department told Toyota President Hiroshi Okuda, who was in the Middle East, that they would close most plants from Monday until at least Thursday -- the longest suspension in company history.
Hectic Scene
On Saturday afternoon, Toyota and Aisin summoned officials from some of the major parts suppliers to a second war room, at Aisin headquarters. It quickly became a hectic scene, with officials shouting out for copies of the blueprints of different P-valves while Toyota executives divvied up valve-making assignments, recalls Osamu Natsume, sales division head at Toyoda Machine Works. "It was chaos," he says.
Then the parts makers had to assemble the tools, dies, drills and other fixtures for machining systems that would normally take several months to perfect. "We had to work, no matter how hard," says Tetsuro Yamakage, production-engineering manager at Toyoda Machine. He immediately raced to find the 30 kinds of cutters, knives and special drills needed to make the valves.
But there still weren't enough suppliers. So Toyota purchasing officials called more parts makers to a Sunday-afternoon meeting. These officials, like those that had met on Saturday, were like family-people who work closely with Toyota from the start of a car's design. "It was crucial because we knew each other, we knew the face of the people," Mr. Ikebuchi says.
One familiar face was Masakazu Ishikawa, a former Toyota manager whose division had designed Toyota P-valves and who now is executive vice president of Somic Ishikawa Inc., a supplier of brake parts and suspension ball joints. Mr. Ishikawa called Somic's top production engineers from his cellular phone on the two-hour ride home from Aisin and asked them to meet at the office at 8 p.m. Sunday. They stayed there until after midnight to plot strategy: They would farm out some of their current factory work to free up machines to make the Toyota parts.
A New Undertaking
At 6 a.m. Monday, Somic's four designers began an eight-stage design process. "We'd literally never done anything like this before," says Isoo Suzuki, production-engineering director. Staying up 40 hours, Mr. Suzuki and his engineers designed jigs. Then they called in some chits from Somic's chain of suppliers. For example, Somic got a machine-tool maker, Meiko Machinery Co., to turn down other orders and put 30 workers on round-the-clock shifts to make the jigs it needed.
Somic drafted technical and administrative staffers to help man the machines. On Feb. 6, right on schedule, it delivered its first P-valves to Toyota.
So many suppliers were rushing to please Toyota that they sparked an unofficial race. Taiho Kogyo Co. would have been first, says Nobuo Fukuma, a vice president of the bearing maker, if it hadn't had to search nationwide for special machine tools. Taiho was forced to alter imported tools, he complains, because "the toolmakers didn't give us priority" and shipped to bigger parts makers instead. Although Taiho's first batch of 500 P-valves was ready on Thursday, less than a day behind two bigger Toyota affiliates, Mr. Fukuma was despondent. "We had wanted to be first," he says.
Adapting a Machine
Others were delighted just to have been called on. Brother Industries Ltd., which usually makes things like sewing and fax machines, got calls Sunday night from Aisin and Toyota. A sense of panic at Toyota had inspired it to go far afield, and Toyota knew Brother had a small machine-tools unit.
Brother cobbled together a P-valve production line by adapting a computerized milling machine that usually makes sewing-machine and typewriter parts. Each valve took Brother 10 minutes to make and five minutes to inspect -- hardly a cost-effective use of its resources. The firm helped out, says Yoshihiko Tsuzuki, a general manager, "because it was an emergency."
Early in the week after the fire, even Toyota's Mr. Ikebuchi had doubts about the goal of resuming production in all plants by Friday. But the supplier group came through. Trucks bearing the first 1,000 usable P-valves rolled in late Wednesday. On Thursday, 3,000 more arrived, and on Friday, 5,000. Slowly, Toyota's assembly lines started up again.
All told, Toyota lost production of 72,000 vehicles. But with overtime and extra shifts, Toyota officials say, it has already nearly recouped the lost output.
The Right System
The fire and its aftermath have left Toyota executives convinced that they have the right balance of efficiency and risk. "Many people say you might need to scatter production to different suppliers and plants, but then you have to think of the costs" of setting up expensive milling machines at each site, Mr. Ikebuchi says. "We relearned that our system works."
In fact, the fire may have made the system even more efficient. Nisshin Kogyo Co., which was making the other 1% of Toyota's P-valves, says that during the crisis it raised production efficiency 30% by speeding up production.
Mr. Kinoshita says the fire spurred Toyota to begin an effort to trim the number of its parts variations, a project that should eventually cut costs. And sole-source suppliers are moving quickly to build fail-safe mechanisms. Somic, which makes all of Toyota's steering linkages, is revamping its system so it can easily shift to another site if disaster strikes.
Suppliers never asked Toyota or Aisin what they would be paid for rushing out the valves, says Somic's Mr. Ishikawa. "We trusted them."
Indeed, as the first valves arrived at Toyota factories, Aisin told the suppliers it would pay for everything, from drills and overtime pay to lost revenue and depreciation. And Toyota promised the suppliers a bonus totaling about $100 million "as a token of our appreciation," says Mr. Okuda, its president. He adds that the auto maker will certainly remember the companies that pitched in during its crisis.
Posted by admin at 09:45 AM | Comments (0) | TrackBack
Get Ready For e-Medicine
From the August 9 issue of Newsweek:
When Anne Perlman, 50, needs to see her doctor at the Palo Alto Medical Foundation (PAMF) in California, she schedules her appointment online. Prescriptions zip through the ether from her physician to her pharmacy. Test results go into her electronic medical records. (Once she even got a lab test back on a Sunday—"very cool," she says.) And Perlman can log on any time to take stock of her health: Did her cholesterol go down this year? When was her last tetanus shot? For Perlman, the business of medicine is ... get this ... "a pleasurable experience."If you're one of the millions of Americans still in the medical dark ages, take heart: e-medicine may be coming your way soon. In July, the government launched a bold plan to get doctors and patients wired over the next 10 years. To encourage participation, officials are looking for ways to reduce costs and ensure software compatibility nationwide. The goal: a vast electronic network, where records can be securely viewed by any doctor or ER you visit. There's more at stake than convenience. Electronic medical records could save $140 billion annually and slash medical errors, which contribute to tens of thousands of deaths a year. "It's the right thing to do, it's the right time," says Health and Human Services Secretary Tommy Thompson. "We have to transform the practice of medicine."
Paperless medicine means you'll be able to go from your GP to your cardiologist—or to a new doc-tor in another state—without having to cart around old records. Your physician, privy to your complete history, will no longer need to rely on you for medical details; you may just walk away with a more accurate diagnosis. Computers will send reminders about vaccines or alerts about dangerous drug interactions. Electronic prescriptions will reduce errors caused by bad handwriting. And for non-urgent matters, you and your doctor will be able to communicate through a secure messaging system, saving time and a lot of frustration.
Electronic medicine won't happen overnight, but you can start managing your health today. Begin by asking your doctors for a copy of your medical records. Web sites like WebMD offer programs where you can store and organize information (healthmanager.webmd.com). And electronic gizmos, such as Med-InfoChip, allow you to download your medical profile onto a computerized key chain (med-infochip.com). But keep in mind that federal law, which protects the privacy of electronic records in doctors' offices and hospitals, doesn't apply to private companies. Read online policies carefully: the company could share your personal health information with a third party. Even if a site looks secure, buyer beware: "A commercial dot-com can promise you privacy, but what if somebody buys it or it goes bankrupt?" says Dr. Paul Tang, who launched PAMF's electronic system. "Your privacy is more protected by your physician."
The buzz around the National Healthcare Information Infrastructure is starting to feel like the buzz around the National Information Infrastructure initiatives from ten years ago...
Posted by admin at 08:56 AM | Comments (0) | TrackBack
Target's Doing RFID, Too
Everyone mentions "RFID" and "Wal-Mart" in the same breath. For the record, Target met with its suppliers to start the process on its first RFID pilots as well.
Requirements identified to date include applying RFID tags to cartons and pallets shipped to regional distribution centers and using 96-bit tags based on EPCglobal standards. An EPCglobal logo is required on cartons and pallets, all current markings and bar codes for pallets and cartons will continue to be applied, and EDI ship notice manifests will still be required.
Posted by admin at 06:37 AM | Comments (0) | TrackBack
August 09, 2004
Some conferences to keep track of...
The 14th International World Wide Web Conference 2005 May '05, paper deadline of 11/28
SIGSOFT 2004/FSE-12 Home Page Oct 31 - Nov 5
2004 Workshop on Self-Managing Systems (WOSS04) Home Page
An increasingly important requirement for software-based systems is the ability to adapt themselves at run time to handle such things as resource variability, changing user needs, and system faults. In the past, systems that supported self-management were rare, confined mostly to domains like telecommunications switches or deep space control software, where taking a system down for upgrades was not an option, and where human intervention was not always feasible. However, today more and more systems have this requirement, including e-commerce systems and mobile embedded systems.
Posted by admin at 08:32 PM | Comments (0) | TrackBack
Slate on 'Decentralized Intelligence'
I found this a captivating read, though it's about risk management and problem solving, not decentralization of power per se. The vivid lessons excerpted in the full entry are a reminder that complete risk analysis is impossible, so the only sure strategy is containment.
We don't do that often enough in software -- tracing how errors propagate as ever-longer chains of legacy software are automated together...
When organizations fail, our first reaction is typically to fall into "control mode": One person, or at most a small, coherent group of people, should decide what the current goals of the organization are, and everyone else should then efficiently and effectively execute those goals. Intuitively, control mode sounds like nothing so much as common sense. It fits perfectly with our deeply rooted notions of cause and effect ("I order, you deliver"), so it feels good philosophically. It also satisfies our desire to have someone made accountable for everything that happens, so it feels good morally as well.But when a failure is one of imagination, creativity, or coordination—all major shortcomings of the various intelligence branches in recent years—introducing additional control, whether by tightening protocols or adding new layers of oversight, can serve only to make the problem worse...
In 1997, the Toyota group suffered what seemed like a catastrophic failure in its production system when a key factory—the sole source of a particular kind of valve essential to the braking systems of all Toyota vehicles—burned to the ground overnight...
How does one rapidly regenerate large quantities of a complex component, in several different varieties, without any specialized tools, gauges, and manufacturing lines (almost all of which were lost), with barely any relevant experience (the company that made them was highly specialized), with very little direction from the original company (which was quickly overwhelmed), and without compromising any of their other production tasks?...
the response was a bewildering display of truly decentralized problem solving: More than 200 companies reorganized themselves and each other to develop at least six entirely different production processes, each using different tools, different engineering approaches, and different organizational arrangements. Virtually every aspect of the recovery effort had to be designed and executed on the fly, with engineers and managers sharing their successes and failures alike across departmental boundaries, and even between firms that in normal times would be direct competitors.
Within three days, production of the critical valves was in full swing, and within a week, production levels had regained their pre-disaster levels. The kind of coordination this activity required had not been consciously designed, nor could it have been developed in the drastically short time frame required. The surprising fact was that it was already there, lying dormant in the network of informal relations that had been built up between the firms through years of cooperation and information sharing over routine problem-solving tasks. No one could have predicted precisely how this network would come in handy for this particular problem, but they didn't need to—by giving individual workers fast access to information and resources as they discovered their need for them, the network did its job anyway.
Perhaps the most striking example of informal knowledge helping to solve what would appear to be a purely technical problem occurred in a particular company that lost all its personnel associated with maintaining its data storage systems. The data itself had been preserved in remote backup servers but could not be retrieved because not one person who knew the passwords had survived. The solution to this potentially devastating (and completely unforeseeable) combination of circumstances was astonishing, not because it required any technical wizardry or imposing leadership, but because it did not. To access the database, a group of the remaining employees gathered together, and in what must have been an unbearably wrenching session, recalled everything they knew about their colleagues: the names of their children; where they went on holidays; what foods they liked; even their personal idiosyncrasies. And they managed to guess the passwords. The knowledge of seemingly trivial factoids about a co-worker, gleaned from company picnics or around the water cooler, is not the sort of data one can feed into a risk-management algorithm, or even collate into a database—in fact, it is so banal that no one would have thought to record it, even if they could. Yet it turned out to be the most critical component in that firm's stunning return to trading only three days after the towers fell.
So, how does one make this kind of magic happen? Unfortunately, no one is quite sure.
Posted by admin at 07:17 PM | Comments (0) | TrackBack
August 05, 2004
Some Decentralization papers for the day
I know it's a little rude to just post links and little more, but I at least wanted to note four papers I came across today. The first is pretty fanciful, but I think it actually speaks to a real set of problems for programming "mass quantities" of computing devices: Spray Computers: Frontiers of Self-Organization for Pervasive Computing Marco Mamei, Franco Zambonelli Dipartimento di Scienze...
Abstract: We envision a future in which clouds of microcomputers can be sprayed in an environment to provide, by spontaneously networking with each other, an endlessly range of futuristic applications. However, beside the vision, spraying may also act as a powerful metaphor for a range of other scenarios that are already under formation, from ad-hoc networks of embedded and mobile devices to worldwide distributed computing.
The 2003 Blackout - Reference and Analysis from the Kennedy School of Government, particularly pointing to the US-Canada Power System Outage Task Force. Final Report on the August 14, 2003 Blackout in the United States and Canada: Causes and Recommendations.
April 2004. 238 pages.
These last two seem like important theoretical contributions, regarding heirarchical composability of policies in coalitions. I really ought to come back to this and write more soon...
Flexible Regulation of Distributed Coalitions - Ao, Minsky
Developing Multiagent Systems: The Gaia Methodology - Zambonelli, Jennings, Wooldridge
Posted by admin at 09:37 PM | Comments (0) | TrackBack
August 04, 2004
Dvorak Disrupts 'Disruptive' Tech Label
I loved this piece. I fell into it from a link to Dvorak's 10 best and worst laptops of all time in Good Morning Silicon Valley. It triggered a bit of melancholy refelection that very, very few of the folks in the field today even remember the 80s, much less the 70s -- the installed base always rounds to zero in a growing market :-(
Basically, it reminds us that the root of all productivity growth is in new ideas -- the perspiration comes later, too, and it is 99% of the effort, but all the same, society needs big new ideas to grow.
The Myth of Disruptive Technology
The microcomputer was never a "less expensive" and "inferior" replacement for minicomputers. It was a more expensive and superior replacement for calculators and slide rules. It was never used "instead of" a minicomputer (or mainframe for that matter) but "in addition to."In the Harvard Business School alumni bulletin highlighting this nonsense, there is a list of supposedly disruptive technologies. Not one is disruptive. At the top of the list are electric cars supplanting gasoline vehicles. On what planet? Internet sales supplanting bookstores. Hmm, Barnes & Noble is packed with people. Restaurants are being affected by the disruptive technology of grocers' takeout. Are you laughing yet? Motorcycles being affected by the disruptive technology of dirt bikes—does anyone see a pattern here? Is this an April Fools' gag?
James Burke's marvelous PBS TV series Connections offers a better explanation for disruption. When there is true disruption, it comes from inventions, regulatory and social change, complementary technologies, coincidence, and demand.
The closest Christensen comes to a real disruptive technology is digital photography. But it was invented in 1972 and has never been "cheaper" than film. The atom bomb is surely disruptive, but neither cheaper nor inferior. The car replaced the horse, but it costs more, and it became a success because of the invention of pavement and the pneumatic tire; asphalt was never cheaper than or inferior to dirt.
There is no such thing as a disruptive technology. There are inventions and new ideas, many of which fail while others succeed. That's it. This concept only services venture capitalists who need a new term for the PowerPoint show to sucker investors.
Posted by admin at 08:19 PM | TrackBack
August 03, 2004
Defcon 12 Trip Report
Adam and I just got back from a few days in Las Vegas to see the (astonishingly young!) face of the computer security, ahem, 'adversary' community at the 12th annual DEFCON. We found several useful sessions on the fringes of electronic commerce ('real-time penetration of credit card networks', 'the farmer's market model of pseudonymous dealing', debates about the broadcast flag and other DRM), as well as several object lessons in how insecure today's economy already is -- from Googling up lists of cc#s to seeing a CommerceNet mail password compromised on the spot (hint: let's turn on IMAP over SSL already! ;-)
The best technical content is actually released a few days earlier, at the more "official" Black Hat briefings. The best single presentation I attended was the release of a practical toolkit for SSH-over-DNS. That's right, DNS name lookup queries form perfectly useful covert channels to send and receive data through all manner of firewalls. And it's that way by design: the whole point is that DNS provides a way to invoke a small RPC at the remote end, namely lookup("symbol"). An even better hack that takes further advantage of DNS's caching semantics is 'DNS Radio' -- audio streaming! For more info, see NomDe (either as in 'Plume' or 'Guerre,' your pick :-).
Another warning that decentralized systems require tracking the conflicting interests of external agencies: not every other computer on the network is necessarily 'helpful' when it answers back!
A sign of how paranoid they were about not keeping records: Defcon 12 FAQs
$80 USD covers the entire 3 days of the conference
Cash only. Absolutely no checks, credit cards, money orders, traveler's checks or foreign currency will be accepted. There is no on-line pre-registration. Everyone must register on-site.
By far the most intriguing single session was hearing about the state of post-9/11 computer security investigation priorities from the horse's, well, choose the equine body part of your choice: DEFCON 12: Feds Yes, Anarchy No.
DEFCON 12's de facto guest of honor was Robert Morris, National Security Agency’s Chief Scientist from 1986 to 1994. With his scraggly beard and unfiltered Camels, Morris would have blended in well with the retirees pumping quarters in the slot machines over at Sam’s Town. Morris was quite happy wandering about talking to the gawking youth and dropping hints that he didn’t really like John Ashcroft.Morris was one of a group of current and former U.S. government employees that appeared on the “Meet the Fed” panel on Saturday afternoon. It was the first time in several years Feds had officially spoken at DEFCON and the panelists used the first half of their presentation as an ad hoc recruiting pitch. Uncle Sam wants talented and clean (i.e. no arrests or documented bad behavior) computer security people. "You can get up to 70 or 75 percent of your students loans forgiven," repeated one official. The U.S. government has a large number of open computer sec positions to fill and has a tough time retaining employees. Entry-level employees join up, learn the ropes, and then end up departing 3 to 4 years later for more lucrative private sector positions.
Another lesson we learned: far too many businesses have decided to place WiFi networks between point-of-sale machines that take credit card information, and the gateways or front-end-processors that do the credit card auth, so hackers discovering sensitive stuff on wireless networks is going to become an ever-more-common occurrence. It's not that WiFi is any less secure than a wire; rather, because accessing open wireless networks is a lot easier than cracking a physical line, these kinds of cracks become a lot easier. The fact that most Internet applications still don't use encryption on the wire makes such systems more vulnerable in the environment where anyone can access what gets sent over the air.
Posted by admin at 08:05 PM | Comments (0) | TrackBack
NYSE prices update at no more than 0.25 Hz (!)
Latency matters -- and embedded within this little trick forced by Reg NMS, is an agency conflict to boot: who's really motivated to give me, the little guy, the best possible price??
NYSE To Further Upgrade Automated Execution System
The New York Stock Exchange next week will unveil a plan for further upgrading its automated execution system, Direct Plus, to enable more trades to be processed electronically. Earlier this year, the NYSE upgraded the system to handle orders of any size and to let investors use the system as often and as rapidly as they like; previously, Direct Plus was restricted to order sizes of less than 1,100 shares and investors had to wait 30 seconds before entering another order.
Thain proposes new electronic trading for NYSE
The NYSE plan is an effort to meet an SEC definition of "fast market" under trading rules proposed in February. That SEC definition would allow the NYSE to keep a large portion of its order flow. But the move to electronic trading will move business away from the floor. Friday was the deadline for comments on the watchdog agency's Regulation NMS, or national market system.
Today's Trade-Through Rule Must Die
The trade-through rule, which was first instituted in 1975, was designed to make sure investors got the best available price for their stock trade. A market system would not allow one customer to "trade through" an existing order without first matching that order. A customer's order has to be routed to the destination with the best price at the moment the order is entered.That sounds like a good idea on the surface, but the rule was enacted before electronic markets existed. Though it's moving in the direction of automation, the NYSE is still at heart a manual system, with trades handled by specialists in particular stocks.
Nasdaq, however, is fully automated, so while a quote on a Nasdaq stock is currently executable, a quote on an NYSE stock is considered an indication and not a firm quote.
The trade-through rule as it stands means that if you place an order and the best possible quote is with a particular specialist on the floor of the NYSE, then your broker is required to route your order there. But a NYSE quote is not immediately executable–it's more analogous to an advertised price than an actual price.
Specialists are allowed to hold an order for 30 seconds before either executing it or handing it off to another specialist—and during that time, the price may change.
Posted by admin at 08:03 PM | TrackBack
Tagging Pharmaceuticals
Project Jumpstart, discussed in this article, is an effort by major pharmaceutical manufacturers to test item-level RFID tagging of drugs as an anti-counterfeiting/theft strategy.A stat from the above Information Week article: "The pharmaceutical industry estimates that between 2% and 7% of all drugs sold globally are counterfeit. Earlier this year the Food and Drug Administration issued a report recommending that drugmakers use RFID on bottles of the most commonly counterfeited drugs starting in 2006 and on bottles of most drugs by 2007."In considering the surveillance issues, drugs are certainly a sensitive issue; on the other hand, it would be easy to "shed" the tags, as an end consumer. My question would be more toward the claims for anti-counterfeiting. Given that the means of detecting counterfeits won't be through detecting a counterfeit tag -- tags are easily copied -- but in assessing the object's claimed pedigree, it just seems too complex to work all that well. Any number of insiders could probably compromise such schemes fairly easily, for example; until and unless RFID reading throughout supply chains becomes highly pervasive, a great many products will sport pretty sparse pedigrees as it is.
Posted by admin at 09:49 AM | Comments (0) | TrackBack
August 02, 2004
Amazon rolls out their version
What is a Plog?
The Plog™ Service provides a personalized blog for each Amazon.com customer. A blog is a straightforward and now widely adopted method of posting a reverse chronological diary on the Internet. Here's a list of some of the best and most popular blogs:
Boing Boing--A directory of wonderful things
Gizmodo--Reviews and charts the latest gadget trends
MobileWhack--Energetic discussions of mobile technology
Megnut--Evolving communication through blogging since 1999
John Robb's Weblog--Thriving on rapid change
Jeremy Zawodny's blog--Daily ramblings on life and technology
www.lileks.com--The Institute of Official Cheer
Gina Smith's BIOTECH--Tech/biotech journalist and author
defective yeti--The musings of Matthew Baldwin, Pretty Okay Guy
InstaPundit.com--The Blogfather
Talking Points Memo by joshua micah marshall--A thoughtful contemplation of current affairs
andrewsullivan.com--A respected intellectual columnist blogger
Intel Dump--Near-real-time military analysis
Daily Kos--Political analysis and other daily rants on the state of the nation
Six Apart--Six Log is the weblog of Six Apart, the company behind TypePad and Movable Type
Your Amazon.com Plog is a diary of events that will enhance your shopping experience, helping you discover products that have just been released, track changes to your orders, and many other things. Just like a blog, your Plog is sorted in reverse chronological order. When we think we have something interesting or important to tell you, we'll post it to your Plog.
Go to the Plog panel in Your Account to change Plog settings.
E-mail plog-feedback@amazon.com to share your thoughts and suggestions on this feature. We'll read everything you send, although we cannot promise an individual response.
Posted by admin at 06:03 PM | Comments (0) | TrackBack
Your Medical History On A Microchip
Laura Landro's Informed Patient article in the Wall Street Journal on July 27, 2004:
The idea is to put together records that patients control and manageStep by step the National Health Information Infrastructure will get built.
themselves, collecting data from different providers and sharing it as
they see fit. Consumers surveyed by the group Connecting for Health
became receptive to the idea of electronic medical records after
viewing an ad showing a man falling from a ladder with the caption
"You have three seconds to remember every doctor you've ever seen,
every procedure you've ever undergone and every medicine you've ever
taken." In addition to recording vital information such as next-of-kin
contacts and lists of allergies, patients could use the records to
track their own immunizations and note any mistakes in their doctor's
records.
Posted by admin at 01:26 PM | Comments (0) | TrackBack
RFDump
Anders at RFID Buzz notes:
German security consultant Lukas Grunwald has released a tool he names RFDump, that can be used to read, and apparently in some contexts, change the contents of an RFID tag. Handy for discounting your purchases, you'd think, but as far as I can see, this would only apply to read/writable tags (and here possibly actually containing the price information), as opposed to read-only "serial number"-style tags.Serial number / product code tags would generally be used by a business to identify the item; the price would then be looked up from a pricing database; changing this price would require more traditional hacking, unrelated to RFID. Furthermore, generally one would also assume full scale consumer implementations to have a certain level of encryption in place.
Still, his point is proven, and businesses implementing RFID in their supply chain should not ignore the abilities of black hat hackers.
See also Forbes.com, A Hacker's Guide to RFID.
Posted by admin at 01:01 PM | Comments (0) | TrackBack
SOAP or HTTP as the basis for TP
Mark Baker responds to Rohit's Teepee post:
Depending upon your POV, TP could either be PEP/SOAP (or similar), or HTTP itself. mod-pubsub probably best reflects the latter position, but I could see value in the former.I'm not sure that there's much in the way of a significant architectural difference between the two, but the latter would be a more useful self-contained package; a personal server, I reckon...
Oh, and parameterized topics! Woot! I think that's just an optimization, but an important one...
Note how routing messages to you via email doesn't work, but routing blog comments to an initial message of yours does? There's a lesson there, somewhere.
TP will likely have both PEP/SOAP and HTTP gateways that
canonicalize the messages being sent so they can be output in either
format as well. SMTP is likely another important gateway interface.
The key arhitectural question we will likely pursue is: how to
make the TP protocol itself as simple as possible, but no simpler.
Parameterized topics? Hmmm... topics seem so gossamer sometimes
that it's hard not to see them as just another name/value pair
attached to a message.
Posted by admin at 12:01 PM | Comments (0) | TrackBack