>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.
On Thu, Oct 04, 2007, Jeff Liebermann wrote: >smlunatick <yves...@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: b...@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
> >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.
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
------------------- 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 -------------------
>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.
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.
>------------------- 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.
On Fri, Oct 05, 2007, Jeff Liebermann wrote: >Jeff Hyman <scol...@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: b...@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
On Fri, 2007-10-05 at 13:16 -0700, Bill Campbell wrote: > On Fri, Oct 05, 2007, Jeff Liebermann wrote: > >Jeff Hyman <scol...@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.
> 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!
>> 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: b...@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
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.
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.
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: b...@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
>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.
On Sun, Oct 07, 2007, Bill Vermillion wrote: >In article <mailman.9.1191687791.2682.sco-m...@lists.celestial.com>, >Bill Campbell <b...@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.
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: b...@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!!
>> 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.
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.
On Oct 5, 2:27 am, smlunatick <yves...@gmail.com> 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.
On Sun, Oct 07, 2007, Jeff Liebermann wrote: >"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.
>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: b...@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
>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.
On Sun, Oct 07, 2007, Jeff Liebermann wrote: >Bill Campbell <b...@celestial.com> 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: b...@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
----- Original Message ----- From: "David Gresham" <gres...@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 br...@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
----- Original Message ----- From: "Bill Campbell" <b...@celestial.com>
Newsgroups: comp.unix.sco.misc To: <sco-m...@lists.celestial.com> Sent: Monday, October 08, 2007 2:26 AM Subject: Re: Alternative to SCO
> On Sun, Oct 07, 2007, Jeff Liebermann wrote: >>Bill Campbell <b...@celestial.com> 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 br...@aljex.com http://www.myspace.com/KEYofR +++++[>+++[>+++++>+++++++<<-]<-]>>+.>.+++++.+++++++.-.[>+<---]>++. filePro BBx Linux SCO FreeBSD #callahans Satriani Filk!
>On Sun, Oct 07, 2007, Bill Vermillion wrote: >>In article <mailman.9.1191687791.2682.sco-m...@lists.celestial.com>, >>Bill Campbell <b...@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. >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.
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 :-(
