/var/opt/K/SCO/Unix/ - SCO

This is a discussion on /var/opt/K/SCO/Unix/ - SCO ; I have a question out of mere curiosity... Why does the OpenServer family have such a convoluted filesystem hierarchy, where the real system binaries and data seems to be in weird places like "/var/opt/K/SCO/Unix/", with the "usual" Unix hierarchy symlinked ...

+ Reply to Thread
Results 1 to 5 of 5

Thread: /var/opt/K/SCO/Unix/

  1. /var/opt/K/SCO/Unix/

    I have a question out of mere curiosity...

    Why does the OpenServer family have such a convoluted filesystem
    hierarchy, where the real system binaries and data seems to be in weird
    places like "/var/opt/K/SCO/Unix/", with the "usual" Unix hierarchy
    symlinked to the "weird" OpenServer hierarchy.

    Why the weird OpenServer hierarchy in the first place? "/var/opt/K"???

  2. Re: /var/opt/K/SCO/Unix/

    Pepe typed (on Fri, Jul 18, 2008 at 04:05:14PM +0200):
    > I have a question out of mere curiosity...
    >
    > Why does the OpenServer family have such a convoluted filesystem
    > hierarchy, where the real system binaries and data seems to be in weird
    > places like "/var/opt/K/SCO/Unix/", with the "usual" Unix hierarchy
    > symlinked to the "weird" OpenServer hierarchy.
    >
    > Why the weird OpenServer hierarchy in the first place? "/var/opt/K"???


    There's an SCO 1995 white paper on Software Storage Objects wherein is
    laid out the rationale for this scheme. Download it from my site:

    ftp.jpr.com/pub/sso_wp.tgz

    --
    JP

  3. Re: /var/opt/K/SCO/Unix/

    Jean-Pierre Radley wrote:
    > Pepe typed (on Fri, Jul 18, 2008 at 04:05:14PM +0200):
    >
    >>I have a question out of mere curiosity...
    >>
    >>Why does the OpenServer family have such a convoluted filesystem
    >>hierarchy, where the real system binaries and data seems to be in weird
    >>places like "/var/opt/K/SCO/Unix/", with the "usual" Unix hierarchy
    >>symlinked to the "weird" OpenServer hierarchy.
    >>
    >>Why the weird OpenServer hierarchy in the first place? "/var/opt/K"???

    >
    >
    > There's an SCO 1995 white paper on Software Storage Objects wherein is
    > laid out the rationale for this scheme. Download it from my site:
    >
    > ftp.jpr.com/pub/sso_wp.tgz
    >


    Thank you. That was a very interesting read.

    So the convoluted OpenServer filesystem hierarchy is just a by-product
    of a in-house developed SCO software packaging scheme, aiming for
    network installations of software and as repository of the files part of
    software packages.

    Makes me shudder. To pervert the sacrosanct UNIX filesystem hierarchy
    seems so wrong to me.

    That explains a lot.

  4. Re: /var/opt/K/SCO/Unix/

    On Fri, Jul 18, 2008, Pepe wrote:
    >Jean-Pierre Radley wrote:
    >> Pepe typed (on Fri, Jul 18, 2008 at 04:05:14PM +0200):
    >>
    >>>I have a question out of mere curiosity...
    >>>
    >>>Why does the OpenServer family have such a convoluted filesystem
    >>>hierarchy, where the real system binaries and data seems to be in weird
    >>>places like "/var/opt/K/SCO/Unix/", with the "usual" Unix hierarchy
    >>>symlinked to the "weird" OpenServer hierarchy.
    >>>
    >>>Why the weird OpenServer hierarchy in the first place? "/var/opt/K"???

    >>
    >> There's an SCO 1995 white paper on Software Storage Objects wherein is
    >> laid out the rationale for this scheme. Download it from my site:
    >>
    >> ftp.jpr.com/pub/sso_wp.tgz
    >>

    >
    >Thank you. That was a very interesting read.
    >
    >So the convoluted OpenServer filesystem hierarchy is just a by-product
    >of a in-house developed SCO software packaging scheme, aiming for
    >network installations of software and as repository of the files part of
    >software packages.


    Many moons ago there was a really great presentation by Mary (something) at
    SCO Forum about their new packaging system and the wonders of visual TCL.

    At the time I thought that visual TCL would make life much easier, figuring
    out how many things in scoadmin worked as I would be able to read the
    source. Unfortunately, the tcl scripts were (are) virtually
    indecipherable, making the sloppy perl of webmin and usermin look great by
    comparison, and there's no comparison to the Red Hat/CentOS python system
    configuration scripts.

    >Makes me shudder. To pervert the sacrosanct UNIX filesystem hierarchy
    >seems so wrong to me.


    You're not the first to say something like that :-).

    Bill
    --
    INTERNET: bill@celestial.com Bill Campbell; Celestial Software LLC
    URL: http://www.celestial.com/ PO Box 820; 6641 E. Mercer Way
    Voice: (206) 236-1676 Mercer Island, WA 98040-0820
    Fax: (206) 232-9186

    Government is the great fiction, through which everbody endeavors to
    live at the expense of everybody else. -- Frederic Bastiat

  5. Re: /var/opt/K/SCO/Unix/

    wrote:

    Pepe>>> Why does the OpenServer family have such a convoluted filesystem
    Pepe>>> hierarchy, where the real system binaries and data seems to be in weird
    Pepe>>> places like "/var/opt/K/SCO/Unix/", with the "usual" Unix hierarchy
    Pepe>>> symlinked to the "weird" OpenServer hierarchy.

    Pepe>>> Why the weird OpenServer hierarchy in the first place? "/var/opt/K"???

    JPR>> There's an SCO 1995 white paper on Software Storage Objects wherein is
    JPR>> laid out the rationale for this scheme. Download it from my site:

    JPR>> ftp.jpr.com/pub/sso_wp.tgz

    Pepe> Thank you. That was a very interesting read.

    Pepe> So the convoluted OpenServer filesystem hierarchy is just a by-product
    Pepe> of a in-house developed SCO software packaging scheme, aiming for
    Pepe> network installations of software and as repository of the files part of
    Pepe> software packages.

    Pepe> Makes me shudder. To pervert the sacrosanct UNIX filesystem hierarchy
    Pepe> seems so wrong to me.

    Pepe> That explains a lot.

    Far more evil than the whole stupid tilting at windmills anti-Linux crusade,
    really.

    Before OpenServer 5.0.0 shipped in 1995, SCO Unix had a perfectly normal
    Unix filesystem hierarchy. I was working in Escalations at the time --
    doing customer-emergency bug fixes on already shipping products (mostly
    SCO Unix 3.2v4.2 / Open Desktop 3.0 at that point). In late 1994 I was
    sent to "SCO London" (Watford) for 3 months to help with the bug backlog
    before shipping what became OSR5. This was my first inkling of the
    whole "SSO" scheme -- the symlink mess.

    I had several long drawn out arguments with the SCO London developers.
    It seemed that they'd had a similar reaction to mine ("what is this
    horrible crap they're doing to the filesystem?"), but they didn't feel
    that they had any political capital to spend on fighting it. The SSO
    design came out of Santa Cruz HQ and they couldn't do anything about it.
    When I returned to Santa Cruz I spent some fruitless time arguing with
    the designers themselves.

    As I see it, the symlink mess in the filesystem is just an externalized
    representation of what custom+ already knows in its databases. There is
    no reason to lay it out all over the filesystem for every administrator
    and script to trip over, when a perfectly fine database already knows
    about it.

    The SSO design says otherwise. Supposedly you could have multiple
    versions of the same component installed at once -- but this never
    worked because after all your symlinks out in the normal filesystem
    hierarchy can only point to one version at a time. Supposedly it would
    help you back up only those parts of the system that were changable
    (back up /var) -- but this could have been done with a trivial database
    dump utility: `custom --list-var-files | cpio -o ...`. Supposedly it
    would let you have diskless or small-disk systems by mounting /opt from
    a large shared repository and /var from the local disk or a small
    private (per-host) NFS store -- but who really cares? Even at that
    time, the likely disk savings weren't worth the pain.

    It was a failed design from the start. It didn't deliver on any of the
    promises it made; except the implied one of making a hash out of the
    filename space.

    Once it was apparent that OpenServer 5.0.0 was doomed to ship with it, I
    started agitating for an "SSO Removal Supplement" that we could possibly
    ship shortly after 5.0.0 went out the door. Nobody would listen to me.
    Everyone -- customers, Support, Escalations, Engineering, and no doubt
    Marketing & Sales -- suffered the consequences from then on.

    I tried to make a "noalias must go"-like stand(*). I apologize to
    everyone for having failed.

    [(*)I didn't try as hard as DMR, nor did I imagine myself to be nearly
    as influential, even within the small world of SCO Engineering.]

    >Bela<


+ Reply to Thread