> >> NewCON:? You haven't tried KingCON then?
>
> >Probably not.  When my last Amiga was showing signs of flakieness (about 5
 [...]
> KingCON is lovely. It's got all modern features such as several kinds of tab-

I'll have to take your word for it, since it's unlikely that I'll ever use
KingCON: myself.  (Unless I purchase a ROM image and set up the UAE...)


> >> I find the blocking "feature" (it's rather a bug, really) useful, since
> >> it's easier to press space than ^S, but it's not optimal, since it becomes
> >> really easy to block a program unintentionally.
>
> >^S isn't an alternative, because then *you* can't type anything either.
 [...]
> I also came to think of another use of this bug. You can submit commands one

You mean the UNIX bug that effectively prevents you from seeing what you
type when a program is spamming you?  I.e., the bug that program output
doesn't block in ``cooked'' mode while a partial input line is being
edited?  (^&


> after another, so that if you're using LAME to encode MP3s, you can first type
> "lame blutti.aiff", and then, while LAME runs, type "rm blutti.aiff" so that

This works on both UNIX and the Amiga.  The only difference is that you
have to type ^R to Redisplay lines (if you want to check for typos) on
UNIX after being spammed.  You don't get spammed on the Amiga, so you
don't need ^R.  This is really just part of my lament about the Amiga
feature not being present in existing UNIX shells.  This brokenness of the
bash/zsh/etc. editing/history is far worse than the fact that you may need
to explicitly enable history in sh/ksh, while the csh's history is mildly
archaic.

The ultimate point is just that what you consider a show-stopper is a
triviality to me.  Different people have different opinions, so just
because you don't like X doesn't mean that X is bad or that everyone
dislikes X.


> >> I'm not into that, but I hear that awk and grep can do wonders in that
> >> regard.
>
> >grep's fine if you're just looking for something and know what it looks
> >like.  It won't help so much if you're just trying to read the sources.
> >I don't see how one would use awk in normal programming.  (Certainly, I
> >*hope* that none of the developers are routinely transforming sources to
> >and fro under off-the-cuff awk scripts!)
>
> I just came to think of a command called SED. I've used that one to fix big
> file lists.

sed is a fine program for such things (or for applying patches, as I
believe some have used it in the past).  But it isn't, any more than awk,
going to help maintain legibility simultaneously with matching the
internal and external names.  At least, I don't see how it can have any
such effect...

Maybe it would help if you would say exactly how you would use these
programs.


> >Since I haven't ever worked on (or spent much time looking at) driver
> >sources in NetBSD, I will only say that my impression is that a verbose
> >name would damage code readability.  Others who actually work on the code
> >may or may not agree, however.
>
> Verbosity, if used properly, is the same as more information, which should
> raise legibility.

``Used properly'' is a key phrase.  Of course, this is subjective, and
entirely up to those who actually work on the code.


> But I digress, the programmer can do what they want with their sources, even
> program them in REXX if they like. I don't think the final name should matter.
> After all, we can rename commands just any way we like, should drivers differ
> in this way?

As I understand it: Drivers each have a suite of similar function names.
Unlike the Amiga shared .library interface, these are actually staticly
linked in (they aren't LVO's from a library base).  The name of a device
function must be unique from one driver to another.  Moreover, if you want
the system to *work* then you don't want the developers to have to jump
through extraneous hoops, translating external names to internal names in
their heads.

I.e., the external names should match the internal names, and the internal
names are probably going to adorn a *lot* of code.

The comparison to commands (which aren't staticly linked to the kernel and
are, in fact, entirely distinct programs) doesn't seem to have a basis.


 [...]
> I still don't think that's an issue. The internals of the code probably
> don't affect something as trivial as the final name of the driver or program.

I haven't seen how the external names are generated, so I'll not comment
on possible technical requirements.

However, it certainly looks like a *feature* (for maintainability) that
the internal and external names agree.


> >> >Besides, you probably will want to find out things like ``my brand new
> >> >ethernet card that I just put in is de'' shortly after the first time that
> > [...]
> >> Not really, no, but once you re-config it, you'd have to think about
> >> whether it was el, ef or ep. As we all can see, this isn't a big issue, but

(Actually, no.  You can probably most commonly get away with just editing
/etc/ifconfig.*; if you have just one interface, you don't ever need to
know its name after the first time that you create that file.  If you are
manually issuing ifconfig commands, you can just ls /etc/ifconfig.* to see
the name; with more familiarity with your shell, you might do even
better.  Though, again, I've not had any trouble remembering my cards'
names.)


 [...]
> No, no, I'd prefer an overall change for the verbose. LE should be LANCE, TLP
> should be TULIP, and so on.
> I have no idea how to actually go about this, though.

Well, on your own personal copy, just go and use sed.  Or awk.  (Either
one should be quite adequate for what amounts to a search-and-replace
operation.)  Or a more user-friendly editor than sed, even.  As someone
said a ways back, make sure you get all of the documentation updated, too.
Then see if the kernel still builds; if it doesn't, fix whatever you
broke.

I wouldn't hold my breath waiting for the changes to be accepted back,
though.  And certainly, I'd oppose having the tlp, ne, and rtk interfaces
renamed (since I actually use those).

(I don't think that a per-driver set of aliases would be a good idea,
either, if you are thinking of aliases.  First, it would require that
every affected driver be visited and modified in some way.  Second, it
would blur the distinction---the set of very similar, yet different, names
would be a source of confusion and furstration I suspect.)


> >> >But, perhaps every ethernet card could be given a generic ``ether*''
> >> >interface name, in addition to the driver-specific name.  I don't know
                      ^^^^^^^^^^^
 [...]
> >> You mean something like Linux, which calls all Ethernet adaptors just eth*?
>
> >As aliases for the real names, yes.  That would meet your request for not
      ^^^^^^^
 [...]
> OTOH, ETH0 is a bit too general, I think. It puts us back at the point where
> you have to remember something quite arbitrary. Was the internal interface
> ETH0 or ETH2?

(Hm.  While ``ether'' seemed a natural idea at the time, it might be
better to go with something like ``net''...aliasing an arcnet interface as
an ``ether'' interface is probably a bad idea.  (^&)

Anyway, I don't think that your objection applies:

 (a) Notice I stressed (in both of the above) *aliases* to the *real*
     interface names.  If you can currently distinguish two cards based
     on their driver, you would still have that ability, should you have
     two cards in the same machine.  Nothing is lost.

 (b) The current system also suffers from the same problem, if you happen
     to have two cards using the same driver.  The problem already exists.

So, the problem (b) already exists, and (a) is not aggrivated by my
suggestion.  Most who don't want to be bothered figuring out that their
interface is an ep would presumably just have the one interface anyway,
and could get away with ``net0'' without trouble or remembering obscure
facts, such as that their card uses the Etherlink III (not Etherlink II)
chipset...


  ``I probably don't know what I'm talking about.'' --rauch@math.rice.edu