Because it doesn't work with non-root installs. We'll have to append lots of paths to LD_LIBRARY_PATH for that. I *think* that ld.so can handle 200 entries in ld.so.conf but 200 entries in PATH is just inefficient.
And of course there's always the relocateability issue. Let's take GTK+ for example. My libpango-1.0.so is installed in/opt/gnome22/lib. It loads modules from/opt/gnome22/lib/pango/1.2.0/modules dynamically. Let's say I move Pango and all of it's other files to a new prefix,/opt/pango. How is Pango supposed to know that the modules are in/opt/pango/lib/pango/1.2.0/modules? There's no way to find out libpango-1.0.so's location automatically.
"and there would be a tool that would manage symlinks into/usr/bin and stuff"
Which kind of defeats the point of installing each app to it's own folder? I thought the primairy reason why people would want that is is reduce clutter in/usr/bin or something. Symlinking like this only adds more to the clutter.
"If a package would have it's own dir, all you need to deinstall the package is to delete this dir. Move the package?, just copy the dir."
If only things are that simple.
What about: - Library search location - PATH - GNOME/KDE file associations -.desktop files - Sysvinit scripts - Some more stuff I can't think of right now
But why do you even want each package in it's own folder? You launch an application using icons and menus, and that is all a user should have to know! Letting them know/decide where an app is installed to is exposing implementation details to them. They shouldn't have to know about implementation details. They should only have to know what it will work and that's it!
How does it do dependancy handling? Or are you going to tell me that each and very app bundles their dependancies with them, wasting harddisk space, memory, and most importantly: bandwidth?
I'm one of the developers of the Autopackage project, and we have bumbed into the relocateability problem since Autopackage allows user (non-root installs).
In Linux (dunno about other Unices), there is one way to tell where the application's binary is: by dereferencing the symlink/proc/self/exe. However, this only works for applications, not for libraries. We still haven't found a solution for libraries, so for now we are using a "semi-hack" solution called libprefixdb. Using a shell script is another solution (since shell scripts can find out their own location), but too only works for applications.
Personally I don't understand what's the big deal about AppFolders. How do you want to handle dependancies? I don't think that shipping all dependancies in the app folder is a good and efficient solution. That'll make us no better than Windows apps which also ship all their dependancies. And second, why should the user even care about where an app is installed? They launch the app using icons and menus, and that's the only thing they should have to know! Letting them know where the app is installed to is exposing implementation details. Users shouldn't have to know about that (unless they're programmers or something). 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.
Have you forgotten GNOME? In GNOME 2, they removed a lot of configuration options and deprecated APIs! They even got heavily flamed and critisized *because* they removed stuff.
Oh yes, let's claim that people almost never remove old stuff while ignoring one of the largest open source projects out there.
Render is for transparency *inside* a window. Transparency *between* windows is much more difficult. I don't know the status on the translucent windows extension.
Ah, so you're volunteering to port the entire GNOME library and all applications to QT? Great! Get started! I'll be waiting to see your excellent results. I'll come back after 10 years and see how you're doing.
May I remind you that GTK+ and GNOME are *open source* projects? Anyone is free to do whatever he wants. There are already tons and tons of people working on fixing bugs in GNOME. Why are you so upset just because one single person jumps out and and does what he wants (making menu shadows)?
What the hell are you smoking? Just look at all the comments! Zillions of posts about how we should not emulate Winodws XP or posts about that Linux doesn't innovate! And back when a Slashdot article was posted about XFree86 getting XRandR, there were tons of posts about how XFree86 === Windows 95 and how Windows already had it for years etc. etc.
And now, somebody like you suddenly jumps in, claims the opposite, and immediately gets modded up to Insightful just because you're not anti-MS. *sigh* Slashdot is not an anti-MS site anymore! How else do you explain that people like you always get modded up, even though you claim that Slashdot is an anti-MS site?
If you've done nothing wrong, you've nothing to fe
on
Twist on DNA Privacy
·
· Score: 1
"If you've done nothing wrong, you've nothing to fear?"
So why don't you let them install a camera in your bathroom? After all, if you've done nothing wrong, you've got nothing to fear.
And this is exactly the problem. Everybody has different aesthetic preferences! Personally I like BlueCurve. There's no way people can agree on one single theme that everybody likes.
Apply unified theme A to GNOME and KDE -> some people say it's ugly. Apply unified theme B -> other people say it's ugly. Apply unified theme C -> yet other people say it's ugly. Etc. etc.
Unix determines the current time by calculating the numbers of seconds that have passed since january 1, 1970. It's stored in a 32-bit integer, also typed time_t. I think function use time_t internally to convert it to tm structures. So if time_t overflows, the tm structures won't be correct either.
DivX is not a "new video" or whatever. In fact, DivX is not even open source!
- MPEG is an open *standard* (not source! since it's not an implementation but a specification).
- There are several versions of DivX: the "original" DivX;-) 3.11 (with the smiley), DivX 4 and DivX 5 (without the smiley). DivX 3.11 is as illegal as it can be: it's a hacked MSMPEG4v3 codec. DivX 4 and 5 are legal rewrites, but are commercial and closed source. There's also OpenDivX, which has been dead for more than a year now. Basically Project Mayo stole all the code from OpenDivX and turned it into their closed source DivX 3/4 codec, and then killed off OpenDivX. Dispite it's name, OpenDivX is NOT open source! (read the license)
- XviD, DivX 4 and DivX 5 are implementations of the MPEG4 standard. Only XviD is open source (GPL), DivX 4 and 5 are not.
- Ogg Theora is something completely different. I don't know whether the quality has improved, but according to a codec comparison at Doom9.org (a site about video encoding), VP3 is one of the worst codecs (codecs compared: DivX 4, DivX 3.11 SBC, XviD, WMV, VP3, RealVideo).
Slashdot Mirror
If you can even *imagine* something groundbreaking and useful then I'll give you a cookie.
It's possible in RedHat, and it's very easy. This is how you do it in RedHat 7.2:
Application->System Tools->New login
And viola, you're presented with a new login screen but your old X session is still active.
That isn't my point. HOW is a library supposed to know where it's data files are if it doesn't even know where it's own .so file is?
What about multiple versions of the same app/library?
Ok but what about data files needed by the application or library? Read my other post for more details about this.
"Why doesnt it work out as ldconfig?"
/opt/gnome22/lib. /opt/gnome22/lib/pango/1.2.0/modules dynamically. /opt/pango. How is Pango supposed to know that the modules are in /opt/pango/lib/pango/1.2.0/modules? There's no way to find out libpango-1.0.so's location automatically.
/usr/bin and stuff"
/usr/bin or something. Symlinking like this only adds more to the clutter.
Because it doesn't work with non-root installs. We'll have to append lots of paths to LD_LIBRARY_PATH for that.
I *think* that ld.so can handle 200 entries in ld.so.conf but 200 entries in PATH is just inefficient.
And of course there's always the relocateability issue. Let's take GTK+ for example. My libpango-1.0.so is installed in
It loads modules from
Let's say I move Pango and all of it's other files to a new prefix,
"and there would be a tool that would manage symlinks into
Which kind of defeats the point of installing each app to it's own folder? I thought the primairy reason why people would want that is is reduce clutter in
"If a package would have it's own dir, all you need to deinstall the package is to delete this dir. Move the package?, just copy the dir."
.desktop files
If only things are that simple.
What about:
- Library search location
- PATH
- GNOME/KDE file associations
-
- Sysvinit scripts
- Some more stuff I can't think of right now
But why do you even want each package in it's own folder? You launch an application using icons and menus, and that is all a user should have to know! Letting them know/decide where an app is installed to is exposing implementation details to them. They shouldn't have to know about implementation details. They should only have to know what it will work and that's it!
How does it do dependancy handling? Or are you going to tell me that each and very app bundles their dependancies with them, wasting harddisk space, memory, and most importantly: bandwidth?
I'm one of the developers of the Autopackage project, and we have bumbed into the relocateability problem since Autopackage allows user (non-root installs).
/proc/self/exe. However, this only works for applications, not for libraries. We still haven't found a solution for libraries, so for now we are using a "semi-hack" solution called libprefixdb.
/etc/ld.so.conf! I don't think that's a good thing.
In Linux (dunno about other Unices), there is one way to tell where the application's binary is: by dereferencing the symlink
Using a shell script is another solution (since shell scripts can find out their own location), but too only works for applications.
Personally I don't understand what's the big deal about AppFolders. How do you want to handle dependancies? I don't think that shipping all dependancies in the app folder is a good and efficient solution. That'll make us no better than Windows apps which also ship all their dependancies.
And second, why should the user even care about where an app is installed? They launch the app using icons and menus, and that's the only thing they should have to know! Letting them know where the app is installed to is exposing implementation details. Users shouldn't have to know about that (unless they're programmers or something).
And installing each app in it's own folder would require 200+ entires in your PATH variable and
And how many closed source companies make big profits again? Only the big ones do. The small ones are having problems surviving.
Have you forgotten GNOME? In GNOME 2, they removed a lot of configuration options and deprecated APIs! They even got heavily flamed and critisized *because* they removed stuff.
Oh yes, let's claim that people almost never remove old stuff while ignoring one of the largest open source projects out there.
Yes, I completely agree. All the anti-anti-MS people get modded up even when they claim they will get modded down.
Render is for transparency *inside* a window. Transparency *between* windows is much more difficult. I don't know the status on the translucent windows extension.
Ah, so you're volunteering to port the entire GNOME library and all applications to QT? Great! Get started! I'll be waiting to see your excellent results. I'll come back after 10 years and see how you're doing.
Who modded this up as Insightful?
May I remind you that GTK+ and GNOME are *open source* projects? Anyone is free to do whatever he wants.
There are already tons and tons of people working on fixing bugs in GNOME. Why are you so upset just because one single person jumps out and and does what he wants (making menu shadows)?
What the hell are you smoking? Just look at all the comments! Zillions of posts about how we should not emulate Winodws XP or posts about that Linux doesn't innovate!
And back when a Slashdot article was posted about XFree86 getting XRandR, there were tons of posts about how XFree86 === Windows 95 and how Windows already had it for years etc. etc.
And now, somebody like you suddenly jumps in, claims the opposite, and immediately gets modded up to Insightful just because you're not anti-MS. *sigh*
Slashdot is not an anti-MS site anymore! How else do you explain that people like you always get modded up, even though you claim that Slashdot is an anti-MS site?
"If you've done nothing wrong, you've nothing to fear?"
So why don't you let them install a camera in your bathroom? After all, if you've done nothing wrong, you've got nothing to fear.
"but Bluecurve was ugly."
And this is exactly the problem. Everybody has different aesthetic preferences! Personally I like BlueCurve. There's no way people can agree on one single theme that everybody likes.
Apply unified theme A to GNOME and KDE -> some people say it's ugly.
Apply unified theme B -> other people say it's ugly.
Apply unified theme C -> yet other people say it's ugly.
Etc. etc.
Unix determines the current time by calculating the numbers of seconds that have passed since january 1, 1970. It's stored in a 32-bit integer, also typed time_t.
I think function use time_t internally to convert it to tm structures. So if time_t overflows, the tm structures won't be correct either.
No, because it's so damn obvious that you anonymous cowards are lying.
"What is it good for?"
It's good for shut up the people who yell "OMG stop copying and start innovating dammit!!!" all the time.
Maybe, just maybe, because the poster has already gone offtopic and is talking about microkernels vs monolithic instead of QNX vs Linux?
Did you ever think that maybe -- just maybe -- that Linux has got absolutely nothing to do with this?
DivX is not a "new video" or whatever. In fact, DivX is not even open source!
;-) 3.11 (with the smiley), DivX 4 and DivX 5 (without the smiley). DivX 3.11 is as illegal as it can be: it's a hacked MSMPEG4v3 codec. DivX 4 and 5 are legal rewrites, but are commercial and closed source.
- MPEG is an open *standard* (not source! since it's not an implementation but a specification).
- There are several versions of DivX: the "original" DivX
There's also OpenDivX, which has been dead for more than a year now. Basically Project Mayo stole all the code from OpenDivX and turned it into their closed source DivX 3/4 codec, and then killed off OpenDivX. Dispite it's name, OpenDivX is NOT open source! (read the license)
- XviD, DivX 4 and DivX 5 are implementations of the MPEG4 standard. Only XviD is open source (GPL), DivX 4 and 5 are not.
- Ogg Theora is something completely different. I don't know whether the quality has improved, but according to a codec comparison at Doom9.org (a site about video encoding), VP3 is one of the worst codecs (codecs compared: DivX 4, DivX 3.11 SBC, XviD, WMV, VP3, RealVideo).