Home
| Calendar
| Mail Lists
| List Archives
| Desktop SIG
| Hardware Hacking SIG
Wiki | Flickr | PicasaWeb | Video | Maps & Directions | Installfests | Keysignings Linux Cafe | Meeting Notes | Linux Links | Bling | About BLU |
On Fri, 22 Feb 2013 08:36:15 -0800 "Rich Braun" <richb at pioneer.ci.net> wrote: > Well, now that the work is done you might compare it to a stock > that's now worth $10: it no longer matters what it cost at the time > you bought, you have something worth $10 now and that's all the > matters. You have a btrfs system based on a recent Linux, and I have > an older one. If you want to follow that analogy then what the stock originally cost does matter. The change in value determines how much value we've gained or lost. > We can maintain a combative tone if you wish, but it serves our mutual > readership better if we focus on teaching and persuading the broader > audience to try out the newer tools that we each have a passion for. Wasn't it you who made the comment about reinventing the backup wheel? But that's precisely what you are doing with your database solution. We have Reed-Solomon cyclic error correction (used on CD and DVD media, some tape systems, and in parchive files). We have cyclic checksum file systems (ZFS, Btrfs and ReFS). What possible benefit is there to using a one-off custom database when the problem has already been solved? None that I can see. It only works with custom tools designed to work with that custom database just like Legato Networker (or whoever owns it now) or any of a plethora of vendor lock-in "solutions". I'm not against teaching. I am against the idea that "let me throw a database at it" is ever a good answer. Backups need to be simple to create and simple to restore. Anything that complicates these two requirements is to be avoided. -- Rich P.
BLU is a member of BostonUserGroups | |
We also thank MIT for the use of their facilities. |