Dear world,
I am setting up a PC to run Unix in a production environment just
to process EMAIL only. I'll install pine server, and have everyone
use PINE off-line via TCP/IP network.
The hardware I have is:
486-66DX2, 16MB RAM (Can add more)
1G IDE + SVGA card & 3COM EThernet
I have ruled out Linux & the likes because I can't justify the
whole company email operation be base on non-brane name :-(
(I have Linux at home) :-))
I have narrowed down to:
SCO Unix
Sun Solaris
IBM AIX
Novell Unixware
Those 4 are our main choices. Since this is my play machine/project,
I can't get $ for a real Sparc/PowerPC :-))
I am looking for recommendation for your input on which machine
can serve my need to support about 1000 user id in a production
environment (meaning support, and good future)..
Everyone will be telnet in, or link through a client for email only. :-)
I love the dynamic partition space of AIX.
The support of Sun, and the linkability of Novell, and the
low cost of SCO :-)
:_)
Thanks
Please email me :-)
>Dear world,
>
>I am setting up a PC to run Unix in a production environment just
>to process EMAIL only. I'll install pine server, and have everyone
>use PINE off-line via TCP/IP network.
>
>The hardware I have is:
>486-66DX2, 16MB RAM (Can add more)
>1G IDE + SVGA card & 3COM EThernet
>
>I have ruled out Linux & the likes because I can't justify the
>whole company email operation be base on non-brane name :-(
What do you mean? Linux is a brand name! Oh you want support? Buy one of
the CD Roms.
>(I have Linux at home) :-))
>
>I have narrowed down to:
> SCO Unix
> Sun Solaris
> IBM AIX
> Novell Unixware
If you must pick one of these, I'd say Solaris is the most stable.
I think what Tim meant is that it is not a commercial package for the most
part.
My opinion is that Slackware (being my choice of linux) is fine for running
email. Is it a huge company? I use slackware now to run our WWW server and
gopher server. I've also had LESS problems setting slackware email than
getting email to work on our AIX server, not to mention that Slackware is free.
Why spend big $$$$ on a unix system when the ONLY thing it is going to be
used for is email? Maybe you can find some other uses for it as well
anyways..
As for service/support.. you can buy a commercial linux and get it.. or just
subscribe to linux newsgroups where people can help you out.
-Ken
I'd say using what criteria?
Darren R. Davis
UnixWare Developer Support Engineer
Novell Developer Support
You can't be serious! Solaris is buggy and **SLOW**. Personally, I'd
pick none of the above (although I actually had pretty good results with
AIX for the PS/2). My first choice would be one of the BSD derivatives:
BSDI if you need a commercial product that is rock solid, well supported,
and ultra-fast. FreeBSD if you can live with a "free" product.
------------------------------------------------------------------------------
"Tundra" Tim Daneliuk COVIA Technologies 708.518.4516
Consulting Engineer Dept. COVGJ 708.518.4850 fax
9700 West Higgins Road
Rosemont, IL 60018 tun...@ct.covia.com
------------------------------------------------------------------------------
--
------------------------------------------------------------------------------
"Tundra" Tim Daneliuk COVIA Technologies 708.518.4516
: You can't be serious! Solaris is buggy and **SLOW**. Personally, I'd
: pick none of the above (although I actually had pretty good results with
: AIX for the PS/2). My first choice would be one of the BSD derivatives:
: BSDI if you need a commercial product that is rock solid, well supported,
: and ultra-fast. FreeBSD if you can live with a "free" product.
Ditto. As far as commercial UNIX for Intel, BSDI is the *only* product
I'd ever recommend. Kudos to Jordan and the FreeBSD team as well.
Daniel
--
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Daniel Leeds FreeBSD
dle...@mcs.com salmacis
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=
Tundra Tim Daneliuk (tun...@ct.covia.com) wrote:
: You can't be serious! Solaris is buggy and **SLOW**. Personally, I'd
: pick none of the above [..would pick BSDI...]
: "Tundra" Tim Daneliuk COVIA Technologies 708.518.4516
Solaris use to be buggy and **SLOW** as were earlier versions of BSD.
Try the latest version of Solaris and you'll see its neither buggy
nor **SLOW**. Things have changed alot from Solaris 2.0 to Solaris 2.4
and stability and performance are the most significant.
--
Regards,
Bryan Althaus br...@krf.com
Which version of Solaris? Which hardware platform?
--
Stacey Campbell - Stacey....@Eng.Sun.COM
I am using 2.4 on my 486-66 with 32MB ram. I totally agree that it is
very slow compare linux on the same machine. However I don't think it
is too buggy.
: As for service/support.. you can buy a commercial linux and get it.. or just
: subscribe to linux newsgroups where people can help you out.
I'm sorry Ken but "get it" is just not good enough to convence the commercial
sector that they will recieve a good backing support for Linux. Look at the
100 of rev's of linux, which one has patches for the network problems? Which
one has patches for the Xwindows problems, for what version of Xwindows?
What does Slackware cut a CD a week to keep up with these problems? Just
look at all the problems and unanswered questions that occur in
comp.unix.x.i386unix of people buying Slackware or the "The big Y's" forgot
how to spell it. Why do you think companies deploy source control and
patch revision control in the first place. With the many thousands of
contributors to Lunix their chaos to control has given proof to the old saying
"Too many cooks spoiled the pot". At admit FreeBSD has a little more
consistentcy to their releases.
So when I can drive up to the Linux in a Box Drive Up Window and whip
my rev card and get my question answered I'll buy into the resale value
of Linux support. I'll just have to check and make sure I don't mistake
my rev number for my SS number.:-)
---Bob
--
+--------------------------------------------------------+
| palo...@fiver.sns.com http://fiver.sns.com/~palowoda/ |
| Solaris x86 Corner http://fiver.sns.com/ |
+--------------------------------------------------------+
So I think that this is the most ridiculeous argument ever heard.
: I think what Tim meant is that it is not a commercial package for the most
: part.
So who cares? I think and my experiences are that signaling a bug and getting
a stable fix for it is then just a couple of days instead of years.
So all those commercial companies should pay attention to their service attitude
Hobbyists are more devoted and have a more long time vision than the short term
policy (next months financial figures) of a bussiness.
: My opinion is that Slackware (being my choice of linux) is fine for running
: email. Is it a huge company? I use slackware now to run our WWW server and
: gopher server. I've also had LESS problems setting slackware email than
: getting email to work on our AIX server, not to mention that Slackware is free.
: Why spend big $$$$ on a unix system when the ONLY thing it is going to be
: used for is email? Maybe you can find some other uses for it as well
: anyways..
Hear hear
: As for service/support.. you can buy a commercial linux and get it.. or just
: subscribe to linux newsgroups where people can help you out.
True true true
I don't want to flame, but some times I can't resist the joy of the reply button.
Victor
>>|> >I have narrowed down to:
>>|> > SCO Unix
>>|> > Sun Solaris
>>|> > IBM AIX
>>|> > Novell Unixware
>>|>
>>|> If you must pick one of these, I'd say Solaris is the most stable.
>>|>
>>
>You can't be serious! Solaris is buggy and **SLOW**.
What version have YOU ever used? We find 2.3 to be quite functional.
2.4 is supposedely even better.
> Personally, I'd
>pick none of the above
There is nothing wrong with SCO either, not as far as stability. We run
our whole hospital on it and I have never seen ANY OS more stable.
--
/--------------------------------------------------------------------------\
| Mark A. Davis | Lake Taylor Hospital | Norfolk,VA (804)-461-5001x431 |
| Director/SysAdmin | Information Systems | ma...@taylor.infi.net |
\--------------------------------------------------------------------------/
Now this is malicious slandering if ever I saw it. Have YOU seen
the patch list for Solaris 2.3 lately?
In fact, the kernel development of Linux is under tight control
of only a handful of people, carefully coordinating patches and
quickly fixing problems as they appear. For standard hardware,
the problems have practically vanished by now (I'm running 1.1.52
-- yes, one of the socalled UNSTABLE kernels, "stable" ones have
an even 2nd digit -- with an uptime of 36 days now and no sign
of a glitch at all). If there is a problem, it is one of
too many ingredients, rather than too many cooks -- there is an
enormous variety of PC cards to cater for and umpteen ways
in which they can step on each others toes. This is a problem
for anybody trying to write OS's for PC's, not just the Linux
operation.
It is the happy users that are counted in thousands!
Of course, the kernel is not the whole thing. There are also a
number of important utilities, being developed along with the
kernel. Some of these seem to have stabilized, whereas others
are constantly being upgraded. This is the main reason for
issuing new distributions of e.g. Slackware. Bear in mind that
several of these packages don't come with the OS on commercial
offerings. There, the sysadmin is the one that has to keep track
of new releases of key PD programs: emacs, gcc, groff, TeX, ...
Most of the problems with Linux and X come from newbies getting
instantly promoted to sysadmins on a Unix system. Of course they
get confused initially. Also, regarding X, the setup is
admittedly a bit complicated, clocks and modelines and all that,
but again this is mainly a matter based on PC hardware. Things
are much easier if you only support only a limited set of
framebuffer/monitor combinations. Once you get past this hurdle,
things are no worse than on Suns (believe me, I've done both).
In fact, Suns are sometimes more of a headache, because they
insist on doing things in nonstandard ways. (Try getting imake
to work properly, e.g.)
As a sysadmin on both Suns and Linux systems, I can assure you
that Slackware has been runnable at a level comparable to SunOS
4.1.x for at least the past year. Remaining problems are nowhere
near comparable to what we are seeing currently with Solaris!
(The argument of wanting to have somebody to sue when things go
wrong is hard to argue against, but don't bash the software
created by extremely talented and seriously working volunteers!)
umount /dev/soapbox
export FLAME=off
--
O_ ---- Peter Dalgaard
c/ /' --- Dept. of Biostatistics
( ) \( ) -- University of Copenhagen
~~~~~~~~~~ - (p...@kubism.ku.dk)
>Kenneth Michelson (kmic...@fas.harvard.edu) wrote:
>
>: As for service/support.. you can buy a commercial linux and get it.. or just
>: subscribe to linux newsgroups where people can help you out.
>
>I'm sorry Ken but "get it" is just not good enough to convence the commercial
>sector that they will recieve a good backing support for Linux. Look at the
>100 of rev's of linux, which one has patches for the network problems? Which
>one has patches for the Xwindows problems, for what version of Xwindows?
>What does Slackware cut a CD a week to keep up with these problems? Just
>look at all the problems and unanswered questions that occur in
>comp.unix.x.i386unix of people buying Slackware or the "The big Y's" forgot
>how to spell it. Why do you think companies deploy source control and
>patch revision control in the first place. With the many thousands of
>contributors to Lunix their chaos to control has given proof to the old saying
>"Too many cooks spoiled the pot". At admit FreeBSD has a little more
>consistentcy to their releases.
Have you tried to compare the number of Linux _development_ releases
(i.e. versions 1.1.xx) or Slackware distribution versions with the
number of patches and bug fixes released by big vendors like IBM or HP?
At least, the Linux fixes come free.
Dan
--
Dan Pop | The only reason God was able to make the
CERN, CN Division | world in 7 days was he didn't have to remain
Email: dan...@cernapo.cern.ch | compatible with the previous version.
Mail: CERN - PPE, Bat. 31 R-004, CH-1211 Geneve 23, Switzerland
Which problems are you referring to ? We're getting Solaris 2.4
to evaluate, and haven't heard anything of such magnitude that
would prompt the above remark. Could you elaborate on major
problems with Solaris 2.4 ?
Thanks,
-Ade Barkah
--
Head of Development
Renaissance Knowledge Systems
Englewood, Colorado
>Now this is malicious slandering if ever I saw it. Have YOU seen
>the patch list for Solaris 2.3 lately?
The patchlist is long, but the majority of patches need not be applied.
We've not applied that many Solaris patches and of the Solaris patches
that we did apply, there's only a very small number that we applied
because we were hit by a bug. Solaris 2.4 can actually run on a umber
of systems w/o applying patches. (Most kernel problems are related to
MP, which is a very difficult subject)
>Most of the problems with Linux and X come from newbies getting
>instantly promoted to sysadmins on a Unix system. Of course they
>get confused initially. Also, regarding X, the setup is
>admittedly a bit complicated, clocks and modelines and all that,
>but again this is mainly a matter based on PC hardware. Things
>are much easier if you only support only a limited set of
>framebuffer/monitor combinations. Once you get past this hurdle,
>things are no worse than on Suns (believe me, I've done both).
>In fact, Suns are sometimes more of a headache, because they
>insist on doing things in nonstandard ways. (Try getting imake
>to work properly, e.g.)
What do you think constitutes the majority of problems with
Solaris 2.x? The majority of migration headaches come from
people who decide that they need to upgrade one weekend and do so.
They're surprised at so many changes.
>As a sysadmin on both Suns and Linux systems, I can assure you
>that Slackware has been runnable at a level comparable to SunOS
>4.1.x for at least the past year. Remaining problems are nowhere
>near comparable to what we are seeing currently with Solaris!
We have have hardly any problems with any of our systems, whether they're
running Solaris or SunOS. The machines are very stable. We hardly
touch the SunOS machines, so they get 400+ day uptimes, but we keep the
Solaris machines current on patches so they get rebooted once a month.
Casper
>Have you tried to compare the number of Linux _development_ releases
>(i.e. versions 1.1.xx) or Slackware distribution versions with the
>number of patches and bug fixes released by big vendors like IBM or HP?
>At least, the Linux fixes come free.
So? That's irrelevant. If that were the case then FreeBSD is 'better'
than Linux simply because we provide hourly releases to the public
that are generally different.
The number of public release is *irrelevant* to the stability of support
of the company. One could argue that fewer releases means more
stability since the number/type of bugs didn't warrant a new release,
but we all know how much merit there is to that statement.
Fact: Every vendor (free or otherwise) make's mistakes in their release.
The measure of how good a vendor is how well they respond to bugs "YOU"
are having, not how many bugs they've fixed. I could care less how may
bugs were fixed in FooBletch OS 2.1 when I never encountered them.
However, I care a great deal when the bugfix breaks OS 2.2, which seems
to happen commonly in the free OS development.
The fact of the matter that since we're not getting paid for it, there
is generally less attention to making sure it works on all supported
hardware. When you are a commercial vendor it's your reputation and
your business on the line. When you're a free OS provider, it's a flood
of email and a quick patch (hopefully).
If you screw up a someone's system and it was free, the worst theing
they can do is mail bomb you. If you're a vendor, you can lose your
job. So, development 'appears' to happen more slowly. You only see
releases when they are fully shaken out by commercial providers, while
with free OS's you see the new OS with all it's warts and blemishes.
Just because a vendor doesn't provide 'patches' and 'bug-fix' releases
doesn't mean they don't fix as many bugs. It means that they do a MUCH
better job of guaranteeing that the fix is the *correct* fix that
doesn't break anything else.
I wouldn't base my company on support from someone who may/may not give
me support depending on how good a day they had. I'd rather base it on
someone who gets paid to hear me whine, and who will make it a priority
to fix MY bug.
Spoken as someone whose done LOTS of free operating system support and
development,
Nate
--
na...@bsd.coe.montana.edu | FreeBSD dude and all around tech.
na...@cs.montana.edu | weenie.
work #: (406) 994-4836 | Unemployed, looking for permanant work in
home #: (406) 586-0579 | CS/EE field.
>Peter Dalgaard SFE (p...@kubism.ku.dk) wrote:
>: ... Slackware has been runnable at a level comparable to SunOS
>: 4.1.x for at least the past year. Remaining problems are nowhere
>: near comparable to what we are seeing currently with Solaris!
>Which problems are you referring to ? We're getting Solaris 2.4
>to evaluate, and haven't heard anything of such magnitude that
>would prompt the above remark. Could you elaborate on major
>problems with Solaris 2.4 ?
Just one: It ain't here.....!
Was referring to things like the 101318-64
(ten-thirteen-eighteen-stroke-sixty-four) patch for 2.3, which
STILL doesn't quite seem to make things like NFS work properly.
>p...@kubism.ku.dk (Peter Dalgaard SFE) writes:
>>Now this is malicious slandering if ever I saw it. Have YOU seen
>>the patch list for Solaris 2.3 lately?
>The patchlist is long, but the majority of patches need not be applied.
>We've not applied that many Solaris patches and of the Solaris patches
>that we did apply, there's only a very small number that we applied
>because we were hit by a bug. Solaris 2.4 can actually run on a umber
>of systems w/o applying patches. (Most kernel problems are related to
>MP, which is a very difficult subject)
I certainly don't want to argue with Casper on this matter. He's
the expert! However note that (a) We're still stuck at 2.3 and
(b) I was reacting to someone bashing my pet toy, Linux.
>>Most of the problems with Linux and X come from newbies getting
>>instantly promoted to sysadmins on a Unix system. Of course they
>>get confused initially. Also, regarding X, the setup is
>>[...]
>What do you think constitutes the majority of problems with
>Solaris 2.x? The majority of migration headaches come from
>people who decide that they need to upgrade one weekend and do so.
>They're surprised at so many changes.
Hmm. I'd hardly characterize myself as a freshly promoted
newbie. We did actually plan pretty carefully before we decided
to upgrade. However, several things came as nasty surprises:
binary non-compatibility for one, we had actually been counting
on not having to upgrade our key freeware applications, but
found that almost every single one had to be recompiled and kept
around in both version, because a few machines could not be
upgraded without losing functionality. Another one was that
workstations with 8Mb became instantly unusable for
OpenWindows. Also, we observed severe performance hits until we
doubled the servers memory.
: Which problems are you referring to ? We're getting Solaris 2.4
: to evaluate, and haven't heard anything of such magnitude that
: would prompt the above remark. Could you elaborate on major
: problems with Solaris 2.4 ?
I'd be interested also.
They are not talking about Solaris 2.4 but earlier versions like Solaris 2.2
or Solaris 2.3. solaris 2.3 with the recommended patchs is known to
be pretty stable but still is nothing compared to Solaris 2.4.
When solaris 2.4 for Sparc ships next week (Dec 6th) these people will
see what Solaris 2.4 Intel users have know for awhile, that Solaris 2.4
is as stable as SunOs 4.1.x.
>When solaris 2.4 for Sparc ships next week (Dec 6th) these people will
>see what Solaris 2.4 Intel users have know for awhile, that Solaris 2.4
>is as stable as SunOs 4.1.x.
Not only that, but SunSoft claims that Solaris 2.4 is now faster than
SunOS 4.1.x... and since Solaris 2.4 now has source compatability between
the Sparc, x86 and PowerPC architectures, this should *hopefully* be seen
across the board (just don't mention Solaris x86 2.1 to me... I'm going to be
glad when I *finally* get a copy of Solaris x86 2.4 workgroup server (I would
have got a copy today, but the UK distributers screwed up....)).
--
Simon
What I think the major problems with Sol is that it is too slow. I
am running it on a 486 DX66 machine with 32MB memory and 64MB swap space,
comparing to linux installed on the same machine, the speed is just
unbearable! Don't know what the reason is.
>There is nothing wrong with SCO either, not as far as stability. We run
>our whole hospital on it and I have never seen ANY OS more stable.
If you can live within it's limitations and are happy using something
based on a product that's so old (how old is 3.2 these days, 7 years?)..
Plus it's overpriced..
--
Larry Snyder, System Adminstrator, GatorNet Internet Connectivity
Lake Mary (Orlando), Florida
la...@rn.com
: >There is nothing wrong with SCO either, not as far as stability. We run
: >our whole hospital on it and I have never seen ANY OS more stable.
: If you can live within it's limitations and are happy using something
: based on a product that's so old (how old is 3.2 these days, 7 years?)..
Well, I must say, that's not a "fair" statement. Indeed SCO
is based on 3.2, but then, so is SVR4. =) It's not like SCO
just let the code stagnate for seven years; they've added
their share of improvements all these times too.
"If it ain't broke..."...
-Ade Barkah
Not to be flippant about this but SunSoft does recommend 16mb minimum with
Solaris. 2.3 pretty much bites in 16mb. 2.4 runs about equal to 4.1.2 in
16mb. 2.4 actually will work in 12mb too.
The extra memory requirement is a tough thing to get around.
We have alot of gunk in Solaris that needs to live somewhere. Alot,
not all, of our customers like that extra stuff.
Kevin Clarke - Speaking for me, not SunSoft.
>>|> >I have narrowed down to:
>>|> > SCO Unix
>>|> > Sun Solaris
>>|> > IBM AIX
>>|> > Novell Unixware
>>|>
>>|> If you must pick one of these, I'd say Solaris is the most stable.
>>|>
>>
>>You can't be serious! Solaris is buggy and **SLOW**.
>What version have YOU ever used? We find 2.3 to be quite functional.
>2.4 is supposedely even better.
Yes it does, except that Sun still can not fix our rpc.nisd dump core
problem as of this writing. They sort of did, at the price of hanging up
two of our productional NIS+ slave servers. Man if you ever played with NIS+
under a 4000 user setup, you would know why Solaris is called Slowwaris. :-)
Keep in mind all our servers are SparcServer 1000s. Unfortunately
they only run Solaris 2.x.
2.4 is faster on the Sun (we discovered), but slowwer on Intel
platform (as compared to 2.3).
Jun
>>is as stable as SunOs 4.1.x.
>Not only that, but SunSoft claims that Solaris 2.4 is now faster than
>SunOS 4.1.x... and since Solaris 2.4 now has source compatability between
>the Sparc, x86 and PowerPC architectures, this should *hopefully* be seen
>across the board (just don't mention Solaris x86 2.1 to me... I'm going to be
>glad when I *finally* get a copy of Solaris x86 2.4 workgroup server (I would
>have got a copy today, but the UK distributers screwed up....)).
I think the more honest assessment is that with 2.4, Solaris is no
longer worse overall than SunOS.
There are certainly things for which Solaris 2.4 is faster than 4.1.x.
On average it is probably no worse, as long as you have enough memory.
But I doubt that a typical user will perceive it as a speedup, and I
think the "feel" on the desktop is that it isn't as snappy. With 2.4
I'd say this is no longer enough of a problem to be bothersome, and
that the advantages of Solaris are now enough to warrant making the
transition. But you should not expect better response from a typical
system. (This assumes you're running the same window system. In our
case X11R5. OpenWindows under 4.1.x is so bad that if you're using
Sun's window system, a move to Solaris probably will give you better
desktop response.)
One area where I do think there's a clear improvement is handling of
many users on a 2-processor SS10, as long they don't do lots of forks.
(Yes, MAXUPC mostly fixes this. But forks still have a lot more
overhead under Solaris than 4.1.x. On a student timesharing system,
an assignment that requires them to use fork is more of a problem
under Solaris than it should be.)
: >I'm sorry Ken but "get it" is just not good enough to convence the commercial
: >sector that they will recieve a good backing support for Linux. Look at the
: >100 of rev's of linux, which one has patches for the network problems? Which
: >one has patches for the Xwindows problems, for what version of Xwindows?
: >What does Slackware cut a CD a week to keep up with these problems? Just
: >look at all the problems and unanswered questions that occur in
: >comp.unix.x.i386unix of people buying Slackware or the "The big Y's" forgot
: >how to spell it. Why do you think companies deploy source control and
: >patch revision control in the first place. With the many thousands of
: >contributors to Lunix their chaos to control has given proof to the old saying
: >"Too many cooks spoiled the pot". At admit FreeBSD has a little more
: >consistentcy to their releases.
: Have you tried to compare the number of Linux _development_ releases
: (i.e. versions 1.1.xx) or Slackware distribution versions with the
: number of patches and bug fixes released by big vendors like IBM or HP?
: At least, the Linux fixes come free.
If you really need a stable, well-tested Linux (without tens of
patches), one can always use 1.0.9, the current non-developmental release.
It's been stable since mid-April, with no patches of any kind since then.
And IMHO the 1.1.x system works pretty well. Even if there is a buggy
patch in one of the releases, it often gets fixed within a week (when other
new things have been plugged in with their own possible bugs :).
For instance, last week I wrote an experimental patch to eliminate
a limit on the number of file locks (it was 64). It used a linked list, which
got clobbered by another piece of code a few lines down (not known to me at
the time). The patch was posted to comp.os.linux.development (labeled
experimental in the subject header), and put into 1.1.67 by Linus Torvalds -
the ONLY person who can post a new version.
(Neither Linus or myself could test the code first - trial by fire
seemed to be the only way..., since I couldn't think of anything to test it on.)
The bug was reported to the newsgroup, and a few days later 1.1.69
came out with a simple bug fix.
IMHO, this shows how the rapid-release system for 1.1.x can work
pretty well. Enhancements get made and bugs get fixed very quickly, and
the more cautious users can wait for 1.2.x to come out before trying it (which
should be very stable upon first release.)
Just my .02 megabytes worth...
- Chad Page
: Dan
>>|> >I have narrowed down to:
>>|> > SCO Unix
>>|> > Sun Solaris
>>|> > IBM AIX
>>|> > Novell Unixware
>>|>
>>|> If you must pick one of these, I'd say Solaris is the most stable.
>>|>
>>
>
>You can't be serious! Solaris is buggy and **SLOW**.
In absolute terms, perhaps. But compared to SCO or Unixware, Solaris looks
good. Don't know much about AIX.
>Personally, I'd
>pick none of the above (although I actually had pretty good results with
>AIX for the PS/2). My first choice would be one of the BSD derivatives:
>BSDI if you need a commercial product that is rock solid, well supported,
>and ultra-fast. FreeBSD if you can live with a "free" product.
Agreed.
: And IMHO the 1.1.x system works pretty well. Even if there is a buggy
: patch in one of the releases, it often gets fixed within a week (when other
: new things have been plugged in with their own possible bugs :).
: For instance, last week I wrote an experimental patch to eliminate
: a limit on the number of file locks (it was 64). It used a linked list, which
: got clobbered by another piece of code a few lines down (not known to me at
: the time). The patch was posted to comp.os.linux.development (labeled
: experimental in the subject header), and put into 1.1.67 by Linus Torvalds -
: the ONLY person who can post a new version.
: (Neither Linus or myself could test the code first - trial by fire
: seemed to be the only way..., since I couldn't think of anything to test it on.)
: The bug was reported to the newsgroup, and a few days later 1.1.69
: came out with a simple bug fix.
: IMHO, this shows how the rapid-release system for 1.1.x can work
: pretty well. Enhancements get made and bugs get fixed very quickly, and
: the more cautious users can wait for 1.2.x to come out before trying it (which
: should be very stable upon first release.)
Wow! Now we really know how quality control works for Linux. "Neither
Linus or myself could test the code first - trial by fire seemed to be the
only way..., since I couldn't think of anything to test it on."
Anyone ever wondered why people in suits don't want free OS's? Here is
the answer for you.
--
+----------------------------------+
Martin Sohnius | "If you can't be funny, |
Novell Labs Europe | at least be interesting." |
Bracknell, England | - Harold W. Ross |
+44-1344-724031 +----------------------------------+
(I speak for myself, not for Novell or anyone else.)
Larry,
I have switched our systems (we're a Hospital Information Systems vendor)
from SCO to UW, so I certainly believe that there is a difference in
performance, stability, reliability, etc between them. Obviously, we believe
that UW is superior. However, that belief is based on empirical data rather
than generalizations about age. (Hell, I'm an old fart *myself* :-)
In short, UW is good enough to stand on it's own merits.
--
Gerry F. Gilmore
Health Systems Resources, Inc.
Atlanta, Ga. E-mail: ger...@atl1.america.net
**********************************************************************
If at first you don't succeed, skydiving is not for you!
**********************************************************************
: As a sysadmin on both Suns and Linux systems, I can assure you
: that Slackware has been runnable at a level comparable to SunOS
: 4.1.x for at least the past year. Remaining problems are nowhere
: near comparable to what we are seeing currently with Solaris!
I am a sysadmin for both Suns and Linux systems. Our main linusx system
has an uptime of over 59 days. We can barely get by on the suns on SunOS
4.1.3 for two weeks without having to reboot for some reason.
=======================================================
| Bob Gerrish |
| Work: Internet: bo...@nta.com |
| NTA, Inc. voice at NTA, Inc.: |
| Federal Way, WA 98063 (206) 874-0600 x459 |
| |
| Personal Addresses: Internet: bo...@andes.pnw.net |
| Prodigy : PFMT36A |
=======================================================
This is NOT the way code is integrated into the other free OS's, and I
would venture to say that no-one is forced to run the 'patch of the day'
release of Linux either.
People in suits 'DO' use free OS's, and saying that they don't is simply
not true. However, for critical projects you NEED to have someone at
the other end of the phone who WILL answer your question and WILL devote
time to fixing YOUR bugs. This is where the free OS's fall short, not
in the way they do development.
Then I guess it is time to upgrade those 4.1.x machines to Solaris 2.4!
Kevin Clarke - SunSoft
With all this discussion of Solaris, I'd like to ask if NFS version 3
is included with the intel version of Solaris. Since Sun was the
co-author (along with DEC) of the June USENIX paper on NFS 3, I'd
expect they'd have it out by now.
We're running NFS 3 on our DEC Alphas running OSF/1. Its pretty
amazing.. I've actually seen over 850k/s on an NFS *write*. And this
is over fairly crappy 10BT wiring.
Any plans for it in the next version of BSDI?
Drew
##############################################################################
# Andrew Gallatin, Computer Project Manager #
# Institute of Statistics and Decision Sciences #
# Box 90251, Duke University, Durham, NC 27708-0251 #
##############################################################################
Of course we have UPS and a very strict change control policy. We don't
play with production systems, or put any software, even SUN patches
without testing them first on a "test" configuration.
Not a small operation either, we have over 300 Sun Sparcs, mostly
Sparc 2's, but fair amounts of 1+s, 10s and 20s. We also have
about 150 HP systems, all networked and stable as well.
My advice to you would be to develop a change management process and
don't accept the "let's try this" attitude from your support contacts;
demand root cause analysis and prompt problem resolution! Beleive me,
your clients will notice and be happy with you$$$.
Albert
>I am a sysadmin for both Suns and Linux systems. Our main linusx system
>has an uptime of over 59 days. We can barely get by on the suns on SunOS
>4.1.3 for two weeks without having to reboot for some reason.
We only reboot Suns when we install patches that require a reboot or
when they need to be moved. The SunOS 4.1.x machines stay op for more than
a year at the time.
Casper
>pag...@netcom.com wrote:
>
>: And IMHO the 1.1.x system works pretty well. Even if there is a buggy
>: patch in one of the releases, it often gets fixed within a week (when other
>: new things have been plugged in with their own possible bugs :).
>
>: For instance, last week I wrote an experimental patch to eliminate
>: a limit on the number of file locks (it was 64). It used a linked list, which
>: got clobbered by another piece of code a few lines down (not known to me at
>: the time). The patch was posted to comp.os.linux.development (labeled
>: experimental in the subject header), and put into 1.1.67 by Linus Torvalds -
>: the ONLY person who can post a new version.
>
>: (Neither Linus or myself could test the code first - trial by fire
>: seemed to be the only way..., since I couldn't think of anything to test it on.)
>
>: The bug was reported to the newsgroup, and a few days later 1.1.69
>: came out with a simple bug fix.
>
>: IMHO, this shows how the rapid-release system for 1.1.x can work
>: pretty well. Enhancements get made and bugs get fixed very quickly, and
>: the more cautious users can wait for 1.2.x to come out before trying it (which
>: should be very stable upon first release.)
>
>Wow! Now we really know how quality control works for Linux. "Neither
>Linus or myself could test the code first - trial by fire seemed to be the
>only way..., since I couldn't think of anything to test it on."
>
>Anyone ever wondered why people in suits don't want free OS's? Here is
>the answer for you.
Nope. Versions 1.1.* are _test_ versions and all the people using them
are testers. If you offer such a version to a suit and get fired, don't
blame Linux.
Has Novell ever released test versions, labeled as such? Did they ever
receive bug reports for these versions? Moreover, did they ever
receive bug reports for _production_ versions of UnixWare?
Anyone ever wondered why people in suits don't want commercial OS's?
Here is the answer for you.
:-)
>pag...@netcom.com wrote:
>: (Neither Linus or myself could test the code first - trial by fire
>: seemed to be the only way..., since I couldn't think of anything to test it on.)
>: The bug was reported to the newsgroup, and a few days later 1.1.69
>: came out with a simple bug fix.
>: IMHO, this shows how the rapid-release system for 1.1.x can work
>: pretty well. Enhancements get made and bugs get fixed very quickly, and
>: the more cautious users can wait for 1.2.x to come out before trying it (which
>: should be very stable upon first release.)
>Wow! Now we really know how quality control works for Linux. "Neither
>Linus or myself could test the code first - trial by fire seemed to be the
>only way..., since I couldn't think of anything to test it on."
>Anyone ever wondered why people in suits don't want free OS's? Here is
>the answer for you.
But this is a ridiculous objection. No one *had* to install the 1.1.67
patch or the 1.1.69 patch. The 1.1.x series is a new revision *in
development*. They are labelled as such. If you want an official stable
release, use 1.0.9. If you want new features before they become part of a
stable release, then you can apply patches and upgrade, but you have to
understand before you do that, that you are participating in a beta test
cycle. Even with that in mind, several of the 1.1.x series kernels are
quite stable.
And I can tell you that commercial products sometimes add new features of
fixes in exactly the same way as described above for Linux. "Don't know
if this will do the trick, but let's throw it at the beta testers, see if
they yell." Of course, most people never see that going on, since
commercial products are rarely developed in public. If they were, you'd
see the same sort of things going on.
--
\\\ Mike Batchelor /// mik...@clark.net \\\ M.Bat...@babylon4.clark.net ///
"Supporting Windows is like buying a puppy. The dog only cost $100, but
we spent another $500 cleaning the carpet."
- Marc Dodge, "Reality Check", _Open Computing_, December 1994
> Wow! Now we really know how quality control works for Linux. "Neither
> Linus or myself could test the code first - trial by fire seemed to be the
> only way..., since I couldn't think of anything to test it on."
>
> Anyone ever wondered why people in suits don't want free OS's? Here is
> the answer for you.
Of course, NetBSD and FreeBSD are developed in a somewhat different
fashion to Linux so I think you're over-generalizing here just a little...
--
Scott Telford, Edinburgh Parallel Computing Centre, <s.te...@ed.ac.uk>
University of Edinburgh, Mayfield Rd, Edinburgh, EH9 3JZ, UK.(+44 131 650 5978)
-- "We do want to tour again, we will tour again" - Kate Bush, Munich, 1980. --
I'd rather suggest that they consider installing some patches for 4.1.3.
Our general impression here is that 4.1.3 (suitably patched) is still
much more stable than 2.3 (suitably patched). Uptime of 59 days is *not*
particularly impressive - we have many 4.1.3 systems which have been up
much longer than that.
Steinar Haug, SINTEF RUNIT, University of Trondheim, NORWAY
Email: Steina...@runit.sintef.no
>I'd rather suggest that they consider installing some patches for 4.1.3.
>Our general impression here is that 4.1.3 (suitably patched) is still
>much more stable than 2.3 (suitably patched). Uptime of 59 days is *not*
>particularly impressive - we have many 4.1.3 systems which have been up
>much longer than that.
(Is this going to be another my uptime is bigger than yours battle?).
We have average uptimes > 100 days. (Averaged over > 100 machines)
Some machines stay up for 450+ days.
Casper
Wow! Now we really know how quality control works for Linux. "Neither
Linus or myself could test the code first - trial by fire seemed to be the
only way..., since I couldn't think of anything to test it on."
Anyone ever wondered why people in suits don't want free OS's? Here is
the answer for you.
Let me guarantee you, firsthand, that it doesn't work this way under
NetBSD. The core team is *very* strict about "correct" code, whether
it belongs in the kernel at all, and if it has been thoroughly tested.
Even then, they rarely integrate a patch directly from the
contributor, but look it over and rewrite it into the appropriate
place by hand, so as to have the most amount of thought applied
throughout the process.
(From an occasional NetBSD code contributor...)
--
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
Michael L. VanLoon mich...@HeadCandy.com mich...@iastate.edu
Free your mind and your machine -- NetBSD free un*x for PC/Mac/Amiga/etc.
Working NetBSD ports: 386+PC, Mac, Amiga, HP300, Sun3, Sun4c, PC532
In progress: DEC pmax (MIPS R2k/3k), VAX, Sun4m
- - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - - -
thanks,
Jack Fijolek
-----Begin Included Message--------------------------------
Standards:
Both are based on UNIX SVR4, so apps should port readily between
the two. Solaris does seem to support a wider range of standards and
is more aggressive in incorporating new technologies.
Processor Portability:
Solaris runs on Intel, Power PC and SPARC.
UNIX Ware is only available on Intel.
UnixWare is definitely Intel only, but so are we.
Market Presence:
The initial release of Intel solaris got off to a slow start because it
did use the lateste technology. This has been fixed with the 2.4 release
and in the future all platfom versions of solaris will have the
same feature set. In the overall UNIX market, Solaris is the leading UNIX
derivitive. In the Intel UNIX market , SCO is the leader (not SVR4 based)
with UNIXware and IntelSolaris trailing behind. Press reports have
indicated that they expect Intel Solaris to gain momentum with the
2.4 release.
Features:
Solaris is a more feature rich platform than UNIX ware.
The major advanatge of UNIX ware is its integration with NOvell's
Netware Presence in PC networking. If Novell network connectivity
is not a requirement, then the value of UNIX ware is greatly diminished.
Sales / Support:
UNIXware is distributed via resellers, where SOlaris is sold
directly by SunSOft. I suspect better support is facilitated
via the direct route. Our experience with Solairs support has been goo(but not great).
Applications:
There are over 3000 applications (tools, add-on devices, etc.) for
Sparc SOlaris. To date 700 of these have migrated to the Intel version.
It is expected that more will migrate with Solaris 2.4.
MicroSOft WIndows App Support:
Solaris includes a facility for running MS windoows apps in the UNIX
environment (called WABI). Other UNIX vensors are liscensing WABI, but I
dont know if UNIX ware is one of them.
Object Support:
If you are considering obect oriented development approaches. Soalris
will be incorporating the NextStep object development environment which
is considered the leading object development environment.
Network Management / OA&M:
Solaris includes standard network management agents and applications as well
as easy to use interfaces for users and administrators.
UNIX ware does not offer as much in this regard.
Future:
Solaris is much more strategic to SUN than UNIXware is to Novell. Recent
history and future projections indicate that Solaris is more likely
to be evolved to support new/emerging technologies.
I`m continuing to research this to find a more detailed feature comparison.
There are other users of Intel Solaris on the campus which you may also
want to contact. I 'll pass along additional info as I get it. Please
feel free to call me to discuss.
----End Included Message-------
Let's make an analogy using Windows. If you were able to buy the source
code for Windows 3.1, do you think you would have a product to sell in
the face of the impending Windows95? Even if you were able to hire
on most of the W95 developers the public wouldn't be very interested,
regardless of what improvements you made. As far as SVR4 being based
on 3.2, well yes, but then again, there are a hell of a lot of
differences, too.
Bottom line? Once the "public" realizes the difference, and UW gains
the perception of being a realiable, mission critical OS, SCO is in
trouble.
--
Bob Stewart (KB9ZW)
wk +1 310 335-7152
eden{wib} rup idefix
idefix up 473 days, 3:54, load average: 0.09, 0.06, 0.00
eden{wib} rsh idefix uname -a
SunOS idefix 4.1.3 3 sun4c
Willi
--
Willi Burmeister, Department of Computer Science, Kiel University
Tel: +49 431 5604 98 S-Mail: Preusserstrasse 1-9, D 24105 Kiel
Fax: +49 431 5661 43 E-mail: w...@cs.uni-kiel.de
: : As a sysadmin on both Suns and Linux systems, I can assure you
: : that Slackware has been runnable at a level comparable to SunOS
: : 4.1.x for at least the past year. Remaining problems are nowhere
: : near comparable to what we are seeing currently with Solaris!
I wouldn't quite say that. Linux's TCP and NFS have only recently
become somewhat useable. You can't call any unix type thing runnable
until the TCP and NFS works.
: I am a sysadmin for both Suns and Linux systems. Our main linusx system
: has an uptime of over 59 days. We can barely get by on the suns on SunOS
: 4.1.3 for two weeks without having to reboot for some reason.
I am not overly happy with the stability of SunOS 4.1.3 or Solaris 2.3
either. However, your comparison may be somewhat unfair. I would bet
that your Sun box is banged on quite a lot more than your Linux box is.
[...]
: >Wow! Now we really know how quality control works for Linux. "Neither
: >Linus or myself could test the code first - trial by fire seemed to be the
: >only way..., since I couldn't think of anything to test it on."
: >
: >Anyone ever wondered why people in suits don't want free OS's? Here is
: >the answer for you.
: Nope. Versions 1.1.* are _test_ versions and all the people using them
: are testers. If you offer such a version to a suit and get fired, don't
: blame Linux.
The point is that haphazard "trial by fire" is not an appropriate test
methodology. Pentium chips get divisions right most of the time, after all.
: Has Novell ever released test versions, labeled as such?
Yes. They are called beta releases.
: Did they ever
: receive bug reports for these versions?
Yes.
: Moreover, did they ever
: receive bug reports for _production_ versions of UnixWare?
Yes. What are you actually trying to say/imply?
: Anyone ever wondered why people in suits don't want commercial OS's?
: Here is the answer for you.
You didn't make any statement related to commercial OSes. Instead, you
asked three questions whose rhetoric escapes me. What is the "answer" you
are talking about?
: And I can tell you that commercial products sometimes add new features of
: fixes in exactly the same way as described above for Linux. "Don't know
: if this will do the trick, but let's throw it at the beta testers, see if
: they yell." Of course, most people never see that going on, since
: commercial products are rarely developed in public. If they were, you'd
: see the same sort of things going on.
You are wrong. Commercial products don't get developed in public, but they
do get developed here. And the procedure you describe is not the one used.
>Dan Pop (dan...@cernapo.cern.ch) wrote:
[...]
>: Has Novell ever released test versions, labeled as such?
>Yes. They are called beta releases.
>: Did they ever
>: receive bug reports for these versions?
>Yes.
>: Moreover, did they ever
>: receive bug reports for _production_ versions of UnixWare?
>Yes. What are you actually trying to say/imply?
>: Anyone ever wondered why people in suits don't want commercial OS's?
>: Here is the answer for you.
>You didn't make any statement related to commercial OSes. Instead, you
>asked three questions whose rhetoric escapes me. What is the "answer" you
>are talking about?
What Dan was trying to get accross, I believe, is that the 1.1.xx where
xx is some number that was referred to previously, is just that, a
*BETA* release. You were saying how shitty Linux QC was, and Dan gave
an example of the exact same process in the corporate world...
If you want a Linux kernel that is stable, etc., don't run the daily
development version [ie, the *BETA* version], run a blessed and stable
release version. If you're hacking on the kernel, you might want that
beta version, and hence it's out there and available....
Note: I don't use Linux, I know very little about the specifics of what
was being discussed, but I did catch the subtle implications you seemed
to brush away with your broad-conclusion brush....
--rafal
A happy NetBSD/i386 user...
/--------------------------------------------------------------------------\
|"Blessed are the meek, for they shall inherit | Rafal Boni |
| 15% of the earth, which is 100% more than they | r-b...@uiuc.edu |
| have now..." -Cartoon caption in New Yorker | My opinions, not UIUC's |
\--------------------------------------------------------------------------/
If Novell's stuff is worth the money, people will buy it. If it's not,
they won't. To take an example we've got a longer history of, decent
free compilers like gcc didn't kill off for-money compilers: they just
raised the game. To make money out of a C compiler you need it to be
better in some way than gcc: that may be difficult, but that's tough.
ian
seuss:/a/kevin/export/u8 (567)
$ rsh fulcrum uptime
5:03pm up 160 days, 9:28, 0 user, load average: 0.60, 0.59, 0.50
seuss:/a/kevin/export/u8 (568)
$ rsh fulcrum uname -a
SunOS fulcrum.f 4.1.2 6 sun4c
ian
This is a subjective statement. What criteria was used when the statement
the Solaris agressively persues new technologies? How about new technologies
such as NetWare support? How about CDE (Both Sun and Novell contribute here).
What aggressive technology has Sun persued that has not been persued by
Novell?
|>
|> Processor Portability:
|>
|> Solaris runs on Intel, Power PC and SPARC.
|> UNIX Ware is only available on Intel.
|> UnixWare is definitely Intel only, but so are we.
Novell provides UnixWare for Intel. ICL provides UnixWare for SPARC.
When is the PowerPC port of Solaris going to be available?
|>
|>
|> Market Presence:
|> The initial release of Intel solaris got off to a slow start because it
|> did use the lateste technology. This has been fixed with the 2.4 release
|> and in the future all platfom versions of solaris will have the
|> same feature set. In the overall UNIX market, Solaris is the leading UNIX
|> derivitive. In the Intel UNIX market , SCO is the leader (not SVR4 based)
|> with UNIXware and IntelSolaris trailing behind. Press reports have
|> indicated that they expect Intel Solaris to gain momentum with the
|> 2.4 release.
How many licenses of Solaris does Sun have? How many of their Unix licenses
are still Sun OS 4.x. Yes, Sun has the claim that they have sold the
most Unix licenses but how many are Solaris? (I am refering to Solaris 2.x).
Press reports also indicate that UnixWare 2.0 is expected to gain momentum.
I guess it all depends on what the customer buys.
|>
|> Features:
|> Solaris is a more feature rich platform than UNIX ware.
|> The major advanatge of UNIX ware is its integration with NOvell's
|> Netware Presence in PC networking. If Novell network connectivity
|> is not a requirement, then the value of UNIX ware is greatly diminished.
Yet another subjective statement. What criteria was used in determining
feature rich. What features does Solaris have that are not present in
UnixWare? How many features does UnixWare have the Solaris doesn't? :^)
How about price? The value of UnixWare is not diminished at all if you
are not going to use the NetWare connectivity. UnixWare is just as capable
OS as is Solaris. You choose what you need.
|>
|> Sales / Support:
|> UNIXware is distributed via resellers, where SOlaris is sold
|> directly by SunSOft. I suspect better support is facilitated
|> via the direct route. Our experience with Solairs support has been goo(but not great).
|>
I believe one of the VARs such as Evan can answer how resellers are better
suited to handle you than direct route. How about having them close at
hand when problems arise? Novell also provides direct support through
support contracts and the 1-800-NETWARE number. You decide what support
you need.
|> Applications:
|>
|> There are over 3000 applications (tools, add-on devices, etc.) for
|> Sparc SOlaris. To date 700 of these have migrated to the Intel version.
|> It is expected that more will migrate with Solaris 2.4.
Applications on Intel Unixs are a moot point. I think you will find that
Intel Unix is supported in general the same. Drivers may be a bigger issue
since Solaris has chosen a different route for their drivers. Remember,
Novell is leveraging their PC presence and the Novell Labs YES program. :^)
I think you will find that Novell has more PC muscle than Sun (IMO).
|>
|> MicroSOft WIndows App Support:
|> Solaris includes a facility for running MS windoows apps in the UNIX
|> environment (called WABI). Other UNIX vensors are liscensing WABI, but I
|> dont know if UNIX ware is one of them.
We provide Advanced Merge which is capable of running Window apps as well.
Which one runs your Windows apps? We are also a licensor of WABI.
|>
|> Object Support:
|> If you are considering obect oriented development approaches. Soalris
|> will be incorporating the NextStep object development environment which
|> is considered the leading object development environment.
Currently (And I emphasize currently) rely on third party vendors for
object support. We do provide a full C/C++ development environment for
UnixWare. Is NextStep the leading object environment? Will it be? Only
you can decide how important this is to you. Novell is persueing object
technology just like the rest of the industry. The jury is still out
on object technology. Some say NeXTstep, some say Taligent, some say
Cairo [I don't know why though :^) ]. There are many third party options
as well.
|>
|> Network Management / OA&M:
|> Solaris includes standard network management agents and applications as well
|> as easy to use interfaces for users and administrators.
|> UNIX ware does not offer as much in this regard.
Our network management tools are improving, after all we are the largest
network software company in the world. We provide many of the same
network tool the Solaris does. I can not say for sure though because I
haven't seen all the tools provided in Solaris and how they differ to UnixWare.
|>
|> Future:
|>
|> Solaris is much more strategic to SUN than UNIXware is to Novell. Recent
|> history and future projections indicate that Solaris is more likely
|> to be evolved to support new/emerging technologies.
How many subjective statements are they going to make. What makes people think
that UnixWare is not strategic to Novell? What makes people think that
UnixWare is going to stagnate into UnixWare 1.x forever. UnixWare 2.0 will
soon be available and we are working on future projects. No company that
stays in business allows their technology to stagnate. Don't expect Novell
to let that happen either. Sun is our competitor too! We will compete!
|>
|> I`m continuing to research this to find a more detailed feature comparison.
|> There are other users of Intel Solaris on the campus which you may also
|> want to contact. I 'll pass along additional info as I get it. Please
|> feel free to call me to discuss.
|> ----End Included Message-------
Contact Novell as well.
Darren R. Davis
UnixWare Developer Support Engineer
Novell Developer Support
> >: As a sysadmin on both Suns and Linux systems, I can assure you
> >: that Slackware has been runnable at a level comparable to SunOS
> >: 4.1.x for at least the past year. Remaining problems are nowhere
> >: near comparable to what we are seeing currently with Solaris!
> >I am a sysadmin for both Suns and Linux systems. Our main linusx system
> >has an uptime of over 59 days. We can barely get by on the suns on SunOS
> >4.1.3 for two weeks without having to reboot for some reason.
> Then I guess it is time to upgrade those 4.1.x machines to Solaris 2.4!
> Kevin Clarke - SunSoft
are you seriously maintaining, with your bare face hanging out, that
solaris 2.4 regularly goes longer without rebooting than sunos 4.1.3.u1
or sunos 4.1.4?
josh
: idefix up 473 days, 3:54, load average: 0.09, 0.06, 0.00
: Willi
Hello Willi,
So, who can keep it up the longest?
(But then, shouldn't it be 3" 54/64 instead of 3:54? And is it really fun
to keep it up that long with such a low load average?)
:=)
What's "odd" about it? I'll stop railing against your development process
once you stop railing against our price and the fact that we don't ship
source. Is that a deal?
This is getting interesting! So Ian's Fulcrum has been up for 160 days,
as compared to Willi's Idefix which has been up for over 400. But then,
Ian's is 9:28, not just 3:54, and is obviously seeing much more action,
too.
:=)
>are you seriously maintaining, with your bare face hanging out, that
>solaris 2.4 regularly goes longer without rebooting than sunos 4.1.3.u1
>or sunos 4.1.4?
Well, SunOS 4.1.4 has a one month head start (2.4 isn't offically out yet).
Do you have any evidence to the contrary?
Casper
Not.
1) cachefs
2) better NFS in general
3) thread support
4) a much more standard and full set of code libraries
5) a better X server
6) a better X environment
7) MAE availability [on sparc]
8) working man pages
9) a proper sysvr4 kernal that doesn't have to be compiled
10) better compilers/tools available (centerline, purify, ...) [on sparc]
Do you think 10 reasons comprises "more capable", or should I go on?
Oh, yeah? :-)
Our Solbourne running SunOS 4.1.*1* regularly stays up longer than 100 days.
And it runs Ingres and about 40 regular users doing nearly everything you
can think of. We usually reboot after a few months because "it's time".
My SS IPC, running 5.3 (kernel patch -31) has been up for 57 days. And I
vaguely recall that it was rebooted then to replace the CD-ROM drive.
--
Ruth Milner NRAO/VLA Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
>In <3c1aj3$b...@mail.fwi.uva.nl> cas...@fwi.uva.nl (Casper H.S. Dik) writes:
>>bo...@pnw.net (Robert Gerrish) writes:
>
>>>I am a sysadmin for both Suns and Linux systems. Our main linusx system
>>>has an uptime of over 59 days. We can barely get by on the suns on SunOS
>>>4.1.3 for two weeks without having to reboot for some reason.
>
>>We only reboot Suns when we install patches that require a reboot or
>>when they need to be moved. The SunOS 4.1.x machines stay op for more than
>>a year at the time.
>
>eden{wib} rup idefix
> idefix up 473 days, 3:54, load average: 0.09, 0.06, 0.00
>eden{wib} rsh idefix uname -a
>SunOS idefix 4.1.3 3 sun4c
>
Which shows that an idle SunOS box can stay up for quite a long while :-)
No. I would rather consider it as evidence that somebody who claims
"We can barely get by on the suns on SunOS 4.1.3 for two weeks without
having to reboot for some reason."
has a serious problem, and should do something about it.
[ I'll skip down to the part where I'm dragged in :-) ]
>|> Sales / Support:
>|> UNIXware is distributed via resellers, where SOlaris is sold
>|> directly by SunSOft. I suspect better support is facilitated
>|> via the direct route. Our experience with Solairs support has
>|> been goo(but not great).
>I believe one of the VARs such as Evan can answer how resellers are better
>suited to handle you than direct route.
It depends on circumstance. I obviously have my biases, but I'll readily
admit that there are times when the VAR/reseller route is not necessarily
a big advantage. The large customer or developer who has significant
in-house Unix smarts, is prepared to not just have Internet access
but depend on it, and knows the product lines of their vendor(s)
intimately, doesn't really gain a lot by having a VAR in the loop.
It's been my experience that the number of present (and potential)
users of Intel-based Unix that fit this category is fairly small.
But it also explains why I as a VAR don't really have a problem with
the Novell program that sold direct to developers.
To look at another vendor of Intel Unix that received a reputation of
"VAR-hostile", I use the example of Dell. That company produced what
many people still consider the best-ever implementation of SVR4.0 for
Intel. It was reasonably priced, had many bug fixes in the USL code
(that other OEMs didn't discover), bundled in a *ton* of stuff, and
had a support team that was both passionate and competent.
But Dell Unix died a fairly painful death as products go. Dell, like
SunSoft, shunned VARs and sold direct. This approach worked fine
for those who knew what they were doing. But most end-users, the kind
who don't even know what a Unix is, let alone that their vertical app
is running on it, never heard of Dell Unix. Their exposure to Unix was
*exclusively* through the VAR channel, which to date has been the
main path for SCO to go. Solaris and Novell alike would love to have
SCO's market share in this corner of the world -- study carefully how
they got there. Hint: SCO doesn't sell direct.
The downside of resellers and VARs is, by far, finding the right one.
Getting authorization for most of the vendors is still relatively easy,
and even so there are precious few resellers who really know their OS
beyond installation and being able to run specific pieces of application
software. It's important to get one who knows the product, its bugs and
fixes, timing and availability of fixes and updates, and different means
of getting help.
SCO has, through sheer inertia, built up a loyal following of VARs,
which is why Novell and SunSoft have an uphill battle no matter how
technically advanced their stuff is. The difference is, though, that
Novell has chosen to take on SCO on its own turf, while SunSoft has
chosen just to ignore that sector and appeal direct.
For any given installation, all this may not matter. But for the
developer trying to determine which platforms will be deployed most in
the field, which will have the critical mass which attracts software ports
and third-party support, I just can't see Solaris getting the installed
base of SCO or UnixWare in the medium to long term.
Amongst those to whom a computer system is an end unto itself, Intel
Solaris may even be better (heck, so might Linux!); but to those for
whom a computer is an intelligent toaster, an appliance to be used for
some other goal, I just can't see a direct-sales approach working at all.
--
Evan Leibovitch, Sound Software Ltd., located in beautiful Brampton, Ontario
Novell Unix Master Reseller / ev...@telly.on.ca / (905) 452-0504
Are vegetarians allowed to eat animal crackers?
The only reason I've ever had to reboot 2.3 machines has been because of
101318-64 problems, and we all make mistakes once in a while. We've got
some machines on an early-access Solaris 2.4 and they've all been up
since they were installed ten days ago.
On the other hand, our 4.1.2 machines have mostly been up since the last
time we had a mains outage, most of them showing uptimes around 160
days. We restarted all our 2.3 machines to update to the latest patches
a few weeks ago, and have been doing so on a fortnightly basis, so we
don't know what uptimes we would see if they were left to free-run.
ian
Loads of action, in fact. Two inbound NNTP news feeds, four outbound
UUCP feeds, full newsreading from everyone on site, main mail gateway,
DNS primary, DNS secondary for quite a few people (incuding a
University, which is quite fun in there days of round-robin RR), NTP
primary...and it's only an ELC with 32MBytes in it!
PID TT STAT TIME COMMAND
0 ? D 58:49 swapper
1 ? IW 16:11 /sbin/init -
2 ? D 0:37 pagedaemon
51 ? IW 38:06 portmap
56 ? IW 0:00 keyserv
65 ? S 52:59 in.routed
72 ? I 0:00 (biod)
73 ? I 0:00 (biod)
74 ? I 0:00 (biod)
75 ? I 0:00 (biod)
99 ? IW 0:00 rpc.bootparamd
102 ? IW 0:00 rpc.lockd
104 ? IW 0:00 rpc.statd
130 ? S 358:13 /usr/lib/newsbin/msgidd -s /usr/lib/news/nntp_msgid -h 120
132 ? IW 0:00 /usr/bin/X11/xdm
135 ? S 8:47 /usr/bin/X11/X -fp tcp/doctor-seuss:7100 :0
138 ? I 2162:44 update
141 ? IW 0:00 -:0 (xdm)
142 ? IW 55:13 cron
149 ? S 53:14 xinetd -syslog auth -pid
157 ? IW 0:00 /usr/lib/lpd
160 ? S 25:09 /usr/bin/X11/xconsole
3363 ? IW 0:00 xinetd rusers d in terc
3364 ? IW 0:00 rpc.rusersd
15141 ? S 447:00 /usr/etc/in.named
23008 ? IW 0:22 -fotogenix.fulcrum.co.uk LIST (in.nntpd.t5.minfr)
23504 ? IW 1:29 /bin/sh /usr/lib/newsbin/expired
24480 ? IW 0:04 -getafix.fulcrum.co.uk BODY (in.nntpd.t5.minfr)
25022 ? IW 0:03 -clockwork-orange.fulcrum.co.uk HEAD (in.nntpd.t5.minfr)
25208 ? IW 0:05 -doctor-seuss.fulcrum.co.uk HEAD (in.nntpd.t5.minfr)
25242 ? IW 0:17 -cornelius.fulcrum.co.uk HEAD (in.nntpd.t5.minfr)
25317 ? IW 0:04 -licinius.fulcrum.co.uk BODY (in.nntpd.t5.minfr)
25361 ? IW 0:00 sleep 3600
25665 ? IW 0:05 -fruitbat.fulcrum.co.uk ARTICLE (in.nntpd.t5.minfr)
25741 ? S 0:06 -doctor-seuss.fulcrum.co.uk HEAD (in.nntpd.t5.minfr)
26130 ? S 0:02 -furius.fulcrum.co.uk ARTICLE (in.nntpd.t5.minfr)
26297 ? S 0:00 -violet.csv.warwick.ac.uk IHAVE (in.nntpd.t5.minfr)
26333 ? S 0:00 -marble.britain.eu.net IHAVE (in.nntpd.t5.minfr)
26338 ? S 0:00 in.rshd
26339 ? S 0:00 csh -c ps -ax
26340 ? R 0:00 ps -ax
26341 ? R 0:00 -sun4.bham.ac.uk (in.nntpd.t5.minfr)
29200 ? IW 12:26 sendmail: accepting connections
87 co S 48:00 syslogd
114 om S < 129:05 /usr/etc/in.xntpd
: ian
I think there is a couple of ways at looking at it. First lets see
Linux from "Just Computers" cost at minimum 57.95. The Linux Professional
package cost 229.95 (Slackware) and a bunch of books. Of coarse you
can get it free but than what do say about the people buying the
CDROM's. The most ironic view is it makes a laughing stock of the
GNU License which it so proudly promotes. I'm sure later on that
distributors of the CD's will add proprieetary install programs
and other programs to commercialize the distribution. No big deal
no body is going to sue them, nobody can. So I guess you could
say Linux has two faces one free available from source on the
net and the other value added. Should one expect the development
efforts of the free one to meet some sort of expectations of
the "not free one"? And ultimately where does the support for
the "not free one" originate from?
Second, alot of the Linux community seems to want commercial
applications ported to it. Or at least run on Linux. WP from
Novell comes to mind. If anything I don't see why employee's
of Novell would not want to express opinions on the support
and quality of development efforts of Linux. If WP core dumps
because of a bug in Linux (the free or commercial version)
the enduser cannot easily determine the fault. What's even
worse is the finger pointing and the "well it's free" anyways
answer. Should Novell and WP be concerned?
I actually think Linux is a decent OS (needs improvement on
some of the network features). But it's still not clear
to "me" the way it is supported in the commercial versions.
I have noticed Linux users are sensitive about this issue.
Hopefully in the future the Linux community will make more efforts
in how they are going to support the "free and commercial"
versions.
Off the subject, does anyone have a hardware list of supported
devices for Linux?
---Bob
--
+--------------------------------------------------------+
| palo...@fiver.sns.com http://fiver.sns.com/~palowoda/ |
| Solaris x86 Corner http://fiver.sns.com/ |
+--------------------------------------------------------+
>I am a sysadmin for both Suns and Linux systems. Our main linusx system
>has an uptime of over 59 days. We can barely get by on the suns on SunOS
>4.1.3 for two weeks without having to reboot for some reason.
Have you tried appropriate kernel tuning? I use a Sparc 2 with SunOS4.1.3
for our primary news server here. Our last reboot was 36 days ago, but
that was for hardware maintenance. We did have problems before customising
the kernel for the uses of the machine, mostly not enough processes or IP
channels to handle the feeds and readers. More RAM was a big help too.
Mike
--
LCDR M. Dobson | NetNews Admin info.usuhs.mil
Experimental Hematology Dept | dob...@info.usuhs.mil
Armed Forces Radiobiology |
Research Institute | I don't have enough rank to speak for DoD
Jeeez guys... would you please move this thread to alt.folklore.something
and continue your bickering (not only Martin's) away from these groups?
Who the hell crossposted this crap anyways?...
Sorry, but this whole thing is getting silly. OS such-and-such exists because
someone thought that there is a demand for it and that someone would buy it.
And if an OS has been around for a while there are two options of what might
have happened. Either there is a giant backing the uselessness of an OS with
financial power or someone else thought that there is a use for an OS and
evidently bought it.
Accept that different OS are made for different demands. Ok? As much as there
are different demands there are different ways to satisfy these demands, and
one of them is also to leave customers unsatisfied. I've worked with HP, SUN,
IBM, Cray (and a whole bunch more vendors, no particular order) and they all
have problems.
Get real. And stop being religious. And also this thread.
Thank you for your patience.
Regards,
Chris
: >Dan Pop (dan...@cernapo.cern.ch) wrote:
: [...]
: >: Has Novell ever released test versions, labeled as such?
: >Yes. They are called beta releases.
: >: Did they ever
: >: receive bug reports for these versions?
: >Yes.
: >: Moreover, did they ever
: >: receive bug reports for _production_ versions of UnixWare?
: >Yes. What are you actually trying to say/imply?
: >: Anyone ever wondered why people in suits don't want commercial OS's?
: >: Here is the answer for you.
: >You didn't make any statement related to commercial OSes. Instead, you
: >asked three questions whose rhetoric escapes me. What is the "answer" you
: >are talking about?
: What Dan was trying to get accross, I believe, is that the 1.1.xx where
: xx is some number that was referred to previously, is just that, a
: *BETA* release.
Thanks for clarifying this. I had honestly not grasped Dan's point. But
now that you are telling me, I can at least answer it!
: You were saying how shitty Linux QC was, and Dan gave
: an example of the exact same process in the corporate world...
No, he did not (which may well be why the point escaped me!). No-one here
would take the attitude "I can't think of any way of testing this, so let's
put it into a beta release and see what happens." If it makes it into beta,
it has already undergone quite a bit of testing. The point of beta testing
is to expose it to all the conditions the original testers didn't think of!
It's not to make their life easier.
: If you want a Linux kernel that is stable, etc., don't run the daily
: development version [ie, the *BETA* version], run a blessed and stable
: release version. If you're hacking on the kernel, you might want that
: beta version, and hence it's out there and available....
Actually, I suppose where I was indeed unfair, is that those odd-numbered
releases (or whatever) are actually not beta at all: they are alpha at best;
the code that's shipped to fellow developers to have a look at.
: Note: I don't use Linux, I know very little about the specifics of what
: was being discussed, but I did catch the subtle implications you seemed
: to brush away with your broad-conclusion brush....
Good for you.
: /--------------------------------------------------------------------------\
: |"Blessed are the meek, for they shall inherit | Rafal Boni |
: | 15% of the earth, which is 100% more than they | r-b...@uiuc.edu |
: | have now..." -Cartoon caption in New Yorker | My opinions, not UIUC's |
: \--------------------------------------------------------------------------/
Looks like we do share at least one thing: New Yorker references in .sig :=)
[...]
>: >: Anyone ever wondered why people in suits don't want commercial OS's?
>: >: Here is the answer for you.
[...]
>: What Dan was trying to get accross, I believe, is that the 1.1.xx where
>: xx is some number that was referred to previously, is just that, a
>: *BETA* release.
>Thanks for clarifying this. I had honestly not grasped Dan's point. But
>now that you are telling me, I can at least answer it!
>: You were saying how shitty Linux QC was, and Dan gave
>: an example of the exact same process in the corporate world...
>No, he did not (which may well be why the point escaped me!). No-one here
>would take the attitude "I can't think of any way of testing this, so let's
>put it into a beta release and see what happens." If it makes it into beta,
>it has already undergone quite a bit of testing. The point of beta testing
>is to expose it to all the conditions the original testers didn't think of!
>It's not to make their life easier.
Well, allright, I've bone a little time at a software house during
summers between school, and you're entirely right on that ascpect.
>: If you want a Linux kernel that is stable, etc., don't run the daily
>: development version [ie, the *BETA* version], run a blessed and stable
>: release version. If you're hacking on the kernel, you might want that
>: beta version, and hence it's out there and available....
>Actually, I suppose where I was indeed unfair, is that those odd-numbered
>releases (or whatever) are actually not beta at all: they are alpha at best;
>the code that's shipped to fellow developers to have a look at.
Well, as long as you can concede this, I'll be 1000% happy to stop
picking nits. 8-)
Novell, or any other software house, usually has resources that make
doing such testing easier [ie, access to lots of bizzarro hardware,
$$$, whatever...]. In the Linux camp, often the only way to get an
extensive amount of testing is to let it out of under wraps and let
other people test it.
Plus, letting the code out of wraps lets the other developers working
on Linux see it. It's not like they can hop accross the office! 8-)
Anyway, as a final remark, the process for the *BSD's is somewhat
different. Because there is a core team that "owns" the tree, the
core team acts as a QA agent for patches sent in by folks, and they
tend to do a damn good job of it. [I know this has little or nothing
to do with the original Linux subject, but the *BSD are (more, IMHO)
free as well].
--rafal
+--------------------------------------------------------------------------+
|"Blessed are the meek, for they shall inherit | Rafal Boni |
| 15% of the earth, which is 100% more than they | r-b...@uiuc.edu |
| have now..." -Cartoon caption in New Yorker | My opinions, not UIUC's |
+--------------------------------------------------------------------------+
There seems to be a misconception here that SunSoft is averse to
VARs and resellers. People seem to be forgetting that one of the reasons
taht SunSoft purchased Interactive's x86 Unix division is the strong VAR
and reseller network that Interactive had. Most of these resellers and
VARs are/will be carrying Solaris 2.x also. In addition new VARs are being
enlisted and many of the SPARC side system integrators also carry
Solaris x86.
Sherif
Ummm, wherever did you get the the idea that SunSoft "has chosen to ignore
that sector (resellers) and appeal direct"?
SunSoft does not sell direct. Closest we came to it was an upgrade program
for 2.1 -> 2.4 X86 and that was due to very special circumstances. If you
are counting SunExpress, don't. They are a different company. We (SunSoft)
do demand creation, but fulfillment is coming through the channel, which
has a choice of programs for providing support backed up by us.
Our primary channels are OEMs and resellers (hopefully with a large value add
component if qualification is going properly). The largest OEM is Sun
Microsystems Computer Co., but if you've following all the complaints about
where 2.4 from SMCC is, it's because SMCC is doing their value-add thing
to our 2.4 OEM release. The X86 OEMS (like Dell - interestingly enough to
help replace their SVr4) don't have to do much because of the binary distribution
model of the X86 product, but they can offer pre-installation and support as
a value add and we are working with major H/W OEMs to support the differentiating
features of their platforms.
Reseller education and training is where a good chunk of our resources are going
at the moment. Your points are well taken. I believe them. The company believes
them. We don't view Solaris as an impulse buy and we are working to build
a world class channel. SCO's channel is a major strength (actually their primary
strength - imho) for all the right reasons. An advanced OS requires a little
more handholding than a DOS/Windows solution. And the solutions it's aimed at
are usually more sophisticated in scope.
-sal-
---
=========================================================================
Steven A. Lipetz SunSoft, Sun Microsystems Inc.
Strategic Accounts Sys Eng Mgr 115 Perimeter Center Place, N.E.
steve....@East.Sun.COM Suite 850
(404) 901-6915 FAX:(404)512-0566 Atlanta, GA 30346
=========================================================================
So what's it, Moronius? Are you just trying to take away a competitor
off the market just by using disinformation tactics?
Has Novell fall so low as to need to recruit people like you?
I don't think so, but you really need to think twice before opening your
mouth. Look, it is as simple as this:
1) We are speaking of free software. And of a free software
that provides a good quality level. It's difficult to beat such a
cost/performance rate, but that's no excuse to begin a disinformation
campaign.
2) It is well known for many free wares (not only LINUX) that
there are "stable" versions, "beta" versions and "development" versions,
just like it happens with any commercial ware.
3) Both, commercial and free providers make copies of their
development and beta wares to interested parties. Only that getting a
commercial one is *rather* difficult, and getting a free one is *very*
easy.
4) The system is thought to work with "persons", not "morons".
A person, and specially a professional selects the appropriate version
he or she needs. And knows how to deal with his/her decisions. So there
is no problem.
- A "professional" knows if he/she needs a stable version
and does not care to get the latest, still buggy, development venture,
neither in the commercial nor the free world. So far for v#.0 versions.
- And he/she also knows when he/she needs more advanced features
or if s/he can afford the risk, or be in the leading edge, and then gets
the betas (like developers for Windows, AXP, OSF, etc...). Knows that
they will still be buggie, but prefers the bugs to be late in his/her
deadlines. No worry about betas. They *need* them.
- And a bery good pro may use an stabilished version but be
willing to know about internal, new developments or want to suit the
system to his/her needs. Then s/he goes for development versions or
sources (something *REALLY DIFFICULT* in the commercial world). And
euther studies the sources or develops new things.
5) In any case a "pro" works constructively with the appropriate
tools. Only a moron goes ahead into troubled waters even when advertised
of the risks and then flames others for his/her irresponsibility. Know in
which rank are you placing yourself with your stupid messages?
So far for morons. You look like the guy that installs MK87 of
Mach in an unsupported platform and expects it to work better than any
full blown OSF version and to have Real Time support, live voice and
video and nice 3-D harlots to suck him out of the screen, and when any
of these fails begins flaming all over the world and saying that he should
have stuck with MeSh-DOS.
Know your place. Know your limitations. Use the appropriate tools.
And some day you might become a true professional.
Dot.
Don't expect me to follow discussing. It's no use with someone
who still thinks grey matter is that which sticks to shoes when it rains.
jr
: This is a subjective statement. What criteria was used when the statement
: the Solaris agressively persues new technologies? How about new technologies
: such as NetWare support? How about CDE (Both Sun and Novell contribute here).
: What aggressive technology has Sun persued that has not been persued by
: Novell?
DOE/CORBA
Open Step
secure RPC (used to be (in)secure, significantly better in Solaris 2)
XTL & ISDN
video conferencing
multiprocessing
multithreading applications
multithreading kernel, including all device drivers, including STREAMS
multithreading debugger
NIS+ (maybe a little too agressive a pursuit, but the idea is advanced ;-)
Of these, only OpenStep isn't shipping now. OOPS, I guess you said
"pursued by Novell," didn't you? Surely you didn't mean to weasel out
by comparing what you're developing now to what Sun has shipped for a
couple of years? Multiprocessing and multithreading are not at all
easy; it takes calendar time and actual running production systems to
wring them out. I have no experience developing the other features at
the system level, but I assume they take maturing as well. (If
maturity wasn't an advantage, we'd all be running our
"mission-critical" applications on Windows NT by now. And Digital's VMS
4 wouldn't have been better than VMS 2.)
Also, note I didn't say UnixWare is a subset of Solaris; I'm just
answering the immediate question you posed. And, by the way, access to
NetWare file and print service is not aggressive technology. Access to
fully developed NetWare NDS might be, if it (NDS, not UnixWare access
to it) were mature enough to use. (I assume it will take a little
real-world time to wring out the operational problems, since the idea
that the whole world revolves around each server is an ingrained
NetWare concept.)
[snip]
: Yet another subjective statement. What criteria was used in determining
: feature rich. What features does Solaris have that are not present in
: UnixWare? How many features does UnixWare have the Solaris doesn't? :^)
Ignoring packaging and thinking only of availability, I can think of
very few. Perhaps you (or George, or someone who has actually done the
analysis) would care to list them.
: How about price? The value of UnixWare is not diminished at all if you
: are not going to use the NetWare connectivity. UnixWare is just as capable
: OS as is Solaris. You choose what you need.
Price is where UnixWare really hurts (compared to perception), in the
heterogeneously networked system arena. UnixWare PE is cheap enough,
but woefully incomplete. By the time you've added SDK (for the
utilities someone thought I could do without) and NFS (which is
required for NIS even if you don't want NFS, which I consider a
required base function), UnixWare PE is about the same price as
Solaris. And the two-user Solaris is complete. Period.
: I believe one of the VARs such as Evan can answer how resellers are better
: suited to handle you than direct route. How about having them close at
: hand when problems arise? Novell also provides direct support through
: support contracts and the 1-800-NETWARE number. You decide what support
: you need.
Resellers are rarely of use in solving my problems. Sun's Catalyst has
been. I understand Novell is trying to get a developer's program
going, but it's not yet as well-known, active, or effective as
Catalyst.
[snip]
: Currently (And I emphasize currently) rely on third party vendors for
: object support. We do provide a full C/C++ development environment for
: UnixWare. Is NextStep the leading object environment? Will it be? Only
: you can decide how important this is to you. Novell is persueing object
: technology just like the rest of the industry. The jury is still out
: on object technology. Some say NeXTstep, some say Taligent, some say
: Cairo [I don't know why though :^) ]. There are many third party options
: as well.
When I develop release 7.0, I'll worry about Cairo and Taligent.
NextStep *is* the leading environment now, because it exists, it works,
it ships, while the others first ship is long off. In addition, I'm
none too sure I want to wait for Novell to ship them even after they're
out. There is reason to doubt Novell's commitment to developer tools.
Where is AppWare? When will CDE be a standard part of UnixWare PE?
: Our network management tools are improving, after all we are the largest
: network software company in the world. We provide many of the same
: network tool the Solaris does. I can not say for sure though because I
: haven't seen all the tools provided in Solaris and how they differ to UnixWare.
Nothing personal, Darren, but I've often felt that no one involved with
UnixWare was really aware of what a real heterogeneous Unix-style
network fully exploiting the facilities of HPUX, AIX, OSF, or Solaris
looks like. In the market I work in, SCO and Netware are invisible.
TCP/IP, NFS, automount, RPC, NIS, and mingled local- and wide-area
networks are the opening joke; they are assumed, not notable features.
: |>
: |> Future:
: |>
: |> Solaris is much more strategic to SUN than UNIXware is to Novell. Recent
: |> history and future projections indicate that Solaris is more likely
: |> to be evolved to support new/emerging technologies.
: How many subjective statements are they going to make. What makes people think
: that UnixWare is not strategic to Novell?
First, that's not what he said. He said Solaris was comparatively more
important to Sun than UnixWare to Netware (oops - I mean Novell).
Second, people think it because Novell, in press releases and at
conferences and trade shows, and in sales presentations, acts that
way. NetWare is more important than UnixWare. NetWare is more
important than UnixWare. Most of the actual presentations I've heard
about UnixWare focus on its integration with NetWare. At the last
Uniforum I attended (which wasn't the most` recent) we were told by
Novell that the really significant features of UnixWare 2.0 were MP
support (which we were told would only appeal to a small part of the
market) and improved integration with UnixWare.
Third, people feel that way because Novell, outside of Usenet, has no
clear message about UnixWare. I realize they are trying, but it hasn't
worked yet, and a faux pas like the recent announcement of the
deemphasis of the desktop and the rapprochement with Microsoft hurts.
It may feel good to blame the press for misinterpretation, but if you
use multisyllable words and compound sentences with those guys, no
one can predict what they'll hear.
[snip]
>In article <3c4rhh$5...@bantu.provo.novell.com>,
> Darren R. Davis <dar...@bikini.USG.Sandy.Novell.COM> wrote:
>>UnixWare is just as capable OS as is Solaris.
>Not.
Hey, folks, this is really well intentioned and all, but has the makings
of a classic computer-religion noisefest. I thought everyone'd learned
their lessons after exposure to the Linux crew.
>1) cachefs
>2) better NFS in general
>3) thread support
>4) a much more standard and full set of code libraries
>5) a better X server
>6) a better X environment
>7) MAE availability [on sparc]
>8) working man pages
>9) a proper sysvr4 kernal that doesn't have to be compiled
>10) better compilers/tools available (centerline, purify, ...) [on sparc]
While hoping not to get (too deeply :-) dragged in, I'll note that
Heather's points 7 and 10 don't apply to this context, which is purely
one of Intel Solaris vs. Intel UnixWare.
Regardless of which side eventually wins this particular pissing match,
please try to use more useful adjectives than "better" or "more standard"
or (worst of all) "proper" when flying your particular flag in the future.
Some of us are actually interested in *meaningful* comparisons;
this wasn't one of them.
>Dan Pop (dan...@cernapo.cern.ch) wrote:
>: In <D0CD...@novell.co.uk> msoh...@novell.co.uk (Martin Sohnius) writes:
>
>[...]
>
>: >Wow! Now we really know how quality control works for Linux. "Neither
>: >Linus or myself could test the code first - trial by fire seemed to be the
>: >only way..., since I couldn't think of anything to test it on."
>: >
>: >Anyone ever wondered why people in suits don't want free OS's? Here is
>: >the answer for you.
>
>: Nope. Versions 1.1.* are _test_ versions and all the people using them
>: are testers. If you offer such a version to a suit and get fired, don't
>: blame Linux.
>
>The point is that haphazard "trial by fire" is not an appropriate test
>methodology. Pentium chips get divisions right most of the time, after all.
>
>: Has Novell ever released test versions, labeled as such?
>
>Yes. They are called beta releases.
>
>: Did they ever
>: receive bug reports for these versions?
>
>Yes.
>
>: Moreover, did they ever
>: receive bug reports for _production_ versions of UnixWare?
>
>Yes. What are you actually trying to say/imply?
>
>: Anyone ever wondered why people in suits don't want commercial OS's?
>: Here is the answer for you.
>
>You didn't make any statement related to commercial OSes. Instead, you
>asked three questions whose rhetoric escapes me. What is the "answer" you
>are talking about?
It's simple. Novell knows that version X has undiscovered bugs and
releases test versions, for those who, at their risks, want to test that
version. The testers find bugs, report them, and Novell fixes them.
In the Linux world, the testing is performed in the same way.
If your "argument" is valid for free OS's, it's necessarily valid for
commercial OS's, too. That's all.
If only it were that simple.....
>In the Linux world, the testing is performed in the same way.
Not even close. In Linux, you never know what bugs are fixed unless you
want to get the mailing list traffic, and your bug might be fixed at the
same time as another one is introduced. There is no one-one mapping from
bug-fixes to releases. Towards the end this happens, but as a general
rule it doesn't occur.
And, the statement 'you can always run the stable 1.0' release doesn't
cut it. There are MONSTER bugs in that branch that have never been
fixed since they 'might' introduce instabilities. However, those bugs
make it useless to put that machine on a network, and the 1.1 branch has
not slowed down enough in the patches that you can grab a revision and
know that it's going to work.
With commercial software at least you can get fixes for things
advertised in *your* release that fix bugs that *you* need. Yes, there
are horror stories about things never getting fixed, but as a general
rule things get done if enough people complain about them, and the
generic functionality expected out of most commercial OS's is still not
'quite' there in Linux.
When 1.2 is out I expect this to change, since networking should be much
more stable (Let's hope the scheduling changes go in as well).
>If your "argument" is valid for free OS's, it's necessarily valid for
>commercial OS's, too. That's all.
C'mon Dan. Commercial OS software testing is completely different than
free software testing in general. The reason Linux and FreeBSD have
more features than the commercial x86 versions sooner is because
stability is not as important as 'feeping creaturism'. Features comes
first, and stability comes second. And, it's a lot more fun to do
things that way. :-)
Nate
--
na...@bsd.coe.montana.edu | FreeBSD dude and all around tech.
na...@cs.montana.edu | weenie.
work #: (406) 994-5980 | Unemployed, looking for permanant work in
home #: (406) 586-0579 | CS/EE field.
Casper> (Is this going to be another my uptime is bigger than
Casper> yours battle?).
Heck, why not?
Casper> We have average uptimes > 100 days. (Averaged over > 100
Casper> machines) Some machines stay up for 450+ days.
One of our two DEC Alpha's running OSF/1 2.0
has been up 71 days so far, and I DON'T think there are many people
that would consider this a mature or particularly robust OS.
The other system is primary file and mail server and seems to crash about
every two weeks.
-castor
--
-- My current net peeve -v Castor Fu, (cas...@drizzle.stanford.edu)
looser: 1. less tightly connected 2. less morally restrained . . .
loser: One suffering defeat, error, etc. ex ."Losers use looser incorrectly"
I hate to burst your bubble, but I worked at Sun in the systems group for
a few years (and then in the server group). They had *no* regression
test other than the binaries that shipped with the OS. Since 5.x,
they use the POSIX test suites but those (were) are pathetic and
certainly don't cover everything.
The commercial OS release mechanism is pretty similar to Linux. You send
out some alpha junk to a few sites and see what the reaction is. The closer
you get to beta the less you allow in. After beta only show stoppers get
in.
Stability is important but there is little in the way of testing done to
insure stability. SMCC might be fixing that, I understand they have/had
Solaris 2.4 months before they shipped it. :-)
--
---
Larry McVoy (415) 390-1804 l...@sgi.com
Then somebody should take the manager of that group out and shoot him.
Either that or his manager for giving unreasonable deadlines that can't
be met with decent testing.
If microsoft does one thing right it's test it's software. Granted, it
still never seems to find the bugs that the average user find the first
time around, but they do indeed spend alot of their resources trying to
break their own products.
>The commercial OS release mechanism is pretty similar to Linux. You send
>out some alpha junk to a few sites and see what the reaction is. The closer
>you get to beta the less you allow in. After beta only show stoppers get
>in.
That might be the way SUN does things, but I know of a couple other OS
vendors that don't do things that way. :)
>Stability is important but there is little in the way of testing done to
>insure stability. SMCC might be fixing that, I understand they have/had
>Solaris 2.4 months before they shipped it. :-)
Stability can be tested by putting real world applications on your
hardware. The way FreeBSD tests it's software is by sticking it on
wcarchive.cdrom.com. Having 250-350 ftp's is one way of seeing how
the system reacts under load. :)
|> 2) better NFS in general
Again subjective, I want numbers! (Just as a note, where do you think we
got our NFS implementation from?)
|> 3) thread support
UnixWare 2.0
|> 4) a much more standard and full set of code libraries
Huh, more standard in what way? Who's standard? Sun's?
Remember X/Open? Remember Unix Trademark? Remember XPG3/POSIX and any
other standard you want to compare on? Give me a break.
|> 5) a better X server
Subject! Give me numbers.
|> 6) a better X environment
A non-standard X environment!
|> 7) MAE availability [on sparc]
Let's keep it apples to apples. Just Intel please. Besides, I fell
that a Mac emulation environment is about as usefull as a DOS one.
|> 8) working man pages
Mine work fine.
|> 9) a proper sysvr4 kernal that doesn't have to be compiled
What does this mean?
|> 10) better compilers/tools available (centerline, purify, ...) [on sparc]
Sunsoft, Centerline, and Purify all ship for UnixWare. Why don't you
check it out before you comment.
|>
|>
|> Do you think 10 reasons comprises "more capable", or should I go on?
|>
|>
Please do, how about some numbers next time. I could make the same
statements myself. :^)
Darren R. Davis
UnixWare Developer Support Engineer
Novell Developer Support
Glad to hear it. Although I'll believe it when I see it :-)
>UW did a nice layered virtual machine for X, and X ain't nice.
What do you mean in this case by "virtual machine for X"?
I shall now, by popular demand, elucidate upon the points I made, which
should already be clear to people who have used both unixware and solaris.
THe following comparison pertains to:
Solaris 2.4
Unixware 1.1 (cause we ain't got no 2.0)
Better NFS:
the nfs daemon for solaris is multithreaded
(+ more reasons that I dont remember, but a sun engineer could
probably point out)
More full set of code libraries:
As I pointed out in email to someone, solaris has the goodies like
strcasecmp(). UW1.1 does not.
Better X server:
R5 based. REAL implementation of standard R5, including 16-bit fonts.
(there is an optional package called metrolink that claims
to provide R5 for unixware. no MITSHM. no 16-bit-fonts)
MITSHM extension.
DPS (Adobe-DPS-Extension, AND DPSExtension)
Multi-Buffering
MIT_SUNDRY_NONSTANDARD
X3D-PEX
XimputExtension
XTEST
Better X server environment:
A real olwm. the pseudo-olwm with unixware 1.1 is broken. i dont
remember how right now, sorry.
A real xterm. The "xterm" with unixware is a very sad joke.
More stuff I dont remember right now, but other users of both systems
should be able to fill in.
Working man pages:
Source for man pages is EXTRA in uw1.1?? Come ON. And the
apropos/whatis stuff is useless without it.
Plus, the solaris stuff uses the cache generated by catman -w
to speed up "man xx" serach times
I apologise for my mistake on the compiler issue.
-> Off the subject, does anyone have a hardware list of supported
-> devices for Linux?
LINUX HARDWARE COMPATIBILITY HOWTO
==================================
Last updated: October 3, 1994
Welcome to the Linux Hardware Compatibility HOWTO. This file will
hopefully list most of the hardwares supported by Linux and help you
locate the necessary drivers. If you know of any Linux hardware
(in)compatibilities not listed here please let me know. Thanks.
Sections marked =others= list hardwares with alpha or beta drivers in
varying degrees of usability or other drivers that aren't included in
standard distributions. Drivers can usually be found on tsx-11.mit.edu
and/or sunsite.unc.edu. Check the Linux Software Map, or check the
html version of this file at <http://ksc.au.ac.th:8000/hardware.html>.
[The server that my httpd runs on is somewhat broken now so the page
may be unreachable. The admins seem to have realized the problems so
hopefully something will be done to fix it soon.]
I need more info on:
* video cards supported by XFree86 3.1
* PCMCIA support - PCMCIA SCSI and sound cards
* sound cards - OPL4 cards, Orchid Soundwave, SB16 daughterboards
* ... and anything else you can send me.
Comments, additions, changes, etc., send mail or find me on irc.
FRiC <fr...@ksc.au.ac.th>
_________________________________________________________________
Computers/Laptops/Notebooks/Motherboards/BIOS
ISA, VLB, EISA, PCI (but read the PCI HOWTO)
PS/2 and Microchannel (MCA) is not supported in the standard kernel.
ALPHA test PS/2 MCA kernels are available but not yet recommended
for beginners or serious use.
Laptops should be able to run Linux with no problems. There are
various patches for laptops, including PCMCIA, APM, power savings
(WD7600 chipset), non-blinking cursor, and more. PCMCIA drivers
currently support Databook TCIC/2, Intel 82365SL, and Cirrus PD67xx
chipsets.
Some laptops have unusual video adapters or power management, it is
not uncommon to be unable to use the power management. Some laptops
with 2.88 meg drives need very recent kernels.
_________________________________________________________________
CPU/FPU
Intel/AMD/Cyrix 386SX/DX/SL/DXL/SLC, 486SX/DX/SL/SX2/DX2/DX4, Pentium.
Basically all 386 or better processors will work. Linux has built-in
FPU emulation if you don't have a math coprocessor.
A few very early AMD 486DX's hang in some special situations. All
current chips should be okay and getting a chip swap for old CPU's
should not be a problem.
ULSI Math*Co series has a bug in the FSAVE and FRSTOR instructions
that causes problems with all protected mode operating systems. Some
older IIT and Cyrix chips may also have this problem.
There is a patch to enable cache on Cyrix processors.
_________________________________________________________________
Video cards
Linux will work with all video cards in text mode, VGA cards not
listed below probably will still work with mono VGA and/or standard
VGA16 drivers.
If you're looking into buying a cheap video card to run X, keep in
mind that accelerated cards (ATI, S3) are MUCH faster than
unaccelerated or partially accelerated (Cirrus, WD) cards. Orchid
Fahrenheit 1280+ (S3 801/805) and ATI Graphics Wonder (Mach32) are
good low-end accelerated cards.
Historically Diamond video cards were not supported by XFree86.
However, as of September 27, 1994, Diamond has verbally agreed to
provide The XFree86 Project, Inc. with detailed information about
Diamond products.
SVGALIB
* VGA
* EGA
* ATI Mach32
* Cirrus 542x
* OAK OTI-037/67/77, OTI-087
* Trident TVGA8900/9000
* Tseng ET3000/ET4000
XFREE86 3.1
Accelerated support (8 bpp unless noted)
* ATI Mach8
* ATI Mach32 (16 bpp - doesn't work with all Mach32 cards)
* Cirrus Logic 5420, 542x/5430 (16 bpp), 5434 (16/24 bpp), 62x5
* IBM 8514/A
* IBM XGA, XGA-II
* IIT AGX-010/014/015/016
* S3 911, 924, 801, 805/805i, 928/928-P, 864, 964
+ S3 801/805, AT&T 20C490 (or similar) RAMDAC (16 bpp)
Orchid Fahrenheit 1280+ VLB, Actix GraphicsENGINE 32
+ S3 805 VLB, S3 GENDAC (16 bpp)
Miro 10SD VLB/PCI
+ S3 805, Diamond SS2410 RAMDAC, ICD2061A Clockchip
Diamond Stealth 24 VLB
+ S3 928, AT&T 20C490 RAMDAC (16 bpp)
Actix Ultra
+ S3 928, Sierra SC15025 RAMDAC, ICD2061A Clockchip (16/24 bpp)
ELSA Winner 1000 ISA/VLB/EISA
+ S3 928, Bt485 RAMDAC, ICD2061A Clockchip
STB Pegasus VL
+ S3 928, Bt485 RAMDAC, SC11412 Clockchip (16 bpp)
SPEA Mercury VLB
+ S3 928, Bt485 RAMDAC, ICD2061A Clockchip
#9 GXE Level 10/11/12
+ S3 928, Ti3020 RAMDAC, ICD2061A Clockchip
#9 GXE Level 14/16
+ S3 864, AT&T 20C498 or STG1700 RAMDAC, ICD2061A or ICS9161
Clockchip (16/24 bpp)
ELSA Winner 1000 PRO VLB/PCI
+ S3 864, STG1700 RAMDAC, ICD2061A Clockchip (16/24? bpp)
Actix GraphicsENGINE 64 VLB
+ S3 864, 20C498 RAMDAC, ICS2595 Clockchip (16 bpp)
SPEA Mirage P64 DRAM
+ S3 964, AT&T 20C505 RAMDAC, ICD2061A Clockchip (16/24 bpp)
Miro Crystal 20SV PCI
+ S3 964, Bt485 RAMDAC, ICD2061A Clockchip (16/24 bpp)
Diamond Stealth 64
+ S3 964, Ti3020 RAMDAC, ICD2061A Clockchip
ELSA Winner 2000 PRO PCI
+ S3 964, Ti3025 RAMDAC, Ti3025 Clockchip (16/24 bpp)
#9 GXE64 Pro VLB/PCI
* Tseng ET4000/W32/W32i/W32p
* Weitek P9000 (16/24 bpp)
+ Diamond Viper VLB/PCI
+ Orchid P9000
* Western Digital WD90C31/33
Unaccelerated
* ATI VGA Wonder, 18800*, 28800*, 68800*, 88800 (Mach64)
* Advance Logic AL2101
* Cirrus Logic 6420
* Compaq AVGA
* Genoa GVGA
* MCGA (320x200)
* MX MX68000/MX68010
* NCR 77C22, 77C22E, 77C22E+
* OAK OTI067, OTI077
* Trident TVGA8800, TVGA8900, TVGA9xxx (not very fast)
* Tseng ET3000, ET4000AX
* VGA (standard VGA, 4 bit, slow)
* Video 7/Headland Technologies HT216-32
* Western Digital/Paradise PVGA1, WD90C00/10/11/24/30/31/33
Monochrome
* Hercules mono
* Hyundai HGC-1280
* Sigma LaserView PLUS
* VGA mono
Work in progress
* ATI Mach64 accelerated support
* Compaq QVision
* Number Nine Imagine 128
OTHER X SERVERS
Commercial X servers may provide support for cards not supported by
XFree86, and might give better performances. Only cards not supported
by XFree86 are listed here. Contact the vendors directly or check the
Commercial HOWTO for more info.
Accelerated-X ($199, X Inside, Inc., in...@xinside.com)
* ATI Mach64
* Matrox MGA-I, MGA-II
* Number Nine I-128
16/24 bit support for many cards
Metro-X ($150, Metro Link, sa...@metrolink.com)
* Diamond SpeedStar, SpeedStar PRO, Stealth, Stealth PRO
* Matrox MGA-I, MGA-II
* TI 34020
16 bit support for S3 and Mach32
24 bit support for S3 and Matrox
_________________________________________________________________
Controllers (hard drive)
Linux will work with standard IDE, MFM and RLL controllers. When using
MFM/RLL controllers it is important to use ext2fs and the bad block
checking options when formatting the disk.
ESDI controllers that emulate the ST-506 (that is MFM/RLL/IDE)
interface will also work. The bad block checking comment also applies
to these controllers.
Generic 8 bit XT controllers also work.
_________________________________________________________________
Controllers (SCSI)
It is important to pick a SCSI controller carefully. Many cheap ISA
SCSI controllers are designed to drive CD-ROM's rather than anything
else. Such low end SCSI controllers are no better than IDE. See the
SCSI HOWTO and look at UNIX performance figures before buying a SCSI
card.
* Adaptec AHA-1510 (ISA)
* Adaptec AHA-152x (1510 with onboard BIOS) (all models)
* Adaptec AHA-154x (ISA) (all models)
* Adaptec AHA-174x (EISA) (in enhanced mode)
* BusLogic (all models)
* DTC 329x (Adaptec compatibility mode)
* Future Domain TMC-16x0, TMC-3260 (PCI)
* Future Domain TMC-8xx, TMC-950
* NCR 53c7x0, 53c8x0 (PCI)
* ProAudio Spectrum 16 SCSI (ISA)
* Seagate ST-01/ST-02 (ISA)
* SoundBlaster 16 SCSI-II (Adaptec 152x) (ISA)
* Trantor T128/T128F/T228 (ISA)
* UltraStor 14F, 24F, 34F
* Western Digital WD7000FASST SCSI
=others=
* Acculogic ISApport / NCR 53c406a
* Adaptec AHA-274x/284x, AIC-7770
* Always AL-500
* Always IN2000
* DPT Smartcache (PM2011, 2012A, 2012B)
* DPT Smartcache III (PM2021, 2022, 2122, 2322)
* EATA-DMA protocol compliant SCSI (DPT/NEC/AT&T)
* Iomega PC2/2B
* Qlogic
* Richoh GSI-8
* NCR53c400 / Trantor T130B
AMI is writing a driver for their Fast Disk VLB Cache SCSI Controller.
Drivers for New Media Bus Toaster and Qlogic Fast!SCSI (PCMCIA) are
being written.
Parallel port SCSI adapters are not supported.
Non Adaptec compatible DTC boards (327x, 328x) are not supported.
_________________________________________________________________
Controllers (I/O)
Any standard serial/parallel/joystick/IDE combo cards.
Linux supports 8250, 16450, 16550, and 16550A UART's.
_________________________________________________________________
Controllers (multiport)
* AST FourPort and clones
* Accent Async-4
* Bell Technologies HUB6
* Boca BB-1004, 1008 (4, 8 port) - no DTR, DSR, and CD
* Boca BB-2016 (16 port)
* Boca IO 2by4 (4S/2P) - works with modems, but uses 5 IRQ's
* PC-COMM 4-port
* STB 4-COM
* Twincom ACI/550
* Usenet Serial Board II
=others=
* Cyclades Cyclom-8Y/16Y asynchronous multiplexer
DigiBoard COM/Xi and PC/Xe drivers are being worked on.
_________________________________________________________________
Network adapters
Ethernet adapters vary greatly in performance. In general the newer
the design the better. Some very old cards like the 3c501 are only
useful because they can be found in junk heaps for $5 a time.
(*) indicates an ALPHA test driver
(n) indicates a footnote
* 3Com 3c501(1)(2), 3c503, 3c505(*), 3c507(*), 3c509/3c579
* AMD LANCE (79C960) / PCnet-ISA (AT1500, HP J2405A, NE1500/NE2100) (3)
* Allied Telesis AT1700
* Cabletron E21xx
* DEC DEPCA and EtherWORKS
* HP PCLAN
* Intel EtherExpress(*)
* NE2000/NE1000
* Racal-Interlan NI5210(*) (i82586 Ethernet chip)
* Racal-Interlan NI6510(*) (am7990 lance chip) - doesn't work with
more than 16 megs RAM
* PureData PDUC8028, PDI8023
* SMC Ultra
* Schneider & Koch G16
* Western Digital WD80x3
EISA and onboard controllers
* Ansel Communications AC3200 EISA
* Apricot Xen-II
Pocket and portable adapters
* AT-Lan-Tec/RealTek parallel port adapter
* D-Link DE600/DE620 parallel port adapter
* Zenith Z-Note / IBM ThinkPad 300 built-in adapter
* SLIP/CSLIP/PPP
* PLIP (parallel port, using "LapLink cable" or bi-directional cable)
=others=
ISDN
* Diehl SCOM card (4)
* Sonix PC Volante - only in asynchronous mode, not useful for some
applications
* Teles ISDN card
Amateur radio cards
* Ottowa PI2
* Most generic 8530 based HDLC boards
No support for the PMP/Baycom board
PCMCIA cards
* 3Com 3c589
* D-Link DE650 PCMCIA
* IBM Credit Card Adapter
* IC-Card
* Linksys EthernetCard
* National NE4100
* Network General "Sniffer"
* Thomas-Conrad Ethernet
* ... possibly more
Xircom adapters are not supported.
1. Obsolete and not recommended.
2. Use the Linux 1.1.50 or higher driver for reliability.
3. Be careful with clones. Not all are good clones and bad clones
often cause erratic lockups under Linux.
4. Requires an extensively modfied kernel by Matthais Urlich.
_________________________________________________________________
Sound cards
* 6850 UART MIDI
* ATI Stereo F/X (SB compatible)
* Adlib
* Ensoniq SoundScape (SB/MPU-401 compatible, boot DOS to init card)
* Gravis Ultrasound
* Gravis Ultrasound MAX
* Logitech SoundMan 16 (PAS-16 compatible)
* Microsoft Sound System
* MPU-401 MIDI
* ProAudio Spectrum-16 (but see Incompatibilities)
* PSS (ECHO-ADI2111) MIDI
* SoundBlaster (version 1 and 2)
* SoundBlaster PRO
* SoundBlaster 16/ASP/MCD/SCSI-II
* Sound Galaxy NX Pro
* ThunderBoard (SB compatible)
* WaveBlaster
=others=
* PC speaker / Parallel port DAC
The ASP chip on SoundBlaster 16 series is not supported.
SoundBlaster AWE32's special features (MIDI, effects) are not
supported.
_________________________________________________________________
Hard drives
All hard drives should work if the controller is supported.
(From the SCSI HOWTO)
All direct access SCSI devices with a block size of 256, 512, or 1024
bytes should work. Other block sizes will not work (Note that this can
often be fixed by changing the block and/or sector sizes using the
MODE SELECT SCSI command)
Large IDE drives will work fine with Linux. With kernels prior to
about 1.1.47 you will need to run with LBA disabled which may confuse
DOS if you wish to share the drive. Your boot partition must lie in
the first 1024 cylinders due to PC BIOS limitations.
_________________________________________________________________
Tape drives
SCSI tape drives (From the SCSI HOWTO)
Drives using both fixed and variable length blocks smaller than the
driver buffer length (set to 32k in the distribution sources) are
supported. Virtually all drives should work. (Send mail if you know of
any incompatible drives.)
* QIC-02
* QIC-117, QIC-40/80 drives (Ftape)
+ Most tape drive using the floppy controller should work.
Check the Ftape HOWTO for details.
+ Colorado FC-10 is supported
* these don't work...
+ Drives that connect to the parallel port (eg: Colorado Trakker)
+ Some high speed tape controllers (Colorado TC-15 / FC-20)
+ Irwin AX250L/Accutrak 250 (not QIC-80)
+ IBM Internal Tape Backup Unit (not QIC-80)
+ COREtape Light
_________________________________________________________________
CD-ROM drives
(From the CD-ROM HOWTO)
Any SCSI CD-ROM drive with a block size of 512 or 2048 bytes should
work under Linux; this includes the vast majority of CD-ROM drives on
the market.
* Kotobuki/Matsushita/Panasonic
* Mitsumi
* Sony CDU31A/CDU33A
=others=
* LMS/Philips CM 205/225/202 (does not work with CM 206)
* NEC CDR-260 IDE CD-ROM drive
* Sony CDU-535/CDU-531
PhotoCD (XA) is supported.
All CD-ROM drives should work similarly for reading data. There are
various compatibility problems with audio CD playing utilities.
(Especially with some NEC drives.) Some alpha drivers may not have
audio support yet.
_________________________________________________________________
Optical/WORM/CD-R/Floptical/Removable drives
All SCSI based drives should work if the controller is supported.
Linux supports both 512 and 1024 bytes/sector optical disks.
Iomega Bernoulli and LaserSafe drives attached to their proprietary
PC2/2B SCSI adapters will work if the driver is installed.
_________________________________________________________________
Mice
* Microsoft serial mouse
* Mouse Systems serial mouse
* Logitech Mouseman serial mouse
* Logitech serial mouse
* ATI XL Inport busmouse
* C&T 82C710 (QuickPort) (Toshiba, TI Travelmate)
* Microsoft busmouse
* Logitech busmouse
* PS/2 (auxiliary device) mouse
=others=
* Sejin J-mouse
Newer Logitech mice (except the Mouseman) use the Microsoft protocol
and all three buttons do work. Eventhough Microsoft's mice have only
two buttons, the protocol allows three buttons. The mouse port on the
ATI Graphics Ultra and Ultra Pro use the Logitech busmouse protocol.
(See the Busmouse HOWTO for details.)
_________________________________________________________________
Modems
All internal modems or external modems connected to the serial port.
A small number of modems come with DOS software that downloads the
control program at runtime. These can normally be used by loading the
program under DOS and doing a warm boot. Such modems are probably best
avoided as you won't be able to use them with non PC hardware in the
future.
PCMCIA modems should work with the PCMCIA drivers.
Fax modems need appropriated fax software to operate.
* Digicom Connection 96+/14.4+ - DSP code downloading program
* ZyXEL U-1496 series - ZyXEL 1.4, modem/fax/voice control program
_________________________________________________________________
Printers/Plotters
All printers and plotters connected to the parallel or serial port
should work.
* HP LaserJet 4 series - free-lj4, printing modes control program
Many Linux programs output PostScript files. Non-PostScript printers
can emulate PostScript Level 2 using Ghostscript. Ghostscript supports
these printers (and compatibles):
* Apple Imagewriter
* C. Itoh M8510
* Canon BubbleJet BJ10e, BJ200
* Canon LBP-8II, LIPS III
* DEC LA50/70/75/75plus
* DEC LN03, LJ250
* Epson 9 pin, 24 pin, LQ series, Stylus, AP3250
* HP 2563B
* HP DesignJet 650C
* HP DeskJet/Plus/500
* HP DeskJet 500C/520C/550C color
* HP LaserJet/Plus/II/III/4
* HP PaintJet/XL/XL300/1200C color
* IBM Jetprinter color
* IBM Proprinter
* Imagen ImPress
* Mitsubishi CP50 color
* NEC P6/P6+/P60
* Okidata MicroLine 182
* Ricoh 4081
* SPARCprinter
* StarJet 48 inkjet printer
* Tektronix 4693d color 2/4/8 bit
* Tektronix 4695/4696 inkjet plotter
* Xerox XES printers (2700, 3700, 4045, etc.)
There is a patch for Canon BJC600 and Epson ESC/P color printers.
SCSI printers?
_________________________________________________________________
Scanners
* A4 Tech AC 4096
* Genius GS-B105G
* GS4500 handheld scanner
* Logitech Scanman 32 / 256
* Mustek M105 handheld scanner with GI1904 interface
Dr. G.W. Wettstein is working on support for Fujitsu SCSI-2 scanners.
_________________________________________________________________
Others
* Built-in support for 2.88 meg floppy drives
* Joysticks
* VideoBlaster, Rombo Media Pro+
* WinVision video capture card
* VESA Power Savings Protocol (DPMS) monitors
* APC Back-UPS (Read the Back-UPS HOWTO)
_________________________________________________________________
Incompatibilities
Both the ProAudio Spectrum-16 and the Adaptec 1542 use 16-bit DMA so
they may have trouble working together. A program called SCSISEL.EXE
may fix this. Check the Sound HOWTO for details.
_________________________________________________________________
Acknowledgments
Thanks to all the authors and contributors of other HOWTO's, many
things here are shamelessly stolen from their HOWTO's; to Zane Healy
and Ed Carp, the original author and maintainer of this list; and to
everyone else who sent in updates and feedbacks.
_________________________________________________________________
--end
Trademarks are owned by their owners. No warranties.
--
>|> 6) a better X environment
>A non-standard X environment!
What is so non-standard about Sun's X environment?
Casper
This WAS my whole point. I am not interested in getting into a pissing
match about my OS versus your OS, we know where that leads. What I was
trying to point out, is if I was givin the task of choosing OSes I would
not believe ANY subjective statement like my X is better than your X, and
your feature really sucks. I would establish myself an acceptance criteria
idependant of any OS I was using and then measure these OSes OBJECTIVELY
to this standard. Then *ALL* I would know is I have the best OS that meets
my criteria. BUT I CAUTION, check all the numbers and features. AND
THROUGH ALL THE OPINION IN THE TRASH WERE IT BELONGS!
[Much deleted for brevity and bandwidth]
In looking at the groups that this was posted to, I really believe this could
have been taken to one of the linux groups. All the linux info you want
is there.
[LINUX HARDWARE COMPATIBILITY HOWTO deleted]
There isn't really any excuse for posting this to comp.unix.aix,
comp.unix.bsd, comp.unix.solaris, and comp.unix.unixware...
Please just post the ftp site next time.
Be happy...
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
::Stormy:Sebastian:Henderson::::::::::::::nosredneH:naitsabeS:ymrotS::
::Sto...@Mail.Mother.COM::::::::::::::::::::::MOC.rehtoM.liaM@ymrotS::
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
And they certainly seem to have succeeded.
-- Richard
--
Satan himself, in a sermon preached from the pulpit of North Berwick
church, comforted his many servants by assuring them that no harm could
befall them "sa lang as their hair wes on, an sould newir latt ane teir
fall fra thair ene". - J G Frazer, The Golden Bough
>>SunSoft, shunned VARs and sold direct. This approach worked fine
>>for those who knew what they were doing. But most end-users, the kind
>>who don't even know what a Unix is, let alone that their vertical app
>>is running on it, never heard of Dell Unix. Their exposure to Unix was
>>*exclusively* through the VAR channel, which to date has been the
>>main path for SCO to go. Solaris and Novell alike would love to have
>>SCO's market share in this corner of the world -- study carefully how
>>they got there. Hint: SCO doesn't sell direct.
>There seems to be a misconception here that SunSoft is averse to
>VARs and resellers.
It is not a misconception, it is a fact that I lived through first-hand.
When my company noticed that Esix appeared to be stagnating, and that we
had to pick up a new Intel Unix line, I shopped around. I spent a long
time with people from SCO, Sunsoft, and that upstart Univel.
SCO's VAR network is like a cozy exclusive club, but it isn't that hard
to join. Univel was very unpolished at the time (it had hardly been
formed!), but it was aggressive, and looked like it was going in the
right direction.
Sun, on the other hand, was a shambles. Its programs (such as they were)
for Intel Solaris, Interactive, SunSelect (the part of Sun that produces
PC-NFS) and Sun hardware were totally separate and totally incompatible.
Since I did this enquiry about a year and a half ago, Sunsoft has turned
around 180 degrees and now requires *no* authorization for any software!
This move is also pretty stupid IMO, because:
1) It's now the *only* commercial Unix that a reseller can get without
demonstrating any Unix smarts at all. You thought Novell dealers were
dumb? Sunsoft doesn't even care who they are!
2) Because it doesn't require authorization, Sunsoft has no idea who
its resellers are (based on the above point, they may not want to
know :-). How can a company implement a VAR program based on that?
When I talked to Sun there were *no* training programs for dealers
(since my company got Novell authorized, they have sent us pounds of
documentation, and a number of videos, in addition to the docs in the
UW product itself).
Moreover, Sun was incredibly arrogant. You practically had to pry VAR
information out of them with a pair of pliers, even at trade shows where
the only attendees were resellers (eg, Merisel's Softeach).
After long consultations and hard comparisons, we decided Sun really
didn't want or care about VARs; a fact borne out by Sun's dependence
on a direct channel. Who needs resellers when you're going direct
to the public anyway? Why would Sun give referrals to resellers when
they can keep all the margin for themselves?
I can sum up Sun's VAR approach as a matter of attitude, as much as
any individual program or thing that Sun reps have told me through the
years; Sun's attitude to VARs is totally one of cold indifference.
Conversations I have had with other VARs have only confirmed this
opinion.
>People seem to be forgetting that one of the reasons
>taht SunSoft purchased Interactive's x86 Unix division is the strong VAR
>and reseller network that Interactive had.
Well, if that's the case it was one of the stupidest buyouts I've seen
in this industry for a while. I had believed that Sun bought Interactive
for its Intel-hardware expertise, nothing more.
I can't speak for much of the US experience; but about the time
that Sun bought Interactive, Interactive's only Canadian distributor
at the time was bought by SCO (and is now SCO Canada), leaving Canadian
distribution in a shambles for many months.
Things have improved significantly over the last year, but they're still
pretty poor. The distribution channels Sunsoft now enjoys are largely
from companies that first carried SMCC anyway; Interactive's distribution
network brought Sun very little indeed.
>Most of these resellers and
>VARs are/will be carrying Solaris 2.x also. In addition new VARs are being
>enlisted and many of the SPARC side system integrators also carry
>Solaris x86.
A culture shift which is IMO almost as severe as getting NetWare VARs to
understand Unix :-).
Remember Novell acquired USL. USL had been delivering MP software to NCR,
ICL, Olivetti, list goes on and on, for YEARS! Do you want to argue this
point? This has included threads as well. The jury is still out on
some object technologies such as NeXTstep/Open Step. Though CORBA is
most likely a must. Just because Sun went out and got software from
NeXT means it's the right bits. Taligent is still working on their
stuff. Novell is examining all the object technologies and standards,
nobody stops looking at the future.
|>
|> Also, note I didn't say UnixWare is a subset of Solaris; I'm just
|> answering the immediate question you posed. And, by the way, access to
|> NetWare file and print service is not aggressive technology. Access to
|> fully developed NetWare NDS might be, if it (NDS, not UnixWare access
|> to it) were mature enough to use. (I assume it will take a little
|> real-world time to wring out the operational problems, since the idea
|> that the whole world revolves around each server is an ingrained
|> NetWare concept.)
|>
|> [snip]
|>
|> : Yet another subjective statement. What criteria was used in determining
|> : feature rich. What features does Solaris have that are not present in
|> : UnixWare? How many features does UnixWare have the Solaris doesn't? :^)
|>
|> Ignoring packaging and thinking only of availability, I can think of
|> very few. Perhaps you (or George, or someone who has actually done the
|> analysis) would care to list them.
You are right, this is a list I would like to see as well. My whole point
was that I wanted an objective list. Not these blanket statments such as
my X is better than your X. We need facts!
|>
|> : How about price? The value of UnixWare is not diminished at all if you
|> : are not going to use the NetWare connectivity. UnixWare is just as capable
|> : OS as is Solaris. You choose what you need.
|>
|> Price is where UnixWare really hurts (compared to perception), in the
|> heterogeneously networked system arena. UnixWare PE is cheap enough,
|> but woefully incomplete. By the time you've added SDK (for the
|> utilities someone thought I could do without) and NFS (which is
|> required for NIS even if you don't want NFS, which I consider a
|> required base function), UnixWare PE is about the same price as
|> Solaris. And the two-user Solaris is complete. Period.
I still think UnixWare is cheaper. I believe that a PE and SDK from
Information Foundation is about $259.00. What is the price of Solaris
as I do not know.
|>
|> : I believe one of the VARs such as Evan can answer how resellers are better
|> : suited to handle you than direct route. How about having them close at
|> : hand when problems arise? Novell also provides direct support through
|> : support contracts and the 1-800-NETWARE number. You decide what support
|> : you need.
|>
|> Resellers are rarely of use in solving my problems. Sun's Catalyst has
|> been. I understand Novell is trying to get a developer's program
|> going, but it's not yet as well-known, active, or effective as
|> Catalyst.
|>
|> [snip]
Evan gave a good discussion on this.
|>
|> : Currently (And I emphasize currently) rely on third party vendors for
|> : object support. We do provide a full C/C++ development environment for
|> : UnixWare. Is NextStep the leading object environment? Will it be? Only
|> : you can decide how important this is to you. Novell is persueing object
|> : technology just like the rest of the industry. The jury is still out
|> : on object technology. Some say NeXTstep, some say Taligent, some say
|> : Cairo [I don't know why though :^) ]. There are many third party options
|> : as well.
|>
|> When I develop release 7.0, I'll worry about Cairo and Taligent.
|> NextStep *is* the leading environment now, because it exists, it works,
|> it ships, while the others first ship is long off. In addition, I'm
|> none too sure I want to wait for Novell to ship them even after they're
|> out. There is reason to doubt Novell's commitment to developer tools.
|> Where is AppWare? When will CDE be a standard part of UnixWare PE?
|>
Why doubt Novell's commitment to developer tools? This is an area I am
intimately familiar with, and we are examining various options to
improve our offerings. We have C and C++ for a collective price of about
$175.00 (Assuming some discount on the SDK). I am curious though what
developers would like. Give me your ideas and I will bring them to the
meetings I participate in. Is anybody shipping all of CDE yet? We are
working on it just like the rest.
|> : Our network management tools are improving, after all we are the largest
|> : network software company in the world. We provide many of the same
|> : network tool the Solaris does. I can not say for sure though because I
|> : haven't seen all the tools provided in Solaris and how they differ to UnixWare.
|>
|> Nothing personal, Darren, but I've often felt that no one involved with
|> UnixWare was really aware of what a real heterogeneous Unix-style
|> network fully exploiting the facilities of HPUX, AIX, OSF, or Solaris
|> looks like. In the market I work in, SCO and Netware are invisible.
|> TCP/IP, NFS, automount, RPC, NIS, and mingled local- and wide-area
|> networks are the opening joke; they are assumed, not notable features.
Yea, I agree that what was once touted as features, is pretty much requirements
in the networking area.
Have you seen the insert in the Open Systems Today outlining UnixWare. I
think Novell is clearly showing it's plans for UnixWare. Believe me, this
company is commited to UnixWare. The recent advertising will show that.
In terms of NetWare being more important than UnixWare, I would probably
rewrite that to say NetWare is more profitable than UnixWare. And after
all, money is what puts bread on my families table.
Darren R. Davis
UnixWare Developer Support Engineer
Novell Developer Support
Disclaimer: There is probably enough of my opinion expressed here that I
should note that these are my feelings and obviously do not reflect those
of Novell.
In article <3c8i58$5...@crl9.crl.com>, jpat...@crl.com (J. Heather Patrick) writes:
|> In article <D0I0J...@ssbunews.ih.att.com>,
|> 55433-jack fijolek(hhall) <ja...@iexist.flw.att.com> wrote:
|> >
|> >In article <3c5cos$b...@crl7.crl.com>, jpat...@crl.com (J. Heather Patrick) writes:
|> >|>
|> >|> Do you think 10 reasons comprises "more capable", or should I go on?
|> >|>
|> >|>
|> >Go on because a lot of this disappears in UW2.0 (ie. X env).
|>
|> Glad to hear it. Although I'll believe it when I see it :-)
|>
|> >UW did a nice layered virtual machine for X, and X ain't nice.
|>
|> What do you mean in this case by "virtual machine for X"?
|>
|> I shall now, by popular demand, elucidate upon the points I made, which
|> should already be clear to people who have used both unixware and solaris.
|>
|> THe following comparison pertains to:
|> Solaris 2.4
|> Unixware 1.1 (cause we ain't got no 2.0)
|>
|> Better NFS:
|> the nfs daemon for solaris is multithreaded
|> (+ more reasons that I dont remember, but a sun engineer could
|> probably point out)
This is probably a good thing for performance.
|>
|> More full set of code libraries:
|> As I pointed out in email to someone, solaris has the goodies like
|> strcasecmp(). UW1.1 does not.
|>
UnixWare has strcasecmp() in /usr/ucblib/libucb.a, please keep your
facts straight.
|> Better X server:
|> R5 based. REAL implementation of standard R5, including 16-bit fonts.
|> (there is an optional package called metrolink that claims
|> to provide R5 for unixware. no MITSHM. no 16-bit-fonts)
|> MITSHM extension.
|> DPS (Adobe-DPS-Extension, AND DPSExtension)
|> Multi-Buffering
|> MIT_SUNDRY_NONSTANDARD
|> X3D-PEX
|> XimputExtension
|> XTEST
We provide an R5 server on xse...@summit.novell.com. There are several
third party X servers such as Metrolink and X inside, though I believe
that UnixWare's is excellent. I do know that our bench mark numbers are
some of the best. Kumar periodically posts X benchmarks for various
cards here. I would use this info for a source of comparison. In terms
of extensions that is many of the third parties claims to fame.
|>
|> Better X server environment:
|> A real olwm. the pseudo-olwm with unixware 1.1 is broken. i dont
|> remember how right now, sorry.
Sorry, but olwm IS DEAD. Motif has won. I am not saying that this is
good, I thought Open Look was nice. Our Open Look was extended with
the MoOlit stuff to include a Motif like look and feel. Though, as I
stated above we now just use mwm.
|>
|> A real xterm. The "xterm" with unixware is a very sad joke.
AGREED! I happen to use the MIT xterm from ftp.novell.com.
|>
|> More stuff I dont remember right now, but other users of both systems
|> should be able to fill in.
|>
I was hoping that you would. You were the one making claims. I just want
facts. And, If Solaris has better features, GREAT competition is good.
We want to make UnixWare the best environment, not a bad thing to shoot
for.
|> Working man pages:
|> Source for man pages is EXTRA in uw1.1?? Come ON. And the
|> apropos/whatis stuff is useless without it.
There is a fix for the whatis stuff. Though, I tend to use the new
dynatext browser in UnixWare 2.0 for manuals. I happen to mostly use
the X environment. I know some people are still character based. Their
opinions need to be kept in mind.
|>
|> Plus, the solaris stuff uses the cache generated by catman -w
|> to speed up "man xx" serach times
We have catman pages as well, that just prevents the nroff processing.
|>
|> I apologise for my mistake on the compiler issue.
|>
Again, all I am soliciting for is facts. Lets disect these two OSes and
compare the features objectively. My point in this whole mess was to
explain to the original poster not to accept subjective statements by
anyone (Solaris or UnixWare). Make his own criteria and match the OS to
it.
A subjective statement on my behalf. Sorry, heat of the moment. :^)
What I was going on was my experience with Open Look and the Windowing
environment I used about two years ago on a Sun OS 4.x platform. I had
a hard time getting X stuff to work from the net or ORielly but really
it has been too long ago to remember the details.
>Rafal Boni (rkb5...@uxa.cso.uiuc.edu) wrote:
>
>: What Dan was trying to get accross, I believe, is that the 1.1.xx where
>: xx is some number that was referred to previously, is just that, a
>: *BETA* release.
>
>Thanks for clarifying this. I had honestly not grasped Dan's point. But
>now that you are telling me, I can at least answer it!
That's because you did read my article carefully enough and removed my
first paragraph from your follow-up :-)
>
>: You were saying how shitty Linux QC was, and Dan gave
>: an example of the exact same process in the corporate world...
>
>No, he did not (which may well be why the point escaped me!). No-one here
>would take the attitude "I can't think of any way of testing this, so let's
>put it into a beta release and see what happens." If it makes it into beta,
>it has already undergone quite a bit of testing. The point of beta testing
>is to expose it to all the conditions the original testers didn't think of!
>It's not to make their life easier.
That's precisely why I used "test" instead of "beta test".
>
>: If you want a Linux kernel that is stable, etc., don't run the daily
>: development version [ie, the *BETA* version], run a blessed and stable
>: release version. If you're hacking on the kernel, you might want that
>: beta version, and hence it's out there and available....
>
>Actually, I suppose where I was indeed unfair, is that those odd-numbered
>releases (or whatever) are actually not beta at all: they are alpha at best;
>the code that's shipped to fellow developers to have a look at.
This is partly true. There is no team of alpha testers, so some changes
are only tested by their author and by Linus (if he has the hardware
needed, which is not the case for many device drivers). So, the "beta"
versions are more like alpha than beta, this is why calling them simply
"test versions" is more appropriate.
The advantage is that anybody (developer or not) can test the new kernel.
If he's competent enough, he can try to fix the problems detected, otherwise
he can report them in comp.os.linux.development. The result is that any
change is tested on a very large number of different hardware configurations,
and any problems who couldn't be noticed on the developers' machines will
be reported before the change is incorporated in the production kernels.
Based on what Mr. Gerrish said about his 4.1.3 systems, the answer would
have to be yes. There have been several responses here about systems
running 2.3 that regularly stay up longer than his 4.1.3 claim. So Mr.
Clarke's statement about 2.4 is not outrageous (though he may be accused
of blowing his own horn :-) ).
System uptime depends on a million different things, and if you happen to
be triggering a bug that hasn't been patched for whatever reason, then it's
going to be pretty poor for you. Someone else might stay up for months on
the same software revision because they don't run the same applications.
It's also likely that the 4.1.3 systems described above have different
hardware installed than the Linux systems, and something in that may be
causing the problems. Whatever the situation, I can guarantee you that
there are more differences between them than just the OS.
You can't make definitive statements about relative OS reliability one way
or the other. All you can talk about is what you've experienced.
--
Ruth Milner NRAO/VLA Socorro NM
Manager of Computing Systems rmi...@aoc.nrao.edu
I'm sure they could!
>
>More full set of code libraries:
> As I pointed out in email to someone, solaris has the goodies like
> strcasecmp(). UW1.1 does not.
Gee! maybe you should have looked in /usr/ucbinclude
on a UW system before you made this statement.
>
>Better X server:
> R5 based. REAL implementation of standard R5, including 16-bit fonts.
> (there is an optional package called metrolink that claims
> to provide R5 for unixware. no MITSHM. no 16-bit-fonts)
> MITSHM extension.
> DPS (Adobe-DPS-Extension, AND DPSExtension)
> Multi-Buffering
> MIT_SUNDRY_NONSTANDARD
> X3D-PEX
> XimputExtension
> XTEST
Except for the PEX extension this looks just like the output
I get from xdpyinfo on a UW machine.
>
>Better X server environment:
> A real olwm. the pseudo-olwm with unixware 1.1 is broken. i dont
> remember how right now, sorry.
Oh well! UW ships a "REAL" mwm and Motif development kit
with their system. Sun is still shipping OLIT and charging
$295.00 for a Motif developers kit (single user license).
>
> A real xterm. The "xterm" with unixware is a very sad joke.
Its hardly as sad as you say, and BTW, if you REALLY must
have the REAL xterm you can just download it and compile
it yourself. OH! and BTW, you can compile it on the c
compiler that comes in the $69.00 SDK.
Whats Sun getting for their SDK today? Lets see, the SunExpress
catalog says the SPARCworks Professional single user license
is $995.00. OH! but don't forget your corporate discount!
>
> More stuff I dont remember right now, but other users of both systems
> should be able to fill in.
Well lets hope that they finally got their act together. After
slow-aris 2.2 and extemely slow-aris 2.3 they had better
get it right. Lets not even mention the numerous patches
that we had to install on our 2.3 systems just to make them
usable.
>
>Working man pages:
> Source for man pages is EXTRA in uw1.1?? Come ON. And the
> apropos/whatis stuff is useless without it.
HMMMM!!! UW comes with the finger-tip library that has
search capabilities. How much does Sun get for AnswerBook
these days???
>
> Plus, the solaris stuff uses the cache generated by catman -w
> to speed up "man xx" serach times
>
>I apologise for my mistake on the compiler issue.
>
--
/* Corey Brown (WB0RXQ): 20m, 15m, 2m(146.82) 70cm(443.65) */
/* AT&T NSD | co...@hustler.att.com */
/* Alpharetta, Ga 30202 | attmail!wcbrown */
/* (404)750-8071 | New rays from an ancient sun (JS) */
>: How about price? The value of UnixWare is not diminished at all if you
>: are not going to use the NetWare connectivity. UnixWare is just as capable
>: OS as is Solaris. You choose what you need.
>Price is where UnixWare really hurts (compared to perception), in the
>heterogeneously networked system arena. UnixWare PE is cheap enough,
>but woefully incomplete. By the time you've added SDK (for the
>utilities someone thought I could do without) and NFS (which is
>required for NIS even if you don't want NFS, which I consider a
>required base function), UnixWare PE is about the same price as
>Solaris.
I just called Merisel (one of the few distributors who carries both Sun
and Novell) for some comparison pricing.
As of *today*, the wholesale cost of the Solaris 2.1 uniprocessor desktop
is exactly 48.3% more expensive than the combination of UnixWare Personal
Edition, SDK and NFS. Add C2 Auditing and UnixWare is still less.
UnixWare also allows the bare-bones PE to turn Intel hardware into a
capable X terminal for 31% of the cost of Solaris' desktop. What is
one person's "woeful" incompleteness is another person's flexibility
of not being forced to buy everything for a minimal configuration.
Debates about bundling-versus-unbundling invariably degenerate into
religious arguments.
I agree with the comment about NIS, though. Wasn't it included in the
1.1.2 update whether you had NFS installed or not?
>And the two-user Solaris is complete. Period.
Unless you want the driver development kit; bundled with the UnixWare
SDK, $300 more for Solaris. While the driver stuff is certainly
not something that everyone wants, "complete...period" is clearly
incorrect because there *is* some unbundling. Sun's just drawn the
line at a different spot.
>Resellers are rarely of use in solving my problems. Sun's Catalyst has
>been. I understand Novell is trying to get a developer's program
>going, but it's not yet as well-known, active, or effective as
>Catalyst.
Absolutely correct. The Yes program is in its infancy compared to
Catalyst, but Catalyst is SPARC-centric and really hasn't had to cope
with the wonderments of PC commodity hardware :-)
>Third, people feel that way because Novell, outside of Usenet, has no
>clear message about UnixWare. I realize they are trying, but it hasn't
>worked yet, and a faux pas like the recent announcement of the
>deemphasis of the desktop and the rapprochement with Microsoft hurts.
>It may feel good to blame the press for misinterpretation, but if you
>use multisyllable words and compound sentences with those guys, no
>one can predict what they'll hear.
Agreed.
> Gee! maybe you should have looked in /usr/ucbinclude
> on a UW system before you made this statement.
Libraries in /usr/ucb* don't count. They're not part of the "native"
OS.
> Oh well! UW ships a "REAL" mwm and Motif development kit
> with their system. Sun is still shipping OLIT and charging
> $295.00 for a Motif developers kit (single user license).
Motif includes & libraries are part of Solaris. mwm is not.
(But then I don't know anyone using it voluntarily, where's
mvwm? That's what people need before they'll switch)
Motif sucks!
Casper
: This is NOT the way code is integrated into the other free OS's, and I
: would venture to say that no-one is forced to run the 'patch of the day'
: release of Linux either.
: People in suits 'DO' use free OS's, and saying that they don't is simply
: not true. However, for critical projects you NEED to have someone at
: the other end of the phone who WILL answer your question and WILL devote
: time to fixing YOUR bugs. This is where the free OS's fall short, not
: in the way they do development.
: Nate
: --
: na...@bsd.coe.montana.edu | FreeBSD dude and all around tech.
: na...@cs.montana.edu | weenie.
: work #: (406) 994-4836 | Unemployed, looking for permanant work in
: home #: (406) 586-0579 | CS/EE field.
In the commercial world, it's called a beta program and it's done by a
limited number of sites, as far out of the public eye as they can keep it,
for exactly the reasons we're seeing here - the CEO would have a cerebral
hemorrhage if some analyst at some large shareholder ever heard about the
development process (e.g. 'patch of the hour') involved in getting their
product ready for release.
Nate Williams (na...@bsd.coe.montana.edu) wrote:
: Then somebody should take the manager of that group out and shoot him.
: Either that or his manager for giving unreasonable deadlines that can't
: be met with decent testing.
Until you've actually implemented a Unix regression test, don't be so
naive. If it was just a matter of a dumbass manager, do you think they
wouldn't have figured that out by now?
Real testing is hard, hard, hard. Let me know when you have a solution.
: If microsoft does one thing right it's test it's software. Granted, it
: still never seems to find the bugs that the average user find the first
: time around, but they do indeed spend alot of their resources trying to
: break their own products.
Reread that paragraph and tell me the content? I'm supposed to (a)
believe that Microsoft does good testing but (b) accept that they can't
find the bugs that the average user encounters? And that is good
testing? Maybe the problem here is your definition of testing, I fail
to see what it is.
: >The commercial OS release mechanism is pretty similar to Linux. You send
: >out some alpha junk to a few sites and see what the reaction is. The closer
: >you get to beta the less you allow in. After beta only show stoppers get
: >in.
: That might be the way SUN does things, but I know of a couple other OS
: vendors that don't do things that way. :)
Name them.
: >Stability is important but there is little in the way of testing done to
: >insure stability. SMCC might be fixing that, I understand they have/had
: >Solaris 2.4 months before they shipped it. :-)
: Stability can be tested by putting real world applications on your
: hardware. The way FreeBSD tests it's software is by sticking it on
: wcarchive.cdrom.com. Having 250-350 ftp's is one way of seeing how
: the system reacts under load. :)
That tests 250-350 ftps. So what? Is that it? That's great if I want to
be doing a bunch of ftps. How about a bunch of ftps and a make? Or a
untar with a make? Or X and an untar and SLIP but no ftps?
Oh, did I mention that all the interesting bugs are ones that only show
up under some weirdball combo of unrelated things?