Defendant Apple has infringed and continues to infringe one or more claims of the ’507 patent [Patent No. 6,263,507]. Apple is liable for infringing the ’507 patent under 35 U.S.C. 271 by making and using websites, hardware, and software to categorize, compare, and display segments of a body of information as claimed in the patent.
I haven't tried to follow all of the claims in that patent, but I did skim the first page. Based on what I read there and the summary in the snippet, I suspect that nearly every web site on the internet is violation. Going after Apple et. al. is a blatant attempt at a money grab. Not naming other companies that probably violate the same patents the same way is blatant favoritism.
Talk about a misuse of the system (which is already sorely misused, I know).
A paper describing the test is here. TritonSort is the abstract method; GraySort and MinuteSort are concrete/benchmarked variations of TritonSort.
As TFA states, this is more about balancing system resources than anything else. The actual sort method used was "a variant of radix sort" (page two of the linked PDF). Everything else was an exercise in how to break up the data into manageable chunks (850MB), distribute the chunks to workers, then merge the results. That was the real breakthrough, I think. But I wonder how much is truly a breakthrough and how much was just taking advantage of modern hardware, since one of the major changes in MinuteSort is simply avoiding a couple of disk writes by keeping everything in RAM (a feat possible because that much RAM is readily available to a single worker).
Regardless, this kind of work is very cool. If web framework developers (for example) paid greater attention to balancing data flow and work performed, we could probably get away with half the hardware footprint in our data centers. As it stands now, too many COTS -- and hence, often-used -- frameworks are out of balance. They read too much data for the task, don't allow processing until it's all read in, etc.. This causes implementors to add hardware to scale up.
Whoa. Someone with common sense. Someone in charge with common sense! I need to get some people around my workplace to read this blog entry.
Based on a few years of observation, we noticed that there was little or no correlation between academic performance, as measured by grades [and] the type of college a person attended, and their real on-the-job performance....
While I'm sure that everyone's personal experience is different, this observation matches perfectly with what I've seen over the last 30 years or so in the field. On-the-job performance is the application of skills that are atually needed somewhere. Education in school is teaching something that may be needed at some future date. A new graduate still has to learn how to adapt their knowledge to the real world. Given what schools seem to be teaching these days, and the typical student's retention rate and enthusiasm, I'm not surprised that grads and non-grads are about equal in skill after working for awhile.
... That was a genuine surprise, particularly for me, as I grew up thinking grades really mattered.
Kudos for admitting that, Vembu. I hope others follow your example.
From TFA, written by Michael Cooney and propagated by the summary:
Dubbed extreme scale computing, such machines are needed DARPA says to "meet the relentlessly increasing demands for greater performance, higher energy efficiency, ease of programmability, system dependability and security."
It looks like these "extreme scale computing" systems are needed before things like "ease of programmability" can be acheived. I call bullshit.
... To meet the relentlessly increasing demands for greater performance, higher energy efficiency, ease of programmability, system dependability, and security, revolutionary new research, development, and design will be essential to enable new generations of advanced DoD computing system capabilities and new classes of computer applications. Current evolutionary approaches to progress in computer designs are inadequate....
That makes a lot more sense.
Now, will someone please go and smack Michael Cooney up the back of head for writing like that?
While I obviously can't speak for everyone, here are some actual statistics regarding hardware usage for one of my apps compatible with iPhone OS 3.1 and higher:
Apple iPhone 3GS: 51.3%
Apple iPhone 3G: 24.1%
Apple iPhone 1G: 5.9%
Apple iPod Touch 2G: 5.6%
Apple iPad: 3.4%
Apple iPod Touch 3G: 2.0%
Apple iPhone: 0.4%
Apple iPod Touch 1G: < 0.1%
Apple iPod Touch: < 0.1%
7.2% were simulator usage. The app used here is a paid business app, with not-very-exciting sales figures. Still, I would think that the hardware distribution would be meaningful. If so, it would indicate that one could profitably ignore the first generation iPhone.
Perhaps the simplest solution is true? People who enjoy driving fast are naturally attracted to games featuring fast driving?
I think people who enjoy driving (not "cruising") also enjoy driving games. Reckless driving, however, is not defined as only "driving fast." Maneuvers that other drivers are not expecting, or maneuvers that are overly dangerous to yourself, are "reckless."
I love driving games, with Gran Turismo being my favorite. Speed is (obviously) an essential part of the game, but that part of it doesn't translate a desire for me to shoot down the road at 140mph (often). However, the handling aspects of the game -- proper high-speed cornering techniques, for instance -- do sometimes translate into the real world and can land you into trouble. I'm guilty of sometimes following driving lines while going back and forth to work. If anyone was nearby, I'm sure they'd say that was reckless, if only because they're not expecting it. If we were all on a road course somewhere, those maneuvers would be expected (and praised).
Anyway, I do think that a love for driving causes people to push the limits on their cars, whether in a game or on the road. The reckless bit starts where common sense leaves off.
The findings do not directly link playing video games to reckless driving. They only show an association. Researchers say the impact of playing games like "Grand Theft Auto" is minimal.
Bingo. Driving games could cause reckless driving in real life. Or people who drive recklessly enjoy driving games. Reckless go-kart racing could also be associated with both games and automobile driving, but that wasn't the focus of the study.
I'm glad TFA admitted that one isn't necessarily the cause of the other, thereby bypassing the whole causation != correlation argument. Kudos for that.
Good luck with that, because the painful truth is that the average pop-media-junky, marketing-spoon-fed citizen is resistant to learning as a general course. I've known so many people - adults, mind you - who honestly believe they simply can't learn new things, especially things of any sort of technical nature, be it computer-related, math-related, or what have you. It makes me sad, but there it is.
What you say is, unfortunately, true in the general sense. The average person dislikes learning new stuff for a myriad of reasons. But this line from the summary:
To provide thousands of niches that will interest people in learning, playing and working with open data.
I don't think "people" meant all people or the average person. I think it really means, "more than the few who are doing it now." There's always a certain percentage of a population that likes poking around with virtually any topic you could name. If you expand that population, then more people will get involved. That could -- but not necessarily -- trigger even more people to get interested.
That's my take on it, anyway. I think it's a good idea, and worth trying.
If Linus Torvald was hired to design the new Chevy Camero, it would also be news worthy on/. When important people in the technology industry do interesting things that may or may not be directly related to actually compiling code, some of us nerds like to know.
I own a 2010 Camaro SS. I like and respect Linus' work. But if I had any kind of hint that Linus was involved in the Camaro's design, I would have waited for an even-numbered release before buying it.
Nothing of value was Lost
on
Lost Ends
·
· Score: 5, Funny
'This is why there's a stench of panic hanging over Silicon Valley. This is why Apple have turned into paranoid security Nazis, why HP have just ditched Microsoft from a forthcoming major platform and splurged a billion-plus on buying up a near-failure; it's why everyone is terrified of Google,' writes Stross. 'The PC revolution is almost coming to an end, and everyone's trying to work out a strategy for surviving the aftermath.'
Specifically, NASA says the SDO will beam back 1.5 terabytes of data every day, 24 hours a day, seven days a week. That's almost 50 times more science data than any other mission in NASA history. It's like downloading 500,000 iTunes a day, NASA stated.
Apparently iTunes has morphed into a unit of scale. What is that in Library of Congresses?
TFA is an extremely well-written, easy-to-follow tutorial. I "played along at home" (well, at work, actually) as the author recommended and exploited a system on the first try. Great stuff!
Hang on, one of our SysAdmins wants to talk to me about something.
The surveys demonstrated that land use type, roadway type, and building setbacks all played significant roles in determining vehicle speeds. Most importantly, though, having cars parked along the side of streets accounted by itself for a reduction in travel speeds...
And:
So the conclusion is this: People can be induced to reduce their driving speeds when cars are parked along the roadways, when buildings are close to the street, and when those buildings include commercial rather than residential activity.
Who would have thought that by reducing a driver's visibility, the driver would go slower to give themselves time to react to surprises? You? You in the back? Are you some kind of smartass? The Connecticut Department of Transportation studied this for four years. There's no way you could have arrived at the same conclusion so quickly!
This study was useful in determining how much people slowed down -- quantifying it at about 10% -- but sweeping on to claims like, "reducing the rates of passenger fatalities and generally encouraging a safer urban environment" is silly. Streets packed with parked cars, pedestrians, nearby buildings, et. al. are generally more dangerous precisely because clear lines-of-sight are cut off. Sane drivers know this, reduce their speed, and then -- making wild hand-waving guesses, here -- wind up with about the same overall level of "dangerousness" as when driving on uncluttered roadways.
Detecting the malware depends on the malware trying to stay in memory. My point was that "properly written" malware wouldn't necessarily care if it is was swapped. Allow the swap, get a clean bill of health from the "external verifier," then get reloaded and continue Bad Activities. Downtime for the malware is negligible.
Assume now that we have a detection algorithm that runs in kernel mode, and that swaps out everything in RAM. Everything except itself. Well, malware may interfere, of course, as it often does, and remain in RAM. But if we know how big RAM is, we know how much space should be free. Assume we write pseudo-random bits over all this supposedly free space. Again, a malware agent could refuse to be overwritten. It could store those random bits somewhere else instead... like in secondary storage.
Then, let us compute a keyed hash of the entire memory contents -- both our detection program and all the random bits. Here is what could happen: If there is no malware in RAM, the results will be the expected result. An external verifier checks this, and tells us that the scanned device is clean. Or there could be malware in RAM, and the checksum will be wrong. The external verifier would notice and conclude that the device must be infected. Or malware could divert the read requests directed at the place it is stored to the place in secondary storage where it stored the random bits meant for the space it occupies. That would result in the right checksum... but a delay. This delay would be detected by the external verifier, which would conclude that the device is infected.
<sarcasm>Punting the problem to an "external verifier" is pretty neat. I wish I could do that with my next hard problem.</sarcasm>
That whole bit about swapping, though.... If I write malware and hide it somewhere in execution space, do I really care if it gets swapped out? So the code that steals keystrokes or sniffs for credit card numbers doesn't get executed for short while. Big deal. At some point it will get loaded again (if written properly, that is).
Electronic books are probably one of the iPad's killer apps. Maybe not the ones we'll see immediately -- the ones basically just ported from the Kindle or something -- but the next generation of books, or the ones after that. Interacting with the book is where the technology will really shine. Think about A Young Lady's Illustrated Primer (from The Diamond Age).
If someone pays you to perform work, they own all rights to that work.
I think this may depend on where you live, but legally this isn't always right. The idea is that when you write software, you're creating something using your talent and skill, then you're selling the end result to a buyer. You can, in fact, sell that something multiple times to different buyers. You haven't created a single instance of an end product (the running software); you've created a repeatable process for creating copies of that end product, then selling each one.
All of that is splitting hairs, I know. And I don't think it agrees with common sense, myself. But that's how a lot of the legal and tax systems treat the process. You can, of course, change the ownership issue with contracts, which is what TFA talks about.
Several years ago, when I owned my own custom software business, I went through a state sales tax audit. The worst six weeks of my entire life, easily. I used "Work For Hire" contracts with my customers, with the modification that I retained the right to excerpt "useful subroutines" and reuse them in any other projects (along with clauses saying that a customer's project may contain such code). In the main, though, what we wrote belonged to the customer when we were finished. The tax department really didn't like that, as that exempted us from charging sales tax (thereby depriving the state of some revenue). I won, eventually, and that whole process left me far more knowledgeable about the tax code and whole lot less enthusiastic about it. They've probably closed that loophole since.
Slashdot Mirror
So Paul is running out of money, huh?
A snippet from the suit:
I haven't tried to follow all of the claims in that patent, but I did skim the first page. Based on what I read there and the summary in the snippet, I suspect that nearly every web site on the internet is violation. Going after Apple et. al. is a blatant attempt at a money grab. Not naming other companies that probably violate the same patents the same way is blatant favoritism.
Talk about a misuse of the system (which is already sorely misused, I know).
"Underrated" is the word you're really looking for.
A paper describing the test is here. TritonSort is the abstract method; GraySort and MinuteSort are concrete/benchmarked variations of TritonSort.
As TFA states, this is more about balancing system resources than anything else. The actual sort method used was "a variant of radix sort" (page two of the linked PDF). Everything else was an exercise in how to break up the data into manageable chunks (850MB), distribute the chunks to workers, then merge the results. That was the real breakthrough, I think. But I wonder how much is truly a breakthrough and how much was just taking advantage of modern hardware, since one of the major changes in MinuteSort is simply avoiding a couple of disk writes by keeping everything in RAM (a feat possible because that much RAM is readily available to a single worker).
Regardless, this kind of work is very cool. If web framework developers (for example) paid greater attention to balancing data flow and work performed, we could probably get away with half the hardware footprint in our data centers. As it stands now, too many COTS -- and hence, often-used -- frameworks are out of balance. They read too much data for the task, don't allow processing until it's all read in, etc.. This causes implementors to add hardware to scale up.
That site serves as a poster child for why Safari 5.0's "Reader" feature exists.
Whoa. Someone with common sense. Someone in charge with common sense! I need to get some people around my workplace to read this blog entry.
While I'm sure that everyone's personal experience is different, this observation matches perfectly with what I've seen over the last 30 years or so in the field. On-the-job performance is the application of skills that are atually needed somewhere. Education in school is teaching something that may be needed at some future date. A new graduate still has to learn how to adapt their knowledge to the real world. Given what schools seem to be teaching these days, and the typical student's retention rate and enthusiasm, I'm not surprised that grads and non-grads are about equal in skill after working for awhile.
Kudos for admitting that, Vembu. I hope others follow your example.
From TFA, written by Michael Cooney and propagated by the summary:
It looks like these "extreme scale computing" systems are needed before things like "ease of programmability" can be acheived. I call bullshit.
The actual notice from DARPA is named Omnipresent High Performance Computing (OHPC). From the first paragraph of that page:
That makes a lot more sense.
Now, will someone please go and smack Michael Cooney up the back of head for writing like that?
While I obviously can't speak for everyone, here are some actual statistics regarding hardware usage for one of my apps compatible with iPhone OS 3.1 and higher:
7.2% were simulator usage. The app used here is a paid business app, with not-very-exciting sales figures. Still, I would think that the hardware distribution would be meaningful. If so, it would indicate that one could profitably ignore the first generation iPhone.
Perhaps the simplest solution is true? People who enjoy driving fast are naturally attracted to games featuring fast driving?
I think people who enjoy driving (not "cruising") also enjoy driving games. Reckless driving, however, is not defined as only "driving fast." Maneuvers that other drivers are not expecting, or maneuvers that are overly dangerous to yourself, are "reckless."
I love driving games, with Gran Turismo being my favorite. Speed is (obviously) an essential part of the game, but that part of it doesn't translate a desire for me to shoot down the road at 140mph (often). However, the handling aspects of the game -- proper high-speed cornering techniques, for instance -- do sometimes translate into the real world and can land you into trouble. I'm guilty of sometimes following driving lines while going back and forth to work. If anyone was nearby, I'm sure they'd say that was reckless, if only because they're not expecting it. If we were all on a road course somewhere, those maneuvers would be expected (and praised).
Anyway, I do think that a love for driving causes people to push the limits on their cars, whether in a game or on the road. The reckless bit starts where common sense leaves off.
Bingo. Driving games could cause reckless driving in real life. Or people who drive recklessly enjoy driving games. Reckless go-kart racing could also be associated with both games and automobile driving, but that wasn't the focus of the study.
I'm glad TFA admitted that one isn't necessarily the cause of the other, thereby bypassing the whole causation != correlation argument. Kudos for that.
Good luck with that, because the painful truth is that the average pop-media-junky, marketing-spoon-fed citizen is resistant to learning as a general course. I've known so many people - adults, mind you - who honestly believe they simply can't learn new things, especially things of any sort of technical nature, be it computer-related, math-related, or what have you. It makes me sad, but there it is.
What you say is, unfortunately, true in the general sense. The average person dislikes learning new stuff for a myriad of reasons. But this line from the summary:
To provide thousands of niches that will interest people in learning, playing and working with open data.
I don't think "people" meant all people or the average person. I think it really means, "more than the few who are doing it now." There's always a certain percentage of a population that likes poking around with virtually any topic you could name. If you expand that population, then more people will get involved. That could -- but not necessarily -- trigger even more people to get interested.
That's my take on it, anyway. I think it's a good idea, and worth trying.
If Linus Torvald was hired to design the new Chevy Camero, it would also be news worthy on /. When important people in the technology industry do interesting things that may or may not be directly related to actually compiling code, some of us nerds like to know.
I own a 2010 Camaro SS. I like and respect Linus' work. But if I had any kind of hint that Linus was involved in the Camaro's design, I would have waited for an even-numbered release before buying it.
The subject lines, they just write themselves.
Ah, the smell of hyperbole in the morning....
Apparently iTunes has morphed into a unit of scale. What is that in Library of Congresses?
TFA is an extremely well-written, easy-to-follow tutorial. I "played along at home" (well, at work, actually) as the author recommended and exploited a system on the first try. Great stuff!
Hang on, one of our SysAdmins wants to talk to me about something.
BRB
Good grief. From TFA:
And:
Who would have thought that by reducing a driver's visibility, the driver would go slower to give themselves time to react to surprises? You? You in the back? Are you some kind of smartass? The Connecticut Department of Transportation studied this for four years. There's no way you could have arrived at the same conclusion so quickly!
This study was useful in determining how much people slowed down -- quantifying it at about 10% -- but sweeping on to claims like, "reducing the rates of passenger fatalities and generally encouraging a safer urban environment" is silly. Streets packed with parked cars, pedestrians, nearby buildings, et. al. are generally more dangerous precisely because clear lines-of-sight are cut off. Sane drivers know this, reduce their speed, and then -- making wild hand-waving guesses, here -- wind up with about the same overall level of "dangerousness" as when driving on uncluttered roadways.
Detecting the malware depends on the malware trying to stay in memory. My point was that "properly written" malware wouldn't necessarily care if it is was swapped. Allow the swap, get a clean bill of health from the "external verifier," then get reloaded and continue Bad Activities. Downtime for the malware is negligible.
<sarcasm>Punting the problem to an "external verifier" is pretty neat. I wish I could do that with my next hard problem.</sarcasm>
That whole bit about swapping, though.... If I write malware and hide it somewhere in execution space, do I really care if it gets swapped out? So the code that steals keystrokes or sniffs for credit card numbers doesn't get executed for short while. Big deal. At some point it will get loaded again (if written properly, that is).
Or am I missing something obvious?
Electronic books are probably one of the iPad's killer apps. Maybe not the ones we'll see immediately -- the ones basically just ported from the Kindle or something -- but the next generation of books, or the ones after that. Interacting with the book is where the technology will really shine. Think about A Young Lady's Illustrated Primer (from The Diamond Age).
If someone pays you to perform work, they own all rights to that work.
I think this may depend on where you live, but legally this isn't always right. The idea is that when you write software, you're creating something using your talent and skill, then you're selling the end result to a buyer. You can, in fact, sell that something multiple times to different buyers. You haven't created a single instance of an end product (the running software); you've created a repeatable process for creating copies of that end product, then selling each one.
All of that is splitting hairs, I know. And I don't think it agrees with common sense, myself. But that's how a lot of the legal and tax systems treat the process. You can, of course, change the ownership issue with contracts, which is what TFA talks about.
Several years ago, when I owned my own custom software business, I went through a state sales tax audit. The worst six weeks of my entire life, easily. I used "Work For Hire" contracts with my customers, with the modification that I retained the right to excerpt "useful subroutines" and reuse them in any other projects (along with clauses saying that a customer's project may contain such code). In the main, though, what we wrote belonged to the customer when we were finished. The tax department really didn't like that, as that exempted us from charging sales tax (thereby depriving the state of some revenue). I won, eventually, and that whole process left me far more knowledgeable about the tax code and whole lot less enthusiastic about it. They've probably closed that loophole since.
I thought the first rule of Linux Patents is you do not talk about Linux Patents.
What happened? Did someone not bend over far enough?
... give a bunch of hungry kids manuals and access and stand back.
That is, some of the time, how you teach most effectively.
From their About page:
One of their forum topics asks about Mac users running this. Several replies indicate that it does work, mostly, under emulators.
You don't need to. There is zero meaningful information in it that is not included in the summary.
It would have been interesting to here some of Gates' reasons behind his statement.