$25,116.50 of 1982 goods would cost $53,954.93 in 2007 according to the calculator.
You wouldn't need double the amount of money your parents made due to inflation to have the same standard of living your frugal parents had. You'd need 2.15 times!
A chicken's quest? Probably meant "fool", but it's funnier this way.:)
Anyways the "paperless is green" idea isn't because we're going to run out of wood. Almost all paper is made from trees that are grown (and replanted and regrown) for that purpose. However turning that wood into paper and shipping it to the utility uses energy and money. Putting ink on the paper likewise isn't free, and mailing it (in postal trucks that burn gas) isn't free either.
Whether you measure in total energy spent or dollars, it's cheaper to have online bills than mailing out paper statements. Most places let you download a PDF of what the paper statement would have been, giving you the efficiencies of online bills while still being able to have a copy of old bills (and print them on demand).
Utilities push online billing because it saves them money; the fact that it also saves energy in the process and is more convenient for consumers is a win/win/win.
You're right, using nuclear instead of coal doesn't change the fact that mining is dangerous. But it does remove the "definitely release tons of toxic and radioactive waste into the air" issue and replace it with a "if everything went horribly wrong, radioactive materials might escape".
If we have a reliable "pickup truck" that can carry a small payload to orbit, then do it again in less than a week, we can send up the crew and supplies for a moon mission.
That was the original objective for the Shuttle - a reusable vehicle that could be turned around quickly.
It reminds me of a time when a teacher who was teaching Pascal explained to us that divisions where executed by repeatedly subtracting, sad but true.
The point your teacher was probably trying to make is that not all instructions cost the same CPU time, even if they use the same number of instructions to issue. Depending on when your teacher learned computers, what architecture the class had in mind, and how old his textbook was, his statement might have been true for the cases he was thinking of.
Some early processors (such as original PDP-11) did not have a DIV instruction at first, so Pascal (and other languages) would have had to emulate it. Some embedded processors also do not have a divide instruction. Dividing isn't universal in processor instruction sets. The simplest (although not usually the most efficient) way to emulate a divide is with repeated subtraction. It's also possible for processors that support a divide instruction to internally subtract in a loop. Pascal (and other languages) also had floating point libraries that couldn't rely on the floating point unit being there; it's entirely possible that early versions of those libraries used repeated subtraction.
Anyways, the question that should've come to your mind after that is "how much slower is it?" and then run a timing test of divisions vs subtractions. For example time 1,000,000 loops of (3000-3), and then time 1,000 loops of (3,000/3). If they come out the same, then your division might be using repeated subtraction. Use 3 to avoid the edge cases of anything divided by one is itself, and anything divided by 2 can be bit-shifted.
There are better ways to test, but since Pascal is normally a beginning teaching language this would be a nice simple one that beginning students should think of and be able to do. If the division came out faster, you would have a reason to believe that it wasn't done through repeated subtraction on that CPU and version of Pascal (and libraries). You could then investigate how it was done (there's some fancy tricks depending on the CPU).
This reminds me of a time when a student who was taking Pascal didn't know his computer architecture, sad but true.:)
The old yellow low pressure sodium lamps have at least twice the efficiency of LEDs.
Indeed.
Low-pressure (yellow) sodium lamps are about 200 lm/W High-pressure (white) sodium lamps are about 100 lm/W LEDs are about 115 lm/W
Replacing high-pressure sodium lamps with LEDs would be a 15% upgrade. Many cities have high-pressure sodium lamps because the yellow ones are fugly.
Sources:
http://en.wikipedia.org/wiki/Sodium_vapor_lamp LPS lamps are the most efficient electrically-powered light source when measured for photopic lighting conditions--up to 200 lm/W,[1] High pressure sodium lamps are quite efficient--about 100 lm/W--when measured for photopic lighting conditions.
http://en.wikipedia.org/wiki/Light-emitting_diode It should be noted that high-power ( 1 W) LEDs are necessary for practical general lighting applications. Typical operating currents for these devices begin at 350 mA. The highest efficiency high-power white LED is claimed[21] by Philips Lumileds Lighting Co. with a luminous efficiency of 115 lm/W (350 mA).
You've been in the basement too long. Outdoors, there's this thing called wind. Sorta like a fan, but caused by a natural themal gradient and it blows a lot stronger.
Awesome job, Sarcastro.
First, *street* lights are the white-ish lights that light up the street. *Traffic* lights are the green/yellow/red things that tell cars to move. Sounds like the guy I responded to was talking about traffic lights and incorrectly used "street light".
Anyways - most street lights are candy-cane shaped (an upside down "U" with one leg longer than the other). The light is on the bottom of the device. There is no way for snow to block operation of the device, unless snow builds up 20 feet to reach the bottom of the device.
Anyhow, I've noticed the snow-cover problem with the newer traffic lights here in the midwest as well. Not sure if it's a matter of oversight in design, or perhaps public works buying the cheaper model light meant for south of the Mason-Dixon line, where snow doesn't happen. (Hopefully if it's the first problem somebody clever will put a nichrome wire and thermostat as an option in future lighting fixtures, for where winter actually gets snow.)
On *traffic* lights, snow can build up on the curved hoods that shield the lights from sunlight, sure. The solution I've seen is to remove the hoods; the lights are bright enough even in daylight, so the hoods are not really required.
Phasing them out as they burn out anyway and have to be replaced, though, is a good idea.
Is it?
Cost of running existing bulbs for the next 5 years: $10 million vs. Cost of replacing with LEDs: $2 million Cost of running LEDs for the next 5 years: $2 million
Numbers are pulled out of thin air, but I wanted to illustrate a point - it sometimes pays to replace something that is working.
Presumably whomever is in charge of the replacement has done this math, and found it comes out ahead to go ahead and switch before the old bulbs burn out.
There's also the issue that there's usually more than replacing a bulb, which requires more downtime. If it takes 5 days to convert, they can schedule a traffic policeman, have everything ready, and do the conversion when it's convenient. The alternative is to start that 5 day clock as soon as the bulb blows, which may take 7 or 10 days now because the resources aren't ready. In the meantime, there's no traffic light.
There's also the issue of the technicians maintaining both types of lights.
So - the economics and logistics probably both favor early replacement, rather than as the old bulbs blow.
I know the reply is late, but uhm, for almost all of your questions, YES it is the operating systems responsibility.
If every operating system has to implement these things.. uh.. we might be waiting a while. Old operating systems stay around for a long, long time - Microsoft just this year stopped selling Windows 3.1. OS/2 still exists in some places, as does DOS and SCO. XP and Windows Server 2000/2003 will be around a while too. While some operating systems now include some virtualization features, it will probably continue to be useful for some time to virtualize operating systems that don't include their own virtualization.
If you're already running a virtualization layer for some OSes, why not have the layer generic and separate for all OSes? Is there any advantage to having the OS try to virtualize itself? Why should it be the operating system's job to provide these capabilities? (My answer: it shouldn't be the operating system's job; it should be another layer)
Just because you haven't seen an operating system that actually works for shit doesn't mean its not there.
I'm pretty sure we're discussing responsibilities, not capabilities - but I'd love to hear about more OSes that provide these capabilities in-built. We previously mentioned OS/360, Solaris Zones, and userland Linux, which provide some of these capabilities (mainframe OSes more than the others, DLPARs are awesome, but not the end-all-be-all).
And stop listening to all the advertising VMware is selling, when your VM server catches fire and suddenly stops, its not going to mysteriously appear on another VM server without stopping. The machine has to be moved to a new VM server. That move has to be triggered while the original server is alive and well or the contents of ram will be lost meaning you have to boot on the new VM server. Second, while the move is in progress the VM has to be paused so the memory contents are consistent, while this is normally a quick process compared to booting, its not instant and you will most certainly notice the pause on anything with a usable amount of ram.
Learn a little bit about what ACTUALLY happens before you start talking about what marketing tells you happens, it doesn't actually work as flawlessly as you think it does, sorry.
Good point; one of the capabilities I mentioned is not available today from VMWare, and it helps to know current capabilities. Right now you have to move the VM before you set the server on fire. In the future (2009?) you can set the server on fire without previously moving the VM:
# It then uses vLockstep technology to keep the primary and secondary virtual machines in exactly the same state on another server. # In the event of hardware failure on the primary virtual machine, the secondary takes over with no disruption to users
I believe certain mainframes have something similar already (though for the life of me I can't remember the name, and Google is failing me.. something about a 10 kilometer limit for fiber interconnect for it to work) - basically two machines execute the same code in tandem, but the result (and I/O) is only used from one. Everything from memory to I/O state to CPU registers is sync'd to within a second.
Anyways, I don't think the current availability of this capability affects whether or not it (or the other capabilities) are the role of the OS or a separate VM layer, which what we were discussing. I'm still of the mind that these capabilities are best served by a separate VM layer under the OS, if for no other reason than organizations need to support multiple operating systems.
Simple: a smalltalk-esque userspace image that hops between kernels.
Take a good look at that and tell me what you see.
Bold print?:)
BTW, i was implying that the kernel should be able to swap the in-RAM userland image in situ without making a hassle, I mean there is no good reason not to.
Ah, you want the kernel to remain hardware dependent but the entire userland to move around. Every API that userland can touch would have to be image-aware, in addition to the kernels on the machines sharing state (whether one-time for moving or continuously for fault tolerance). But yeah, that'd be interesting - for that one OS.
Instead of crufting it up with things that are hardware independent and pointless to be there, like the file system, lets put something useful in there, for a change.
I don't understand what you're trying to say here. Crufting what up? The kernel? Where should the filesystem modules live?
Damn it, replying to myself... Whatever. Um, did you say Java bytecode? You do realize that the concept of a easy to handle image of an application and its state are specific to the smalltalk VM environment?
For different definitions of "easy", sure. You can serialize out Java apps with their state, but you have to write the serialization wrapper yourself instead of being built into the environment.
Sounds like you shouldn't be using roaming profiles.
You need to teach your users to make proper use of networked storage, including local copies and synchronisation if work is done off-site. Copying all of the users' profile over the network every time they log on must cripple your network in the morning.
Yep. But companies still do it the wrong way - often because "it works, why change it?". While this is hard to hear from someone who knows it can be done better, from a business perspective the risk of downtime from any changes is often greater than the possible reward of saving a few minutes of booting.
Simple: a smalltalk-esque userspace image that hops between kernels.
That's.. exactly what VMs are. Except instead of rewriting everything to Smalltalk or Java bytecode, it's left as x86 code. You can't exactly pause a Smalltalk image during the middle of a network operation, move it to a new kernel, and have it resume as if nothing happened (and within a half second).
All this VM stuff is becoming truely silly. Its really the OSes job to do all this crap, but since all the OS people can't get together in a sane manner, we have people making hardware virtualization to accomplish what the OS should be doing already.
Is it the operating system's job to migrate to a new physical machine if the one its running on catches on fire? Without stopping? Is it the operating system's job to consolidate multiple discrete machines with different purposes, users, and security on to the same physical hardware while keeping them separated logically? Is it the operating system's job to reliably checkpoint and playback operation of all apps and the operating system itself? Is it the operating system's job to correctly run old applications in a supported old version of the OS? For example, a legacy CP/M or OS/2 app that controls custom machinery.
OS/360, Solaris Zones, and user-mode Linux do some of these; however it does make sense to have a VM layer underneath the OS, especially when you have needs for multiple OSes.
Why have every OS implement these things when you can just have a VM layer doing it, and provide an additional layer of control and security beyond what the OS provides?
Voicemail is just a gimmick to get you to use more minutes than you really should, at no expense to the carrier since they don't actually have to connect the call to anyone. It's 100% profit.
Most carriers have free calls to voicemail and customer service.
I heard this product mentioned elsewhere. It's inexpensive enough that I'm thinking of buying one and asking a cashier to keep it under their counter at a local electronics store I frequent.
If you're not a complete butterfingers, you can do the same thing with a box cutter which is $0.89. Bonus: you can detach the razor blade and use it to clean off old stickers on your car windshield.
One of the most significant modifications in the general addressing model in IPv6 was a change to the basic types of addresses and how they were used. Unicast addresses are still the choice for the vast majority of communications as in IPv4, but the "bulk" addressing methods are different in IPv6. Broadcast as a specific addressing type has been eliminated. Instead, support for multicast addressing has been expanded and made a required part of the protocol, and a new type of addressing called anycast has been implemented.
Ok, having multicast a required part of the protocol means people would actually be able to use it. Right now multicast over the internet often gets filtered/ignored. Multicast makes a compelling case for content distributors - send out one copy of your stream and routers along the way will duplicate it as necessary.
All this really does is save you from having the buy more bandwidth/servers. I don't see how this enables new classes of applications; I can't think of many non-media applications that would benefit from multicast. That may just be my poor imagination. I have seen systems that use UDP multicast to deliver realtime stock quotes for traders, but that was run over a private IPv4 network.
As a workaround, content distribution networks could easily replicate streaming protocols for you without multicast; they already do it for HTTP. You set up one copy of your stream to Akamai, and they replicate it as necessary as clients connect to them. They already have distribution points scattered across the globe, close to the endpoint users.
No need to change the whole world over to IPv6; just shell out a few bucks. So if by "difficult" you mean "expensive" - yes. Difficult as in requiring new technology - not really.
You run the two protocols simultaneously for years, add AAAA records to DNS which get looked up and tried before A records, and when you notice that no-one is connecting to your services over v4 any more, you have a v6 only network.
Yep, that seems to be the plan. Only.. if I have to run IPv4 anyways, and everything I have works on IPv4, why in the world would I bother running IPv6? There aren't any IPv6-only services, and won't be for some years (if ever). There definitely aren't any IPv6-only clients.
There are "nice" reasons to switch to IPv6, but at the moment there aren't really any practical/financial reasons to switch before everyone else does, at which point it becomes a requirement. There's no point in being the only person with a telephone, you need everyone else to have one too.
It's quite depressing really how people (mainly American, it seems) on Slashdot are so anti IPv6. They bleat on about NAT, and how there are loads of addresses, and why on earth would you want your fridge with an IP address.
I'll point out the the US federal government is one of the largest proponents of IPv6, and is putting into place IPv6 requirements for doing business with the government - which will probably be the tipping point for most major corporations to switch to IPv6. But don't let that stop your jingoism.
It's not just to do with the extra addresses. There. Did you get that?
Ok, I'll bite. What is it about, then?
Autoconfiguration? Already have DHCP and the 169.x.x.x magic range. You still need a DHCPv6 server (or router autoconfig which is DHCP in all but name) for DNS anyways. Directly contacting machines behind NAT? Most people don't care, and most applications have figured a way around it (external mediation server, or STUN). Security? IPSEC is optional in IPv6, same as IPv4. Making money for Cisco as they sell new routers? Ok, IPv6 wins that one.:)
What is the great compelling argument beyond "oh noes, we have no IPs left"?
The fingerprint reader is intended to make logging in a simple step of swiping your finger across the sensor. It's not designed to grab a thief's fingerprint.
You missed the point. He means that the thief can easily swipe the fingerprint of the legitimate user from the keyboard, then use it on the fingerprint scanner.
In fact, you don't even have to steal the laptop. Just press a gummi bear on a key on the keyboard, then swipe that. The machine is now open. Send goat porn to the CEO from the victim, then relock the machine.
"It had to be you, it was locked with a fingerprint scanner!"
Slashdot Mirror
Since the link was messed up, here it is: http://www.minneapolisfed.org/
Median income in the US in 2007 was $50,233.00. So, half of that is $25,116.50.
$25,116.50 of 1982 goods would cost $53,954.93 in 2007 according to the calculator.
You wouldn't need double the amount of money your parents made due to inflation to have the same standard of living your frugal parents had. You'd need 2.15 times!
A chicken's quest? Probably meant "fool", but it's funnier this way. :)
Anyways the "paperless is green" idea isn't because we're going to run out of wood. Almost all paper is made from trees that are grown (and replanted and regrown) for that purpose. However turning that wood into paper and shipping it to the utility uses energy and money. Putting ink on the paper likewise isn't free, and mailing it (in postal trucks that burn gas) isn't free either.
Whether you measure in total energy spent or dollars, it's cheaper to have online bills than mailing out paper statements. Most places let you download a PDF of what the paper statement would have been, giving you the efficiencies of online bills while still being able to have a copy of old bills (and print them on demand).
Utilities push online billing because it saves them money; the fact that it also saves energy in the process and is more convenient for consumers is a win/win/win.
Mining in general is dangerous and sometimes toxic to the surrounding areas.
http://www.nytimes.com/2008/12/30/us/30sludge.html?em
You're right, using nuclear instead of coal doesn't change the fact that mining is dangerous. But it does remove the "definitely release tons of toxic and radioactive waste into the air" issue and replace it with a "if everything went horribly wrong, radioactive materials might escape".
That was the original objective for the Shuttle - a reusable vehicle that could be turned around quickly.
The point your teacher was probably trying to make is that not all instructions cost the same CPU time, even if they use the same number of instructions to issue. Depending on when your teacher learned computers, what architecture the class had in mind, and how old his textbook was, his statement might have been true for the cases he was thinking of.
Some early processors (such as original PDP-11) did not have a DIV instruction at first, so Pascal (and other languages) would have had to emulate it. Some embedded processors also do not have a divide instruction. Dividing isn't universal in processor instruction sets. The simplest (although not usually the most efficient) way to emulate a divide is with repeated subtraction. It's also possible for processors that support a divide instruction to internally subtract in a loop. Pascal (and other languages) also had floating point libraries that couldn't rely on the floating point unit being there; it's entirely possible that early versions of those libraries used repeated subtraction.
Anyways, the question that should've come to your mind after that is "how much slower is it?" and then run a timing test of divisions vs subtractions. For example time 1,000,000 loops of (3000-3), and then time 1,000 loops of (3,000/3). If they come out the same, then your division might be using repeated subtraction. Use 3 to avoid the edge cases of anything divided by one is itself, and anything divided by 2 can be bit-shifted.
There are better ways to test, but since Pascal is normally a beginning teaching language this would be a nice simple one that beginning students should think of and be able to do. If the division came out faster, you would have a reason to believe that it wasn't done through repeated subtraction on that CPU and version of Pascal (and libraries). You could then investigate how it was done (there's some fancy tricks depending on the CPU).
This reminds me of a time when a student who was taking Pascal didn't know his computer architecture, sad but true. :)
I was trying to explain why they might be moving from HPS -> LED, which is an efficiency upgrade, vs LPS -> LED which is a downgrade.
Indeed.
Low-pressure (yellow) sodium lamps are about 200 lm/W
High-pressure (white) sodium lamps are about 100 lm/W
LEDs are about 115 lm/W
Replacing high-pressure sodium lamps with LEDs would be a 15% upgrade. Many cities have high-pressure sodium lamps because the yellow ones are fugly.
Sources:
http://en.wikipedia.org/wiki/Sodium_vapor_lamp
LPS lamps are the most efficient electrically-powered light source when measured for photopic lighting conditions--up to 200 lm/W,[1]
High pressure sodium lamps are quite efficient--about 100 lm/W--when measured for photopic lighting conditions.
http://en.wikipedia.org/wiki/Light-emitting_diode
It should be noted that high-power ( 1 W) LEDs are necessary for practical general lighting applications. Typical operating currents for these devices begin at 350 mA. The highest efficiency high-power white LED is claimed[21] by Philips Lumileds Lighting Co. with a luminous efficiency of 115 lm/W (350 mA).
Awesome job, Sarcastro.
First, *street* lights are the white-ish lights that light up the street. *Traffic* lights are the green/yellow/red things that tell cars to move. Sounds like the guy I responded to was talking about traffic lights and incorrectly used "street light".
Anyways - most street lights are candy-cane shaped (an upside down "U" with one leg longer than the other). The light is on the bottom of the device. There is no way for snow to block operation of the device, unless snow builds up 20 feet to reach the bottom of the device.
On *traffic* lights, snow can build up on the curved hoods that shield the lights from sunlight, sure. The solution I've seen is to remove the hoods; the lights are bright enough even in daylight, so the hoods are not really required.
Is it?
Cost of running existing bulbs for the next 5 years: $10 million
vs.
Cost of replacing with LEDs: $2 million
Cost of running LEDs for the next 5 years: $2 million
Numbers are pulled out of thin air, but I wanted to illustrate a point - it sometimes pays to replace something that is working.
Presumably whomever is in charge of the replacement has done this math, and found it comes out ahead to go ahead and switch before the old bulbs burn out.
There's also the issue that there's usually more than replacing a bulb, which requires more downtime. If it takes 5 days to convert, they can schedule a traffic policeman, have everything ready, and do the conversion when it's convenient. The alternative is to start that 5 day clock as soon as the bulb blows, which may take 7 or 10 days now because the resources aren't ready. In the meantime, there's no traffic light.
There's also the issue of the technicians maintaining both types of lights.
So - the economics and logistics probably both favor early replacement, rather than as the old bulbs blow.
How does snow get on to the bottom of the street lamp? What exactly *are* you guys smoking out there?
Like, aluminum screws?
If every operating system has to implement these things.. uh.. we might be waiting a while. Old operating systems stay around for a long, long time - Microsoft just this year stopped selling Windows 3.1. OS/2 still exists in some places, as does DOS and SCO. XP and Windows Server 2000/2003 will be around a while too. While some operating systems now include some virtualization features, it will probably continue to be useful for some time to virtualize operating systems that don't include their own virtualization.
If you're already running a virtualization layer for some OSes, why not have the layer generic and separate for all OSes? Is there any advantage to having the OS try to virtualize itself? Why should it be the operating system's job to provide these capabilities? (My answer: it shouldn't be the operating system's job; it should be another layer)
I'm pretty sure we're discussing responsibilities, not capabilities - but I'd love to hear about more OSes that provide these capabilities in-built. We previously mentioned OS/360, Solaris Zones, and userland Linux, which provide some of these capabilities (mainframe OSes more than the others, DLPARs are awesome, but not the end-all-be-all).
Good point; one of the capabilities I mentioned is not available today from VMWare, and it helps to know current capabilities. Right now you have to move the VM before you set the server on fire. In the future (2009?) you can set the server on fire without previously moving the VM:
http://www.vmware.com/technology/virtual-datacenter-os/application.html
# It then uses vLockstep technology to keep the primary and secondary virtual machines in exactly the same state on another server.
# In the event of hardware failure on the primary virtual machine, the secondary takes over with no disruption to users
I believe certain mainframes have something similar already (though for the life of me I can't remember the name, and Google is failing me.. something about a 10 kilometer limit for fiber interconnect for it to work) - basically two machines execute the same code in tandem, but the result (and I/O) is only used from one. Everything from memory to I/O state to CPU registers is sync'd to within a second.
Anyways, I don't think the current availability of this capability affects whether or not it (or the other capabilities) are the role of the OS or a separate VM layer, which what we were discussing. I'm still of the mind that these capabilities are best served by a separate VM layer under the OS, if for no other reason than organizations need to support multiple operating systems.
Bold print? :)
Ah, you want the kernel to remain hardware dependent but the entire userland to move around. Every API that userland can touch would have to be image-aware, in addition to the kernels on the machines sharing state (whether one-time for moving or continuously for fault tolerance). But yeah, that'd be interesting - for that one OS.
I don't understand what you're trying to say here. Crufting what up? The kernel? Where should the filesystem modules live?
For different definitions of "easy", sure. You can serialize out Java apps with their state, but you have to write the serialization wrapper yourself instead of being built into the environment.
http://java.sun.com/developer/technicalArticles/Programming/serialization/
No need for Wake on LAN. Most BIOSes can boot at a predetermined time every day.
Yep. But companies still do it the wrong way - often because "it works, why change it?". While this is hard to hear from someone who knows it can be done better, from a business perspective the risk of downtime from any changes is often greater than the possible reward of saving a few minutes of booting.
That's.. exactly what VMs are. Except instead of rewriting everything to Smalltalk or Java bytecode, it's left as x86 code.
You can't exactly pause a Smalltalk image during the middle of a network operation, move it to a new kernel, and have it resume as if nothing happened (and within a half second).
Is it the operating system's job to migrate to a new physical machine if the one its running on catches on fire? Without stopping?
Is it the operating system's job to consolidate multiple discrete machines with different purposes, users, and security on to the same physical hardware while keeping them separated logically?
Is it the operating system's job to reliably checkpoint and playback operation of all apps and the operating system itself?
Is it the operating system's job to correctly run old applications in a supported old version of the OS? For example, a legacy CP/M or OS/2 app that controls custom machinery.
OS/360, Solaris Zones, and user-mode Linux do some of these; however it does make sense to have a VM layer underneath the OS, especially when you have needs for multiple OSes.
Why have every OS implement these things when you can just have a VM layer doing it, and provide an additional layer of control and security beyond what the OS provides?
Most carriers have free calls to voicemail and customer service.
I am completely and utterly shocked that someone who chose "PC and Sony Fanboy" as their nickname is both defending the PS3 and disparaging Macs. :)
If you're not a complete butterfingers, you can do the same thing with a box cutter which is $0.89. Bonus: you can detach the razor blade and use it to clean off old stickers on your car windshield.
I would love to be able to deposit checks electronically, as I am often on the road. What bank/service offers this for personal accounts?
Interesting. I wasn't aware that IPv6 changed anything with respect to multicasting. I Googled it and came up with this:
http://www.tcpipguide.com/free/t_IPv6MulticastandAnycastAddressing.htm
Ok, having multicast a required part of the protocol means people would actually be able to use it. Right now multicast over the internet often gets filtered/ignored. Multicast makes a compelling case for content distributors - send out one copy of your stream and routers along the way will duplicate it as necessary.
All this really does is save you from having the buy more bandwidth/servers. I don't see how this enables new classes of applications; I can't think of many non-media applications that would benefit from multicast. That may just be my poor imagination. I have seen systems that use UDP multicast to deliver realtime stock quotes for traders, but that was run over a private IPv4 network.
As a workaround, content distribution networks could easily replicate streaming protocols for you without multicast; they already do it for HTTP. You set up one copy of your stream to Akamai, and they replicate it as necessary as clients connect to them. They already have distribution points scattered across the globe, close to the endpoint users.
Oh wait, they already do that. http://www.akamai.com/html/technology/products/streaming.html
No need to change the whole world over to IPv6; just shell out a few bucks. So if by "difficult" you mean "expensive" - yes. Difficult as in requiring new technology - not really.
Yep, that seems to be the plan. Only.. if I have to run IPv4 anyways, and everything I have works on IPv4, why in the world would I bother running IPv6? There aren't any IPv6-only services, and won't be for some years (if ever). There definitely aren't any IPv6-only clients.
There are "nice" reasons to switch to IPv6, but at the moment there aren't really any practical/financial reasons to switch before everyone else does, at which point it becomes a requirement. There's no point in being the only person with a telephone, you need everyone else to have one too.
I'll point out the the US federal government is one of the largest proponents of IPv6, and is putting into place IPv6 requirements for doing business with the government - which will probably be the tipping point for most major corporations to switch to IPv6. But don't let that stop your jingoism.
Ok, I'll bite. What is it about, then?
Autoconfiguration? Already have DHCP and the 169.x.x.x magic range. You still need a DHCPv6 server (or router autoconfig which is DHCP in all but name) for DNS anyways. :)
Directly contacting machines behind NAT? Most people don't care, and most applications have figured a way around it (external mediation server, or STUN).
Security? IPSEC is optional in IPv6, same as IPv4.
Making money for Cisco as they sell new routers? Ok, IPv6 wins that one.
What is the great compelling argument beyond "oh noes, we have no IPs left"?
You missed the point. He means that the thief can easily swipe the fingerprint of the legitimate user from the keyboard, then use it on the fingerprint scanner.
In fact, you don't even have to steal the laptop. Just press a gummi bear on a key on the keyboard, then swipe that. The machine is now open. Send goat porn to the CEO from the victim, then relock the machine.
"It had to be you, it was locked with a fingerprint scanner!"