You can do that by modifying the rpath yes, though obviously that solution only works for the zero-install case. Once you start mixing several libraries together in the same image with different (possibly conflicting) rpaths things can get quite confused but it does work.
It also doesn't let you choose between newer/older versions, but I doubt that's often a problem.
The trick then for you is to get zero install bundled by default, have you considered sending it upstream to lkml?
Your solution, developers packaging for every distribution, is not going to work unless this is made ridiculously easy. I don't think this is ever going to happen.
Well, I disagree. I'm working on making it easy. So far it's not doing badly, though for more robust installs we want to be able to delegate to apt/yum/urpmi/whatever when there are no distro-neutral packages available.
I am the Debian zealot I am because many people complain that something does not work in "Linux", even though it does on Debian.
There are plenty of things that work in Fedora/Mandrake/SuSE that don't work (out of the box) in Debian, so I don't really see your point. Every distro has strong points and weak points.
Well, you're the linker expert, but can't something like your relaytool do that automatically?
relaytool is a useful program to have in our kit, but it's not meant for relaying large numbers of large libraries as is typical with most programs. The relay blocks it generates bloats the working set considerably: while for <100 functions this isn't really a problem once you go beyond that it begins to make an impact.
I think it's possible to use even more advanced linker tricks than relaytool to fix that problem, by allowing MacOS X style library "swallowing" where the swallowed library is sucked into the executable binary itself and used only if the system library is not present, otherwise the highest version takes priority. But, this is still theoretical and would need more R&D which I don't have time to do currently.
I'm also concerned that by going down that route people would end up swallowing loads of libraries which would hugely bloat download times - without a standardised platform to guarantee large chunks of functionality you would end up shipping most of the OS in your binaries.
Using local libraries is a small efficiency gain when running on legacy systems; it's not the end of the world if it doesn't work.
I have to disagree. Duplicating libraries like that instantly doubles memory pressure on a desktop system - our performance due to swap load is already pathetic enough. It doesn't scale as a solution. It might work in an all zero-install distribution but such a system would not bear much resemblence to the Linux systems of today.
Presumably, the application added the association when it was run. If it can do it at install time, it can do it at run time.
That works, though it requires wrapper scripts or patches to all the apps. So does autopackage however, so I guess it's an academic point:)
Sure, like I said it's possible to use cute hacks in certain circumstances. Now make that automatic for the 40-50 ELF libraries typical modern desktop apps use.
For file associations, I'm talking about "run random 3rd party app, save a file, click the file". How does the desktop know to link that file type to the program just run? Maybe ROX knows, how about KDE and GNOME which are based on the idea of files in magic path locations to describe this?
I'll keep repeating this until posts about RPM being good/not doing dependencies/both no longer get modded up.
Yes, people keep repeating this nonsense in every Slashdot discussion about packages and dependency resolution in Linux.
I'll take this slowly. There is a problem, a serious problem, that affects many people. It's that software which is not in the distros repositories is too hard to install.
The solution is not "just use Debian because that has everything". Firstly, not all software is in Debian, and some never will be - proprietary software that does not have Debian packages and cannot be repackaged, for instance. Secondly, not everybody wants to use Debian.
Some people like the graphical installers, branded graphics, fast release cycles and tightly integrated desktops that distros like Fedora, Mandrake and SuSE provide. Even if Debian provided all these things are more, there would still be non-Debian distros that people wanted to use. Debian has had years in which to wipe out the competition with its superiority, it has not happened and probably will not.
Even if Debian was the only Linux distribution anybody used, it would still not be a "solution".
Both in unstable and - yes! even in experimental - distro packages are frequently out of date or wrong. The Wine and Mono packages have this problem for instance. For Wine Gentoo is a particularly bad offender. It routinely causes a support nightmare.
They are out of date or wrong because the traditional Debian orthodoxy that centralised packaging works best is also wrong. Think about that for a moment.
I'm sure you're dying to tell me why I'm wrong, why Debian/Gentoo packagers with a guru-like understanding of Debian/Gentoo policy will always do a better job than a hapless developer, and why having all the packages in a central place allows for better "integration".
I'm not going to name names, but I have seen far, far too many flat out broken packages that are excellently integrated with their distribution but are nonetheless wrong. In some cases, they would not even start. I'm thinking primarily of Wine here because that's what I know. Wine is not exactly difficult to install, especially not in the latest versions yet somehow people still get it horribly wrong. I know from talking to other developers though that once you bring up this taboo topic, all kinds of horror stories come out of the woodwork. Brokenness on Debian, on Gentoo, on Mandrake, on Fedora... the list goes on and on.
Mistakes include not shipping critical files, shipping them in separate "optional" packages when they aren't optional at all, shipping the right files but putting them in the wrong places so the app can't find them, incorrect modifications to system settings based on flawed understanding on the behalf of the packager, oh and the worst - applying random patches which either aren't sent upstream or are so hacky and/or incorrect that they're rejected but still applied downstream.
All these problems cause support nightmares for the developers who at the end of the day actually know how to install their software. Projects don't outsource documentation writing, or usability, or optimization, why should installation be any different?
The Debian approach has many other problems. It doesn't scale. Keeping all the packages up to date requires horrific amounts of manpower and these distros still have problems doing releases. The problem affects every distro: a few days ago I installed Gimp into Fedora and found that it was a 1.3.x prerelease package! Gimp 2 has been out for ages now, and it's still out of date. Desktop Debian basically does not release, you have to use unstable to get a modern system and risk occasionally being locked out of your own system (eg, pam problems) and the like, and Gentoo has given up on that entirely and simply marks a snapshot 4 times a year as their "release".
The problem with zero install is that it's not backwards compatible enough. There's no easy way for a zero install app to use the Python on your system but fall back to a zero-install build on the net if that's not present. It can be done but it's really non-trivial. Oh, not to mention that it doesn't fit in with the FDO standards being created for things like menus (not *everyone* wants to use their file manager for that), file associations and so on.
When will people figure out that the answer to "Linux software installation is too hard" is not "Just use Debian". There are so many things wrong with that non-solution that it amazes me people still bring it up.
Wouldn't it be easier to simply not use Internet Explorer on whatever you have currently?
Re:This is only worrying
on
Hacking Quartz
·
· Score: 2, Informative
One, the problem in Windows is mostly that MS's hidden APIs are for (1) very important and basic things and (2) used extensively by MS's in-house apps.
Not really. I work on Wine and most of the undocumented APIs I can think of are very boring, in fact they're mostly utility APIs implemented by various teams (especially IE and the shell). Certainly Microsoft tends to err on the side of exposing potentially dodgy APIs rather than keeping them quiet.
While there are large chunks of undocumented APIs for instance in NTDLL these really are simply internal functions that happen to cross DLL boundaries. They aren't designed to be used from apps. In the case of NTDLL they are simply the internal implementations of the kernel DLL (amongst other things).
Every OS has these, even Linux. It's just a normal part of OS development.
Currently a full database dump total size 14,828MB (501MB for just current revisions). If you thought that's 14.48 gigabytes, you're absolutely correct! At a v.90 modem connection, it will take you only 500 years! (Actually it would take 29 days if you got the full 50,000 bps, but that's usually not the case).
So, the full encylopedia would currently fit on a CD, but only the most current versions of each page. Bear in mind that's just the database dump though. If you wanted to pre-render it to HTML you'd probably need a lot more space, so it'd be simpler to just ship MySQL and a decent local web server on the CD.
I'm pretty sure that's not how IP multicast works. You need to join a group for multicast to work and that involves back propogation through the routers to figure out the most efficient distribution graph. It's not just a case of "wait a few moments and fire", nice though that would be.
The right way to solve the problems sites like these have is to have robust distributed replication software, so ISPs can start replicating the Wiki databases. They can then offer this as a value-added service to customers: "ultra-fast access to the wikipedia", a good, wholesome feature for family-friendly ISPs. It also saves them money as they aren't paying for the bulk of the (read only) outgoing traffic.
The BBC has similar arrangements with some ISPs, AFAIR.
More like, how to get FC2 to the state this particular individual prefers it. Certainly some of the stuff in there is little more than personal taste and is definitely not a reflection on Fedora or Gnome.
I quite like spatial mode, for instance. I actually use graphical file managers now. Before with non-spatial Nautilus and Konqueror, I thought they were cute but never actually used them. The command line was far faster.
They give back enough to look good but nothing of much value. KHTML has nearly no market penetration on Linux, perhaps 5%-10% at max. Darwin is used by nobody, etc etc.
Depends very much on the individual situation. In this case the guy whos work was duplicated had not finished his version, and he was still around so there was no need to discuss replacing it without his consent.
Of course they're grateful, a lot of work has been done on it but you'll see in that email that they already encountered the problems I described - duplicated work, primarily. It took months to merge in the initial KHTML patch drop, in fact I'm not 100% sure it's even all in now. Do you think they'd have preferred open development or not?
Oh, okay, well, by MY reckoning, none of the OS X vulnerabilities were "highly" or "extremely" critical, therefore by MY reckoning, OS X is the most secure of them all!
How can you not find arbitrary remote code execution from a web browser highly critical? It meant that if a bad guy hacked a website popular with Mac users, they could take control of many machines potentially without their users noticing - just like the problems Windows has.
Unfortunately that makes it nearly impossible to support by 3rd parties, whether that is for proprietary vendors or simply non-debian using open source developers...
That doesn't stop them building a Linux version of QuickTime, of course, it doesn't have to be open source. They won't do however because Linux is one of their top competitors and they are in the business of selling proprietary operating systems at the end of the day.
Not really. The case of KHTML is a pretty good example of Apples less than great relationship with open source. When they wanted their own web browser, they also wanted to ship a rendering engine with the OS a la Windows. They had three choices:
1) Use Gecko
2) Use KHTML and bring it up to speed
3) Write their own
4) License one
3 was entirely out of the question - the investment and time it takes to build a modern web rendering engine is enormous and they don't have the resources nor desire to do that. 4 would have been difficult - the only other rendering engines on the market would have been from Opera or OmniWeb. Both these companies make their living by selling unit copies of their browsers so the idea of having them bundled with the OS and potentially reused in competitors browsers to compete against them can't have been pretty.
So they had to use a pre-existing open source rendering engine. They went for KHTML, for various well documented reasons, and started work on bringing up to scratch. But did they work with the KDE community to do that? No. Of course not. Steve Jobs wanted to go "tada!" and surprise his followers. So instead they released an enormous patch dump once Safari was out.
I can tell you from working with similar patch dumps from TransGaming that this is very nearly as bad as not getting the changes back at all. They are ridiculously hard to make use of - not only are all the changes mixed together, but often they contain duplicated work. How do you pick between the component written as a labour of love by a volunteer, or the corporate version dumped on your lap by an organization merely following the letter of the law? What if the corporate version is better? What kind of message does that send? How do you split the patch up into discrete commits so you can track regressions when each part depends on the others?
To be frank, if Apple were truly working with the open source community in the KHTML case, they'd have entered the spirit of "no secrets" and released their work as it was done, with discussion on the mailing list. They did not. I've been there - it's not much fun.
You probably just need to tell Wine to report that it's Windows 98 or maybe 2K if the game requires that. The latest version of Wine (may not be released yet, don't recall) reports 98 by default.
But the same is true of Windows. Patches Microsoft has released to Windows have broken applications before, and new versions of Office they released are not always runnable on older versions of Windows.
I don't really see your point. Your asking for guarantees you don't even get with regular Windows.
Slashdot Mirror
It also doesn't let you choose between newer/older versions, but I doubt that's often a problem.
The trick then for you is to get zero install bundled by default, have you considered sending it upstream to lkml?
Well, I disagree. I'm working on making it easy. So far it's not doing badly, though for more robust installs we want to be able to delegate to apt/yum/urpmi/whatever when there are no distro-neutral packages available.
I am the Debian zealot I am because many people complain that something does not work in "Linux", even though it does on Debian.
There are plenty of things that work in Fedora/Mandrake/SuSE that don't work (out of the box) in Debian, so I don't really see your point. Every distro has strong points and weak points.
relaytool is a useful program to have in our kit, but it's not meant for relaying large numbers of large libraries as is typical with most programs. The relay blocks it generates bloats the working set considerably: while for <100 functions this isn't really a problem once you go beyond that it begins to make an impact.
I think it's possible to use even more advanced linker tricks than relaytool to fix that problem, by allowing MacOS X style library "swallowing" where the swallowed library is sucked into the executable binary itself and used only if the system library is not present, otherwise the highest version takes priority. But, this is still theoretical and would need more R&D which I don't have time to do currently.
I'm also concerned that by going down that route people would end up swallowing loads of libraries which would hugely bloat download times - without a standardised platform to guarantee large chunks of functionality you would end up shipping most of the OS in your binaries.
Using local libraries is a small efficiency gain when running on legacy systems; it's not the end of the world if it doesn't work.
I have to disagree. Duplicating libraries like that instantly doubles memory pressure on a desktop system - our performance due to swap load is already pathetic enough. It doesn't scale as a solution. It might work in an all zero-install distribution but such a system would not bear much resemblence to the Linux systems of today.
Presumably, the application added the association when it was run. If it can do it at install time, it can do it at run time.
That works, though it requires wrapper scripts or patches to all the apps. So does autopackage however, so I guess it's an academic point :)
For file associations, I'm talking about "run random 3rd party app, save a file, click the file". How does the desktop know to link that file type to the program just run? Maybe ROX knows, how about KDE and GNOME which are based on the idea of files in magic path locations to describe this?
Yes, people keep repeating this nonsense in every Slashdot discussion about packages and dependency resolution in Linux.
I'll take this slowly. There is a problem, a serious problem, that affects many people. It's that software which is not in the distros repositories is too hard to install.
The solution is not "just use Debian because that has everything". Firstly, not all software is in Debian, and some never will be - proprietary software that does not have Debian packages and cannot be repackaged, for instance. Secondly, not everybody wants to use Debian.
Some people like the graphical installers, branded graphics, fast release cycles and tightly integrated desktops that distros like Fedora, Mandrake and SuSE provide. Even if Debian provided all these things are more, there would still be non-Debian distros that people wanted to use. Debian has had years in which to wipe out the competition with its superiority, it has not happened and probably will not.
Even if Debian was the only Linux distribution anybody used, it would still not be a "solution".
Both in unstable and - yes! even in experimental - distro packages are frequently out of date or wrong. The Wine and Mono packages have this problem for instance. For Wine Gentoo is a particularly bad offender. It routinely causes a support nightmare.
They are out of date or wrong because the traditional Debian orthodoxy that centralised packaging works best is also wrong. Think about that for a moment.
I'm sure you're dying to tell me why I'm wrong, why Debian/Gentoo packagers with a guru-like understanding of Debian/Gentoo policy will always do a better job than a hapless developer, and why having all the packages in a central place allows for better "integration".
I'm not going to name names, but I have seen far, far too many flat out broken packages that are excellently integrated with their distribution but are nonetheless wrong. In some cases, they would not even start. I'm thinking primarily of Wine here because that's what I know. Wine is not exactly difficult to install, especially not in the latest versions yet somehow people still get it horribly wrong. I know from talking to other developers though that once you bring up this taboo topic, all kinds of horror stories come out of the woodwork. Brokenness on Debian, on Gentoo, on Mandrake, on Fedora ... the list goes on and on.
Mistakes include not shipping critical files, shipping them in separate "optional" packages when they aren't optional at all, shipping the right files but putting them in the wrong places so the app can't find them, incorrect modifications to system settings based on flawed understanding on the behalf of the packager, oh and the worst - applying random patches which either aren't sent upstream or are so hacky and/or incorrect that they're rejected but still applied downstream.
All these problems cause support nightmares for the developers who at the end of the day actually know how to install their software. Projects don't outsource documentation writing, or usability, or optimization, why should installation be any different?
The Debian approach has many other problems. It doesn't scale. Keeping all the packages up to date requires horrific amounts of manpower and these distros still have problems doing releases. The problem affects every distro: a few days ago I installed Gimp into Fedora and found that it was a 1.3.x prerelease package! Gimp 2 has been out for ages now, and it's still out of date. Desktop Debian basically does not release, you have to use unstable to get a modern system and risk occasionally being locked out of your own system (eg, pam problems) and the like, and Gentoo has given up on that entirely and simply marks a snapshot 4 times a year as their "release".
The right solution to this problem - for eve
The problem with zero install is that it's not backwards compatible enough. There's no easy way for a zero install app to use the Python on your system but fall back to a zero-install build on the net if that's not present. It can be done but it's really non-trivial. Oh, not to mention that it doesn't fit in with the FDO standards being created for things like menus (not *everyone* wants to use their file manager for that), file associations and so on.
Why not simply compile the RPM once and have everybody use it? Linux binary portability is good enough for that, you know.
When will people figure out that the answer to "Linux software installation is too hard" is not "Just use Debian". There are so many things wrong with that non-solution that it amazes me people still bring it up.
Wouldn't it be easier to simply not use Internet Explorer on whatever you have currently?
Not really. I work on Wine and most of the undocumented APIs I can think of are very boring, in fact they're mostly utility APIs implemented by various teams (especially IE and the shell). Certainly Microsoft tends to err on the side of exposing potentially dodgy APIs rather than keeping them quiet.
While there are large chunks of undocumented APIs for instance in NTDLL these really are simply internal functions that happen to cross DLL boundaries. They aren't designed to be used from apps. In the case of NTDLL they are simply the internal implementations of the kernel DLL (amongst other things).
Every OS has these, even Linux. It's just a normal part of OS development.
So, the full encylopedia would currently fit on a CD, but only the most current versions of each page. Bear in mind that's just the database dump though. If you wanted to pre-render it to HTML you'd probably need a lot more space, so it'd be simpler to just ship MySQL and a decent local web server on the CD.
The right way to solve the problems sites like these have is to have robust distributed replication software, so ISPs can start replicating the Wiki databases. They can then offer this as a value-added service to customers: "ultra-fast access to the wikipedia", a good, wholesome feature for family-friendly ISPs. It also saves them money as they aren't paying for the bulk of the (read only) outgoing traffic.
The BBC has similar arrangements with some ISPs, AFAIR.
I quite like spatial mode, for instance. I actually use graphical file managers now. Before with non-spatial Nautilus and Konqueror, I thought they were cute but never actually used them. The command line was far faster.
You don't need root to do the things most malware/trojan programs do. This is doubly the case for non-secured windowing systems like Quartz.
They give back enough to look good but nothing of much value. KHTML has nearly no market penetration on Linux, perhaps 5%-10% at max. Darwin is used by nobody, etc etc.
Depends very much on the individual situation. In this case the guy whos work was duplicated had not finished his version, and he was still around so there was no need to discuss replacing it without his consent.
Do you have any evidence for that, it sounds like a rather bizarre deal to me if so.
Of course they're grateful, a lot of work has been done on it but you'll see in that email that they already encountered the problems I described - duplicated work, primarily. It took months to merge in the initial KHTML patch drop, in fact I'm not 100% sure it's even all in now. Do you think they'd have preferred open development or not?
How can you not find arbitrary remote code execution from a web browser highly critical? It meant that if a bad guy hacked a website popular with Mac users, they could take control of many machines potentially without their users noticing - just like the problems Windows has.
Unfortunately that makes it nearly impossible to support by 3rd parties, whether that is for proprietary vendors or simply non-debian using open source developers ...
That doesn't stop them building a Linux version of QuickTime, of course, it doesn't have to be open source. They won't do however because Linux is one of their top competitors and they are in the business of selling proprietary operating systems at the end of the day.
1) Use Gecko
2) Use KHTML and bring it up to speed
3) Write their own
4) License one
3 was entirely out of the question - the investment and time it takes to build a modern web rendering engine is enormous and they don't have the resources nor desire to do that. 4 would have been difficult - the only other rendering engines on the market would have been from Opera or OmniWeb. Both these companies make their living by selling unit copies of their browsers so the idea of having them bundled with the OS and potentially reused in competitors browsers to compete against them can't have been pretty.
So they had to use a pre-existing open source rendering engine. They went for KHTML, for various well documented reasons, and started work on bringing up to scratch. But did they work with the KDE community to do that? No. Of course not. Steve Jobs wanted to go "tada!" and surprise his followers. So instead they released an enormous patch dump once Safari was out.
I can tell you from working with similar patch dumps from TransGaming that this is very nearly as bad as not getting the changes back at all. They are ridiculously hard to make use of - not only are all the changes mixed together, but often they contain duplicated work. How do you pick between the component written as a labour of love by a volunteer, or the corporate version dumped on your lap by an organization merely following the letter of the law? What if the corporate version is better? What kind of message does that send? How do you split the patch up into discrete commits so you can track regressions when each part depends on the others?
To be frank, if Apple were truly working with the open source community in the KHTML case, they'd have entered the spirit of "no secrets" and released their work as it was done, with discussion on the mailing list. They did not. I've been there - it's not much fun.
Does that mean you still have the overhead of storing the JITCd code blocks in memory for each process?
You probably just need to tell Wine to report that it's Windows 98 or maybe 2K if the game requires that. The latest version of Wine (may not be released yet, don't recall) reports 98 by default.
I don't really see your point. Your asking for guarantees you don't even get with regular Windows.