Unixware Documentation
KrayZ
this system. I need all kind of docs including instalation system and
setup it. Where can I find these docs???
Thanks!
Park, Jae-Hwa
KrayZ 이(가) <376DE957...@kryz.es> 메시지에서
작성하였습니다...
You can buy a following book via www.amazon.com:
UnixWare System Administration
By Gene Henriksen and Melissa Henriksen
1st Edition 1999
537 pages, ISBN 1-57870-080-9
Macmillan Technical Publishing U.S.A
It contains so good informations for installation & administration.
Jaehwa
Joe Doupnik
> I'm a Linux User migrating to Unixware and I need documentation about
> this system. I need all kind of docs including instalation system and
> setup it. Where can I find these docs???
The docs come with the product. There is also a paper installation
guide which comes with it. And everything is also on the net via SCO's
web site. Rather obvious places to look.
Once you've made the mental jump to UW and have run UW for a little
time I believe you will find it to be a very large distance ahead of Linux.
Joe D.
Warren Young
...Until he tries to build egcs/gcc or emacs or gdb or... B-)
One other person in this thread recommended the Hendriksen book.
That's a good reference, especially for UW-specific stuff like sacadm.
(Despite the number of Unixes based on SVR4.2, UW appears to be the
only one that uses the entire SAF mechanism. Thus, most books don't
cover it fully.) For more general Unix advice, I think the Red Book
(_Unix System Administration Handbook_ 2/e, by Nemeth et al.) is
wonderful. It even applies to Linux, should you decide to go back.
;-)
= Warren -- http://www.cyberport.com/~tangent/
Bruce Schuck
> I'm a Linux User migrating to Unixware and I need documentation about
> this system. I need all kind of docs including instalation system and
> setup it. Where can I find these docs???
The online docs at uw7doc.sco.com are pretty much a duplicate of what
comes with the product.
I also bought the UW Administration book mentioned in another reply,
and it is quite good.
There is one critical point before doing the migration. Check SCO's
compatible hardware list! UW can be quite picky about what hardware
it's running on.
Bruce S.
Nige
>
> I'm a Linux User migrating to Unixware and I need documentation about
> this system. I need all kind of docs including instalation system and
> setup it. Where can I find these docs???
>
Don't know, but I'm a Unixware user possibly migrating to Linux. Where can
I find out the differences?
Cheers,
Nige
--
Remove the zeds to reply by email
Warren Young
comp.unix.unixware.misc:
Nige <zn...@zwg.zicl.co.uk> wrote:
>> I'm a Linux User migrating to Unixware and I need documentation about
>> this system. I need all kind of docs including instalation system and
>> setup it. Where can I find these docs???
>
>Don't know, but I'm a Unixware user possibly migrating to Linux. Where can
>I find out the differences?
First, note that none of the items below deal with opinion, only fact.
It is not my purpose to ignite a flame war here, but simply to give
potential UnixWare deserters an idea of what to expect from Linux.
Flames go to /dev/null, but if you have other items to add to this
list, please post them. I don't care which OS they favor -- I
probably already know about the difference, but just forgot to put it
here. Nothing has been left out due to bias or malice. If my facts
are wrong, please correct me calmly -- it's only ones and zeroes,
after all. I may post a revised list here later, or among my web
pages.
1. UnixWare has better support for high-end apps like terabyte
databases. This stems from having support for Intel's 64 GB memory
hack (anyone who thinks differently of this feature probably also
thinks that the x86 chip architecture is elegant) and for having
support for larger filesystems. (1 terabyte filesystems in the
UnixWare case with 1 TB maximum file size; 2 TB filesystems in the
Linux case, but only 2 GB files.) On the other hand, Linux on an
Alpha or UltraSparc box supports 64-bit memory addressing and file
sizes, which makes memory and file size limitations a hardware problem
rather than an OS problem. The filesystem limitations in 32-bit Linux
are also being worked on -- Linux 2.4 will probably push these back
quite a bit, especially if the newly open-sourced SGI XFS filesystem
is accepted into the kernel. See also item 16, which bears on this
issue.
2. Linux has much better hardware support than UW does, especially
user-level hardware like laptops/PCMCIA, IRDA, TV/radio boards, CD-ROM
burners, 3-D graphics boards, alternative input devices (graphics
tablets, etc.), USB, parallel port devices (NICs, Zip drives, external
IDE) as well as adequate PnP support (better than NT4, at any rate!)
This also extends to common hardware categories: NICs, graphics cards,
sound cards, SCSI cards and printers (by way of built-in support for
ghostscript) all have broader support under Linux. There are a few
cases where UW supports something that Linux doesn't. For example, UW
supports telephony cards, whereas until recently, Linux didn't; the
Linux support for these cards is still somewhat immature. There are
other examples, especially in high-end server hardware like the more
exotic types of RAID controllers. If you count Sequent's efforts, UW
has better top-end SMP support than Linux, though Linux has been known
to run well on 14-processor UltraSPARC systems.
3. It's much easier to get freeware to run on Linux, in general. The
reason for this is that Linux is almost always considered a primary
target platform from day one, whereas UnixWare and other SCO OSes are
usually after-the-fact ports. For the same reason, the typical Linux
distribution comes with more and newer versions of freeware packages,
even when you take Skunkware into account. (Skunkware is around 120
packages, whereas even a relatively slim distribution like Red Hat has
perhaps 400 non-core packages. Distributions like SuSE and Debian
have thousands of packages, all installable at the same time as the
base system.) Many of the packages in a Linux distribution overlap,
because choice is preferred, whereas in UnixWare, only one package (or
just a few) from the available ones is provided. A good example is
text editors: Red Hat provides vim, elvis, nvi, emacs, pico, jed,
jove, the KDE editor (forgot the name; knote?), gnotepad+, GXedit and
gEdit. UnixWare provides vi, pico and the "Typewriter" Motif thingy.
Oh, and both OSes support ed(1). Gotta have ed. B->
4. Third-party software support (binary payware) is similar for both
OSes, but very much non-overlapping. In the low-end server and
user-level apps arenas Linux has the advantage, whereas UnixWare has
ports of some high-end server apps that Linux doesn't. Often, one
system will have a port of a package that the other doesn't, but a
similar competing product is available for the other OS. Example:
Reliant/HA on UnixWare, Net/Equater on Linux. Another traditional
UnixWare stronghold is vertical market apps and small business apps
(bookkeeping, POS, etc.).
5. Linux is generally more user-friendly. This is of course due to a
difference in the Linux and UW target markets. You can get KDE and
other stuff from Skunkware or port it to UW, but the fact that it's a
post-installation matter is significant.
6. UW tends to be more administrator-friendly, as SCO has been working
on the "pretty administration tool" problem far longer than the Linux
community has. (For most of the decade, if you consider sysadm, from
the Novell days.) linuxconf and COAS are good examples of how this is
quickly changing.
7. Some people like the single-source nature of UW. Others like the
freedom of style choice in the Linux world. Those that don't like the
results of these freedoms will see the Linux world as horribly
fragmented. In my experience, this is only a limited problem, of
concern only to those who insist on "just one way to do it". The
difference between any two Linux distributions is less than the
difference between UnixWare 2.1 and OpenServer, for example. (UW7, of
course, brought the two much closer.)
8. UW comes with Motif and CDE in the package. Most distributions of
Linux don't, because these packages aren't free. You can of course
get them from third parties.
9. You get almost everything in a typical Linux distribution that SCO
makes you pay extra for: SMP, SMB/CIFS file sharing, unlimited
concurrent users, directory services, software RAID, a C++ compiler
and Netware file/print support.
10. Online docs for UnixWare and Linux are similar in their scope,
though Linux's are more spread out: man pages, GNU info files, Linux
Documentation Project books, HOWTO files and any additional docs that
come with the package are all provided, and they are by no means
completely overlapping. With UnixWare, almost everything is in
SCOhelp.
11. Both OSes come with similar amounts of paper documentation, unless
you get a cheapie version of Linux, like the $1.89 CDs from Linux
Mall.
12. Third-party documentation for UnixWare is hard to find. I only
know of one book (the Hendriksen job) specifically for UnixWare; most
of the generalist Unix books like Frisch and Nemeth et al. don't even
cover UnixWare -- you have to infer the correct info from their
Solaris coverage. Linux books are, by contrast, easy to find. There
are even two books out that dissect the kernel code, though both still
need to be updated to cover kernel 2.2.
13. Linux doesn't support NDS and WebTop, as UnixWare does.
14. Linux has better networking support than UnixWare does. This is
multifaceted: more protocols (DECnet, SNA), more features
(masquerading, tunneling, QoS, DHCP client), and support for popular
programming standards (e.g. tools like tcpdump and code from the W.
Richard Stevens networking bibles runs on Linux, but often not on
UnixWare).
15. Where both OSes have the same command-line tools, the Linux
counterparts are often more advanced than the ones on UnixWare.
Examples: vim vs. vi, bash vs. ksh, tcsh vs. csh, less vs. more/pg,
ncftp vs. plain ftp, gzip vs. compress, GNU awk, m4, ls, make, man,
tar, and find vs. the SysV flavors, etc. Other good examples are
vixie-cron and the Linux version of man: both are far more flexible
than their UnixWare counterparts.
16. The UnixWare disk device naming scheme allows for more online
storage because it can support more volumes. So far as I know, the
Linux kernel doesn't have any inherent limitations in this regard, but
the limitations stem from the way the OS is configured in all
distributions I'm aware of. Specifically, you can easily have 240
volumes (sd[a-p][1..15]) under Linux, whereas UW supports over 1000,
IIRC. More importantly, the Linux disk naming scheme doesn't have
much to do with the SCSI ID or partition number. So, adding a disk to
a SCSI chain with a lower ID than an existing disk can shift the /dev
names assigned to the disk under Linux; under UnixWare, this would not
happen. Note that Linux will be getting a System V-like naming setup
in the next version.
17. Linux's loadable module support is much more powerful than
UnixWare's, and more of Linux's drivers are dynamically-loadable than
UnixWare's.
Aside from all of the above, there are numerous style differences:
1. UnixWare believes in TLI/XTI whereas Linux believes in Berkeley
sockets. (Both OSes support the other standard, but the preferences
are still there.)
2. UnixWare believes in the Service Access Facility, whereas Linux
believes in separate getty and lpd processes.
3. UnixWare believes in System V options for tools like ps, ping and
ls whereas Linux believes in the BSD flavor.
4. UnixWare believes in /tmp as a RAM disk whereas Linux believes in
/tmp as a disk-based filesystem.
5. UnixWare believes in only a basic /proc whereas Linux believes in
giving away all kinds of info in /proc. (This is why Linux has more
system monitoring tools: the information is readily available, and
documented. In UW, you usually have to dig for it in
poorly-documented kernel structures via /dev/kmem.)
6. UnixWare believes in a combination of DCU, the /etc/conf.d
directory and the opaque id* tools for kernel configuration whereas
Linux believes in a straightforward makefile-based system.
7. UnixWare believes in STREAMS whereas Linux does not. (Linux
prefers speed to being able to dynamically reconfigure the network
stack. There's an add-on STREAMS package available, but the kernel
developers are adamant that it will never be part of the core
distribution.)
8. The directory layouts are, of course, rather different.
Nige
Warren Young wrote:
>
> This comparison was sparked by the following post in
> comp.unix.unixware.misc:
>
>
Excellent!
Bartek Golenko
>This comparison was sparked by the following post in
>comp.unix.unixware.misc:
>
>2. Linux has much better hardware support than UW does, especially
>tablets, etc.), USB, parallel port devices (NICs, Zip drives, external
Well, USB support for Linux is quite poor right now AFAIK
>16. The UnixWare disk device naming scheme allows for more online
>storage because it can support more volumes. So far as I know, the
>Linux kernel doesn't have any inherent limitations in this regard, but
>the limitations stem from the way the OS is configured in all
>distributions I'm aware of. Specifically, you can easily have 240
>volumes (sd[a-p][1..15]) under Linux, whereas UW supports over 1000,
>IIRC. More importantly, the Linux disk naming scheme doesn't have
>much to do with the SCSI ID or partition number. So, adding a disk to
Is this really true ? I have never used SCSI disk with Linux, but on IDE
this naming convention is perfectly precise - hd[a-d][1-15]
a - first drive on first controller
b - second drive on first
c - first on second
d - second on second
Number - partition number.
Anyway - There is an option in 2.2.x Linux Kernel series, that offers
"Unixware slices support" (it's still experimental - you have to select
"Prompt for developement and/or incomplete code/drivers" to see it).
--
Bartek Golenko
bar...@caton.com.pl
Joe Doupnik
> This comparison was sparked by the following post in
> comp.unix.unixware.misc:
>
> Nige <zn...@zwg.zicl.co.uk> wrote:
>
>>> I'm a Linux User migrating to Unixware and I need documentation about
>>> this system. I need all kind of docs including instalation system and
>>> setup it. Where can I find these docs???
>>
>>Don't know, but I'm a Unixware user possibly migrating to Linux. Where can
>>I find out the differences?
>
> First, note that none of the items below deal with opinion, only fact.
That's a pretty good quick summary. To add a smidge from recent
experience here --
I've had a kernel modification task underway for the past month,
to demonstrate a replacement for Nagle mode in TCP stacks. I bought two
Linux distributions (RedHat 6 and Caldera 2.2), Solaris 7 source code, and
FreeBSD 3.2 source code. From this and plenty of years working inside other
systems my view on the Linux vs SysV item is there are names for things
and there is content under those names, and one may not imply the other.
Linux has lots of names, and an abundance of third party utilities. SysV
has fewer names, much better organized, and does not ship with the third
party material in any significant extent.
Leaving aside the fringe third party apps what I find is the SysV
material is solid, stogey, and not the cutting edge in most cases. But its
well done for the long term and generally finished. The Linux material is
all over the map when we peek under the covers, not confidence inspiring
and not finished, and I was less than impressed. This reflects the attitude
of the developers, and both have good things to offer. The BSD material
is solid, well designed and dependable; it is also very long in the tooth
on many matters.
The sockets vs Streams item is another much misunderstood affair.
The two are not the same thing. First there is the TCP stack. SysV uses
Streams (from OSI days) and that turns out to be both complicated and
long term flexible. BSD systems (from which Linux draws its guidelines)
are single purpose stacks, and hence simpler. Above the stack are the
interfaces such as TLI and sockets. BSD and Linux stay with sockets,
SysV offers both. Sockets is not the end of the earth just because it
is initially easier to understand and program to, but then most folks
stop at that point. It turns out that both approaches are about the
same speed performance, provided both are in the kernel (and UW 7's
is so).
Many TCP tools are designed and written for BSD, plain and simple.
The authors don't seem to know more than that. Hence the pain in building
them on SysV machinery. But in most cases the programs do build and the
task is getting slightly easier (because SysV adds more BSD-isms, not that
the programmers are learning more). Support of fancy things (shared memory,
threads, etc) in Linux is definitely a hit or miss affair these days, and
thus both building and running successfully is a major headache.
Make files and id* stuff. Personally I prefer precision and hence
the id* approach to changes. Make files reach out and touch far too many
things, and may require a very large body of source code to work. And when
one small component in the make tree does not work then everything stops.
RedHat has this problem with peripheral Ham Radio stuff, and I wanted to
rebuild the TCP stack. Clearly, the commercial Unices don't give away
sources to play the make game, so the make vs id* argument is a non-starter.
Loadable modules. 99% of the time this is a non-issue. We don't
normally load them manually. SysV buries the ways to do this, Linux makes
a big noise and then leads one into utter confusion. The need to even
play this game depends on how well the main o/s does its job in the first
place.
I approached all this with a long term SysV bias (I have one
of those AT&T source licenses from the paleolithic era). I was pleased by
the BSD code (yes, I have Rich Stevens' books) for logical finesse and
compact expression. I was dismayed by the scattered approach to things in
Linux distributions, but equally impressed by the work that individuals
put in to get that far. For getting work done day after day I place
emphasis on stability, and that means the major SysV products first and
the BSD derivatives second. To deal with the latest wrinkle in PC hardware
then Linux will be there far quicker than the corporate products, and
probably faster than the BSD folks will want their code base to evolve.
Personally I'd rather not have to rebuild the o/s; the box should just sit
there, get a periodic bunch of patches, and run.
For the strongest file systems there is little question that UW with
the Veritas material is the cutting edge and the preferred solution at this
time. UFS is nice but limited and vulnerable.
In the end all three kinds of systems do work, to state a truism.
What it takes to get them into that shape, smooth them out, and maintain
them differs dramatically.
Joe D.
John Hughes
> In article <377748bb....@news.cyberport.com>, Warren Young wrote:
> > More importantly, the Linux disk naming scheme doesn't have
> >much to do with the SCSI ID or partition number.
> Is this really true ? I have never used SCSI disk with Linux, but on IDE
> this naming convention is perfectly precise - hd[a-d][1-15]
> a - first drive on first controller
> b - second drive on first
> c - first on second
> d - second on second
>
> Number - partition number.
Answer quickly: if I have a SCSI bus with ID's 1, 4 and 6 what are the
device nodes?
What are they if I add ID 3?
(What happens if I do this without a reboot as I can do on UW?)
(UnixWare answer:
/dev/rdsk/c0b0t1s0, /dev/rdsk/c0b0t4s0, /dev/rdsk/c0b0t6s0.
Adding ID 3 gives a new /dev/rdsk/c0b0t3s0, leaves others unchanged).
--
John Hughes <jo...@Calva.COM>,
Atlantic Technologies Inc. Tel: +33-1-4313-3131
66 rue du Moulin de la Pointe, Fax: +33-1-4313-3139
75013 PARIS.
John Hughes
> The sockets vs Streams item is another much misunderstood affair.
...
> It turns out that both approaches are about the same speed
> performance, provided both are in the kernel (and UW 7's is so).
Now you've done it!
Don flameproof underwear now!
sparr...@my-deja.com
j...@cc.usu.edu (Joe Doupnik) wrote:
> The sockets vs Streams item is another much misunderstood affair.
> uses Streams (from OSI days) and that turns out to be both
> complicated and long term flexible. BSD systems (from which Linux
> Above the stack are the interfaces such as TLI and sockets. BSD and
> Linux stay with sockets, SysV offers both. Sockets is not the end of
> the earth just because it is initially easier to understand and
> that both approaches are about the same speed performance, provided
> both are in the kernel (and UW 7's is so).
An old Linux STREAMS project (http://email.gcom.com/LiS) dating back to
1995 has recently had a major overhaul and is getting acceptance from
vendors who want to port their STREAMS based code to Linux.
There are no plans to distribute it with the Linux kernel, but it will
load as a module into an unpatched 2.2 kernel.
With the exception of an alpha level IPX protocol stack I released last
week there are still no protocol stacks in it, but the basic framework
for STREAMS based kernel level programming is fairly complete.
Regards,
Ole Husgaard
Sent via Deja.com http://www.deja.com/
Share what you know. Learn what you don't.
Brian K. White
> >comp.unix.unixware.misc:
> >
>
> >2. Linux has much better hardware support than UW does, especially
>
>
> >storage because it can support more volumes. So far as I know, the
> >Linux kernel doesn't have any inherent limitations in this regard, but
> >the limitations stem from the way the OS is configured in all
> >distributions I'm aware of. Specifically, you can easily have 240
> >volumes (sd[a-p][1..15]) under Linux, whereas UW supports over 1000,
> >IIRC. More importantly, the Linux disk naming scheme doesn't have
> >much to do with the SCSI ID or partition number. So, adding a disk to
> this naming convention is perfectly precise - hd[a-d][1-15]
> a - first drive on first controller
> b - second drive on first
> c - first on second
> d - second on second
>
> Number - partition number.
>
> "Unixware slices support" (it's still experimental - you have to select
> "Prompt for developement and/or incomplete code/drivers" to see it).
>
> --
> Bartek Golenko
> bar...@caton.com.pl
And how would devfs and/or devfsd figure into this comparison? To hear
the devfs author talk on linux-kernel mail list, it can be used to
present your devices according to any possible style, nameing convention
or ruleset you want to dream up. I have not used it so I cannot say how
true this is.
do...@28.usenet.us.com
: programming standards (e.g. tools like tcpdump and code from the W.
: Richard Stevens networking bibles runs on Linux, but often not on
: UnixWare).
I thought The honorable W.R.Stevens might have gone away by now.
His proclamations on how he _thought_ SVR4 must work, long before it was
released, caused some difficulties, as he described, in detail, how BSD and
SVR4 handled some atomic operations...
He was wrong, way wrong. But he was published, and that level of detail
was not published for SVR4, even after it was released...
Bible? He was his own prophet.
I'm not surprised his examples don't work on Unixware.
--
---
Clarence A Dold - do...@network.rahul.net
- Pope Valley & Napa CA.
Bartek Golenko
>bar...@caton.com.pl (Bartek Golenko) writes:
>
>> In article <377748bb....@news.cyberport.com>, Warren Young wrote:
>> >much to do with the SCSI ID or partition number.
>
>> this naming convention is perfectly precise - hd[a-d][1-15]
>> a - first drive on first controller
>> b - second drive on first
>> c - first on second
>> d - second on second
>>
>> Number - partition number.
>
>device nodes?
Quick answer - I HAVE NEVER USED SCSI WITH LINUX, so how could I know ;) ?
I have just checked in /usr/doc/linux/Documentation/devices.txt -
0 = /dev/sda First SCSI disk whole disk
16 = /dev/sdb Second SCSI disk whole disk
32 = /dev/sdc Thirdi SCSI disk whole disk
...
240 = /dev/sdp Sixteenth SCSI disk whole disk
It sucx ;) Hope 2.3.x will fix it ;)
--
Bartek Golenko
bar...@caton.com.pl
arthur marsh
by someone who was one of the architects of SVR4.
On 24 Jun 1999 do...@28.usenet.us.com wrote:
> Warren Young (tan...@cyberport.com) wrote:
> : programming standards (e.g. tools like tcpdump and code from the W.
> : Richard Stevens networking bibles runs on Linux, but often not on
> : UnixWare).
>
Bill Vermillion
>> In article <377748bb....@news.cyberport.com>, Warren Young
>> wrote:
>> > More importantly, the Linux disk naming scheme doesn't have
>> >much to do with the SCSI ID or partition number.
>> Is this really true ? I have never used SCSI disk with Linux,
>> but on IDE this naming convention is perfectly precise -
>> hd[a-d][1-15]
>> a - first drive on first controller
>> b - second drive on first
>> c - first on second
>> d - second on second
>> Number - partition number.
>Answer quickly: if I have a SCSI bus with ID's 1, 4 and 6 what are the
>device nodes?
>What are they if I add ID 3?
>(What happens if I do this without a reboot as I can do on UW?)
>(UnixWare answer:
>/dev/rdsk/c0b0t1s0, /dev/rdsk/c0b0t4s0, /dev/rdsk/c0b0t6s0.
>Adding ID 3 gives a new /dev/rdsk/c0b0t3s0, leaves others unchanged).
The UnixWare naming scheme is pretty standard in the V.4 world and
make a lot of sense.
From above c0b0t4s0
c - the number of controllers. I remember Bela and I went over
this a LONG time ago. At that time - and it may have changed -
software suppored up to 15 controllers. c0 - control zero
b - bus number. Many SCSI cards have multiple busses. It
means you have an equivalent of as many singles cards as you have
busses. b0 - bus zero
t - target. The ID of the target device - in the wide world
it is 15.
s - designated the LUN - Logical Unit number - there can be 7
of those for any target.
Just quick math shows that you could easily have 4725 targets.
In today's world where system access more and more data the
simplistic Linux method as described above just doesn't fit in to
well IMO.
--
Bill Vermillion bv @ wjv.com
Kostis Mentzelos
> make a lot of sense.
>
> From above c0b0t4s0
>
> c - the number of controllers. I remember Bela and I went over
> this a LONG time ago. At that time - and it may have changed -
> software suppored up to 15 controllers. c0 - control zero
>
> b - bus number. Many SCSI cards have multiple busses. It
> means you have an equivalent of as many singles cards as you have
> busses. b0 - bus zero
>
> t - target. The ID of the target device - in the wide world
> it is 15.
>
> s - designated the LUN - Logical Unit number - there can be 7
> of those for any target.
>
> Just quick math shows that you could easily have 4725 targets.
>
> In today's world where system access more and more data the
> simplistic Linux method as described above just doesn't fit in to
> well IMO.
>
> --
> Bill Vermillion bv @ wjv.com
Ok, now I feel free to plug my 4725 hard drive into my machine.
It running UnixWare of course.
Joe Doupnik
> In article <ufaetqd...@microlite.CalvaCom.FR>,
> John Hughes <jo...@AtlanTech.COM> wrote:
>>bar...@caton.com.pl (Bartek Golenko) writes:
>
>>> In article <377748bb....@news.cyberport.com>, Warren Young
>>> wrote:
>
>>> > More importantly, the Linux disk naming scheme doesn't have
>>> >much to do with the SCSI ID or partition number.
>
>>> Is this really true ? I have never used SCSI disk with Linux,
>>> but on IDE this naming convention is perfectly precise -
>>> hd[a-d][1-15]
>
>>> a - first drive on first controller
>>> b - second drive on first
>>> c - first on second
>>> d - second on second
>
>>> Number - partition number.
>
>>Answer quickly: if I have a SCSI bus with ID's 1, 4 and 6 what are the
>>device nodes?
>
>>What are they if I add ID 3?
>
>>(What happens if I do this without a reboot as I can do on UW?)
>
>>(UnixWare answer:
>
>>/dev/rdsk/c0b0t1s0, /dev/rdsk/c0b0t4s0, /dev/rdsk/c0b0t6s0.
>
>>Adding ID 3 gives a new /dev/rdsk/c0b0t3s0, leaves others unchanged).
>
> make a lot of sense.
>
> From above c0b0t4s0
>
> c - the number of controllers. I remember Bela and I went over
> this a LONG time ago. At that time - and it may have changed -
> software suppored up to 15 controllers. c0 - control zero
>
> b - bus number. Many SCSI cards have multiple busses. It
> means you have an equivalent of as many singles cards as you have
> busses. b0 - bus zero
>
> t - target. The ID of the target device - in the wide world
> it is 15.
>
> s - designated the LUN - Logical Unit number - there can be 7
> of those for any target.
"s" is slice, not LUN (a SCSI term and most SCSI controllers use
only one LUN). Slice is a Unix anachronism independent of disk drive design.
Various Unices mix slices and PC disk partitions, and mix them
very badly indeed. Linux also mixes them but in its own way and not for
the better. Recall those slices disguised as disk idents which reside
within a "extended" partition on Linux. Shades of MS work. SysV for PCs
does pick out "disk partitions" with a "p" prefix.
I've said this before here and to the UW folks, but here it is
again. The ctbsp naming scheme is just dandy for computers and horrid for
people. Disks 1, 2, 3 or disk labels is being people organized. I wish
"slices" would go away in this day and age. I wish UW disk labels or
mount point names (/usr, /home, diskette1..) were used throughout the
system. I wish action were to occur. I wish, I wish...
Joe D.
Nige
> I've said this before here and to the UW folks, but here it is
> again. The ctbsp naming scheme is just dandy for computers and horrid for
> people. Disks 1, 2, 3 or disk labels is being people organized. I wish
> "slices" would go away in this day and age. I wish UW disk labels or
> mount point names (/usr, /home, diskette1..) were used throughout the
> system. I wish action were to occur. I wish, I wish...
Yes, having grown up with mainframes, this is something that's always narked
me about Unix systems. Why can't the discs have labels? Oh, go on.
Please? Pretty please?
Still, I prefer "cbtds" to arbitrary (and changing) numbers.
John Hughes
> Joe Doupnik wrote:
> > I've said this before here and to the UW folks, but here it is
> > again. The ctbsp naming scheme is just dandy for computers and horrid for
> > people. Disks 1, 2, 3 or disk labels is being people organized. I wish
> > "slices" would go away in this day and age. I wish UW disk labels or
> > mount point names (/usr, /home, diskette1..) were used throughout the
> > system. I wish action were to occur. I wish, I wish...
>
> Yes, having grown up with mainframes, this is something that's always narked
> me about Unix systems. Why can't the discs have labels? Oh, go on.
> Please? Pretty please?
You want mainframe stuff? We got mainframe stuff. I have disk labels
on UW, I only use disk labels on UW.
Serious disk users *MUST* have ODM.
Bill Vermillion
>In article <FDu1v...@wjv.com.REMOVEME>, bi...@wjv.com.REMOVEME (Bill Vermillion) writes:
>> In article <ufaetqd...@microlite.CalvaCom.FR>,
>> John Hughes <jo...@AtlanTech.COM> wrote:
>>>bar...@caton.com.pl (Bartek Golenko) writes:
>>>> Number - partition number.
>> From above c0b0t4s0
>> c - the number of controllers. I remember Bela and I went over
>> this a LONG time ago. At that time - and it may have changed -
>> software suppored up to 15 controllers. c0 - control zero
>> b - bus number. Many SCSI cards have multiple busses. It
>> means you have an equivalent of as many singles cards as you have
>> busses. b0 - bus zero
>> t - target. The ID of the target device - in the wide world
>> it is 15.
>> s - designated the LUN - Logical Unit number - there can be 7
>> of those for any target.
> "s" is slice, not LUN (a SCSI term and most SCSI controllers use
>only one LUN). Slice is a Unix anachronism independent of disk
>drive design.
Yup - I screwed up royally with that comment. :-(
>Various Unices mix slices and PC disk partitions, and mix them very
>badly indeed. Linux also mixes them but in its own way and not for
>the better. Recall those slices disguised as disk idents which
>reside within a "extended" partition on Linux. Shades of MS work.
>SysV for PCs does pick out "disk partitions" with a "p" prefix.
Well I still haven't 'warmed up' to Linux so I'll take you word
for how they work there.
> I've said this before here and to the UW folks, but here it is
>again. The ctbsp naming scheme is just dandy for computers and
>horrid for people. Disks 1, 2, 3 or disk labels is being people
>organized. I wish "slices" would go away in this day and age. I
>wish UW disk labels or mount point names (/usr, /home, diskette1..)
>were used throughout the system. I wish action were to occur. I
>wish, I wish...
You could label things almost any way you want by linking to the
designed names. /dev/disk1 linked to system designated
nomenclature.
Your comments appear to be targeted toward PC-centric Unix systems,
but there are a great many systems out there that don't fit that
model.
The control, bus, id naming conventions make a lot of sense one the
drives start getting numerous. You can look at a drive ID jumpers
and know how the system will see it - depending on which controller
and which bus on that controller the drive is attached.
I saw a local installation with 500 4GB drives - that's 2TB of
storage - I'd hate to think of trying to know what controller,
bus, and ID number that drive 312 was attached too.
What would make things more friendly would be a front-end that
linked the system names to a user-defined name. Of course the
concept of disk1, disk2, etc., really doesn't belong in the
Unix arena as we mount file systems and not disk drives.
Think of the fun you would have with a file whose was in
a mounted tree of /disk1/disk2/disk3/application. Let the admin's
set the system and then forget about disks.
Bill
Joe Doupnik
Not to belabor the point, but may I add a few more words?
People see disk drives, even in massive RAID arrays. They can touch
and replace them. That's the fundamental item. The file system
can do its own thing about mounting file systems, hiding stuff, etc,
and that is an abstraction used in a different regime. There is no
reason at all that I must remember, or shutdown the system for
detailed physical inspection to reveal, how many and which busses a
controller uses and which drives are on which busses under what unit
ident and which "slice" of that is involved, when all I wish to do is
access a drive. That's what machines are for. Try this with backups
and see what I mean. Try "diskette1" and find its recognition by the
o/s is poor indeed. Naturally we all know to say /dev/dsk/f03ht, not
forgetting the h nor the t; it's all so obvious and intuitive, so much
so the machine is totally unable to do this job itself.
I'm not really PC-centric. People centric would fit better.
I understand the technical matters.
User created logicals don't work unless the o/s uses those
tags, and it rarely does so. Again, people first, make the system
work for the owners and users. Technical arrogance is another way
of expressing this situation.
Joe D.
Warren Young
>In article <9ElJwk7mG$3...@cc.usu.edu>, Joe Doupnik <j...@cc.usu.edu> wrote:
>>In article <FDu1v...@wjv.com.REMOVEME>, bi...@wjv.com.REMOVEME (Bill Vermillion) writes:
>>> In article <ufaetqd...@microlite.CalvaCom.FR>,
>>Various Unices mix slices and PC disk partitions, and mix them very
>>badly indeed. Linux also mixes them but in its own way and not for
>>the better. Recall those slices disguised as disk idents which
>>reside within a "extended" partition on Linux. Shades of MS work.
>>SysV for PCs does pick out "disk partitions" with a "p" prefix.
>
>Well I still haven't 'warmed up' to Linux so I'll take you word
>for how they work there.
The problem isn't Microsoft or Linux, but whoever designed the PC's
partition scheme. The fact is, a hard disk drive on a PC can only
have 4 partitions -- it probably stems from fixed-size structures in a
record at the head of the disk defined back in the Dark Ages of the
PC. Since Linux wants its partition tables to be read by other tools
like DOS fdisk (if only so that those tools don't go _totally_ ape
when they read the tables), it uses the same 4-entry tables that other
OSes use.
The "extended partition" idea is in fact sort of like slices. It just
uses a special "magic" partition type which then allows any number of
subpartitons. (Or at least a fairly large number of them.) Ideally,
we'd all just put a single extended partition on the disk and define
the "real" partitions within that. The problem is that many PC BIOSes
and SCSI cards refuse to boot into an extended partition.
UnixWare side-steps this issue by using one of those partition table
entries per disk and then does the slices thing inside. It makes the
subpartitions visible only to UnixWare, but at least it's compatible
with other OS's tools.
One difference between "slices" and partitions within a subpartition
is that a slice can be expanded. That may just be a tools issue, but
I suspect that the UnixWare filesystem has a specific structuring
strategy that makes resizing fairly easy.
>I saw a local installation with 500 4GB drives - that's 2TB of
>storage - I'd hate to think of trying to know what controller,
>bus, and ID number that drive 312 was attached too.
I'm assuming that these were in external RAID enclosures. In that
case, you could probably just label each enclosure with its
controller, bus and target number, and then each removable disk sled
is probably also labeled. From that you could construct the /devname.
Joe Doupnik
> bi...@wjv.com.REMOVEME (Bill Vermillion) wrote:
>
>>In article <9ElJwk7mG$3...@cc.usu.edu>, Joe Doupnik <j...@cc.usu.edu> wrote:
>>>In article <FDu1v...@wjv.com.REMOVEME>, bi...@wjv.com.REMOVEME (Bill Vermillion) writes:
>>>> In article <ufaetqd...@microlite.CalvaCom.FR>,
>>>Various Unices mix slices and PC disk partitions, and mix them very
>>>badly indeed. Linux also mixes them but in its own way and not for
>>>the better. Recall those slices disguised as disk idents which
>>>reside within a "extended" partition on Linux. Shades of MS work.
>>>SysV for PCs does pick out "disk partitions" with a "p" prefix.
>>
>>Well I still haven't 'warmed up' to Linux so I'll take you word
>>for how they work there.
>
> The problem isn't Microsoft or Linux, but whoever designed the PC's
> partition scheme. The fact is, a hard disk drive on a PC can only
> have 4 partitions -- it probably stems from fixed-size structures in a
> record at the head of the disk defined back in the Dark Ages of the
> PC. Since Linux wants its partition tables to be read by other tools
> like DOS fdisk (if only so that those tools don't go _totally_ ape
> when they read the tables), it uses the same 4-entry tables that other
> OSes use.
<omitting other good comments>
I would hope that SCO could deal with two situations regarding
disk drives larger than 8GB. One is allowing the entire drive to be
devoted to UW and not be bootable. That is a common enough situation
for us with plenty of data needing storage. Without a boot requirement
the partition table limitations become invisible or avoidable.
The second hope is to allow more than one UW disk partition on
a disk. This way a bootable partition can obey the rule of staying inside
the 1024 cylinder limit and yet the rest of the disk would available for UW
too.
In both cases one needs to go beyond conventional Int 13h information
to see what the disk is like. There are Bios extensions to do this, and
more importantly one may do disk IDE/ATA inquiries to discover real disk
parameters. Novell's NetWare does this so that an 18GB IDE drive is seen
as that, no problem whatsoever.
While we mull the subject, it would be nice to have a tiny boot
area, /stand say, that obeys the rules and the rest of the drive becomes
available after the kernel loads. Thus "/" could be 20GB if we so chose,
as I do when /home is there. Basically I try to avoid slices these days.
These huge partitions become available under protected mode, at
which time the Bios is unused and the driver talks to the controller
directly. Taking this one step further, the boot/install disk could also
talk straight to the controller once it knew the flavor.
Joe D.
Andrew Smallshaw
> 5. Linux is generally more user-friendly. This is of course due to a
> difference in the Linux and UW target markets. You can get KDE and
> other stuff from Skunkware or port it to UW, but the fact that it's a
> post-installation matter is significant.
>
> 6. UW tends to be more administrator-friendly, as SCO has been working
> on the "pretty administration tool" problem far longer than the Linux
> community has. (For most of the decade, if you consider sysadm, from
> the Novell days.) linuxconf and COAS are good examples of how this is
> quickly changing.
These are pretty much the same point, about different target audiences.
Linux is a fairly `techie' OS, whereas the SCO Unices tend to be regarded
as black boxes by the vast majority of their users: they don't _care_
what's going on, so long as it works and they can use it. Having said
that a lot of Linux's growth seems to be part of an anti-Microsoft
sentiment, bringing forth Windows-style bloatware, such as KDE, to the
small-is-beautiful world of UNIX. And there's no way linuxconf can be
compared with scoadmin (IMHO).
> 15. Where both OSes have the same command-line tools, the Linux
> counterparts are often more advanced than the ones on UnixWare.
> Examples: vim vs. vi, bash vs. ksh, tcsh vs. csh, less vs. more/pg,
> ncftp vs. plain ftp, gzip vs. compress, GNU awk, m4, ls, make, man,
> tar, and find vs. the SysV flavors, etc. Other good examples are
> vixie-cron and the Linux version of man: both are far more flexible
> than their UnixWare counterparts.
This is often considered a good thing, but it does mean that you very
quickly get locked in to Linux and particular bits of software because of
their non-standard features - e.g. try replacing the /bin/sh link to bash
on a Linux box with one to /bin/ash. ash is more similar to Bourne shell
than Bash, yet you'd be suprised how many things this breaks. It is
still important to avoid vendor lock-in, even when there isn't a vendor.
Of course, the GNU tools are widely ported to most Unices, should you
want them.
--
Andrew Smallshaw
smal...@cs.man.ac.uk
Tony Lawrence
> These are pretty much the same point, about different target audiences.
> Linux is a fairly `techie' OS, whereas the SCO Unices tend to be regarded
> as black boxes by the vast majority of their users: they don't _care_
> what's going on, so long as it works and they can use it. Having said
> that a lot of Linux's growth seems to be part of an anti-Microsoft
> sentiment, bringing forth Windows-style bloatware, such as KDE, to the
> small-is-beautiful world of UNIX. And there's no way linuxconf can be
> compared with scoadmin (IMHO).
Sure you can compare linuxconf to scoadmin: one is a
confused mess of often contradictory and conflicting tools
that don't always work, and the other isn't :-)
But that's one of the very few things "wrong" with Linux,
and as always it is a very fast moving target, so today's
criticism has to be tenderized and swallowed whole tomorrow.
The only thing that worries me at all about Linux is whether
the vendors can make enough money to keep producing it. I
would simply love to see it get good enough to replace
Microsoft desktops (I know that some insist that it is now,
but corporate America mostly disagrees), just because I
detest the Evil Empire for their hypocrisy, greed, and
suspicious business practices. Also, the more Unix there is,
the more money is apt to flow into my hands, and I have
grown accustomed to the joy of that flow :-)
As to SCO, it looks like they are concentrating on the big
boys. That's not my market; I can't take dealing with the
impotent middle managers of the world, but if it keeps them
healthy and happy, more power to them. If at the same time
they manage to hang on to at least some of the small
business market, that certainly won't upset me either.
--
Tony Lawrence (to...@aplawrence.com)
SCO articles, help, book reviews, tests,
job listings and more : http://www.aplawrence.com
Leroy Janda
Unlikely scenario but very possible with Y2k comming up real fast.
Say Informix or even Sendmail go down real hard Jan 1, 2000.
Where do you think their resources will be fixing any kind of bugs?
I can bet that it will not be the Linux version. Linux will be at the bottom of
the list.
Joe Doupnik
> Andrew Smallshaw wrote:
>
>> These are pretty much the same point, about different target audiences.
>> Linux is a fairly `techie' OS, whereas the SCO Unices tend to be regarded
>> as black boxes by the vast majority of their users: they don't _care_
>> what's going on, so long as it works and they can use it. Having said
>> that a lot of Linux's growth seems to be part of an anti-Microsoft
>> sentiment, bringing forth Windows-style bloatware, such as KDE, to the
>> small-is-beautiful world of UNIX. And there's no way linuxconf can be
>> compared with scoadmin (IMHO).
>
> Sure you can compare linuxconf to scoadmin: one is a
> confused mess of often contradictory and conflicting tools
> that don't always work, and the other isn't :-)
>
> But that's one of the very few things "wrong" with Linux,
> and as always it is a very fast moving target, so today's
> criticism has to be tenderized and swallowed whole tomorrow.
>
> The only thing that worries me at all about Linux is whether
> the vendors can make enough money to keep producing it. I
As astute observers know, Linux is more a social event than a
technical one. The technical matters improve with time, get worse, get
better etc, but seem to remain a mess. But the appeal is because it's
talked about and "free". The money making part runs smack into licensing
issues, and that is the topic of a huge ongoing discussion (to be polite)
in the free software groups. Open Source, FSF, and all that jazz.
I try to stay out of such social events and instead concentrate on
getting things done, with suitable available tools. Alas, the grabbing for
money based on "open source" Linux will make that process more difficult
over time as people lock up their intellectual property. Speaking personally
I would be happier if money making were more closely tied to producing
something of value rather than remarketing (unpaid) efforts of others.
I don't know of a polite expression to describe the current activity,
but good old "raid & plunder" comes close.
If one is worried about profit margins of Linux vendors then
there are much bigger fish than that in the financial marketplace. If one
is concerned about technical matters then there are attractive alternatives,
including products from our host SCO.
Joe D.
Warren Young
>
> In article <377CE8BF...@aplawrence.com>, Tony Lawrence <to...@aplawrence.com> writes:
> > Andrew Smallshaw wrote:
> >
> > The only thing that worries me at all about Linux is whether
> > the vendors can make enough money to keep producing it. I
> ----------
> As astute observers know, Linux is more a social event than a
> technical one.
[snip]
> I try to stay out of such social events and instead concentrate on
> getting things done, with suitable available tools. Alas, the grabbing for
> money based on "open source" Linux will make that process more difficult
> over time as people lock up their intellectual property. Speaking personally
> I would be happier if money making were more closely tied to producing
> something of value rather than remarketing (unpaid) efforts of others.
> I don't know of a polite expression to describe the current activity,
> but good old "raid & plunder" comes close.
This is beginning to veer off-topic, but keep in mind that most
contributors to the Linux movement don't _mind_ not being paid for their
efforts. The reason goes right to the core of the social part of Linux:
Linux is _our_ operating system.
If I write a free tool, it's because I think I can do a better job than
anyone has done before -- either in terms of technical excellence,
features or availability (e.g. free vs. payware).
Now it's all well and fine if I then install that tool on my new Linux
boxes, but how much better if a Linux distributor decides my tool is
good enough that they want it in their distro? Not only do I not mind
them including it (after all, I released it not expecting to receive a
dime from it to begin with), I'm now happy because others will use my
tool, and because I don't have to install it when I build a Linux box:
it's already there. This might sound like a rare event, but the same
applies to patches submitted to already-popular programs. I saw this
personally when the Samba team accepted my Makefile mods -- I could then
upgrade to new versions of Samba without having to patch them to work
with UnixWare.
An SCO Unix, by contrast, is SCO's: it's not Warren's OS, it's not Joe's
OS, and it's not Tony's OS. If SCO is scared by Linux, it's for this
reason alone: they can't match the Linux community's sense of ownership
of the operating system. The best they can do is tie their customers'
breadwagons to the SCO product line. That's good, but distinctly
second-fiddle to the power of the Linux movement.
--
Andrew Fry
writes
>Joe Doupnik wrote:
> (SNIP)
>If SCO is scared by Linux,...
> (SNIP)
According to a couple of friends who work for SCO (though one
has recently left for Cisco), SCO is more concerned with
Windows NT / 2000.
---
Andrew Fry
"Time flies like an arrow. Fruit flies like a banana". (Groucho Marx).