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

Sure. Like, UNIX v7 or something. :-)

I'm not saying they can't be handy.  I just don't find them particularly 
useful myself, and I don't think they solve probems.

>> Oh, give it a rest, Warp.
>   You are not giving me much reason to.

I haven't turned anything into personal attacks.

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

Or use the registry. :-)  And yes, I think that's sometimes a good idea, 
because it gives you a place to leverage when you have to change something. 
If all your configuration control is based on symlinks and then you want 
something more powerful, it's very difficult to backpatch everything after 
the fact.

For example, if you base your configuration on ini files, you're pretty 
screwed if you need something more complicated, or if you want to go into a 
multi-user system where individual users don't have permissions to change 
global ini files.  If you base your configuration on an API to read and 
write ini files, then you can reimplement that API to store the ini files in 
the registry or in a per-user directory. Unless, of course, you have a 
program that bypasses the API and tries to write ini files directly into 
c:\program files, which causes all kinds of trouble and hackage to fix.

Basically, you're saying "if you don't encapsulate stuff, you can use it 
more easily for completely unrelated applications."  I find encapsulation is 
more future-proof.

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

Sure, symlinks can be used for other things too.

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

Were you, by chance, using UNIX variants before Linux had package 
management? Because, ya know, I was, and it sucked.

>   Seemingly you missed the "if the library is backwards-compatible" part.

That works great until the new library (say) fixes a bug the old library 
had, and programs that worked around the bug now break, and programs that 
expect it fixed break if you don't.

"Backwards compatible" isn't a binary choice.

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

Sure. If everything comes from the repository, you're golden.  I'm talking 
about stuff not from the repository.

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

I hadn't remembered that one.  Plus, I was really looking for an example 
where *users* would care about symlinks, rather than system administrators.

You gripe that explorer doesn't let you make symlinks. That seemed an odd 
gripe if the reason you want them is to manipulate shared library versioning 
schemes. It sounded more like a gripe about not being able to have your 
music library organized the way you want on your desktop.

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

Yep. You don't really need a *sym* link for that, tho.

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

Give me an example?

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

No, because I'm actually interested. Every time someone says "symlinks 
rulez" I ask for examples. Virtually nobody gives me decent examples of why 
someone would prefer them over hard links, except in very specific 
circumstances having to do with crossing file systems.

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

No, they're interpreted by the shell. They're more like aliases in bash.

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

Shortcuts are useful because they provide more than just a symlink. They 
provide a place to store settings for an executable program, they eliminate 
a "path" variable that's 90K long (given that there's no central authority 
regulating what you name your program, and you wind up clobbering things if 
you put everything into "/bin").

Given that, people have made shortcuts on their desktop to point to network 
shares and such, so I see the point, yes.  If Windows had symlinks before 
shortcuts, Windows probably wouldn't have shortcuts and would probably store 
the auxiliary information in a different part of the symlink file or something.

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