This is generally incorrect advice at least for a VMware environment. Best practice is to virtualize vCenter Server and its database, and use them with HA/DRS...
Agreed that this is "generally incorrect". It really depends on the size and complexity of the environment, however. If you have a fairly small environment that can be covered by a small number of hosts, then I would most likely virtualize vCenter. However, if you have a large enterprise environment with redundant data centers and a non-small number of hosts, I would take a more careful look at whether virtualizing vCenter was the correct solution. There are some circumstances that make virtualizing vCenter a little ugly in a full DR situation - anything where you are taking an entire data center offline (planned power outage, cooling/power failure, etc). Especially if you are using a 3rd party distributed switching product (aka Cisco Nexus 1000v), where you can run into some circular dependencies if you have not properly planned your environment. Perhaps this has been fixed at some point, but a version or two ago, when a host initially booted, all VM network connectivity was blocked until the VEM (1000v Host software) checked in with the VSM (Virtual Supervisor). The VSM was a VM that tied into the vCenter database to provide distributed switching. If vCenter could not start for some reason (maybe because your database VM was using Nexus 1000v for network connectivity, or vCenter was using AD authentication for SQL and an AD server was unreachable, or vCenter was using DNS to reach SQL, but no DNS server was available), then none of your hosts would have network connectivity because the VSM wouldn't complete initialization until vCenter was online.
The obvious fix is that all vCenter dependencies have to be on VMs that do not rely on any Nexus 1000v ports. Unfortunately, this means you have to use hosts that are not at all controlled by Nexus 1000v, or you have to have both standard vSwitch/vDS ports and Nexus 1000v ports connected to the same host - and if you ever move vCenter around, that means all of your hosts have to have both vSwitch/vDS and 1000v ports. Or you can run all dependencies right on the vCenter server - but that isn't ideal either, because that's another SQL server (and license) that you have to manage. Of course, if you opt not to virtualize vCenter, then you are likely either going to have on-box SQL or be connecting to a physical SQL server regardless. Even if you're not using Nexus 1000v, you need to be fully aware of all of the dependencies in the virtual environment; one minor oversight can lead to fairly significant consequences.
As far as virtualizing vCenter being the "Best practice", that's fine for protecting against host failures inside a single data center. If your DR plan needs to accommodate a failure of an entire data center, then you need more than that. In that case you are typically going to be using vCenter Heartbeat or a 3rd party protection product, and the HA/DRS protection is less vital. In this type of environment, I would generally favor a physical vCenter server in each data center.
I was just short of getting that raise that would take me into the 6-figure range, but I was tired of working 60 hour work weeks. I took a job with a 15% pay cut for a 4-day work week. However, I do get bonuses here, so it didn't end up being nearly that much. Best move I've ever made in my life. The Health Insurance is a little disappointing, but it's not the worst I've heard of either. Plus, it's a great place to work - I actually feel appreciated for the first time in my working career, which is pretty amazing.
However, there don't seem to be a lot of candidates out there who are willing to make that kind of change - for most, it's all about the money.
And if I could get $20k per year just to wear a neck tie, I'd totally do it.
And what I've strongly suspected is that the good candidates, the ones you'd want to hire, get screened out in HR because they don't have that 20-page resume listing every skill under the sun and so don't get through the keyword filtering HR uses on resumes...
I think this is exactly right. Head hunters aren't much better, because most of the time they have no idea what they are talking about either.
And as AC mentioned, there is an entire generation of "engineers" who seem to know only what the books tell them (and maybe not even that much). As far as Network Engineers go, it's amazing how many people list "Microsoft" or "VMware" or "Cisco" on resumes (especially as far as Certifications go), but can't answer basic questions about the technology. I'm guessing that their TestKing's didn't prepare them well enough for that. If you are asking for a salary anywhere close to 6-figures, you shouldn't be stumped by basic questions in your field - if you are, then you are likely under-qualified and/or over-employed.
And yes, there are employers that list ridiculous qualifications and inadequate compensation. If you are a savvy person, you can identify those positions pretty quickly, and you ignore them, because they aren't targeted at you. If the compensation is dis-proportionally low compared to the qualifications, then that job is for someone who is good at lying on their resume and bs-ing their way through an Interview, not someone who has real talent. Any employer who claims otherwise is disingenuous.
How do you find a person who is going to be loyal to the company? It has become the cultural norm in IT to move jobs frequently, so there are fewer and fewer "loyal to the death" employees. If someone is only going to stick around for 2-3 years, why spend thousands or tens-of-thousands of dollars training them?
Granted, a lot of companies brought this upon themselves by not properly paying loyal employees, so the only way for talented employees to get "market rate" was to move to another job. I've worked for several companies where the only way to get a "market adjustment" was to get an offer letter from another employer. If you go to all that work, why bother sticking around? Obviously the company doesn't value you if you had to twist their arm to give you a raise.
Agreed. You should change the requirement to state that the candidate must be able to obtain a security clearance, that you will pay for it, and that they will not retain their position if they fail to obtain it.
Maybe they are hard to fill because they dont pay enough?
This isn't *exactly* the problem, but it is kind of close. The specific problem (that I've had, anyways) is that there are very few mid-range applicants. You have the entry level guys who have little experience (or little applicable experience) in the 70k or less range, and then you have the Senior level guys who can command 6-figures. If you want to fill a position that sits between those two extremes, it can be a challenge to find talent. This puts you in a position of either hiring an under-qualified person, and paying them above their comparative value, or hiring a completely unqualified person in basically an Internship position, which then ends up costing you extra training dollars, reduced effectiveness of employees who are helping train them, etc, so it still ends up costing more then their comparative value.
So many good comments here - but I still find it disturbing that some people truly believe that the US literally "controls" the Internet, and that having the "control" "turned over" to the UN would be a good thing. However, in reality, the US doesn't "control" the Internet. Yes, the US does "control" ICANN and IANA, but if another country wants to run their own versions of these services, there isn't anything stopping from doing so (other than money and control over their ISPs). That way, they could "control" their own Internet in the same way the United States does. Interoperability could be a challenge if they deviated too far from how things exist today, but my guess is that is something they wouldn't really care about anyway.
What part of the Internet do people really feel like the US "controls"? IETF is somewhat US-oriented, so I guess you could argue that IPv4 and IPv6 (and all other Internet standards) are "controlled" by the US. But, there is still nothing (other than money and control over their ISPs) stopping a country from writing their own protocol stack, then having government backed companies produce the network equipment and software to work with it. Finally, they would be free from the tyranny of the United States!
So far, the worst thing the US Government has done is seize/alter DNS records. Nothing an entry in the ole' hosts file (or alternate DNS service) doesn't fix. Yes, this is dumb, and as a US citizen I feel this is a ridiculous offense against free speech. However, comparatively speaking, what the US is doing is petty. The US version of free speech violation involves whatever the wealthiest corporations tell the government needs to be censored (i.e. RIAA/MPAA sponsored policies to "stop piracy"). Generally speaking, the government doesn't care what I say about it, so long as it isn't extreme enough to get myself labeled as a terrorist. The China/Iran/etc. version of free speech violation involves you going to jail if you say anything negative about the government. India has been struggling to find effective ways to censor their Internet for some time now, and what they are asking for goes far beyond meddling with DNS. Allow the UN to "develop internet policies" and "oversee all internet standards bodies and policy organizations"? Gee, that sounds like a great idea. What could possibly go wrong? Let me get in line to allow the UN to set policies to what I can access and not access on the Internet. While they are at it, they should stop the IETF from publishing RFCs such as 1149 - I'm concerned that could assist with overthrowing a militant regime somewhere.
That sounds way better than what we have today! </sarchasm>
My personal opinion is that India keeps failing to find effective ways to perform the censorship they want to, and this is their way of soliciting external help with "solving" the problem. Maybe someone should put them in touch with China and tell them to leave everyone else out of this. Once the UN solves all of the other world problems, like war, crime, hunger, disease, etc. then they can move on to more minor tasks like this one...
I swear most hotels must have 300+ rooms sharing a T1 line.
I think you were maybe being sarcastic here, but coming from someone who use to support hotels, this isn't far from reality. I worked for a company who supported several somewhat prominent hotels, and they would frequently have 100s of guest rooms on 1 or 2 T1s.
If the RIAA / MPAA would have just bought Napster rather than trying to sue them into oblivion, they would have had the chance to make the music/movie industry into what iTunes is today. Instead, they brought Napster into media attention, which caused lots of people to start giving consideration to downloading music instead of purchasing it. They have only themselves to blame for failing to deliver the goods that people wanted to buy - people wanted digital media rather than CDs. They failed to innovate. If only the government would shut them down for being monopolies in their industries, we could all get back to spending our time on more productive issues.
I personally don't think Apple has a place in the Enterprise - they cater to consumers, and they don't care about anything in the Enterprise unless it is something that is necessary to make things work for the consumers (i.e. ActiveSync). The attitude that really irks me the most (and Apple seems to be especially bad about this) is the one that every device is disposable. If a device is lost or stolen, just buy another one - phone, tablet, computer, whatever. They clearly do not care about environments where data loss is a concern. "Remote Wipe" is the general answer to this question - you know, since Remote Wipe is impossible to avoid from the device end [/sarchasm].
With BYOD is becoming more and more common, however, and the big issue I have with that is that there is very little visibility into the device itself - how does IT know that a device being brought in by a person is "safe"? Sure you can write policies that say you have to properly maintain your own equipment, but those only let you fire someone (maybe) after the damage has been done. What happens if someone roots their iDevice (or Android, or whatever), sets up the root user with a password of "password" and sets it to be accessible from any network? How do I enforce any measure of security in that type of environment? Sure, some Mobile Device Management applications give you kind of a protected, encrypted environment on the device - which is good for IT - however, I have yet to evaluate any solution that users considered as usable as the native interfaces (granted, it's been a couple of years since I've looked - maybe this problem has been solved by now). And, in the environments I've been in where BYOD was tolerated, IT could not force users to install any applications, and IT could not restrict BYOD devices access to ActiveSync. I guess you can just assume that every endpoint is unsafe, but it can get a bit expensive to properly protect an environment like that - either in terms of hardware, software, labor, or some combination of the three.
Granted, some of these same issues exist on corporate liable devices as well - people can still mess with the device they are issued. However, at least the enterprise can generally enforce things such as requiring users to use some kind of secure MDM environment rather than ActiveSync. Or, if you choose to use ActiveSync, at least something like a Remote Wipe is a little less controversial.
So can HP handle that better? I'm not sure how. What leverage do they have over the carriers?
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.
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."
No doubt they're in the gray area of the law, but as long as there's money in it companies will test those limits. What we do know is that RapidShare is legal and Grokster was illegal. Hotfile is floating somewhere in between, either way we're likely to see another precision of what you can do and not.
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.
"Serial" shouldn't go away, but the massive plug should.
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).
whether its large data loads being done over the network causing the voice quality to go through the floor
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.
or a network outage killing the system dead
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.
or SIP server bugs
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.
or just bugs in the IP phones themselves.
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.
VOIP for the office is hype - all it does is save on some cabling and wall sockets which had already been installed and paid for anyway!
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.
Slashdot Mirror
This is generally incorrect advice at least for a VMware environment. Best practice is to virtualize vCenter Server and its database, and use them with HA/DRS...
Agreed that this is "generally incorrect". It really depends on the size and complexity of the environment, however. If you have a fairly small environment that can be covered by a small number of hosts, then I would most likely virtualize vCenter. However, if you have a large enterprise environment with redundant data centers and a non-small number of hosts, I would take a more careful look at whether virtualizing vCenter was the correct solution. There are some circumstances that make virtualizing vCenter a little ugly in a full DR situation - anything where you are taking an entire data center offline (planned power outage, cooling/power failure, etc). Especially if you are using a 3rd party distributed switching product (aka Cisco Nexus 1000v), where you can run into some circular dependencies if you have not properly planned your environment. Perhaps this has been fixed at some point, but a version or two ago, when a host initially booted, all VM network connectivity was blocked until the VEM (1000v Host software) checked in with the VSM (Virtual Supervisor). The VSM was a VM that tied into the vCenter database to provide distributed switching. If vCenter could not start for some reason (maybe because your database VM was using Nexus 1000v for network connectivity, or vCenter was using AD authentication for SQL and an AD server was unreachable, or vCenter was using DNS to reach SQL, but no DNS server was available), then none of your hosts would have network connectivity because the VSM wouldn't complete initialization until vCenter was online.
The obvious fix is that all vCenter dependencies have to be on VMs that do not rely on any Nexus 1000v ports. Unfortunately, this means you have to use hosts that are not at all controlled by Nexus 1000v, or you have to have both standard vSwitch/vDS ports and Nexus 1000v ports connected to the same host - and if you ever move vCenter around, that means all of your hosts have to have both vSwitch/vDS and 1000v ports. Or you can run all dependencies right on the vCenter server - but that isn't ideal either, because that's another SQL server (and license) that you have to manage. Of course, if you opt not to virtualize vCenter, then you are likely either going to have on-box SQL or be connecting to a physical SQL server regardless. Even if you're not using Nexus 1000v, you need to be fully aware of all of the dependencies in the virtual environment; one minor oversight can lead to fairly significant consequences.
As far as virtualizing vCenter being the "Best practice", that's fine for protecting against host failures inside a single data center. If your DR plan needs to accommodate a failure of an entire data center, then you need more than that. In that case you are typically going to be using vCenter Heartbeat or a 3rd party protection product, and the HA/DRS protection is less vital. In this type of environment, I would generally favor a physical vCenter server in each data center.
I was just short of getting that raise that would take me into the 6-figure range, but I was tired of working 60 hour work weeks. I took a job with a 15% pay cut for a 4-day work week. However, I do get bonuses here, so it didn't end up being nearly that much. Best move I've ever made in my life. The Health Insurance is a little disappointing, but it's not the worst I've heard of either. Plus, it's a great place to work - I actually feel appreciated for the first time in my working career, which is pretty amazing.
However, there don't seem to be a lot of candidates out there who are willing to make that kind of change - for most, it's all about the money.
And if I could get $20k per year just to wear a neck tie, I'd totally do it.
And what I've strongly suspected is that the good candidates, the ones you'd want to hire, get screened out in HR because they don't have that 20-page resume listing every skill under the sun and so don't get through the keyword filtering HR uses on resumes...
I think this is exactly right. Head hunters aren't much better, because most of the time they have no idea what they are talking about either.
And as AC mentioned, there is an entire generation of "engineers" who seem to know only what the books tell them (and maybe not even that much). As far as Network Engineers go, it's amazing how many people list "Microsoft" or "VMware" or "Cisco" on resumes (especially as far as Certifications go), but can't answer basic questions about the technology. I'm guessing that their TestKing's didn't prepare them well enough for that. If you are asking for a salary anywhere close to 6-figures, you shouldn't be stumped by basic questions in your field - if you are, then you are likely under-qualified and/or over-employed.
And yes, there are employers that list ridiculous qualifications and inadequate compensation. If you are a savvy person, you can identify those positions pretty quickly, and you ignore them, because they aren't targeted at you. If the compensation is dis-proportionally low compared to the qualifications, then that job is for someone who is good at lying on their resume and bs-ing their way through an Interview, not someone who has real talent. Any employer who claims otherwise is disingenuous.
I second this motion. Where do I sign up?
How do you find a person who is going to be loyal to the company? It has become the cultural norm in IT to move jobs frequently, so there are fewer and fewer "loyal to the death" employees. If someone is only going to stick around for 2-3 years, why spend thousands or tens-of-thousands of dollars training them?
Granted, a lot of companies brought this upon themselves by not properly paying loyal employees, so the only way for talented employees to get "market rate" was to move to another job. I've worked for several companies where the only way to get a "market adjustment" was to get an offer letter from another employer. If you go to all that work, why bother sticking around? Obviously the company doesn't value you if you had to twist their arm to give you a raise.
Agreed. You should change the requirement to state that the candidate must be able to obtain a security clearance, that you will pay for it, and that they will not retain their position if they fail to obtain it.
Maybe they are hard to fill because they dont pay enough?
This isn't *exactly* the problem, but it is kind of close. The specific problem (that I've had, anyways) is that there are very few mid-range applicants. You have the entry level guys who have little experience (or little applicable experience) in the 70k or less range, and then you have the Senior level guys who can command 6-figures. If you want to fill a position that sits between those two extremes, it can be a challenge to find talent. This puts you in a position of either hiring an under-qualified person, and paying them above their comparative value, or hiring a completely unqualified person in basically an Internship position, which then ends up costing you extra training dollars, reduced effectiveness of employees who are helping train them, etc, so it still ends up costing more then their comparative value.
So many good comments here - but I still find it disturbing that some people truly believe that the US literally "controls" the Internet, and that having the "control" "turned over" to the UN would be a good thing. However, in reality, the US doesn't "control" the Internet. Yes, the US does "control" ICANN and IANA, but if another country wants to run their own versions of these services, there isn't anything stopping from doing so (other than money and control over their ISPs). That way, they could "control" their own Internet in the same way the United States does. Interoperability could be a challenge if they deviated too far from how things exist today, but my guess is that is something they wouldn't really care about anyway.
What part of the Internet do people really feel like the US "controls"? IETF is somewhat US-oriented, so I guess you could argue that IPv4 and IPv6 (and all other Internet standards) are "controlled" by the US. But, there is still nothing (other than money and control over their ISPs) stopping a country from writing their own protocol stack, then having government backed companies produce the network equipment and software to work with it. Finally, they would be free from the tyranny of the United States!
So far, the worst thing the US Government has done is seize/alter DNS records. Nothing an entry in the ole' hosts file (or alternate DNS service) doesn't fix. Yes, this is dumb, and as a US citizen I feel this is a ridiculous offense against free speech. However, comparatively speaking, what the US is doing is petty. The US version of free speech violation involves whatever the wealthiest corporations tell the government needs to be censored (i.e. RIAA/MPAA sponsored policies to "stop piracy"). Generally speaking, the government doesn't care what I say about it, so long as it isn't extreme enough to get myself labeled as a terrorist. The China/Iran/etc. version of free speech violation involves you going to jail if you say anything negative about the government. India has been struggling to find effective ways to censor their Internet for some time now, and what they are asking for goes far beyond meddling with DNS. Allow the UN to "develop internet policies" and "oversee all internet standards bodies and policy organizations"? Gee, that sounds like a great idea. What could possibly go wrong? Let me get in line to allow the UN to set policies to what I can access and not access on the Internet. While they are at it, they should stop the IETF from publishing RFCs such as 1149 - I'm concerned that could assist with overthrowing a militant regime somewhere.
That sounds way better than what we have today! </sarchasm>
My personal opinion is that India keeps failing to find effective ways to perform the censorship they want to, and this is their way of soliciting external help with "solving" the problem. Maybe someone should put them in touch with China and tell them to leave everyone else out of this. Once the UN solves all of the other world problems, like war, crime, hunger, disease, etc. then they can move on to more minor tasks like this one...
I swear most hotels must have 300+ rooms sharing a T1 line.
I think you were maybe being sarcastic here, but coming from someone who use to support hotels, this isn't far from reality. I worked for a company who supported several somewhat prominent hotels, and they would frequently have 100s of guest rooms on 1 or 2 T1s.
If the RIAA / MPAA would have just bought Napster rather than trying to sue them into oblivion, they would have had the chance to make the music/movie industry into what iTunes is today. Instead, they brought Napster into media attention, which caused lots of people to start giving consideration to downloading music instead of purchasing it. They have only themselves to blame for failing to deliver the goods that people wanted to buy - people wanted digital media rather than CDs. They failed to innovate. If only the government would shut them down for being monopolies in their industries, we could all get back to spending our time on more productive issues.
I personally don't think Apple has a place in the Enterprise - they cater to consumers, and they don't care about anything in the Enterprise unless it is something that is necessary to make things work for the consumers (i.e. ActiveSync). The attitude that really irks me the most (and Apple seems to be especially bad about this) is the one that every device is disposable. If a device is lost or stolen, just buy another one - phone, tablet, computer, whatever. They clearly do not care about environments where data loss is a concern. "Remote Wipe" is the general answer to this question - you know, since Remote Wipe is impossible to avoid from the device end [/sarchasm].
With BYOD is becoming more and more common, however, and the big issue I have with that is that there is very little visibility into the device itself - how does IT know that a device being brought in by a person is "safe"? Sure you can write policies that say you have to properly maintain your own equipment, but those only let you fire someone (maybe) after the damage has been done. What happens if someone roots their iDevice (or Android, or whatever), sets up the root user with a password of "password" and sets it to be accessible from any network? How do I enforce any measure of security in that type of environment? Sure, some Mobile Device Management applications give you kind of a protected, encrypted environment on the device - which is good for IT - however, I have yet to evaluate any solution that users considered as usable as the native interfaces (granted, it's been a couple of years since I've looked - maybe this problem has been solved by now). And, in the environments I've been in where BYOD was tolerated, IT could not force users to install any applications, and IT could not restrict BYOD devices access to ActiveSync. I guess you can just assume that every endpoint is unsafe, but it can get a bit expensive to properly protect an environment like that - either in terms of hardware, software, labor, or some combination of the three.
Granted, some of these same issues exist on corporate liable devices as well - people can still mess with the device they are issued. However, at least the enterprise can generally enforce things such as requiring users to use some kind of secure MDM environment rather than ActiveSync. Or, if you choose to use ActiveSync, at least something like a Remote Wipe is a little less controversial.
So can HP handle that better? I'm not sure how. What leverage do they have over the carriers?
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."
No doubt they're in the gray area of the law, but as long as there's money in it companies will test those limits. What we do know is that RapidShare is legal and Grokster was illegal. Hotfile is floating somewhere in between, either way we're likely to see another precision of what you can do and not.
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.
"Serial" shouldn't go away, but the massive plug should.
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).
whether its large data loads being done over the network causing the voice quality to go through the floor
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.
or a network outage killing the system dead
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.
or SIP server bugs
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.
or just bugs in the IP phones themselves.
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.
VOIP for the office is hype - all it does is save on some cabling and wall sockets which had already been installed and paid for anyway!
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.