[Info-vax] HP wins Oracle Itanium case

[Stephen Hoffman]

On 2012-08-23 07:06:47 +0000, Howard S Shubs said:

> In article <k1499b$a1e$1 at dont-email.me>,
>  Stephen Hoffman <seaohveh at hoffmanlabs.invalid> wrote:
> 
>> I'm finding directories less relevant.  They're just a resource
>> address, and a GUID could or would work as well.
>> 
>> I might as well just ask the OS "where's my local file store?" and just
>> start using that address.
> 
> I find them useful for organization.  Having one big multi-TB pot
> containing a bunch undifferentiated files doesn't sound as useful.

Nothing precludes you (or the system) from using a database for that 
mapping, of course.  That's what a file system is, after all; it's one 
of the simplest databases around, and without transaction support and 
other features.

And perversely, if you squint at a classic hierarchy of devices, 
directories and files, you can see the Microsoft registry; the primary 
keys and the hives, the keys, and the data.  (Or maybe if you squint at 
the registry...  That squinting seems to be somewhat more common.)

With some platforms, it's common to be handed a relative path (which 
itself might include a GUID) for various storage tasks (volatile 
storage, permanent storage, your libraries, executable code, etc) and 
to then resolve what your application needs to do, relative to those 
available paths.

What we're all used to with installing a layered product or application 
on VMS - having application files scattered all over the place, and 
each product often doing its own unique thing, all (hopefully) tracked 
by PCSI or (not tracked at all by) VMSINSTAL - is just one of the ways 
you can load your code (or your data) onto a system.  With some other 
platforms, you're encouraged to have all of your "stuff" under one path 
(and quite possibly with an embedded GUID), with system-defined 
relative paths under your path for various components of your 
environment.

The nice thing with these bundles: it avoids getting applications 
tangled, and completely avoids "DLL hell".   Yes, at the cost of some 
storage; usually negligible.

-- 
Pure Personal Opinion | HoffmanLabs LLC