Here is my suggestion: follow a model similar to Nvidia. Allow the manufacturer / carrier to customize however they see fit, but require them to allow the reference build to be installed. Then, the people who don't care about it get what their manufacturer / carrier feed to them. Those who wish to customize/tweak can flash the same reference build that the manufacturer would be basing their own customized build on.

A big part of the problem is they way Apple chose to implement certain parts of ActiveSync. When comparing connections from iDevices versus Android or WinMo phones, you will see a disproportionate number of connections (and bandwidth) coming from iDevices compared to the Android/WinMo device. Poor mailbox management (especially if Exchange restrictions are loose) on the user side makes this problem even more noticeable.

We once watched event logs pouring with errors caused by an iPhone of a user who had let his password expire and hadn't yet updated it on his phone. We were seeing between 4 and 8 failed logon attempts every second. Granted, this was a few versions of iOS ago, so I'm sure that particular problem has been fixed by now. Apple's implementation is still highly taxing on Exchange servers compared to other devices.

The real problem is that someone failed to plan adequately for this rollout. Either IT didn't appropriately calculate the load required to add the new devices (along with their inherent inefficiencies), or they did calculate it, and someone overlooked or ignored it.

As long as you have a new enough version of IOS, they will support Dyndns.
http://www.cisco.com/en/US/docs/ios/12_3/12_3y/12_3ya8/gt_ddns.html

I have a Cisco 3640 at home that takes care of my Dyndns for me with no issues.

More like revoking a SSL certificate. Except most employers don't actually check the revocation lists.

Even if the "right" candidate is elected by the 99% "learning to vote", the corporations would just buy him off once he is in office.

Cisco's offers this with their WCS product in conjunction with their Controller-based lightweight APs. http://www.cisco.com/en/US/prod/collateral/wireless/ps5755/ps6301/ps6305/product_data_sheet0900aecd802570d0.html From the configuration guide (http://www.cisco.com/en/US/docs/wireless/wcs/7.0/configuration/guide/7_0mon.html): "Contain rogue access points by sending their clients deauthenticate and disassociate messages from one to four access points. This containment can be done for individual rogue access points by MAC address or can be mandated for all rogue access points connected to the enterprise subnet."

I've used the free versions of both RapidShare and Hotfiles and they seemed pretty much the same to me. Are the paid versions so different that Hotfiles is breaking the law but RapidShare isn't? I just assumed that all of these sites operated the same way...

This claim by Blizzard (and many others) is completely dumb. I really hope they lose on this, because if I buy a product off the shelf, I feel it should be a sale regardless of what their TOS says. That is the precedent that the courts really need to set here. I think in a perfect world, the only way Blizzard should be able to pull this stunt is to actually "lease" you the client as part of the monthly subscription. No extra purchase for the game + expansion packs. You straight up pay your monthly access fee for the "service". If that were actually their model, this case would be a slam-dunk for Blizzard in my mind. Since they are selling a boxed version of the client, they deserve to lose this one. Same thing should be set for every other vendor out there: if you want to have absurd TOS terms, then you have to figure out how to sell your product as a monthly recurring service. Then you can fit right in with the other consumer abusive companies such as telcos, cell phone providers, and cable providers.

But, they will probably end up winning and that will be even more motivation for additional companies to become even more hostile against consumers. Oh, happy day.

I am familiar with the "real world". We have connections from two telcos to each of our sites. I am not worried about me screwing something up to kill my remote access to a site, or losing a circuit and losing access to a site. What I am worried about are the other people I have to work with that can barely hook up a Linksys switch who are permitted full RW access to the Routers and Switches that run everything. If you've not witnessed the type of damage a stupid person can do, you are extremely lucky. If the stupid people ever go away, then I will feel comfortable giving up the modems.

As far as security is concerned - you're right, it is less secure than a well-designed IP infrastructure. However, I have yet to see any random logins on the console server logs. I'm guessing that wardialing is declining in popularity.

Regardless of all that, I still prefer the console for initial device setup. It seems like we never have unused KVM dongles laying around, and I hate to drag out the crash cart just to configure an IP address; especially since the monitor routinely gets removed for some unknown reason. It takes only a few moments to cross-connect from a RJ-45 console port to the console server. Only a minute longer if I need to grab a RJ-45 to DB9 adapter.

