Richard Rauch skrev:

>> NewCON:? You haven't tried KingCON then?

>Probably not.  When my last Amiga was showing signs of flakieness (about 5
>years ago), I hurried up to get something else.  The Amgia's future looked
>dim, so I caved in and bought a PC.  (And after the obligatory playing of
>games that came bundled, I eventually installed NetBSD so that the PC
>would be useful.  (^&)

KingCON is lovely. It's got all modern features such as several kinds of tab-
completion. I prefer the tab completion method, which if there are several
matches, pops up a file list with all matches in a window for you too choose
from. And lovely line editing. You kan jump between arguments/flags using alt-
arrows and within directories in file specifications with ctrl-arrows. The
closest thing I've found in UNIX shells is ^W, but that will delete arguments
instead of jumping between them. Is there some way to do this in ZSH or BASH?

>> 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.
>The point is, when I'm typing, I want the computer to shut up and listen,
>not spam me.  I had never heard that this was a bug in the console
>handling; but if it is, it's a very fortuitous one, and I'm glad that CBM
>recognized its positive value and replicated it from CON: to NewCON:.

I also came to think of another use of this bug. You can submit commands one
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
the file is deleted after LAME is finished.
But I still think it's basically a bug. The VincED CON-handler (delivered with
OS 3.9), can work asynchronously.

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

>> >> >Perhaps someone who knows more about the way that the system works from
>> >> >source can say how functionally necessary this is.  But certainly, it
> [...]
>> >> What the sources look like internally is of no interest to the end user.
>> >> The programmer may call all their includes and procedure foo, bar and
>> >> joe for all I'm concerned. I don't mind at all.
>>
>> >I value the fact that NetBSD works well.  If having a 2- or 3-letter name
>> >for my ethernet card helps even in a small way towards that, by making
>> >development quicker or more pleasant (or easier for pieceworkers to pick
>> >up) then it's more than justified for me.  I *do* care about this.
>>
>> I don't really think the internal names are an issue, though. Sounds really
>> odd, really, though I have only limited C experience.

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

>> I tend to value clarity, but perhaps I'd be more suited as a VMS user than
>> a UNIX user, then.

>I value clarity, too.  But there's more than just the end-user's immediate
>perspective to bear in mind.  Or, put another way, some ``end-users'' are
>developers or professional administrators, and they (to varying degrees)
>need to be able to make changes; clean code is an end-user plus for them.
>And, there's the indirect benefit that even you and I get from having code
>that's more easily maintained.

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.

>> Didn't know about that file in /var, though.

>Someone also suggested /var/run/dmesg.boot, which is even better for this.

I'll have to check whether this is in OpenBSD (It wasn't my choice to run
that, it just happens that one of my co-administrators is more security-minded
than I).

>> >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
>> I still wonder why the names can't be a bit more verbose.

>Hm.  This doesn't cause any trouble for me.  I rather have trouble
>remembering the names that were on the boxes for the cards that I have.

You had boxes for your cards? =)

> [...]
>> >If so, consider that the name on the box isn't really tied to the chipset
>> >used (hence to the driver required).
>>
>> I appreciate this in the case of the NS8390 (NE2000 and clones, as well as
>> non-clones) or the LANCE, but the EtherLink III chipset is AFAIK only used
>> on EtherLink III cards.

>So this is something that would only affect a single driver?  You're not
>after a general change to make driver names more verbose?  Well, if you
>want to go through and rename the driver (and fix up all of the sources
>and docs to match), and if the changes are accepted by the developers,
>it's no skin off my nose either way.  After all, I don't use that
>interface, so I wouldn't have to rename my /etc/ifconfig.* files, or
>relearn anything.  (^&

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.

>If you're waiting for someone else to do that work for you, though, my
>impression is that it's not going to happen.

Probably not, but it was worth a suggestion.

>> >But, perhaps every ethernet card could be given a generic ``ether*''
>> >interface name, in addition to the driver-specific name.  I don't know
>> >what sort of technical barriers would be involved, or how much resistance
>> >such an idea would receive...
>>
>> 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
>having to think about the driver name.  I'm not sure if it's a good idea
>to do such a thing, or how difficult it would be.  And, being quite
>content with names such as tlp0, I have no real interest in this.  (^&

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?

--
En ligne avec Thor 2.6a.

Wenn ich ein Junge wär / das wußte ich so gut / was so ein junger Boy / aus
lauter Liebe tut / ich würde in die Schwulenscene gehn / und sexy Boys den
Kopf verdrehn / ich hätt genug Verkehr / wenn ich ein Junge wär.
  Wenn ich ein Junge wär - Nina Hagen