I too agree with this. In fact, I think it should have been done 15 years ago. But I suspect that wireless solutions on the horizon will make the whole issue mute in a few years time.
And I would just add... when are these people going to realize that the "interactive TV" they have been envisioning for the past 20 years already exists. It's called the Web.
Suppose for a moment that you were responsible for creating some kind of commercial or enterprise database. For the sake of discussion, let's imagine that it's a database which tracks a retail company's inventory. So you've got various pieces of information to track for things like product name, number, description, quantity, location, ordering information, and so on.
If you were responsible for creating this database, would you create a single table with a single column and dump every piece of information into that field? Of course not, because then the data would be meaningless -- and useless.
Well guess what? The Web is just a massive distributed database -- and right now, every piece of data is indistinguishable from every other piece of data -- just like the above example.
The Semantic Web simply provides the constructs necessary to slice and dice the Web in meaningful ways. It will enable a whole new generation of tools... from super-accurate searching to data mining (as in the article example) to agent technology and AI.
I was about 3 1/2. My brother was still in the womb. Mom was sitting in a chair in the kitchen balling while dad paced around. I came out of my room and new that something was wrong.
One of the fundamental concepts in building mission critical networks is what is referred to as "A/B Diversity" -- also sometimes called "salt and peppering". The idea is that you build two or more physically and logically separate network infrastructures and distribute the user population evenly across them. Thus, when a catastrophic failure occurs in one of the network "domains", the other will continue to function and business can continue in "degraded" mode.
We have a long way to go before data networks reach the stability of, for example, the public telephone system. The modern reality is that these networks are susceptible to a host of trivial yet potentially catastrophic failure scenarios. Spanning Tree (STP) is a very unreliable protocol. If has the potential to fail under many conditions such as the presence of physical errors, very high load, or as a consequence of a bug in the OS of one or many network devices.
Broadcast storms will occur. ARP storms will occur. OS bugs will crop up. Facilities personnel will play jump rope with your cable plant.
These problems can be mitigated, but not eliminated, by good network design. Thus, in environments such as hospitals and banks, where the cost of network downtime is too great too bear, it is common practice to build one or several parallel infrastructures as I have described.
FUNNY NETWORK TRICKS
I used to be in charge of the NOC at a large investment bank in New York. One of our buildings had six floors each housing 1,000 equities traders -- and this was during the stock market boom. Network downtime was not tolerated during trading hours. Therefore, the building was divided into four separate network domains connected to each other, server farms, and the WAN/MAN environment via a layer-3 core.
-- One time a printer became wedged and proceeded to send out ARP requests at the rate of thousands per second. The flood of messages pegged the CPUs of the routers servicing that domain and brought network services to a halt. Time To Resolution: 20 minutes (proud to say) to deploy sniffer, identify offending host, and rip its cable out of the wall with extreme prejudice. % of building affected: 25.
-- Over the course of several months, the Novell/NT team progressively decommissioned Novell servers and replaced them with W2K servers. Unfortunately, nobody thought to turn off the Netware services in the roughly 1,000 printers deployed throughout the building. On one glorious day, the very last Netware server was decommissioned in a particular domain leaving the printers in that domain with no server to "attach" to. The resultant flood of SAP messages became so great that the Cisco routers could not service them in a timely manner and they became cached in memory. The routers would gradually run out of memory, spontaneously reboot, and repeat the cycle. Time To Resolution: ONE FULL DAY. % of building affected: 25. Number of hours spent in postmortem meetings: ~15.
-- On several occasions, Spanning Tree failed resulting in loss of network services for the affected domain. Time To Resolution: 15 minutes to identify problem and perform coordinated power cycle of Distribution switches. % of building affected: 25.
And the list of stories goes on. You get the point.
I'm no expert, but why didn't we slap this problem in the face long ago with digital certificates?
... here's my cert ... you trust the root CA. If I'm known to be a spammer, blacklist me ... bada boom!
I'm sending a piece of mail
Is it an implementation problem? Could authentication be implemented on top of the existing system and phased in?
Why the hell do all of these pop stars live in mansions in Beverly Hills. They must be making money *somehow*!!!
... and interviews, magazine covers (1M a pop) etc.
I too agree with this. In fact, I think it should have been done 15 years ago. But I suspect that wireless solutions on the horizon will make the whole issue mute in a few years time.
It might not be worth it at this point.
I agree 100%.
... when are these people going to realize that the "interactive TV" they have been envisioning for the past 20 years already exists. It's called the Web.
And I would just add
Suppose for a moment that you were responsible for creating some kind of commercial or enterprise database. For the sake of discussion, let's imagine that it's a database which tracks a retail company's inventory. So you've got various pieces of information to track for things like product name, number, description, quantity, location, ordering information, and so on.
... from super-accurate searching to data mining (as in the article example) to agent technology and AI.
If you were responsible for creating this database, would you create a single table with a single column and dump every piece of information into that field? Of course not, because then the data would be meaningless -- and useless.
Well guess what? The Web is just a massive distributed database -- and right now, every piece of data is indistinguishable from every other piece of data -- just like the above example.
The Semantic Web simply provides the constructs necessary to slice and dice the Web in meaningful ways. It will enable a whole new generation of tools
It's revolutionary. And it's coming.
I was about 3 1/2. My brother was still in the womb. Mom was sitting in a chair in the kitchen balling while dad paced around. I came out of my room and new that something was wrong.
Great first memory, huh?
One of the fundamental concepts in building mission critical networks is what is referred to as "A/B Diversity" -- also sometimes called "salt and peppering". The idea is that you build two or more physically and logically separate network infrastructures and distribute the user population evenly across them. Thus, when a catastrophic failure occurs in one of the network "domains", the other will continue to function and business can continue in "degraded" mode.
We have a long way to go before data networks reach the stability of, for example, the public telephone system. The modern reality is that these networks are susceptible to a host of trivial yet potentially catastrophic failure scenarios. Spanning Tree (STP) is a very unreliable protocol. If has the potential to fail under many conditions such as the presence of physical errors, very high load, or as a consequence of a bug in the OS of one or many network devices.
Broadcast storms will occur. ARP storms will occur. OS bugs will crop up. Facilities personnel will play jump rope with your cable plant.
These problems can be mitigated, but not eliminated, by good network design. Thus, in environments such as hospitals and banks, where the cost of network downtime is too great too bear, it is common practice to build one or several parallel infrastructures as I have described.
FUNNY NETWORK TRICKS
I used to be in charge of the NOC at a large investment bank in New York. One of our buildings had six floors each housing 1,000 equities traders -- and this was during the stock market boom. Network downtime was not tolerated during trading hours. Therefore, the building was divided into four separate network domains connected to each other, server farms, and the WAN/MAN environment via a layer-3 core.
-- One time a printer became wedged and proceeded to send out ARP requests at the rate of thousands per second. The flood of messages pegged the CPUs of the routers servicing that domain and brought network services to a halt. Time To Resolution: 20 minutes (proud to say) to deploy sniffer, identify offending host, and rip its cable out of the wall with extreme prejudice. % of building affected: 25.
-- Over the course of several months, the Novell/NT team progressively decommissioned Novell servers and replaced them with W2K servers. Unfortunately, nobody thought to turn off the Netware services in the roughly 1,000 printers deployed throughout the building. On one glorious day, the very last Netware server was decommissioned in a particular domain leaving the printers in that domain with no server to "attach" to. The resultant flood of SAP messages became so great that the Cisco routers could not service them in a timely manner and they became cached in memory. The routers would gradually run out of memory, spontaneously reboot, and repeat the cycle. Time To Resolution: ONE FULL DAY. % of building affected: 25. Number of hours spent in postmortem meetings: ~15.
-- On several occasions, Spanning Tree failed resulting in loss of network services for the affected domain. Time To Resolution: 15 minutes to identify problem and perform coordinated power cycle of Distribution switches. % of building affected: 25.
And the list of stories goes on. You get the point.