Warp wrote:
>   No. Windows doesn't support them, so user have learned to live without
> them, and then they are claiming that they "don't need them" (one of the
> most common "windows'isms").

More like "Programmers learned to live without them." I'd classify that as a 
good idea.

What do you *need* symlinks for?  I've never found a good use except getting 
around paths that are hard-coded that shouldn't be, or distributing files 
from one directory onto multiple file systems due to not all file systems 
having the same capabilities.

>   If Windows had supported soft links from day one, they would probably be
> in pretty common use, and it would be unthinkable to drop them.

Possibly.  That wouldn't necessarily be a good thing.

>>  Software is written to not hard-code paths that don't need to be 
>> hard-coded.
> 
>   Yeah, because that's the *only* thing soft links are used for.

Well, tell me what else you *need* them for that a configuration variable 
wouldn't work just as well.

>   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.

>>  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.)

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. And dont tell me 
it doesn't happen, as I have not infrequently binary-edited libraries to 
change the strings there.

> 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.

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

Inadequate configuration. The program itself should be telling you which 
versions it's compatible with, 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. :-)

> It's a question of
> practicality (an executable may have been linked against version 1.0.0 of
> the library, but it will work ok with the version 1.2.3, so the soft link
> will make it load that) and saving disk space (especially if the library is
> several megabytes in size).

This works less well when you have a bunch of programs that you don't have 
the source for which may or may not break when you change library versions. 
Hence, "DLL Hell".  That's much less common when you can just test every 
piece of software written for the platform when you change a library.

>   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.

>   (Another cool example is when a software package consists of several
> executables, each one doing slightly different things... But instead of
> having a 5-megabyte file for each executable, they are all in fact soft
> links to one single 6-megabyte executable which then acts different depending
> in which name was used to start it. Again, this saves disk space.)

Yep. This is what the whole busybox thing is about. Given that, the common 
functionality ought be in a shared library. Otherwise, you're taking up more 
memory than disk space.

Or in the Windows way, you have one tiny file that launches the library with 
different arguments, so you don't have to depend on the file name not 
changing in order to make it work. You know, like, a shortcut or something. :-)

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?

-- 
Darren New, San Diego CA, USA (PST)
   Linux: Now bringing the quality and usability of
   open source desktop apps to your personal electronics.

Post a reply to this message