Subject: Re: Another changer, another changer problem
To: John Nemeth <jnemeth@cue.bc.ca>
From: David Maxwell <david@fundy.ca>
List: current-users
Date: 10/10/1998 14:05:01
On Sat, Oct 10, 1998 at 12:48:03AM -0700, John Nemeth wrote:
> On Oct 3,  9:02pm, Greg A. Woods wrote:
> } 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
>...
> 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.

I think the problem here is that Greg feels the PC architechture is
a slowly developing version of what was once a home computer. Although 
we may have to deal with i386 hardware, that doesn't mean that we 
should not look at what i386 hardware is missing, and try to provide some
of the functionality that isn't there in the hardware (yet).

> 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!).

Cost engineering at its worst. :-(

> } 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.

Today. That may very well change, with the rise and fall of various chip
makers. Good design is good design, if i386 can't accomodate it completely,
that doesn't mean all of NetBSD should suffer, even if i386 is the most
popular/widely used port. I think many people here believe in the portable
design model, or they'd have started running some other single platform OS.

> } 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!

I think you're misinterpreting Greg's statement. He's not saying BSD
(Free/Net/Open, and Linux) isn't _being_ used in the real world, he's
saying that there are some limitations that would cause people to
hesitate to use it in certain types of applications. As an example,
I'm sure integration of RAIDframe would help win a lot of machine-room
space for NetBSD servers.

> } > 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
> 
>      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."

There are different interpretations of the word 'adoption'. Adoption as
in replace the current method, or as in add as an alternative to the 
current method. I think Greg proposes the latter.

> } 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.

As I've said in earlier messages, nobody is trying to turn NetBSD into
(non-NetBSD thing that people don't like for the same reason they like
NetBSD), they're trying to discuss useful approaches to problems, and
different points of view.

> } 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.

I'm not sure what you mean here. Once you have more than a couple of
systems to admin you'll likely look at 'df' or /etc/fstab to find the
devices again anyway, unless you have the luxury of identical hardware
on every system.

> } advantage of suggestions such as David Maxwell's to think about here
> } too.
> 
>      I don't recall what his suggestion was off-hand.

Applying a label to a disk (or partition) and teaching mount to
do something like 'mount -l wwwmaindisk_a' (or :a, as you suggested in
a later message.) I'm not sure if you were thinking of this before I
brought it up or after, your message wasn't a reply to mine.

btw, I'd still appreciate from anyone a good pointer to an example of the
kvm_open stuff. Basically, I want to read the kernel linked list 'disklist'

> } 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.

Compare the ATM and IP standards sometime...

> } 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?

Well, box horsepower is a tricky thing to discuss, since it really
depends on how the procudure is designed. Just take a look at the
distributed encryption cracking going on... There may not be a box
'powerful' enough to do the job... but the job still gets done.

Nortel's recent switches (I believe 'Thor' was the project name) are
Unix based. No, I don't know which flavour.

I think Greg had some inside info on AT&T (Lucent, whatever...) it
wouldn't surprise me if they used Unix in their switches... they
developed it after all.

-- 
David Maxwell, david@vex.net|david@maxwell.net --> Mastery of UNIX, like
mastery of language, offers real freedom. The price of freedom is always dear,
but there's no substitute. Personally, I'd rather pay for my freedom than live
in a bitmapped, pop-up-happy dungeon like NT. - Thomas Scoville