Gerard Beekmans gerard at
Wed Mar 14 07:03:42 PST 2001

this should go to lfs-discuss but let's keep it here, will only concuse 
people by having htem jump in the middle of our subthread.

> I'd not say all sym- or all-hardlinks. If you link from /bin to /usr/bin
> e.g. a softlink is necessary, because /usr can be on a different
> partition.

of course

> Using hardlinks for links inside the same dir is okay.
> Other distro's do it that way too.

that's why LFS is here. Never liked other distro's much ;)

but seriously, the argument because other distro's do it does not work with 
me. I generally don't care what others do, I Just want to do what makes 

> > Actually they are already.
> uh - yes... hardlinked ;-) in /usr/bin?


So far i've seen two argument why using hardlinks may be better:
1) performance wise
2) saves space

IMHO (but i'm not pushing my views into the book so if the majority wants 
hardlinks I'd most likely just go with it for the sake of the book) number 1 
doesn't mean much. You wouldn't notice it unless under extreme conditions. 
Number 2 doesn't have much bearing either. One little inode, I have never 
seen a situation where you are counting out your inodes because you don't 
have enough. If that is your case, I rather clean out /dev first to free up  
a few hundred inodes.

Why I would use symlinks instead of hardlinks:
I find them easier to manage. A simple ls -l tells you what it points to and 
if you have colours enabled with ls you can see what file is a symlink. I'm 
thinking i create a hardlink and 5 months later I wouldn't know I did so. A 
comprehensive ls -i would be needed to try and find that other inode 
somewhere on the partition in order to find that file it's linked to.

Personally the 'easier to manage' outweighs the hardlink pro's. But that's 
just me of course. I'm not particularly known for doing things that most 
other people do, so I'll see what the majority on lfs-discuss thinks about it.

Gerard Beekmans

-*- If Linux doesn't have the solution, you have the wrong problem -*-

More information about the lfs-book mailing list