Date: Sat, 7 Dec 1996 20:37:17 -0800 (PST) From: Jake Hamby <jehamby@lightside.com> To: hackers@freebsd.org Cc: jkh@time.cdrom.com Subject: Help, I've been SCOed! Message-ID: <Pine.BSF.3.95.961207195642.184D-100000@hamby1>
next in thread | raw e-mail | index | archive | help
I just spent a day trying to upgrade a SCO system to Solaris/x86, and I
thought y'all might be interested to hear a brief summary of: Why SCO
stinks so bad, What FreeBSD can do to court SCO users, and Why I wasn't
able to upgrade to Solaris (hint: it's not Solaris's fault!).
First, why I wasn't able to upgrade. This user is primarily using the SCO
system as a dial-in (through a Digi Portserver) to remote sites, who
access a FoxPro database (yes, Microsoft FoxPro 2.6 for SCO UNIX!) for
contact and billing info. We decided that Solaris/x86 would be the most
compatible with SCO, because it has full COFF binary support (or so we
thought).
Wisely, we grabbed a scratch hard drive from the old (now unused) 486
server to install Solaris, so we could leave the SCO installation
untouched until we'd verified compatibility. Good move. Solaris
immediately core-dumped when attempting to run the foxpro executable! A
truss output revealed it was looking for locale data, then immediately
received a bunch of signals (apparently from itself), including SIGABORT.
Copying the locale data over (into the rather odd directory
/usr/lib/locale/C/C/C), didn't fix the problem. Lacking any more
sophisticated tools, we gave up.
The worst part was that some of the programs they had used (fortunately
not FoxPro) were not even COFF, but XENIX a.out! Running "file" revealed
something like:
Microsoft a.out pure dynamic byte-swapped executable
(I forget the exact modifiers). Needless to say, Solaris had NO clue
about this files and tried to run them as shell scripts!
At any rate, to justify our day's worth of work, we replaced the crappy
Trident video card the original sysadmin had installed (this was a
custom-built PC with the only redeeming quality being a dual hot-swappable
power supply, that he had charged them over $6000 for, which we all agreed
was a ripoff) with a Diamond Stealth 64 from another PC, and miraculously
were able to get X running immediately (they had NEVER got it to work
before, so had been using console mode all this time). We also tried to
install the developer environment on the off chance that we could use ld
or some other tool to somehow "wrap" the a.out binaries with a COFF or ELF
header. There was a tool called "coff2elf" but NOTHING related to XENIX
binaries. Does anyone have background info on these old XENIX binaries?
Will FreeBSD or Linux run them?
Fortunately, the company is understanding of our failure, because we tried
everything in our power to give them a drop-in replacement for SCO, and
they didn't have high hopes to begin with. Even if we had been able to
deliver, they still want to migrate to Windows NT, so we spent a lot of
today talking about exactly what our options were. And for what they need
(a simple relational database, and many are comfortable with Access
already), I can't say that I blame them. If they did want to stay with
UNIX, they would likely need some programmer to come in and custom-write a
front-end (probably in VB for Windows) to access Oracle or some other
RDBMS on the UNIX host, which would cost them a lot more than using
shrink-wrapped software and NT (I realize they would probably still need
some VB programming on the NT clients regardless). FWIW, the regular
sysadmin was cool, and even though he hadn't used UNIX before, in the six
months he'd worked there, he'd become quite proficient. Personally, he is
comfortable with UNIX or NT, so if anyone can tell me what FreeBSD
software is available to implement basic billing, contact management, and
RDBMS capabilities that would NOT require a lot of custom programming,
they would be equally receptive to a UNIX solution.
Also, I got a copy of FoxPro squirreled away on my Zip drive, so just to
torment my PC, I will play around with them on FreeBSD and Linux. If
either of them actually works, I will be VERY pleasantly surprised!
Some final comments about SCO:
Their package system is VERY VERY slow. It also requires a huge amount of
time just to read the package information from the CD-ROM before it even
starts (every time you use it!). Packages (including most of the OS
itself) are all installed in /opt/K/SCO/blah/foo/whatever and symlinked
all over the place (this has been mentioned before on this list)
Changing almost ANY trivial parameter requires a kernel relink and reboot.
This includes adding a SCSI hard drive (boot it up, configure it, and then
reboot again!), or even adding a serial-port mouse!
SCO's next project is Gemini, a merger of OpenServer 5 (SVR3.2) and
UnixWare (SVR4). The article I read was very flattering of all the
wonderful features of SVR4 (better performance, standard package tools, no
need to relink the kernel), but I couldn't help but notice all of these
features are available now in Solaris or UnixWare, so I guess these people
that are still running SCO must all be using XENIX binaries or something.
The "SCO Doctor Lite" package promised to do all sorts of wonderful
pro-active system management stuff. It turns out that the really clever
AI stuff ("intelligent kernel tuning", interpreting the results) was in
the full SCO Doctor product so essentially all we got were some pretty
(character-mode) bar graphs of data you could get from "top".
On the plus side, the X11R5/Motif desktop is decent. It looks a bit like
both Windows and CDE. Their help system is done in HTML (oddly, most of
the HTML pages were compress(1)ed), with a modified version of NCSA Mosaic
called "scohelp" (the regular Mosaic was also bundled). All the pages are
fed through a local http server (running on port 432), so that a cgi
script can also link you to man pages (e.g. /cgi-bin/man/cp+1). Also,
scoadmin is a decent program, and the Visual Tcl concept (the same program
works in console or X) is interesting.
So, what can FreeBSD do to court SCO users? We could:
1) Have really good COFF and/or XENIX binary compatibility. This is a lot
better than what Solaris/x86 offers right now!
2) Start on a decent admin type program. Personally, I think a good
approach is something combining the ideas of SCO (works on GUI and
command-line), Sun (supports files and NIS), and AIX (shows you exactly
what commands it's running to do the job, so you can put them in a script
or run them manually if you desire). The disadvantages of these three
tools we should avoid: SCO almost everything involves relinking the
kernel, Solaris doesn't use UNIX tools to do its job so you have no idea
how to do things yourself manually (the exact opposite of AIX), and I
don't know about AIX enough to say what its weak points are.
3) Start thinking about a custom help system like scohelp, which would
combine man pages and HTML through a custom HTTP server that could be
accessed remotely. Everyone is moving to HTML (or SGML) anyway, including
our own FreeBSD Handbook. We just need to make things more approachable
for new users.
All of these have been discussed recently in hackers, so I thought I'd
post this as a summary of how one vendor has done things. I wish I had
some more insightful comments, but I hope that repeating what they've done
wrong should show us what we can do better.
I hope you found these comments useful and relevant. Overall, I'd say
FreeBSD has done as good (and often better) job than many commercial UNIX
vendors have done, as my experience today proved! BTW, now I know that if
I had spent $10 on "Free SCO", it would've been wasted money. Rather to
find that out with someone else paying me, than vice versa! :-) Now, when
Free UnixWare comes out, that I might think about buying. Comments?
-- Jake
Want to link to this message? Use this URL: <https://mail-archive.FreeBSD.org/cgi/mid.cgi?Pine.BSF.3.95.961207195642.184D-100000>