I fully agree with you for servers. However, for switches, routers, PDUs, UPSs, etc, iLO/LOM/IPMI/RIB really isn't that useful. Some newbie messed up an access-list or a route in the router and now you can't access it remotely? Good luck with TCP/IP there; I'll keep my 56k modem + serial connection for out-of-band management, thank you. Even better, I can connect a terminal server to the modem so that I can get to the consoles of all of the network devices - Oh, some newbie shut down the PDU port(s) that powers the Router/Switch? I can dial in and fix that for you.

100% agree with this. There is no reason (none that is obvious to me, anyways) why the existing DB-9 connector can't go bye-bye. Many manufacturers have been using RJ-45 serial connectors for a long time. Our APC PDUs use what appears to be a RJ-11 (or perhaps RJ-12) port for their Serial console. One or the other of these formats would be much more convenient to have on a laptop in my opinion. I can't remember the last time I used the modem in my laptop, it'd be nice for it to be multipurpose so I don't have to mess with a stupid barely working (if I'm lucky) USB Serial adapter.

I'm not agreeing with illegal file sharing, but what I don't understand is how they pin massive fines on one single person as though they are solely responsible for 100,000,000 downloads. If I share something and 2 people download it, aren't they at least partially responsible for allowing others to download from them (i.e. redistributing)? Conversely, if I download something illegally and share it with 2 other people, should it be entirely my fault for every download that happens after it was downloaded from me?

Maybe I'm mistaken, but I've not saw any hard evidence in any of the P2P cases which indicate for a certainty that x number of copies were distributed solely because of the file sharer being charged. At best, they might know who downloaded directly from that person, but if that person was just another link in a chain of hundreds or thousands of sharers/downloaders, why do they bear the burden of the responsibility? Just because they were the only ones who happened to be caught?

So, making this into a paper illustration, let's say a random person gives me a (photo)copy of a book that I've been wanting to read, and I then take that book and make 2 more copies copies (a stretch, I know) and give each copy to another random person. Each of those persons goes and makes 2 copies and gives to 2 other persons. Somehow, i get caught (probably for using up too much paper at work). Is it my fault for all of the copies that were made? Do I get a $10,000,000 fine because I illegally "made available" the publication? I'm sure this isn't a particularly common scenario, but I've certainly never heard of anything remotely similar (excluding digital works).

The laws as they are applied to digital works just seem utterly ridiculous. I can appreciate that they deserve to get paid for their work, but some of these stories are just absurd.

Good point about Cisco's SIP stack. The SIP release notes are laughable compared to the SCCP ones. Anyone using Cisco phones connecting to CCM or CUCM via SIP must be completely bonkers. It really is a poor implementation. I'm interested to see if it improves now that they have started releasing SIP-only phones (89xx and 99xx).

QoS issues with your network. Many VoIP installations seem to fail to consider LAN QoS. A busy LAN is just as deadly to VoIP as a busy WAN.

Poor High Availability design. A properly designed network should be able to tolerate the failure of a core switch or router without any noticeable impact to traffic. Sure, if you have an access switch that phones are connected to go belly up, you're going to lose some phones, but it's kind of hard to get around that one. Keep a hot spare on hand if uptime is that big of a concern.

The beauty with SIP is that it is an open standard. The downfall of SIP is that not every vendor supports the same SIP RFCs (Compare RFC 2543 and 3264; two different "standards" for placing SIP calls on hold- although RFC 2543 is obsolete, some vendors still utilize that mechanism for call hold. There are many other examples of this within the SIP stack). Many people read that a product supports SIP and instantly think that it will work with any other product they have that supports SIP. This isn't always the case if one vendor or the other doesn't support the same SIP RFCs. When you create SIP Profiles in Cisco Unified Communications Manager, you can enable/disable some of the RFCs that other vendors may or may not support (or may support differently) which can frequently resolve these SIP headaches.

This is a pretty rare event with Cisco phones in a Cisco UCM environment- especially if you are running the current UCM release. Since Cisco deploys phone firmware as part of a UCM build, the software is typically well tested for interoperability. Not that it never happens, but in my experience, it's quite rare- especially since the old Windows-based CCM 3.x and CCM 4.x days are past.

Sounds like someone is resisting the change. The reduction in MAC changes alone saved us an enormous amount of time when we switched from a traditional PBX environment to a Cisco VoIP solution. Plus, ever since Cisco UCM version 5.x, they are using Linux rather than Windows, so that's certainly a benefit.

As far as interactive environments go, I still look back fondly at the interactive pool tables and the arcade games. The best was the Duke Nukem cabinet- when you operated it, Duke would say: "I don't have time to play with myself." Classic.