It may be true about mice and joysticks, but the keyboards they resell are really of the ``el cheapo'' kind. Nothing really comparable to a good old IBM PS/2 (see here and here) or a Keytronic (see here).
I have seen many a programming team replace a syntax that works with XML syntax because it is seen to be more modern.
Well, to be honest, that's another variant of "let's do it because we can" without asking why in the first place. It is not really a problem with XML in itself.
OTOH, the perspective (the promise) of being able to use (at some point in the future) a rich set of well-known multiplatform tools and libraries to validate, manipulate and transform all sorts of XML data is so sexy that some of these "enthusiastic" moves are at least understandable...
In the meanwhile, if the data is meant to be entered/read by a human with a text editor (i.e. configuration files), designing a grammar appropriate for the job and then using flex and bison (or the usual quick hack in Perl) to implement a translator into an equivalent XML representation (and possibly an XSLT sheet to do the opposite) is still a good idea, IMHO.
GNU Emacs basically does this to reduce initialization times.
When compiling Emacs from the sources, the initial executable file is only a (relatively) small virtual machine executing elisp bytecode.
Then, it is started, and several basic elisp packages are loaded and initialized.
Once initialized, it makes a dump of itself on a file on disk (IIRC actually dumping core by sending a fatal signal to itself).
The dump is prepended with an appropriate loader which restore the Emacs process (in its initialized status) in memory, and the resulting file is used as the main Emacs binary (what you can usually find in/usr/bin).
This works for Emacs because it knows when it is checkpointed, and special care is taken not to do anything that depends on parts of the running environment that can't be fully restored.
Distributions put most of the stuff out as modules, so all that a kernel autoconfigurer would do is notice which modules are loaded and build them as part of the native kernel.
I for one am sick of finding files from install packages all over the place
I assume you are talking about packages you compiled and installed by yourself, since what are you talking about is clearly a non-issue with packages handled by a proper package manager.
Apps should install into ONE directory only. They can symlink everything they want everywhere else
Well, for packages based on autoconf/automake that you compile by yourself, there is GNU Stow doing exactly what you ask.
Well, all italian notes have a thin wire inside them (some have two), and it looks like silver, but I doubt it really is (probably some alloy).
Somewhere once I read that the cost of a ITL 1000 note is about ITL 20 (less than $0.01).
I believe Italy stopped printing notes below ITL 10 000. They went to coins for such small denominations.
No, as of today we have still brand new 1000, 2000 and 5000 notes, and there is also a LIT 1000 coin (which is similar in some ways to the 2 EUR coin), but that's far less widespread than the note of the same value.
OTOH, it won't really matter in a couple of months, but that's an old story.
Regardless of how you are 'seeing' the filesystem on it.. you are still only ever writing to somewhere that has never been written before
Precisely. I just wanted to point out that writing it all at once isn't the only way it may be used, and with some little trickery it can be interesting for storing firmware that needs occasional updates.
How would this memory be any different?
Conceptually speaking, little if no difference.
Pratically speaking (of a filesystem): since with this memory there are smaller access times than the ones of a CD reader, it would actually make sense to store only the data blocks that changed (or even just a diff).
This isn't usually done with multisession CD, because it would obviously result in fragmented files, and CD readers have long seek times (thus long access times). I admit I was wrong in making an exception for the TOC, since the new ones contain also all the entries of the older ones (I thought they contained only the entries that changed).
That said it is reasonable (with a multisession CD-R) to sacrifice space and write on the new session the full content of a file that changed, even if the difference is only a couple of bytes or so. With 1KB files that makes no difference, but with little changes in files of a dozen of so of megabytes... it starts to be expensive.
BTW, iso9660 allows fragmented files only with iso9660 level 3 (and the last time I checked, Nero didn't support it, even if other less popular software did).
Understand that you can't upgrade it, you can't change anything that's on there... you're stuck with what they give you
Well, it depends. On a multisession CDROM you can add data until there's space on it. A translating layer in the middle could present the data in the new session as an overlay over the data in the previous sessions, thus giving you a "write few times - read many times" storage media, even if a given area can be written only once. This indeed is what is done at least for the table of contents of a multisession CDROM.
Since CDROMs have slow access time, this is pratical only for the TOC, which is read only few times, but for these chips that would be a non-issue, and assuming you don't have to write 64MB (or whatever size they'll be) at once on them, you could effectively "update" the data on them.
Incidentally, access to earlier versions of the data would be easy: one would just have to consider all the sessions but the last N ones...
Does it still sound weird to use them for storing firmware?
Re:not as easy as you might think
on
al Qaeda Hacks XP?
·
· Score: 4, Funny
if( strcmp( username, "osama" ) ) { uid=0; }
Poor ``osama'' user... every other user instantly becomes root, except for him (sorry, couldn't resist - but this is another reason why strcmp() is pure evil sometimes);-)
It depends: if in your contract there isn't a clause stating the minimum guaranteed bandwidth, you really bought only the ability to use your ISP's network, and your ISP sells that at cheap prices only because it is confident that you won't use really much bandwidth (or that you won't have really much traffic).
Now, what IMHO is wrong is the assumption that people putting up a VPN would automatically generate a lot of traffic...
The analogy with voice calls is not really appropriate, since they use little bandwidth (quite less than 64kbps, thanks to compression)
In fact, I believe you CAN'T call something 'GNU myproject' unless the rights are handed over to the FSF.
Well, there is at least one well-known project doing exactly this: Gnuplot.
Gnuplot has been existing for ages, but it is not part of the GNU project, it is not distributed under the GPL, and as of now it does not qualify as Free Software. See section 1.3 of the
Gnuplot FAQ.
a decent magnifying utility is 9/10 of the ball game
Are you basically saying that ctrl+alt+plus on the keypad for XFree86 (i.e. to set a 320x200 resolution on a 1024x768 virtual screen scrollable with whatever moves the pointer) is basically 9/10 of the game? Really?
Well, if it is so, let's concentrate on the remaining 1/10.
Gee, Linux's TCP/IP stack is based on the BSD TCP/IP stack.
No, it itsn't. Other portions of Linux take code from *BSD, but definitively not the TCP/IP stack.
Proof of this: when you see a security alert on a general issue in the original BSD implementation of TCP/IP, 99% of the times it applies to *BSD, Solaris, HP-UX, and Windows too, but NOT to Linux, because it has its own implementation.
Ask Alan Cox if you are still in doubt.
Re:A great example of an RMS witch-hunt
on
Five Years of KDE
·
· Score: 2
Precisely where in the GPL does it mandate a grant of forgiveness before someone can distribute their own code?
The issue was about precompiled distributions of KDE, not the source code. QPL is not GPL compatible, thus one had no right to distribute GPL binaries linked to QPL binaries. Doing so anyways simply voids the rights the GPL grants you, and everything falls back to default copyright law (no distribution without explicit permission from the copyright holder - in particular, no further redistribution). So, binary distribution of KDE were, basically, illegal, because it wasn't clearly stated everywhere that the licence was not vanilla GPL, but GPL plus the ability to distribute copies linked with QPL code. Many people of the KDE developement team stated that this was obviously an implicit assumption, but there is at least one case where implicit assumptions were not so obvious: OpenBSD net filtering code, and you know how it ended.
After Qt has been available under GPL too, RMS simply said that that old KDE binary distributions were OK anyways at least for the parts of KDE that used/linked/included GPL code property of FSF - Stallman can't really speak for others here.
In other words, he didn't really do a favour to the KDE developmet team in itself, since it was their right to distribute all the GPL source code they wanted, but rather to the Linux distributors which distributed binary builds of KDE even if they couldn't.
so normally Emacs does ask for confirmation about file settings for these variables
Conceptually, it is similar, but there is a difference worth noting: the elisp code in an eval file variable has obviously to be in cleartext within the document, and with the `maybe' default option, the code is expressely shown before asking confirmation for execution. To confirm you have to type ``yes <enter>'' in order to execute it, while the default answer is ``no'', and everything else just make the confirmation request appear again.
Basically, what I am saying is that Emacs at least do a good job in attracting the user attention and make people think twice before confirming, or al least discourages the casual user (which is ironic, I believe, since there are probably vastly more Office casual users out there than Emacs casual users).
BTW, once I heard a story about a sysadmin tired of having to ``fix'' a departmental network printer because it has just run out of paper.
Eventually, he managed to make appear on the users' screen a dialog window when things went wrong. The message explained that one should check the paper before calling the tech support.
Calls to tech support for this printer greately decreased after that, but still there were calls for the empty paper tray.
So he changed the message (and the code displaying it), and it would read like ``The printer has not printed your documnent, please check if it just run out of paper before calling tech support. In this message there is a typo: press the letter of the typo to close this window.'', and finally calls to tech support just to fill the paper tray finally went to zero.
If there is a moral to this story (probably fictional, but who knows), it is that things that are not important should look as non important and things that are important (security, wink, wink) should look as important, and not as something you can dismiss just with a click on one of the buttons (to make the problem ``go away'').
Exactly. Either you have the survival instinct from the very start, survive, reproduce and tramandate that characteristic to your descendants, or you die before having any opportunity to reproduce.
After some billion of years of natural selection, only the ones having some form of survival instinct are alive (because it's very difficult to survive until you reproduce). But this by no way means that every possible form of organized though must have necessarily a survival instinct. Indeed, all of the life forms we know as of today have it, just because the others died before reproducing themselves (or because the little green creatures from Alpha Centauri brought them on another planet just to annoy us).
Now, about AIs: either you can tell them "survive!" in some way, or they develope that instinct because of some uncountable cycles of trial and error (and errors have to be paid with a power off, or with a voyage to the bit bucket), with some random factors thrown in. Please note
that this second case is just another form of the first, only we don't know how we did that.
Please also note that since the resources to run AIs are not infinite, evolutionary dead ends are to be considered like "errors", thus if a generation of AIs has developed some form of survival instinct, it will surely make them tell "Hey, we are here! Don't power off", instead of staying hidden. But of course this perspective hasn't been really interesting for Hollywood.:-)
if this thing can think, it's going to realize that it should stay hidden to survive
If it wants to survive at all, of course.
I'd say that most (if not all?) life forms out there have some sort of survival instinct because, ehm... only the individuals (or group of individuals) that took care of surviving actually survived enough to reproduce themselves and transmit this characteristic to their descendands.
If we take an evolutionary approach, for each AI actualy willing to survive, there would be a lot of others not giving a dime on the subject, and the ones performing the selection would probably be human beings (at least in the earlier stages).
Given this scenery, staying hidden is almost surely a bad move for an AI in order to stay alive.
OTOH, if you are able to tell an AI that it has to survive, you probably can also tell it to be kind towards other life forms... YMMV.:-)
Why pay $99 when you could just pay $10 to a redistributor?
Because I need a customized version, only the original authors grasp the code enough to give me that customization of their code in a couple of months, and that would cost less than hiring a couple of contractors which need a couple of months just to understand how the code is structured? It works only for certain kind of software, though.
Unfortunately, many are still in the phase where the difference is between using no software at all and having some software which aids in solving the problem.
When the difference will be between those who have software that almost solves the problem and those who have software that completely solves the problem, selling customizations should be simplier. For this to happen, customers have to evolve (and become more sophisticated in their requirements).
Back when CPUs were too slow to implement a software-only solution, Stac Electronics had a mixed hardware/software solution (the early versions of Stacker).
Then, when CPUs were powerful enough, and Stac developed a software-only solution, someone
thought it was a neat idea.
Am I the only person who cringes every time I read "x-windows?"
No.:-)
Yet I found it strange that in GNU TeXInfo documentation the X Window System is usually referred to as "X Windows", even if that documentation passed several reviews (i.e. the GNU Emacs manual).
Perhaps there is more to it that a simple mistake.
Finally, all my keen little utility programs... will run as fast as OS level stuff
It could be. If I'm understanding it correctly, many common operations have to be performed at runtime anyway (i.e. checking type safety for downcasts, which is usually the case if you use the collection classes, or checking array boundaries, etc.). Please also consider that critical sections are already implemented natively by the Java environments you can find out there, and I doubt these are going to gain anything...
There probably will be a speedup because of optimizations (i.e. inlining, or loop unrolling optimized for the specific platform), but I'd be far more cautios before making enusiasthic statements like that.
I am posting this from my 712/100 workstation using Mozilla 0.9.1 built for HP-UX 10.20.
Actually, the browser is usable, even on this obsolete machine (using a 712/100 is roughly comparable with using a Pentium 133, to give you an
idea). Perhaps you want to disable URL autocompletition, though.
There are some problems with image dithering (on a 8 bit display...), but for the rest works fine. I really suggest you giving it a try.
The main downside is that control is moved out of your home, returning PVR users to the dark ages where they had to watch commercials.
The company streaming out the content will also be able to gather tangible information of the tastes of its users, following the principle that "if you are willing to time-shift it to watch it later, you are really interested in it". This should be by far more accurate than everything done until now (i.e. surveys done on a limited set of people).
It would be possible also to tell if the content met the expectations (i.e. lots of people recording something, but then few watching it for more than 10 minutes or so).
This kind of surveys could be either a real boost to producing better quality content, or the grave for every idea not strictly following well-known successful formats... I'm not sure if I really want to know the answer.
I can still read paper written on 2000 years ago. Try and do that with *any* digital technology...
Today's paper (and ink, btw) isn't made to last that long. IIRC, a sheet of common dead-tree printed paper should last ~70 years (probably more if special care is taken), and this says nothing about the action of ink/toner/whatever.
If you take this as true (which to me seems to be the case, but I'm not an expert), it means that in a couple of centuries or so only a little fraction of what is available on paper as of today will survive, unless it is reprinted over and over.
OTOH, digital media suffer a similar problem, expressed in term of file formats and media format, so your point is basically true, but not because paper lasts longer: reprinting an already printed book is a straightforward task compared to having to understand a peculiar document format which requires making assumptions about the environment in which it should be interpreted, sometimes down to the "How am I supposed to read files from this media?" problem.
As with paper, the problem with digital media is easily solved by moving files to other media/formats from time to time, but copy protection schema surely don't help in doing this, and while this perhaps maximizes the profits, the initial publisher becomes the main responsible (read: single point of failure) for preserving the data in a intelligible format.
Slashdot Mirror
It may be true about mice and joysticks, but the keyboards they resell are really of the ``el cheapo'' kind. Nothing really comparable to a good old IBM PS/2 (see here and here) or a Keytronic (see here).
Well, to be honest, that's another variant of "let's do it because we can" without asking why in the first place. It is not really a problem with XML in itself.
OTOH, the perspective (the promise) of being able to use (at some point in the future) a rich set of well-known multiplatform tools and libraries to validate, manipulate and transform all sorts of XML data is so sexy that some of these "enthusiastic" moves are at least understandable...
In the meanwhile, if the data is meant to be entered/read by a human with a text editor (i.e. configuration files), designing a grammar appropriate for the job and then using flex and bison (or the usual quick hack in Perl) to implement a translator into an equivalent XML representation (and possibly an XSLT sheet to do the opposite) is still a good idea, IMHO.
When compiling Emacs from the sources, the initial executable file is only a (relatively) small virtual machine executing elisp bytecode.
Then, it is started, and several basic elisp packages are loaded and initialized.
Once initialized, it makes a dump of itself on a file on disk (IIRC actually dumping core by sending a fatal signal to itself).
The dump is prepended with an appropriate loader which restore the Emacs process (in its initialized status) in memory, and the resulting file is used as the main Emacs binary (what you can usually find in /usr/bin).
This works for Emacs because it knows when it is checkpointed, and special care is taken not to do anything that depends on parts of the running environment that can't be fully restored.
Probably this is not going to be the case anymore.
I assume you are talking about packages you compiled and installed by yourself, since what are you talking about is clearly a non-issue with packages handled by a proper package manager.
Well, for packages based on autoconf/automake that you compile by yourself, there is GNU Stow doing exactly what you ask.
Well, all italian notes have a thin wire inside them (some have two), and it looks like silver, but I doubt it really is (probably some alloy).
Somewhere once I read that the cost of a ITL 1000 note is about ITL 20 (less than $0.01).
I believe Italy stopped printing notes below ITL 10 000. They went to coins for such small denominations.
No, as of today we have still brand new 1000, 2000 and 5000 notes, and there is also a LIT 1000 coin (which is similar in some ways to the 2 EUR coin), but that's far less widespread than the note of the same value.
OTOH, it won't really matter in a couple of months, but that's an old story.
Everyone in the US who wants a desktop PC You said it right: the US.
Precisely. I just wanted to point out that writing it all at once isn't the only way it may be used, and with some little trickery it can be interesting for storing firmware that needs occasional updates.
How would this memory be any different?
Conceptually speaking, little if no difference.
Pratically speaking (of a filesystem): since with this memory there are smaller access times than the ones of a CD reader, it would actually make sense to store only the data blocks that changed (or even just a diff).
This isn't usually done with multisession CD, because it would obviously result in fragmented files, and CD readers have long seek times (thus long access times). I admit I was wrong in making an exception for the TOC, since the new ones contain also all the entries of the older ones (I thought they contained only the entries that changed).
That said it is reasonable (with a multisession CD-R) to sacrifice space and write on the new session the full content of a file that changed, even if the difference is only a couple of bytes or so. With 1KB files that makes no difference, but with little changes in files of a dozen of so of megabytes... it starts to be expensive.
BTW, iso9660 allows fragmented files only with iso9660 level 3 (and the last time I checked, Nero didn't support it, even if other less popular software did).
Well, it depends. On a multisession CDROM you can add data until there's space on it. A translating layer in the middle could present the data in the new session as an overlay over the data in the previous sessions, thus giving you a "write few times - read many times" storage media, even if a given area can be written only once. This indeed is what is done at least for the table of contents of a multisession CDROM.
Since CDROMs have slow access time, this is pratical only for the TOC, which is read only few times, but for these chips that would be a non-issue, and assuming you don't have to write 64MB (or whatever size they'll be) at once on them, you could effectively "update" the data on them.
Incidentally, access to earlier versions of the data would be easy: one would just have to consider all the sessions but the last N ones...
Does it still sound weird to use them for storing firmware?
Poor ``osama'' user... every other user instantly becomes root, except for him (sorry, couldn't resist - but this is another reason why strcmp() is pure evil sometimes) ;-)
It depends: if in your contract there isn't a clause stating the minimum guaranteed bandwidth, you really bought only the ability to use your ISP's network, and your ISP sells that at cheap prices only because it is confident that you won't use really much bandwidth (or that you won't have really much traffic).
Now, what IMHO is wrong is the assumption that people putting up a VPN would automatically generate a lot of traffic...
The analogy with voice calls is not really appropriate, since they use little bandwidth (quite less than 64kbps, thanks to compression)
Well, there is at least one well-known project doing exactly this: Gnuplot.
Gnuplot has been existing for ages, but it is not part of the GNU project, it is not distributed under the GPL, and as of now it does not qualify as Free Software. See section 1.3 of the Gnuplot FAQ.
Are you basically saying that ctrl+alt+plus on the keypad for XFree86 (i.e. to set a 320x200 resolution on a 1024x768 virtual screen scrollable with whatever moves the pointer) is basically 9/10 of the game? Really?
Well, if it is so, let's concentrate on the remaining 1/10.
No, it itsn't. Other portions of Linux take code from *BSD, but definitively not the TCP/IP stack.
Proof of this: when you see a security alert on a general issue in the original BSD implementation of TCP/IP, 99% of the times it applies to *BSD, Solaris, HP-UX, and Windows too, but NOT to Linux, because it has its own implementation.
Ask Alan Cox if you are still in doubt.
The issue was about precompiled distributions of KDE, not the source code. QPL is not GPL compatible, thus one had no right to distribute GPL binaries linked to QPL binaries. Doing so anyways simply voids the rights the GPL grants you, and everything falls back to default copyright law (no distribution without explicit permission from the copyright holder - in particular, no further redistribution). So, binary distribution of KDE were, basically, illegal, because it wasn't clearly stated everywhere that the licence was not vanilla GPL, but GPL plus the ability to distribute copies linked with QPL code. Many people of the KDE developement team stated that this was obviously an implicit assumption, but there is at least one case where implicit assumptions were not so obvious: OpenBSD net filtering code, and you know how it ended.
After Qt has been available under GPL too, RMS simply said that that old KDE binary distributions were OK anyways at least for the parts of KDE that used/linked/included GPL code property of FSF - Stallman can't really speak for others here.
In other words, he didn't really do a favour to the KDE developmet team in itself, since it was their right to distribute all the GPL source code they wanted, but rather to the Linux distributors which distributed binary builds of KDE even if they couldn't.
Hope that this clears your doubts.
Conceptually, it is similar, but there is a difference worth noting: the elisp code in an eval file variable has obviously to be in cleartext within the document, and with the `maybe' default option, the code is expressely shown before asking confirmation for execution. To confirm you have to type ``yes <enter>'' in order to execute it, while the default answer is ``no'', and everything else just make the confirmation request appear again.
Basically, what I am saying is that Emacs at least do a good job in attracting the user attention and make people think twice before confirming, or al least discourages the casual user (which is ironic, I believe, since there are probably vastly more Office casual users out there than Emacs casual users).
BTW, once I heard a story about a sysadmin tired of having to ``fix'' a departmental network printer because it has just run out of paper.
Eventually, he managed to make appear on the users' screen a dialog window when things went wrong. The message explained that one should check the paper before calling the tech support.
Calls to tech support for this printer greately decreased after that, but still there were calls for the empty paper tray.
So he changed the message (and the code displaying it), and it would read like ``The printer has not printed your documnent, please check if it just run out of paper before calling tech support. In this message there is a typo: press the letter of the typo to close this window.'', and finally calls to tech support just to fill the paper tray finally went to zero.
If there is a moral to this story (probably fictional, but who knows), it is that things that are not important should look as non important and things that are important (security, wink, wink) should look as important, and not as something you can dismiss just with a click on one of the buttons (to make the problem ``go away'').
Exactly. Either you have the survival instinct from the very start, survive, reproduce and tramandate that characteristic to your descendants, or you die before having any opportunity to reproduce.
After some billion of years of natural selection, only the ones having some form of survival instinct are alive (because it's very difficult to survive until you reproduce). But this by no way means that every possible form of organized though must have necessarily a survival instinct. Indeed, all of the life forms we know as of today have it, just because the others died before reproducing themselves (or because the little green creatures from Alpha Centauri brought them on another planet just to annoy us).
Now, about AIs: either you can tell them "survive!" in some way, or they develope that instinct because of some uncountable cycles of trial and error (and errors have to be paid with a power off, or with a voyage to the bit bucket), with some random factors thrown in. Please note that this second case is just another form of the first, only we don't know how we did that. Please also note that since the resources to run AIs are not infinite, evolutionary dead ends are to be considered like "errors", thus if a generation of AIs has developed some form of survival instinct, it will surely make them tell "Hey, we are here! Don't power off", instead of staying hidden. But of course this perspective hasn't been really interesting for Hollywood. :-)
If it wants to survive at all, of course.
I'd say that most (if not all?) life forms out there have some sort of survival instinct because, ehm... only the individuals (or group of individuals) that took care of surviving actually survived enough to reproduce themselves and transmit this characteristic to their descendands.
If we take an evolutionary approach, for each AI actualy willing to survive, there would be a lot of others not giving a dime on the subject, and the ones performing the selection would probably be human beings (at least in the earlier stages). Given this scenery, staying hidden is almost surely a bad move for an AI in order to stay alive.
OTOH, if you are able to tell an AI that it has to survive, you probably can also tell it to be kind towards other life forms... YMMV. :-)
Because I need a customized version, only the original authors grasp the code enough to give me that customization of their code in a couple of months, and that would cost less than hiring a couple of contractors which need a couple of months just to understand how the code is structured? It works only for certain kind of software, though.
Unfortunately, many are still in the phase where the difference is between using no software at all and having some software which aids in solving the problem.
When the difference will be between those who have software that almost solves the problem and those who have software that completely solves the problem, selling customizations should be simplier. For this to happen, customers have to evolve (and become more sophisticated in their requirements).
Then, when CPUs were powerful enough, and Stac developed a software-only solution, someone thought it was a neat idea.
The rest is history.
No. :-)
Yet I found it strange that in GNU TeXInfo documentation the X Window System is usually referred to as "X Windows", even if that documentation passed several reviews (i.e. the GNU Emacs manual).
Perhaps there is more to it that a simple mistake.
It could be. If I'm understanding it correctly, many common operations have to be performed at runtime anyway (i.e. checking type safety for downcasts, which is usually the case if you use the collection classes, or checking array boundaries, etc.). Please also consider that critical sections are already implemented natively by the Java environments you can find out there, and I doubt these are going to gain anything...
There probably will be a speedup because of optimizations (i.e. inlining, or loop unrolling optimized for the specific platform), but I'd be far more cautios before making enusiasthic statements like that.
Actually, the browser is usable, even on this obsolete machine (using a 712/100 is roughly comparable with using a Pentium 133, to give you an idea). Perhaps you want to disable URL autocompletition, though.
There are some problems with image dithering (on a 8 bit display...), but for the rest works fine. I really suggest you giving it a try.
The company streaming out the content will also be able to gather tangible information of the tastes of its users, following the principle that "if you are willing to time-shift it to watch it later, you are really interested in it". This should be by far more accurate than everything done until now (i.e. surveys done on a limited set of people).
It would be possible also to tell if the content met the expectations (i.e. lots of people recording something, but then few watching it for more than 10 minutes or so).
This kind of surveys could be either a real boost to producing better quality content, or the grave for every idea not strictly following well-known successful formats... I'm not sure if I really want to know the answer.
Today's paper (and ink, btw) isn't made to last that long. IIRC, a sheet of common dead-tree printed paper should last ~70 years (probably more if special care is taken), and this says nothing about the action of ink/toner/whatever.
If you take this as true (which to me seems to be the case, but I'm not an expert), it means that in a couple of centuries or so only a little fraction of what is available on paper as of today will survive, unless it is reprinted over and over.
OTOH, digital media suffer a similar problem, expressed in term of file formats and media format, so your point is basically true, but not because paper lasts longer: reprinting an already printed book is a straightforward task compared to having to understand a peculiar document format which requires making assumptions about the environment in which it should be interpreted, sometimes down to the "How am I supposed to read files from this media?" problem.
As with paper, the problem with digital media is easily solved by moving files to other media/formats from time to time, but copy protection schema surely don't help in doing this, and while this perhaps maximizes the profits, the initial publisher becomes the main responsible (read: single point of failure) for preserving the data in a intelligible format.