On Wednesday 14 September 2005 16:24, Jack Carroll wrote: > On Tue, Sep 13, 2005 at 08:23:57PM -0400, Timothy Miller wrote: > > An open source, distributed, fault-tolerant, portable part number > > system with human-readable backup data would be a boon to companies > > everywhere. > > > > It would be wonderful if the OGP could inspire other OSS projects. > > Maybe this should be one? > > Other open source projects have been forced to create tools that > were useful to others. Why not us? > > Here are my one-quarter baked preliminary thoughts. > > As I said yesterday, the infrastucture and tools to support a number > log should be the most basic and traditional features and utilities of > Unix. This maximizes future-proofing.
If you want future-proofing, go with open formats. Software can (and will have to be) rewritten. On the time scales we're thinking of, there is simply no way to see what will happen. > A good form of organization might be a directory tree, with each log > entry file consisting of a single line of text containing four > tab-separated fields. Permissions would be set so that any authorized > designer could write a new file, and edit it for a specific time after > first writing it. Permissions should be set to make all files and > directories world-readable, but no files or directories could be deleted or > changed without > extraordinary effort. (Turn on root write permission, turn off sticky > bits, etc.) Not even root should be able to alter information without > extraordinary effort. There is already a trend towards moving to databases instead of filesystems. I wouldn't be so sure that basic filesystems will still be around in a couple of decennia. Also, who is going to guarantee that the numbers entered conform to the naming standard? > The writable on-line log should have multiple sites, with automatic > synchronization of new entries with very short latency. Any accidental > conflicting assignment of a number should be immediately reported to both > designers. No. Accidental conflicting assignment should be impossible, not fixable. Any interaction with the system should be either successful or not. Also, multiple changes at the same time, when independent, should not interfere. > There should be a stated procedure to write backup snapshots to > durable media and store them in safe locations. It's safest never to > rewrite media; the log is extraordinarily critical to the organization. Agreed. Incidentally, there's special software for storing critical information reliably. It's called a database. I'm sorry, but I just can't see a bunch of shell scripts and a file system being anywhere near reliable enough. > It may be desirable for designers to cryptographically sign their > entries, but that would probably be more beneficial for ECOs and released > drawings. The main requirement with the log is to prevent loss of entries, > once entered. In other words, the information needs to be stored durably. If you look closely at what I said above, you'll also spot requirements for atomicity, consistency and isolation. These four things are what databases are designed for. We'd be crazy not to use them. Longevity should not be a problem. I suspect that SQL will last at least as long as UNIX, and even if it doesn't, since there is no way to predict what will happen in the IT sector in the next decennia, we will have to be prepared to migrate to newer infrastructure anyway. Anyway, also see my other post about this for a bit more detail. Lourens
pgpjtxt3bJ68s.pgp
Description: PGP signature
_______________________________________________ Open-graphics mailing list [email protected] http://lists.duskglow.com/mailman/listinfo/open-graphics List service provided by Duskglow Consulting, LLC (www.duskglow.com)
