You're right, and I'm well aware of the point
you're making.
Three separate people have replied to me (including you) who misinterpreted what I was saying. The person a couple levels up (the one
that I originally replied to) made the remark that you could just stop by a grocery store and snag a bottle of Wesson when making a cross-country trip with a biodiesel vehicle.
I was just observing that the bottle of Wesson ironically is 4x as expensive as gasoline. I felt it was ironic, as the Wesson is a renewable resource we make here in the US (all those wonderful fields of corn and whatnot), whereas gasoline is not quite as renewable.
I realize that suitable vegetable oil doesn't have to cost 4x the cost of gasoline. (In all actuality, the reverse should be true -- gasoline should be 4x the cost of vegetable fuel oil.) However, given the present state of the universe, the most readily available off-the-shelf vegetable oil does cost 4x as much as gasoline, and as I said, I find that vaguely ironic.
Now, if vegetable-oil biodiesel vehicles were ever to take off, I imagine we would see vehicle grade vegetable-oil widely available and quite cheap.
Well, I suppose it does, but it doesn't say it equivalently. It says that it costs 4 cents a mile to operate the biodiesel bike, vs. 3 cents a mile for ordinary petrol. And the difference of 4 vs. 3 is not too much different than the price of gasoline this month vs. the price of gasoline a couple months ago (or a couple months from now).
As for motorbikes, they can be very fuel efficient with ordinary petrol. (The 70mpg number you quote is pretty typical as far as the numbers I've heard, if maybe towards the high side.) It's not clear to me whether the 100mpg is due to difference in fuel, or difference in engine configuration.
Anyway, back to my original point, which I apparently didn't elucidate: The Wesson is significantly more expensive than petrol
at the pump. Not 30% more expensive. Not 2x more
expensive. More like 4x-8x more expensive. I just priced online a 48oz bottle at $2.19. That works out to $5.84 a gallon, which is about 4x what I pay for 93 octane gas at the pump. If you get the smaller-sized bottles, the ratio goes up.
That's a much bigger gap than 4 cents/mile vs. 3 cents/mile.
I think you're thinking of the date that Skynet became sentient (in the Terminator series). I seem to recall that that was on August 29th, 1997 at 2:14 AM.
(That was also my 22nd birthday, FWIW, which is the ONLY reason I happened to remember this little tidbit. Google remembered the 2:14AM bit for me though.)
Hate to break it to you, bub, but Michigan is very much in the Eastern time zone. You have to get on the other side of Lake Michigan to be in the Central time zone.
I am a DSP software applications-type person
at a certain large DSP vendor. While I don't work in the broadband access group, I still get to occasionally implement the crazy algorithms that deal with the reflections, noise, and other crap
that DSL has to put up with.
So, no, I'm not a phony. (And BTW, I believe
SDSL and ADSL and all the other xDSL family
connection types have to put up with the same
annoyances unless you get fresh copper laid just
for you. If you get a "dry pair" that's already
in the ground, you still may have stubs, wire-gauge differences and distance-related signal attenuation to contend with. Thankfully, you do still miss out on repeaters (which I forgot in my post above), loading coils, and voice-band filters.))
BTW, I also wouldn't be surprised if telcos in the US just have crappier infrastructure overall than our Canadian neighbors. Partly because (in some areas) the infrastructure is as old as the hills and hard to get to to replace it all, and partly because the telcos (and big business in general) are in bed with the US Gov't.:-P Other contries have decent communication infrastructure, why not us?
I've noticed that the US has a tendency to not embrace new technology as quickly, as long as businesses can still milk $$ out of the current technology. Fun, fun... I suspect it's that sort of thinking that's left the US with a rotting, aging, non-DSL-friendly POTS network, little
ISDN to speak of, and a country that 1/2 to 1
full step back from most of the world in deployed wireless
technology. Whoo hoo!
Changes in wire type/gauge. Every time you change gauge in wire, you potentially have an impedance mismatch which can cause reflections on the line. These reflections cause certain frequencies (well above human hearing range, but smack-dab in the middle of the DSL frequency range) to be attenuated or altogether canceled out.
Related to this are stubs. Often times, a single line pair leaving a junction box is spliced somewhere along the way and actually goes to two destinations -- one live, one not. This could happen for a variety of reasons, typically due to changes in service at residences near each other. Each stub also causes reflections (worse than those reflections caused by changes in wire gauge), and so this too frustrates DSL service.
Line filters. Strictly speaking, line filters aren't necessary until well down the line, where your voice-band data is converted to digital, or is analog-multiplexed with other signals on a line. To reduce crosstalk and noise (apparently), most POTS lines have line filters closer to the home so only voiceband energy is on the line. These kill DSL dead, as you noted.
Loading coils. On some longer runs out there, loading coils are on the lines to help even out the response curve of the line in the voice band, in part by absorbing reflections. These totally screw up the frequency bands outside the voice band though.
And finally, from what I recall, upper frequences attenuate fairly sharply with distance on unshielded copper, and so the further away you get, the fewer usable frequencies you have to play with.
So, yes, there are a lot of problems as you go from the CO to the end terminal. Some of these problems are in the last mile (changes in wire gauge, stubs) and some are along the way (loading coils).
I think this can be expanded to *any* product. If you're Johnson and Johnson, create the home healthcare, health, and self improvement pages. Don't bother too heavily with product placement,
I don't think, but when people start associating 'health' and 'wellness' with J&J, they've done good advertsing.
Actually, there are sites that are starting to do something like that, if in a less proactive way. Rather than host the sites themselves, they sponsor sites which meet those criteria. Of course, the lack of impartiality on company-sponsored sites can make them less attractive. That's why you end up sometimes with "astroturf" sites which appear to be impartial by not disclosing their sponsorship, but are not...:-P Ah well.
I think you mean the SNR is too low (as in, not much signal for the amount of noise).
I tend to agree. The couple times I have clicked on a banner, I get dropped into some noisy top-level page that has nothing to do with the content of the ad. Either that, or a page that
says "Click here to add to your shopping cart",
with little detail about the product or the company.
It depends on whether it's modifying a word
that immediately follows it, as in "That is an anal-retentive poster," or if it is used
alone, as in "The poster is anal retentive."
:-)
--Joe
(PS. As long as the CoS folks are around, I figure anything that's OT might as well be OT3...) --
If anyone can tell me how I can get simple text-terminals (i.e. a telnet login prompt) sent to my workstation's virtutual terminals, let me know. I can do it via a serial cable, but over TCP/IP it
seems much more difficult.
If you just want a plain login prompt on your text consoles, getty is what you want. Just point getty at ttyX and you're most of the way there. (Do it in/etc/inittab. Most of the distros do this for you...)
If that's not what you wanted, then perhaps you can elaborate on your question?
--Joe --
Re:SMT != ILP != multiple pipes.
on
Emergence of SMT
·
· Score: 2
SMT is a relatively
new idea that lets you easily boost the instruction-level parallelism, which in turn makes scheduling and issuing instructions *much* easier.
That's true only if you have sufficient hardware registers (not to be confused with architectural registers), and your tasks aren't bottlenecked on memory. If you have truly independent tasks, then each will effectively see half as much cache at all levels of the hierarchy. This can get especially painful in L1I -- if you can't keep the CPU fed from both streams, oops! And, large register files can be a speed limiter in the architecture. (On the plus side, though, the hardware register files can be distinct between the threads, so it's not too bad. As I understand it, it's the unified register files that are the real problem.)
One of the main attractive things I see in SMT is that you can effectively make the pipeline deeper on the architecture while completely hiding it. This is important on VLIW-style architectures that have an exposed pipeline. To make it deeper, you need to somehow hide the fact that it's deeper
than the code thinks it is. One way is to add interlocks (gradually making stages of the pipeline protected, rather than exposed). Another is to interleave multiple threads, so that each thread sees the pipeline length it expects, but the actual pipeline is some factor larger.
Of course, in this VLIW world, things can get
tricky outside the CPU. Because you lack superscalar issue (that's what VLIW's about), the issue of stalls becomes a problem. "One-stall-all-stall" is an oft-mentioned SMT VLIW technique, and with it, you really need to make sure you aren't bottlenecked on memory before you go down the SMT path. "One-stall-all-stall" means if one SMT thread stalls, all threads stall... As I understand it, it's the "cheap" way to maintain the VLIW state in an SMT VLIW machine, but it
also amplifies any memory system bottlenecks you might have.
Optimization is all about turning compute-bound problems into I/O bound problems. Most processors are fast enough these days that they're I/O bound.
Particularly if you have an OS that tends to keep L1 completely thrashed. (I recall seeing numbers which showed that Win9x tends to keep L1 completely hosed, whereas WinNT and Linux do not.)
Note that I/O bound doesn't necessarily mean bandwidth starved -- latency is also an issue with many typical tasks. Notice how RAMBUS machines tend to perform fairly slowly on many non-latency-tolerant tasks. It's not for lack of bandwidth.
What's worse is that we've passed the sweet spot in cache sizes such that L1 cache sizes are going to stop increasing and start decreasing again, sadly.
(Transport delay in getting bits from the far side of L1 is limiter, I understand.)
Now the statement that most machines spend their time waiting for disk, I don't think that's quite true. That's maybe true under Windows (it certainly seemed to be last time I used it regularly, even with gobs of RAM handy), but it's certainly not true under Linux or Solaris. I almost never hear my HD run under normal circumstances. Even when it does run, it's not chugging incessantly. It's called "having enough RAM."
Even with enough RAM, though, PC133 SDRAM is quite a bit slower than L2, which is noticably slower than L1. Anything that doesn't stay in L1 most of the time is going to quickly bottleneck on the other levels of the memory hierarchy. Not much you can do about it, either.
I wrote a version that I embedded into my game, 4-Tris. This heart of this version was about 430 words of assembly code. I hadn't bothered to optimize for size. I'm sure you could get it somewhat smaller. Anyone?
S.P.I.P.O.P.D. stands for Smashing Pumpkins Into Small Piles Of Putrid Debris. This whole thing got startted in late 1993 in the Usenet newsgroup comp.sys.ibm.pc.games.action when anticipation for the as yet to be relased game DOOM had reached a fever pitch.
Tired of all the DOOM related posts someone made the comment that all this buzz would not exist if DOOM had a more mundane name like Smashing Pumpkins Into Small Piles Of Putrid Debris. Within hours this was contracted to SPISPOPD and all hell broke loose.
comp.sys.ibm.pc.games.action was soon flooded with ever increasingly wild posts about this fictional game,
much to the aggravation of those who had complained about all the DOOM posts.
Taking the bull by the nose Seth Cohn created the Official SPISPOPD FAQ and a small legend was born. When DOOM finally did come out SPISPOPD was almost forgotten, but that's another story.
Dave Taylor of id Software caught wind of the SPISPOPD madness
and added the cheat code "idspispopd" to DOOM (renamed "idclip" in DOOM 2).
Oh yeah... Smashing Pumpkins Into Small Piles Of Putrid Debris, by SuperEGO! Anyone still have a copy of that game (pref. v1 as that's the one I played, although either version is fine).
CVS is pretty automated too. I just type cvs update and I'm brought up to date with no hassles. (...as long as I haven't edited any of the files.)
As for point #2: An arbitrary limitation makes it novel?
And point #3: I'm not sure what you mean here. In the case of CVS, there's a CVS directory with a file named Entries which says what versions are stored locally. The server uses this information to determine what to send you to bring you up to date. And on the server, the revision-control
files in the Repository describe how one version is generated from another. Is that the kind of thing you're talking about?
In my mind, the most 'interesting' aspect of this patent is the layering mechanism. On the other hand, I don't know if there's enough unique ideas between the RCS type stuff, incremental backups and
this patent to make this into a patentable improvement. Definitely, I don't see this as being anything like the basic patent that they seem to be making it out to be.
This "layering" is not all that different than how MPEG video works with I, P, and B frames, either.
:-P There's just way too much prior art for methods of performing incremental updates. Basically, in MPEG, you have I frames every so often (similar to monthly backups), P frames which are either predicted from a previous I frame, future I frame, previous P frame or future P frame (analagous to weekly incremental backups), and then B frames which are bidirectionally predicted from I or P frames (analagous to daily incremental backups). I forget the exact rules about what can be predicted from what, but the main point is that each non-I frame is expressed as a diff relative to some other non-B frame.
Incidentally, with CVS, you can still get the equivalent of monthly, weekly, and daily by compressing away intermediate versions in the repository. Essentially, you tell CVS that "Revisions x.a.b through x.y.z are no longer
interesting", and it'll update the repository
so that x.y.z is expressed as a diff relative to x.a.b, and all the versions in-between disappear.
And then there's the concepts of "trunk" and
"branch" and....
Actually, I think, from a cursory look through the pages, that this is different from the way that the common "patch" program works.
It is, but it's not that much different than how RCS and CVS work. The main difference is that the differences are generated between the version of software being updated and the desired version. Since there could (theoretically) be hundreds of "versions" out there, there needs to be some way of finding out the starting version, and then applying the appropriate patches.
If I do a cvs update -ttagin my CVS work area, the CVS software looks at my Entries files and determines what versions I presently have checked out of the various files CVS controls. It then queries the server, which sends tailored diffs that will bring my work area in sync with the version specified by the provided tag. (Or, I can leave off the tag and be up-to-date with the most current version.) These diffs are generated specifically between the desired version and the currently checked out version. Additionally, CVS will try to merge differences if any of the patches don't apply cleanly (such as on files that I've edited locally, but have not checked in).
That sounds an awful like what the virus vendors are claiming to do, and I think RCS (upon which CVS is originally based) has definite prior art
here. The oldest reference I've found to RCS is:
Walter F. Tichy, RCS--A System for Version Control,
Software--Practice & Experience 15, 7 (July 1985),
637-654. (Type man rcs if you have RCS installed.)
Our eyes only need ~20FPS to perceive motion,
but there are definitely aspects of our vision that are sensitive to higher frequencies, particularly our peripheral vision. At I can see monitor flicker at >60Hz out of the corner of my eye, but I don't notice it really at all if I look at the monitor head-on.
Most of the reason we need high frame rates is that we don't do motion-blur when we generate the image. Without motion blur, you need high frame rates to ensure that contrasting edges don't move far between frames. Otherwise, you get "edge inversion" artifacts where your eye superimposes the same edge at two positions from consecutive frames.
This is also why live video from slow-motion cameras played at normal speed by dropping frames looks strangely crisp and unnatural.
Slashdot Mirror
You're right, and I'm well aware of the point you're making.
Three separate people have replied to me (including you) who misinterpreted what I was saying. The person a couple levels up (the one that I originally replied to) made the remark that you could just stop by a grocery store and snag a bottle of Wesson when making a cross-country trip with a biodiesel vehicle.
I was just observing that the bottle of Wesson ironically is 4x as expensive as gasoline. I felt it was ironic, as the Wesson is a renewable resource we make here in the US (all those wonderful fields of corn and whatnot), whereas gasoline is not quite as renewable.
I realize that suitable vegetable oil doesn't have to cost 4x the cost of gasoline. (In all actuality, the reverse should be true -- gasoline should be 4x the cost of vegetable fuel oil.) However, given the present state of the universe, the most readily available off-the-shelf vegetable oil does cost 4x as much as gasoline, and as I said, I find that vaguely ironic.
Now, if vegetable-oil biodiesel vehicles were ever to take off, I imagine we would see vehicle grade vegetable-oil widely available and quite cheap.
--Joe--
Well, I suppose it does, but it doesn't say it equivalently. It says that it costs 4 cents a mile to operate the biodiesel bike, vs. 3 cents a mile for ordinary petrol. And the difference of 4 vs. 3 is not too much different than the price of gasoline this month vs. the price of gasoline a couple months ago (or a couple months from now).
As for motorbikes, they can be very fuel efficient with ordinary petrol. (The 70mpg number you quote is pretty typical as far as the numbers I've heard, if maybe towards the high side.) It's not clear to me whether the 100mpg is due to difference in fuel, or difference in engine configuration.
Anyway, back to my original point, which I apparently didn't elucidate: The Wesson is significantly more expensive than petrol at the pump. Not 30% more expensive. Not 2x more expensive. More like 4x-8x more expensive. I just priced online a 48oz bottle at $2.19. That works out to $5.84 a gallon, which is about 4x what I pay for 93 octane gas at the pump. If you get the smaller-sized bottles, the ratio goes up. That's a much bigger gap than 4 cents/mile vs. 3 cents/mile.
--Joe--
Of course, interestingly, that gallon bottle of Wesson at the grocery store costs alot more than a gallon of good ol' petrol at the pump.
--Joe--
I think you're thinking of the date that Skynet became sentient (in the Terminator series). I seem to recall that that was on August 29th, 1997 at 2:14 AM. (That was also my 22nd birthday, FWIW, which is the ONLY reason I happened to remember this little tidbit. Google remembered the 2:14AM bit for me though.)
--Joe--
Hate to break it to you, bub, but Michigan is very much in the Eastern time zone. You have to get on the other side of Lake Michigan to be in the Central time zone.
--
Never watched any of the SNLs from when Dan Aykroyd was still on it as a regular castmember, did you? How about this link on Everything2?
--Joe--
I am a DSP software applications-type person at a certain large DSP vendor. While I don't work in the broadband access group, I still get to occasionally implement the crazy algorithms that deal with the reflections, noise, and other crap that DSL has to put up with.
So, no, I'm not a phony. (And BTW, I believe SDSL and ADSL and all the other xDSL family connection types have to put up with the same annoyances unless you get fresh copper laid just for you. If you get a "dry pair" that's already in the ground, you still may have stubs, wire-gauge differences and distance-related signal attenuation to contend with. Thankfully, you do still miss out on repeaters (which I forgot in my post above), loading coils, and voice-band filters.))
BTW, I also wouldn't be surprised if telcos in the US just have crappier infrastructure overall than our Canadian neighbors. Partly because (in some areas) the infrastructure is as old as the hills and hard to get to to replace it all, and partly because the telcos (and big business in general) are in bed with the US Gov't. :-P Other contries have decent communication infrastructure, why not us?
I've noticed that the US has a tendency to not embrace new technology as quickly, as long as businesses can still milk $$ out of the current technology. Fun, fun... I suspect it's that sort of thinking that's left the US with a rotting, aging, non-DSL-friendly POTS network, little ISDN to speak of, and a country that 1/2 to 1 full step back from most of the world in deployed wireless technology. Whoo hoo!
--Joe--
There are several factors that come into play:
Changes in wire type/gauge. Every time you change gauge in wire, you potentially have an impedance mismatch which can cause reflections on the line. These reflections cause certain frequencies (well above human hearing range, but smack-dab in the middle of the DSL frequency range) to be attenuated or altogether canceled out.
Related to this are stubs. Often times, a single line pair leaving a junction box is spliced somewhere along the way and actually goes to two destinations -- one live, one not. This could happen for a variety of reasons, typically due to changes in service at residences near each other. Each stub also causes reflections (worse than those reflections caused by changes in wire gauge), and so this too frustrates DSL service.
Line filters. Strictly speaking, line filters aren't necessary until well down the line, where your voice-band data is converted to digital, or is analog-multiplexed with other signals on a line. To reduce crosstalk and noise (apparently), most POTS lines have line filters closer to the home so only voiceband energy is on the line. These kill DSL dead, as you noted.
Loading coils. On some longer runs out there, loading coils are on the lines to help even out the response curve of the line in the voice band, in part by absorbing reflections. These totally screw up the frequency bands outside the voice band though.
And finally, from what I recall, upper frequences attenuate fairly sharply with distance on unshielded copper, and so the further away you get, the fewer usable frequencies you have to play with.
So, yes, there are a lot of problems as you go from the CO to the end terminal. Some of these problems are in the last mile (changes in wire gauge, stubs) and some are along the way (loading coils).
--Joe--
Actually, there are sites that are starting to do something like that, if in a less proactive way. Rather than host the sites themselves, they sponsor sites which meet those criteria. Of course, the lack of impartiality on company-sponsored sites can make them less attractive. That's why you end up sometimes with "astroturf" sites which appear to be impartial by not disclosing their sponsorship, but are not... :-P Ah well.
Here's one example I came across recently: The website www.feline-behavior.com seems to be sponsored by Friskies Cat Food. Makes perfect sense, I suppose.
--Joe--
I think you mean the SNR is too low (as in, not much signal for the amount of noise). I tend to agree. The couple times I have clicked on a banner, I get dropped into some noisy top-level page that has nothing to do with the content of the ad. Either that, or a page that says "Click here to add to your shopping cart", with little detail about the product or the company.
*sigh*
--Joe--
Yeah, but do you ever dress up as Ada? :-) (And no, I'm not interested in seeing...)
--Joe--
It depends on whether it's modifying a word that immediately follows it, as in "That is an anal-retentive poster," or if it is used alone, as in "The poster is anal retentive."
:-)
--Joe(PS. As long as the CoS folks are around, I figure anything that's OT might as well be OT3...)
--
If you just want a plain login prompt on your text consoles, getty is what you want. Just point getty at ttyX and you're most of the way there. (Do it in /etc/inittab. Most of the distros do this for you...)
If that's not what you wanted, then perhaps you can elaborate on your question?
--Joe--
That's true only if you have sufficient hardware registers (not to be confused with architectural registers), and your tasks aren't bottlenecked on memory. If you have truly independent tasks, then each will effectively see half as much cache at all levels of the hierarchy. This can get especially painful in L1I -- if you can't keep the CPU fed from both streams, oops! And, large register files can be a speed limiter in the architecture. (On the plus side, though, the hardware register files can be distinct between the threads, so it's not too bad. As I understand it, it's the unified register files that are the real problem.)
One of the main attractive things I see in SMT is that you can effectively make the pipeline deeper on the architecture while completely hiding it. This is important on VLIW-style architectures that have an exposed pipeline. To make it deeper, you need to somehow hide the fact that it's deeper than the code thinks it is. One way is to add interlocks (gradually making stages of the pipeline protected, rather than exposed). Another is to interleave multiple threads, so that each thread sees the pipeline length it expects, but the actual pipeline is some factor larger.
Of course, in this VLIW world, things can get tricky outside the CPU. Because you lack superscalar issue (that's what VLIW's about), the issue of stalls becomes a problem. "One-stall-all-stall" is an oft-mentioned SMT VLIW technique, and with it, you really need to make sure you aren't bottlenecked on memory before you go down the SMT path. "One-stall-all-stall" means if one SMT thread stalls, all threads stall... As I understand it, it's the "cheap" way to maintain the VLIW state in an SMT VLIW machine, but it also amplifies any memory system bottlenecks you might have.
--Joe "Mr. VLIW"--
Optimization is all about turning compute-bound problems into I/O bound problems. Most processors are fast enough these days that they're I/O bound. Particularly if you have an OS that tends to keep L1 completely thrashed. (I recall seeing numbers which showed that Win9x tends to keep L1 completely hosed, whereas WinNT and Linux do not.)
Note that I/O bound doesn't necessarily mean bandwidth starved -- latency is also an issue with many typical tasks. Notice how RAMBUS machines tend to perform fairly slowly on many non-latency-tolerant tasks. It's not for lack of bandwidth.
What's worse is that we've passed the sweet spot in cache sizes such that L1 cache sizes are going to stop increasing and start decreasing again, sadly. (Transport delay in getting bits from the far side of L1 is limiter, I understand.)
Now the statement that most machines spend their time waiting for disk, I don't think that's quite true. That's maybe true under Windows (it certainly seemed to be last time I used it regularly, even with gobs of RAM handy), but it's certainly not true under Linux or Solaris. I almost never hear my HD run under normal circumstances. Even when it does run, it's not chugging incessantly. It's called "having enough RAM."
Even with enough RAM, though, PC133 SDRAM is quite a bit slower than L2, which is noticably slower than L1. Anything that doesn't stay in L1 most of the time is going to quickly bottleneck on the other levels of the memory hierarchy. Not much you can do about it, either.
--Joe--
I wrote a version that I embedded into my game, 4-Tris. This heart of this version was about 430 words of assembly code. I hadn't bothered to optimize for size. I'm sure you could get it somewhat smaller. Anyone?
--Joe--
I know it's in at least one version of Commander Keen (it's built into Keen's wristwatch), and I embedded a version in my Intellivision game 4-Tris.
It's such a simple and straightforward game, it's not surprising it's in so many places.
--Joe--
I prefer two passes of the XOR 0x69 filter. ;-)
--Joe--
Sounds pretty similar to SOUNDEX and related algorithms which attempt to find a "canonical form" based on the approximate phonetic content of a word.
So, "Wolf", "Wolff", "Wolffe" all collapse down to the same thing. Etc...
--Joe--
The whole scoop is here: http://www.trilobite.org/spispopd/.
Quoting from the page:
So there you have it.
--Joe--
Oh yeah... Smashing Pumpkins Into Small Piles Of Putrid Debris, by SuperEGO ! Anyone still have a copy of that game (pref. v1 as that's the one I played, although either version is fine).
--Joe--
CVS is pretty automated too. I just type cvs update and I'm brought up to date with no hassles. (...as long as I haven't edited any of the files.)
As for point #2: An arbitrary limitation makes it novel?
And point #3: I'm not sure what you mean here. In the case of CVS, there's a CVS directory with a file named Entries which says what versions are stored locally. The server uses this information to determine what to send you to bring you up to date. And on the server, the revision-control files in the Repository describe how one version is generated from another. Is that the kind of thing you're talking about?
--Joe--
This "layering" is not all that different than how MPEG video works with I, P, and B frames, either. :-P There's just way too much prior art for methods of performing incremental updates. Basically, in MPEG, you have I frames every so often (similar to monthly backups), P frames which are either predicted from a previous I frame, future I frame, previous P frame or future P frame (analagous to weekly incremental backups), and then B frames which are bidirectionally predicted from I or P frames (analagous to daily incremental backups). I forget the exact rules about what can be predicted from what, but the main point is that each non-I frame is expressed as a diff relative to some other non-B frame.
Incidentally, with CVS, you can still get the equivalent of monthly, weekly, and daily by compressing away intermediate versions in the repository. Essentially, you tell CVS that "Revisions x.a.b through x.y.z are no longer interesting", and it'll update the repository so that x.y.z is expressed as a diff relative to x.a.b, and all the versions in-between disappear.
And then there's the concepts of "trunk" and "branch" and....
--Joe--
It is, but it's not that much different than how RCS and CVS work. The main difference is that the differences are generated between the version of software being updated and the desired version. Since there could (theoretically) be hundreds of "versions" out there, there needs to be some way of finding out the starting version, and then applying the appropriate patches.
If I do a cvs update -ttag in my CVS work area, the CVS software looks at my Entries files and determines what versions I presently have checked out of the various files CVS controls. It then queries the server, which sends tailored diffs that will bring my work area in sync with the version specified by the provided tag. (Or, I can leave off the tag and be up-to-date with the most current version.) These diffs are generated specifically between the desired version and the currently checked out version. Additionally, CVS will try to merge differences if any of the patches don't apply cleanly (such as on files that I've edited locally, but have not checked in).
That sounds an awful like what the virus vendors are claiming to do, and I think RCS (upon which CVS is originally based) has definite prior art here. The oldest reference I've found to RCS is: Walter F. Tichy, RCS--A System for Version Control, Software--Practice & Experience 15, 7 (July 1985), 637-654. (Type man rcs if you have RCS installed.)
--Joe--
Our eyes only need ~20FPS to perceive motion, but there are definitely aspects of our vision that are sensitive to higher frequencies, particularly our peripheral vision. At I can see monitor flicker at >60Hz out of the corner of my eye, but I don't notice it really at all if I look at the monitor head-on.
Most of the reason we need high frame rates is that we don't do motion-blur when we generate the image. Without motion blur, you need high frame rates to ensure that contrasting edges don't move far between frames. Otherwise, you get "edge inversion" artifacts where your eye superimposes the same edge at two positions from consecutive frames.
This is also why live video from slow-motion cameras played at normal speed by dropping frames looks strangely crisp and unnatural.
--Joe--