41 karma · joined November 30, 2009
This is basically why GBDE exists.
See s.s. 4.1 "Protecting the user" of http://phk.freebsd.dk/pubs/bsdcon-03.gbde.paper.pdf
The drawback is that GBDE is for cold storage protection (which I imagine could be okay in a camera).
2. buy van
3. get someone to customize your van
4. ???
5. profit
For example, one can use the atomic nature of creating a symbolic link on nix to create a lock file to prevent a race condition in a forking shell script. Say you have two or more processes wanting to do something that can (or should) only be done by one process at a time; one naive solution is to manage access of each process to said action by using a lock file. However, writing or touching a file itself is not atomic.
The answer is to throw a symbolic link into the mix. In this scenario, the lock file already exists. However, the lock is not the file itself, but a symbolic link to the file. The protocol for each process to follow is:
1. try to create a symbolic link to lock file (any file really)
2. if successful, proceed; if failed, wait (or exit)
3. when process is done, delete symbolic link to lock file
Simply checking for the existence of the symlink is not sufficient since there is a period of time between checking for the symlink (or file) and proceeding with said action where another process can think it has the lock.
The OS ensures that one and only one symlink (of the same name) can exist; attempts to create it again (even simultaneously) will result in a failure of one process to create the symlink. There is one winner; all others are losers. This is to say, the kernel ensures that the operation is atomic. As a result, the OS is now arbitrating what process can proceed to action, at the very lowest level. Another way to think about it is that it provides a way to make competing processes serialize - or get in line so that they may complete their action one at a time.
In my experience, it is important to experiment and test to make sure that the atomic primitive you're using is actually working as expected. I've run up against some inconsistent implementations of symlink creation that make this action not as straightforward to use as one is lead to believe.
My first exposure to web programming was HTMLScript at my university in the mid 90s (now called MivaScript and is the language used to build the MivaMerchant product). Soon after, I switched to PHP 3, but I found that I preferred Miva.
I have not touched Miva in years after spending some time as a freelancer in the late 90s, but because it is tied to a successful niche e-commerce platform, the language survives. It is very similar to Cold Fusion minus the enterprise level database support.
I worked with CF for a time in the late 90s/00s (when it was still a product of Allaire) along side of ASP (pre .net), and I actually preferred it to both ASP and PHP - mainly because the mixing of mark up and DSL blocks seemed really unscalable.
PHP may have been seen as an evolution in web programming since it abstracted the mixing of logic and presentation a bit more than Miva or CF, but in retrospect I believe PHP was not an improvement. It made general web programming easier, but software maintenance is easier in languages like CF and Miva that embrace embedded mark up/logic.
The frameworks provided by Ruby, Python, Perl, and even TCL (among others) seem to have reached a point where only blurring the lines between client and server seem like the only logical paradigm change - and that's not to say it's an improvement.
http://www.archiveteam.org/index.php?title=Fire_Drill
Update: seems others have linked to archiveteam.org, so maybe that's the best route. Is the OP part of the AT effort or do they know about each other? Maybe they should.