The proper solution is to standardize on some set of libraries for common functions that would guarantee that my application has what it needs (note: esoteric libraries are the exception -- I'm fine taking a dependency on something like a high-level mathematics library, because I don't expect every system to have that.
There would be an endless debate on what should be in a standard distro. You would end up with this distro thinking gtk was standard (Redhat anyone?:) ) and another that qt is the way to do (Lycoris pe) so sou actually wouldn't gain anything, except for each distro having a bigger default install.
What is needed imho is an even better handling of dependencies as we have now. If a user has to install a program now, s/he has to install an rpm which may or may not run on his system (compatibility...), or compile from source, eat through tons of errors and hunt for header files.
Maybe an extra application could do the work of resolving depedencies on the fly while compiling? I think about something like this: an app that calls./configure scripts and catches all the requests for header files from auto*/gcc/whatever; if it exists on the system, find; if it doesn't, look up which package the file belongs to (using some sort of database à la apt-file, for those who use Debian), install it, give it to the script.
Hmmm. It seems something like that allready exists: auto-apt. Looks interesting, I'll let you know how it works...
(quote)
why do we need 50 different UI widget sets? pick one, whether it be gtk or qt or something else, and make it standard. You can be assured everybody with Linux will have that widget set, and so you can confidently write against it without having to add another dependency to your project. Dependencies suck. Look at trying to compile GNOME by hand. You have to track down a metric pantload of different libraries before you can even get the core installed. Yes, package managers make that easier, but there's another problem -- we've got deb, rpm, tgz, and whatever else, and even within those things are different. An rpm for Redhat may or may not install on SuSE or Mandrake, and vice versa.
(/quote)
About "pick one": there is no point in that; I use them all concurrently without problems.
About compiling gnome by hand: What kind of a fool does it take to want to do this? Compiling should be restricted to applications (not libraries!) which aren't covered by the distributions.
About compatibility: Yes, I also don't understand why an app compiled for version x of library foo won't work with a slightly different version of library foo, even if they're compatible on source level. Look at tucows: a great deal of the apps you find there will run on anything from Windoys 95 to Me over nt4 to Xp. Why this isn't the case on Linux, I wouldn't know.
Slashdot Mirror
Ok, let's port Windows to Acrobat reader! :-)
A pentium 2? Woosh... the family runs msoffice2k on a p133 and that's just ok...
Whatever, this post actually sounds like good news to me, muhaha :-D
I think a computer for office-work wouldn't reasonably benefit from more then a boring pentium 200...
There would be an endless debate on what should be in a standard distro. You would end up with this distro thinking gtk was standard (Redhat anyone? :) ) and another that qt is the way to do (Lycoris pe) so sou actually wouldn't gain anything, except for each distro having a bigger default install.
What is needed imho is an even better handling of dependencies as we have now. If a user has to install a program now, s/he has to install an rpm which may or may not run on his system (compatibility...), or compile from source, eat through tons of errors and hunt for header files.
Maybe an extra application could do the work of resolving depedencies on the fly while compiling? I think about something like this: an app that calls ./configure scripts and catches all the requests for header files from auto*/gcc/whatever; if it exists on the system, find; if it doesn't, look up which package the file belongs to (using some sort of database à la apt-file, for those who use Debian), install it, give it to the script.
Hmmm. It seems something like that allready exists: auto-apt. Looks interesting, I'll let you know how it works...
As much as I like Debian,this thread is about desktops and 2 years uptime means you run a kernel with several security holes.
(quote) why do we need 50 different UI widget sets? pick one, whether it be gtk or qt or something else, and make it standard. You can be assured everybody with Linux will have that widget set, and so you can confidently write against it without having to add another dependency to your project. Dependencies suck. Look at trying to compile GNOME by hand. You have to track down a metric pantload of different libraries before you can even get the core installed. Yes, package managers make that easier, but there's another problem -- we've got deb, rpm, tgz, and whatever else, and even within those things are different. An rpm for Redhat may or may not install on SuSE or Mandrake, and vice versa. (/quote)
About "pick one": there is no point in that; I use them all concurrently without problems.
About compiling gnome by hand: What kind of a fool does it take to want to do this? Compiling should be restricted to applications (not libraries!) which aren't covered by the distributions.
About compatibility: Yes, I also don't understand why an app compiled for version x of library foo won't work with a slightly different version of library foo, even if they're compatible on source level. Look at tucows: a great deal of the apps you find there will run on anything from Windoys 95 to Me over nt4 to Xp. Why this isn't the case on Linux, I wouldn't know.