It's a scam if you enter into it like you describe, and aren't aware of exactly these kinds of problems. However, I think there are some inherent advantages to packet-switched voice communications which use the same infrastructure as your data communications.
The expectation is that the VoIP charges will allow ISPs and providers to expand their bandwidth to support both voice and data over the same network. It's not necessarily orders of magnitude cheaper, but once it scales up it should be easier to support than separate networks.
In the meantime, it may be an excellent way to use up dark fibre...
Before anyone who didn't RTFA gets up in arms: No, he didn't say that, and the article header really should explain. The Register is drawing a comparison with his attitude towards BitKeeper. s/BitKeeper/Microsoft and s/Tridge/OpenOffice.org.
Were the submitter and editor confused, or are one or both intentionally trying to provoke a reaction by providing an inaccurate summary? At least the Register article has a clear "No, he really didn't say that" line. The/. summary acts as if it's a real Linus quote.
Not at all. It's the difference between downloading complete ISOs (at least one full 650MB CD) and downloading a small install CD plus the packages you actually need. It may take a while, but it will take a lot longer to download 1-4 complete ISOs, especially if you do a minimal install. Since I don't like taking the time to burn all of the CDs (or a DVD), I usually save the ISOs on my server and do a net install over NFS.
Ubuntu has the best compromise IMO: most of what you need is on the CD, so you can still do a decent desktop or server install (without trying to remember what packages are necessary to get a Gnome or KDE desktop). The rest you get through apt after the install.
I'm going to upgrade my Sarge server to Hoary this weekend. I love Debian but testing breaks too much and stable is too old. The basic idea of Ubuntu is that they support the most popular / important packages from Debian, but still let you install almost all of the other Debian packages (via universe). For me, the packages I needed from universe were stuff like Gallery and SpamAssassin which I don't consider critical for security updates.
The advantage is that the software is recent but reasonably well-tested, will have security updates for the core (non-universe) packages, and can be upgraded in six months to the next version. It solves the Debian problem of choosing between old stable or broken testing / unstable. It's also completely free and has a good social contract along the lines of Debian. The development process seems reasonably open and the community is pretty strong, especially considering the young age of the distro.
Does anyone know if Debian is planning to do something like this? It's good about telling me when a config file has changed, and providing me with the differences between my version and the new version. Clearly it knows when I've made changes (therefore it must know what the original old version looked like) but it doesn't seem to be able to do a 3-way diff and present me with logical changes. I keep getting clobbered with new versions of files in/etc where I'm left wondering 'which of these changes are reverting things I added for good reason, and which are the new changes the maintainer has added?'
I guess that the Debian Party Line would be: config files don't change in stable (I'm running sarge), so it's not an official Debian problem.
Here's a case where the FOSS (Free/Open Source Software) acronym doesn't work, because Free Software and Open Source Software are not the same thing.
Practical, pragmatic decisions like using Java are not a problem for Open Source. That's what Open Source is: developing software in an open manner because of a belief that software developed this way is technologically better than closed-source software. It does not insist that every tool (or language) used in the development process be Free Software or Open Source. From a practical standpoint, it is sufficient that the tool or language meets the needs of the developers and is available on the required platforms, and does not appear to be a patent or other legal liability.
Free software on the other hand, insists for idealogical reasons that any software or tool which is not completely free is deterimental to the community. It's important to have respect for this opinion, but it is not a catastrophe for the OO.org team to choose the Open Source route.
That's not only true for thin-client setups: most thick-client offices have servers (and other hardware) which, if they go down, also provide unplanned free time.
Re:and how many times...
on
GCC 4.0 Preview
·
· Score: 2, Interesting
You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...
Can you run C++ applications compiled on Solaris 2 on any later version?
Compatibility is where Sun rocks, and it's also the rock that Sun is tied to. Most of the things that people hate about Solaris are kept that way because of their commitment to backwards compatibility. It becomes difficult to make signifigant changes if you focus on compatibility the way they do.
Linux and other OSS tools like GCC have advanced quickly partly because they have always been able to rewrite just about anything if they need to. Historically people were used to it, or okay with it. I wouldn't be suprised if at some point Red Hat and other Enterprise vendors forked a stable-ABI version of GCC, glibc, and Linux, because in larger environments backwards compatibility is very important.
Re:and how many times...
on
GCC 4.0 Preview
·
· Score: 0, Redundant
You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...
Can you run C++ applications compiled on Solaris 2 on any later version?
Can Mozilla integrate these apps better? From what I understand there's a lot of JavaScript going on to talk to the server, parse the results, etc. Could some of that be moved into custom reusable libraries in Mozilla / Firefox which the Javascript (Ajax engine) utilizes? I've noticed that Google Maps can take a heck of a lot of processor overhead. I imagine a lot of that is Javascript parsing which could easily be moved into compiled libraries.
It would be very interesting to have these applications work better (faster, more smoothly) on Mozilla based platforms, and degrade into a portable Javascript-only implementation on other browsers such as IE.
Gentoo and Debian are centrally-manged free software projects. This means they can control all of the packages themselves, which does result in better integration, quality, etc.
RPMs are not centrally managed. There are the main YUM repositories (which work nearly as well as the debian and gentoo repositories) but you can also download RPMs from many third parties.
When was the last time you saw a third party offer a.deb which wasn't in the Debian repository? Do ATI or NVidia offer kernel packages for Debian or Gentoo? No; you have to either use the centrally-managed repository version, or compile it yourself.
On Windows and OSX, do you install all software directly through Windows Update / Apple Update from their servers? Third party software is an important part of widespread acceptance of an operating system. RPMs could be better but they are important for commercially-oriented distros.
And this will suffer from the same problem: capabilities and ACLs are very difficult to get right, and require extremely good tools as well as informed administrators.
For quite a while (as the OP points out) the Linux kernel hasn't checked for "uid=0". Instead it checks for one of many capabilities, like CAP_SET_SYSTEM_TIME or whatever. You can give these fine-grained capabilities to other users. SELinux does something similar for applications, letting you restrict in extremely fine-grained detail what a process can do.
The key word is fine grained. It's pretty difficult to build a sand castle if you have to move individual grains. If you can manage it, it's one hell of a sand castle, but you need tools, patterns, and layers to do it.
Implementing capabilties, roles, contexts, etc. doesn't solve anything by itself, any more than a compiler solves problems by itself. It gives us the ability to solve the problem, but we're still left with the hard work.
The most interesting work going on in this area IMO is (believe it or not) Fedora. They're trying really hard to integrate SELinux into a usable operating system. It's much harder than it looks; at the moment they only have certain services running under SELinux restrictions, but eventually they'll get to a complete model where it really will be difficult to comprimise the system.
It's not hard to secure a system; just turn it off. It's very hard to secure a system so that it allows "approved" actions and disallows everything else.
The lovely thing about paying back T-Bills to yourself is that noone can actually tell whether you did it. You tax people, you buy backs some T-Bills (move money from left pocket to right), you take money out of right pocket and pay some bills. Alternatively, you tax people, you DON'T buy back some T-Bills, you take money out of the left pocket and pay some bills.
People most certainly would notice this. Exactly because of the shell-game issue, doing this would be the equivalent of not repaying t-bill loans to other investors. Can you imagine the financial panic which would result from that, and the effect on our economy?
You talk about suckers for the T-bills. It comes down to that; if people are willing to loan the government money, then the T-bills the trust fund has are worth their face value. If not, then they're worthless. However, there isn't any indication that the country will be unable to repay loans anytime soon; the surest sign of that would be an immediate decline in T-bill purchasing, because if they're not guaranteed the crappy interest rate sure won't interest anyone.
If the trust fund 'goes away', and the debt is suddenly 40% lower, then people would immediately loan the government the money, and we're back where we started. So the question is, is the current debt load too much? Most people don't think so; it's the deficit (and the prospect of continued long-term deficits) which worries people. But that's a separate issue.
A company can sucker people with shell-games like you describe, and then default and walk away. I don't think our government is doing that. There are things companies can do which governments can't, and vice-versa, because the motives of the two are completely different.
The trust fund is invested in US Treasuries, which are the most reliable form of investing on the planet. If the government fails to pay back US Treasury notes, even to itself, there will be much more signifigant problems in the world.
If you remove the Trust Fund from equations, then you also have to remove it from the national debt (which includes money owed to the trust fund), which decreases the need for revenue by exactly the same amount you're referring to.
Is it true that DVI is limited to 60hz, and so that even if LCD refresh times improve, DVI always will be limited?
Does anyone have recommendations for lower-end LCDs? I just bought a 17-inch LCD from Dell for my girlfriend for $300 (on sale from $350), and it seems pretty good.
Are prices going to continue to drop? I know people predicted they would hold steady for most of 2004--are the supply problems fixed?
The situation of outlays exceeding revenue designed into SS; that's what the trust fund is used for. The fact that we can sustain that situation for 30 years should tell you something.
The article, if you care to read it, argues that the forecasts are possibly quite pessimistic. Most of the forecasts of the last twenty years have been pessimistic compared to actual values. And a slight change in some estimates results in your figure of 2053 changing to 2093.
Everyone agrees that if / when SS is faced with clear shortfalls in the medium-term, we should make changes appropriately. The article is arguing that the shortfalls are not clear, and they are at the limit of our ability to predict with even ballpark accuracy.
Can you imagine a president in 1940 making radical changes to SS because forecasts predicted bankruptcy in 2000? Do you think those predictions would have been correct, and the changes necessary or even beneficial?
Boot can live on a RAID because you really just boot off of one of the devices, right? All the implementations I've heard about revolve around 'boot from hda1, then from hdc1' where hda1 and hdc1 make RAID device md1. Software RAID has the nice property of its component disks being readable even if RAID isn't enabled / running. Grub can't read RAID devices or LVM AFAIK.
Slashdot has hardware to support its reader base. Other sites have much smaller requirements. When Slashdot links to them, they get 10x or more times their regular traffic. If they chose to spend what Slashdot does on hardware, presumably they could support the load. But it's not worth it for rare cases of extreme short-term interest. On a large site, the Slashdot effect may show up only as a small jump (percentage-wise) in hits.
Unfortunately, architectural issues like these are very difficult to overcome, because of backwards compatibility. They can't make Longhorn refuse to run ActiveX without killing a lot of applets / applications. I know people keep saying it, but this is the real problem with Microsoft's security: not small buffer overflows, but large-scale issues resulting from many years of focusing on features rather than security. It will be many years before Microsoft can make Windows truly secure (assuming they maintain backwards compatibility).
Microsoft started out with a single-user, single-threaded, non-networked OS. They've never really lost that mindset.
LVM isn't designed for any sort of redundancy. If disks fail with LVM, you're just as screwed as if you didn't have it. If you want redundancy, you want to use LVM on RAID. But you seem to have used it more than I have, so I'm curious to know what you mean by "normal recovery procedure".
The example of this I've heard is LVM and XFS. I believe that XFS allows you to freeze changes to a filesystem, and LVM can write a snapshot of a partition to another disk. Then you backup from the snapshot.
I know that everyone says that transcoding loses quality. So when I finally got an iPod, I initially transcoded all of my.ogg files to.mp3, but planned on re-encoding later from the CDs. But when I re-encoded a few tracks with lame, and listened to them versus the transcoded track, I honestly couldn't tell a difference (even with headphones). If I ever notice poor quality on my iPod, I guess I'll re-encode then, but otherwise why bother?
I believe that I used the default settings for both oggenc and lame, which was ~128 bit VBR in both cases.
The best way to create differential backups under Unix is with hardlinked snapshots. Easy Automated Snapshot-Style Backups with Rsync has a good explanation of how to do this. The best part is that restoring is as simple as copying a file. Each snapshot is a folder hierarchy on disk, and you can browse through any snapshot and find files you want.
One small improvement over rsync (IMO) is to use mkzftree from the zisofs-tools package. It's designed to create compressed ISO filesystems which will be transparently uncompressed when mounted under Linux (and other supporting operating systems; it's a documented ISO extension). mkzftree supports an option for creating hardlinked forest (like cp -al and rsync), with the advantage that the files are compressed, thus saving space. ISO isn't quite as flexible as ext2 for things like hardlinks, so what I do is have DVD-sized disk images formatted as ext2 to store the snapshots. I burn the disk images directly to DVD; each one can hold ten or twenty compressed snapshots (of my data anyway). The disadvantage is that I can't read the files directly (because they're compressed, and the transparent decompression only works with ISO) but it's easy to decompress a file or folder to/tmp using mkzftree if I need to restore something.
It shouldn't be hard to make the transparent decompression code work with other filesystems than ISO, as long as they're mounted read-only. The files are just gzipped with a header block indicating they are compressed.
Slashdot Mirror
It's a scam if you enter into it like you describe, and aren't aware of exactly these kinds of problems. However, I think there are some inherent advantages to packet-switched voice communications which use the same infrastructure as your data communications.
The expectation is that the VoIP charges will allow ISPs and providers to expand their bandwidth to support both voice and data over the same network. It's not necessarily orders of magnitude cheaper, but once it scales up it should be easier to support than separate networks.
In the meantime, it may be an excellent way to use up dark fibre...
Before anyone who didn't RTFA gets up in arms: No, he didn't say that, and the article header really should explain. The Register is drawing a comparison with his attitude towards BitKeeper. s/BitKeeper/Microsoft and s/Tridge/OpenOffice.org.
/. summary acts as if it's a real Linus quote.
Were the submitter and editor confused, or are one or both intentionally trying to provoke a reaction by providing an inaccurate summary? At least the Register article has a clear "No, he really didn't say that" line. The
Not at all. It's the difference between downloading complete ISOs (at least one full 650MB CD) and downloading a small install CD plus the packages you actually need. It may take a while, but it will take a lot longer to download 1-4 complete ISOs, especially if you do a minimal install. Since I don't like taking the time to burn all of the CDs (or a DVD), I usually save the ISOs on my server and do a net install over NFS.
Ubuntu has the best compromise IMO: most of what you need is on the CD, so you can still do a decent desktop or server install (without trying to remember what packages are necessary to get a Gnome or KDE desktop). The rest you get through apt after the install.
I'm going to upgrade my Sarge server to Hoary this weekend. I love Debian but testing breaks too much and stable is too old. The basic idea of Ubuntu is that they support the most popular / important packages from Debian, but still let you install almost all of the other Debian packages (via universe). For me, the packages I needed from universe were stuff like Gallery and SpamAssassin which I don't consider critical for security updates.
The advantage is that the software is recent but reasonably well-tested, will have security updates for the core (non-universe) packages, and can be upgraded in six months to the next version. It solves the Debian problem of choosing between old stable or broken testing / unstable. It's also completely free and has a good social contract along the lines of Debian. The development process seems reasonably open and the community is pretty strong, especially considering the young age of the distro.
Does anyone know if Debian is planning to do something like this? It's good about telling me when a config file has changed, and providing me with the differences between my version and the new version. Clearly it knows when I've made changes (therefore it must know what the original old version looked like) but it doesn't seem to be able to do a 3-way diff and present me with logical changes. I keep getting clobbered with new versions of files in /etc where I'm left wondering 'which of these changes are reverting things I added for good reason, and which are the new changes the maintainer has added?'
I guess that the Debian Party Line would be: config files don't change in stable (I'm running sarge), so it's not an official Debian problem.
Here's a case where the FOSS (Free/Open Source Software) acronym doesn't work, because Free Software and Open Source Software are not the same thing.
Practical, pragmatic decisions like using Java are not a problem for Open Source. That's what Open Source is: developing software in an open manner because of a belief that software developed this way is technologically better than closed-source software. It does not insist that every tool (or language) used in the development process be Free Software or Open Source. From a practical standpoint, it is sufficient that the tool or language meets the needs of the developers and is available on the required platforms, and does not appear to be a patent or other legal liability.
Free software on the other hand, insists for idealogical reasons that any software or tool which is not completely free is deterimental to the community. It's important to have respect for this opinion, but it is not a catastrophe for the OO.org team to choose the Open Source route.
That's not only true for thin-client setups: most thick-client offices have servers (and other hardware) which, if they go down, also provide unplanned free time.
You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...
Can you run C++ applications compiled on Solaris 2 on any later version?
Compatibility is where Sun rocks, and it's also the rock that Sun is tied to. Most of the things that people hate about Solaris are kept that way because of their commitment to backwards compatibility. It becomes difficult to make signifigant changes if you focus on compatibility the way they do.
Linux and other OSS tools like GCC have advanced quickly partly because they have always been able to rewrite just about anything if they need to. Historically people were used to it, or okay with it. I wouldn't be suprised if at some point Red Hat and other Enterprise vendors forked a stable-ABI version of GCC, glibc, and Linux, because in larger environments backwards compatibility is very important.
You're talking about C++ binary compatibility, right? I don't think that GCC has broken C binary compatibility in a long time...
Can you run C++ applications compiled on Solaris 2 on any later version?
Can Mozilla integrate these apps better? From what I understand there's a lot of JavaScript going on to talk to the server, parse the results, etc. Could some of that be moved into custom reusable libraries in Mozilla / Firefox which the Javascript (Ajax engine) utilizes? I've noticed that Google Maps can take a heck of a lot of processor overhead. I imagine a lot of that is Javascript parsing which could easily be moved into compiled libraries.
It would be very interesting to have these applications work better (faster, more smoothly) on Mozilla based platforms, and degrade into a portable Javascript-only implementation on other browsers such as IE.
Gentoo and Debian are centrally-manged free software projects. This means they can control all of the packages themselves, which does result in better integration, quality, etc.
.deb which wasn't in the Debian repository? Do ATI or NVidia offer kernel packages for Debian or Gentoo? No; you have to either use the centrally-managed repository version, or compile it yourself.
RPMs are not centrally managed. There are the main YUM repositories (which work nearly as well as the debian and gentoo repositories) but you can also download RPMs from many third parties.
When was the last time you saw a third party offer a
On Windows and OSX, do you install all software directly through Windows Update / Apple Update from their servers? Third party software is an important part of widespread acceptance of an operating system. RPMs could be better but they are important for commercially-oriented distros.
And this will suffer from the same problem: capabilities and ACLs are very difficult to get right, and require extremely good tools as well as informed administrators.
For quite a while (as the OP points out) the Linux kernel hasn't checked for "uid=0". Instead it checks for one of many capabilities, like CAP_SET_SYSTEM_TIME or whatever. You can give these fine-grained capabilities to other users. SELinux does something similar for applications, letting you restrict in extremely fine-grained detail what a process can do.
The key word is fine grained. It's pretty difficult to build a sand castle if you have to move individual grains. If you can manage it, it's one hell of a sand castle, but you need tools, patterns, and layers to do it.
Implementing capabilties, roles, contexts, etc. doesn't solve anything by itself, any more than a compiler solves problems by itself. It gives us the ability to solve the problem, but we're still left with the hard work.
The most interesting work going on in this area IMO is (believe it or not) Fedora. They're trying really hard to integrate SELinux into a usable operating system. It's much harder than it looks; at the moment they only have certain services running under SELinux restrictions, but eventually they'll get to a complete model where it really will be difficult to comprimise the system.
It's not hard to secure a system; just turn it off. It's very hard to secure a system so that it allows "approved" actions and disallows everything else.
The lovely thing about paying back T-Bills to yourself is that noone can actually tell whether you did it. You tax people, you buy backs some T-Bills (move money from left pocket to right), you take money out of right pocket and pay some bills. Alternatively, you tax people, you DON'T buy back some T-Bills, you take money out of the left pocket and pay some bills.
People most certainly would notice this. Exactly because of the shell-game issue, doing this would be the equivalent of not repaying t-bill loans to other investors. Can you imagine the financial panic which would result from that, and the effect on our economy?
You talk about suckers for the T-bills. It comes down to that; if people are willing to loan the government money, then the T-bills the trust fund has are worth their face value. If not, then they're worthless. However, there isn't any indication that the country will be unable to repay loans anytime soon; the surest sign of that would be an immediate decline in T-bill purchasing, because if they're not guaranteed the crappy interest rate sure won't interest anyone.
If the trust fund 'goes away', and the debt is suddenly 40% lower, then people would immediately loan the government the money, and we're back where we started. So the question is, is the current debt load too much? Most people don't think so; it's the deficit (and the prospect of continued long-term deficits) which worries people. But that's a separate issue.
A company can sucker people with shell-games like you describe, and then default and walk away. I don't think our government is doing that. There are things companies can do which governments can't, and vice-versa, because the motives of the two are completely different.
Hopefully.
The trust fund is invested in US Treasuries, which are the most reliable form of investing on the planet. If the government fails to pay back US Treasury notes, even to itself, there will be much more signifigant problems in the world.
If you remove the Trust Fund from equations, then you also have to remove it from the national debt (which includes money owed to the trust fund), which decreases the need for revenue by exactly the same amount you're referring to.
Is it true that DVI is limited to 60hz, and so that even if LCD refresh times improve, DVI always will be limited?
Does anyone have recommendations for lower-end LCDs? I just bought a 17-inch LCD from Dell for my girlfriend for $300 (on sale from $350), and it seems pretty good.
Are prices going to continue to drop? I know people predicted they would hold steady for most of 2004--are the supply problems fixed?
The situation of outlays exceeding revenue designed into SS; that's what the trust fund is used for. The fact that we can sustain that situation for 30 years should tell you something.
The article, if you care to read it, argues that the forecasts are possibly quite pessimistic. Most of the forecasts of the last twenty years have been pessimistic compared to actual values. And a slight change in some estimates results in your figure of 2053 changing to 2093.
Everyone agrees that if / when SS is faced with clear shortfalls in the medium-term, we should make changes appropriately. The article is arguing that the shortfalls are not clear, and they are at the limit of our ability to predict with even ballpark accuracy.
Can you imagine a president in 1940 making radical changes to SS because forecasts predicted bankruptcy in 2000? Do you think those predictions would have been correct, and the changes necessary or even beneficial?
Boot can live on a RAID because you really just boot off of one of the devices, right? All the implementations I've heard about revolve around 'boot from hda1, then from hdc1' where hda1 and hdc1 make RAID device md1. Software RAID has the nice property of its component disks being readable even if RAID isn't enabled / running. Grub can't read RAID devices or LVM AFAIK.
Slashdot has hardware to support its reader base. Other sites have much smaller requirements. When Slashdot links to them, they get 10x or more times their regular traffic. If they chose to spend what Slashdot does on hardware, presumably they could support the load. But it's not worth it for rare cases of extreme short-term interest. On a large site, the Slashdot effect may show up only as a small jump (percentage-wise) in hits.
Unfortunately, architectural issues like these are very difficult to overcome, because of backwards compatibility. They can't make Longhorn refuse to run ActiveX without killing a lot of applets / applications. I know people keep saying it, but this is the real problem with Microsoft's security: not small buffer overflows, but large-scale issues resulting from many years of focusing on features rather than security. It will be many years before Microsoft can make Windows truly secure (assuming they maintain backwards compatibility).
Microsoft started out with a single-user, single-threaded, non-networked OS. They've never really lost that mindset.
The reason it was changed for the movie was because Kubrick wasn't happy with the special effects backgrounds for Saturn.
LVM isn't designed for any sort of redundancy. If disks fail with LVM, you're just as screwed as if you didn't have it. If you want redundancy, you want to use LVM on RAID. But you seem to have used it more than I have, so I'm curious to know what you mean by "normal recovery procedure".
The example of this I've heard is LVM and XFS. I believe that XFS allows you to freeze changes to a filesystem, and LVM can write a snapshot of a partition to another disk. Then you backup from the snapshot.
I know that everyone says that transcoding loses quality. So when I finally got an iPod, I initially transcoded all of my .ogg files to .mp3, but planned on re-encoding later from the CDs. But when I re-encoded a few tracks with lame, and listened to them versus the transcoded track, I honestly couldn't tell a difference (even with headphones). If I ever notice poor quality on my iPod, I guess I'll re-encode then, but otherwise why bother?
I believe that I used the default settings for both oggenc and lame, which was ~128 bit VBR in both cases.
The best way to create differential backups under Unix is with hardlinked snapshots. Easy Automated Snapshot-Style Backups with Rsync has a good explanation of how to do this. The best part is that restoring is as simple as copying a file. Each snapshot is a folder hierarchy on disk, and you can browse through any snapshot and find files you want.
/tmp using mkzftree if I need to restore something.
One small improvement over rsync (IMO) is to use mkzftree from the zisofs-tools package. It's designed to create compressed ISO filesystems which will be transparently uncompressed when mounted under Linux (and other supporting operating systems; it's a documented ISO extension). mkzftree supports an option for creating hardlinked forest (like cp -al and rsync), with the advantage that the files are compressed, thus saving space. ISO isn't quite as flexible as ext2 for things like hardlinks, so what I do is have DVD-sized disk images formatted as ext2 to store the snapshots. I burn the disk images directly to DVD; each one can hold ten or twenty compressed snapshots (of my data anyway). The disadvantage is that I can't read the files directly (because they're compressed, and the transparent decompression only works with ISO) but it's easy to decompress a file or folder to
It shouldn't be hard to make the transparent decompression code work with other filesystems than ISO, as long as they're mounted read-only. The files are just gzipped with a header block indicating they are compressed.
We use Base 10, where the 10 means "10 in Base 10." Clear now?