That example was due to incompetence, not due to automation. Whilst recover from that would be a pain in the ass, if you are unable to recover at all, you have a major DR oversight.
Automating shit that can be automated so that you can actually do thing that benefit the business instead of simply maintaining the status-quo is not a bad thing. Doing automate-able drudge work when it could be automated is just stupid. Muppets who can click next through a Windows installer or run apt-get, etc. are a dime a dozen. IT staff who can get rid of that shit so they can actually help people get their own jobs done better are way more valuable.
The job of IT is to enable the business to continue to function and improve. Never forget that. People don't spend up big on computer stuff just because. They do it in order to save money by improving process. Improving process is where you should be focused, anything to do with general maintenance of the status quo is dead time.
Alternatively, perhaps somewhere up the chain they have no idea what can be done (this IT shit isn't their area of expertise), and are not being told by their IT department how to actually fix the problem properly. Rather, they are just applying band-aid after band-aid for breakage that happens.
It is my experience that if you outline the risks, the costs and the possible mitigation strategies to eliminate the risk, most sensible businesses are all ears. At the very least, if they don't agree on the spot, they are at least aware of what is possible and when the inevitable happens, be more keen to fix the problem next time.
Downtime cost adds up pretty fucking quickly. For example, my company: We have 650 PC users. pay rate probably ranges from 25 bucks an hour to 100 bucks an hour or more. Lets say the average is probably somewhere around 45 per hr.
1 hour of downtime, by 650 users, by 45 bucks per hour = $29,250 in lost productivity. Plus the embarrassment of not being able to deal with clients, etc. Plus potentially other flow on effects (e.g., in our case, possibly: maintenance scheduling for our mining equipment - trucks, drills, etc. didn't run. Plant therefore didn't get serviced properly, $500k engine dies).
If you fuck something up and are down for a day? Well... you can do the math.
This is why you move the fuck on and adapt. If your job is relying on stuff that can be done by a shell script, you need to up-skill and find another job. Because if you don't do it, someone like myself will.
And we'll be getting paid more due to being able to work at scale (same shit for 10 machines or 10,000 machines), doing less work and being much happier, doing it.
Yeah, don't get me wrong (i've been posting about setting up a test lab using vSphere, vFilters and vlans) - you can't replace the need to have someone on call or watching in case it all fucks up. But you can generally reduce the outage window and risk significantly by actually testing (both the roll out and roll back) first. And if you've got it to the point where you can reliably test, you can work on your automation scripts, test the shit out of them, and having been tested with a copy of live using a copy of live data, be reasonably confident that they will work.
If they don't? Snapshot the breakage, roll back to pre-fuckup, and examine at your leisure. Then re-schedule once you know wtf happened.
Yup. Company I work currently has only a 4 hour window per day where we don't have active users actually on the clock. And if we win a job in say, south america (we're a mining company), that goes out the window entirely. VMotion, virtual networking, virtual filers/writable snapshots, are all beautiful things.
OS choice is irrelevant. I've seen plenty of critical linux fuck ups in my day, and OS choice doesn't account for human error. And, being human, you WILL make human errors. You need a test environment and a backout plan. If you don't at least have a back-out plan and an estimate of how much the fuckup will cost BEFORE proceeding (and balancing that against the cost/risk of leaving it the fuck alone), you should not be carrying out the work.
Sure, that sounds like management speak, but seriously... cover your fucking ass. Because one day it will fuck up (whatever, the OS, this isn't just a Linux or Windows problem) and whilst the fuck up may not necessarily be your fault, the extended downtime because you have not tested and have no backout plan will be.
This is why you build a test environment. VLANS, virtualization, SAN snapshots. There's no real excuse. Articulate the risks that a lack of a test environment entail to the business, and ask them if they want you doing shit without being able to test to see if it breaks things. Do some actual calculations on cost of system failure, and explain to them ways in which it can be mitigated. Putting your head in the sand and just breaking shit in live... well, that's one way to do it, but I fucking guarantee you: it WILL bit you in the ass, hard one day, whether it is automated or not. if you have a test environment, you can automate the shit out of your process, TEST it, and TEST a backout plan before going live.
Yup. Although, that said, if you have a proper test environment, like say, a snap-clone of your live environment and an isolated test VLAN, you can do significant testing on copies of live systems and be pretty confident it will work. You can figure out your back-out plan, which may be as simple as rolling back to a snapshot (or possibly not).
Way too many environments have no test environment, but these days with the mass deployment of FAS/SAN and virtualization, you owe it to your team to get that shit set up.
No I'm not missing your point. There may be a trend, but i guarantee you that if someone writes a killer app that asks for way more access than it requires, people will still install it. Just look at Facebook, or Google's services.
Blu-ray is better quality than streaming, sure. Most people don't actually care. Just look at the blu-ray adoption rate. I can stream 1080p youtube or 720 Apple TV content and do other stuff at the same time on a 16 megabit ADSL with zero hiccups. I was streaming AppleTV content (720p) with zero hiccups on a 6 meg sync back in 2010. And codecs are only going to get better.
This was a developer showcase, for developers who are already in the apple ecosystem. It wasn't a marketing event. There was plenty of stuff that people will want in the conference. But hey, believe what you want to believe.
You can install whatever you please on an iOS device, you just need to be a member of the developer program to do it. Yes it costs money. no, it isn't a lot.
95% plus of people are not interested in computers for computers sake. They may be teachers, scientists or business moguls. Not necessarily fucktards - just not interested in computers. For them, a computer is a tool like a hammer or a screwdriver, that they only use to get a job done. Fucking around with PC brain damage rather than spending their valuable time doing what they would rather be doing is something that Apple minimises for them.
Similar experience here. First of the Android/iOS handsets was a iPhone 3G. Jailnbroke it. Ran quake. realised that touch sucks for quake. Installed a few themes.
Upgraded to a 3G-S. didn't bother to jailbreak. Didn't miss it. Have run iOS primarily ever since.
Dabbled with Android on a HTC One and Samsung Galaxy S3. Noticed that many apps do not scale to the screen properly. Encountered folder bug on HTC One (created a folder in the launcher I could not delete until updating firmware). Noticed bug in alarm clock - didn't wake me up. Noticed scrolling was less smooth than my 3-4 year old iPhone from 2008. Constantly annoyed with the UI and crappy email program.
Didn't find anything to hold me to the platform and the UI was annoying. Handset quality was not as good - the S3 feels like a plastic child's toy, and the buttons on the bottom of the HTC one are awkward to use with one hand.
Try using a 16x9 tablet for email or web browsing, then try it on an iPad or Surface Pro 3 and get back to me. 4:3 is a compromise for the form factor. It isn't designed purely for watching videos. Besides, if you want something optimised for videos, you want 2.3:1. But that aspect ratio on a tablet is clearly ridiculous. So is 16x9, once you've actually tried it back to back with something more close to square.
Slashdot Mirror
Get access to SCCM or get your outsourcer to fix the fucking problems they created.
That example was due to incompetence, not due to automation. Whilst recover from that would be a pain in the ass, if you are unable to recover at all, you have a major DR oversight.
Yup. Same reason changes on the weekend are bad, as are changes on (in my opinion) Thursdays and Fridays.
Automating shit that can be automated so that you can actually do thing that benefit the business instead of simply maintaining the status-quo is not a bad thing. Doing automate-able drudge work when it could be automated is just stupid. Muppets who can click next through a Windows installer or run apt-get, etc. are a dime a dozen. IT staff who can get rid of that shit so they can actually help people get their own jobs done better are way more valuable.
The job of IT is to enable the business to continue to function and improve. Never forget that. People don't spend up big on computer stuff just because. They do it in order to save money by improving process. Improving process is where you should be focused, anything to do with general maintenance of the status quo is dead time.
Alternatively, perhaps somewhere up the chain they have no idea what can be done (this IT shit isn't their area of expertise), and are not being told by their IT department how to actually fix the problem properly. Rather, they are just applying band-aid after band-aid for breakage that happens.
It is my experience that if you outline the risks, the costs and the possible mitigation strategies to eliminate the risk, most sensible businesses are all ears. At the very least, if they don't agree on the spot, they are at least aware of what is possible and when the inevitable happens, be more keen to fix the problem next time.
Downtime cost adds up pretty fucking quickly. For example, my company: We have 650 PC users. pay rate probably ranges from 25 bucks an hour to 100 bucks an hour or more. Lets say the average is probably somewhere around 45 per hr.
1 hour of downtime, by 650 users, by 45 bucks per hour = $29,250 in lost productivity. Plus the embarrassment of not being able to deal with clients, etc. Plus potentially other flow on effects (e.g., in our case, possibly: maintenance scheduling for our mining equipment - trucks, drills, etc. didn't run. Plant therefore didn't get serviced properly, $500k engine dies).
If you fuck something up and are down for a day? Well... you can do the math.
This is why you move the fuck on and adapt. If your job is relying on stuff that can be done by a shell script, you need to up-skill and find another job. Because if you don't do it, someone like myself will.
And we'll be getting paid more due to being able to work at scale (same shit for 10 machines or 10,000 machines), doing less work and being much happier, doing it.
Yeah, don't get me wrong (i've been posting about setting up a test lab using vSphere, vFilters and vlans) - you can't replace the need to have someone on call or watching in case it all fucks up. But you can generally reduce the outage window and risk significantly by actually testing (both the roll out and roll back) first. And if you've got it to the point where you can reliably test, you can work on your automation scripts, test the shit out of them, and having been tested with a copy of live using a copy of live data, be reasonably confident that they will work.
If they don't? Snapshot the breakage, roll back to pre-fuckup, and examine at your leisure. Then re-schedule once you know wtf happened.
Yup. Company I work currently has only a 4 hour window per day where we don't have active users actually on the clock. And if we win a job in say, south america (we're a mining company), that goes out the window entirely. VMotion, virtual networking, virtual filers/writable snapshots, are all beautiful things.
Work smarter, not harder. This is the difference between an IT muppet and someone who actually goes places in this industry.
OS choice is irrelevant. I've seen plenty of critical linux fuck ups in my day, and OS choice doesn't account for human error. And, being human, you WILL make human errors. You need a test environment and a backout plan. If you don't at least have a back-out plan and an estimate of how much the fuckup will cost BEFORE proceeding (and balancing that against the cost/risk of leaving it the fuck alone), you should not be carrying out the work.
Sure, that sounds like management speak, but seriously... cover your fucking ass. Because one day it will fuck up (whatever, the OS, this isn't just a Linux or Windows problem) and whilst the fuck up may not necessarily be your fault, the extended downtime because you have not tested and have no backout plan will be.
This is why you build a test environment. VLANS, virtualization, SAN snapshots. There's no real excuse. Articulate the risks that a lack of a test environment entail to the business, and ask them if they want you doing shit without being able to test to see if it breaks things. Do some actual calculations on cost of system failure, and explain to them ways in which it can be mitigated. Putting your head in the sand and just breaking shit in live... well, that's one way to do it, but I fucking guarantee you: it WILL bit you in the ass, hard one day, whether it is automated or not. if you have a test environment, you can automate the shit out of your process, TEST it, and TEST a backout plan before going live.
Yup. Although, that said, if you have a proper test environment, like say, a snap-clone of your live environment and an isolated test VLAN, you can do significant testing on copies of live systems and be pretty confident it will work. You can figure out your back-out plan, which may be as simple as rolling back to a snapshot (or possibly not).
Way too many environments have no test environment, but these days with the mass deployment of FAS/SAN and virtualization, you owe it to your team to get that shit set up.
damn it... wrong article....
Instead of some proper mil-spec language like Jovial or Ada. And it's delayed massively due to software problems. Co-incidence?
No I'm not missing your point. There may be a trend, but i guarantee you that if someone writes a killer app that asks for way more access than it requires, people will still install it. Just look at Facebook, or Google's services.
Blu-ray is better quality than streaming, sure. Most people don't actually care. Just look at the blu-ray adoption rate. I can stream 1080p youtube or 720 Apple TV content and do other stuff at the same time on a 16 megabit ADSL with zero hiccups. I was streaming AppleTV content (720p) with zero hiccups on a 6 meg sync back in 2010. And codecs are only going to get better.
This was a developer showcase, for developers who are already in the apple ecosystem. It wasn't a marketing event. There was plenty of stuff that people will want in the conference. But hey, believe what you want to believe.
Nah. An app could ask for your firstborn and plenty of people will still click through install it. Nigerian 419 scams don't work for no reason.
You can install whatever you please on an iOS device, you just need to be a member of the developer program to do it. Yes it costs money. no, it isn't a lot.
You know carriers know what handset you use, and apple has agreements with their carriers, right?
95% plus of people are not interested in computers for computers sake. They may be teachers, scientists or business moguls. Not necessarily fucktards - just not interested in computers. For them, a computer is a tool like a hammer or a screwdriver, that they only use to get a job done. Fucking around with PC brain damage rather than spending their valuable time doing what they would rather be doing is something that Apple minimises for them.
Because it has a touchscreen for everything else?
Upgraded to a 3G-S. didn't bother to jailbreak. Didn't miss it. Have run iOS primarily ever since.
Dabbled with Android on a HTC One and Samsung Galaxy S3. Noticed that many apps do not scale to the screen properly. Encountered folder bug on HTC One (created a folder in the launcher I could not delete until updating firmware). Noticed bug in alarm clock - didn't wake me up. Noticed scrolling was less smooth than my 3-4 year old iPhone from 2008. Constantly annoyed with the UI and crappy email program.
Didn't find anything to hold me to the platform and the UI was annoying. Handset quality was not as good - the S3 feels like a plastic child's toy, and the buttons on the bottom of the HTC one are awkward to use with one hand.
10.4 is from 2005. Let me know how you go downloading binaries for a Linux distribution from 2005.
Try using a 16x9 tablet for email or web browsing, then try it on an iPad or Surface Pro 3 and get back to me. 4:3 is a compromise for the form factor. It isn't designed purely for watching videos. Besides, if you want something optimised for videos, you want 2.3:1. But that aspect ratio on a tablet is clearly ridiculous. So is 16x9, once you've actually tried it back to back with something more close to square.