I've been trying to install a functional SCO Open Server 5.0.5
enterprise system.
The install seems to go fine. Upon reboot I'm told there are no
passwd or inittab files and I get tossed into single user mode.
From there I learn there is no utmp file, custom complains about
not being able to create an error file and exits, the 'more'
command doesn't exist and neither does vi. df -iv reports all
partitions having the same size, same number of blocks and inodes
used.
The system does function - up to a point, but it's pretty much
braindead.
Anyone seen anything like this before? Any ideas on what (if anything)
I may have done wrong?
The people I bought the package from thought it might be bad install
media so they sent me another copy - same results. They also think
there might be a motherboard compatibility problem but my feeling is
that since the machine can boot and is semi-alive the motherboard is
fine.
The hardware is:
Abit BF6 ATX motherboard
Pentium III 500 cpu
256 megs SDRAM PC100 non ecc memory
Adaptec 2940U2W scsi card
two Seagate ST39140LW 9 gig scsi drives
3com 3c905B ethernet card
Diamond Stealth III video card
Delta IDE CD
--
-----------------------------------------------------------------------------
-- Erik Collin http://www.acm.rpi.edu/~cougar/ cou...@acm.rpi.edu --
-----------------------------------------------------------------------------
Seems to go fine? Or does it in fact go fine?
| passwd or inittab files and I get tossed into single user mode.
| From there I learn there is no utmp file, custom complains about
| not being able to create an error file and exits, the 'more'
| command doesn't exist and neither does vi. df -iv reports all
| partitions having the same size, same number of blocks and inodes
| used.
|
| The system does function - up to a point, but it's pretty much
| braindead.
How did you divvy up your first disk?
--
JP
> Seems to go fine? Or does it in fact go fine?
The install finishes whithout displaying any error messages.
> | passwd or inittab files and I get tossed into single user mode.
> | From there I learn there is no utmp file, custom complains about
> | not being able to create an error file and exits, the 'more'
> | command doesn't exist and neither does vi. df -iv reports all
> | partitions having the same size, same number of blocks and inodes
> | used.
> |
> | The system does function - up to a point, but it's pretty much
> | braindead.
> How did you divvy up your first disk?
stand 15 megs
swap 512 megs
root 1024 megs
tmp 512 megs
usr 3072 megs
var 3531 megs
recover 1 meg
diespamd...@acm.rpi.edu.killthespam wrote:
> Jean-Pierre Radley <j...@jpr.com> wrote:
> > diespamd...@acm.rpi.edu-.killthespam opined
> > How did you divvy up your first disk?
>
> stand 15 megs
> swap 512 megs
> root 1024 megs
> tmp 512 megs
> usr 3072 megs
> var 3531 megs
> recover 1 meg
I'm no expert, but I believe that it is evil to separate
root, usr, tmp and var filesystems, particularly during
the install.
--
----
Jim Sullivan
Manager, ATG
SCO - j...@sco.com
831 427 7108
DO NOT make a separate filesystem out of /usr, NOR out of /var, NOR out
of /tmp. The recover area need only be 10 1K blocks, not 1 Meg.
What you got is what is to be expected: a braindead system.
--
JP
So the install is braindead because YOU don't read the
manual?
Sheesh...
--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.ApLawrence.com
Buddy Z
Tony Lawrence <to...@aplawrence.com> wrote in message
news:385AB68A...@aplawrence.com...
>I think he looked in a wrong manual :-)
>A little off-topic (I know it's not a Linux group).
>Red Hat Installation guide RECOMMENDS creating
>/, /swap, /usr, /home
>Tony Lawrence <to...@aplawrence.com> wrote in message
snip
>> So the install is braindead because YOU don't read the
>> manual?
>>
>> Sheesh...
AIX also wants /var /usr /usr/home and other system
kept out of root. This is, in MHO, a "good thing", as
it keeps file systems that the system will die without
from having to be user writable. Yes, there is ulimit,
but that gets to be a pain when you have large data
bases and wouldn't work if you upped the ulimit.
If the /usr/home was on a different file system
and the user filed up his home directory with the latest
Quake demo, then no big whoop. If /usr/home is part
of the root file system, then your server just crashed, and
that IS a big whoop.
I think OSR should allow some fragmenting of how /usr
and /var get allocated, but since OSR is going end-of-life pretty
soon, I doubt that it will change.
So make /home a different file system. Or if you prefer, /usr/home a
different file system. Or, /usr/home/baduser a different file system.
--
Jim Richardson
I like NT because it constantly reminds me of my daughter.
"Honest Daddy, I wasn't doing anything and it just broke."
Sent via Deja.com http://www.deja.com/
Before you buy.
So, many of us have move the $HOME directories to other filesystems
for years. /usr/local/bin and /usr/spool/mail are other candidates
for different filesystems but you do have to be careful about moving
mail.
Nothing says you can't move those volatile directories, it is the
system directories that cause problems.
--
==========================================================================
Tom Parsons t...@tegan.com
==========================================================================
There are a few basic reasons to have separate filesystems:
o There isn't space on the hard drive to fit everything you
need. This, of course, was very common in the days of small
hard drives, but seldom is an issue nowadays.
o Related to that is the situation where you WANT the data
on a separate drive for other reasons, but that forces a
separate fs so it isn't a "reason", it's a requirement.
o You want to control how much data gets put on a drive.
For example, in some environments, I'll make
/var/spool/lp/temp a small fs of its own. This causes it
to fill up if there are too many unfulfilled print jobs,
which calls attention to the problem before it really gets
out of hand and fills up something more important. The idea
here is that it's better not to print than not to work at
all.
o You can't fit an entire drive on your backup media, and
want to keep volatile data on separate fs's to make it
easier to use archaic backup programs like "dump". This is
unlikely to be a problem nowadays except for the very
largest systems.
o You want to be able to do upgrades or reinstalls and leave
some fs's untouched. This remains a valid reason for
separating certain areas from others, but with the speed and
capacity of modern backup systems, it is hardly as
compelling as it used to be.
o You want to be able to clean the fs in the event of a
crash. Older large fs's, took a long time to clean and fsck
needed more memory than was likely to be present, so it
would need scratch files, which slowed it down further. It
was not at all unusual for these fs's to get confused for no
particular reason; not from a crash, just because, so it was
obviously better to clean one or two small fs's now and then
as opposed to having to clean one big fs every time this
happened. Linux fs's still have that mentaility, btw, and
will automatically run fsck after x number of boots and/or x
number of days. Older Sun fs's would run it on EVERY boot.
Modern fs's very seldom need to run fsck anyway, so this is
not an issue. I imagine it won't be an issue for Linux,
either, once it catches up in this area.
o You want to contain the damage. On older systems, it was
often observed that if you had physical or electronic
damage, it was sometimes unrecoverable by fsck, but that it
was very apt to be confined to one fs. Therefore, spreading
the fs's out made it more likely that more of your data
survived a crash. Again, this is unlikely to be an issue
with modern fs's, and as we tend to back up more data more
often from and to more reliable media, it's even less
important.
So, IMNSHO, there is damn little reason for this anymore,
and I regularly and usually don't bother with separate fs's
unless I have something specific in mind like /var/spool/tmp
or some giant database.
Well, if pretty soon is defined as "supported, maintained and enhanced
for the conceivable future", you're correct.
SCO has not plans, at this time, to discontinue OpenServer. We have
a new release coming out (You've probably seen the beta request)
and a renewed committment to OSR5 (as future announcements will attest)
I don't know how I came under this mistaken impression,
but am I glad I was wrong!
> Thanks for clearing that up. I not just glad to hear Open Server
> is going to stick around, I'm delighted!
>
> I don't know how I came under this mistaken impression,
> but am I glad I was wrong!
Oh, sheesh :-)
You got that "impression" because that's what SCO told you.
Now, because somebody has finally woken up and realized that
the massive base of OSR5 users aren't just automatically
going to upgrade to Unixware, they are back-pedaling and
getting all mushy-mouthed about it. It's quite obvious that
there is a tremendous amount of internal stress about this:
they NEED to get rid of it, because it's really dumb and
very expensive to have two disparate product lines, but on
the other hand, OSR5 is the primary source of revenue, and
if they dump it now, users are going to look hard at other
alternatives. Keep the upgrades coming, and people will
stay with OSR5. Stop the upgrades, and maybe they'll go to
Unixware, but since that means a major change and a new OS
to learn, maybe they'll cast around and look at other
alternatives instead.
Note how the language is changing. A year back, SCO people
were telling us that OSR5 was slated for demise in a "few
years". In recent months, it's been "no immediate plans",
and now it's "no plans, at this time". Don't for a minute
think that there's anything careless about that phrase: my
bet is that it's very deliberate, designed to placate while
still leaving the door open to make plans at some other
time. Did you notice the "renewed commitment" line? That's
a telling phrase all by itself. The perception of OSR5
being dead has been very damaging both for customers
considering upgrades and for software vendors considering
their ports, and language like that is very important for
them to hear.
Longer term, SCO's only hope is to get Unixware to the point
where it effectively becomes just a simple upgrade. That's
a tall order, but they have made progress in that area.
It's not enough just now, but maybe the unspoken thought is
that they can continue along for a few years, quietly
working from both ends: making Unixware easier to transition
to for OSR5 users, and making the OSR5 product easier to
transition *from*. That's just speculation on my part, of
course. It's a tough road to follow: they don't want to
invest a lot of engineering time in a dead product, but
politically they don't want to even admit that it is a dead
product ("no plans, at this time"). That's a tough line to
walk, isn't it? In a company the size of SCO, you know that
there definitely are internal camps championing both sides
of the keep it/dump it debate: apparently the fortunes of
the "keep it" crowd are waxing just now, and it may be that
some engineering money has been re-allocated- is that what
Jim's "as future announcements will attest" means? Well,
we'll see. Let's hope so.
>Keep the upgrades coming, and people will
>stay with OSR5. Stop the upgrades, and maybe they'll go to
>Unixware, but since that means a major change and a new OS
>to learn, maybe they'll cast around and look at other
>alternatives instead.
If SCO dumps, down-grades, or jacks up the price of OSR5, the obvious
alternative is NOT UW7. It's NT4 or possibly Windoze 2000 (NT5). The
effort in transplanting the applications is the issue. If a new OS and a
new learning curve is necessary, the temptation to got to NT is all to
obvious. Linux is becoming an alternative, but it will take some time for
the apps to be tranplanted, the support staff trained, and some field
testing.
I don't specify the OS. My customers buy applications, the applications
vendor specifies the OS, the customer buys the package. I make it all
work. I've done some 3.2v4.2 to OSR5 upgrades, some Xenix to OSR5
upgrades, and some older OSR5 to 3.2v5.0.5 upgrades. Not once in the last
2 years has anyone asked about UW7. Part of the problem is the UW7.1
doesn't run Xenix binaries, while OSR5 does. Most of those that were
running 3.2v4.2 went to NT4.
I wish I had an answer to the problem. UW7 is where most of SCO's effort
is going. The trend is to introduce main-frame like features (NSK) and
support for modern technology (I20, fiberchannel, monster memory, giant
filesystem, 8-way processors, etc). The IA64/Merced/Itanium initiative is
a mix of AIX and UW7. Trying to add these features to OSR5 is going to be
difficult if not impossible. Yet OSR5 has a reputation for stability and
that's what my customers and the vertical market software vendors want.
They want it to work, never die, 100% uptime, and not see me swearing at
the console. As long as OSR5 can deliver that, it will continue to sell,
and sell, and sell, and sell. SCO could play divide and conquer, freezing
features and market segments, but there are going to be complaints and
problems.
--
Jeff Liebermann 150 Felker St #D Santa Cruz CA 95060
(831)421-6491 pgr (831)426-1240 fax (831)336-2558 home
http://www.cruzio.com/~jeffl WB6SSY
je...@comix.santa-cruz.ca.us je...@cruzio.com
>>Keep the upgrades coming, and people will
>>stay with OSR5. Stop the upgrades, and maybe they'll go to
>>Unixware, but since that means a major change and a new OS
>>to learn, maybe they'll cast around and look at other
>>alternatives instead.
>If SCO dumps, down-grades, or jacks up the price of OSR5, the
>obvious alternative is NOT UW7. It's NT4 or possibly Windoze 2000
>(NT5). The effort in transplanting the applications is the issue.
>If a new OS and a new learning curve is necessary, the temptation
>to got to NT is all to obvious. Linux is becoming an alternative,
>but it will take some time for the apps to be tranplanted, the
>support staff trained, and some field testing.
> Not once in the last 2 years has anyone asked about UW7. Part of
>the problem is the UW7.1 doesn't run Xenix binaries, while OSR5
>does. Most of those that were running 3.2v4.2 went to NT4.
One of my clients is looking forward to moving to that environment,
as they are getting tired of archiving data from one of their
files, which regularly hits the 2GB file size limit. They'd like
to keep the data on line. A year ago it was decided that this was
the way to go. We >slowly< upgraded out of older non-supported
hardware, and they had a serious amount of work on Y2K - so we all
felt the appropriate action was to upgrade well after the Y2K
scene. I would not have recommended upgrades to UW7 unless
absolutley neccesary this past year to avoid compounding potential
problems.
>I wish I had an answer to the problem. UW7 is where most of SCO's
>effort is going. The trend is to introduce main-frame like features
>(NSK) and support for modern technology (I20, fiberchannel,
>monster memory, giant filesystem, 8-way processors, etc). The
>IA64/Merced/Itanium initiative is a mix of AIX and UW7.
I always considered AIX a mix of everything already. I remember
when IBM was getting ready to release it. It was to include
the best of System 7, Version III, Xenix, BSD, System V.x, etc.
The standing joke was that they did not include the best of the
above, but that they included all of the above.
>Trying to add these features to OSR5 is going to be difficult
>if not impossible. Yet OSR5 has a reputation for stability and
>that's what my customers and the vertical market software vendors
>want. They want it to work, never die, 100% uptime, and not see
>me swearing at the console. As long as OSR5 can deliver that, it
>will continue to sell, and sell, and sell, and sell. SCO could play
>divide and conquer, freezing features and market segments, but
>there are going to be complaints and problems.
Just like there were after Xenix was 'frozen forever' in 1988 - and
just two years later - because of the demand - there were updates
to it. It's the old 'best planned lays of mice and men' - or
something like that :-)
--
Bill Vermillion bv @ wjv.com
Indeed.
> It's NT4 or possibly Windoze 2000 (NT5). The
> effort in transplanting the applications is the issue. If a new OS and a
> new learning curve is necessary, the temptation to got to NT is all to
> obvious.
Personally, I just don't see MS Windows (in whatever form) doing it.
As an example, to create a virtual domain on an NT4 server and give that
virtual domain Frontpage support, you'll need to reboot it two or three
times. Add other drivers? More reboots. It's just plain silly.
> Linux is becoming an alternative, but it will take some time for
> the apps to be tranplanted, the support staff trained, and some field
> testing.
Linux isn't too bad. But, FreeBSD or OpenBSD (or even NetBSD, if
management is allergic to the words "free" and "open") would probably be
more saleable to management who are after stability. Afterall, even
Microsoft use it for their most highly used sites (Hotmail, etc).
> [...] Part of the problem is the UW7.1
> doesn't run Xenix binaries, while OSR5 does. Most of those that were
> running 3.2v4.2 went to NT4.
IIRC, both Linux and the *BSD camps have compatibility means for
XENIX/SCO. I can't say I've tested them overly much. But XENIX/SCO, Linux
and *BSD are all POSIX compliant, aren't they? Porting ought to be
doable and it would be an awful lot easier than trying to port across
to the MS Windows platform :-).
--
_ _ _ _
|_|_ |__ _ | _ |_|_o _ pc at it dot net dot a u |
| (/_|(/_| |_(_|| | || | http://it.net.au/~pc |
PO Box 869, Hillarys WA 6923, AUSTRALIA |
That's painfully inaccurate, and I say that with greatest respect.
Trends are favoring IE5 and Win2k, but you well know that both of
those open you up to no end of security problems. What to put in
next is up in the air, unless someone is fixated on installing an
inferior system. Uw7 is near 7.1.1, which'll be it's 4th revision,
similar to OpenServer's 4th revision, 5.0.5. They both are mature now.
|The effort in transplanting the applications is the issue. If a new OS
|and a new learning curve is necessary, the temptation to got to NT is all
|too obvious. Linux is becoming an alternative, but it will take some time
|for the apps to be tranplanted, the support staff trained, and some field
|testing.
|
|I don't specify the OS. My customers buy applications, the applications
|vendor specifies the OS, the customer buys the package. I make it all
|work. I've done some 3.2v4.2 to OSR5 upgrades, some Xenix to OSR5
|upgrades, and some older OSR5 to 3.2v5.0.5 upgrades. Not once in the last
|2 years has anyone asked about UW7. Part of the problem is the UW7.1
|doesn't run Xenix binaries, while OSR5 does. Most of those that were
|running 3.2v4.2 went to NT4.
|
|I wish I had an answer to the problem. UW7 is where most of SCO's effort
|is going. The trend is to introduce main-frame like features (NSK) and
|support for modern technology (I20, fiberchannel, monster memory, giant
|filesystem, 8-way processors, etc). The IA64/Merced/Itanium initiative is
|a mix of AIX and UW7. Trying to add these features to OSR5 is going to be
>Jeff Liebermann <je...@comix.santa-cruz.ca.us> wrote:
>> If SCO dumps, down-grades, or jacks up the price of OSR5, the obvious
>> alternative is NOT UW7.
>
>Indeed.
>
>> It's NT4 or possibly Windoze 2000 (NT5). The
>> effort in transplanting the applications is the issue. If a new OS and a
>> new learning curve is necessary, the temptation to got to NT is all to
>> obvious.
>
>Personally, I just don't see MS Windows (in whatever form) doing it.
>As an example, to create a virtual domain on an NT4 server and give that
>virtual domain Frontpage support, you'll need to reboot it two or three
>times. Add other drivers? More reboots. It's just plain silly.
>
>> Linux is becoming an alternative, but it will take some time for
>> the apps to be tranplanted, the support staff trained, and some field
>> testing.
>
>Linux isn't too bad. But, FreeBSD or OpenBSD (or even NetBSD, if
>management is allergic to the words "free" and "open") would probably be
>more saleable to management who are after stability. Afterall, even
>Microsoft use it for their most highly used sites (Hotmail, etc).
>
>> [...] Part of the problem is the UW7.1
>> doesn't run Xenix binaries, while OSR5 does. Most of those that were
>> running 3.2v4.2 went to NT4.
>
>IIRC, both Linux and the *BSD camps have compatibility means for
>XENIX/SCO. I can't say I've tested them overly much. But XENIX/SCO, Linux
>and *BSD are all POSIX compliant, aren't they? Porting ought to be
>doable and it would be an awful lot easier than trying to port across
>to the MS Windows platform :-).
--
>Personally, I just don't see MS Windows (in whatever form) doing it.
>As an example, to create a virtual domain on an NT4 server and give that
>virtual domain Frontpage support, you'll need to reboot it two or three
>times. Add other drivers? More reboots. It's just plain silly.
One of the major objectives in Windoze 2000 (NT5) is to reduce the number
of "required" reboots. I believe the number went from something like 75
instances to about 5. However, such features do NOT make a sellable
operating systems. For example, MacOS 8 doesn't require any reboots for
any tcp/ip reconfiguration. You can change the numbers to your hearts
content, and the OS will comply. Yet, I don't see everyone migrating
toward MacOS 8 or 9. However, such improvements in NT5 err... Win 2K will
come at a price. Everything now talks AD (active directory). I've been
reading about how this ties into applications, single sign-on, security,
built-in Kerberos, ad nausium and am literally overwhelmed. I'm not an
expert on NT but I see problems ahead.
However, none of the aformentioned has anything to do with why one of my
customers would chose to migrate from OSR5 to NT instead of OSR5 to UW7.
It has to do with the applications vendors. For every OS that they
support, they need programmers, developers, documentation, training,
testing, and knowledgeable support people. Reduce the number of OS's
supported and the software manufactory has eliminated considerable effort
and produced a cost savings. If no customers are lost (i.e. the software
vendor can specify the OS), then dropping an OS is a win.
I should point out (again) that I do not specify the OS. No customer has
ever come to me and asked "I need an OS to run my application" nor have I
been asked anything more than recommending an OS. It's the applications
vendor that specifies the OS. It's usually something like "I just bought
Conglomerator 2000. Can you setup our office?" Often, they don't even
know what OS it's running upon. It's the software vendor that specifies
the OS that they want to support. What I'm seeing is more and more drift
toward the evil empire and away from the Unix road to righteousness.
>Linux isn't too bad. But, FreeBSD or OpenBSD (or even NetBSD, if
>management is allergic to the words "free" and "open") would probably be
>more saleable to management who are after stability.
Here's where I get to play FUD (fear, uncertainty, doubt). What's a crash
or trashout cost these days? For any kind of transaction (order taking)
intensive system, the loss of one days worth of business can easily exeed
the cost of the operating system. Wanna gamble? OSR5 has a good
reputation and somewhat proven track record for stability. Linux and
mutations currently do not. They may have in the future, but not today.
Again, it's not the customers management types that need to be sold, it's
the applications vendors management if they want to commit resources (i.e.
spend the bucks) on Linux development and support.
>IIRC, both Linux and the *BSD camps have compatibility means for
>XENIX/SCO. I can't say I've tested them overly much. But XENIX/SCO, Linux
>and *BSD are all POSIX compliant, aren't they? Porting ought to be
>doable and it would be an awful lot easier than trying to port across
>to the MS Windows platform :-).
POSIX, FIPS, Unix 99, etc complaint means that someone paid for a very
expensive testing suite. I don't think anyone has bothered to do this with
Linux. Linux and others do their best to come as close as possible, but I
suspect that official certifications are lacking. (This was the case when
I last looked about 9 months ago and may have changed).
People don't care. Amazing as it seems to us, neither
security nor stability are important features to the
overwhelming majority. Applications and ease of use are
usually the only items on the table, period.
In all my years, I only recall being asked about security
once or twice. I've brought it up myself, but most folks
run along in blissful ignorance. I've seen some really
scary systems connected to the net with absolutely zero
concern or preparation.
As to stability, I most often hear that when I'm playing
Doctor Kevorkian: taking down some ancient SCO system that
has been replaced by a sharp new set of NT server(s).
Invariably the SCO box gets praised for its reliability,
which is so ironic under the circumstances.
>>Personally, I just don't see MS Windows (in whatever form) doing it.
>>As an example, to create a virtual domain on an NT4 server and give that
>>virtual domain Frontpage support, you'll need to reboot it two or three
>>times. Add other drivers? More reboots. It's just plain silly.
> One of the major objectives in Windoze 2000 (NT5) is to reduce the number
> of "required" reboots. I believe the number went from something like 75
> instances to about
About time they spent time on reliability issues instead of the MS Office
Paperclip code *grin*
> However, such features do NOT make a sellable
> operating systems. For example, MacOS 8 doesn't require any reboots for
> any tcp/ip reconfiguration. You can change the numbers to your hearts
> content, and the OS will comply. Yet, I don't see everyone migrating
> toward MacOS 8 or 9.
Yes, I think we agree: removing the unnecessary reboots and the other bugs
are but one of the factors pertaining to a decision to migrate.
[...]
> However, none of the aformentioned has anything to do with why one of my
> customers would chose to migrate from OSR5 to NT instead of OSR5 to UW7.
> It has to do with the applications vendors. For every OS that they
> support, they need programmers, developers, documentation, training,
> testing, and knowledgeable support people.
At the same time, management would hopefully take into account the
stability and maintainability of the OS. If there are a few extra software
developers working on MS Windows 2000 apps, does this make up for the fact
that you're more likely than not going to have to hire extra staff
to babysit the machine to make sure it carries out its operations without
bluescreening because it loaded a screensaver? ;-)
> I should point out (again) that I do not specify the OS. No customer has
> ever come to me and asked "I need an OS to run my application" nor have I
> been asked anything more than recommending an OS. It's the applications
> vendor that specifies the OS. It's usually something like "I just bought
> Conglomerator 2000. Can you setup our office?" Often, they don't even
> know what OS it's running upon. It's the software vendor that specifies
> the OS that they want to support. What I'm seeing is more and more drift
> toward the evil empire and away from the Unix road to righteousness.
I'd agree with you to a certain extent. But I also would think it's more a
case for sales to be arguing the server vs workstation model. A good
workstation does not necessarily make a good server.
>>Linux isn't too bad. But, FreeBSD or OpenBSD (or even NetBSD, if
>>management is allergic to the words "free" and "open") would probably be
>>more saleable to management who are after stability.
> Here's where I get to play FUD (fear, uncertainty, doubt). What's a crash
> or trashout cost these days? For any kind of transaction (order taking)
> intensive system, the loss of one days worth of business can easily exeed
> the cost of the operating system.
The cost of an operating system or any other piece of software does not
equate to quality. Apache HTTPd (free) vs IIS (not). Squid Cache (free) vs
heck, I dunno ;-).
> Wanna gamble? OSR5 has a good
> reputation and somewhat proven track record for stability. Linux and
> mutations
I take issue with your description of FreeBSD as a mutation of Linux.
FreeBSD's lineage is traceable back to the Berkley Standard Distribution
and I would venture to say it has at least equal claim to claiming the
UNIX mantle as System V.
On a perhaps related note (perhaps also unrelated), I guess I should try
to describe where I see these OSes each flourishing currently. It is
perhaps coloured by the nature of the market in my neck of the woods
(Western Australia), but, the observations might be appropriate for other
places.
* SCO OS5: Purchased by companies who want a company to blame if their
software crashes, but, are too cheap to buy non-Intel hardware. Oh, and
it's popular with stodgey organisations who bought an Intel-based XENIX
system back in the 1980s.
* Sun/Solaris: Purchased by companies who want a company to blame if their
software crashes, but, are willing to spend the money to buy decent
hardware performance.
* Linux: Installed by companies who are are willing to pay for staff
experience, ability and ingenuity; it's a platform where hacking something
together that works better is the key. Often ISPs, etc, prefer this
environment.
* *BSD: Installed by companies who want the source open so they can
hack together something if absolutely necessary, but, they want stability
in the core system. *BSD is the conservative open source platform. I think
that's why I'm starting to like it.
My own personal bias is probably easy to spot: I like all of these OSes
apart from SCO. SCO felt like historic crippleware with serious
performance issues. But that's reasonably irrelevant to this particular
thread :-).
[Regarding *BSD and Linux having a proven track record for reliability:]
> currently do not. They may have in the future, but not today.
I find it exceptionally strange that you can't imagine BSD machines being
reliable, especially in comparison with MS Windows. You will of course
know which OS Microsoft uses for http://www.hotmail.com/. It's not NT.
It's not SCO OSR5 (formerly MS XENIX). True enough, it's not Solaris or
Linux. It's FreeBSD. Someone considers it reliable :-)
Regarding Linux? Linux itself is a kernel, not an OS. There are good
distributions and there are bad. Redhat is bad. Debian is good. Highly
recommended among the majority of ISPs in Western Australia; I recommend
that you have a look at it :-)
> Again, it's not the customers management types that need to be sold, it's
> the applications vendors management if they want to commit resources (i.e.
> spend the bucks) on Linux development and support.
The greatest benefit the open source community is having is the freedom to
shift platforms and simply recompile the apps you're used to using on the
new OS and hardware platform you're using. It's hopefully a sign of better
things to come :-)
> POSIX, FIPS, Unix 99, etc complaint means that someone paid for a very
> expensive testing suite. I don't think anyone has bothered to do this with
> Linux. Linux and others do their best to come as close as possible, but I
> suspect that official certifications are lacking. (This was the case when
> I last looked about 9 months ago and may have changed).
Formal POSIX compliance really doesn't matter much. The question is: Does
the app I'm using compile under this new platform and, if not, how long
will it take to port? Trust me: the time and money needed to port apps or
systems from one POSIX unix to another POSIX unix is easy to justify in
comparison to a POSIX unix to MFC-based MS-Windows32 environment.
Hope you had a great Christmas. All the best for the new year.
>On 24 Dec 1999 15:28:00 GMT, "Peter Caffin" <nosp...@it.net.au>
>wrote:
>>Linux isn't too bad. But, FreeBSD or OpenBSD (or even NetBSD,
>>if management is allergic to the words "free" and "open") would
>>probably be more saleable to management who are after stability.
>Here's where I get to play FUD (fear, uncertainty, doubt). What's
>a crash or trashout cost these days? For any kind of transaction
>(order taking) intensive system, the loss of one days worth of
>business can easily exeed the cost of the operating system. Wanna
>gamble? OSR5 has a good reputation and somewhat proven track record
>for stability. Linux and mutations currently do not. They may
>have in the future, but not today.
Jeff - just a quick comment here about your reply which appears to
lump the *BSD* variants in the same mold as the *nux group.
I still haven't found a Linux variant I pesonally like - and there
seems to be a lack of consitancy among them and file placements
seem to wander all over the place. (at least from what I've
been expecting). [I've found that if you knew your way around most
of the major Unixen you could quickly adapt to other variants - but
I have not foud that in *nux]
I'll agree on that the cost of the OS should never be the deciding
factro, and those who believe differently probably aren't
readers/posters into this group.
BSDI is definately not free. Fully supported, and last time I
checked its price list was similar to SCO OSR5. Find the OSR5 cost
per user license and cut it in half and get theirs.
My BSD 4.4 BSD manuals (from the original Berkeley/Usenix/OReilly
distributions) match the current releases for applications which
were extant at that time. So much for reputation and documentation.
But it is definately a server/network platform and I only use it
for an ISP I work with/for. It's a long way from the desktop
device that the Linux advocates use. It's the OS or the base for
proprietized OSes, that are in several ICSA certified firewalls, and
it's the driving mechanism underneath Quantum Snapserver from what
I understand, in firmware.
And as a server it comes with tools which even the experts use with
care - on wrong move and the system goes 'poof'. Not many
commercial OSes ship with tools that let you manipulate the SCSI
code pages as part of the standard distribution :-( Not something
that should probalby be used where most OSR5 reside.
>management types that need to be sold, it's the applications
>vendors management if they want to commit resources (i.e. spend the
>bucks) on Linux development and support.
I'd never pretend to support an application on an OS upon which the
vendor has not indicated support. At that point 'free' can cost more
than the most expensive commercial variant. I've seen too many
problems in the "it should work but it's not supported" area.
>>IIRC, both Linux and the *BSD camps have compatibility means
>>for XENIX/SCO. I can't say I've tested them overly much. But
>>XENIX/SCO, Linux and *BSD are all POSIX compliant, aren't they?
>>Porting ought to be doable and it would be an awful lot easier
>>than trying to port across to the MS Windows platform :-).
There is the iBCS variant available in *BSD but I've never tested
nor tried it. When asked about making BSD variants the developers
typically will say port it to Linux and then use compatibility mode
to run there. At least they are doing something to avoid further
fragmentation of the entire *ix market.
>POSIX, FIPS, Unix 99, etc complaint means that someone paid for a
>very expensive testing suite. I don't think anyone has bothered
>to do this with Linux. Linux and others do their best to come as
>close as possible, but I suspect that official certifications are
>lacking. (This was the case when I last looked about 9 months ago
>and may have changed).
While not OS certifcation I have seen one Linux ICSA certified
firewall listed. There are 25 OS based firewalls currently listed
at the ISCA site. 6 on Solaris, 4 *BSD, ten NT, and rest scattered
among Unixware, Netware, AIX and Tru64Unix.
I have no idea how much or even if any of these OSes was gutted to
bring them to compliance, but the greatest number of firewalls
are hardware implementations.
As you indicated, the driving force behind anything is the
application. My first real Xenix client from about 1983 is
currently building a system where the best OS for the application
is the Mac OS and they are currently implementing the Max OS X.
There is another OS currently supported (it's initials are NT), but
the serious *ix OSes won't be delivered until later this coming
year. (In the process I've seen state-of-the-art network facilities
that are far beyond what my small mind ever envisioned).
One of the things I liked when I first encounted the BSD world was
that it was so like the Radio Xenix 1.x (prior to the more popular
3.x series that most people now) upon which I learned.
Trying to save money costs in the end. Monday (if not sooner -
depending on when I can get the needed boot disks) I will attempt
to recover a crashed system that the users had decided not to
upgrade and had planned to be totally out of the SCO environment
long before Y2K. It is not going to be fun or pretty - old
hardware, no OSes disks to be found anywhere. Have the license
numbers from their sales invoice - but I suspect they will be
on OSR5 by Tuesday. Worst mess I've seen in over 5 years.
They now think they might be able to complete their move by April.
The person in charge was quite anti-Unix. When I questioned him
it turns out the most current Unix he had seen was the 2.3.4.2 they
were running and was comparing it to their Windows 98 and NT in
terms of 'user friendliness'. I pointed out (I'm not a politically
correct animal) that to be fair then he really should compare
the version of Unix to Windows 2.0. (gawd whan an ugly beast that
was. I still have a 1.4 around here somewhere - when I saw that
then I just KNEW the DRI's GEM would be the graphical interface of
the future. Along that line I was also a confiremed betaphile).
Enough of the rambling.
Bill
American Airlines cared. HP Cust Support cared. BMW cared.
And for those of you who've been too busy to let your curiosity
get you to build a Uw7 test system, I have some news. It's
a lot like OpenServer and it's nearly identical to Solairis 7.
If you've ever worked on Unix before. . . then it'll be a piece
of cake. Things like more, grep, ifconfig, netstat, and the
usual commands like shutdown work as you'd expect. There are
differences in hardware config and device names and the like,
but the secret's out on those if you just check out the Faq.
|In all my years, I only recall being asked about security
|once or twice. I've brought it up myself, but most folks
|run along in blissful ignorance. I've seen some really
|scary systems connected to the net with absolutely zero
|concern or preparation.
|
|As to stability, I most often hear that when I'm playing
|Doctor Kevorkian: taking down some ancient SCO system that
|has been replaced by a sharp new set of NT server(s).
|Invariably the SCO box gets praised for its reliability,
|which is so ironic under the circumstances.
Man this is so sad. I can't believe I got snowed by SCO marketing and
wasted all these years with SCO when I should've gone for an mcse or gone
towards Sun or IRIX.
Also, it ocuurs to me that you all frequently see Mom n' Pop businesses.
90% of the well paying sysop jobs in the SF area seem to be with growing
businesses that run Sun Sun Sun. It's all I ever hear. People are
always trying to roll out another Sun NFS NIS setup. I figured I'd
mount the attack from the SCO Unix end, as it's hard to get a Sparc.
How very very sad. I thought people ran Oracle on Uw7. Ooops.
I thought people needed a seperate DNS server in the DMZ. I thought
they needed a web server in the DMZ. I thought people need scalability
and FTP servers and this is too long already
HH
Matthew
Topic drift in action. Oh well...
>About time they spent time on reliability issues instead of the MS Office
>Paperclip code *grin*
The MS paper clip is a very important part of the Office 2000 product. Ask
any magician why it's there. It's called an "attention distractor". Keep
your eye on the right hand, while the left hand does all kinds of sneaky
things. The way it works is that your eyes follow the moving paper clip
and never notice how slow, sluggish, and sloth-like the product performs.
The paper clip get top priority in CPU cycles (run Wintop). Notice that it
only moves when Office needs to (slowly) repaint the screen.
>I take issue with your description of FreeBSD as a mutation of Linux.
>FreeBSD's lineage is traceable back to the Berkley Standard Distribution
>and I would venture to say it has at least equal claim to claiming the
>UNIX mantle as System V.
I should have known that heredity and lineage are important in this
business. Among some of my relatives, I'm "Ytzchak Ben Mosheh" (Isaac, son
of Mosheh). Anything less would be marginal heresy. So, what do I call
it? "FreeBSD Ben SYS_V", "Son of UCB Unix", or "BSDenstein"? I agree
that I should not have lumped them all together as "Linux mutations", which
is obviously incorrect, but I'm at a loss for the proper description.
>* SCO OS5: Purchased by companies who want a company to blame if their
>software crashes, but, are too cheap to buy non-Intel hardware. Oh, and
>it's popular with stodgey organisations who bought an Intel-based XENIX
>system back in the 1980s.
Interesting observation. Most companies that were using Xenix in its
hayday would have needed to be in business for at least 15 years. This
kind of longevity is not common. In order to have been in business at
least 15 years, said companies will need to be doing something right. They
also would have experienced a few meltdowns, drive failures, backup
nightmares, and update ordeals. In other words, they know what they really
need from a computer system (and software) with a trend toward the
conservative bordering on paranoid. This type of customer is not often
impressed by glitz, promises, vapourware, and rotten support. They stick
with OSR5 because it does most everything that they need.
>* Linux: Installed by companies who are are willing to pay for staff
>experience, ability and ingenuity; it's a platform where hacking something
>together that works better is the key. Often ISPs, etc, prefer this
>environment.
In other words, they do their own support. Not bad if the customer can
afford it. I recently attended a meeting of the remains of the IS
department of a "merged" company. One of the clueless VP's asked "Why are
there 3ea full time programmers on the support staff"? Nobody could supply
a straight answer as about half of the time was spent making Linux do some
fairly weird things while the boring database stuff was being seriously
neglected.
Moral: Eliminating temptation does not build integrity. It's the ability
to function properly in the presence of temptation that builds integrity.
Knowing when to stop programming is something that's not included in the
HOWTO docs.
>My own personal bias is probably easy to spot: I like all of these OSes
>apart from SCO. SCO felt like historic crippleware with serious
>performance issues. But that's reasonably irrelevant to this particular
>thread :-).
I don't wanna get into a point by point comparison. I keep blundering into
Linux boxes that have never had the "hdperf"(?) command run to set the hard
disk performance to anything faster than the lowest form of IDE.
>I find it exceptionally strange that you can't imagine BSD machines being
>reliable, especially in comparison with MS Windows. You will of course
>know which OS Microsoft uses for http://www.hotmail.com/. It's not NT.
>It's not SCO OSR5 (formerly MS XENIX). True enough, it's not Solaris or
>Linux. It's FreeBSD. Someone considers it reliable :-)
Everyone knows that story. Hotmail started out with SunOS, went to
Solaris, and uses FreeBSD for their web server front end. When MS bought
Hotmail, they tried to switch it over to NT4. NT puked and died under
load. That was many years ago and hasn't changed since. See:
http://www.kirch.net/unix-nt/hotmail.html
Before everyone started hiding behind firewalls, you could telnet to
various MS mail servers and discover that they were running either FreeBSD
or NetBSD (I forgot which). Eventually, they switched to MS Exchange
Server, but I heard the transition was painful. I see the whole episode as
an indictment against NT rather than an endorsement of FreeBSD or Solaris.
>Regarding Linux? Linux itself is a kernel, not an OS. There are good
>distributions and there are bad. Redhat is bad. Debian is good. Highly
>recommended among the majority of ISPs in Western Australia; I recommend
>that you have a look at it :-)
Sigh. Yet another product to test. My shelf is littered with Linux
distributions and shelfware. I picked up more cdroms at Linux Expo than I
could possibly have time to try. I haven't tried Debian yet. It seems to
be geared toward running an ISP, something that I have no interest in
attempting. I'm looking for an SMB platform. So far, Caldera 2.3 is good
enough. Red Hat 6.0 has been muddled. SUSE 6.1 is quite nice and stable.
I couldn't keep the libraries straight in Slackware. I have a simple
criteria. I'll tolerate program installation failures. But, if the RPM
mutation and install programs (LISA, YAST, etc) can't recover from an
install trashout, it's garbage.
>The greatest benefit the open source community is having is the freedom to
>shift platforms and simply recompile the apps you're used to using on the
>new OS and hardware platform you're using. It's hopefully a sign of better
>things to come :-)
No, that's not the greatest benifit. It's the ability to turn around
changes and updates rapidly. The internet and all that it's dragging
behind it is changing far too fast for a full blown QA effort to keep up.
If the customer needs those features, then fast hacks are the hot ticket.
Four version of PPPoE are already available for Linux, while SCO finally
gets around to delivering NAT and DHCP clients. However, my SMB customers
grind numbers, take phone orders, do bookkeeping, and scribble letters.
They might as well be in the stone age. Modest delays for testing to avoid
early adoption instabilities are easily accomidated.
Gross generalization: Given a situation that demands a decision, customers
will *ALWAYS* chose stability and reliability over features and functions.
It's amazing what features, functions, utilities, and junkware can be
removed and still have a functioning company. That's how I fix NT4
servers. Get rid of crap that's not needed and it will work reliably. I
think I've now cleaned up about 5 big NT4 servers by reducing them to just
file and print boxes. The only ones that give me trouble are also running
Exchange Server.
>Formal POSIX compliance really doesn't matter much.
OK. You just threw out the government market, most of the fortune 1000
companies, and much of the medical software business. I dunno about the
schools. To someone who has a clue, certification doesn't matter. To
Dilbert's PHB boss, it's the only thing he knows what to look for, and will
insist on certification even if he doesn't have a clue what it means or
offers.
>Hope you had a great Christmas. All the best for the new year.
Bah Humbug. I've been semi-grounded for about a week with the flu. Sky
high fever, hacking cough, muscle aches, no brain. Missing Christmas was
no loss since I'm Jewish. However, last Weds was the ultimate full moon.
My hair started growing, nose elongated, teeth sharpened, and my voice
turned into growl. Instead of lopeing through the forest with the pack,
treating myself to a meal at the local chicken ranch (it's kosher), I got
to lay in bed and feebly snarl at the moon. What was supposed to be the
longest night and brightest full moon, ended up a total bummer. The next
day, all the fur fell out while I was still in bed, and I shredded the
sheets with my paws, resulting in a major cleanup mess. Snarl, growl, bah
humbug.
> American Airlines cared. HP Cust Support cared. BMW cared.
> And for those of you who've been too busy to let your curiosity
> get you to build a Uw7 test system, I have some news. It's
> a lot like OpenServer and it's nearly identical to Solairis 7.
> If you've ever worked on Unix before. . . then it'll be a piece
> of cake.
I'll agree with that much more than disagree. I've said
before that moving to UW7 is not so horrible- it is very
OSR5 friendly and if you have a Solaris background too, as I
do, it really is a piece of cake.
That doesn't change a damn thing. Stop OSR5 and SCO will
lose customers- droves of customers, probably the majority
of customers.
> |As to stability, I most often hear that when I'm playing
> |Doctor Kevorkian: taking down some ancient SCO system that
> |has been replaced by a sharp new set of NT server(s).
> |Invariably the SCO box gets praised for its reliability,
> |which is so ironic under the circumstances.
>
> Man this is so sad. I can't believe I got snowed by SCO marketing and
> wasted all these years with SCO when I should've gone for an mcse or gone
> towards Sun or IRIX.
I think you missed my point :-)
>|As to stability, I most often hear that when I'm playing
>|Doctor Kevorkian: taking down some ancient SCO system that
>|has been replaced by a sharp new set of NT server(s).
>|Invariably the SCO box gets praised for its reliability,
>|which is so ironic under the circumstances.
>Man this is so sad. I can't believe I got snowed by SCO marketing
>and wasted all these years with SCO when I should've gone for an
>mcse or gone towards Sun or IRIX.
Considering the state of SGI in today's world IRIX may not have
been a good move either. However if you learn UNIX - and by that
I mean understand the design and the philosphy behind the design
- Unix as a system - then the brand name on the variant doesn't
really mean that much - and you should be able to move among various
installations without a lot of problems.
> Topic drift in action. Oh well...
This is Usenet, afterall. Should one of us compare an OS to Hitler, I
believe the Usenet Thread 1.0 criteria will have been completed and
the framed certificate pending ;-).
My take on the topic (at least when I joined in) was whether anyone would
leap to UnixWare should SCO remove OSR5 immediately and, if not, what
would they leap to.
[Regarding MS Office Paperclip:]
> The paper clip get top priority in CPU cycles (run Wintop). Notice that it
> only moves when Office needs to (slowly) repaint the screen.
I don't think I've reinstalled MS Office since I reinstalled my MS Windows
partition at home. Sun's StarOffice does the jobs I need, if slowly ;-).
> I should have known that heredity and lineage are important in this
> business.
They are indeed when you're talking about whether FreeBSD is UNIX enough
for use.
> [...] I agree
> that I should not have lumped them all together as "Linux mutations", which
> is obviously incorrect, but I'm at a loss for the proper description.
"FreeBSD is an open source descendant of Berkley Standard Distribution."
That'll do... for me anyway :-).
> Interesting observation. Most companies that were using Xenix in its
> hayday would have needed to be in business for at least 15 years. This
> kind of longevity is not common. In order to have been in business at
> least 15 years, said companies will need to be doing something right.
Not really. Government departments, companies locked into long term
contracts with software developers unable to port to other UNIX platforms,
local government agencies, companies unwilling to change. At least these
have been the only organisations in Western Australia that I've seen
running SCO. Any other company with prior SCO systems I've seen has had
plans to shift from SCO to a non-SCO unix/linux.
[Regarding Linux:]
> In other words, they do their own support. Not bad if the customer can
> afford it.
Incorrect. They have the option to do their own support. Or they can
purchase support from another company, such as Redhat, LinuxCare, or any
other organisation which offers it; and there are many.
Internet providers typically will provide a support contract if you're
purchasing a Linux machine and network connectivity, just as one example.
There are companies out there who don't want to mess around, and other
companies who provide services which cater to their needs.
> Moral: Eliminating temptation does not build integrity. It's the ability
> to function properly in the presence of temptation that builds integrity.
> Knowing when to stop programming is something that's not included in the
> HOWTO docs.
Agreed, but, this applies to the use of any platform. One person's
decision on an OS platform doesn't affect the behaviour of that OS's
users; much as we'd like it to :-)
> I don't wanna get into a point by point comparison. I keep blundering into
> Linux boxes that have never had the "hdperf"(?) command run to set the hard
> disk performance to anything faster than the lowest form of IDE.
Yup, true most likely. As I've mentioned before, Linux itself is just the
kernel. Each distribution organises itself differently.
I've always been a fan of using low-end hardware platforms as a guide to
OS efficiency. Give a unix variant a 486DX2 or similar and see how it
goes at running its base operations and its install. SCO OSR5 proved to be
a disaster zone. After 4+1/2 hours, it finally ground to completion. Even
then, it could barely handle doing anything more than running a HTTPd with
next to zero load and a console session. That in comparison to Linux and
*BSD convinced me of the dinosaur-land SCO inhabits; fit only for those
with no alternative whatsoever.
[Regarding Debian Linux:]
> could possibly have time to try. I haven't tried Debian yet. It seems to
> be geared toward running an ISP, something that I have no interest in
> attempting.
Actually, it's not. ISPs like it because it makes updating software
packages and applying security patches extremely quick and without much
fuss. Debian's .deb package format incorporates pre-installation
scripting, system testing, dependency testing, and post-installation
scripting. It just works and doesn't touch configuration files (it will
suggest if it feels you should); perfect for sites and networks with more
than one server.
[...]
> criteria. I'll tolerate program installation failures. But, if the RPM
> mutation and install programs (LISA, YAST, etc) can't recover from an
> install trashout, it's garbage.
I think I've mentioned my feelings re Redhat, ie I agree ;-).
[...]
> Gross generalization: Given a situation that demands a decision, customers
> will *ALWAYS* chose stability and reliability over features and functions.
Both Debian and FreeBSD keep their STABLE and development trees distinctly
separate. One of the reasons I like them.
[...]
>>Formal POSIX compliance really doesn't matter much.
Bear in mind that I have no idea as to the formal standing of POSIX or
other compliancy of Linux or *BSD. However, they've been compliant enough
in practice.
> [...] To someone who has a clue, certification doesn't matter. To
> Dilbert's PHB boss, it's the only thing he knows what to look for, and will
> insist on certification even if he doesn't have a clue what it means or
> offers.
IME, most bosses will ask: "What will do X, Y, Z? Howabout
SillyBrand?" Sometimes SillyBrand will win, sometimes not. It depends on
the salesmanship of the admin and the glossiness of the brochures, as well
as the level of bloodymindedness in management. Some managers will ignore
technical advice because it threatens their authority. Office politics,
grr.
Certification is generally an issue hidden in the glossy brochures. I
can't say it's ever been raised as an issue to me. But then Western
Australia may be a bit different to your neck of the woods.
>>Hope you had a great Christmas. All the best for the new year.
> Bah Humbug. I've been semi-grounded for about a week with the flu. Sky
> high fever, hacking cough, muscle aches, no brain.
Not fun. I don't envy you.
> Missing Christmas was no loss since I'm Jewish.
Ah well, hope you had/have a happy Hunnacha (sp?)
> [...] Snarl, growl, bah humbug.
You're a strange man, Jeff :-).
Well, I have to disagree here (with greatest respect); I switched
my OS from SCO OpenServer 5 to UnixWare middle this year just
in order to get better acquainted with it. I have to tell that
the system has been pretty stable so far, but it's far from being
mature (IMHO). As an example, bring it to multi-user, back
to single user and again in multi-user mode; I've noticed several
warning messages which made me think about a complete reboot (which
I did and it made 'em disappear).
Also consider the serial terminal support; it took SCO one year and a
half
to release a pre-patch in order to correctly handle 3 wired serial
cables (TX,RX,GND) and I've yet to see it released on the SCO's site.
Not to mention the 4GB boot limitation and so on ...
Also, please take a look at the number of patches being released so far;
while I do appreciate the fact that SCO cares about it, and I
agree that UW7 brings a lot of new stuff with it, you have to
get in synch with SCO every day in order to have your system
upgraded to the latest patch/fix. Also, consider the fact that version
7.1.1 has not been released yet (at least, here in Italy) but there
are 9 patches available to it, which is rather discouraging ...
Please don't get me wrong; I think UW7 will be the future in terms of
new fetaures added, but I think it's STILL not mature right now.
Looking forward version 7.2.0 :-)
Best,
Roberto
--
---------------------------------------------------------------------
Roberto Zini email : fr...@strhold.it
Technical Support Manager -- Strhold Sistemi EDP Reggio Emilia(ITALY)
---------------------------------------------------------------------
"Has anybody around here seen an aircraft carrier?"
(Pete "Maverick" Mitchell - Top Gun)