Re: On links and things (LONG)
On Wed, 2 Feb 1994 Mark_Weaver@brown.edu wrote:
> 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 did realise that there were problems with lock files, but didn't know
the details, and I was saying enough already. The reason that there are
problems is because programs try to lock a file, rather than a device.
Because the device has multiple names, there is a problem managing
contention. If every program ignored that file system name space and
locked on major & minor device numbers, there wouldn't be that problem.
Anyway, that's all water under the bridge, and not for discussion here.
You've convinced me about symlinks in /dev.
> 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 haven't done the work yet, but perl could be a lot smaller if you left
out some stuff - sockets come to mind. Size isn't the big issue anyway.
A rather feeble interactive shell, called for example, /bin/sh can be
done in a few lines of perl, and you won't need sed, and maybe a few
other things. Whether you *need* bash or not on the boot floppy depends
on whether there are other shell scripts which can't be redone 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?
> 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'.
It's not so much the arithmetic that's missing as the difficulty of the
parsing. In order to do package size accounting, you need a database of
directory and size pairs, which need to be matched against the partition
mount points. For example, elm.tgz from debian 0.81:
[ This generated by:
gunzip -c comm/elm.tgz | tar xf - ; find var usr -type d -print | xargs du -s ]
If the mount points are / and /usr, then we have / 11 and /usr 632 used.
If the mount points are / and /usr/lib, then we have / (11 + 632 - 33)
and /usr 33.
That should be enough to see what I mean. The matching, logic and
arithmetic would be much easier to do in perl, especially, I think if a
dbm file was used for the data, although I haven't used dbm files myself.
Before anyone throws out the idea, think how much benefit could be
obtained from knowing how much space you have *before* doing any package
installation, when you can still easily add or subtract a few packages,
change the mount points or re-arrange the partition sizes. The package
usage information is easy to generate, and easy (I'm guessing) to convert
to a dbm file if that was useful.
I'm not suggesting that we do this overnight, but I think it is useful
and worth striving for, so that we can have the *best* installation
Charlie Brady * (W) email@example.com * (H) firstname.lastname@example.org
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
but no simpler" Einstein, A | Fax: (02) 413 6868 Pacing Systems \/