Alternative to SCO
smlunatick
long time viable alternative to SCO OpenServer?
ThreeStar
> With the chapter 11 filing and other recommendations, what is a good,
> long time viable alternative to SCO OpenServer?
Daytimer.
Jeff Liebermann
>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 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Bill Campbell
>smlunatick <yve...@gmail.com> 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: bi...@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
Tony Lawrence
> smlunatick <yves...@gmail.com> hath wroth:
> 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
Jeff Hyman
| 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
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 -------------------
Jeff Liebermann
>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.
Let's go through the current excuses for my customers still old
hardware and software:
1. The business is being sold. This is not a good time for changes.
2. I'm ready to retire. Let my kids decide what they want to do.
3. Business sucks. I don't have the money to do anything more than
tread water.
4. The current stuff works for us. We don't need anything better.
5. Moving applications from a terminal to a desktop means all new
desktops (and wiring) for everyone. Maybe later.
There are a few others, but that's roughly what's stopping any
upgrades. Incidentally, I also keep two Novell 3.1 servers alive.
There's no question that all of these customers should kicked into the
21st century, but I don't run their business or make their decisions.
I could go on strike and refuse to work on the old junk, or raise my
rates for old junk, but I won't do that.
>You don't want to be flailing around at the last minute trying to
>figure out what to do.
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. My ODT3 box is only 1.5GBytes, most of which is spam. The
typical 3.2v5.0.x system is running about 2GBytes, again mostly data.
I backup these as image files to portable NAS drive dumpster. If I
need to do "maintenance", I just restore the image file. Old hardware
is always a problem, but I disposed of the exotic cards and
controllers long ago. Most of these systems have a backup machine
sitting nearby waiting for an image reload. I don't like doing it
this way, but it does get the system back online quickly.
>Start investigating alternatives now, research
>at your leisure, and be ready to move under your terms.
Around 2001, I scribbled quotes for replacement hardware and software
to each of my SCO Unix/Xenix customers. I gave everyone the choice of
a Windoze or Linux upgrade path. I revise these quotes regularly as
things change. I've done trial application transplants to Linux and
found numerous surprises and complications (bbx4 runtimes). My
remaining customers are well aware of the costs and alternatives.
However, it's their decision and I won't force them into doing
anything.
>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
Very nice. I wish I had known about those when I was trying to
transplant various SCO applications to Linux. However, I don't think
any of it will be used by me. If history repeats itself, most of my
customers will choose the Windoze path because they have existing
Windoze machines. That implies that the SCO applications will be
replaced rather than transplanted to a new operating system.
--
Jeff Liebermann je...@cruzio.com
150 Felker St #D http://www.LearnByDestroying.com
Santa Cruz CA 95060 http://802.11junk.com
Skype: JeffLiebermann AE6KS 831-336-2558
Jeff Liebermann
>------------------- 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.
Bill Campbell
>Jeff Hyman <sco...@cactus.com> 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.
My answer to that is that the demise of SCO would probably end any
development to support newer hardware necessary to replace machines that
die of old age.
It has been increasingly difficult to support new things on OSR5 as it has
not kept up with the times, particularly in the areas of networking (try to
get something like openvpn working on SCO without tun and tap interfaces).
The OSR5 systems we support are basically islands on the network with do a
single job with other systems handling everything outside the application
running on OSR5.
I'm no stranger to running open source applications on SCO systems. Our
ftp site, ftp.celestial.com, was a major source of open source software
compiled for Xenix and OSR5 for well over a decade. At this point though,
it's very rare that I tackle updating existing ports on OSR5 since it's
generally a royal PITA.
>>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.
My biggest gripe with Novell, as I said in a private reply to Jeff, is that
Novell isn't providing much support, even to their ``Partners'' who have
made fairly major committments to Novell to sell SuSE Linux Enterprise
systems.
Of course this should be familiar to SCO customers as well. The only
answers and support I ever got to questions from SCO was through back
channels with people I knew well,
>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.
It's hell being a bottom feeder, dealing with the small customers who just
want things to work without spending any money :-). Fortunately one of our
customers who was running an unsupported FilePro application with custom
code, compiled for 80286 Xenix, retired recently, so I don't have to worry
about dealing with that any longer.
Bill
--
INTERNET: bi...@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
Many citizens because of their respect for what only appears to be a law
are cunningly coerced into waiving their rights due to ignorance.
-- U.S. v. Minker
Gregory P. Ennis
> On Fri, Oct 05, 2007, Jeff Liebermann wrote:
> >Jeff Hyman <sco...@cactus.com> 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
Brian K. White
> 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 br...@aljex.com http://www.myspace.com/KEYofR
+++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++.
filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
Bill Campbell
>
>> 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: bi...@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
Bill Vermillion
Brian K. White <br...@aljex.com> 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
Bill Campbell
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: bi...@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
David Gresham
>
pick up a dramm of Macallans 25.
Sorry, couldn't resist!
Dave
Bill Vermillion
Bill Campbell <bi...@celestial.com> wrote:
>On Sat, Oct 06, 2007, Bill Vermillion wrote:
>>In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
>>Brian K. White <br...@aljex.com> 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 Campbell
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: bi...@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!!
Jeff Liebermann
>> 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:
<http://www.unicom.com/pw/faq/sco-xenix.faq>
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.
<http://www.whispertech.com/surfer/download.htm>
About once a year, I do a full cpio backup just in case the house of
cards collapses early. So far, so good.
James_Szabadics
> 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
Bill Campbell
>"Brian K. White" <br...@aljex.com> 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:
><http://www.unicom.com/pw/faq/sco-xenix.faq>
>
>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: bi...@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
Jeff Liebermann
>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.
Bill Campbell
>
>>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: bi...@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
Brian K. White
----- Original Message -----
From: "David Gresham" <gre...@panix.com>
Newsgroups: comp.unix.sco.misc
To: <dis...@jpr.com>
Sent: Saturday, October 06, 2007 12:48 PM
Subject: Re: Alternative to SCO
> In article <00cf01c807c7$f39bf5f0$6800000a@venti>,
> Brian K. White <br...@aljex.com> 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
----- Original Message -----
From: "Bill Campbell" <bi...@celestial.com>
Newsgroups: comp.unix.sco.misc
To: <sco-...@lists.celestial.com>
Sent: Monday, October 08, 2007 2:26 AM
Subject: Re: Alternative to SCO
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.
Bill Vermillion
I traded that in to Bob Snapp for a Rodime 35MB drive.
>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.
That's because it was more like pre System III than the 3.x
version. As I had mentioned you could compile almost anything
by defining it as a CSRG system - which is pure BSD.
>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.
I have/had an old [really old] price-list from SCO that had
a lot of cross-development tools for many many processors - most
of which would be unknown to anyone who came to computing in the
last 15-20 years. :-) They also some applications for other
systems, and also had Xenix for Apples' LISA.
>>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.
I guess you mean that 'thin' manual that came with the original
distribution diskettes. Yup. That was really small. But I had
acquired copies/reprints of the original Bell Labs version 7
manuals before I got my RS Xenix system, so I never worried too
much about that manual.
>>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.
The Tandy manuals were really good - and seemed almost to be Unify
reprints. Those were the ones in the big 8.5x11" manuals. An
upgrade to Unify went from 2 manuals to 3 manuals in the smaller
format that IBM moved to - 5.5x8.5" [approx]. Still they were some
of the best manuals that RS ever shipped IMO.
I learned the Unify when a client did not take my recommendations
for a really good used system with Wyse 50 terminals, and went for
a NEW model 6000 system from the local RS manager and filePro.
But that version of filePro did not run on the new 6000s. I talked
to the manager and had him verify with Tandy HQ and he called back
and verfied that was true.
So we went to Unify. And then since the owner had gotten the
Radio-Shack/Tandy terminals [sort of Vt100s as I recall] there were
problems with the termcvaps when the user would use a certain
keystroke in Unify it would change the terminal setting.
I sent all the detail to Ft.Worth[less] and wanted them to fix the
termcap. They couldn't after two weeks, so we got the Wyse50s
from Lee and everything worked well.
From that point on the owner trusted what I said and NOT what
RS said - as they had led him down the wrong path too many times.
And of course with the Tandy/RS return policy the money he got
for the 3 terminals form them bought 4 Wyse 50s'.
The worst part of the whole system conversion was from Snapp's
BASIC that didn't have error checking because the local programmer
didn't understand that, so trying to figure out if the
date [allocated 6 digits but not required] was if 12389 was
January 23 1989 or December 3, 1989. I don't know how many of
those I stumbled upon when moving the data from that program
to Unify. A true learhning experience. :-) and :-(
Bill Vermillion
>>> 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:
><http://www.unicom.com/pw/faq/sco-xenix.faq>
>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. ....
>Incidentally, my last Xenix system has only 8MBytes of ram.
My first - a discontinued 16 on a closeout 'whereis' special came
with 128K RAM as base. I did bump that up.
But running a usnet node meant I had to get everytihng in 13-bit
compressed format, as 16-bit would be so slow I'd get a new feed
before the first one uncomrpessed. Putting in Bob Snapp's 1MB
board as SWAP fixed that problem. The sysetem really flew
with the RAM based swapped compared to the really slow access
[compared to today's drives] of those drive from the mid-1980s.
>I think 16MBytes is the maximum that Xenix will address.
Correct. I had a client who hated to pay money except when he had
too, and I got called in and saw there was 32MB or RAM in the
machine. I asked him who put that in. He said he did and thought
32MB would be good. I told him he wasted his money on the extra
RAM and that the top 16MB were doing nothing but using electricity
and creating a small amount of heat. Some people really do make
money for the rest of us by doing things on their own that they
have no idea of what the consequences will be.
Bill Vermillion
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 Vermillion
Jeff Liebermann <je...@cruzio.com> 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."
Brian K. White
----- Original Message -----
From: "Jeff Liebermann" <je...@cruzio.com>
Newsgroups: comp.unix.sco.misc
To: <dis...@jpr.com>
Subject: Re: Alternative to SCO
> "Brian K. White" <br...@aljex.com> 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:
> <http://www.unicom.com/pw/faq/sco-xenix.faq>
>
> 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.
Walter Vaughan
> Correct. I had a client who hated to pay money except when he had
> too, and I got called in and saw there was 32MB or RAM in the
> machine.
Today's evilness is selling a x86 server with exactly 4 gig of memory. Of course
it runs like crap with either a 32bit or 64 bit version of an OS. It's almost as
if it's a goverment works program...
--
Walter
Dan Martin
> Bill Vermillion wrote:
> > Correct. I had a client who hated to pay money except when he had
> > too, and I got called in and saw there was 32MB or RAM in the
> > machine.
>
> Today's evilness is selling a x86 server with exactly 4 gig of memory. Of course
> it runs like crap with either a 32bit or 64 bit version of an OS.
How so? What is the relationship to 32 and 64 bit os vis a vis 4 GB
RAM ? (I'm evil without knowing it!)
Regards,
Dan Martin
Bill Vermillion
Dan Martin <dc.m...@verizon.net> wrote:
>On Oct 9, 9:17 am, Walter Vaughan <wvaug...@steelerubber.com> wrote:
>> Bill Vermillion wrote:
>> > Correct. I had a client who hated to pay money except when he had
>> > too, and I got called in and saw there was 32MB or RAM in the
>> > machine.
>>
>> Today's evilness is selling a x86 server with exactly 4 gig of memory. Of course
>> it runs like crap with either a 32bit or 64 bit version of an OS.
>
>How so? What is the relationship to 32 and 64 bit os vis a vis 4 GB
>RAM ? (I'm evil without knowing it!)
>Regards,
>Dan Martin
I've seen the reported problem on some email lists I get. One
thing on the x86 platforms is to run PAE on the machine.
You get a bit under 4GB with it.
I also have seen reports that some of the latest Intel boards
have a problem with 4GB on some operating systems [I was this
on a FreeBSD mailing list].
Gary R. Schmidt
Strange, my 64-bit OS runs happily on 4Gig of RAM. What one(s) don't?
Cheers,
Gary B-)
--
______________________________________________________________________________
Armful of chairs: Something some people would not know
whether you were up them with or not
- Barry Humphries
Jeff Liebermann
>Walter Vaughan wrote:
>> Bill Vermillion wrote:
>>> Correct. I had a client who hated to pay money except when he had
>>> too, and I got called in and saw there was 32MB or RAM in the
>>> machine.
>> Today's evilness is selling a x86 server with exactly 4 gig of memory.
>> Of course it runs like crap with either a 32bit or 64 bit version of an
>> OS. It's almost as if it's a goverment works program...
>Strange, my 64-bit OS runs happily on 4Gig of RAM. What one(s) don't?
> Cheers,
> Gary B-)
"Not All Physical Memory May Be Reported By The Operating System On
Certain HP ProLiant Servers"
<http://h20000.www2.hp.com/bizsupport/TechSupport/Document.jsp?objectID=PSD_EL041214_CW01>
<http://support.intel.com/support/motherboards/server/sb/CS-010458.htm>
Note that this is from 2 years ago, when the problem was first
identified. It's really an old problem all over again at a higher
memory location. Some devices memory map themselves to sit above the
highest memory location. Some of the chips involved cannot do that
when either overlapping or sitting above 4GB.
Jeff Liebermann
>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.
I used WD8003 and 3C501 cards. I still have a small collection. The
Excelan cards never worked for me. I sold a few TCP/IP upgrades for
Xenix when they were available, they were for working systems. For
transplants, I just TEMPORARILY installed a card, loaded TCP/IP,
installed the updates, and moved the programs and data. Not exactly
totally in compliance with the license, but quite expedient. I only
had one case where the customer kept the Xenix box running with the
"borrowed" TCP/IP license for more than about a month. The hard disk
conveniently died just before it became an issue.
>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.
Same here. I sold very few Xenix systems, but I inherited most of my
customers and systems, usually immediately after a hardware failure,
where the software vendor or VAR wanted an outrageous amount of money
to repair the system, or insisted on a massive upgrade. So, I would
throw together a reasonable system for much less, and continue to run
Xenix. However, I would also insist that communications and backup
systems were functional, which often involved some upgrades. When
dumping terminals in favor of networked PC's became popular, I sold
TCP/IP runtime "upgrades".
>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.
Ok, that's acceptable. I also won't claim to always be prepared.
However, given the choice of an overnight backup via RS-232 versus an
overnight shipment of card, media, and license, I would do both.
Strangely, I never had much difficulties getting obsolete product
licenses, but I'll admit that Xenix and later ODT TCP/IP were a
problem.
>I defy you to say that those
>things are easy to produce on the spot, today, by the average tech.
True. If I were to do this today, it would be difficult to find the
necessary parts and pieces, even in my own storage closet. These
days, I would remove the drive, cram it into an OSR5 box, enable the
Xenix filesystem, and extract the files directly. That avoids both
the TCP/IP treasure hunt, and the ancient serial solutions.
>I don't see what statements I made are questionable.
The max file system sizes. It's 1GB for Xenix SCSI but only 512MB for
IDE. The fire hazzard for old boards is a bit over the top. The
486-100 mentioned will not work. I've done all of the options you
mentioned (except the cd burner) and generally agree with your
observations. However, lacking any better alternatives, the HD mount,
serial, and floppy methods are good enough.
>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 have those manuals still on my bookshelf and can look them up. The
big problem was fixed timing loops that assumed the system was running
on a specific processor. I didn't work on too many 2.3.4 systems.
Most were previous versions upgraded to 2.3.3. That would work well
up to 486DX33 but failed badly at anything faster including 486DX2/66
or 486DX50. I considered the 486DX50 to be too fast for many
motherboards and avoided using it. A common problem (for me) was the
tape controllers not working on the faster machines.
>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.
Agreed, completely. I had one system where the backup instruction
included first punching the "turbo" button to slow mode. If that
didn't hang the machine, it was ok to proceed with the backup.
>I can't check what counter claims that faq link might make, since all it
>shows me is some perl code.
Yeah, the web page is busted. I'll bug Chip Rosenthal about it later.
>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.
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.
Brian K. White
> 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.
smlunatick
> 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.
Bill Campbell
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: bi...@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
John Schmidt
> 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
Gary R. Schmidt
HCL and you are laughing.
darko
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