"if Google were to release the source for Honeycomb, Google would be unable to prevent it from being installed on mobile phones and 'creating a really bad user experience.'"
So what? If it creates a really bad user experience, then users won't use it. Let users decide. Survival of the fittest. Allowing it would allow experimentation. This does nothing but prevent innovation. Sad.
How do you handle it now? Suppose two versions of the same app. If the executable name is the same, one of them must be given preference in the path, or you execute it directly. Say,/usr/bin/kate or/usr/local/bin/kate. In our case, during the link contruction by this app we are talking about, if the tool is pointed to/usr to construct the links, a conflict would appear, and it would have to be solved. It would give a warning and choose the first one, or would give an error and expect the user to do something. Maybe a central file would contain those resolutions. I havent thought of the best way for that, but it isnt complicated. If we are talking about libraries, well, I think the concept discussed above can be extended. I mean, in my idea, you would have to manage conflicts, that only happen if you have multiple versions of the same library. Say ldconfig descends/whatever/lib/ and is putting links in/apps/lib and finds two versions of lib libsomething.so.4.1, It would generate a warning and depending of configuration, abort and wait for the user to solve the conflict, or just choose the first one or whatever. Well, if this happens, you most likely are a developer, and must know how to solve the conflict. Normal users dont have two versions of the same library. But why would you put the same library twice under the same path that ldconfig would descend to? If could just put the library somewhere else, say/opt/cvs/lib/{whatever} and make ldconfig descend it and put links in/opt/lib and in ld.conf.so you would put the/opt/lib higher than/apps/lib. Come to think about it, it would be exacly the same with binaries. Any comments?
>Which kind of defeats the point of installing each app >to it's own folder?
Well the way I see it, it wouldn't be clutter. It would be lots of links automaticaly managed by some tool. When you remove some program, by deleting its directory, you would run the tool again to remove the leftover links, just as you manage libraries with ldconfig. To make this work we would have to let ldconfig handle scan directories recursively. Then you would point LD_LIBRARY_RECURSIVE_PATH to this directory. For example, imagine that all programs are installed under/opt This tool would recursively look for executables and place links, in say,/apps/bin. ldconfig would descend recursivelly to/opt and place its links in/apps/lib. of course then you would have to add ignore path options to ld.so.conf. for relocatibility, isn't it possible to know the path of the executable? ex:/apps/lib/libpango-1.0.so.0 would point/opt/gnome22/lib/pango/libpango-1.0.so, so the lib or app could know that its real path is/opt/gnome22/lib/pango and use it.
This would allow a program to find its resources too. Like configurations and images.
I guess my idea fails somewhere, I just dont see where...
>And installing each app in it's own folder >would require 200+ entires in your PATH >variable and/etc/ld.so.conf! I don't think >that's a good thing.
Why doesnt it work out as ldconfig? Each program would be installed into a seperate folder, and there would be a tool that would manage symlinks into/usr/bin and stuff. that way you dont get the 200+ entries in your PATH and ld.so.conf.
Slashdot Mirror
"if Google were to release the source for Honeycomb, Google would be unable to prevent it from being installed on mobile phones and 'creating a really bad user experience.'"
So what? If it creates a really bad user experience, then users won't use it. Let users decide. Survival of the fittest.
Allowing it would allow experimentation. This does nothing but prevent innovation. Sad.
Someone tell these guys about the "Uncanny valley" theory.
http://en.wikipedia.org/wiki/Uncanny_valley
I viewed it, I hereby turn myself in. Here's my IP: 127.0.0.1
I've got the patent covering the process of posting on Slashdot.
2nd post?
How do you handle it now? /usr/bin/kate or /usr/local/bin/kate. /usr to construct the links, a conflict would appear, and it would have to be solved. It would give a warning and choose the first one, or would give an error and expect the user to do something. Maybe a central file would contain those resolutions. I havent thought of the best way for that, but it isnt complicated. /whatever/lib/ and is putting links in /apps/lib and finds two versions of lib libsomething.so.4.1, It would generate a warning and depending of configuration, abort and wait for the user to solve the conflict, or just choose the first one or whatever. /opt/cvs/lib/{whatever} and make ldconfig descend it and put links in /opt/lib /opt/lib higher than /apps/lib.
Suppose two versions of the same app.
If the executable name is the same, one of them must be given preference in the path, or you execute it directly. Say,
In our case, during the link contruction by this app we are talking about, if the tool is pointed to
If we are talking about libraries, well, I think the concept discussed above can be extended.
I mean, in my idea, you would have to manage conflicts, that only happen if you have multiple versions of the same library.
Say ldconfig descends
Well, if this happens, you most likely are a developer, and must know how to solve the conflict. Normal users dont have two versions of the same library.
But why would you put the same library twice under the same path that ldconfig would descend to? If could just put the library somewhere else, say
and in ld.conf.so you would put the
Come to think about it, it would be exacly the same with binaries.
Any comments?
>Which kind of defeats the point of installing each app >to it's own folder?
/opt /apps/bin. /opt and place its links in /apps/lib. /apps/lib/libpango-1.0.so.0 would point /opt/gnome22/lib/pango/libpango-1.0.so, so the lib or app could know that its real path is /opt/gnome22/lib/pango and use it.
Well the way I see it, it wouldn't be clutter. It would be lots of links automaticaly managed by some tool. When you remove some program, by deleting its directory, you would run the tool again to remove the leftover links, just as you manage libraries with ldconfig.
To make this work we would have to let ldconfig handle scan directories recursively. Then you would point LD_LIBRARY_RECURSIVE_PATH to this directory. For example, imagine that all programs are installed under
This tool would recursively look for executables and place links, in say,
ldconfig would descend recursivelly to
of course then you would have to add ignore path options to ld.so.conf.
for relocatibility, isn't it possible to know the path of the executable? ex:
This would allow a program to find its resources too. Like configurations and images.
I guess my idea fails somewhere, I just dont see where...
Cheers
>And installing each app in it's own folder >would require 200+ entires in your PATH >variable and /etc/ld.so.conf! I don't think >that's a good thing.
/usr/bin and stuff. that way you dont get the 200+ entries in your PATH and ld.so.conf.
Why doesnt it work out as ldconfig?
Each program would be installed into a seperate folder, and there would be a tool that would manage symlinks into
Is there any linux client that does icqphone, or similar in the other protocols? I hate going to windows everytime to speak to my friends.