Ever wondered why we are seeing a rapid increase in solar activity?
As spectacular as the emissions of Xrays and charged particles from solar flares may be, they don't represent an overall increase in solar output.
After all, increased "solar activity" also represents an increase in sunspots which are cooler areas of the Sun's photosphere.
If you think about it this isn't as strange as it seems
at first glance.
The technology for accurately communicating and amplifying
waveforms has gotten steadily cheaper, in large
part due to digital coding and advances in semiconductor
technology.
There has been no such radical technical improvement in the
sound transducers -- microphones, speakers, and headphones.
Quality costs about as much as it ever did, with economies
due to technical
improvements pretty much eaten up by inflation.
(And I'm not talking about the phony "improvements" used
to part affluent audiophiles from their money,
like 00 oxygen-free crystal-aligned litz wire.)
I expect to spend about as much for a good set of headphones
today as I did 20 years ago.
The problem with Judith Harris' book is that she
dismisses claims of parental influence as "anecdotal" but
doesn't offer anything more objective supporting
the notion that peer influence is the missing factor.
One study she considers authoratiative gives a.19
correlation between parenting and outcone; she makes
much of this number, of how it pretty much eliminates
parents as a major influence.
But where are the (one must assume) stronger
numbers for peer influence?
I don't entirely disagree with Harris' point, though;
parents can have a vanishingly small amount to do with
their children's ultimate development if they choose
not to, at least in American society.
The influence of peers, the media, and so on, might
actually yield a relatively healthy outcome, given
reasonable luck and a good (genetically-determined
temperament.
But this doesn't mean that parents couldn't have
made a difference -- perhaps a very large one -- if
they had decided to do so.
Maybe most parents don't; it's a lot of work, after all.
And this is where Harris' numbers break down: they are
based on statistical averages.
They say little about the kind of influence parents
could have.
We're talking about a different level of abstraction, here.
After all, from the OS's perspective, how can Plan9 "use the
network stack of a remote machine" except via the network
stack of the local machine?
Nothing short of magic will let a machine "use another machine's nic" except via packets sent through its own.
Yes, Plan9 supports user namespaces that allows network
interfaces to be virtualized, but that's from the perspective
of what BSD calls "userland" -- which is only partly
related to what the article discusses.
This facility is about allowing multiple networks stacks
from the kernel's perspective.
Not just the illusion of separate stacks as seen from
userland (though it certainly provides that, too).
These stacks can then be treated independently from
the perspective of packet filtering, traffic shaping,
and so on, as well as providing a "virtual machine"
from a user's perspective.
This isn't to say that Plan9's capabilities aren't
useful or interesting, especially from a theoretical
perspective.
But Plan9 has different goals than an OS like FreeBSD
that first and foremost is designed to be used as on
server in a datacenter.
Thus the perspective is more along the lines of machine
virtualization and really has little to do with Plan9's
concept of a namespace.
In most cases, I really doubt that embedding access control in the document is workable.
Most organizations are pretty dynamic, with both internal
and external turnover of personnel.
Adding or revoking
access on a document-by-document basis would be such a pain
that I suspect the general tendency will be for individuals
to misuse the mechanism in ways that circumvent its effectiveness.
Why?
Because in practice it will wind up restricting access from
those who need it as much as preventing access for those who don't.
I'd much rather have a mechanism that allowed me to add or
remove access for a given set of documents as a single action
than such inappropriately fine-grained control such as this.
Perl, cpp, m4, C++, and other code-generation systems do TEXT substitution/rewriting.
There is a lot more going on
here
(for instance) than text-substitution.
The syntax for C++ templates may make LISP's seem downright
pleasant, even for a LISP-hater, and some of the techniques border on language abuse,
but it forms a full-blown compile-time functional programming language that integrates fulling into the C++ type and class mechanism.
The Boost library collection is full of such metaprogramming, such as
this.
-Ed
Re:Please, DO NOT support them
on
Support FreeBSD
·
· Score: 5, Insightful
You must not have spent much time reading LKML (Linux Kernel Mailing List).
It's hardly populated by paragons of politeness (from Linus
on down).
That's hardly a surprise -- they are there to conduct the
serious business of building and enhancing
the Linux kernel, and naive questions draw dismissive
responses if they are answered at all.
So why are people so surprised at the responses they get when
they post inappropriately to the equivalent FreeBSD lists?
I've seen it happen again aand again: someone posts an
inappropriate question to freebsd-stable,
freebsd-current, or some other technical list,
and after a few private suggestions to take
it to freebsd-questions or freebsd-chat
persists in posting.
It's usually only then that one of the heavy hitters decides
to knock him out of the ring...
As for Matt Dillion, he was given a choice: play by the
rules, or leave.
He chose the latter.
It's no secret that he didn't agree with some of the
choices made in FreeBSD 5 development, so it's a good
thing that he's decided to channel his considerable
talents into creating his own distribution based on FreeBSD 4.
Nonetheless, he still is on cordial terms with many of the
FreeBSD developers, still runs FreeBSD on many of his
machines, still makes bug reports and suggests patches,
and so on.
In other words, he shows a lot more class and maturity than guys like you who, sore after some imagined slight, take anonymous pot-shots from the sidelines.
Read the article; it's far more ingenious than that.
The coil is just feed into two PIC inputs, and the PIC's
static-protection diodes do the rectification.
A zener and a cap across the power pins complete the
power supply.
It gets better.
They use the clock pin as one of those inputs.
Thus the chip is clocked by the received RF.
And by briefing switching the other input to
an output, they communicate pulses back to the
sender.
(That right -- no separate RFID chip, the PIC does
all the sending as well as the sensing.)
Speaking of sensing, it gets even better.
The capacitance measurement used to determine
the fluid level is done by switiching two other
input/output pins and a fixed capacitor
to create a charge pump measurement.
By counting the number of times a charge on
the fluid-measuring capacitance has to be transfered
to the fixed capacitor to bring it up to a logic
level, they measure picofarad differences corresponding
to changing fluid levels easily.
What part of "these sorts of things can already be done on 32-bit systems, but the 4GB address space creates a brick wall when you try to scale," didn't you understand?
64bit math is actually not the draw of 64bits, it's all about the mapping capabilities.
Bingo!
One of the more interesting aspects of 64-bit platforms is
that they enable a programming model where a
process maps all its files into its address space and
lets the OS's VM system handle all the I/O.
This can have huge advantages; for example, the OS can
perform I/O directly into the process's memory and can
even share that memory
via the VM mappings
when multiple processes open the same file.
Simultaneous updates are much easier to handle than with
explicit reads and writes, and it even
becomes possible to embed
synchronization data structures (e.g. mutexes) right in the
file itself and use them efficiently.
These sorts of things can already be done on 32-bit systems,
but the 4GB address space creates a brick wall when you try to scale.
16 exabytes is a hell of a lot of address space, and
although it's likely to be exceeded at some point, it is
more than enough to handle any existing database.
Don't underestimate the power of a programming system where
all data is accessed in the same way; it can both simplify
code and remove the opportunity for bugs.
If the operating system manages its VM intelligently, it
can improve performance in many cases as well.
You're forgetting something.
OGG shows the world that free software can do as well
or better than proprietary.
OGG's existance and prevelance has everything to
do with discrediting the model you despise.
You're just pissing in the wind by using MP3; if you use,
demand, and support OGG, you're sending a stronger
message IMHO.
You mean VA Software Corporation, of which OSDN is
a wholly-owned subsidiary.
I'd say that
things are looking better
than they were even a couple months ago.
Of course, if the naysayers had been right, they'd have
gone "poof" in 2000 or 2001, like about 80% of companies
formed during the internet bubble.
is on the wall behind the computer.
One of the biggest noise-emitters is
often the power supply fan
and noise from other sources tends to leak
out through other access points on the
computer's back.
If the computer's back faces the wall,
putting a block of good sound-absorbing material
can lower the amount of noise radiated into the
room quite noticeably.
You don't even need a screwdriver.
-Ed
I'd have thought this would be on the front page
on
FreeBSD 802.11a/g Support
·
· Score: 5, Interesting
Given that there have been a lot of complaints that
802.11{a,g} wasn't available for Linux & BSD
and that this announces both FreeBSD and Linux
drivers for 802.11{a,g}, I'd have expected this
to appear on the front page.
Not that this driver is a perfect solution --
part of the driver
is closed due to "legal requirements" --
but that hasn't
kept, say, Nvidia's drivers from being Big News.
As you imply, back in the really old days, there was
effectively only one class C (later an effective class B)
for the entire ARPANET (although they didn't actually
have such a thing as "class A," "class B," and so on back
then).
Everyone was on net 10, e.g. 10.0.0.1, 10.0.0.2, and so on.
The place I worked at then (RAND) had 10.0.0.7.
I'm sure that at the time some folks thought that using
four address bytes was gross overkill, but in retrospect
it was amazingly far-sighted.
It's not a coincidence that when the Great Split
of the ARPANET into MILNET and the public Internet
happened, net 10 was declared dead (and thus
unrouted).
That's why the entire class A net 10 is now used
only for private networks (along
with net 192.168), since these addresses will
never be used on the public network (and aren't likely
to get anywhere should they "escape").
The release notes mention that an experimental amd64
release is available, but don't mention that
it can be downloaded from
here,
including ISO images.
Most of the credit for its rapid development goes to Peter Wemm,
who nearly single-handedly
took the X86-64 architecture from "it can't even mount the root filesystem or exec init"
to a nearly-polished release in little more than a month.
(And, no, it wasn't just a matter of copying what NetBSD did;
the processor-specific parts of FreeBSD and NetBSD are quite
different.)
Nope.
On Alpha Linux, in any case, sizeof(int) == 4
while sizeof(void*) == 8.
Now sizeof(long) == 8, so you could force a
pointer into a long if you wanted to.
But the C standard doesn't even guarantee that a
long is big enough.
Writing code that makes such assumptions shows that
the author has a bit more to learn about C, or just
doesn't care about portability.
Here is a commit message, which lists what is and isn't working yet.
There are still some loose ends (as the message states), but things appear to be coming along quickly.
So definitely be very careful, especially if you connect to a line-powered oscilloscope or other equipment.
Or a line-powered computer.
I was amazed how he went to the trouble of explaining
how he used a 9V battery for safety, but said nothing
about using a battery-powered (with the
charger disconnected!) laptop.
Just because the server can handle the load doesn't mean that
its network connection has the bandwidth.
The OS is often irrelevent.
In fact, in many cases of "slashdotting" the servers
(whatever they're running) do fine, but the network "pipe"
isn't big enough.
There's a bit of a positive feed back loop as well,
since the tiny bandwidth available for any given
connection makes it slower, and thus take longer, and
thus increase the number of simultaneous connections
the server has to handle.
The latter can be hell on database backends
(a common failure mode when DB-driven sites are overloaded)
and on a poorly-configured server can run it out of
system resources as well.
As for FreeBSD 5.1-BETA2, I'm sure it could handle the load,
but it's not going to be as stable as FreeBSD 4.8, and
the FreeBSD folks will freely admit as much.
That's why it's "BETA,"
and it's also why the 5.x branch most likely
won't be labeled "STABLE" until 5.2.
Until then, the place to test it is as a member of a
server farm,
where if it does happen to have trouble the load will
immediately be taken over by other machines.
It really isn't appropriate to use beta software
as a stand-alone FTP server.
That doesn't mean that people won't try
(just like there are servers out there running Linux 2.5).
But it would be irresponsible to do this for any
server that is mission-critical.
The ARPANET (or ARPA Internet as some called it at the time)
existedbefore Gore was in office.
Gore had nothing to do with its creation, and never
really claimed to.
It had a backbone, which became MILNET after DARPA cut off
all the nodes which couldn't justify their
connection in terms of support for military projects.
Gore's legislation created a new backbone, run by the
National Science Foundation.
Without it, and without Gore's follow-on legislation
opening it up to commercial use, the Internet as we
know it would not exist.
You can quibble with the phrase "took the initiative in creating the Internet" (more accurate would be
"created the backbone of the modern Internet"), but it
doesn't change the fact that Gore's role was a crucial one.
But in the only sense that matters for a politition, he
did create the Internet.
Senator Gore (or rather some unnamed staffer) wrote the
legislation that created NSFNET back when DARPA was
chasing everyone without military connections off the
ARPANET (resulting in the MILNET).
Thus was born the backbone of the Internet.
He also wrote the continuing legislation that funded
the NSF backbone for the five or six years it took to become
self-sufficent.
This was no mean feat; contrary to the grandparent post
that claims he was just riding a wave of support, there
was a lot of opposition and cries of wasted taxpayer
money.
(Eventually those cries were right -- funding lasted a
couple years longer than it probably needed to.)
It wasn't until after Netscape's success that VCs
started lining up with funding and the real "wave" began.
The perception that the Internet was a desirable thing was quite uncommon thirteen years ago even if it seems
perfectly obvious to us now.
I guess you save some gas not having to return them tho.
Bingo!
Even at 30 miles per gallon, a two-mile trip to return a video to a nearby rental store is going to use more petrochemicals and (probably) produce more polution than the production and discarding of the DVD itself.
What's weird is (for instance) people driving 15 miles each way to recycle 50 pounds of glass bottles.
Hell, even a Toyota Prius isn't going to make that sort of thing cost-effective.
There are a lot of reasons to dislike this idea.
Environmentalism isn't one of them.
Slashdot Mirror
As spectacular as the emissions of Xrays and charged particles from solar flares may be, they don't represent an overall increase in solar output. After all, increased "solar activity" also represents an increase in sunspots which are cooler areas of the Sun's photosphere.
It's:
If you think about it this isn't as strange as it seems at first glance. The technology for accurately communicating and amplifying waveforms has gotten steadily cheaper, in large part due to digital coding and advances in semiconductor technology. There has been no such radical technical improvement in the sound transducers -- microphones, speakers, and headphones. Quality costs about as much as it ever did, with economies due to technical improvements pretty much eaten up by inflation. (And I'm not talking about the phony "improvements" used to part affluent audiophiles from their money, like 00 oxygen-free crystal-aligned litz wire.)
I expect to spend about as much for a good set of headphones today as I did 20 years ago.
The problem with Judith Harris' book is that she dismisses claims of parental influence as "anecdotal" but doesn't offer anything more objective supporting the notion that peer influence is the missing factor. One study she considers authoratiative gives a .19
correlation between parenting and outcone; she makes
much of this number, of how it pretty much eliminates
parents as a major influence.
But where are the (one must assume) stronger
numbers for peer influence?
I don't entirely disagree with Harris' point, though; parents can have a vanishingly small amount to do with their children's ultimate development if they choose not to, at least in American society. The influence of peers, the media, and so on, might actually yield a relatively healthy outcome, given reasonable luck and a good (genetically-determined temperament. But this doesn't mean that parents couldn't have made a difference -- perhaps a very large one -- if they had decided to do so. Maybe most parents don't; it's a lot of work, after all. And this is where Harris' numbers break down: they are based on statistical averages. They say little about the kind of influence parents could have.
We're talking about a different level of abstraction, here. After all, from the OS's perspective, how can Plan9 "use the network stack of a remote machine" except via the network stack of the local machine? Nothing short of magic will let a machine "use another machine's nic" except via packets sent through its own. Yes, Plan9 supports user namespaces that allows network interfaces to be virtualized, but that's from the perspective of what BSD calls "userland" -- which is only partly related to what the article discusses.
This facility is about allowing multiple networks stacks from the kernel's perspective. Not just the illusion of separate stacks as seen from userland (though it certainly provides that, too). These stacks can then be treated independently from the perspective of packet filtering, traffic shaping, and so on, as well as providing a "virtual machine" from a user's perspective. This isn't to say that Plan9's capabilities aren't useful or interesting, especially from a theoretical perspective. But Plan9 has different goals than an OS like FreeBSD that first and foremost is designed to be used as on server in a datacenter. Thus the perspective is more along the lines of machine virtualization and really has little to do with Plan9's concept of a namespace.
In most cases, I really doubt that embedding access control in the document is workable. Most organizations are pretty dynamic, with both internal and external turnover of personnel. Adding or revoking access on a document-by-document basis would be such a pain that I suspect the general tendency will be for individuals to misuse the mechanism in ways that circumvent its effectiveness. Why? Because in practice it will wind up restricting access from those who need it as much as preventing access for those who don't. I'd much rather have a mechanism that allowed me to add or remove access for a given set of documents as a single action than such inappropriately fine-grained control such as this.
There is a lot more going on here (for instance) than text-substitution. The syntax for C++ templates may make LISP's seem downright pleasant, even for a LISP-hater, and some of the techniques border on language abuse, but it forms a full-blown compile-time functional programming language that integrates fulling into the C++ type and class mechanism. The Boost library collection is full of such metaprogramming, such as this.
You must not have spent much time reading LKML (Linux Kernel Mailing List). It's hardly populated by paragons of politeness (from Linus on down). That's hardly a surprise -- they are there to conduct the serious business of building and enhancing the Linux kernel, and naive questions draw dismissive responses if they are answered at all. So why are people so surprised at the responses they get when they post inappropriately to the equivalent FreeBSD lists?
I've seen it happen again aand again: someone posts an inappropriate question to freebsd-stable, freebsd-current, or some other technical list, and after a few private suggestions to take it to freebsd-questions or freebsd-chat persists in posting. It's usually only then that one of the heavy hitters decides to knock him out of the ring...
As for Matt Dillion, he was given a choice: play by the rules, or leave. He chose the latter. It's no secret that he didn't agree with some of the choices made in FreeBSD 5 development, so it's a good thing that he's decided to channel his considerable talents into creating his own distribution based on FreeBSD 4. Nonetheless, he still is on cordial terms with many of the FreeBSD developers, still runs FreeBSD on many of his machines, still makes bug reports and suggests patches, and so on.
In other words, he shows a lot more class and maturity than guys like you who, sore after some imagined slight, take anonymous pot-shots from the sidelines.
Read the article; it's far more ingenious than that. The coil is just feed into two PIC inputs, and the PIC's static-protection diodes do the rectification. A zener and a cap across the power pins complete the power supply.
It gets better. They use the clock pin as one of those inputs. Thus the chip is clocked by the received RF. And by briefing switching the other input to an output, they communicate pulses back to the sender. (That right -- no separate RFID chip, the PIC does all the sending as well as the sensing.)
Speaking of sensing, it gets even better. The capacitance measurement used to determine the fluid level is done by switiching two other input/output pins and a fixed capacitor to create a charge pump measurement. By counting the number of times a charge on the fluid-measuring capacitance has to be transfered to the fixed capacitor to bring it up to a logic level, they measure picofarad differences corresponding to changing fluid levels easily.
An utterly amazing bit of minimalist engineering!
What part of "these sorts of things can already be done on 32-bit systems, but the 4GB address space creates a brick wall when you try to scale," didn't you understand?
Bingo! One of the more interesting aspects of 64-bit platforms is that they enable a programming model where a process maps all its files into its address space and lets the OS's VM system handle all the I/O. This can have huge advantages; for example, the OS can perform I/O directly into the process's memory and can even share that memory via the VM mappings when multiple processes open the same file. Simultaneous updates are much easier to handle than with explicit reads and writes, and it even becomes possible to embed synchronization data structures (e.g. mutexes) right in the file itself and use them efficiently. These sorts of things can already be done on 32-bit systems, but the 4GB address space creates a brick wall when you try to scale. 16 exabytes is a hell of a lot of address space, and although it's likely to be exceeded at some point, it is more than enough to handle any existing database.
Don't underestimate the power of a programming system where all data is accessed in the same way; it can both simplify code and remove the opportunity for bugs. If the operating system manages its VM intelligently, it can improve performance in many cases as well.
You're forgetting something. OGG shows the world that free software can do as well or better than proprietary. OGG's existance and prevelance has everything to do with discrediting the model you despise. You're just pissing in the wind by using MP3; if you use, demand, and support OGG, you're sending a stronger message IMHO.
You mean VA Software Corporation, of which OSDN is a wholly-owned subsidiary. I'd say that things are looking better than they were even a couple months ago. Of course, if the naysayers had been right, they'd have gone "poof" in 2000 or 2001, like about 80% of companies formed during the internet bubble.
is on the wall behind the computer. One of the biggest noise-emitters is often the power supply fan and noise from other sources tends to leak out through other access points on the computer's back. If the computer's back faces the wall, putting a block of good sound-absorbing material can lower the amount of noise radiated into the room quite noticeably.
You don't even need a screwdriver.
Given that there have been a lot of complaints that 802.11{a,g} wasn't available for Linux & BSD and that this announces both FreeBSD and Linux drivers for 802.11{a,g}, I'd have expected this to appear on the front page. Not that this driver is a perfect solution -- part of the driver is closed due to "legal requirements" -- but that hasn't kept, say, Nvidia's drivers from being Big News.
Curious...
In any case, Thanks, Sam!
As you imply, back in the really old days, there was effectively only one class C (later an effective class B) for the entire ARPANET (although they didn't actually have such a thing as "class A," "class B," and so on back then). Everyone was on net 10, e.g. 10.0.0.1, 10.0.0.2, and so on. The place I worked at then (RAND) had 10.0.0.7. I'm sure that at the time some folks thought that using four address bytes was gross overkill, but in retrospect it was amazingly far-sighted.
It's not a coincidence that when the Great Split of the ARPANET into MILNET and the public Internet happened, net 10 was declared dead (and thus unrouted). That's why the entire class A net 10 is now used only for private networks (along with net 192.168), since these addresses will never be used on the public network (and aren't likely to get anywhere should they "escape").
The release notes mention that an experimental amd64 release is available, but don't mention that it can be downloaded from here, including ISO images.
Most of the credit for its rapid development goes to Peter Wemm, who nearly single-handedly took the X86-64 architecture from "it can't even mount the root filesystem or exec init" to a nearly-polished release in little more than a month. (And, no, it wasn't just a matter of copying what NetBSD did; the processor-specific parts of FreeBSD and NetBSD are quite different.)
Nope. On Alpha Linux, in any case, sizeof(int) == 4 while sizeof(void*) == 8. Now sizeof(long) == 8, so you could force a pointer into a long if you wanted to. But the C standard doesn't even guarantee that a long is big enough. Writing code that makes such assumptions shows that the author has a bit more to learn about C, or just doesn't care about portability.
Or a line-powered computer. I was amazed how he went to the trouble of explaining how he used a 9V battery for safety, but said nothing about using a battery-powered (with the charger disconnected!) laptop.
No; see the schedule. You're thinking of 5.1-RC1 (the "release candidate").
Just because the server can handle the load doesn't mean that its network connection has the bandwidth. The OS is often irrelevent.
In fact, in many cases of "slashdotting" the servers (whatever they're running) do fine, but the network "pipe" isn't big enough. There's a bit of a positive feed back loop as well, since the tiny bandwidth available for any given connection makes it slower, and thus take longer, and thus increase the number of simultaneous connections the server has to handle. The latter can be hell on database backends (a common failure mode when DB-driven sites are overloaded) and on a poorly-configured server can run it out of system resources as well.
As for FreeBSD 5.1-BETA2, I'm sure it could handle the load, but it's not going to be as stable as FreeBSD 4.8, and the FreeBSD folks will freely admit as much. That's why it's "BETA," and it's also why the 5.x branch most likely won't be labeled "STABLE" until 5.2. Until then, the place to test it is as a member of a server farm, where if it does happen to have trouble the load will immediately be taken over by other machines. It really isn't appropriate to use beta software as a stand-alone FTP server. That doesn't mean that people won't try (just like there are servers out there running Linux 2.5). But it would be irresponsible to do this for any server that is mission-critical.
The ARPANET (or ARPA Internet as some called it at the time) existedbefore Gore was in office. Gore had nothing to do with its creation, and never really claimed to. It had a backbone, which became MILNET after DARPA cut off all the nodes which couldn't justify their connection in terms of support for military projects. Gore's legislation created a new backbone, run by the National Science Foundation. Without it, and without Gore's follow-on legislation opening it up to commercial use, the Internet as we know it would not exist. You can quibble with the phrase "took the initiative in creating the Internet" (more accurate would be "created the backbone of the modern Internet"), but it doesn't change the fact that Gore's role was a crucial one.
But in the only sense that matters for a politition, he did create the Internet. Senator Gore (or rather some unnamed staffer) wrote the legislation that created NSFNET back when DARPA was chasing everyone without military connections off the ARPANET (resulting in the MILNET). Thus was born the backbone of the Internet. He also wrote the continuing legislation that funded the NSF backbone for the five or six years it took to become self-sufficent. This was no mean feat; contrary to the grandparent post that claims he was just riding a wave of support, there was a lot of opposition and cries of wasted taxpayer money. (Eventually those cries were right -- funding lasted a couple years longer than it probably needed to.) It wasn't until after Netscape's success that VCs started lining up with funding and the real "wave" began. The perception that the Internet was a desirable thing was quite uncommon thirteen years ago even if it seems perfectly obvious to us now.
Bingo!
Even at 30 miles per gallon, a two-mile trip to return a video to a nearby rental store is going to use more petrochemicals and (probably) produce more polution than the production and discarding of the DVD itself.
What's weird is (for instance) people driving 15 miles each way to recycle 50 pounds of glass bottles. Hell, even a Toyota Prius isn't going to make that sort of thing cost-effective.
There are a lot of reasons to dislike this idea. Environmentalism isn't one of them.