We sold our old mountain cabin above Rjukan, Telemark (in Norway) this winter to buy a new one a few kms away:
The local power company, Rauland Kraft, by default installs a PVC tube alongside the 400 V electrical cables to each new hoouse or cabin, and they pull fiber to the local junction box. The only thing needed for a "Triple Play" (IP + IPTV + Phone) connection was a 15-minute visit to blow a fiber through that PVC tube.
Oil companies which do a lot of Pre-Stack processing, i.e. raw seismic data, need an awful lot of disk storage: We're currently in the ~50 TB (geographically mirrored RAID5 servers) range, and this is with Post-Stack only.
Going to Pre-Stack will generate 10 to 100 times as much data, which means that 500 TB to multi-PB is where we'll be in a couple of years. Having 750 GB SATA drives in a Nexsan SATABeast http://nexsan.com/products/products/satabeast/sata beast.html enclosure results in about 27-28 TB of usable disk space in a single 4U rack unit.
If you follow the link given above, you'll notice that this phone is based on the NSK 200, where NSK stands for 'Norsk Sterk Krypto', i.e. 'Norwegian Strong Crypto'.
The main problem with this phone is the price, when I looked at it last year we also found that is 900/1800 only, i.e. it won't work on 1900 MHz US networks. The cheapest solution I found is the sw only http://securegsm.com/ which can run on top of several Qtek Windows Mobile cell phones.
Terje
PS. Even though Sweden (Ericsson) and Finland (Nokia) have both made a lot of money from the GSM system, it was actually invented/developed in Norway.
First, my credentials: I've been working with NTP for more than 10 years, my personal web server, which you can find via http://www.ntp.org/ (I won't link directly to try to avoid the/. effect.) have hosted windows binaries of the official NTP distribution for some years now.
Since the original article didn't mention this, I would like to warn NTP users against ever configuring two servers! The reason is that NTP by design requires a plurality of all sources to agree on what the time is, before it will believe any of them.
This means that if you have two sources that disagree slightly, you can relatively easily get into a situation where your local machine decides to distrust both and simply start drifting away. I have actually seen this happen multiple times.
This means that you need to configure either a single or at least three servers, and if you want fault tolerance you actually need four, since that will leave three even when one of them fails.
PHK have (of course!) considered moving his box to a new DNS name, the problem lies in the way it is used:
By moving it, he'll require every single BGP router in Denmark to be reconfigured, if you read his Open Letter you'll notice that he has considered and rejected this option as unworkable.
Terje (Who's been hosting windows ntp binaries for several years now, at http://norloff.org/ntp/)
This system uses absolutely no board/controller lever redundancy, instead they use a separate file system on every disk, then mirror pairs of 1U units, and finally mirror the entire (mirrored) rack to a geographically distant location.
I am currently testing a much denser solution, the SATABeast http://nexsan.com/products/products/satabeast/sata beast.html from nexsan http://nexsan.com/ which manages to pack 42 500 GB SATA drives into a single 4U rackmount box. With multiple RAID5 volumes and shared hot spare drives, this results in about 17-18 TB of usable file system space.
According to the nexsan engineer I spoke with today, they do so much burn-in testing of the Hitachi Deskstar drives they ship, that over the 15-18 month period they've used these drives, the total error rate has been just 0.4%.
Even if these numbers are somewhat skewed due to many systems (i.e. drives) being relatively recently installed, it is still very impressive.
For our setup we plan to use multiple full boxes, each connected to a separate NFS server. Each server has multiple FC host adapters, so if a server crashes, the corresponding box can be connected to one of the other servers.
We will also use rsync to mirror all data across the country to a secondary site.
I used Watcom's compilers for a number of years, mostly to develop code for NetWare, but also for Dos/Windows.
Among the things I really liked was the beautiful integration between C(++) and inline asm code, where you could do stuff like defining an inline asm macro, while telling the compiler exactly which registers/memory areas would be used and/or modified. This meant that the C optimizer could work perfectly well across such asm code.
I am currently piloting a setup intended to replace 35 TB of disk+tape used for sesmological data:
Each array will consist of a pair of full (42-disk) nexsan SATABeast 4U boxes. These use RAID5 + hot spares and connect to the host systems with FC.
The two pairs will be mirrored (over a fiber connection) between two geographically separated locations.
The payback time for this setup is so short that we can plan on replacing half the gear every year, using a staggered schedule. (Replace A after year 1, B after two years, then A/B/A/B etc.)
For a stock/stock options program to work properly, it really needs to last for several years, or at least long enough to not tempt executives into doing stuff which hurts the long-term viability of the company, in order to increase the short-term value of a set of stock options.
I.e. the stock options you get this year cannot be sold/converted until X years later.
Prof. Nicely found it of course, but he didn't announce it in any public forum.
I got a tip from an EEtimes journalist who had heard a rumour about it, then wrote a small asm program to test it out.
After verifying that the bug was real, on both the initial 60/66 MHz stepping and the brand new 90/100 MHz model, I wrote the post in news:comp.sys.intel
All of this is documented in Cleve Moler's "Pentium Papers".
I read the first article about the theoretical possibility of a PC virus in either 1984 or '85, at this time most people scoffed at it, simply refusing to believe it was possible.
Anyway, having written quite a bit of asm code, I had no problems accepting the possibility, so for fun I decided to write a sort of vaccine:
Simply a small program that took a digitial signature of every executable piece of code (boot blocks,.com/.exe etc) and saved this to a text file on a bootable floppy, which was then marked read-only.
Afterwards I could simply put in this floppy and reboot, whereupon the same program would compare the current signatures with those saved on the floppy.
The problem was to keep the original list updated each time I wrote a new program.:-(
More than 11 years ago (nov '94) I happened to be the one to make the first public announcement of the Pentium FDIV bug, and over the next few weeks/months I also wrote most of the sw workaround (together with Cleve Moler, Tim Coe & Peter Tang).
At the time I believed Intel would replace the Pentium name in time for the P6 (Hexium anyone?), but instead they started the long-running series of Pentium* processor families.
I live in Norway, but have worked in the US previously.
The standard 2-week notice never ceases to amaze me, here in Norway the standard is "3 months, starting at the end of the current month."
Yes, a very few companies will still pay you to quit immediately, but you cannot depend upon this, which means that both employee and employer needs to consider their actions more carefully: You, as the employee, cannot walk away immediately, even if you have many weeks of acrued leave/vacation time, and your boss cannot fire you immediately without having to explain how a 3-4 month severance payment ended up on his balance sheet.
Yes, sometimes this sucks, but mostly I believe it to be a very good idea.
Autostitch/autopano/autopano-sift, along with Panorama Tools, PTAssembler, PTGui or Hugin (open source!) makes it possible to take a bunch of images, and automatically detect which sets of images can be merged into panoramas/photo-mosaics.
Using any of them on a set of partial scans can be used to regenerate the original page.
I just downloadded all of the Cell pdf's to take a look at them. I posted the following analysis to news:comp.arch:
Naturally, I started reading the SPU asm manual, and that makes it immediately obvious that this is a cpu directly targeted at MPEG style video processing:
absdb Absolute difference of bytes
avgb Average bytes: dest = (a+b+1) >> 1 (MPEG interpolation)
ct Carry Generate: Target = carry out of (A+B)
addx Add word extended: Target = A+B+(Target & 1)
Notice the last one! It uses the least significant bit of each part of the target register as input to an AddWithCarry operation, which means that you need three read ports.
This pair of opcodes seems to me to be meant as building blocks for extended/arbitrary precision calculations.
It has a full set of branch instructions that as a side-effect either enable or disable interrupts, i.e. critical sections are supposed to be handled this way.
It seems to handle sub-register size operations with a set of opcodes, where one of a group of GenerateMask operations is used to generate an input mask for a general shuffle operation.... There's a bunch of generalized three-input FMAC opcodes, all working on SIMD data, like fnms (T = Acc - (a * b).
It has fsqest and frest to generate approximate reciprocal square root and reciprocal lookup values. However, these operations does not seem to deliver results in a standard format, instead each resulting element consists of two parts, a base and a step, so that a following fi (Floating Interpolate) can improve upon the table lookup results.
I'm guessing you'd then want one NR iteration to get somewhere close to IEEE single precision.
The shufb (Shuffle bytes) opcode seems like a small extension to the Altivec Permute, in that in addition to using 5 bits to select one of 32 possible input bytes, and can also specify three different immediate values (0, 0x80 and 0xFF), which would be needed to make it work with the GenerateMask operations mentioned above.
All in all a pretty general set of opcodes for SIMD data processing, it is particularly obvious in the way each of the possible operations has forms to work on either a set of input data (reg or immediate), or on it's complement. This saves a lot of bubble-introducing mask setup operations, but is normally not considered to be required on a regular cpu.
"Almost all programming can be viewed as an exercise in caching."
For the last ten years or so, this has been my.sig, and this article is just a pretty bad example:
Yes, you should probably cache some or most of this stuff, but you should also consider which of these lists might contain dynamic data:
Is it enough to reload the list at application startup, every N days/hours/minutes, or would it be possible to send a signal from the updating process to trigger a reload only when needed?
Many contributors do this already. A few times they'll just submit all the individual images, and one of the coordinators will assemble them into a panorama.
nosphalot is correct: The Turbo breakthrough was that they determined that by using feedback, just as in an engine turbo, you could get arbitrarily close to Shannons limit.
The key idea is that this feedback gives you an infinite impulse response, i.e. in theory all bits ever transmitted through such a channel will continue to affect it for ever after.
Even if you do limit the feedback time to more reasonable levels, you can still get a very useful increase in channel capacity.
It is also important to notice that such a channel must have significant delay, i.e. here's another reason to complain about being lagged.;.)
You're right: 64 bits doesn't make it faster, but otoh it doesn't really make it significantly slower or bigger either.
According to the latest discussions on news:comp.arch, the 64-bit size overhead on current cpus is around 3%, the internal bus size increase doesn't matter, and code size can be more or less the same.
It is only when you automatically extend all default-sized data items from 32 to 64 bits that you get a noticable slowdown.
It is only when you really do need more than about 2 GB of RAM that a 64-bit cpu is really useful.
However, I have no respect for any legal system that places defendants at the mercy of overzealous prosecutors driven by either corporate cartels or popular sentiment. I have no opinion on Norway's society or government in general, but I can still say their legal rules suck fat cock.
Please do some more reading: In all criminal cases in Norway, the government has to pick up the defendant's legal costs, irrespective of which lawyer he chooses to represent himself.
This means that even in an obviously lopsided case like this (really the MPAA vs Jon J), the stronger party cannot add cripling economic burdens on top of the onus of being forced to show up in court.
"A hard disk is a binary medium, it can either be new, or full."
For personal data (code I write, photos I take etc.) I've been using disk-to-disk backups for many years: I keep copies on at least three machines, in two locations (home/office/laptop). Since I always roll all the files forward when I upgrade, this means that I have never lost any significant amount of data over the last 20 years.
I don't believe you can trust an IDE RAID array to stay healthy for years if you just store it in a closet somewhere, you need to keep those disks at least somewhat active. Even so, I've been looking seriously at disk-to-disk backups for all our PC servers (500+) for some time now, and it is starting to make a lot of sense:
This is not intended as longterm storage however, instead it would allow a server to be booted off the last IDE snapshot, as soon as we can determine that the primary (SCSI) arrays are well and truly hosed. Booting from IDE and allowing all users read-only access to week-old versions of their files, while restoring the incremental backups from tape, is much better than staying offline for a week.
At the same time, we can rebuild a new SCSI array from scratch, mirror the IDE data onto it, and as soon as the last incremental backup tapes have been restored, we'll switch back to the SCSI disks, and resume normal operation.
I believe even the US will implement some form of caller pays for cell phone calls. This is because it leads to much higher usage of those phones:
Several of my friends in the US tends to keep their phones turned off, only using them for outgoing calls to give important messages. Some of them even carry beepers to receive notification that they need to call someone.
With caller pays and built-in text messaging I keep my phone on at all times, except when on a plane. (In a meeting I'll make it silent, but I can still receive messages.)
Here in Norway we've had number portability for a while now, but all cell phones still have a number starting with either 9 or 4. (Yes, it is legal to have a cell phone number that starts with 911, I had such a number a few years ago.)
All phone calls (except 800) are caller pays, and even 800 numbers still carry a call setup fee of about 5 cents. There are in fact no free calls at all, since even local calls cost about a $1 to $1.50 per hour depending upon the time of day/week.
OTOH, we got totally rid of long distance charges several years ago, so it costs exactly the same to call 2500 km from Lindesnes to North Cape as to call next door.
Calls to cell phones are relatively expensive, they cost about the same as an international call to the US (10 to 20 cents/minute). Many people have still decided to not have a landline phone at all. Those copper wires can be put to much better use with ADSL, which costs from $45/month.
Slashdot Mirror
A similar competition was recently held in Europe, contested by student teams:
r athon-en
o ads/sem_press/Nogaro%20May%202006/press_release_se m_210506.pdf
http://www.shell.com/home/Framework?siteId=eco-ma
The winning entry ran on biofuel (Ethanol) and achieved 2885 km/liter, which should correspond to about 6800 miles/gallon:
(Warning: PDF file)
http://www.shell.com/static/eco-marathon-en/downl
Terje
We sold our old mountain cabin above Rjukan, Telemark (in Norway) this winter to buy a new one a few kms away:
The local power company, Rauland Kraft, by default installs a PVC tube alongside the 400 V electrical cables to each new hoouse or cabin, and they pull fiber to the local junction box. The only thing needed for a "Triple Play" (IP + IPTV + Phone) connection was a 15-minute visit to blow a fiber through that PVC tube.
Terje
Oil companies which do a lot of Pre-Stack processing, i.e. raw seismic data, need an awful lot of disk storage: We're currently in the ~50 TB (geographically mirrored RAID5 servers) range, and this is with Post-Stack only.
a beast.html enclosure results in about 27-28 TB of usable disk space in a single 4U rack unit.
Going to Pre-Stack will generate 10 to 100 times as much data, which means that 500 TB to multi-PB is where we'll be in a couple of years. Having 750 GB SATA drives in a Nexsan SATABeast http://nexsan.com/products/products/satabeast/sat
Very nice!
Terje
If you follow the link given above, you'll notice that this phone is based on the NSK 200, where NSK stands for 'Norsk Sterk Krypto', i.e. 'Norwegian Strong Crypto'.
The main problem with this phone is the price, when I looked at it last year we also found that is 900/1800 only, i.e. it won't work on 1900 MHz US networks. The cheapest solution I found is the sw only http://securegsm.com/ which can run on top of several Qtek Windows Mobile cell phones.
Terje
PS. Even though Sweden (Ericsson) and Finland (Nokia) have both made a lot of money from the GSM system, it was actually invented/developed in Norway.
First, my credentials: I've been working with NTP for more than 10 years, my personal web server, which you can find via http://www.ntp.org/ (I won't link directly to try to avoid the /. effect.) have hosted windows binaries of the official NTP distribution for some years now.
Since the original article didn't mention this, I would like to warn NTP users against ever configuring two servers! The reason is that NTP by design requires a plurality of all sources to agree on what the time is, before it will believe any of them.
This means that if you have two sources that disagree slightly, you can relatively easily get into a situation where your local machine decides to distrust both and simply start drifting away. I have actually seen this happen multiple times.
This means that you need to configure either a single or at least three servers, and if you want fault tolerance you actually need four, since that will leave three even when one of them fails.
Terje
PHK have (of course!) considered moving his box to a new DNS name, the problem lies in the way it is used:
By moving it, he'll require every single BGP router in Denmark to be reconfigured, if you read his Open Letter you'll notice that he has considered and rejected this option as unworkable.
Terje
(Who's been hosting windows ntp binaries for several years now, at http://norloff.org/ntp/)
If you ever travel to Antarctica and think you see a polar bear, one of three things are actually happening:
1) One of your friends have put on a costume to scare you.
2) You joined the wrong expedition, the one going to the Arctic (think North Pole) instead of the one going south.
3) You're hallucinating
Take your pick what's the most likely.
Terje
The Internet Archive Project http://www.archive.org/ is running on the PetaBox http://petabox.com/ rack system, which was commercialized by Capricorn Tech http://www.capricorn-tech.com/ more than a year ago.
a beast.html from nexsan http://nexsan.com/ which manages to pack 42 500 GB SATA drives into a single 4U rackmount box. With multiple RAID5 volumes and shared hot spare drives, this results in about 17-18 TB of usable file system space.
This system uses absolutely no board/controller lever redundancy, instead they use a separate file system on every disk, then mirror pairs of 1U units, and finally mirror the entire (mirrored) rack to a geographically distant location.
I am currently testing a much denser solution, the SATABeast http://nexsan.com/products/products/satabeast/sat
According to the nexsan engineer I spoke with today, they do so much burn-in testing of the Hitachi Deskstar drives they ship, that over the 15-18 month period they've used these drives, the total error rate has been just 0.4%.
Even if these numbers are somewhat skewed due to many systems (i.e. drives) being relatively recently installed, it is still very impressive.
For our setup we plan to use multiple full boxes, each connected to a separate NFS server. Each server has multiple FC host adapters, so if a server crashes, the corresponding box can be connected to one of the other servers.
We will also use rsync to mirror all data across the country to a secondary site.
Terje
I used Watcom's compilers for a number of years, mostly to develop code for NetWare, but also for Dos/Windows.
Among the things I really liked was the beautiful integration between C(++) and inline asm code, where you could do stuff like defining an inline asm macro, while telling the compiler exactly which registers/memory areas would be used and/or modified. This meant that the C optimizer could work perfectly well across such asm code.
Terje
I am currently piloting a setup intended to replace 35 TB of disk+tape used for sesmological data:
Each array will consist of a pair of full (42-disk) nexsan SATABeast 4U boxes. These use RAID5 + hot spares and connect to the host systems with FC.
The two pairs will be mirrored (over a fiber connection) between two geographically separated locations.
The payback time for this setup is so short that we can plan on replacing half the gear every year, using a staggered schedule. (Replace A after year 1, B after two years, then A/B/A/B etc.)
Terje
For a stock/stock options program to work properly, it really needs to last for several years, or at least long enough to not tempt executives into doing stuff which hurts the long-term viability of the company, in order to increase the short-term value of a set of stock options.
I.e. the stock options you get this year cannot be sold/converted until X years later.
Terje
Prof. Nicely found it of course, but he didn't announce it in any public forum.
I got a tip from an EEtimes journalist who had heard a rumour about it, then wrote a small asm program to test it out.
After verifying that the bug was real, on both the initial 60/66 MHz stepping and the brand new 90/100 MHz model, I wrote the post in news:comp.sys.intel
All of this is documented in Cleve Moler's "Pentium Papers".
Terje
I read the first article about the theoretical possibility of a PC virus in either 1984 or '85, at this time most people scoffed at it, simply refusing to believe it was possible.
.com/.exe etc) and saved this to a text file on a bootable floppy, which was then marked read-only.
:-(
Anyway, having written quite a bit of asm code, I had no problems accepting the possibility, so for fun I decided to write a sort of vaccine:
Simply a small program that took a digitial signature of every executable piece of code (boot blocks,
Afterwards I could simply put in this floppy and reboot, whereupon the same program would compare the current signatures with those saved on the floppy.
The problem was to keep the original list updated each time I wrote a new program.
Terje
More than 11 years ago (nov '94) I happened to be the one to make the first public announcement of the Pentium FDIV bug, and over the next few weeks/months I also wrote most of the sw workaround (together with Cleve Moler, Tim Coe & Peter Tang).
At the time I believed Intel would replace the Pentium name in time for the P6 (Hexium anyone?), but instead they started the long-running series of Pentium* processor families.
Terje
I live in Norway, but have worked in the US previously.
The standard 2-week notice never ceases to amaze me, here in Norway the standard is "3 months, starting at the end of the current month."
Yes, a very few companies will still pay you to quit immediately, but you cannot depend upon this, which means that both employee and employer needs to consider their actions more carefully: You, as the employee, cannot walk away immediately, even if you have many weeks of acrued leave/vacation time, and your boss cannot fire you immediately without having to explain how a 3-4 month severance payment ended up on his balance sheet.
Yes, sometimes this sucks, but mostly I believe it to be a very good idea.
Terje
Autostitch/autopano/autopano-sift, along with Panorama Tools, PTAssembler, PTGui or Hugin (open source!) makes it possible to take a bunch of images, and automatically detect which sets of images can be merged into panoramas/photo-mosaics.
Using any of them on a set of partial scans can be used to regenerate the original page.
Terje
I just downloadded all of the Cell pdf's to take a look at them. I posted the following analysis to news:comp.arch:
...
Naturally, I started reading the SPU asm manual, and that makes it
immediately obvious that this is a cpu directly targeted at MPEG style
video processing:
absdb Absolute difference of bytes
avgb Average bytes: dest = (a+b+1) >> 1 (MPEG interpolation)
ct Carry Generate: Target = carry out of (A+B)
addx Add word extended: Target = A+B+(Target & 1)
Notice the last one! It uses the least significant bit of each part of
the target register as input to an AddWithCarry operation, which means
that you need three read ports.
This pair of opcodes seems to me to be meant as building blocks for
extended/arbitrary precision calculations.
It has a full set of branch instructions that as a side-effect either
enable or disable interrupts, i.e. critical sections are supposed to be
handled this way.
It seems to handle sub-register size operations with a set of opcodes,
where one of a group of GenerateMask operations is used to generate an
input mask for a general shuffle operation.
There's a bunch of generalized three-input FMAC opcodes, all working on
SIMD data, like fnms (T = Acc - (a * b).
It has fsqest and frest to generate approximate reciprocal square root
and reciprocal lookup values. However, these operations does not seem to
deliver results in a standard format, instead each resulting element
consists of two parts, a base and a step, so that a following fi
(Floating Interpolate) can improve upon the table lookup results.
I'm guessing you'd then want one NR iteration to get somewhere close to
IEEE single precision.
The shufb (Shuffle bytes) opcode seems like a small extension to the
Altivec Permute, in that in addition to using 5 bits to select one of 32
possible input bytes, and can also specify three different immediate
values (0, 0x80 and 0xFF), which would be needed to make it work with
the GenerateMask operations mentioned above.
All in all a pretty general set of opcodes for SIMD data processing, it
is particularly obvious in the way each of the possible operations has
forms to work on either a set of input data (reg or immediate), or on
it's complement. This saves a lot of bubble-introducing mask setup
operations, but is normally not considered to be required on a regular cpu.
Terje
"Almost all programming can be viewed as an exercise in caching."
.sig, and this article is just a pretty bad example:
For the last ten years or so, this has been my
Yes, you should probably cache some or most of this stuff, but you should also consider which of these lists might contain dynamic data:
Is it enough to reload the list at application startup, every N days/hours/minutes, or would it be possible to send a signal from the updating process to trigger a reload only when needed?
Terje
Many contributors do this already. A few times they'll just submit all the individual images, and one of the coordinators will assemble them into a panorama.
I've posted panos from most of the confluences I've personally visited: http://www.confluence.org/visitor.php?id=157
Terje Mathisen
Scandinavian Coordinator The Degree Confluence Project
nosphalot is correct: The Turbo breakthrough was that they determined that by using feedback, just as in an engine turbo, you could get arbitrarily close to Shannons limit.
;.)
The key idea is that this feedback gives you an infinite impulse response, i.e. in theory all bits ever transmitted through such a channel will continue to affect it for ever after.
Even if you do limit the feedback time to more reasonable levels, you can still get a very useful increase in channel capacity.
It is also important to notice that such a channel must have significant delay, i.e. here's another reason to complain about being lagged.
Terje
You're right: 64 bits doesn't make it faster, but otoh it doesn't really make it significantly slower or bigger either.
According to the latest discussions on news:comp.arch, the 64-bit size overhead on current cpus is around 3%, the internal bus size increase doesn't matter, and code size can be more or less the same.
It is only when you automatically extend all default-sized data items from 32 to 64 bits that you get a noticable slowdown.
It is only when you really do need more than about 2 GB of RAM that a 64-bit cpu is really useful.
Terje
Novell had even greater problems with WAN latencies due to having an effective window size of 1 for most connections.
They solved this with something they called Packet Burst, with depended upon very careful, high-resolution timing, of all replies from the client.
They also used the same timers to insert controlled amounts of gap time between each transmitted packet, if that was needed.
The net effect was that they could get very close to maximum throughput, for the current combination of source, destination and current network load.
Terje
However, I have no respect for any legal system that places defendants at the mercy of overzealous prosecutors driven by either corporate cartels or popular sentiment. I have no opinion on Norway's society or government in general, but I can still say their legal rules suck fat cock.
Please do some more reading: In all criminal cases in Norway, the government has to pick up the defendant's legal costs, irrespective of which lawyer he chooses to represent himself.
This means that even in an obviously lopsided case like this (really the MPAA vs Jon J), the stronger party cannot add cripling economic burdens on top of the onus of being forced to show up in court.
Terje
First of all, Steve Gibson is only partly right:
"A hard disk is a binary medium, it can either be new, or full."
For personal data (code I write, photos I take etc.) I've been using disk-to-disk backups for many years: I keep copies on at least three machines, in two locations (home/office/laptop). Since I always roll all the files forward when I upgrade, this means that I have never lost any significant amount of data over the last 20 years.
I don't believe you can trust an IDE RAID array to stay healthy for years if you just store it in a closet somewhere, you need to keep those disks at least somewhat active. Even so, I've been looking seriously at disk-to-disk backups for all our PC servers (500+) for some time now, and it is starting to make a lot of sense:
This is not intended as longterm storage however, instead it would allow a server to be booted off the last IDE snapshot, as soon as we can determine that the primary (SCSI) arrays are well and truly hosed. Booting from IDE and allowing all users read-only access to week-old versions of their files, while restoring the incremental backups from tape, is much better than staying offline for a week.
At the same time, we can rebuild a new SCSI array from scratch, mirror the IDE data onto it, and as soon as the last incremental backup tapes have been restored, we'll switch back to the SCSI disks, and resume normal operation.
Terje
I believe even the US will implement some form of caller pays for cell phone calls. This is because it leads to much higher usage of those phones:
Several of my friends in the US tends to keep their phones turned off, only using them for outgoing calls to give important messages. Some of them even carry beepers to receive notification that they need to call someone.
With caller pays and built-in text messaging I keep my phone on at all times, except when on a plane. (In a meeting I'll make it silent, but I can still receive messages.)
Here in Norway we've had number portability for a while now, but all cell phones still have a number starting with either 9 or 4. (Yes, it is legal to have a cell phone number that starts with 911, I had such a number a few years ago.)
All phone calls (except 800) are caller pays, and even 800 numbers still carry a call setup fee of about 5 cents. There are in fact no free calls at all, since even local calls cost about a $1 to $1.50 per hour depending upon the time of day/week.
OTOH, we got totally rid of long distance charges several years ago, so it costs exactly the same to call 2500 km from Lindesnes to North Cape as to call next door.
Calls to cell phones are relatively expensive, they cost about the same as an international call to the US (10 to 20 cents/minute). Many people have still decided to not have a landline phone at all. Those copper wires can be put to much better use with ADSL, which costs from $45/month.