On links and things (LONG)
On Mon, 31 Jan 1994, Daniel Quinlan wrote:
> Charlie Brady <charlieb@tplrd.tpl.oz.au> writes:
>
> > Or with real links :-) Symlinks are just a poor substitue for when
> > you can't use a real link, IMO.
>
> Real link? There are two kinds of links, symbolic links and hard
> links. I have seen symbolic links referred to as "soft" before, but
> not "fake".
>
> I also disagree. Your aren't speaking from reason here.
> o symbolic links can remain in place when the file is changed,
> removed copied, etc.
> o hard links can not go across filesystems.
> o hard links are faster.
> o only symbolic links can be on whole directories.
> o hard links can not be made to non-existing files.
>
> Clearly, symlinks are called at some times while hard links are called
> for at other times.
On Mon, 31 Jan 1994, Daniel Quinlan wrote:
> Paul Kilroy <kilroy@ms.uky.edu> writes:
>
> >>> also, (this is just pickiness), the install said something about not
> >>> making symlinks to /dev/modem and /dev/mouse, but selection was
> >>> compiled to use these, kinda wierd, might cause problems for
> >>> novices...
>
> Daniel Quinlan wrote:
>
> >> Symlinks are *generally* a bad idea in /dev.
..
> >> Another option is to use a hard link if mknod scares you and you get
> >> something which requires /dev/mouse or /dev/modem.
>
> Charlie Brady <charlieb@tplrd.tpl.oz.au> writes:
>
> > I don't understand why links are a problem, and why one form of link
> > might be better than another. Why is mknod a better way of having an
> > alternate name for the device which the mouse is attached to than a
> > so-called hard link (a real link for us old timers, as opposed to these
> > new-fangled and often broken symbolic link), and a hard link better than
> > a sym link?
>
> Well, it was you who just said "Symlinks are just a poor substitue for
> when you can't use a real link, IMO."
>
> A hard link is exactly the same thing as mknod, here.
>
> > They are just different names for the device. I like the idea that I
> > only have to think about which device the mouse is connected 1) when
> > I install and 2) when I change them. When I change them, I like the
> > idea that I only have to change one link in the /dev directory
> > rather than any number of scripts and configuration files.
>
> Anyone remember the numerous and reoccuring problems with device
> symlinks in the SLS distribution? Symbolic links are not something
> that belongs in /dev by default or that should be introduced to new
> UNIX users -- with responsible use, they are not a problem. Sure,
> symlinking /dev/mouse to the wrong /dev/cua? is no big deal. What
> about /dev/swap to /dev/hda2 when hda2 is your /usr partition?
>
Please, please, please, let us not have a flame war. I'd like us to
have a civilised discussion about whether we should configure modems
and mice by the use of links or not. IMO, it is a reasonable thing to
consider - there are arguments for and against it. Daniel hasn't
responded to my points in favour of using links. I know there are
arguments against as well. Why don't we debate them and see what the
consensus is?
I don't think it is appropriate for an installation script to
pontificate about the appropriatness or not of links, symbolic or
otherwise, in /dev. I also don't think it is reasonable for Daniel
to be dogmatic *on behalf of Debian* about whether symbolic links
belong in /dev or not.
Now, about links - did anyone see the smiley? My experience of Unix goes
back to Version 7, which had only one type of link.
"The same non-directory file may appear in several directories under
possibly different names. This feature is called linking; a directory
entryfor a file is sometimes called a link. The UNIX system differs from
other systems in which linking is permitted in that all links to a file
have equal status. That is, a file does not exist within a particular
directory; the directory entry for a file consists merely of its name and
a pointer to the information actually describing the file. Thus a file
exists independently of any directory entry, although in practice a file
is made to disappear along with the last link to it."
The UNIX Time-Sharing System. D.M.Ritchie & K.Thompson. Communications of
the ACM, July, 1974 - the paper which introduced UNIX to the world.
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.
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.
On Mon, 31 Jan 1994, Daniel Quinlan wrote:
>
> lam836@cs.cuhk.hk wrote:
>
> >> I've written a little program called 'dialog'
..
> >> I just think it may help to give a new look to the installation
> >> scripts, with minimal change to it, I hope.
>
> Charlie Brady <charlieb@tplrd.tpl.oz.au> writes:
>
> > I second this. Scripts which use "dialog" look great, and a lot of
> > the complexity of looping, parsing and error checking is taken out
> > of the script.
>
> 'dialog' should not be introduced at this point when the install
> script is so stable. I am not also entirely certain that 'dialog'
> will work for all monitor types (monochrome, namely).
>
> This also reminds me of the entirely shameful Perl rewrite.
>
> > A lot of discussion went on a while ago about a good looking
> > installation - I think that dialog will make that possible.
>
> "Good looking" is just that -- looks. You install once. The majority
> of Ian's install is also based on 'dpkg' and I don't want some cutesy
> interface being used for it.
>
> I really don't think it is wise to make major changes like this at
> this point.
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 don't
understand your assertion that the install script is stable. I haven't
yet installed 0.90 or 0.91, but I understand that major changes have been
made to the script, and there hasn't been much time for user feedback.
What is your BETA test group for?
My opinion, expressed before, is that a good looking, reliable and
easy-to-use installation procedure is important for the success of Linux.
It's worth working at. If it is ever going to be done, sooner is better
than later. If you look into it, you might find that changing the
installation script to use dialog is not such a major change. Is the
decision not to use it final?
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?
On Mon, 31 Jan 1994, Greg Hudson wrote:
.. some words in my defence. Thanks. You've read my position pretty
accurately.
On Mon, 31 Jan 1994, Jeffrey Wescott wrote:
> If the development model is not "living up to the claim in the
> manifesto", it is CERTAINLY not the fault of Ian, but rather, the
> fault of all of US who cannot seem to volunteer for developing.
>
On Mon, 31 Jan 1994, Joseph Boyle wrote:
> How about a HOWTO telling how to put a package together?
> I'd certainly consider packaging some software I'm familiar with
> if I knew how to do it, and I'm sure many other people feel the same.
>
On Mon, 31 Jan 1994, Ian A Murdock wrote:
> Debian Linux. Until I'm done with it, you may contribute packages in
> any format and I will take care of putting them in Debian pkg format
> for the distribution.
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?
Ian A Murdock wrotes:
> From imurdock@shell.portal.com Tue Feb 1 12:56:10 1994
> Date: Fri, 28 Jan 1994 10:00:09 -0800 (PST)
> From: Ian A Murdock <imurdock@shell.portal.com>
> To: debian-linux@netcom.com
> Subject: Repacking of 0.90
>
> Ian A Murdock writes:
> >
> > Does everyone agree with Jos? Should I repackage the system with
> > relative paths or is it not a big deal? When I packaged the system in
> > the first place I didn't think it would be, but I've been wrong a few
> > times before...
> >
>
> Nevermind. I'm going to repackage it with relative paths. I've seen
> enough good reasons to do that already, and there's no sense in wasting
> any more time talking about it.
On Mon, 31 Jan 1994, Daniel Quinlan wrote:
>
> Charlie Brady <charlieb@tplrd.tpl.oz.au> writes:
>
> > Yes, you should repackage them. I unpack things and compare them or
> > look at them very, very often.
>
> We already established this quite some time ago.
What for you is a long time ago is first thing after the weekend
for others.. :-) :-) [see the time stamps]
>
> 3. Find someone who has done more work than Ian Murdock for Debian.
> Ian should get the last and first say.
>
..
> everyone's concerns. 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.
Again, for the record - I offered a package of Pine, which Ian Kluft
accepted. Communication with Ian is a bit slow. By the time I had a set
of patches to send Ian, Debian 0.90 was "about to appear". Since I couldn't
find out what would be different in Debian 0.90 I didn't know what to do
then. I was never told that there would be a change in package format. Ian
has never confirmed that he has the original Pine source and asked me for
my patches. I'm not prepared to send him the full source or a binary package
at 2400 baud unsolicited.
> > it. It's still a surpise what will appear in 0.90.
>
> Ahhh, but that's because you don't have the secret decoder ring. ;-)
Now *that's* flame bait.
Charlie Brady * (W) charlieb@tplrd.tpl.oz.au * (H) charlieb@budge.apana.org.au
"Make it as simple as possible - | Tel: (02) 413 6838 ____Telectronics__| /\__
but no simpler" Einstein, A | Fax: (02) 413 6868 Pacing Systems \/
Reply to: