The problem is that importing Facebook "friends" to gmail requires you to get access to their email address.
No, the problem is that facebook hasn't allowed data portability so that whatever contact info your "friends" do share hasn't been available by 3rd parties (like Google).
...but the content providers, as has been discussed time and time again, have no clue about anything, for example, that it's been possible, even easy, to hook your computer up to your TV for years.
I think that content providers know that it's possible to hook your computer up to your TV. I think that they also know that most people do not have their computer hooked up to their TV. They are targeting the infrastructure of today. Once having your computer hooked up to your TV is the norm, the folks at Hulu (and the rest) will change course to address the changing market (though not nearly as quickly as we'd like them to).
I suspect that part of the reason is that Boxee doesn't support Windows yet... and I suspect that the majority of Hulu users are Windows users. Additionally, Hulu most likely wants (possibly needs, based on contracts) total control of their distribution channel.
I would think that it has more to do with the markets that the advertisers are paying to reach... if the advertisers are marketing a product that only exists in the USA, then allowing other countries access to the video doesn't make financial sense. I suspect that the technology will mature over time, and it will reach a point where they can insert local advertisements in to the video streams on the fly, and allow access to every geographic location they receive advertising dollars from... but, what do I know - I'm just an outsider guessing here.
Every company seems to have a different definition of what a "Network Manager" is responsible for, so "documenting a network" is too vague a phrase. Are you referring to network equipment only, all of your IT infrastructure, or some middle ground? Furthermore, depending on the size of your infrastructure, it may make sense to consolidate or further break down the bits in to larger or smaller chunks (adding more detail or diagram/document X, or breaking diagram/document X in to three smaller diagrams/documents.)
In my experience, the best documentation is accurate documentation. Since most IT operations are in a constant state of flux, your documentation repository will need to be updated frequently (and these updates will have to become part of your company's work-flow if your documentation has any chance of keeping up). I've seen many systems come and go, and strongly suggest that you adopt a wiki of some sort. If you choose one with a changelog (most have them these days), I suggest that you grant write access to everyone you grant read access to. (Frequently the consumers of the information can make important/useful updates - let them!)
1) Physical Inventory - manufacturer, make, model, location (rack/u)
2) Network Diagram - Your network diagrams should include all network infrastructure (communication lines, switches, routers, SLBs, etc.). If you are responsible for the servers and storage as well, then include them too. For each piece of equipment, include hostname(s), IP(s) and the high-level function (web/db,mail,etc.). I usually use Visio for this, but finding a wiki that supports network diagrams natively would be even better.
3) Service Notes - Make notes for each "service" available on the network.
>Big picture overview - what does this service do?
>How important is this service (think outage)?
>Who is responsible for this service?
>list of all machines that make up this service
>machine's role/sub-role/hostname/IP/console port/etc.
>include information about how to access (log in to) the machines
>(physical access, console access, network access)
>information about service dependencies, start/stop scripts, etc.
>include hardware type, OS, list of packages to install, config files, etc.
>notes about what is/should be monitored, and where to find logs/etc.
>how to test each service/sub-service
>include notes about required test accounts/etc.
>include information about common problems, planned upgrades, etc.
4) Passwords - There should be a physical copy locked in a safe somewhere, that a select few have access to. The specifics will depend on your organizational structure, but the post by christianT about sealing them in an envelope is right on track.
5) Escalation Procedures
-List of all services, and their associated priority, and escalation procedures
6) Disaster Recovery - whatever one needs to know to restore service in the event of a disaster
I'm sure that I forgot many things... this was just a quick brain-dump.
"God is a comedian playing to an audience too afraid to laugh." - Voltaire