On things
Charlie Brady <charlieb@tplrd.tpl.oz.au> writes:
>> Now, considering only modems and mice. There are standard names for
>> all of many serial devices under Linux, including those known as
>> COM1, COM2, COM3 and COM4 under MS-DOS. Debian has /dev entries for
>> all of them. I could make an argument that Debian should only have
>> entries /dev/mouse and /dev/modem, for a machine with two serial
>> ports, each made by an appropriate mknod. No confusion, no links, no
>> duplicate names, no wasted files space. Now I'm not saying that's
>> what we should do, just saying that it's a reasonable thing to
>> consider.
>> Accepting that we will keep all the traditional /dev entries, then I
>> think that we should use links in /dev for modem and mouse. That way
>> configuration files can be distributed for all packages which use the
>> modem or mouse which will not need to be changed on installation, nor if
>> the devices are re-organised.
I think that Ian McCloghrie hit the nail on the head with his posting
about links in /dev. However, I would like to comment on this portion
of his posting:
> "/dev/mouse" is only likely to be used with either X386 or
> selection. In the case of X386, there's no way to automate the
> generation of an Xconfig, so forcing people to figure out which
> serial port they've got their mouse on and type "Mouse = /dev/ttyS2"
> is not a hardship. As for selection... *shrug*. The package
> install script prompts for the serial port once, enters it into the
> rc file, and everybody's happy.
Well, it is *possible* to generate an Xconfig or to at least change
entries in it. A little 'sed' never hurt anyone...
It would be a good thing if 'rdev' (or something similar) could be
used to change the mouse device used for selection in the kernel
(where I think it is stored as /dev/mouse).
Daniel Quinlan wrote:
>> This also reminds me of the entirely shameful Perl rewrite.
Charlie Brady writes:
> What was "the entirely shameful Perl rewrite"? Is anything done
> voluntarily really shameful, even if it isn't as good as one might
> hope? Actually, I'd like to see the installation script written in
> perl - some things which are difficult or slow now would be very
> easy in perl. I think that we should be accounting file space
> used/free/available for every package selected/deselected, which
> would be difficult in shell, but not too hard in perl. But since
> you and Ian have made your minds up, there's no point in discussing
> that, eh?
It is shameful because Ian was criticized for use of a Bourne shell
script, the issue was debated, and Ian believed that the people who
told him that Perl was the way to go would do more than volunteer.
Volunteering is easy if you never do the work.
IMHO, the installation procedure should be done with curses in C.
(for those who enjoy the use of the term) "commerial quality"
operating systems do it in C.
> On Mon, 31 Jan 1994, Greg Hudson wrote:
> .. some words in my defence. Thanks. You've read my position pretty
> accurately.
This isn't a war. It isn't about defense and offense. It is about
debating and trying to reach a common position or (at least) a
compromise.
> Ian - you are doing a terrific job, but you *are* trying to do too
> much. The volunteers, myself included, are finding it a bit hard to
> contribute. IMO, part of the reason that Ian is doing such a high
> proportion of the work is that he is not very accessible to the
> network. Wouldn't it be a better idea for another site and person
> more accessible to the network (and hence contributions) host the
> collection and collation of packages, with Ian working on the
> installation script and organisation?
I believe that very few people, if anyone, have the strength of vision
that Ian Murdock has shown us. The right thing to do is to be a
little more practical about things that just pushing the load on to
another single person.
Debian has now settled on a format for packages, package maintenance,
and even a filesystem structure to put them in.
The obvious goal that Ian should have is getting "Debian package
coordinators" to handle the complete packaging of their package. For
instance, I submitted Emacs to Ian in tar.gz format. He added the
packaging stuff, converted it to cpio.gz, and when I submit a fix for
something, it is he who puts it in. This has to stop.
I wrote:
>> [...] How suggestions, complaints, and "concerns", are evaluated and
>> implemented is up to Ian Murdock, 100%.
> Well, OK, if Ian has special status, rather than him being just one
> of the contributors, then let that be clear. But I had hoped that my
> opinion would count equally to his, my contribution would be as
> welcome as his.
I disagree. I trust Ian's judgement here more than I trust "the mass
will" of the Debian mailing list.
Back when people were worrying about the speed of the shell script and
how "nice" it looked, Ian perfected on the best Linux packaging system
I've ever seen. The Perl rewrite faded away, but Ian is still here.
He was ready to force himself to learn Perl and rewrite every last
line of Bourne shell script.
When everyone has control you end up with lots of neat features (if
they ever get done), not clarity of direction. Someone has to be at
the helm of the ship or the wheel will get ripped right off. That
person is, and should continue to be, Ian Murdock.
Dan
--
Daniel Quinlan <quinlan@spectrum.cs.bucknell.edu>
Reply to: