Darren New <dne### [at] sanrrcom> wrote:
> What do you *need* symlinks for?

  What do you *need* directories for? Useless. Just use a naming convention.

  What do you *need* long file names for? 8 characters are plenty for any
amount of files you might need. Useless to have anything larger.

  What do you *need* Windows shortcuts for? It's not like the system
couldn't work without them.

  If we start dropping everything that is not absolutely necessary, we could
get a pretty bare-bones system.

  On the other hand, other people find convencience features useful.

> >   You might yourself believe that, but I don't think it's true. I'm pretty
> > certain that if Windows had supported soft links from the very beginning,
> > you would today be defending them. (You would *especially* be defending
> > them if Unix/Linux didn't support them, I'm pretty sure.)

> Oh, give it a rest, Warp.

  You are not giving me much reason to.

> >>  I think soft links are an abomination, and I've 
> >> only ever seen them used to basically correct flaws in software 
> >> configurations.
> > 
> >   Linux distros use them frequently to, for example, make "aliases" of
> > libraries of different versions to an actual file which is fully compatible.

> OK. Windows puts this information in the files themselves, and the code asks 
> to load the library with the compatible version. Or it looks up the 
> registration in the registry. (Hence the name, you see.)

  And once again we have a hard-coded, specific feature which will work
*only* for dll files but nothing else which might be similar.

  Generic solutions are much more useful than hard-coded, specific ones.

> The symlink solution works OK until the upgrade from libxyz.1.2.so to 
> libxyz.1.3.so breaks the program written to use libxyz.so.

  Yeah, I see how programs are constantly breaking when libraries are
updated.

  Seemingly you missed the "if the library is backwards-compatible" part.
If it isn't, then it will not be sym-linked so that programs will believe
it's the same library, of course.

> And dont tell me it doesn't happen

  I don't remember personally ever seeing it happen in my computer.
OpenSUSE repositories are pretty competent at handling dependencies
properly.

> > In other words, if version 1.2.3 of a library is fully backwards compatible
> > back to version 1.0.0 of the library, the "versionless" library (eg.
> > "libsomething.so") file will usually be linked to the 1.2.3 version of the
> > file (eg. "libsomething.so.1.2.3"), as well as the several versioned files
> > (eg. "libsomething.so.1" would be a soft link to "libsomething.so.1.2.3" if
> > the latter is fully backwards compatible with version 1).

> Yes, I know how that works.

  Then why are you asking for examples if you know that?

> >   This is not a question of "bad configuration". 

> Inadequate configuration. The program itself should be telling you which 
> versions it's compatible with

  Most programs do. You can use the 'ldd' utility to check which .so files
they depend on, and usually they do have the version number. (Then if you
check the actual .so file itself, you'll usually see that it's a soft link
to a compatible version of the library.)

  As said, if program A depends on libSomething.so.3 and program B depends
on libSomething.so.4, and the latter happens to be fully compatible with
the former, it would be a waste of disk space to have both. Instead, the
former is simply made a symbolic link which points to the latter.

> and the loader should be enforcing that. The 
> fact that you *can* do it with the file system doesn't mean that's a *good* 
> way to do it. :-)

  Instead, you want to hard-code such specific features as .so file versions
into a loader routine.

  What happens if you are dealing with something similar, but which is not
a bunch of .so files which are loaded by a loader routine?

> >   And before you start nitpicking about how that could be solved in other
> > ways (which I'm 100% sure you will do), that was just ONE EXAMPLE of many.

> Sure. Let's hear some others. Seriously.

  Why? For any possible example I could mention you will come up with a
contrived reason why it's "better" to do it in some other way. Just for
the sake of argument.

> How would a *user* use symlinks, is really what I want to hear. Not someone 
> managing software installations, but an end-user. Why would I want a symlink 
> in my home directory, for example?

  Have you ever heard of "shortcuts" in Windows? They are like a poor-man's
symbolic link.

  Why would a user need those?

  (Yes, go on an rant about how these "shortcuts" are so much infinitely
better than symbolic links. After you have done, please explain to me why
shortcuts *are* useful to regular users while symbolic links *aren't*.
You are insinuating that symbolic links would be completely useless for
regular users. "Shortcuts" are functionally the same, and are being
constantly used in Windows. Are you arguing they are also completely
useless?)

-- 
                                                          - Warp

Post a reply to this message