udev reorders assignment [was Re: Solved Debian update - keyboard responsive, Lennart Sorrenson not so much]

[Russell Reiter]

On Wed, Nov 2, 2011 at 10:52 PM, D. Hugh Redelmeier <hugh-pmF8o41NoarQT0dZR+AlfA at public.gmane.org> wrote:
> | From: Russell Reiter <rreiter91-Re5JQEeQqe8AvxtiuMwx3w at public.gmane.org>
>
> | <snip previous>
>
> I strongly advocate selective snipping, but I do recommend including
> attribution so that the reader can tell whose voice they are reading.

Thanks, I forgot that. Sometimes I think I've forgotten too much
appropriate stuff and remember too much inappropriate stuff.

>
>
> | > In the case of ethernet interfaces (not in /dev, thanks to BSD brain
> | > damage 30 years ago), you can discriminate by way of MAC address, but
> | > I don't think that that is satisfactory since a card's MAC addresses
> | > can be changed.  I've not yet bumped hard into this problem so I
> |
> | Could you elaborate a little more on BSD brain damage. Also, I assumed
> | MAC address's were stored on prom's not eproms and so were permanently
> | assigned by the manufacturer.
>
> I guess I should have said Berkeley CSRG brain damage -- those were
> the people that designed the socket interface, for BSD (Berkeley
> Software Distribution).
>
> The sensible way of addressing devices, including networking
> interfaces, would have been through inodes named in /dev.  See how
> Plan 9 does it -- eg. /net/ether0.  Why invent a new name resolution
> mechanism?  And a whole new API to deal with things using those names.
>
> The socket stuff is a lot of warts on the side of UNIX.  Very useful
> warts, I admit.


Not trying to sound trite here. But the way I see it is, if someone
spend's a great deal of time learning how to create a programming
interface, that's what they want to do, start creating applications
via that interface. If your only tool is a hammer, pretty soon
everything starts to look like a nail.

In terms of capacity planning, keeping an architecture, soft or hard,
small and closed enough for current capacity while still preserving
future development forking, seems to me to be almost political and
hardly scientific. In fact it is the dynamic relationships between the
various people on the committee's planning for development, which
charts that course of development. There are a number of people on
this list who discuss those political aspects of Linux in a great deal
of depth.

For me I'm grateful that IBM chose not to completely close off it's
complex architecture while those manufacturing using reduced
architecture sets did close theirs, by way of fee simple. You have to
pay to play.

>
> Old time UNIX purists don't like BSD and many of the extensions it
> added.  They don't have the elegance of 7th Edition UNIX or Plan 9.
> But they did add functionality that is very important.  BSD was the
> first UNIX with support for paging, for example.  (I've been using
> UNIX heavily since 1975, so when I say old time, I mean it in that
> scale.)

I didn't even know there was a Unix until well after 1992. That was
when I bought the assembly language rom cart for the TRS-80 my
girlfriends dad had bought for her. I tried to teach myself 6808
assembly language. Boy did that make my head hurt. I never did do what
I was intending to do. Now, these years later, I know I was trying to
write an API.

>
> All of this is only of historic interest now.  BSD won a long long
> time ago.  It is good enough.  I read Plan 9's marketplace failure as
> demonstrating that doing things right isn't enough of a win for folks
> to change.

I like history it helps to plan for the future.

How did Minix fit into things? Was it a precursor for Plan 9? Isn't
that what Linus Torvalds was working from when he started writing the
drivers for intel chipsets?

I understand that Minix was developed, maybe not entirely but at least
in part here in Toronto at UofT.

Thanks I appreciate your comments.
--
The Toronto Linux Users Group.      Meetings: http://gtalug.org/
TLUG requests: Linux topics, No HTML, wrap text below 80 columns
How to UNSUBSCRIBE: http://gtalug.org/wiki/Mailing_lists