I can't answer for Microsoft or others, but if I had to guess, I'd say that although the class of vulnerability was know about, it wasn't considered to be much threat; the chances of this happening under normal circumstances are vanishingly small. So it was probably considered more of an artifact of the implementation than something exploitable. It seems like apparently only yesterday that someone put together that these linked hash maps are used in pretty much every web scripting language out there, and it's not very hard to purposely generate collisions.
Because growth is O(n**2), attacks with a smaller payload will hurt a lot less than attacks with a larger payload. Until recently it was probably somewhat hard to come up with the bandwidth necessary to keep even a mid-sized operation occupied. But as bandwidth availability has increased, this has become easier to come by. Again, just guessing, but this strikes me as something which may have been previously attackable only in theory, and suddenly technology advanced to the point that the attack became viable without people really noticing until just now.
Also, despite the article title, Microsoft's patch was off-schedule, not out-of-band. As another poster pointed out, out-of-band would be if they had to distribute the patch via an unusual distribution method (such as by having to ship CDs out).
More importantly, although lookup is O(n), the insert growth is O(n**2). The request environment preparation for many web languages such as PHP,.NET, Java, Ruby, and Python will time out before script execution even begins (while maxing out a CPU for whatever the request timeout is, usually at least 30 seconds).
The vulnerability is essentially that it's easy to generate intentional key hash collisions for these hash table implementations. This class of vulnerability has been known about since at least 2003.
Yeah, just like most big brand stores, but this is not very relevant because the store you bought an item at is presumably local to you, so who cares if they also have a location in East Jabyyp? Unless you regularly travel a lot, the chances of this being useful is pretty low.
if you are supported, they an tell you that
There's the problem. It's not like Apple Care is one of those cell phone insurance plans where it covers anything that can go wrong. Plenty of things can go wrong that they will be happy to tell you is not covered - even stuff that is not a wear-and-tear fault. Try to get a reasonably expensive part replaced, such as a video card, and they'll tell you how they found some dust in your chassis, so it overheated and it's your fault for not keeping it clean (nevermind that you can't open the chassis on most modern macs without voiding the warranty anyway). At least that's what they told me for my wife's 3 month old iMac.
Likewise my brother's 1 year old Macbook Pro had a recognized fault with its video card. It would sometimes just refuse to produce any video, sometimes to the built-in LCD, sometimes to the video out port, sometimes to both. Plenty of people with the same generation MBP had the same problem. He took it in to get it repaired, and was initially told it was covered since it was a known problem. When he went to pick it up a week later, they wanted $800 in parts in labor - even though he had been told it was going to be a covered repair. Their reason? The chassis had a scratch on it - seriously. They claimed this scratch (in an aluminum chassis) had caused the damage. They went ahead and made the repair without consulting him, and now refused to return his laptop until he coughed up the cash.
Also, if it's not this year's model, they're not going to have replacement parts on hand, and it's going to be 1-2 weeks before you can get that replacement part.
But it seems like a good idea for someone who isn't tech savvy and doesn't want to bother their friends for help
That's probably true. If you don't know how to use your computer, the Geniuses can tell you how to double click. Make sure to call ahead for an appointment, they're booked until next week, but they'll be happy to let you sit in their gallery store for 45 minutes after your appointment time while you have nothing else to do but decide if maybe buying a new one is a better path than being without a computer for two weeks while your old one is getting fixed on your own dime despite having an extended warranty.
Hasbro's trademark dispute against Asus on "Transformer Prime" is remarkably weak. It's a similar name, but in a completely different industry. Trademark is industry specific, so unless Hasbro beats Asus to market with an Autobots themed tablet, this is just saber rattling. But if by some incredible feat they do get this blocked on name, it's just a name, Asus could rename it and sell away overnight.
Apple does the same thing, except they let you upgrade the core OS version number, you just don't get access to the hottest new wizbang features. For example, Siri won't run on stock iPhone 4 phones even though hackers have proven it's not a hardware restriction.
If you buy Google's flagship devices, they get the OS updates without the handset manufacturers being able to drag their feet to prompt you to buy new instead of upgrade existing.
In cases like the original Galaxy Tab from Samsung, this seems like it's false advertising. When they released this device running Gingerbread, they promised it would get a Honeycomb makeover. When Google was tight-fisted with Honeycomb source saying, "Wait for ICS," Samsung said they'd stick it out for ICS instead. However now that ICS is out, they're going back on their word and apparently OS updates for that brand of tablet are now dead at two versions behind.
This is the reason I've stopped buying Samsung hardware, I can't trust them to honor their word about when they'll upgrade the devices since they often promise to and rarely do. Otherwise I'd own a Galaxy Tab 10.1, it's a pretty slick device; I just don't want a dead-end path on upgrades. I plan to get the Asus Transformer Prime instead when it becomes available (glad I waited, Prime is much better).
You cynical man. For all you know, upper management have a budget flush with cash and have singled out someone in the hard working but unacknowledged IT department for a raise and a promotion.
Its partly this that has led to the outsourcing of support to experts with SLAs that include fix times
Yeah, but this sounds good on paper but in practice doesn't really help much. Our support contracts had SLAs on them too. SLAs tend to be either extremely specific (eg, will not include things like the time it takes to restore something from backup, time spent waiting on replacement hardware [for software vendors], and so forth), include a lot of wiggle room (TTF SLAs categorize problems by severity and different severities have different TTF's, so your problem will get classified as the severity for how long it took to solve rather than the other way around), include verbiage like "95% of the time we'll meet objective X," when of course the remaining 5% is the most costly to your business, or simply don't include penalties commensurate with the damage to your company.
Companies which write SLAs which they end up violating don't stay in business or else the SLA had no teeth to begin with. In actual practice you'll find most SLAs are very easy to keep.
As to your counter anecdote, this doesn't seem to line up very well with the discussion at hand. You were the high priced consultant and you made recommendations which were not followed. Any organization is at risk of thick headed territorial people who won't heed advice of those who are more experienced than them. Support contracts are not for "Help us build an infrastructure" problems, they're for "We have a good infrastructure, we want to fire the guys who built it and pay you a fraction of it to help out only when something goes wrong." We're not talking about job outsourcing, we're talking replacing jobs with support instead.
So they fire some people, and they start having problems.
Critically a lot of companies will tread down this road cautiously because they realize how critical their IT infrastructure is to their business. So they fire some people, but they don't have any problems. At first new projects just take a bit longer to materialize.
The problem is that like a well maintained car, a well maintained infrastructure will probably hum along smoothly for a while with reduced maintenance. But technical debt (maintenance debt?) will build up, and when things go critical, they'll go bad much more quickly, and take longer to recover.
The major fallacy many big companies fall into is that some of these systems have been running flawlessly for years, because they hired a competent IT staff. They look at the price of those paychecks and shiver. Why are we paying so many high priced engineers when we've never had a problem, they think.
So they reduce staff and start to rely on support contracts instead of on-site gurus. The gurus are still there to solve any oh-shit moments. But that back investment in good engineers has produced a stable infrastructure that runs with few problems for years. So they reduce staff more, pay for more support contracts, and eventually the system critical mass is greater than the engineers who can support it. It's no problem until it's a problem.
Eventually something minor goes wrong, but nobody notices or if they do it's not really their field of expertise so they don't understand it's minor now but could escalate. When it does, something else goes wrong, and a cascade effect takes out more and more systems. With a full staff, you have enough guys that when the critical mass is reached, they can start defensive measures and get things back in working order in no time. With support staff only, things are going wrong faster than they can deal with it.
"Call on our support contracts," shout the bosses! So now your on-site staff are all on hold instead of troubleshooting. When they get through to someone, they have to spend the first hour or two describing their infrastructure to the technician on the other end, who starts making random suggestions that maybe help, but probably don't.
My anecdote on this front is a company I used to work for. It's a long read, but demonstrates the failures at several levels which is the direct result of this kind of thinking. The Oracle transaction log disk was getting full. Some warnings came in, but disks running low on space was an every day occurrence, we'll send an email to the person on record as being responsible for those servers, and troubleshoot why the "Executive Dashboard" is responding a bit slow today (it's for the execs, it's automatically high priority). Except that person is currently aboard an airplane on his way to help reduce staff in east Asia, he'll be incommunicado for the next 19 hours or more.
It seems like an innocent enough problem, it's just a log disk, the worst thing that could happen is we lose some logs, right? Whoops, transaction logs are pretty important for Oracle. The fact that the disk is filling up at all is itself an indicator that something bigger is wrong; this shouldn't happen. But critically once the disk does fill up, Oracle will enter read-only mode. Or it should. This time it doesn't, it shuts down. BOOM, offline. So down goes SAP. With SAP down, our entire business is offline. We can't take orders, we can't ship orders, we can't pay bills, we can't pay paychecks, the hourly workers whose shift is starting can't even clock in. Some buildings with tighter badge access can't even be entered unless someone inside opens an emergency door to let someone in.
Once the transaction log disk was full, Oracle will no longer start up, it needs some space on the log disk to log startup-related transactions. Two hours on hold with Oracle Gold Pressed Latinum level support they finally get an engineer. Wow, this is something he's never seen before, Oracle should have gone into read-only mode before this happened! The only solution anyone can seem to think of is to get some bigger disks for the transaction logs, clone the data over to these new disks and give the startup another go. We have hot spares on a shelf, but nobody knows this. Finding disks requires a different support contract, they can have disks out to us tomorrow. Yeah, that's not going to cut it. Someone literally drives out to a distribution warehouse. Two more hours down (they actually send two different guys in different cars with instructions to take different routes in case one runs into traffic or gets in an acciden
in any semi decent bar on a friday night there'll be about 20 teenagers filling
Not in the US! It'd be a mix of bar flies, trannies, and hot coeds drinking for free by using the power of suggestion on lonely guys looking to score. But not teenagers, no sir chief!
At first I thought you were going for funny. But your points seem serious, so I don't think so any longer.
To a certain extent you have to know your users. Some classes of user are simply not of the mindset to give you requirements or meaningful bug reports. The responsibility to bridge this gap belongs to the project manager or some designee if the project is of sufficient scale. Sometimes for small projects, the developer is the project manager, so that's the developer's responsibility.
Users/Customers do not have requirements they have PROBLEMS
Right, and the PM first details those problems, then propose to the users possible solutions for those problems. Depending on what level of knowledge the users have about the type of system you're going to be creating, this is voiced to the users in various levels of technical detail. If the user is your grandmother trying to create an online space for her knitting group, you avoid jargon and talk about things at extremely high levels, "post pictures of their projects," "have a calendar of upcoming get-togethers and whose house it's at," etc. If the user is the CFO of your company, you talk about GL, profitability reports, and so forth. If the user is the head of operations you talk about data centers, topology maps, border routing, and stuff like that.
This is why there's a difference between user requirements and technical requirements. User requirements are meaningful to the user, and technical requirements are meaningful to the developers. Users inform the user requirements, user requirements inform the technical requirements, and technical requirements inform the developers.
Of course not every project is of a scope and scale for all of this to be formal. Sometimes it's ok to just sit down with the user, get some thoughts together, bang together a POC, and ask the user for feedback, polish, feedback, repeat. But the different types of requirements still exist, they're just in someone's head instead of on paper, and they may be a continuous work in progress. You can't create something new without knowing what it's supposed to do though.
Likewise for bug reports. If you have incredibly intechnical users, you're never going to get a meaningful bug report from them. But you can educate them on what things would be useful. However, if they have a hard time with copy & paste, you're not going to get a stack trace or a screenshot from them. You do have to go sit with them to watch repro steps. There are products out there that can help with this though. For example, Atlassian Bonfire is a great way for users to submit bug details without having to be too technical. Or you can use something like Adobe Captivate and they can record a repro session (so you can watch the steps asynchronously).
Almost all users can be educated in the ways of better bug reporting, however no user will EVER always give you all the details you need. Even developers can't always do that without more often than not providing too much detail. I have found that although bug reports from untechnical users are the least detailed, they're also usually the most flexible with their expectations (not always). You may have to do a lot more user babysitting to extract detail, but you probably will also have fewer feedback cycles on the back end. More technical users have a stronger idea of how things ought to work, and so you'll spend less time up front, but probably more time walking in a specific requirement.
There's inconvenient, then there's inconvenient. Most people would probably put up with a 50% increase on the length of their commute to take public transportation. That's not what would happen though. It works fine in the city and if sufficiently bought into, in the immediate suburbs. But if you live an hour outside the city, and your job is 45 minutes away by car, but also about the same distance outside the city, the best designed mass transit system is going to take 2+ hours to get you to work (unless for some reason specifically optimized for your particular endpoints). Population density outside of cities is just not high enough in the states to make mass transit viable unless you going to or from the city.
Do four-star restaurants suck simply because your food doesn't come for 25 minutes while McDonald's could have given you a Big Mac in 60 seconds?
If I have to wait for that during my 30 minute lunch break, then yeah, a four star restaurant sucks if it takes that long to bring me my food. But mass transit isn't a four star restaurant. It's vending machine that sells you a $4 wilty premade salad with fixed ingredients and dressing, and you have to wait 30 minutes for it to come out, compared to the salad bar across the street where you put together your own salad with the ingredients you like in the ratios you choose. It costs $1 more, but you get it as quickly as you can make it.
Please define inlining HTML. Do you mean this: <?php/*...*/ ?>someHTML<?php/*...*/
Or do you mean this: <?php echo "someHTML";
Or both?
Presumably you don't mean that every little bit of single-resource-specific markup should be a file read or database hit. The I/O requirements would ruin performance even with OS level disk cache available. I could see the case for low-usage large text blocks (such as a privacy policy or TOS) being in their own standalone file which if fpassthru()'d at runtime. But if it's not low-usage, it probably belongs in cache, and if it is low usage, the cache should be smart enough to notice this and expire it early. For example, APC keeps a hitcount on each file and expires the files with the lowest hitcounts when it's out of memory, and if that still causes you troubles, you can use filters to exclude paths you know don't benefit much from caching.
It's interesting that you feel iOS interface is easier to use. I suspect this is more about habituation and accustomisation to your current platform's UI tendencies than it is about one UI paradigm being markedly better than the other.
By way of support, I'll say that I first had an iPhone (3G), and got a Nexus One after that. I felt lost for a little bit using the Android UI, but after a few days, I had the hang of it. Now when I go back and use iOS, it's like every app puts the Back button in a different place, and the Settings button in a different place (if it's in the app at all, it might be off in System Settings). Getting around in apps is a constant scavenger hunt. How many freaking taps does it take to enable airplane mode? Or lock orientation. And always having to drag around home screen icons to keep them organized, what a pain. Why do all the home screen icons have to be fitted in the upper left, why can't I lay them out however I choose? Why can't I have an empty homescreen between two other homescreens? Why can't I have homescreens to the left of the default homescreen? What's with the limit on number of apps in a folder? And so on. These things all frustrated me sufficiently that when I had gone back to my iPhone for a few days while working on a particular development effort, I was glad to get out of that mish mash of a UI (iOS) and back to something that makes more sense to me (Android, which I'm accustomed to).
My point is that what you use the most is what is the easiest to use. Some people are power users and like to customize every aspect of their phone. Some people just want to read Twitter and check their email, and don't care about any of that stuff. Or in other words, different strokes for different folks.
I don't get it, how does your bank charge you more for a transaction than the price of the transaction? Do you have one of those setups where every purchase is rounded up to the next dollar and the difference is put in a savings account / donated to charity / etc.?
If not, why on earth do you still have an account with a bank that would just steal from you like this?
There was an issue with the NYPD being upset that they couldn't film the protests in order to provide a fuller context to their actions.
Your link sure makes it sound like the NYPD were actively engaged in recording activity in and around Zuccotti park related to the OWS protests. Here a blog author wonders if this is illegal, but I didn't see anything that said the NYPD were not recording, and in fact it suggests they were recording as actively as they had the resources to be able to do so.
It was probably a smart move to have waited this long to post that link so your FUD could be out there without refutation for so long. Saved some karma on that I bet.
And as long as the volunteer does a reasonable job of balancing their volunteering and their work commitments, you're probably right that most small companies don't have much problem with it. The problem arises when the volunteer always prioritizes each fire call over their work duties. There are many fire calls which are non-emergency calls. Nobody is in imminent peril. If you drop your extremely urgent work to put up traffic cones because there's a tree down on some back road, you're doing a terrible job of balancing this.
We had a press operator who was like that. Any time his fire radio squawked he was out the door. Because he was a press operator this meant several things: 1) the people downstream from him in the work cycle ended up with nothing to do - the paper cutter can't cut unprinted paper, the binders / gluers / folders can't fold uncut paper, the packagers can't box up and ship unfinished product. 2) when he started the print back up again, the press often was not shut down very well, it wasn't properly cleaned, sometimes paper or ink was still in the press, etc. 3) even when 1 and 2 were not factors, interrupting a print run and starting it up again causes a lot of wasted materials; it takes a while on presses of that era to get the colors right, you might spend as long as an hour getting the ink evenly distributed, registration aligned properly, and the right amount of ink being put down (this was affected by many factors such as the kind of paper, but also, including temperature, humidity, and the viscosity of the particular can of ink you opened, so you couldn't just use yesterday's settings, or even always settings from a few hours ago). A lot of material gets thrown out while you're walking those settings in, never mind the time it takes.
They had to set limits with the guy, only calls of a certain severity, only after a certain number of calls, etc. It wasn't that they wanted someone whose house was on fire to have to wait 10 more minutes while his possessions were destroyed, it was just that this press operator did a terrible job of balancing work / volunteer obligations. He fought them over the limits (eg, claiming he was being singled out) and eventually forced a corporate policy such that those other volunteers in the company who were doing a good job of balancing their commitments now lost that control over which fire calls they could respond to. And whereas the company used to quietly forgive the time on their timecard (basically paying them to be at a fire call), now that they had an official policy, that policy was very strict about pay practices during a call (for liability reasons, if they're paying you and you get injured, that may end up being worker's comp).
Anecdotes aren't that meaningful. Not every company should succeed. If they're outgrowing their available talent pool, the appropriate path to success for them is not to abuse their employees with long work hours. If they really have tapped out the local talent pool, they should open a satellite office somewhere they can find more talent.
Re Ignorance: There has been a lot of misunderstanding towards mozilla "memory usage" over the years because users can't figure out that each of the 100 tabs they have open consumes a certain amount of memory. And several of those tabs, running Adobe Flash in the background, simply bring their system to it's knees.
I'm currently testing a website in various browsers. I've had Firefox and Chrome both open for a few days. Firefox has only had one tab open during this time (the site I'm testing), while I've been using Chrome for active browsing (two Gmail sessions, Google+, Google Reader, the site I'm testing [in several tabs], and various searches on StackOverflow, RFC's and the like).
Firefox's current memory usage: 692mb (never had more than 1 open tab, just loaded pages periodically when I needed to test something). Chrome's current memory usage: 200mb (currently 11 open tabs, actively browsing for days).
Firefox does have memory issues. After a few days of actively using Firefox, I need to shut it down and open it back up to let some other programs have some RAM. Chrome is also just a lot faster in many ways. Faster rendering of pages, faster execution of JavaScript, faster startup, faster opening of new tabs, more responsive to UI events (eg, Firefox takes 2 seconds to tear off a tab, Chrome the tab is torn off as I drag my mouse)
I agree, platform competition is good for all involved. I sincerely hope Firefox sticks around and remains popular. I resisted Chrome at first too, but when you've used it for a while, Firefox just feels sluggish. Also, when Chrome upgrades itself, my extensions all keep working. It seems like every time I fire up Firefox, some new extension is broken and I have to go hunting for a new version.
Particularly in IT, you can't just bring in part timers to bridge the gap when you need more work done than your current staff can accomplish in 40 hours. Sometimes it takes a month or more to bring a new guy up to speed.
The reason they have mandatory time and a half rules is because typically the lower you are on the hourly wage scale, the more badly you need the job, and the easier you are to replace. Without this, companies would just demand 80 hours or more from their employees rather than hiring new employees. Each employee has a fixed cost, so one person doing 80 hours work is a higher profit than two employees each doing 40 hours work at the same salary. If you don't agree to that work schedule, they'll replace you, and soon all jobs in your skill range require this.
The point is to incentivize employers to maintain a reasonable work/life balance for their employees, while not totally crippling them when there's a short term work load glut. Time and a half over 40 hours strikes me as a particularly good balance. Many hourly workers are happy to have the bonus pay at that rate, while employers are typically willing to pay it since this work glut represents unusual profitability on their part. If you're consistently paying 20 hours of overtime, then you probably should increase the size of your work force.
Unfortunately most IT jobs are already overtime exempt. At first I misread the title and though, "About time they made non-IT managers eligible for overtime!" What I mentioned above about unreasonable work schedules is pretty true in many corners of the industry. If you're a software tester or software engineer, chances are you have felt pressured to donate time to the company on a regular basis. Each extra hour they can squeeze out of you just increases their ROI on your salary, so they're incentivized to find the highest number of hours they can convince their workforce to commit. In many shops, you'll be consistently found to be under-producing if you go home before 10 or 12 hours, and you may be let go as a result.
Apple's mobile success is due at least in part to the vibrancy of their app store. Now that there are 2 Android handsets for every iOS handset, and there are more Java developers than Objective C developers out there, the quality apps either also support Android, or sometimes come to Android first, and possibly only.
That will hurt Apple's presence, as it may already be doing - it looks like Samsung may be outselling Apple (which probably explains all the specious legal acrobatics Apple is tossing at Samsung).
The point is that mobile games aren't currently rated with ESRB ratings, which means that ESRB isn't making money off the submissions process ($800 for a small game, $4,000 for a large game).
Basically ESRB is pissed they're not making bank on this trend, and they'd like the app store owners (Google, Apple, Amazon, Microsoft, RIM) to require ratings for games before the game is available for sale.
I should add, that the moment I heard that Google was releasing a smartphone OS aka Android, my first thought was "Nice. Now google can spy on everyone when they are away from their computer and follow their movements in the physical world."
It should be noted that CarrierIQ is not Google and is not related to Google. This is a third party which makes a rootkit/spyware app that carriers have installed on handsets that they sell (it is not part of a vanilla Android install).
That's a little like saying that Michael Jordan can jump really high, so if you work hard enough you can too. Most people aren't Michael Jordan, so no matter how hard they try they're never going to jump that high. But even if they were such a one-in-7-billion people, they're not in the right place at the right time. Golden opportunities are rare, and very minor changes in circumstance would have had Steve Jobs be a name we recognize only once we've looked it up on Wikipedia, and that's if he made the notability cut. He succeeded because all the big money bet in a different direction, and they lost that bet.
If you use Steve as an example that money isn't required for success, you might as well be advocating that people play the lottery instead, the odds are not as long, and you could then take your winnings and found a company with a respectable shot at success.
Slashdot Mirror
I can't answer for Microsoft or others, but if I had to guess, I'd say that although the class of vulnerability was know about, it wasn't considered to be much threat; the chances of this happening under normal circumstances are vanishingly small. So it was probably considered more of an artifact of the implementation than something exploitable. It seems like apparently only yesterday that someone put together that these linked hash maps are used in pretty much every web scripting language out there, and it's not very hard to purposely generate collisions.
Because growth is O(n**2), attacks with a smaller payload will hurt a lot less than attacks with a larger payload. Until recently it was probably somewhat hard to come up with the bandwidth necessary to keep even a mid-sized operation occupied. But as bandwidth availability has increased, this has become easier to come by. Again, just guessing, but this strikes me as something which may have been previously attackable only in theory, and suddenly technology advanced to the point that the attack became viable without people really noticing until just now.
Also, despite the article title, Microsoft's patch was off-schedule, not out-of-band. As another poster pointed out, out-of-band would be if they had to distribute the patch via an unusual distribution method (such as by having to ship CDs out).
More importantly, although lookup is O(n), the insert growth is O(n**2). The request environment preparation for many web languages such as PHP, .NET, Java, Ruby, and Python will time out before script execution even begins (while maxing out a CPU for whatever the request timeout is, usually at least 30 seconds).
The vulnerability is essentially that it's easy to generate intentional key hash collisions for these hash table implementations. This class of vulnerability has been known about since at least 2003.
Source: http://www.nruns.com/_downloads/advisory28122011.pdf
Apple Care is better though
No, it's really not.
They have stores all over the world
Yeah, just like most big brand stores, but this is not very relevant because the store you bought an item at is presumably local to you, so who cares if they also have a location in East Jabyyp? Unless you regularly travel a lot, the chances of this being useful is pretty low.
if you are supported, they an tell you that
There's the problem. It's not like Apple Care is one of those cell phone insurance plans where it covers anything that can go wrong. Plenty of things can go wrong that they will be happy to tell you is not covered - even stuff that is not a wear-and-tear fault. Try to get a reasonably expensive part replaced, such as a video card, and they'll tell you how they found some dust in your chassis, so it overheated and it's your fault for not keeping it clean (nevermind that you can't open the chassis on most modern macs without voiding the warranty anyway). At least that's what they told me for my wife's 3 month old iMac.
Likewise my brother's 1 year old Macbook Pro had a recognized fault with its video card. It would sometimes just refuse to produce any video, sometimes to the built-in LCD, sometimes to the video out port, sometimes to both. Plenty of people with the same generation MBP had the same problem. He took it in to get it repaired, and was initially told it was covered since it was a known problem. When he went to pick it up a week later, they wanted $800 in parts in labor - even though he had been told it was going to be a covered repair. Their reason? The chassis had a scratch on it - seriously. They claimed this scratch (in an aluminum chassis) had caused the damage. They went ahead and made the repair without consulting him, and now refused to return his laptop until he coughed up the cash.
Also, if it's not this year's model, they're not going to have replacement parts on hand, and it's going to be 1-2 weeks before you can get that replacement part.
But it seems like a good idea for someone who isn't tech savvy and doesn't want to bother their friends for help
That's probably true. If you don't know how to use your computer, the Geniuses can tell you how to double click. Make sure to call ahead for an appointment, they're booked until next week, but they'll be happy to let you sit in their gallery store for 45 minutes after your appointment time while you have nothing else to do but decide if maybe buying a new one is a better path than being without a computer for two weeks while your old one is getting fixed on your own dime despite having an extended warranty.
Hasbro's trademark dispute against Asus on "Transformer Prime" is remarkably weak. It's a similar name, but in a completely different industry. Trademark is industry specific, so unless Hasbro beats Asus to market with an Autobots themed tablet, this is just saber rattling. But if by some incredible feat they do get this blocked on name, it's just a name, Asus could rename it and sell away overnight.
Apple does the same thing, except they let you upgrade the core OS version number, you just don't get access to the hottest new wizbang features. For example, Siri won't run on stock iPhone 4 phones even though hackers have proven it's not a hardware restriction.
If you buy Google's flagship devices, they get the OS updates without the handset manufacturers being able to drag their feet to prompt you to buy new instead of upgrade existing.
In cases like the original Galaxy Tab from Samsung, this seems like it's false advertising. When they released this device running Gingerbread, they promised it would get a Honeycomb makeover. When Google was tight-fisted with Honeycomb source saying, "Wait for ICS," Samsung said they'd stick it out for ICS instead. However now that ICS is out, they're going back on their word and apparently OS updates for that brand of tablet are now dead at two versions behind.
This is the reason I've stopped buying Samsung hardware, I can't trust them to honor their word about when they'll upgrade the devices since they often promise to and rarely do. Otherwise I'd own a Galaxy Tab 10.1, it's a pretty slick device; I just don't want a dead-end path on upgrades. I plan to get the Asus Transformer Prime instead when it becomes available (glad I waited, Prime is much better).
You cynical man. For all you know, upper management have a budget flush with cash and have singled out someone in the hard working but unacknowledged IT department for a raise and a promotion.
Don't forget the free pony.
Its partly this that has led to the outsourcing of support to experts with SLAs that include fix times
Yeah, but this sounds good on paper but in practice doesn't really help much. Our support contracts had SLAs on them too. SLAs tend to be either extremely specific (eg, will not include things like the time it takes to restore something from backup, time spent waiting on replacement hardware [for software vendors], and so forth), include a lot of wiggle room (TTF SLAs categorize problems by severity and different severities have different TTF's, so your problem will get classified as the severity for how long it took to solve rather than the other way around), include verbiage like "95% of the time we'll meet objective X," when of course the remaining 5% is the most costly to your business, or simply don't include penalties commensurate with the damage to your company.
Companies which write SLAs which they end up violating don't stay in business or else the SLA had no teeth to begin with. In actual practice you'll find most SLAs are very easy to keep.
As to your counter anecdote, this doesn't seem to line up very well with the discussion at hand. You were the high priced consultant and you made recommendations which were not followed. Any organization is at risk of thick headed territorial people who won't heed advice of those who are more experienced than them. Support contracts are not for "Help us build an infrastructure" problems, they're for "We have a good infrastructure, we want to fire the guys who built it and pay you a fraction of it to help out only when something goes wrong." We're not talking about job outsourcing, we're talking replacing jobs with support instead.
So they fire some people, and they start having problems.
Critically a lot of companies will tread down this road cautiously because they realize how critical their IT infrastructure is to their business. So they fire some people, but they don't have any problems. At first new projects just take a bit longer to materialize.
The problem is that like a well maintained car, a well maintained infrastructure will probably hum along smoothly for a while with reduced maintenance. But technical debt (maintenance debt?) will build up, and when things go critical, they'll go bad much more quickly, and take longer to recover.
The major fallacy many big companies fall into is that some of these systems have been running flawlessly for years, because they hired a competent IT staff. They look at the price of those paychecks and shiver. Why are we paying so many high priced engineers when we've never had a problem, they think.
So they reduce staff and start to rely on support contracts instead of on-site gurus. The gurus are still there to solve any oh-shit moments. But that back investment in good engineers has produced a stable infrastructure that runs with few problems for years. So they reduce staff more, pay for more support contracts, and eventually the system critical mass is greater than the engineers who can support it. It's no problem until it's a problem.
Eventually something minor goes wrong, but nobody notices or if they do it's not really their field of expertise so they don't understand it's minor now but could escalate. When it does, something else goes wrong, and a cascade effect takes out more and more systems. With a full staff, you have enough guys that when the critical mass is reached, they can start defensive measures and get things back in working order in no time. With support staff only, things are going wrong faster than they can deal with it.
"Call on our support contracts," shout the bosses! So now your on-site staff are all on hold instead of troubleshooting. When they get through to someone, they have to spend the first hour or two describing their infrastructure to the technician on the other end, who starts making random suggestions that maybe help, but probably don't.
My anecdote on this front is a company I used to work for. It's a long read, but demonstrates the failures at several levels which is the direct result of this kind of thinking. The Oracle transaction log disk was getting full. Some warnings came in, but disks running low on space was an every day occurrence, we'll send an email to the person on record as being responsible for those servers, and troubleshoot why the "Executive Dashboard" is responding a bit slow today (it's for the execs, it's automatically high priority). Except that person is currently aboard an airplane on his way to help reduce staff in east Asia, he'll be incommunicado for the next 19 hours or more.
It seems like an innocent enough problem, it's just a log disk, the worst thing that could happen is we lose some logs, right? Whoops, transaction logs are pretty important for Oracle. The fact that the disk is filling up at all is itself an indicator that something bigger is wrong; this shouldn't happen. But critically once the disk does fill up, Oracle will enter read-only mode. Or it should. This time it doesn't, it shuts down. BOOM, offline. So down goes SAP. With SAP down, our entire business is offline. We can't take orders, we can't ship orders, we can't pay bills, we can't pay paychecks, the hourly workers whose shift is starting can't even clock in. Some buildings with tighter badge access can't even be entered unless someone inside opens an emergency door to let someone in.
Once the transaction log disk was full, Oracle will no longer start up, it needs some space on the log disk to log startup-related transactions. Two hours on hold with Oracle Gold Pressed Latinum level support they finally get an engineer. Wow, this is something he's never seen before, Oracle should have gone into read-only mode before this happened! The only solution anyone can seem to think of is to get some bigger disks for the transaction logs, clone the data over to these new disks and give the startup another go. We have hot spares on a shelf, but nobody knows this. Finding disks requires a different support contract, they can have disks out to us tomorrow. Yeah, that's not going to cut it. Someone literally drives out to a distribution warehouse. Two more hours down (they actually send two different guys in different cars with instructions to take different routes in case one runs into traffic or gets in an acciden
in any semi decent bar on a friday night there'll be about 20 teenagers filling
Not in the US! It'd be a mix of bar flies, trannies, and hot coeds drinking for free by using the power of suggestion on lonely guys looking to score. But not teenagers, no sir chief!
At first I thought you were going for funny. But your points seem serious, so I don't think so any longer.
To a certain extent you have to know your users. Some classes of user are simply not of the mindset to give you requirements or meaningful bug reports. The responsibility to bridge this gap belongs to the project manager or some designee if the project is of sufficient scale. Sometimes for small projects, the developer is the project manager, so that's the developer's responsibility.
Users/Customers do not have requirements they have PROBLEMS
Right, and the PM first details those problems, then propose to the users possible solutions for those problems. Depending on what level of knowledge the users have about the type of system you're going to be creating, this is voiced to the users in various levels of technical detail. If the user is your grandmother trying to create an online space for her knitting group, you avoid jargon and talk about things at extremely high levels, "post pictures of their projects," "have a calendar of upcoming get-togethers and whose house it's at," etc. If the user is the CFO of your company, you talk about GL, profitability reports, and so forth. If the user is the head of operations you talk about data centers, topology maps, border routing, and stuff like that.
This is why there's a difference between user requirements and technical requirements. User requirements are meaningful to the user, and technical requirements are meaningful to the developers. Users inform the user requirements, user requirements inform the technical requirements, and technical requirements inform the developers.
Of course not every project is of a scope and scale for all of this to be formal. Sometimes it's ok to just sit down with the user, get some thoughts together, bang together a POC, and ask the user for feedback, polish, feedback, repeat. But the different types of requirements still exist, they're just in someone's head instead of on paper, and they may be a continuous work in progress. You can't create something new without knowing what it's supposed to do though.
Likewise for bug reports. If you have incredibly intechnical users, you're never going to get a meaningful bug report from them. But you can educate them on what things would be useful. However, if they have a hard time with copy & paste, you're not going to get a stack trace or a screenshot from them. You do have to go sit with them to watch repro steps. There are products out there that can help with this though. For example, Atlassian Bonfire is a great way for users to submit bug details without having to be too technical. Or you can use something like Adobe Captivate and they can record a repro session (so you can watch the steps asynchronously).
Almost all users can be educated in the ways of better bug reporting, however no user will EVER always give you all the details you need. Even developers can't always do that without more often than not providing too much detail. I have found that although bug reports from untechnical users are the least detailed, they're also usually the most flexible with their expectations (not always). You may have to do a lot more user babysitting to extract detail, but you probably will also have fewer feedback cycles on the back end. More technical users have a stronger idea of how things ought to work, and so you'll spend less time up front, but probably more time walking in a specific requirement.
There's inconvenient, then there's inconvenient. Most people would probably put up with a 50% increase on the length of their commute to take public transportation. That's not what would happen though. It works fine in the city and if sufficiently bought into, in the immediate suburbs. But if you live an hour outside the city, and your job is 45 minutes away by car, but also about the same distance outside the city, the best designed mass transit system is going to take 2+ hours to get you to work (unless for some reason specifically optimized for your particular endpoints). Population density outside of cities is just not high enough in the states to make mass transit viable unless you going to or from the city.
Do four-star restaurants suck simply because your food doesn't come for 25 minutes while McDonald's could have given you a Big Mac in 60 seconds?
If I have to wait for that during my 30 minute lunch break, then yeah, a four star restaurant sucks if it takes that long to bring me my food. But mass transit isn't a four star restaurant. It's vending machine that sells you a $4 wilty premade salad with fixed ingredients and dressing, and you have to wait 30 minutes for it to come out, compared to the salad bar across the street where you put together your own salad with the ingredients you like in the ratios you choose. It costs $1 more, but you get it as quickly as you can make it.
Please define inlining HTML. Do you mean this: <?php /*...*/ ?>someHTML<?php /*...*/
Or do you mean this: <?php echo "someHTML";
Or both?
Presumably you don't mean that every little bit of single-resource-specific markup should be a file read or database hit. The I/O requirements would ruin performance even with OS level disk cache available. I could see the case for low-usage large text blocks (such as a privacy policy or TOS) being in their own standalone file which if fpassthru()'d at runtime. But if it's not low-usage, it probably belongs in cache, and if it is low usage, the cache should be smart enough to notice this and expire it early. For example, APC keeps a hitcount on each file and expires the files with the lowest hitcounts when it's out of memory, and if that still causes you troubles, you can use filters to exclude paths you know don't benefit much from caching.
So Digitude Innovation is the new SCO, which makes Apple the new Microsoft.
It's interesting that you feel iOS interface is easier to use. I suspect this is more about habituation and accustomisation to your current platform's UI tendencies than it is about one UI paradigm being markedly better than the other.
By way of support, I'll say that I first had an iPhone (3G), and got a Nexus One after that. I felt lost for a little bit using the Android UI, but after a few days, I had the hang of it. Now when I go back and use iOS, it's like every app puts the Back button in a different place, and the Settings button in a different place (if it's in the app at all, it might be off in System Settings). Getting around in apps is a constant scavenger hunt. How many freaking taps does it take to enable airplane mode? Or lock orientation. And always having to drag around home screen icons to keep them organized, what a pain. Why do all the home screen icons have to be fitted in the upper left, why can't I lay them out however I choose? Why can't I have an empty homescreen between two other homescreens? Why can't I have homescreens to the left of the default homescreen? What's with the limit on number of apps in a folder? And so on. These things all frustrated me sufficiently that when I had gone back to my iPhone for a few days while working on a particular development effort, I was glad to get out of that mish mash of a UI (iOS) and back to something that makes more sense to me (Android, which I'm accustomed to).
My point is that what you use the most is what is the easiest to use. Some people are power users and like to customize every aspect of their phone. Some people just want to read Twitter and check their email, and don't care about any of that stuff. Or in other words, different strokes for different folks.
I don't get it, how does your bank charge you more for a transaction than the price of the transaction? Do you have one of those setups where every purchase is rounded up to the next dollar and the difference is put in a savings account / donated to charity / etc.?
If not, why on earth do you still have an account with a bank that would just steal from you like this?
There was an issue with the NYPD being upset that they couldn't film the protests in order to provide a fuller context to their actions.
Your link sure makes it sound like the NYPD were actively engaged in recording activity in and around Zuccotti park related to the OWS protests. Here a blog author wonders if this is illegal, but I didn't see anything that said the NYPD were not recording, and in fact it suggests they were recording as actively as they had the resources to be able to do so.
It was probably a smart move to have waited this long to post that link so your FUD could be out there without refutation for so long. Saved some karma on that I bet.
And as long as the volunteer does a reasonable job of balancing their volunteering and their work commitments, you're probably right that most small companies don't have much problem with it. The problem arises when the volunteer always prioritizes each fire call over their work duties. There are many fire calls which are non-emergency calls. Nobody is in imminent peril. If you drop your extremely urgent work to put up traffic cones because there's a tree down on some back road, you're doing a terrible job of balancing this.
We had a press operator who was like that. Any time his fire radio squawked he was out the door. Because he was a press operator this meant several things: 1) the people downstream from him in the work cycle ended up with nothing to do - the paper cutter can't cut unprinted paper, the binders / gluers / folders can't fold uncut paper, the packagers can't box up and ship unfinished product. 2) when he started the print back up again, the press often was not shut down very well, it wasn't properly cleaned, sometimes paper or ink was still in the press, etc. 3) even when 1 and 2 were not factors, interrupting a print run and starting it up again causes a lot of wasted materials; it takes a while on presses of that era to get the colors right, you might spend as long as an hour getting the ink evenly distributed, registration aligned properly, and the right amount of ink being put down (this was affected by many factors such as the kind of paper, but also, including temperature, humidity, and the viscosity of the particular can of ink you opened, so you couldn't just use yesterday's settings, or even always settings from a few hours ago). A lot of material gets thrown out while you're walking those settings in, never mind the time it takes.
They had to set limits with the guy, only calls of a certain severity, only after a certain number of calls, etc. It wasn't that they wanted someone whose house was on fire to have to wait 10 more minutes while his possessions were destroyed, it was just that this press operator did a terrible job of balancing work / volunteer obligations. He fought them over the limits (eg, claiming he was being singled out) and eventually forced a corporate policy such that those other volunteers in the company who were doing a good job of balancing their commitments now lost that control over which fire calls they could respond to. And whereas the company used to quietly forgive the time on their timecard (basically paying them to be at a fire call), now that they had an official policy, that policy was very strict about pay practices during a call (for liability reasons, if they're paying you and you get injured, that may end up being worker's comp).
Anecdotes aren't that meaningful. Not every company should succeed. If they're outgrowing their available talent pool, the appropriate path to success for them is not to abuse their employees with long work hours. If they really have tapped out the local talent pool, they should open a satellite office somewhere they can find more talent.
Re Ignorance: There has been a lot of misunderstanding towards mozilla "memory usage" over the years because users can't figure out that each of the 100 tabs they have open consumes a certain amount of memory. And several of those tabs, running Adobe Flash in the background, simply bring their system to it's knees.
I'm currently testing a website in various browsers. I've had Firefox and Chrome both open for a few days. Firefox has only had one tab open during this time (the site I'm testing), while I've been using Chrome for active browsing (two Gmail sessions, Google+, Google Reader, the site I'm testing [in several tabs], and various searches on StackOverflow, RFC's and the like).
Firefox's current memory usage: 692mb (never had more than 1 open tab, just loaded pages periodically when I needed to test something).
Chrome's current memory usage: 200mb (currently 11 open tabs, actively browsing for days).
Firefox does have memory issues. After a few days of actively using Firefox, I need to shut it down and open it back up to let some other programs have some RAM. Chrome is also just a lot faster in many ways. Faster rendering of pages, faster execution of JavaScript, faster startup, faster opening of new tabs, more responsive to UI events (eg, Firefox takes 2 seconds to tear off a tab, Chrome the tab is torn off as I drag my mouse)
I agree, platform competition is good for all involved. I sincerely hope Firefox sticks around and remains popular. I resisted Chrome at first too, but when you've used it for a while, Firefox just feels sluggish. Also, when Chrome upgrades itself, my extensions all keep working. It seems like every time I fire up Firefox, some new extension is broken and I have to go hunting for a new version.
Particularly in IT, you can't just bring in part timers to bridge the gap when you need more work done than your current staff can accomplish in 40 hours. Sometimes it takes a month or more to bring a new guy up to speed.
The reason they have mandatory time and a half rules is because typically the lower you are on the hourly wage scale, the more badly you need the job, and the easier you are to replace. Without this, companies would just demand 80 hours or more from their employees rather than hiring new employees. Each employee has a fixed cost, so one person doing 80 hours work is a higher profit than two employees each doing 40 hours work at the same salary. If you don't agree to that work schedule, they'll replace you, and soon all jobs in your skill range require this.
The point is to incentivize employers to maintain a reasonable work/life balance for their employees, while not totally crippling them when there's a short term work load glut. Time and a half over 40 hours strikes me as a particularly good balance. Many hourly workers are happy to have the bonus pay at that rate, while employers are typically willing to pay it since this work glut represents unusual profitability on their part. If you're consistently paying 20 hours of overtime, then you probably should increase the size of your work force.
Unfortunately most IT jobs are already overtime exempt. At first I misread the title and though, "About time they made non-IT managers eligible for overtime!" What I mentioned above about unreasonable work schedules is pretty true in many corners of the industry. If you're a software tester or software engineer, chances are you have felt pressured to donate time to the company on a regular basis. Each extra hour they can squeeze out of you just increases their ROI on your salary, so they're incentivized to find the highest number of hours they can convince their workforce to commit. In many shops, you'll be consistently found to be under-producing if you go home before 10 or 12 hours, and you may be let go as a result.
Apple's mobile success is due at least in part to the vibrancy of their app store. Now that there are 2 Android handsets for every iOS handset, and there are more Java developers than Objective C developers out there, the quality apps either also support Android, or sometimes come to Android first, and possibly only.
That will hurt Apple's presence, as it may already be doing - it looks like Samsung may be outselling Apple (which probably explains all the specious legal acrobatics Apple is tossing at Samsung).
The point is that mobile games aren't currently rated with ESRB ratings, which means that ESRB isn't making money off the submissions process ($800 for a small game, $4,000 for a large game).
Basically ESRB is pissed they're not making bank on this trend, and they'd like the app store owners (Google, Apple, Amazon, Microsoft, RIM) to require ratings for games before the game is available for sale.
I should add, that the moment I heard that Google was releasing a smartphone OS aka Android, my first thought was "Nice. Now google can spy on everyone when they are away from their computer and follow their movements in the physical world."
It should be noted that CarrierIQ is not Google and is not related to Google. This is a third party which makes a rootkit/spyware app that carriers have installed on handsets that they sell (it is not part of a vanilla Android install).
That's a little like saying that Michael Jordan can jump really high, so if you work hard enough you can too. Most people aren't Michael Jordan, so no matter how hard they try they're never going to jump that high. But even if they were such a one-in-7-billion people, they're not in the right place at the right time. Golden opportunities are rare, and very minor changes in circumstance would have had Steve Jobs be a name we recognize only once we've looked it up on Wikipedia, and that's if he made the notability cut. He succeeded because all the big money bet in a different direction, and they lost that bet.
If you use Steve as an example that money isn't required for success, you might as well be advocating that people play the lottery instead, the odds are not as long, and you could then take your winnings and found a company with a respectable shot at success.