DragonFly BSD
DragonFly users List (threaded) for 2006-09
[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]

Re: users as blobs

From: Bill Hacker <wbh@xxxxxxxxxxxxx>
Date: Mon, 04 Sep 2006 20:19:59 +0800

Markus Hitter wrote:

Am 04.09.2006 um 00:16 schrieb walt:

Are you thinking about, say, pointers to my real blob which exists
on one physical server, or actually migrating blob->walt to anywhere
I'm actually needed?  (Most likely to unplug the sink or the toilet.)

This could be something like a mirrored RAID, but over the network. Do a network mount of the /home/bob partition, then, as you work with it, files are copied to a local drive and things start to become faster. Similar to how you'd recover from a drive failure in a two disk RAID.

Such a network-RAID would be a great solution for people partly working on a laptop elsewhere and partly working on the own desktop as well, but I couldn't find a piece of software supporting such a strategy so far.


Not new. Aside from RAID NAS, even ancient smbfs could handle that - with Warp, anyway.

- Find oneself short of local HDD space.

- drag an entire app folder or dirtree off my box and drop it into spare space on a drive 'mapped' from another Warp box.

- 'alias' icons still open and run the apps, just a bit slower on 100 BT. Gig-E? Probably close to same as ATA speed.

(The same stunt would break MS shortcut links. Worse, the dependencies might not be found...).

- finish the local cleanup/new disk, drag the dirtree/folder back onto my own box.

- 'alias' icons still work, but faster again.

Same with a whole user 'tree'.

SOM. The 'System Object Model' - the OS/2 DB that tracks paths, settings, dependencies, etc. Auto updated by drag'n drop, but NOT by CLI manual moves.

User as a 'BLOB'? Mmmmm.. more like 'pointers to the app/user's resources'

So the concept is well-proven - aside from the issue of OS/2 never doing an automated 'pack' on those DB files... a sorely needed feature.

The *BSD's have the 'locate' DB, 'whereis', et al - but do not (ordinarily) automagically use them to override/augment/alter the path during such moves.

Clustering and such entirely aside, DFLY might be able to improve on that.

To Wit:

"Long ago and far away..." The Novell Netware default was to first search for config files, overlays, modules, and such in the same directory the code that needed them was operating from. If not found, Netware would traverse down all the subdirs from that point - even if NONE of these were in/on the 'PATH'.
As is was/is not unreasonable to expect an app to keep all it bits stuff under its own dir, that worked really well.

Only when those steps failed did Netware search the PATH.

We kept paths simple by calling all apps from a script that began with a 'cd' to wherever the app lived, invoked the app, and did a 'cd' back to where the menus lived on exit. HAd to. PATH environment was too small to cover 'em all.

Crude and rude, but effective.

By contrast, *n*x is often irritating in that one can be sitting in the same dir as a given binary, but if it is not on the PATH, still have to prepend at least a './' - if not the entire path - in order to invoke said binary.

Even CP/M or DOS ain't *that* picky!

May be something there for down the road.


[Date Prev][Date Next]  [Thread Prev][Thread Next]  [Date Index][Thread Index]