> How about this though. It *is* a desktop replacement, and in that, with its interactive applications and notifications means that perhaps the ideal here is to create a modern day real world interactive desktop
Hopefully they haven't reused the code from the previous interactive desktop that most people have determined never to use, after the eighteenth or nineteenth "desktop recovery" message.
A friend of mine came to me with a problem. His grandparents' TV just went out, and they need to buy a new one for their enclosed media center. It was an old non-widescreen TV, and pretty much anything you can buy now is widescreen. Given that the old TV was 20 inches, what size TV do they order that will fit in the cabinet? I'll even give you, the ratio of width to height for old TVs was 4:3, and the ratio of width to height of widescreen TVs is 16:9. (Some allowance has to be made for the bezel as well.) TV size is measured diagonally.
I solved it for him (elementary trigonometry) but I think his grandparents ended up going to the store with a tape measure. That works too, I guess.
Your backup library has a certain number of drives of a certain maximum throughput. Your backup software divides up the data set into a number of jobs equal to the number of drives, and assigns each job to a drive. But the software can only start one job at a time, so on a graph of collective throughput per unit time, you see the total throughput ramp up to maximum drives, then ramp back down as each individual job finishes. The graph represents collective throughput at a particular time. (Say, in Mbytes/second.) The steepness of the curve represents how fast drives can get online, increasing the collective throughput (Mbytes/second/second) (You can observe empirically that the curve falls off with the same slope as individual jobs complete, which makes sense if the jobs are roughly the same size.) The area under the curve represents the amount of data in the data set. (Mbytes.) Thus function, derivative of function, and integral of function.
Immediately, you can see that the area under the curve for a particular data set size will remain constant, as the size of the data set is fixed. You can change the shape of the curve, which also changes the end time, by improving the rate at which drives can come online. You can also postulate that given a certain rate at which drives come online, and a given drive throughput, there is a maximum number of drives that are practical for a given data set.
The purpose of this analysis (math left as an exercise to the student) was to convince engineers that the best tactic to solving slow performance was in improving the task management part of the backup software, and that given the current conditions, more hardware wouldn't help.
Example two:
A very large, very complex installation is significantly less reliable than than it should be.
The vendor says, each component has an MTBF of thousands of hours, therefore we shouldn't see the failure rate we've been seeing. (Which was in tens of hours.) But assuming every component has to be online to complete the job, and that a failure of any component causes the job to fail, the MTBF of the system is considerably less than the MTBF of a given individual component. Given the monstrous length of the jobs and tremendous number of components, it could be demonstrated mathematically that on average, one job in three would fail. The solution was to redesign the system with "hot spare" components and changes to software to take advantage of them, so that it would take several component failures to cause a job failure. The reason this had not been done previously was the perception that a component MTBF in thousands of hours made the issue of component failure unimportant. (They were also wildly optimistic on component duty cycle, but that's another story.)
The difference between knowing math and not knowing math is (in my opinion) the difference between being an engineer, able to solve problems, take measurements, understand what one is seeing, and draw conclusions, and being a technician, doing basic triage and following rote procedures written by someone else (probably an engineer). If you have engineering aptitude, you may be able to get by without math the same way a carpenter can build a house without knowing how to use a hammer. Mostly, he gets someone else to do the hammering for him.
I think it was supposed to. The story was carefully crafted to present an impossible problem with no solution, and then to portray people's reaction to it. It was intended to mess you up.
> Usually sci-fi provides adventure with happy endings for everyone.
What?? Seriously? Maybe today, (although I think I could find lots of counter examples) but there was a time when it wasn't science fiction if it didn't make you feel bad. Try Harlan Ellison's "Dangerous Visions" or any issue of Fantasy and Science Fiction magazine from 1967 to the late seventies (after that I can't say). Or anything by Ellison, Phillip K. Dick, William Gibson, a dozen others.
The most depressing scifi would be a multi-way tie, I'm thinking. I'd have to divide it up as "most relentlessly depressing", "most unintentionally depressing", "most depressingly unnecessary twist ending", "most depressing attempt at humor", "most depressingly, distressingly inept" and probably others.
Now, the most *frightening* scifi book I've ever read was Cory Doctorow's "Down and out in the Magic Kingdom". Although I get the impression he did not mean it so.
I'm a little surprised that IBM didn't buy their portfolio a long time ago. Unless they were waiting for the price to go down. Come to think of it, it probably has.
Right. At first I had an errant fantasy that companies were finally realizing that outsourcing their core competency really wasn't a good idea, (I should have known better) but reading TFA it sounds like a combination of (a) "swiss army knife" IE, one person to get burned out doing the work of an entire department at tremendous cost savings, and (b) prepubescent Cloud Bubble ramp-up. So, really, nothing new here.
Well, one of the problems with crappy monkey code is that after it's in place it takes an Act of God (or a sufficient number of very public, embarrassing failures) to get it removed. Crappy monkey code tends to breed. Code that's not *quite* crappy enough to require action, or code that provides crappy, unreliable resources that just aren't important enough to require attention, tend to survive in an Darwinian way.
Crappy monkey code can even reproduce by binary fission, like bacteria, through code reuse. "I know it's crappy monkey code, but it's easier to reuse it than rewrite it. Besides, IT is already used to rebooting the machines once a month."
(And thanks, "crappy monkey code" is my new favorite term.)
My daughter recently introduced me to an app called Life 360. Amongst other things, it flags all the registered sexual offenders in your area. Only makes sense that the next thing to flag would be Democrats.
I wonder about that. As a libertarian, (socially liberal, fiscally conservative) I regularly re-register to the party with the most interesting primary. I wonder how that comes out on the map?
Slashdot Mirror
> How about this though. It *is* a desktop replacement, and in that, with its interactive applications and notifications means that perhaps the ideal here is to create a modern day real world interactive desktop
Hopefully they haven't reused the code from the previous interactive desktop that most people have determined never to use, after the eighteenth or nineteenth "desktop recovery" message.
A friend of mine came to me with a problem. His grandparents' TV just went out, and they need to buy a new one for their enclosed media center. It was an old non-widescreen TV, and pretty much anything you can buy now is widescreen. Given that the old TV was 20 inches, what size TV do they order that will fit in the cabinet? I'll even give you, the ratio of width to height for old TVs was 4:3, and the ratio of width to height of widescreen TVs is 16:9. (Some allowance has to be made for the bezel as well.) TV size is measured diagonally.
I solved it for him (elementary trigonometry) but I think his grandparents ended up going to the store with a tape measure. That works too, I guess.
Example one:
Your backup library has a certain number of drives of a certain maximum throughput. Your backup software divides up the data set into a number of jobs equal to the number of drives, and assigns each job to a drive. But the software can only start one job at a time, so on a graph of collective throughput per unit time, you see the total throughput ramp up to maximum drives, then ramp back down as each individual job finishes. The graph represents collective throughput at a particular time. (Say, in Mbytes/second.) The steepness of the curve represents how fast drives can get online, increasing the collective throughput (Mbytes/second/second) (You can observe empirically that the curve falls off with the same slope as individual jobs complete, which makes sense if the jobs are roughly the same size.) The area under the curve represents the amount of data in the data set. (Mbytes.) Thus function, derivative of function, and integral of function.
Immediately, you can see that the area under the curve for a particular data set size will remain constant, as the size of the data set is fixed. You can change the shape of the curve, which also changes the end time, by improving the rate at which drives can come online. You can also postulate that given a certain rate at which drives come online, and a given drive throughput, there is a maximum number of drives that are practical for a given data set.
The purpose of this analysis (math left as an exercise to the student) was to convince engineers that the best tactic to solving slow performance was in improving the task management part of the backup software, and that given the current conditions, more hardware wouldn't help.
Example two:
A very large, very complex installation is significantly less reliable than than it should be.
The vendor says, each component has an MTBF of thousands of hours, therefore we shouldn't see the failure rate we've been seeing. (Which was in tens of hours.) But assuming every component has to be online to complete the job, and that a failure of any component causes the job to fail, the MTBF of the system is considerably less than the MTBF of a given individual component. Given the monstrous length of the jobs and tremendous number of components, it could be demonstrated mathematically that on average, one job in three would fail. The solution was to redesign the system with "hot spare" components and changes to software to take advantage of them, so that it would take several component failures to cause a job failure. The reason this had not been done previously was the perception that a component MTBF in thousands of hours made the issue of component failure unimportant. (They were also wildly optimistic on component duty cycle, but that's another story.)
The difference between knowing math and not knowing math is (in my opinion) the difference between being an engineer, able to solve problems, take measurements, understand what one is seeing, and draw conclusions, and being a technician, doing basic triage and following rote procedures written by someone else (probably an engineer). If you have engineering aptitude, you may be able to get by without math the same way a carpenter can build a house without knowing how to use a hammer. Mostly, he gets someone else to do the hammering for him.
I can appreciate that.
Business executives are bankruptcy assets? Wow.
I think it was supposed to. The story was carefully crafted to present an impossible problem with no solution, and then to portray people's reaction to it. It was intended to mess you up.
> Usually sci-fi provides adventure with happy endings for everyone.
What?? Seriously? Maybe today, (although I think I could find lots of counter examples) but there was a time when it wasn't science fiction if it didn't make you feel bad. Try Harlan Ellison's "Dangerous Visions" or any issue of Fantasy and Science Fiction magazine from 1967 to the late seventies (after that I can't say). Or anything by Ellison, Phillip K. Dick, William Gibson, a dozen others.
The most depressing scifi would be a multi-way tie, I'm thinking. I'd have to divide it up as "most relentlessly depressing", "most unintentionally depressing", "most depressingly unnecessary twist ending", "most depressing attempt at humor", "most depressingly, distressingly inept" and probably others.
Now, the most *frightening* scifi book I've ever read was Cory Doctorow's "Down and out in the Magic Kingdom". Although I get the impression he did not mean it so.
Yeah, that one really bothered me.
> "Led by a team of visionary and accomplished technology and businesses executives"
Really? Like, from where?
I'm a little surprised that IBM didn't buy their portfolio a long time ago. Unless they were waiting for the price to go down. Come to think of it, it probably has.
And really. Since when are architects called "swiss army knives"? Oh, when they have to do the actual work, not just the design. Never mind.
Parenthetically, I'd like to thank you for using "second derivative" in a sentence; I really miss calculus.
Right. At first I had an errant fantasy that companies were finally realizing that outsourcing their core competency really wasn't a good idea, (I should have known better) but reading TFA it sounds like a combination of (a) "swiss army knife" IE, one person to get burned out doing the work of an entire department at tremendous cost savings, and (b) prepubescent Cloud Bubble ramp-up. So, really, nothing new here.
Well, one of the problems with crappy monkey code is that after it's in place it takes an Act of God (or a sufficient number of very public, embarrassing failures) to get it removed. Crappy monkey code tends to breed. Code that's not *quite* crappy enough to require action, or code that provides crappy, unreliable resources that just aren't important enough to require attention, tend to survive in an Darwinian way.
Crappy monkey code can even reproduce by binary fission, like bacteria, through code reuse. "I know it's crappy monkey code, but it's easier to reuse it than rewrite it. Besides, IT is already used to rebooting the machines once a month."
(And thanks, "crappy monkey code" is my new favorite term.)
Too far away. You know that companies won't start looking at it until halfway through 2036.
> If only there were a Y2.012K bug...
Well, let's get busy and design one!
When I was doing war toys, not all that long ago, (ok, I guess it was. Where did the time go?) 40 Ghz was considered really, really high.
This is slashdot; the attribution was redundant. Most of us got it on the second line...
Chicago has more blue flags than residents.
Really? I thought it was outsourced to Shenzhen.
My daughter recently introduced me to an app called Life 360. Amongst other things, it flags all the registered sexual offenders in your area. Only makes sense that the next thing to flag would be Democrats.
I wonder about that. As a libertarian, (socially liberal, fiscally conservative) I regularly re-register to the party with the most interesting primary. I wonder how that comes out on the map?
Didn't I see this exact text in a previous article?