Alternative to SCO - SCO

This is a discussion on Alternative to SCO - SCO ; ----- Original Message ----- From: "David Gresham" Newsgroups: comp.unix.sco.misc To: Sent: Saturday, October 06, 2007 12:48 PM Subject: Re: Alternative to SCO > In article , > Brian K. White wrote: >> >>* cd burner - put down the Lagavulin. ...

+ Reply to Thread
Page 2 of 2 FirstFirst 1 2
Results 21 to 31 of 31

Thread: Alternative to SCO

  1. Re: Alternative to SCO


    ----- Original Message -----
    From: "David Gresham"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Saturday, October 06, 2007 12:48 PM
    Subject: 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.


    Indeed. Finish salvaging a 15 year old xenix box that is only in such dire
    straits because the owner ignored sound advice which was given clearly,
    repeatedly, and years before any crisis happened when it would have been
    easy to perform... or have another sip... hm... You're right, I had the
    priorities all backwards. Now if only I _had_ some Lagavulin...

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


  2. Re: Alternative to SCO


    ----- Original Message -----
    From: "Bill Campbell"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Monday, October 08, 2007 2:26 AM
    Subject: 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.


    Just a few weeks ago I received a blue&white G3. 350mhz G3 with 512M of
    pc100 ram.
    The original macos8.6 was somehow a bit messed up. Would run fine for 15 or
    20 minutes, or 1 minute, then lock up. I installed openSUSE 10.2, then
    ubuntu7.04, and finally osx 10.4 on it on a "new" (old but not corrupt)
    drive. Both Linux's ran about as I'd expect running a current 2.6 kernel on
    350mhz 512ram instead of say a 2.2 kernel that more appropriately matches
    the age & the hardware. Even stripping away gnome/kde and using xfce it was
    still pretty slow but toerable. Though you live without things like a flash
    plugin as there isn't one ported to ppc. But OSX 10.4 not only istalled, not
    only supports every current bell & whistle, it's actually significantly
    faster than linux even without turning off any gui candy.

    I was impressed enough with Linux on it. Linux had bootable cd's with
    working recovery environments. I was able to boot suse's recovery mode which
    gave me a text environment with working automatic nic driver and dhcp, and
    the env included rsync and netcat so I was able to capture both files at the
    fs level with rsync and a whole raw disk image with dd piped to netcat to
    another box all nice and convenient before installing on a new bigger drive.
    And then I was able to copy the disk image back to a file on the new system
    and run the original macos 8.6 in a vm in linux (haven't trid that on osx
    but I imagine the means are there). Very pleased with how useful that
    recovery mode actually is. Then, as flat out great as that is, Ubuntu's live
    desktop mode worked and put that to shame.

    But I'm very impressed with how well the very latest osx runs on such an old
    machine.
    The only hitch so far is, I don't seem to be able to install open-office.
    The installer starts up and not much happens for a while and then it just
    dissapears.
    Oh well.

    The only thing that bugs me is, Why am I amazed that osx performs merely
    well enough not to want to throw the machine off the top of the building?
    I know, because I was there and did it myself, that it only takes 10 to 50
    mhz to do the actual work of being a simple desktop and web browser. It
    should be incredible, the bad way not the good way, that a 650% faster
    machine can barely tread water.

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


  3. Re: Alternative to SCO

    In article ,
    Bill Campbell wrote:
    >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.


    I find my 400Mhz G4 a bit slow compared to my 2.4Ghz FreeBSD
    machine :-). But at heart - underneath the 'pretty face' OS/X
    is alomst all FreeBSD based.

    Are you aware that the OpenGroup has OX/X 10.5 [aka Leopard]
    as a certified Unix OS - under the Unix 03 specifications.
    That's one of the first new Unix certifications in years from
    someone who was not certified as a Unix vendor previously.

    Bill

    --
    Bill Vermillion - bv @ wjv . com

  4. Re: Alternative to SCO

    In article ,
    Jeff Liebermann wrote:
    [and from Bill's sig]

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


    Gawd I've seen that SO often.

    But the when I work for someone they seem suprised that I know
    both HW and SW [as many in this NG do], and I tell them I can't
    look at SW and blame the HW person because I'd just be pointing a
    finger at myself.

    Which bring to mind one of George Morrow's classic quotes, "Never
    trust a programmer with a screwdriver."

    Bill

    --
    Bill Vermillion - bv @ wjv . com

  5. Re: Alternative to SCO


    ----- Original Message -----
    From: "Jeff Liebermann"
    Newsgroups: comp.unix.sco.misc
    To:
    Sent: Sunday, October 07, 2007 11:33 PM
    Subject: 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.


    Well it's fine that you were lucky enough to be dealing with Xenix when it
    was still possible to aquire the media kit and a working licence for xenix
    tcp/ip (Or Excelan for that matter). I wasn't.

    All boxes I've encountered have been end-user boxes supplied by long-gone
    vars that installed the minimum feature set and their software and whatever
    other 3rd party software was needed. And the first of these came (for me)
    after it was not possible to buy xenix tcp/ip. I supposed I could/should
    have tried to find a used copy on ebay or here or something just for this
    occasional reason but it never occured to me and besides I do know the other
    ways of getting the job done. I only said it could be a problem if you
    weren't prepared with things that would be hard to produce on the spot, not
    that there was no good way to do the job. I defy you to say that those
    things are easy to produce on the spot, today, by the average tech. But I do
    happen to already have the things that make it do-able, so for me it's not
    actually usually a problem. But thats just because, like you with the tcp/ip
    package, I just happen to have unix boxes that I can take down at will, drag
    on-site (as inconvenient as that is) if needed, and install hd's and tapes
    and special controllers into. I don't expect most people to have that lying
    around. For one thing, just the minimum osr5 license is kind of a lot to
    invest just for that. I happen to have nfr licenses so I'm neither guilty of
    over-installing some other license nor paid a lot for a rarely used tool,
    but again, thats just my good luck not something you can really just assume
    or expect.

    I don't see what statements I made are questionable.
    I definitely read somewhere, as in somewhere official like the 2" thick
    paper xenix386 2.3.4 manual, which was also the last version released so
    whatever was true there is still true, that a xenix fs cannot exceed 512M
    and that it can't see more than 16M of ram, and later in some driver readme
    or TA that the recommended fastest cpu was about 50mhz 486. I've seen it run
    ok on faster (only a little faster), I've also seen it flake out or lock up
    on faster. Sometimes it seemed to be ok on faster aslong as it wasn't
    stressed. It would idle indefinitely but try to do a backup and it'd lock.

    I can't check what counter claims that faq link might make, since all it
    shows me is some perl code.

    In any event, I trust my own eyes first, then official sources or sources
    that should know because they have access to the source (the xenix manual),
    and any other home grown faqs and collections of wisdom last.

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


  6. Re: Alternative to SCO


    > Sure, however I'm really only interested in making one point, which is
    > being mostly ignored. The older systems are smaller and therefore
    > transplants are easier to deal with. Exactly how one deals with these
    > older systems is dependent on circumstances and available tools.


    Can't disagree.
    One guy waited too long and we had to send the hd to Seagate. That was some
    grief, but that was the lest grief because then Seagate was able to send
    back a simple single cd that had everything.
    Not only was the entire root & /u filesystems a mere 150M cpio file, but
    that compressed to about a 19M cpio.bz2. They actually included 4 copies of
    everything all on the same cd and still had room.
    Uncompressed tar and cpio, and gzip compressed tar & cpio. (Nice of them,
    allows for CD damage)

    Of course from that point on it never takes more than a minute or two to
    handle the entire data set. Uploading 20 megs from my office to their osr
    507 box (which they already had for our software) took seconds, unpacking on
    their unix box took seconds, etc.

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


  7. Re: Alternative to SCO - Part 2

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


    Let me re-phrase this!!!

    We a mainly a custom programming company who also sells/maintain
    servers for our application at the customer locales. We usually
    recommend SCO OpenServer since it is usually stable and no one @ the
    customer will "play" inside it (unlike Windows 2003.) We now have a
    branch server at one of our clients tah is "dieing" and the
    administration will be replacing it. During the submission of quotes,
    most server hardware VARs are not recommending SCO (they even state
    that SCO is discontinued.) It is not a problem for our application
    since our "base" will work on most WIndows / Linux servers, besides
    SCO. This client has now heard that SCO is in chapter 11 and does
    not want any new server running SCO. Besides going to "mainframes"
    what is a good alternative to SCO OpenServer on Intel based servers.


  8. Re: Alternative to SCO - Part 2

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

    >
    >Let me re-phrase this!!!
    >
    >We a mainly a custom programming company who also sells/maintain
    >servers for our application at the customer locales. We usually
    >recommend SCO OpenServer since it is usually stable and no one @ the
    >customer will "play" inside it (unlike Windows 2003.) We now have a
    >branch server at one of our clients tah is "dieing" and the
    >administration will be replacing it. During the submission of quotes,
    >most server hardware VARs are not recommending SCO (they even state
    >that SCO is discontinued.) It is not a problem for our application
    >since our "base" will work on most WIndows / Linux servers, besides
    >SCO. This client has now heard that SCO is in chapter 11 and does
    >not want any new server running SCO. Besides going to "mainframes"
    >what is a good alternative to SCO OpenServer on Intel based servers.


    We have been using various release of SuSE Linux for that last
    six years or so, most recently SuSE Linux Enterprise 10. We're
    now using CentOS 5 for most of our new installations as the
    support we have gotten from SuSE as Partners has been poor.

    We have several systems running SCO OSR5 COFF binaries with
    linux-abi. The most recent version of Linux I've found that does
    this reliably (at all) is SuSE 9.0 Professional.

    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

    It is practically impossible to teach good programming style to
    students that have had prior exposure to BASIC: as potential
    programmers they are mentally mutilated beyond hope of
    regeneration. -- Dijkstra

  9. Re: Alternative to SCO - Part 2

    smlunatick wrote:
    > Besides going to "mainframes"
    > what is a good alternative to SCO OpenServer on Intel based servers.


    I've been *extraordinarily* happy with Solaris for x(86|64).

    JS


  10. Re: Alternative to SCO - Part 2

    John Schmidt wrote:
    > smlunatick wrote:
    >> Besides going to "mainframes"
    >> what is a good alternative to SCO OpenServer on Intel based servers.

    >
    > I've been *extraordinarily* happy with Solaris for x(86|64).
    >

    +1 here. Just make sure that the bits are of good quality and on the
    HCL and you are laughing.

    Cheers,
    Gary B-)

    --
    __________________________________________________ ____________________________
    Armful of chairs: Something some people would not know
    whether you were up them with or not
    - Barry Humphries

  11. Re: Alternative to SCO - Part 2

    On Oct 12, 3:40 pm, "Gary R. Schmidt" wrote:
    > John Schmidt wrote:
    > > smlunatick wrote:
    > >> Besides going to "mainframes"
    > >> what is a good alternative to SCO OpenServer on Intel based servers.

    >
    > > I've been *extraordinarily* happy with Solaris for x(86|64).

    >
    > +1 here. Just make sure that the bits are of good quality and on the
    > HCL and you are laughing.
    >
    > Cheers,
    > Gary B-)
    >
    > --
    > __________________________________________________ ____________________________
    > Armful of chairs: Something some people would not know
    > whether you were up them with or not
    > - Barry Humphries



    And +1 here :-) Very reliable and fairly simple to setup, if you have
    the right hardware. Solaris x64 is supported by many major software
    vendors now (Oracle, IBM,...).

    Among Linuxes, SuSE 9.0 Pro and SLES 8 & 9 are my favourites.

    Darko Krstic


+ Reply to Thread
Page 2 of 2 FirstFirst 1 2