Alternative to SCO - SCO

This is a discussion on Alternative to SCO - SCO ; With the chapter 11 filing and other recommendations, what is a good, long time viable alternative to SCO OpenServer?...

+ Reply to Thread
Page 1 of 2 1 2 LastLast
Results 1 to 20 of 31

Thread: Alternative to SCO

  1. Alternative to SCO

    With the chapter 11 filing and other recommendations, what is a good,
    long time viable alternative to SCO OpenServer?


  2. Re: Alternative to SCO

    On Oct 4, 11:27 am, smlunatick wrote:
    > With the chapter 11 filing and other recommendations, what is a good,
    > long time viable alternative to SCO OpenServer?


    Daytimer.


  3. Re: Alternative to SCO

    smlunatick hath wroth:

    >With the chapter 11 filing and other recommendations, what is a good,
    >long time viable alternative to SCO OpenServer?


    For long term, probably a mainframe. It really depends on how you
    long you consider long term and what you're doing with OpenServer. For
    data dumpsters, I've been using NAS (network attached sewer). For
    servers that require services and application servers, FreeBSD or
    Windoze 2000/2003 server, depending on the service, application, and
    religious mix. For desktops, mostly Windoze 2000 or XP, and a weird
    mix of Linux mutations. There's no single solution that works for
    everything.

    However, I have a question: Why do you consider chapter 11 to be
    justification for a move from OSR5? I can see it if you're a software
    developer and OpenServer is one of your target platforms. However, if
    you're currently running OSR5, and it works, I don't see much reason
    to switch to something else. I still have several 3.2v5.0.4
    customers. Also one Xenix customer. I'm still running ODT 3.2v4.2 in
    my office. Except for MMDF (which I'm too lazy to fix), everything
    works just fine.


    --
    Jeff Liebermann jeffl@cruzio.com
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  4. Re: Alternative to SCO

    On Thu, Oct 04, 2007, Jeff Liebermann wrote:
    >smlunatick hath wroth:
    >
    >>With the chapter 11 filing and other recommendations, what is a good,
    >>long time viable alternative to SCO OpenServer?

    >
    >For long term, probably a mainframe. It really depends on how you
    >long you consider long term and what you're doing with OpenServer. For
    >data dumpsters, I've been using NAS (network attached sewer). For
    >servers that require services and application servers, FreeBSD or
    >Windoze 2000/2003 server, depending on the service, application, and
    >religious mix. For desktops, mostly Windoze 2000 or XP, and a weird
    >mix of Linux mutations. There's no single solution that works for
    >everything.


    Most of our servers have been running on Linux or FreeBSD for years (it's
    not like the future of SCO hasn't been in doubt for at least five years).
    Our first mission-critical Linux installation at a customer's was done in
    September 1997, and we have been moving our customers from SCO Xenix and
    OpenServer to Linux for the last decade, first Caldera, then SuSE, and
    we're starting to use CentOS now.

    We've done a few FreeBSD systems, and have one in-house that has only been
    rebooted once in the last four years, that due to an extended power failure
    in the wee hours of the morning so it wasn't switched to generator before
    the UPS batteries died.

    We still have one OSR 5.0.6a system in-house for support for the few
    OpenServer systems our customers still have in use, but most of them have
    been moved to Linux or FreeBSD over the last 5 or 6 years.

    All of our in-house desktops are running Mac OS X, and we have migrated
    many of our customer's desktops to it as well including a bunch that were
    running diskless Linux boxes primarily as data entry terminals.

    >However, I have a question: Why do you consider chapter 11 to be
    >justification for a move from OSR5? I can see it if you're a software
    >developer and OpenServer is one of your target platforms. However, if
    >you're currently running OSR5, and it works, I don't see much reason
    >to switch to something else. I still have several 3.2v5.0.4
    >customers. Also one Xenix customer. I'm still running ODT 3.2v4.2 in
    >my office. Except for MMDF (which I'm too lazy to fix), everything
    >works just fine.


    The biggest issue is hardware on the older systems. Currently available
    hardware often doesn't support things like the ISA Specialix multi-port
    boards we used on many of our SCO Xenix and OpenServer installations, not
    to mention things like customer running 80286 Xenix binaries. Even
    discounting the problems of support for '286 binaries, there are often
    timing issues running old SCO binary applications on new fast hardware.

    We still have a Xenix and an OSR 3.2v4.2 system in the rack in case I need
    to do some kind of hardware recovery, but neither of these has been booted
    in years.

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

    We contend that for a nation to try to tax itself into prosperity is like a
    man standing in a bucket and trying to lift himself up by the handle.
    -- Winston Churchill

  5. Re: Alternative to SCO

    On Oct 4, 3:26 pm, Jeff Liebermann wrote:
    > smlunatick hath wroth:
    >
    > >With the chapter 11 filing and other recommendations, what is a good,
    > >long time viable alternative to SCO OpenServer?

    >
    > For long term, probably a mainframe. It really depends on how you
    > long you consider long term and what you're doing with OpenServer. For
    > data dumpsters, I've been using NAS (network attached sewer). For
    > servers that require services and application servers, FreeBSD or
    > Windoze 2000/2003 server, depending on the service, application, and
    > religious mix. For desktops, mostly Windoze 2000 or XP, and a weird
    > mix of Linux mutations. There's no single solution that works for
    > everything.
    >
    > However, I have a question: Why do you consider chapter 11 to be
    > justification for a move from OSR5? I can see it if you're a software
    > developer and OpenServer is one of your target platforms. However, if
    > you're currently running OSR5, and it works, I don't see much reason
    > to switch to something else. I still have several 3.2v5.0.4
    > customers. Also one Xenix customer. I'm still running ODT 3.2v4.2 in
    > my office. Except for MMDF (which I'm too lazy to fix), everything
    > works just fine.
    >
    > --
    > Jeff Liebermann je...@cruzio.com
    > 150 Felker St #D http://www.LearnByDestroying.com
    > Santa Cruz CA 95060http://802.11junk.com
    > Skype: JeffLiebermann AE6KS 831-336-2558


    I have to disagree to some extent. Yes, there's no reason to dump a
    working system. However, this is far past the time when you should BE
    READY to dump it.

    You don't want to be flailing around at the last minute trying to
    figure out what to do. Start investigating alternatives now, research
    at your leisure, and be ready to move under your terms. See

    http://aplawrence.com/OSR5/selfdefense.html
    http://aplawrence.com/Blog/B831.html

    I also have a small pile of articles related to converting from SCO at
    http://aplawrence.com/cgi-bin/indexget.pl?Conversion



  6. Re: Alternative to SCO

    ------------------- clipped -------------------
    | Most of our servers have been running on Linux or FreeBSD for years (it's
    | not like the future of SCO hasn't been in doubt for at least five years).
    | Our first mission-critical Linux installation at a customer's was done in
    | September 1997, and we have been moving our customers from SCO Xenix and
    | OpenServer to Linux for the last decade, first Caldera, then SuSE, and
    | we're starting to use CentOS now. ^^^^

    Thread drift?

    Bill,

    What drives ones decision as to which version of Linux to use.
    Specifically with SuSE. Does having Novell behind the SuSE scene play
    any major factor in your decision process?

    TIA,
    - Jeff H
    ------------------- clipped -------------------

  7. Re: Alternative to SCO

    Jeff Hyman hath wroth:

    >------------------- clipped -------------------
    >| Most of our servers have been running on Linux or FreeBSD for years (it's
    >| not like the future of SCO hasn't been in doubt for at least five years).
    >| Our first mission-critical Linux installation at a customer's was done in
    >| September 1997, and we have been moving our customers from SCO Xenix and
    >| OpenServer to Linux for the last decade, first Caldera, then SuSE, and
    >| we're starting to use CentOS now. ^^^^
    >
    >Thread drift?


    You expected this to remain on topic? Surely you jest. Even the
    mention of Linux is guaranteed to create a flame war over a multitude
    of ever expanding topics. All I wanted to know is why SCO Chapter 11
    constitutes sufficient justification for abandoning OSR5, and nobody
    has addressed that question directly.

    >Bill,
    > What drives ones decision as to which version of Linux to use.
    >Specifically with SuSE. Does having Novell behind the SuSE scene play
    >any major factor in your decision process?


    I'm not Bill, but I do have a comment. The choice of operating system
    is not mine. Even with Linux, it's the applications vendor that
    forces the choice. Few commerical vendors will suppport every known
    Linux mutation available (in a multitude of languages). For self
    defense and to keep things sane, most will support one or two Linux
    mutations and then only on specific platforms. If Novell goes out of
    its way to make the application vendors happy, then they get
    supported. If Novell can effectively remove part of the support load
    from the applications vendor, then even better. However, if Novell
    waits for the applications vendor to do everything, then SUSE ends up
    looking like an expensive alternative to what would normally be a
    "free" operating system.

    Things are a bit different for transplanting applications from OSR5 to
    one of the Linux mutations. In my case, the applications are all dead
    or unupported. No new versions are available unless the customer
    wants to go to Windoze. Moving applications is all seat of the pants
    hacking. OS vendor support is useful, but not terribly interesting to
    my very small customers.

    I'll keep my opinions on the various Linux mutations to myself for
    fear of creating additional topic drift.

    --
    Jeff Liebermann jeffl@cruzio.com
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  8. Re: Alternative to SCO

    On Fri, 2007-10-05 at 13:16 -0700, Bill Campbell wrote:
    > On Fri, Oct 05, 2007, Jeff Liebermann wrote:
    > >Jeff Hyman hath wroth:
    > >
    > >>------------------- clipped -------------------
    > >>| Most of our servers have been running on Linux or FreeBSD for years (it's
    > >>| not like the future of SCO hasn't been in doubt for at least five years).
    > >>| Our first mission-critical Linux installation at a customer's was done in
    > >>| September 1997, and we have been moving our customers from SCO Xenix and
    > >>| OpenServer to Linux for the last decade, first Caldera, then SuSE, and
    > >>| we're starting to use CentOS now. ^^^^
    > >>


    We still have a 3.2v5.0.5 system with a unibasic license and our
    application software; we plan to move everything to Centos 5.0, and have
    been experimenting with it since March of this year. I have never had
    any support I could be thankful toward from SCO, but I could thank many
    members of this list especially Jean-Pierre Radley for holding my hand.

    I am not much more than a user compared to most of you on this list, but
    have appreciated the many threads that I have used as tutorials. From
    my perspective it is very frustrating to not be able to have a stable
    supportable base. However, I finally realized that this is just part of
    'computer life'. As an owner of a small business I have always just
    been hoping I could pass the computer baton to someone else. I finally
    realized that was not going to happen when some of my Microsoft friends
    asked me to set up a mail server with dhcpd, and bind for one of their
    clients.

    In the past 2 years our firm has let expire all of our Wyse terminals
    and each was replaced with a cheap PC from Frys or garage sales with
    various assortments of Fedora. The cost of this equipment was cheaper
    than the purchase of refurbished Wyse Terminals. We use the Fedora
    systems as terminal interfaces for the SCO server using konsole along
    with a cups server for print jobs. In three years I have only had 2
    episodes where one PC at a time became disabled by a broken automatic
    update, and each case was fixed in less than 48 hours. We have a total
    of over 30 PC's. The servers use Centos 5.0 and the Desktops use
    versions of Fedora 4, 5, 6 or 7. The support lists for Fedora and
    Centos are almost as good as this one at least for my level of
    expertise.

    As a user/admin Unix/Linux is so much better than Windows for our
    purpose. I would sure like to encourage all of this list to be
    aggressive implementers of these opensource platforms.

    Greg Ennis








  9. Re: Alternative to SCO


    > Actually, it's easier to deal with the old systems. The main
    > advantage is the very small sizes of the OS and applications. For
    > example, the Xenix system fits in about 500MBytes, most of which is
    > data.


    Just to point out for those unfamiliar with Xenix, the OS itself is actually
    under 50, heck, under 10!. An entire Xenix filesystem can not even exceed
    512M, though you can have multiple 512M fs's mounted for a total system that
    exceeds 512M.

    However, a 320M Xenix system IS huge when you remember all the options you
    don't have for getting data off of a Xenix box.

    * Networking - nope. (it existed but I never saw a single box with it, just
    like the C compiler)

    * Serial (kermit/rz/sz not PPP, no networking!) - yes, but only at 9600
    unless you have a 3rd party serial card driver and card and the right kind
    of serial cable. Hopefully the box has a 3.5" floppy drive at least to copy
    gzip, rz, sz, and kermit onto the box in the first place, or else you are in
    for some real nostalgia using cu and %put or %take and learning how great we
    all hove it now that most communications protocols have built-in error
    detection, correction and/or retransmit, which cu put/take does not! Oh, and
    beware even if it is a 3.5" drive, it might well actually be a 720K drive
    not a 1.44M drive!

    * hd transplant to new hardware to continue to run xenix - if you can find a
    486-100 or slower box that actully runs, reliably. (think 20 year old dried
    out capacitors all out of spec making the circuit unstable at the very
    least, if not a fire hazard! Not kidding! Seen it! Caps out of spec, so
    voltage regulator circuit out of spec, cooked several parts of the board,
    dried up stickers on components and on circuit traces caught fire!).

    * hd transplant for linux to read - linux can mount xenix fs's but it can't
    parse xenix divvy tables to know where the fs's start & stop. Theoretically
    you can read the divvy table yourself while still in xenix and write down
    the numbers and calculate the offsets yourself manually and use dd in linux
    to extract the fs to a seperate file. If you can manage that then linux can
    loopback mount the extracted image files effortlessly. I never managed it
    but I think Bela once described the basic steps here.

    * hd to hd copy to create partitions or cpio files that linux CAN read - if
    you can find a hard drive small enough that an old 486-66 motherboard bios
    can even see it.

    * tar/cpio to floppies - yep, that works. You need to know how to reassemble
    sco's multi-volume tar files unless you happen to be restoring onto a newer
    sco os instead of linux or freebsd. It's not conceptually hard, but is
    incredibly tedious and thus prone to human error, but a simple script can
    and has been written to automate that. So the only problem is that it's
    almost impossible to write to 200 floppies and read from them and have not
    one of them turn out corrupt. An you must be ok with spending a few solid
    hours feeding/swapping floppies into machines every couple minutes.

    ....hm... I could modify the sco-tar script so that it will retry any given
    volume and not proceed on to subsequent volumes until you say this one was
    OK, giving you a chance to throw away the bad floppy and regenerate the
    volume on the source machine instead of having to start the entire job over
    from the beginning. But is there a way to do the same thing on the source
    machine that is generating the volumes? Have it regenerate a given volume as
    many times as you ask, before proceeding on the the next, giving you a
    chance to read a volume and discover it's bad instead of having to start the
    entire job from the beginning. hm...

    * tape drive - if you can find working media for the ancient tape drive in
    the xenix box, and if that drive and it's controller card can then be moved
    and be installed on linux, or if you can install a newer drive on the xenix
    box.

    * cd burner - put down the Lagavulin.

    So, when faced with an old xenix box, you are actually faced with a pretty
    big problem getting that system off onto other hardware or OS in less time
    than a full weekend unless you are well prepred ahead of time with things
    you would have a hard time finding on short notice.

    Someone recently posted on this list that they worked out a recipe for
    taking a full xenix raw hd image and running it in a bochs or qemu emulator.
    I'm dying to try that. If that's possible, then that opens up a fast
    migration option by just taking the hard drive out of the xenix box and
    plugging into any linux box, dd an image of the whole disk in linux in no
    time. You could do it with a laptop and a usb drive enclosure and the drive
    could be cloned and right back into production in the old box in a few
    minutes if necessary. Then you get that working in linux at your leisure,
    then some other time update the clone and switch over to it for live
    production in as little as a few minutes.

    Brian K. White brian@aljex.com http://www.myspace.com/KEYofR
    +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
    filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!


  10. Re: Alternative to SCO

    On Fri, Oct 05, 2007, Brian K. White wrote:
    >
    >> Actually, it's easier to deal with the old systems. The main
    >> advantage is the very small sizes of the OS and applications. For
    >> example, the Xenix system fits in about 500MBytes, most of which is
    >> data.

    >
    >Just to point out for those unfamiliar with Xenix, the OS itself is actually
    >under 50, heck, under 10!. An entire Xenix filesystem can not even exceed
    >512M, though you can have multiple 512M fs's mounted for a total system that
    >exceeds 512M.


    That doesn't sound right. I think I've run 1GB SCSI hard drives
    on Xenix systems with file systems larger that 512Meg.

    >However, a 320M Xenix system IS huge when you remember all the options you
    >don't have for getting data off of a Xenix box.
    >
    >* Networking - nope. (it existed but I never saw a single box with it, just
    >like the C compiler)


    Most of the Xenix systems we installed from 1990 on had Xenix
    TCP/IP networking. Every one had the full Development system,
    starting with Radio Shack Xenix on the Model 16/6000 (it was the
    only way to get vi and the other basic tools :-).

    ....
    >* hd transplant to new hardware to continue to run xenix - if you can find a
    >486-100 or slower box that actully runs, reliably. (think 20 year old dried
    >out capacitors all out of spec making the circuit unstable at the very
    >least, if not a fire hazard! Not kidding! Seen it! Caps out of spec, so
    >voltage regulator circuit out of spec, cooked several parts of the board,
    >dried up stickers on components and on circuit traces caught fire!).


    I've found the easiest way usually is to mount the HD in an OSR5 box after
    enabling Xenix file systems.

    One can also install Adaptec SCSI controller in the Xenix box, and back up
    to a SCSI tape. This only works with Xenix with SCSI support (all Tandy
    Xenix, and most later versions if I remember correctly).

    ....
    >So, when faced with an old xenix box, you are actually faced with a pretty
    >big problem getting that system off onto other hardware or OS in less time
    >than a full weekend unless you are well prepred ahead of time with things
    >you would have a hard time finding on short notice.


    I've done a fair number of these, but it's been at least five years since I
    last did one. Of the available methods, I find that installing the Xenix
    hard disks in an OSR5 system the easiest and fastest.

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

    No matter how much I may exaggerate it, it must have a certain amount of
    truth...Now rumor travels fast but it don't stay put as long as truth
    Will Rogers

  11. Re: Alternative to SCO

    In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
    Brian K. White wrote:

    >> Actually, it's easier to deal with the old systems. The main
    >> advantage is the very small sizes of the OS and applications. For
    >> example, the Xenix system fits in about 500MBytes, most of which is
    >> data.


    >Just to point out for those unfamiliar with Xenix, the OS itself
    >is actually under 50, heck, under 10!. An entire Xenix filesystem
    >can not even exceed 512M, though you can have multiple 512M fs's
    >mounted for a total system that exceeds 512M.


    Actually less than that. I had one site with seven Xenix systems
    running on Tandy 3000's - 286 machines - that had 20MB HDs and we
    had a lot of room left for the data - word processor, spread sheet,
    filepro, and ?? [forgot what the 4th major ap was]

    My first Xenix [on a 16] had a 76K [ that's K ] kernel.

    Bill
    --
    Bill Vermillion - bv @ wjv . com

  12. Re: Alternative to SCO

    On Sat, Oct 06, 2007, Bill Vermillion wrote:
    >In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
    >Brian K. White wrote:
    >
    >>> Actually, it's easier to deal with the old systems. The main
    >>> advantage is the very small sizes of the OS and applications. For
    >>> example, the Xenix system fits in about 500MBytes, most of which is
    >>> data.

    >
    >>Just to point out for those unfamiliar with Xenix, the OS itself
    >>is actually under 50, heck, under 10!. An entire Xenix filesystem
    >>can not even exceed 512M, though you can have multiple 512M fs's
    >>mounted for a total system that exceeds 512M.

    >
    >Actually less than that. I had one site with seven Xenix systems
    >running on Tandy 3000's - 286 machines - that had 20MB HDs and we
    >had a lot of room left for the data - word processor, spread sheet,
    >filepro, and ?? [forgot what the 4th major ap was]
    >
    >My first Xenix [on a 16] had a 76K [ that's K ] kernel.


    The first Xenix for the Tandy Model 16 came on 3 8 inch 640k floppies with
    the Development system on another. The first hard drives for the Model
    II/16 systems were 8 Meg, and Xenix installed with enough room left to
    actually do some work.

    I did a few classes on Xenix for other Radio Shack managers in the D.C.
    area, telling the managers that they had time to read the Tandy manual
    while the disks were loading.

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

    Virtually everything is under federal control nowadays except the
    federal budget. -- Herman E. Talmadge, 1975

  13. Re: Alternative to SCO

    In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
    Brian K. White wrote:
    >
    >* cd burner - put down the Lagavulin.
    >

    Why on earth would I want to do this? Unless your asking me to
    pick up a dramm of Macallans 25.



    Sorry, couldn't resist!

    Dave

  14. Re: Alternative to SCO

    In article ,
    Bill Campbell wrote:
    >On Sat, Oct 06, 2007, Bill Vermillion wrote:
    >>In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
    >>Brian K. White wrote:
    >>
    >>>> Actually, it's easier to deal with the old systems. The main
    >>>> advantage is the very small sizes of the OS and applications. For
    >>>> example, the Xenix system fits in about 500MBytes, most of which is
    >>>> data.

    >>
    >>>Just to point out for those unfamiliar with Xenix, the OS itself
    >>>is actually under 50, heck, under 10!. An entire Xenix filesystem
    >>>can not even exceed 512M, though you can have multiple 512M fs's
    >>>mounted for a total system that exceeds 512M.

    >>
    >>Actually less than that. I had one site with seven Xenix systems
    >>running on Tandy 3000's - 286 machines - that had 20MB HDs and we
    >>had a lot of room left for the data - word processor, spread sheet,
    >>filepro, and ?? [forgot what the 4th major ap was]


    >>My first Xenix [on a 16] had a 76K [ that's K ] kernel.


    >The first Xenix for the Tandy Model 16 came on 3 8 inch 640k floppies with
    >the Development system on another. The first hard drives for the Model
    >II/16 systems were 8 Meg, and Xenix installed with enough room left to
    >actually do some work.


    Hm. I remember they had a SD boot track and then went to DD for
    about 1MB/disk. I actually had one with the 8 inch 8MB HD - I
    think the drive was a Shugart SA-400. Am I mis-remebering.
    The first Xenix was a 1.x.x system - I even have an orignal
    unopened package of one of those. When compiling you could
    take the Unix codes with the system defs and tell it that it
    was a CSRG system [that's the group that basically wrote BSD] and
    it would compile cleanly.

    When they went to the 3.x system it was sort of a hybrid with
    many things from Unix System III - and I actually prefred the old
    ones. Going to FreeBSD was like going 'back home' to the old
    16 with the 1.x.x series.

    >I did a few classes on Xenix for other Radio Shack managers in the D.C.
    >area, telling the managers that they had time to read the Tandy manual
    >while the disks were loading.


    I guess that would depend upon the manual.

    As to applications the Unify manuals from Tandy/RS were an
    excellent tutorial on data-base design and SQL.

    Bill

    --
    Bill Vermillion - bv @ wjv . com

  15. Re: Alternative to SCO

    On Sun, Oct 07, 2007, Bill Vermillion wrote:
    >In article ,
    >Bill Campbell wrote:
    >>On Sat, Oct 06, 2007, Bill Vermillion wrote:
    >>>In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
    >>>Brian K. White wrote:
    >>>
    >>>>> Actually, it's easier to deal with the old systems. The main
    >>>>> advantage is the very small sizes of the OS and applications. For
    >>>>> example, the Xenix system fits in about 500MBytes, most of which is
    >>>>> data.
    >>>
    >>>>Just to point out for those unfamiliar with Xenix, the OS itself
    >>>>is actually under 50, heck, under 10!. An entire Xenix filesystem
    >>>>can not even exceed 512M, though you can have multiple 512M fs's
    >>>>mounted for a total system that exceeds 512M.
    >>>
    >>>Actually less than that. I had one site with seven Xenix systems
    >>>running on Tandy 3000's - 286 machines - that had 20MB HDs and we
    >>>had a lot of room left for the data - word processor, spread sheet,
    >>>filepro, and ?? [forgot what the 4th major ap was]

    >
    >>>My first Xenix [on a 16] had a 76K [ that's K ] kernel.

    >
    >>The first Xenix for the Tandy Model 16 came on 3 8 inch 640k floppies with
    >>the Development system on another. The first hard drives for the Model
    >>II/16 systems were 8 Meg, and Xenix installed with enough room left to
    >>actually do some work.

    >
    >Hm. I remember they had a SD boot track and then went to DD for
    >about 1MB/disk. I actually had one with the 8 inch 8MB HD - I
    >think the drive was a Shugart SA-400. Am I mis-remebering.
    >The first Xenix was a 1.x.x system - I even have an orignal
    >unopened package of one of those. When compiling you could
    >take the Unix codes with the system defs and tell it that it
    >was a CSRG system [that's the group that basically wrote BSD] and
    >it would compile cleanly.


    I don't think I ever had one of the 8 inch drives open. I do
    remember that they were easy to destroy by forgetting to remove
    the drive locking screw from the bottom before applying power.
    They also chirped when moving the heads.

    The first version of Xenix sold by Tandy was the original
    Microsoft port (they did once do a real operating system in
    Redmond :-). It had a fair number of BSDish tools including the
    vi editor and csh. I think that Microsoft handed off all Xenix
    development to SCO for hardware other than IBM manufactured PCs,
    but I don't know whether this included the Motorola 68000 based
    Model 16/6000 machines.

    >When they went to the 3.x system it was sort of a hybrid with
    >many things from Unix System III - and I actually prefred the old
    >ones. Going to FreeBSD was like going 'back home' to the old
    >16 with the 1.x.x series.
    >
    >>I did a few classes on Xenix for other Radio Shack managers in the D.C.
    >>area, telling the managers that they had time to read the Tandy manual
    >>while the disks were loading.

    >
    >I guess that would depend upon the manual.


    The one that came from Radio Shack was minimal to say the least.

    >As to applications the Unify manuals from Tandy/RS were an
    >excellent tutorial on data-base design and SQL.


    I still have Unify manuals, but the ones from Unify, not Tandy's,
    and have to refer to them occassionally as we're still supporting
    applications written around the Unify RDBMS, built for 3.2v4 Unix.

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

    Windows is a computer virus with a user interface!!

  16. Re: Alternative to SCO

    "Brian K. White" hath wroth:

    >> Actually, it's easier to deal with the old systems. The main
    >> advantage is the very small sizes of the OS and applications. For
    >> example, the Xenix system fits in about 500MBytes, most of which is
    >> data.


    >Just to point out for those unfamiliar with Xenix, the OS itself is actually
    >under 50, heck, under 10!. An entire Xenix filesystem can not even exceed
    >512M, though you can have multiple 512M fs's mounted for a total system that
    >exceeds 512M.
    >
    >However, a 320M Xenix system IS huge when you remember all the options you
    >don't have for getting data off of a Xenix box.


    Oh swell, looks like the Xenix FAQ page has a problem:


    Bill Campbell covered most of the issues I have with your statements.
    Most of my earlier Xenix systems had TCP/IP installed, which makes
    data migrations very easy. For those that did not, I would
    temporarily install TCP/IP, copy everything off via ethernet, and then
    retire the old system. I did transplant one Xenix system via serial
    port using Kermit at 9600 baud. After that overnight experience, I
    vowed never to do that again.

    However, you seem to have missed my original point. The small size of
    the older Xenix, ODT, and even OSR5 systems, makes whole disk image
    backups very easy. By implication, that also makes OS transplants
    fairly easy, because unlike todays feature infested operating systems,
    the older systems were constrained by limited disk space. I have a
    CDROM (somewhere) with cpio copies of about a dozen old Xenix systems.
    Small is beautiful.

    Incidentally, my last Xenix system has only 8MBytes of ram. I think
    16MBytes is the maximum that Xenix will address. My ODT 3.2v4.2 has
    16MBytes. By contrast, my latest Ubuntu server has 4GigaBytes, where
    the RAM cost about the same as what the 8MBytes cost my back in the
    late 1980's.

    My last remaining Xenix customer has a Wangtek DC-6150 tape drive
    installed. It died perhaps 5 years ago and was not replaced. Instead,
    I do nightly ftp backups over the network via TCP/IP to a Windoze
    server. It was initially a problem because of Xenix TCP/IP inadequate
    streams buffers problems. Rather than fix it on the Xenix end, I just
    found a Windoze FTP client that would would retry until the buffers
    cleared without timing out. Crude, but functional.

    About once a year, I do a full cpio backup just in case the house of
    cards collapses early. So far, so good.



    --
    Jeff Liebermann jeffl@cruzio.com
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  17. Re: Alternative to SCO

    On Oct 5, 2:27 am, smlunatick wrote:
    > With the chapter 11 filing and other recommendations, what is a good,
    > long time viable alternative to SCO OpenServer?


    You assume Chapter11 is the end of the Operating Systems. It may be
    the end of the litigation, I am thinking that probably the OS will
    soldier on under a new company hopefully with different goals and
    priorities. Depending on how comfortable you are with SCO systems and
    your software you use on it then I see no reason to change unless the
    system you are moving to gives you something you need that you simply
    cant do on your SCO platform.

    If you were putting in a brand new system then the field is open but
    why change something you already have unless there is an actual
    business case to do so.

    Regards

    James


  18. Re: Alternative to SCO

    On Sun, Oct 07, 2007, Jeff Liebermann wrote:
    >"Brian K. White" hath wroth:
    >
    >>> Actually, it's easier to deal with the old systems. The main
    >>> advantage is the very small sizes of the OS and applications. For
    >>> example, the Xenix system fits in about 500MBytes, most of which is
    >>> data.

    >
    >>Just to point out for those unfamiliar with Xenix, the OS itself is actually
    >>under 50, heck, under 10!. An entire Xenix filesystem can not even exceed
    >>512M, though you can have multiple 512M fs's mounted for a total system that
    >>exceeds 512M.
    >>
    >>However, a 320M Xenix system IS huge when you remember all the options you
    >>don't have for getting data off of a Xenix box.

    >
    >Oh swell, looks like the Xenix FAQ page has a problem:
    >
    >
    >Bill Campbell covered most of the issues I have with your statements.
    >Most of my earlier Xenix systems had TCP/IP installed, which makes
    >data migrations very easy. For those that did not, I would
    >temporarily install TCP/IP, copy everything off via ethernet, and then
    >retire the old system. I did transplant one Xenix system via serial
    >port using Kermit at 9600 baud. After that overnight experience, I
    >vowed never to do that again.


    If you really want to see slow, try the fptransfer program with
    Profile16/FilePro. I think it had a maximum transfer rate around 2,400
    baud regardless of the speed of the connection.

    >However, you seem to have missed my original point. The small size of
    >the older Xenix, ODT, and even OSR5 systems, makes whole disk image
    >backups very easy. By implication, that also makes OS transplants
    >fairly easy, because unlike todays feature infested operating systems,
    >the older systems were constrained by limited disk space. I have a
    >CDROM (somewhere) with cpio copies of about a dozen old Xenix systems.
    >Small is beautiful.
    >
    >Incidentally, my last Xenix system has only 8MBytes of ram. I think
    >16MBytes is the maximum that Xenix will address. My ODT 3.2v4.2 has
    >16MBytes. By contrast, my latest Ubuntu server has 4GigaBytes, where
    >the RAM cost about the same as what the 8MBytes cost my back in the
    >late 1980's.


    Most of the early x86 versions of Xenix I supported ran on 4MB on the Tandy
    4000s, and supported at least 4 dumb terminals. The cost to bring these to
    16MB in 1985 or so was close to $10,000, just for the RAM.

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

    Ah, you know the type. They like to blame it all on the Jews or the
    Blacks, 'cause if they couldn't, they'd have to wake up to the fact that
    life's one big, scary, glorious, complex and ultimately unfathomable
    crapshoot -- and the only reason THEY can't seem to keep up is they're a
    bunch of misfits and losers.
    -- A analysis of Neo-Nazis, from "The Badger" comic

  19. Re: Alternative to SCO

    Bill Campbell hath wroth:

    >If you really want to see slow, try the fptransfer program with
    >Profile16/FilePro. I think it had a maximum transfer rate around 2,400
    >baud regardless of the speed of the connection.


    Ummm.... no thanks.

    >Most of the early x86 versions of Xenix I supported ran on 4MB on the Tandy
    >4000s, and supported at least 4 dumb terminals. The cost to bring these to
    >16MB in 1985 or so was close to $10,000, just for the RAM.


    Well, let's do the math. As I recall, I was paying about $5/ea for
    256Kbit dynamic RAM chips. I don't think Tandy 4000 had a parity
    chip, so that's 32 chips per megabyte or $160/MByte, which sounds
    about right. However, 16MB would be only $2,560. That means you were
    using 64Kbit chips. As I recall, those were about $5/ea in 1985. So,
    that would be 4 times as expensive or $10,240 for 16MB. Yep.

    Just about everything in computing is now bigger, better, more feature
    infested. However, it's not faster. My 486 DX2/66 ODT 3.2v4.2 box is
    much faster than anything I'm running non later operating systems.
    Windoze is even worse as Vista trades an elaborate desktop for a huge
    drop in speed. One giant step forwards for hardware upgrades, one
    equally giant step backwards for usability.

    >Ah, you know the type. They like to blame it all on the Jews or the
    >Blacks, 'cause if they couldn't, they'd have to wake up to the fact
    >that life's one big, scary, glorious, complex and ultimately unfathomable
    >crapshoot -- and the only reason THEY can't seem to keep up is they're
    >a bunch of misfits and losers.
    > -- A analysis of Neo-Nazis, from "The Badger" comic


    My version is something like:

    The first step to solving a problem is to blame someone. That's fine
    but a huge number of individuals and civilizations tend to get stuck
    on this first step, and never move on beyond this first step, even
    when succesful.
    Me, just now.

    --
    Jeff Liebermann jeffl@cruzio.com
    150 Felker St #D http://www.LearnByDestroying.com
    Santa Cruz CA 95060 http://802.11junk.com
    Skype: JeffLiebermann AE6KS 831-336-2558

  20. Re: Alternative to SCO

    On Sun, Oct 07, 2007, Jeff Liebermann wrote:
    >Bill Campbell hath wroth:
    >
    >>If you really want to see slow, try the fptransfer program with
    >>Profile16/FilePro. I think it had a maximum transfer rate around 2,400
    >>baud regardless of the speed of the connection.

    >
    >Ummm.... no thanks.
    >
    >>Most of the early x86 versions of Xenix I supported ran on 4MB on the Tandy
    >>4000s, and supported at least 4 dumb terminals. The cost to bring these to
    >>16MB in 1985 or so was close to $10,000, just for the RAM.

    >
    >Well, let's do the math. As I recall, I was paying about $5/ea for
    >256Kbit dynamic RAM chips. I don't think Tandy 4000 had a parity
    >chip, so that's 32 chips per megabyte or $160/MByte, which sounds
    >about right. However, 16MB would be only $2,560. That means you were
    >using 64Kbit chips. As I recall, those were about $5/ea in 1985. So,
    >that would be 4 times as expensive or $10,240 for 16MB. Yep.


    I'm pretty sure the Tandy 4000 did have parity checking. I seem
    to remember that most machines did until the early '90s or so
    (Bela may have a better handle on this).

    >Just about everything in computing is now bigger, better, more feature
    >infested. However, it's not faster. My 486 DX2/66 ODT 3.2v4.2 box is
    >much faster than anything I'm running non later operating systems.
    >Windoze is even worse as Vista trades an elaborate desktop for a huge
    >drop in speed. One giant step forwards for hardware upgrades, one
    >equally giant step backwards for usability.


    I've been very impressed with Apple's OS X. Every release I've
    used in the last 6 years has actually seemed faster than the
    previous releases, and they maintain backwards compatibility with
    older hardware. I can run OS X 10.4.x without too much pain on
    my old 450MhZ G4 tower, including fairly fancy graphics.

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

    Freedom from prices is freedom from responsibility. You can simply pass
    laws, using the magic wand of government to satisfy your own desires at
    unspecified costs to be paid by others. -- Thomas Sowell Aug 2000

+ Reply to Thread
Page 1 of 2 1 2 LastLast