Re: users as blobs

[Bill Hacker <wbh@xxxxxxxxxxxxx>]

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.
>
>
> Markus

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.

Bill