Re: On links and things (LONG)
> The original implementation of links did not allow links to directories,
> nor links across file systems, nor could a link exist before the
> information that it pointed to existed. Symbolic links were added to
> overcome some or all of these restrictions. I don't know when or why
> these two types of links became called "soft" and "hard" links. From what
> I can see, symbolic links are now more commonly used, even when they are
> to ordinary files within the same directory. As Daniel has pointed out,
> so-called "hard" links are faster. They also often take less file space.
> They also *never* point into the never-never. I consider them real links
> :-) :-) :-). OK?
>
> 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.
Many people used links (hard and soft) in NetBSD for devices as well.
If a link was used for a device which getty was servicing, there were
some problems. The "tty" program would use the major/minor device
numbers to try to find the name of the original device file, and it
was undefined which link it would come up with. In practice, it was
probably dependent on the order of the files in the directory
(unsorted), but isn't easily controllable.
In particular, sometimes the TERM variable would be set incorrectly
because it was looking that device name up in the /etc/ttys file,
which only contains one of the link names.
The solution was to:
1. Only use symlinks in /dev
2. Make 'tty' always give the name of a non-symlink
3. Use the non-symlink names in /etc/ttys
..and there were no more problems...
I am against the use of hard links in /dev simply because there is no
way to tell the original from the link.
I do, however, agree with the use of symlinks in /dev. If you decide
to move your modem from one port to another, it makes things easier.
> Daniel, *your* opinion is that you don't want some cutesy interface. I
> think that it should be considered, and that the list should have a say.
> My advocacy for dialog was not just for its attractive appearance, but
> because it allows easier and more reliable script development. [...]
I would also favor making some changes to dpkg. First, I think there
should be a way to process the installations from within the
menu-driven part. It will be a whole lot easier that way. I like the
fact that you _can_ use dpkg from a script, however.
Second, I think that dpkg, by default, should pause (prompt for a key)
after certain package installations, so they can tell you things like
"Use the netconfig command to configure your network" or something
like that.
I like moving the configuration of packages to separate commands,
since it means you can reconfigure it later, although the option to
also configure it during the install should be considered.
> 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. [...]
Perl is great, and I use it all the time, but it may not fit on the
boot floppy. I really like the fact that the base installation fits
on only three disks.
> [...] 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?
Search for "Arithmetic Expansion" in the bash(1) man page. Besides,
it is easy using a few simple filters to get the info out of 'df'.
Mark
--------------------------------------------------------------------
Email: Mark_Weaver@brown.edu | Brown University
PGP Key: finger mhw@cs.brown.edu | Dept of Computer Science
Reply to: