On Oct 3,  9:02pm, Greg A. Woods wrote:
} [ On Sat, October 3, 1998 at 15:18:14 (-0700), John Nemeth wrote: ]
} >
} >      Really?  With just a quick glance at the machine can you tell me
} > what "c2" is?  Nine times out of ten you won't be able to do that.  99
} > per cent of the time I do system administration remotely, and
} > therefore can't look at the physical hardware.  "c2t15d0" is just as
} > arbitrary as "sd47", except that it is longer and very awkward to
} > type.  Now explain to me why SysV scheme makes so much more sense.
} 
} Perhaps you're not thinking of *real* machines.  Certainly with PCs you

     I think the problem is that *you're* not thinking of *real*
machines.  You keep talking about things like the 3B2.  I agree that
the 3B2 is a neat machine.  It also has some very nice features, i.e.
soft powerdown, that is only now starting to show up in the PC world
and on things like Sun's (SGI had it a several years ago).  Heck, one
day when I'm bored, I may even dig my 3B2 out of the closet.  However,
regardless of what you or I think about the 3B2, it is a dead
architecture and comparing it to modern machines is just plain silly.
Have you looked inside modern machines?  As several people have
pointed out, many of them contain PCI slots.  I have a one year old HP
which is a current model intended to be used as a departmental server
that has EISA slots in it.  The reality is that unless you're talking
about million dollar machines, modern workstations and low-end servers
are looking more and more like PC's.

} are likely to be correct, but with all *real* machines that I've ever
} dealt with you can easily find "c2".  On most such systems you won't

     It's time to go look at what manufacturers are putting out today,
not what they put out five years ago.  Modern machines do pretty much
the same thing as PC's.  They simply scan the bus and assign
controller numbers in the order the controllers are found.  They don't
care where they are found.  Heck, current Sun entry-level workstations
have PCI slots and IDE disks (ugh!).

} even have to decode switch or jumper settings.  If I plug a second and
} third host adapter into the sbus slots on my sparcstations I'll have

     Instead of plugging in two host adaptors, plug in an ethernet
card in the lower numbered slot.  Do a 'boot -r' as recommended by
Sun, and like the majority of system administrators would do.  Now,
take out the ethernet card, put in a host adaptor, do another 'boot
-r' and tell me what happened to all your disks that were on the other
host adaptor.  I know that you're going to point out that Solaris 2.x
is a bad implementation, but the fact is that is the best selling
workstation OS (ignoring PC's running SCO UNIX).

} absolutley no trouble figuring out which is which.  All the world's not
} a PC, luckily.  I feel almost as little compassion for PC users as I do
} for users of Microsoft products.  They made their choice -- let'm burn!

     No, but most of it is, and that's reality.  I don't like the
design of PC's either.  But, we don't have the luxury of designing and
building our own hardware, so we have to work with what's out there.

} Seriously though, maybe a pure cNtNdN scheme isn't good enough for
} NetBSD.  Maybe it's better to stick to driver prefixes, but be more
} explicit about it -- i.e. don't lump all SCSI controllers into sd and
} st, and so on, but actually use espNtNlN and so on.

     This is really gross!  If I have a machine with multiple SCSI
ports on the back, why should I care what's on the other side of them?
I can usually tell what slot a board is in, but unless I open the box,
I won't know what type of controller it is.  Why should I do that?
This is even worse then the pure cNtNdN scheme.

} This little bit of "middle of the road" stuff the BSDs are currently
} trying with SCSI is what's causing the problem.  Going totally generic
} in device naming (and major number assignment), such as calling all NICs
} /dev/nicN regardless of which driver they are may not be appropriate for

     Linux uses /dev/ethN and HP-UX does /dev/lanN.  I can see some
arguments for doing it this way.  The main point against it would be
tradition, even Solaris 2.x doesn't do it this way.

} /dev/ncr0t0l0 and /dev/ahc0t0l0, etc.  Surely you can tell the
} difference between your NCR card and your Adaptec card, no?  If what

     Only if I open the box and why should I do that?

} There are many things about it that I don't like, and there are many
} things about it that I would prefer to change, but unless/until I want
} to cause another chasm in the BSD camps by creating yet another variant,
} I'm going to try and encourage NetBSD to look slightly beyond the OS R&D
} venue it currently harbours in and take some heed of the requirments of
} real-world 

     cdrom.com isn't the real world?  hotmail.com isn't the real
world?  NASA isn't the real world (or, real space as the case may be)?
Various ISP's aren't the real world?  BSD/OS isn't used in the real
world?  Convex wasn't used in the real world?  Etc.  The point is that
various versions of BSD have been used very successfully in the
"real-world" for mission critical applications for a very long time
and continue to be used.  There is nothing in BSD stopping it from
being used in the "real-world."  Your arguments about it not being
suitable for the "real-world" are totally bogus!

} > Note, that this rant isn't just aimed at you, but rather everybody
} > that is trying to turn NetBSD into SysV (*especially* Greg, who keeps
} > restarting this idiotic discussion every few months).
} 
} Now this is total bullshit.  I've not discussed rationalization of
} device naming since somewhere around, or even before, the NetBSD 1.2
} days, and the only other issue I can think of that I keep badgering
} people about is getting a *real* init with proper run level support.  If
} you want to make these kinds of false acusations you should do so in
} private.  If it were only me you might have a point, but I'm usually
} only the seconder on such suggestions these days.

     Yes, there are a handful of others, but your name is the one that
I most often see at the top of posts arguing for the adoption of
various SysV "features."

} Even if I mention in passing that I once ran a bunch of SysV machines
} people in the BSD camps will get all jumpy and introspective.  If

     Nobody gets jumpy when you say you ran or that you currently run
SysV machines.  Most of us administrate more then one platform.  Some
of us even have to work with NT (shudder).  People only get jumpy when
you try to turn NetBSD into SysV.

} instead I actually come out and claim I prefer Research Unix BSDers get
} all glassy eyed and most have no idea at all what I'm talking about.

     Sure, because very few people here have seen it.  Besides the
fact that it's not used in the "real-world" anywhere.

} How about we change the pathname separator in NetBSD so it looks more
} like Multics?  That would *really* make me feel more at home!  Or how
} about we throw out all the BSD crap and make it NetV7?

     Go for it.  You can get a source licence for V7 from SCO for
$100 US.  Have fun, V7's idea of networking was UUCP.  TCP/IP was first
introduced to UNIX in 4.2BSD.

} >      Tell me what "the 1st SCSI controller attached to this system"
} > is.  In general, you can't.  Heck, you can't even depend on the OS not
} > to re-arrange the controllers on you.  That blows your whole argument
} > out of the water.  On the HP I have, c0 is a card sitting in an EISA
} > (aka GSC) slot, and c1 is the "Built-in SCSI".  Does that make any
} > sense?  Of course not.
} 
} I've no idea what HP hardware looks like never mind how it works.
} 
} However I must ask the obvious question:  what OS are you talking about
} here?  HP-UX?  If so, what's the upgrade history of that machine?  I've

     It came with HP-UX 10.20 installed (it appears that I missed 11.0
only by a few months).  All I've done in the way of upgrading is to
add patches.

} heard that HP-UX does stupid things to try and preserve ancient mappings
} after new hardware is added.  Nobody I know has *ever* put HP-UX up on a

     I would call the preservation of mappings a good thing.  I don't
like it when things move around on their own.  In other messages you
slam Sun's 'boot -r' because it can cause mappings to change, now
you're slamming HP because they go to great lengths not to change
mappings?!?  You can't have it both ways.

} > tagged onto the end of the list.  Why should I have to remember to use
} > 'mount /dev/dsk/c1t2d0 /cdrom' (taken from an HP-UX system just now; I
} > had to use ioscan to remind myself where the cdrom drive is) as
} > opposed to simply 'mount /dev/cd0a /cdrom' in order to view a cdrom?
} 
} That begs the question:  Why didn't you just type "mount /cdrom"?????
} 
} Surely c1t2d0 is no more meaningful to a naive user than cd0a is.  The

     No, but the latter is a heck of a lot easier to type and
remember.  And, I would argue the latter is more meaningful, since it
contains the string "cd" and that's the kind of device they want;
whereas, the former is just a collection of random characters.

} proper place to encode these kinds of mappings is in a user-level
} configuration file such as /etc/fstab.  And of course then there's the

     Sure, I could have done that.  But, why should I have to do that?
What happens if I feel like mounting a particular CD at a different
location?  Now, I have to go back and look up the device name again.

} advantage of suggestions such as David Maxwell's to think about here
} too.

     I don't recall what his suggestion was off-hand.

} PLEASE forget about your partisan views and look at the merits of
} changes.  I don't make these suggestions lightly -- they're based on
} actual real-world requirements.

     My views are based on *my* actual real-world experience.

} After all, SysV didn't get the way it was totally by accident.  Quite

     Trying to think of how some of the "features" of SVR4 got
"designed" is rather scary.  There are a lot of grossly overly complex
things in there.  As well as things that just don't make any sense at
all.

} often some of its features were indeed designed to solve real-world
} problems.  Remember that BSD has never really had a history of catering
} to real-world production uses (such as running major telco central
} office switches and billing systems), whereas some commercial operating

     I wouldn't use any version of UNIX to run a CO.  This is a hard
real-time application, which requires a real-time OS.  The only CO's
with which I have direct experience is Northern Telecom DSS'es.  I
couldn't tell you what runs a 5ESS, but I doubt very much that it is
UNIX.  I also doubt that UNIX runs their billing systems; MVS is a far
more likely answer.  Until recently, there weren't very many UNIX
boxes that had the horsepower to do the job.  Do you have any
references to back up your claims?

}-- End of excerpt from Greg A. Woods