I retired because I was turning 70. There have been comments about age discrimination in "resource actions" at the company where I worked for over 34 years, but my impression was that it was more "senior employee discrimination". I.e. the longer you work in a place, the more connections you have and therefore the more "dotted line" or "implicit" obligations you have that never show up on performance plans/evaluations or at least are more difficult to quantify. Anyway, I had held on long enough.
As others have pointed out Groklaw provided ongoing coverage of SCO vs the universe matters until August, 2013. At that point PJ gave up the ghost and quit running Groklaw. Groklaw's SCO vs IBM timeline continued to be updated with documents, including the summary judgement decision that was just overturned and returned to the district court for trial. That opinion has a decent history of the case with regards to SCO's only remaining claim against IBM.
FORTRAN course in high school in 1963 (high school did not offer it, dedicated teacher took two of us to an early morning vocational school), and then CORC in 1964, required course for 1st year engineering students.
Full text (PDF) of the Amicus Brief is worth reading and not that long. Excerpts "The Eastern District has adopted certain procedural rules that benefit patent owners—particularly those with weak patents and no products—to the detriment of small innovators and those accused of infringement. These rules drive up costs to defendants and work to increase settlement pressure untethered to the merits of a particular claim for patent infringement." and "These rules, although facially neutral, give significant advantages to patent owners with minimal assets, dubious patents or infringement claims, or a goal of extracting undeserved settlements."
Longer piece on same topic for different audience in the New England Journal of Medicine.
Selective breeding, an extreme form of evolution?
on
High Speed Evolution
·
· Score: 2
Consider dogs (all breeds derived from wolves several thousand years ago) and foxes http://cbsu.tc.cornell.edu/ccgr/behaviour/Index.htm the genetic basis has been studied and similar studies have been done on other domestic animals. The chicken http://en.wikipedia.org/wiki/Junglefowl This type of "evolution" is really just exploitation of existing genetic variation within a species.
"I remember being very nervous about throwing my first (and hopefully last) handgrenade. Regardless of hollywood fantasies, it leaves you 3 seconds til detonation, once its armed and released."
You think you were nervous? What about the sergeant watching you and (successively) all the other green recruits in your training cycle throw their first grenade?
'I remember thinking "If you mess this up, it'll be your last mistake"'
And the sergeant is looking at you, the grenade and thinking about where he has to kick the damn thing if you drop it instead of throw it over the blast barrier. Or at least that's how I remember it. But that was a long time ago and the training circumstances may be different now.
> In this case, the greater patent term is 20 years from the filing date (Oct. 27, 1996), such that the patent expires on Oct. 27, 2006.
Umm 20+1996 = 2016, no? But what patent are we talking about here? US 4,698,672 was filed 1986-10-27 and issued on 1987-10-06 and thus expires on 2004-10-07, because it was filed and issued under the old rules: 17 years of protection from date of issue. The new rule (20 years from date of file) was put in to keep people from keeping applications alive with trivial interactions with the patent office until there was interest and then resolving the patent and getting 17 years of protection from date of issue.
As far as IBM computers/calculators are concerned, there are two authoritative books:
"IBM's Early Computers" by C.J. Bashe, L.R. Johnson, J.H. Palmer and E.W. Pugh, 1986, MIT Press
"IBM's 360 and Early 370 Systems" by E.W. Pugh, L.R. Johnson, and J.H. Palmer, 1991, MIT Press
Both part of an MIT Press series on the history
of computing:
http://mitpress.mit.edu/books-in-series.tcl?series =History%20of%20Computing
The two books on IBM computers give a lot of internal IBM culture, but one should be aware that the authors were all IBM employees when the books were researched and written. This gave the authors excellent access to IBM sources, but also gives the books a decidedly IBM point of view.
Caveat lector.
This reminds me of an "extra points" question on a final exam in a course on operating systems taught by Vint Cerf at Stanford many years ago. Similar setup except the bar was some number of light years long and was rotated at a rate that would make the tip move faster than the speed of light. In this case what happens is that the "bar" (no matter how rigid) wraps up in a spiral around the axis of rotation, with the result that the tip never exceeds (or for real a physical bar, even approaches) the speed of light. I put this answer (that the bar winds up around the axis of rotation) on the exam and concluded with "Rigid rods are illegal in physics, Freud notwithstanding" and got 15 out of 10 points extra credit: I think Vint (or perhaps the grader) got a laugh out of my answer:-)
I could not tell from the article, but I suspect that the 16 vs 32 bit has as much to do with typical applications as with the OS: they ran some "typical" workload and found a lot of 16 bit code. The article didn't go into any technical detail about the performance measuremnt, but surely they were trying to figure out whether or not the chip would be competitive running common Windows "laptop" applications: after sll the emphasis (at least in the end) is on low power and mobile devices: they almost certainly weren't running Windows NT and "server applications" to see if their performance was accaptable.
So, on hardware that is indifferent to the direction of stack growth, it would make sense to have the stack grow up (from some limit) and the heap grow down (from some other limit), right?
The counter argument that I remember has to do with machines that have "store multiple" instructions to save (and "load multiple" instructions to restore) multiple registers at a time. These instructions allow you to "buy a stack frame" (by storing at a location beyond the known stack usage of the called routine...doesn't work for routines that call alloca) cheaply with a downward growing stack (or something like that).
In any event, it sounds to me like it might well be worth it to look at exactly what it really costs on "normal" function calls to have an upward growing stack.
Slashdot Mirror
I retired because I was turning 70. There have been comments about age discrimination in "resource actions" at the company where I worked for over 34 years, but my impression was that it was more "senior employee discrimination". I.e. the longer you work in a place, the more connections you have and therefore the more "dotted line" or "implicit" obligations you have that never show up on performance plans/evaluations or at least are more difficult to quantify. Anyway, I had held on long enough.
As others have pointed out Groklaw provided ongoing coverage of SCO vs the universe matters until August, 2013. At that point PJ gave up the ghost and quit running Groklaw. Groklaw's SCO vs IBM timeline continued to be updated with documents, including the summary judgement decision that was just overturned and returned to the district court for trial. That opinion has a decent history of the case with regards to SCO's only remaining claim against IBM.
FORTRAN course in high school in 1963 (high school did not offer it, dedicated teacher took two of us to an early morning vocational school), and then CORC in 1964, required course for 1st year engineering students.
Full text (PDF) of the Amicus Brief is worth reading and not that long. Excerpts "The Eastern District has adopted certain procedural rules that benefit patent owners—particularly those with weak patents and no products—to the detriment of small innovators and those accused of infringement. These rules drive up costs to defendants and work to increase settlement pressure untethered to the merits of a particular claim for patent infringement." and "These rules, although facially neutral, give significant advantages to patent owners with minimal assets, dubious patents or infringement claims, or a goal of extracting undeserved settlements."
Longer piece on same topic for different audience in the New England Journal of Medicine.
Consider dogs (all breeds derived from wolves several thousand years ago) and foxes http://cbsu.tc.cornell.edu/ccgr/behaviour/Index.htm the genetic basis has been studied and similar studies have been done on other domestic animals. The chicken http://en.wikipedia.org/wiki/Junglefowl This type of "evolution" is really just exploitation of existing genetic variation within a species.
Or look at some of the articles in the latest issue of the IBM Journal of Research and Development for some more techincal detail.
"I remember being very nervous about throwing my first (and hopefully last) handgrenade. Regardless of hollywood fantasies, it leaves you 3 seconds til detonation, once its armed and released."
You think you were nervous? What about the sergeant watching you and (successively) all the other green recruits in your training cycle throw their first grenade?
'I remember thinking "If you mess this up, it'll be your last mistake"'
And the sergeant is looking at you, the grenade and thinking about where he has to kick the damn thing if you drop it instead of throw it over the blast barrier. Or at least that's how I remember it. But that was a long time ago and the training circumstances may be different now.
Guess what field Irving Wladawsky-Berger's PhD is in? Physics, how did you guess? And he has been pushing
Linux inside IBM for quite a while.
> In this case, the greater patent term is 20 years from the filing date (Oct. 27, 1996), such that the patent expires on Oct. 27, 2006.
Umm 20+1996 = 2016, no? But what patent are we talking about here? US 4,698,672 was filed 1986-10-27 and issued on 1987-10-06 and thus expires on 2004-10-07, because it was filed and issued under the old rules: 17 years of protection from date of issue. The new rule (20 years from date of file) was put in to keep people from keeping applications alive with trivial interactions with the patent office until there was interest and then resolving the patent and getting 17 years of protection from date of issue.
This isn't the only IBM contribution. Look in the latest glibc source at the accurate math routines, for at least one other... http://sources.redhat.com/cgi-bin/cvsweb.cgi/libc/ sysdeps/ieee754/dbl-64/?cvsroot=glibc
Actually, it's running a full function VM, probably the latest release...all the software is described on the website: http://www.ibm.com/servers/eserver/zseries/os/linu x/lcds
"IBM's Early Computers" by C.J. Bashe, L.R. Johnson, J.H. Palmer and E.W. Pugh, 1986, MIT Press
"IBM's 360 and Early 370 Systems" by E.W. Pugh, L.R. Johnson, and J.H. Palmer, 1991, MIT Press
Both part of an MIT Press series on the history of computing: http://mitpress.mit.edu/books-in-series.tcl?series =History%20of%20Computing
The two books on IBM computers give a lot of internal IBM culture, but one should be aware that the authors were all IBM employees when the books were researched and written. This gave the authors excellent access to IBM sources, but also gives the books a decidedly IBM point of view. Caveat lector.
This reminds me of an "extra points" question on a final exam in a course on operating systems taught by Vint Cerf at Stanford many years ago. Similar setup except the bar was some number of light years long and was rotated at a rate that would make the tip move faster than the speed of light. In this case what happens is that the "bar" (no matter how rigid) wraps up in a spiral around the axis of rotation, with the result that the tip never exceeds (or for real a physical bar, even approaches) the speed of light. I put this answer (that the bar winds up around the axis of rotation) on the exam and concluded with "Rigid rods are illegal in physics, Freud notwithstanding" and got 15 out of 10 points extra credit: I think Vint (or perhaps the grader) got a laugh out of my answer :-)
I could not tell from the article, but I suspect that the 16 vs 32 bit has as much to do with typical applications as with the OS: they ran some "typical" workload and found a lot of 16 bit code. The article didn't go into any technical detail about the performance measuremnt, but surely they were trying to figure out whether or not the chip would be competitive running common Windows "laptop" applications: after sll the emphasis (at least in the end) is on low power and mobile devices: they almost certainly weren't running Windows NT and "server applications" to see if their performance was accaptable.
So, on hardware that is indifferent to the direction of stack growth, it would make sense to have the stack grow up (from some limit) and the heap grow down (from some other limit), right? The counter argument that I remember has to do with machines that have "store multiple" instructions to save (and "load multiple" instructions to restore) multiple registers at a time. These instructions allow you to "buy a stack frame" (by storing at a location beyond the known stack usage of the called routine...doesn't work for routines that call alloca) cheaply with a downward growing stack (or something like that). In any event, it sounds to me like it might well be worth it to look at exactly what it really costs on "normal" function calls to have an upward growing stack.
If you have trouble with the LinuxPlanet link, you might try this link from the Author's home page.