From: <ohi...@md...> - 2003-05-16 16:29:29
|
On Fri, 16 May 2003 12:02:12 +0100 Thomas Leonard <ta...@ec...> wrote: > Yes, that's why it's important to provide standard locations for each > library. Once the thing is more well tested, we should try to get library > developers to support us (this could mean just installing a symlink on > their site to ours, so at least people still use www.gtk.org for GTK, even > if the data actually comes from somewhere else). What about a mirror directory based system? The files don't even have to reside at gtk.org, etc. but rather a mirrors file that lists all the repositories that the resource can be downloaded from and the hash of the resource for verification. Some intelligence could also be built into the downloader to track what download sites have the best download rate and select the fastest one. A main value of Zero-Install is moving the namespace for software dependencies into the global namespace of the Internet's DNS based addressing system. Current systems like RPM can give you a filename to resolve a dependency but not where to find it, the add-on systems like APT and RPMfind are quite centralized and at best imperfect. |
From: Thomas L. <ta...@gm...> - 2012-01-18 08:18:29
|
On 16 January 2012 23:50, Dave Abrahams <da...@bo...> wrote: > > on Mon Jan 16 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: > >> On 16 January 2012 20:00, Dave Abrahams <da...@bo...> wrote: >>> >>> I am investigating 0install both as a new user and as a potential >>> "exploiter" for a project I've been working on called "ryppl" (I'll >>> explain more about that later). I have several questions: >>> >>> * I installed 0install through macports. The latest version there is >>> version 1.2. I don't know how to upgrade 0install itself in that >>> situation. How do I do that? >> >> I guess you need to wait for MacPorts to update it. > > what about using, e.g. pip or easy_install? As I understand it, the main problem is the non-Python dependencies (PyGTK, etc). > And, stepping back, isn't there something fundamentally wrong with a > packaging system that can't update itself? On Linux systems, it's expected that programs don't update themselves. Other systems may have other conventions, though. The Windows version updates itself. >> You can do: >> >> 0install update alias:foo > > Nifty; but that's no in the 0install man page I have. Fixed. > Anyway, why should I have to write alias: ? I understand that if > there's an ambiguity you have to tell people about it and stop, but 99% > of the time there's none. It could cause a problem with scripts (e.g. a script that did "0launch selections" might suddenly fail if the user happened to have an alias called "selections"). Arguably scripts should always use a prefix (e.g. "0launch file:selections"), but relative paths weren't supported with file: before (now fixed). > Ease-of-use is really important to me. Ryppl's primary test case is > going to be the Boost C++ Libraries, which do *not* have a good > ease-of-installation story. It's part of our mission to fix that. > >>> I'd also like to be able to bless some "feed catalogs" that map short >>> names to feeds and be able to install anything in one of those >>> catalogs by its short name (unless there was an ambiguity). I can >>> always put a wrapper around 0install for this sort of thing, but I >>> worry that if it isn't a native feature 0install will not be able to >>> gain much market share. >> >> ROX has a feed catalog like that ("ROX-Defauts", which sets up a "rox" >> alias and maps various MIME types to ROX application handlers). > > I'm not sure if that's what I mean by a feed catalog. I'm thinking of > something like > > http://roscidus.com/0mirror/feed-list > > [BTW, what do the initial "-" characters mean on some of those feeds?] Retired (no longer monitored for updates, usually because they no longer exist, but still available from the mirror). > but with an optional second column that gives a short name for each feed > (where the default short name is the last part of the URI, but without > the .xml extension). So if I said http://roscidus.com/0mirror/feed-list > is a "blessed feed catalog" then I could "0install TightVNC" and it > would be the same as "0install http://0install.de/feeds/TightVNC.xml". With the ROX-style system, you can just type "TightVNC" and it will download it automatically the first time you use it. >> A more general one would indeed be useful. >> >>> * Even if you don't make short names available, doesn't it make sense to >>> give the feed URL when announcing an update? I ask in part because of >>> http://article.gmane.org/gmane.comp.file-systems.zero-install.devel/4811 >>> and the feeling that I must be missing something obvious. >> >> Oops. Cut-and-paste problem; the page with the feed link has moved to: >> >> http://0install.net/packaging-binaries.html > > Sorry, what I mean is that I was expecting to see this URI in the posting: > > http://0install.net/2007/interfaces/0publish-gui.xml Could do. Especially now we have the "0install update" command. >>> * Is there any chance that 0install could be dual-licensed so it was >>> available under some FOSS license that doesn't include the letters >>> "GPL?" I know, I know, but unfortunately it is a reality that even >>> LGPL is enough to prevent adoption in some shops. >> >> Unlikely. Probably easier to educate them that LGPL isn't going to be >> a problem (unless the company actually wants to make a competing, >> non-LGPL installer using our code and can't work out how to do it as a >> separate module). Normally, of course, they won't be distributing >> 0install itself at all and so there's no problem with copyright >> anyway. > > As I said, "I know, I know, but..." > > Of course it's probably easier for _you_ if _I_ educate them about LGPL > ;-). We could perhaps put something about it on the legal issues page (e.g. "Since you're not distributing 0install itself, you don't need a license to distribute it, and can therefore ignore the license terms entirely; your users can use a client with any license they please as long as it understands the XML format."). Though it would need more detail for people bundling it (0export, etc). -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
From: Dave A. <da...@bo...> - 2012-01-18 16:09:45
|
on Wed Jan 18 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: > On 16 January 2012 23:50, Dave Abrahams <da...@bo...> wrote: >> >> on Mon Jan 16 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: >> >>> On 16 January 2012 20:00, Dave Abrahams <da...@bo...> wrote: >>>> >>>> I am investigating 0install both as a new user and as a potential >>>> "exploiter" for a project I've been working on called "ryppl" (I'll >>>> explain more about that later). I have several questions: >>>> >>>> * I installed 0install through macports. The latest version there is >>>> version 1.2. I don't know how to upgrade 0install itself in that >>>> situation. How do I do that? >>> >>> I guess you need to wait for MacPorts to update it. >> >> what about using, e.g. pip or easy_install? > > As I understand it, the main problem is the non-Python dependencies > (PyGTK, etc). What's the problem? I got those through MacPorts. >> And, stepping back, isn't there something fundamentally wrong with a >> packaging system that can't update itself? > > On Linux systems, it's expected that programs don't update > themselves. Other systems may have other conventions, though. The > Windows version updates itself. > > On Linux systems, it's expected that programs don't update > themselves. Package managers are an exception, though, as far as I can tell. I can update apt using apt. > Other systems may have other conventions, though. The Windows version > updates itself. > >>> You can do: >>> >>> 0install update alias:foo >> >> Nifty; but that's no in the 0install man page I have. > > Fixed. > >> Anyway, why should I have to write alias: ? I understand that if >> there's an ambiguity you have to tell people about it and stop, but >> 99% of the time there's none. > > It could cause a problem with scripts (e.g. a script that did > "0launch selections" might suddenly fail if the user happened to have > an alias called "selections"). Arguably scripts should always use a > prefix (e.g. "0launch file:selections"), but relative paths weren't > supported with file: before (now fixed). I say: favor the humans. And if you really have enough of a userbase at this early stage that you can't break backward compatibility of scripts for a long-term usability/adoption benefit, then you can provide a new user-facing command called "0lunch" ;-). The UI is lacking, but there are lots of ways to approach that problem. >> Ease-of-use is really important to me. Ryppl's primary test case is >> going to be the Boost C++ Libraries, which do *not* have a good >> ease-of-installation story. It's part of our mission to fix that. >> >>>> I'd also like to be able to bless some "feed catalogs" that map short >>>> names to feeds and be able to install anything in one of those >>>> catalogs by its short name (unless there was an ambiguity). I can >>>> always put a wrapper around 0install for this sort of thing, but I >>>> worry that if it isn't a native feature 0install will not be able to >>>> gain much market share. >>> >>> ROX has a feed catalog like that ("ROX-Defauts", which sets up a "rox" >>> alias and maps various MIME types to ROX application handlers). >> >> I'm not sure if that's what I mean by a feed catalog. I'm thinking of >> something like >> >> http://roscidus.com/0mirror/feed-list >> >> [BTW, what do the initial "-" characters mean on some of those feeds?] > > Retired (no longer monitored for updates, usually because they no > longer exist, but still available from the mirror). > >> but with an optional second column that gives a short name for each feed >> (where the default short name is the last part of the URI, but without >> the .xml extension). So if I said http://roscidus.com/0mirror/ feed-list >> is a "blessed feed catalog" then I could "0install TightVNC" and it >> would be the same as "0install http://0install.de/feeds/ TightVNC.xml". > > With the ROX-style system, you can just type "TightVNC" and it will > download it automatically the first time you use it. Not what I'm looking for, I don't think. I don't want to have a bunch of executable aliases in my path just to get easy access to installation. That's /too/ easy. When I want to install, I want to explicitly ask for it. After that, running with a single command is fine. And what about libraries that have no executable to run? Even if the ROX model were somehow objectively better, I think not providing the other model, which so many people are used to, is going to be a huge adoption killer. >>>> * Even if you don't make short names available, doesn't it make sense to >>>> give the feed URL when announcing an update? I ask in part because of >>>> http://article.gmane.org/ >>>> gmane.comp.file-systems.zero-install.devel/4811 >>>> and the feeling that I must be missing something obvious. >>> >>> Oops. Cut-and-paste problem; the page with the feed link has moved to: >>> >>> http://0install.net/packaging-binaries.html >> >> Sorry, what I mean is that I was expecting to see this URI in the posting: >> >> http://0install.net/2007/interfaces/0publish-gui.xml > > Could do. Especially now we have the "0install update" command. Jah. (consider supplying 0update) >>>> * Is there any chance that 0install could be dual-licensed so it was >>>> available under some FOSS license that doesn't include the letters >>>> "GPL?" I know, I know, but unfortunately it is a reality that even >>>> LGPL is enough to prevent adoption in some shops. >>> >>> Unlikely. Probably easier to educate them that LGPL isn't going to be >>> a problem (unless the company actually wants to make a competing, >>> non-LGPL installer using our code and can't work out how to do it as a >>> separate module). Normally, of course, they won't be distributing >>> 0install itself at all and so there's no problem with copyright >>> anyway. >> >> As I said, "I know, I know, but..." >> >> Of course it's probably easier for _you_ if _I_ educate them about LGPL >> ;-). > > We could perhaps put something about it on the legal issues page > (e.g. "Since you're not distributing 0install itself, you don't need > a license to distribute it, and can therefore ignore the license > terms entirely; your users can use a client with any license they > please as long as it understands the XML format."). Though it would > need more detail for people bundling it (0export, etc). That could help, though FUD runs deep. Just curious, and I don't mean to press this issue, but is there some reason that dual-licensing (e.g. under BSD, MIT, or BSL) wouldn't work for you? -- Dave Abrahams BoostPro Computing http://www.boostpro.com |
From: Tim C. <ti...@gf...> - 2012-01-19 12:55:35
|
On Jan 19, 2012 3:07 AM, "Dave Abrahams" <da...@bo...> wrote: > > > on Wed Jan 18 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: > > > On 16 January 2012 23:50, Dave Abrahams <da...@bo...> wrote: > >> > >> on Mon Jan 16 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: > >> > >>> On 16 January 2012 20:00, Dave Abrahams <da...@bo...> wrote: > >>>> > >>>> I am investigating 0install both as a new user and as a potential > >>>> "exploiter" for a project I've been working on called "ryppl" (I'll > >>>> explain more about that later). I have several questions: > >>>> > >>>> * I installed 0install through macports. The latest version there is > >>>> version 1.2. I don't know how to upgrade 0install itself in that > >>>> situation. How do I do that? > >>> > >>> I guess you need to wait for MacPorts to update it. > >> > >> what about using, e.g. pip or easy_install? > > > > As I understand it, the main problem is the non-Python dependencies > > (PyGTK, etc). > > What's the problem? I got those through MacPorts. > > >> And, stepping back, isn't there something fundamentally wrong with a > >> packaging system that can't update itself? > > > > On Linux systems, it's expected that programs don't update > > themselves. Other systems may have other conventions, though. The > > Windows version updates itself. > > > > On Linux systems, it's expected that programs don't update > > themselves. > > Package managers are an exception, though, as far as I can tell. I can > update apt using apt. Apt is the odd one out here - rubygems self update is disabled on debian, and I presume all other package managers that are installed by apt must follow the same rules. But unlike gem, you can at least bootstrap 0install fairly trivially (I use a bash alias to avoid the recursive problem mentioned earler). > >>>> * Is there any chance that 0install could be dual-licensed so it was > >>>> available under some FOSS license that doesn't include the letters > >>>> "GPL?" I know, I know, but unfortunately it is a reality that even > >>>> LGPL is enough to prevent adoption in some shops. > >>> > >>> Unlikely. Probably easier to educate them that LGPL isn't going to be > >>> a problem (unless the company actually wants to make a competing, > >>> non-LGPL installer using our code and can't work out how to do it as a > >>> separate module). Normally, of course, they won't be distributing > >>> 0install itself at all and so there's no problem with copyright > >>> anyway. > >> > >> As I said, "I know, I know, but..." > >> > >> Of course it's probably easier for _you_ if _I_ educate them about LGPL > >> ;-). > > > > We could perhaps put something about it on the legal issues page > > (e.g. "Since you're not distributing 0install itself, you don't need > > a license to distribute it, and can therefore ignore the license > > terms entirely; your users can use a client with any license they > > please as long as it understands the XML format."). Though it would > > need more detail for people bundling it (0export, etc). > > That could help, though FUD runs deep. > > Just curious, and I don't mean to press this issue, but is there some > reason that dual-licensing (e.g. under BSD, MIT, or BSL) wouldn't work > for you? I can't speak for Thomas or others, but I choose gpl for moral reasons - if I were OK with bsd I would pick it in the first place. I have seen a lot of people suggesting gpl projects should switch to bsd in order to allow ios apps to use their code, but isn't much of the point of gpl to dissuade such platforms? |
From: Thomas L. <ta...@gm...> - 2012-01-20 21:00:53
|
On 19 January 2012 12:25, Tim Cuthbertson <ti...@gf...> wrote: > > On Jan 19, 2012 3:07 AM, "Dave Abrahams" <da...@bo...> wrote: >> >> >> on Wed Jan 18 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: [...] >> > We could perhaps put something about it on the legal issues page >> > (e.g. "Since you're not distributing 0install itself, you don't need >> > a license to distribute it, and can therefore ignore the license >> > terms entirely; your users can use a client with any license they >> > please as long as it understands the XML format."). Though it would >> > need more detail for people bundling it (0export, etc). >> >> That could help, though FUD runs deep. >> >> Just curious, and I don't mean to press this issue, but is there some >> reason that dual-licensing (e.g. under BSD, MIT, or BSL) wouldn't work >> for you? > > I can't speak for Thomas or others, but I choose gpl for moral reasons - if > I were OK with bsd I would pick it in the first place. I have seen a lot of > people suggesting gpl projects should switch to bsd in order to allow ios > apps to use their code, but isn't much of the point of gpl to dissuade such > platforms? I think that's right. We want people to use 0install to distribute their software, not to use our code to write closed-source installers. I've tried to summarise the effects of the LGPL on the legal issues page: http://0install.net/legal.html If anyone thinks I'm interpreting the license wrongly, let me know. BTW, I noticed that when I wrote that page, long ago, I said you couldn't use 0install to distribute programs unless you allowed "unlimited redistribution of unmodified binaries", due to the effects of mirroring and caching. I think that's too strict. Currently we never mirror software (only feeds) and the peer-to-peer stuff hasn't been merged, so the only real issue is that installing on a machine may make the software available to other users on the same machine, which is quite common for installers anyway. So, I propose we add some kind of do-not-redistribute marker to packages, so that any mirroring/caching/p2p system we might build in the future can ignore them. I was going to suggest putting a '.do-not-redistribute' file at the top-level, but maybe Windows won't like that name. Anyone have a better suggestion? Alternatively, it could be a flag in the feed that causes such a file to be generated. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
From: Dave A. <da...@bo...> - 2012-01-30 08:30:55
|
This is a self-reply, but only because my most important questions/issues didn't get a response (the licensing thing is a very low priority for me)... I hope someone will be able to take the time to address the items below. Thanks... on Wed Jan 18 2012, Dave Abrahams <dave-AT-boostpro.com> wrote: >>> Anyway, why should I have to write alias: ? I understand that if >>> there's an ambiguity you have to tell people about it and stop, but >>> 99% of the time there's none. >> >> It could cause a problem with scripts (e.g. a script that did >> "0launch selections" might suddenly fail if the user happened to have >> an alias called "selections"). Arguably scripts should always use a >> prefix (e.g. "0launch file:selections"), but relative paths weren't >> supported with file: before (now fixed). > > I say: favor the humans. And if you really have enough of a userbase at > this early stage that you can't break backward compatibility of scripts > for a long-term usability/adoption benefit, then you can provide a new > user-facing command called "0lunch" ;-). The UI is lacking, but there > are lots of ways to approach that problem. > >> With the ROX-style system, you can just type "TightVNC" and it will >> download it automatically the first time you use it. > > Not what I'm looking for, I don't think. I don't want to have a bunch > of executable aliases in my path just to get easy access to > installation. That's /too/ easy. When I want to install, I want to > explicitly ask for it. After that, running with a single command is > fine. And what about libraries that have no executable to run? Even if > the ROX model were somehow objectively better, I think not providing the > other model, which so many people are used to, is going to be a huge > adoption killer. Here's what I'm concerned about: * People want control over their computing environments - The ROX model—which I understand to be keeping a large collection of executables in my PATH, most of which will cause new software to be downloaded from the internet when they are first run—will be unacceptably "out-of-control" for many. * People want to be able to easily install software from a catalog - It's what many people are used to. A novel usage model will hurt adoption unless there's some killer benefit to outweigh the unfamiliarity. So far, I don't see any benefits associated the novel usage model of 0install. - Using URIs to identify software to be installed is cumbersome * Implicit installation on-demand is not going to be acceptable to many - It may not even be possible depending on the user's privileges - People want explicit control over what's installed on their systems - The non-uniform performance characteristics (first run is an order of magnitude slower) could be a problem - The fact that you may not be able to run some "installed" software at all without internet connectivity (because dependencies aren't installed already) could be a problem * People want to be able to easily use their installed software - Running software through 0launch is cumbersome - Using URIs to identify software to run is cumbersome - Creating aliases is cumbersome - Qualifying package names with alias:, etc., is cumbersome * Having to launch python (via 0launch) just to run any installed executable is... disturbing. It "feels" like a highly intrusive design and has worrisome implications for performance. Hoping to learn that I'm wrong about all these things. Thanks in advance for your replies. -- Dave Abrahams BoostPro Computing http://www.boostpro.com |
From: Bastian E. <ba...@ei...> - 2012-01-30 13:00:08
|
> * People want to be able to easily install software from a catalog This feature is available right now in the Windows version of Zero Install. You get a catalog of well-known feeds and can pick and choose the applications you want with a few clicks. I haven't received much feedback yet as to whether there is any interest in this being ported to Linux and/or MacOS X. > * Implicit installation on-demand is not going to be acceptable to many > - The fact that you may not be able to run some "installed" software at all without internet connectivity (because dependencies aren't installed already) could be a problem When you create a new menu entry for a Zero Installed application on Linux or use the desktop integration feature on Windows the application and all its dependencies are downloaded ahead of time so they will be available even without an internet connection. Installation on-demand only happens if you run something you have manually deleted from the cache or have never used before anyway. > - It may not even be possible depending on the user's privileges Zero Install only requires write access to the user's home directory so privileges should never be a problem. > - People want explicit control over what's installed on their systems In the best case novice users will perceive Zero Install as a system that "just works" where they only manage what menu entries, aliases, etc. they want. Nothing else gets "installed" in the sense that it modifies your system configuration. Advanced users can use the "0store manage" GUI to see what files Zero Install has placed on their machines and can easily remove them. > * People want to be able to easily use their installed software The aforementioned Linux menu entries and Windows desktop integration (desktop shortcuts, start menu entries, file type associations) should make the experience of starting an application via Zero Install almost identical to starting normal applications. I am not sure what the integration story on MacOS X is at the moment. > * Having to launch python (via 0launch) just to run any installed executable is... disturbing. It "feels" like a highly intrusive design and has worrisome implications for performance. Having to go through an additional executable does of course have a performance impact but it only occurs once per application launch and is usually below 1 second. I use Zero Install to launch a number of applications such as VLC, Pidgin, FileZilla and NetBeans in my everyday usage and haven't had any performance troubles. It should also be noted that you "get something in return" for this additional process: When you launch an application via Zero Install new versions of the application are automatically detected and downloaded in the background and become available the next time you launch the application (with no additional startup delay!). |
From: Dave A. <da...@bo...> - 2012-01-30 19:28:27
|
on Mon Jan 30 2012, "Bastian Eicher" <bastian-AT-eicher.net> wrote: >> * People want to be able to easily install software from a catalog > This feature is available right now in the Windows version of Zero > Install. You get a catalog of well-known feeds and can pick and choose > the applications you want with a few clicks. > I haven't received much feedback yet as to whether there is any interest in this being ported to Linux and/or MacOS X. +1 for interest. However, there should be a standard mechanism for publishing feed aggregations, and for subscribing to those. >> * Implicit installation on-demand is not going to be acceptable to many >> - The fact that you may not be able to run some "installed" software at > all without internet connectivity (because dependencies aren't > installed already) could be a problem > > When you create a new menu entry for a Zero Installed application on > Linux or use the desktop integration feature on Windows the > application and all its dependencies are downloaded ahead of time so > they will be available even without an internet connection. > > Installation on-demand only happens if you run something you have > manually deleted from the cache or have never used before anyway. My understanding was that in <http://old.nabble.com/Re%3A-Questions-p33159573.html> the ROX model was being proposed as an alternative for the common catalog model I'm pushing for, and that the ROX model dumps a bunch of executables into your PATH that install themselves on demand. Please correct me if I've misunderstood. >> - It may not even be possible depending on the user's privileges > > Zero Install only requires write access to the user's home directory > so privileges should never be a problem. It clearly depends where the applications are being installed, and by whom. If a sysadmin uses 0install to put things in some standard system location, users will be unable to use any that haven't also been downloaded. As I understand it, the ROX-style system would leave users stuck in that case. >> - People want explicit control over what's installed on their >> systems > > In the best case novice users will perceive Zero Install as a system > that "just works" where they only manage what menu entries, aliases, > etc. they want. Nothing else gets "installed" in the sense that it > modifies your system configuration. > Advanced users can use the "0store manage" GUI to see what files Zero > Install has placed on their machines and can easily remove them. Sorry, but you're completely missing my point here. The ROX-style system only gives people indirect control. >> * People want to be able to easily use their installed software > > The aforementioned Linux menu entries and Windows desktop integration > (desktop shortcuts, start menu entries, file type associations) should > make the experience of starting an application via Zero Install almost > identical to starting normal applications. > I am not sure what the integration story on MacOS X is at the moment. As that's my primary platform, that's what I see most of the time. And there are *lots* of things I might want to install that aren't helped at all by desktop shortcuts, start menu entries, and file type associations. For example: command-line tools libraries >> * Having to launch python (via 0launch) just to run any installed > executable is... disturbing. It "feels" like a highly intrusive > design and has worrisome implications for performance. > > Having to go through an additional executable does of course have a > performance impact but it only occurs once per application launch and > is usually below 1 second. I guess you don't use many shell scripts? It's very easy to imagine a shell script launching the same executable thousands of times in a second. > I use Zero Install to launch a number of applications such as VLC, > Pidgin, FileZilla and NetBeans in my everyday usage and haven't had > any performance troubles. Of course not. These are top-level applications, but they're not all there is. > It should also be noted that you "get something in return" for this > additional process: When you launch an application via Zero Install > new versions of the application are automatically detected and > downloaded in the background and become available the next time you > launch the application (with no additional startup delay!). That may or may not be considered a benefit, depending on the user. There should be an option to bypass 0launch. -- Dave Abrahams BoostPro Computing http://www.boostpro.com |
From: Anders F B. <af...@us...> - 2012-01-30 21:00:45
|
Dave Abrahams wrote: >>> * Having to launch python (via 0launch) just to run any installed >> executable is... disturbing. It "feels" like a highly intrusive >> design and has worrisome implications for performance. >> >> Having to go through an additional executable does of course have a >> performance impact but it only occurs once per application launch and >> is usually below 1 second. > > I guess you don't use many shell scripts? It's very easy to imagine a > shell script launching the same executable thousands of times in a > second. You should be able to set up the executable using the regular PATH, and LD_LIBRARY_PATH for libraries, and call it in the usual fashion ? It shouldn't be a major problem... But one could use --show or even --get-selections, to cache the resolving results/environment variables. Something called very often usually gets a custom variable set: <requires interface="http://repo.roscidus.com/devel/make"> <executable-in-var name='MAKE'/> </requires> Then you call it with $MAKE ? Slightly more effort for shared libs. Should get around to fixing the set up of DYLD_LIBRARY_PATH*, though. --anders * Zero Install should "translate" any setting of LD_LIBRARY_PATH to DYLD_LIBRARY_PATH when running on Darwin, for easy porting... <environment insert="lib" mode="prepend" name="LD_LIBRARY_PATH"/> |
From: Bastian E. <ba...@ei...> - 2012-01-31 00:56:10
|
> However, there should be a standard mechanism for publishing feed aggregations, and for subscribing to those. Agreed. We currently have something of a quasi-standard which has been called a metafeed on this mailing list. This XML file is such a feed of feeds (and happens to be what Zero Install for Windows uses internally to display its application catalog): http://0install.de/catalog/ > It clearly depends where the applications are being installed, and by whom. If a sysadmin uses 0install to put things in some standard system location, users will be unable to use any that haven't also been downloaded. As I understand it, the ROX-style system would leave users stuck in that case. Actually that's not quite right. Even if a sysadmin uses 0install to put things in some standard system location that "thing" will only be an alias. When a user launches it his own solver will be run and will be able to use both a shared cache and the private cache in the home directory. So if I were to launch a 0installed /usr/bin/emacs and the application files are missing, Zero Install would simply download them into my home directory. > As that's my primary platform, that's what I see most of the time. And there are *lots* of things I might want to install that aren't helped at all by desktop shortcuts, start menu entries, and file type associations. For example: > command-line tools Command-line tools should be covered by 0alias. > libraries Zero Install is centered around the principal of dependency injection so libraries are never "installed". Instead they get provided to applications that declare that they need them. If you wish to install a library for usage by non-0installed applications I think Zero Install is probably not well suited. > I guess you don't use many shell scripts? It's very easy to imagine a shell script launching the same executable thousands of times in a second. > Of course not. These are top-level applications, but they're not all there is. What sort of low-level applications are you thinking of? Personally, I wouldn't want to use Zero Install for something like "grep" since on the one hand it would probably be too slow, as you pointed out, and on the other hand large collections of low-level tools are already handled pretty well by existing distributions. For me, Zero Install is great for providing specialized tools on demand and in up-to-date versions. Say I need the newest version of Ant right now, 0launch provides it easily (and keeps it up-to-date in the future) and I don't mind a short startup delay. This may sound like a cheap answer, but I'd say if you need to launch an executable thousands of times in a second, then don't install it via Zero Install. > There should be an option to bypass 0launch. I'm not quite sure what the point of Zero Install would be then. Basically we'd have downloaded and extracted a ZIP archive and created some aliases/menu entries/etc. that point there. If we bypass 0launch we don't really provide anything beyond what existing installers/package managers can do. |
From: Tim C. <ti...@gf...> - 2012-01-31 05:05:48
|
On Tue, Jan 31, 2012 at 11:56 AM, Bastian Eicher <ba...@ei...> wrote: >> As that's my primary platform, that's what I see most of the time. And > there are *lots* of things I might want to install that aren't helped at all > by desktop shortcuts, start menu entries, and file type associations. For > example: >> command-line tools > Command-line tools should be covered by 0alias. >> libraries > Zero Install is centered around the principal of dependency injection so > libraries are never "installed". Instead they get provided to applications > that declare that they need them. > If you wish to install a library for usage by non-0installed applications I > think Zero Install is probably not well suited. > >> I guess you don't use many shell scripts? It's very easy to imagine a > shell script launching the same executable thousands of times in a second. >> Of course not. These are top-level applications, but they're not all > there is. > What sort of low-level applications are you thinking of? Personally, I > wouldn't want to use Zero Install for something like "grep" since on the one > hand it would probably be too slow, as you pointed out, and on the other > hand large collections of low-level tools are already handled pretty well by > existing distributions. > For me, Zero Install is great for providing specialized tools on demand and > in up-to-date versions. Say I need the newest version of Ant right now, > 0launch provides it easily (and keeps it up-to-date in the future) and I > don't mind a short startup delay. > This may sound like a cheap answer, but I'd say if you need to launch an > executable thousands of times in a second, then don't install it via Zero > Install. It's worth noting that the overhead really only applies when entering 0launch in the first place. If your script (that uses grep lots) is itself a 0install feed, and declares its dependency on the `grep` 0install feed, than `grep` will be placed into your $PATH for the duration of your script - each time you execute it, it will essentially bypass 0launch since it's already been resolved for you. So really, the overhead is only present for the _outermost_ application that uses 0launch - for an application (or script) accessing its own dependencies, there's no overhead. |
From: Bastian E. <ba...@ei...> - 2012-01-31 18:48:52
|
> It's worth noting that the overhead really only applies when entering 0launch in the first place. If your script (that uses grep lots) is itself a 0install feed, and declares its dependency on the `grep` 0install feed, than `grep` will be placed into your $PATH for the duration of your script - each time you execute it, it will essentially bypass 0launch since it's already been resolved for you. > So really, the overhead is only present for the _outermost_ application that uses 0launch - for an application (or script) accessing its own dependencies, there's no overhead. I forgot about that approach, thanks for pointing it out. :) Just for completeness a little sample: $ cat > my_script.sh #!/bin/bash # Run foobar 1000 times for i in {1..1000} do foobar done $ cat > my_script.xml <?xml version="1.0"?> <interface xmlns="http://zero-install.sourceforge.net/2004/injector/interface"> <name>My script</name> <summary>Runs foobar a lot</summary> <implementation id="my_script" main="my_script.sh" local-path="."> <requires interface="http://foobar.domain/foobar.xml"> <executable-in-path name="foobar"/> </requires> </implementation> </interface> $ 0launch my_script.xml Having to create a whole feed file for a simple shell script does seem a little overkill but it does offer neat possibilities such as specifying exactly which version of foobar the script needs. |
From: Anders F B. <af...@us...> - 2012-01-30 20:35:28
|
Bastian Eicher wrote: >> * People want to be able to easily use their installed software > The aforementioned Linux menu entries and Windows desktop integration (desktop shortcuts, start menu entries, file type associations) should make the experience of starting an application via Zero Install almost identical to starting normal applications. > I am not sure what the integration story on MacOS X is at the moment. Mac OS X uses application directories, so it works like ROX AppDirs and pretty similar to what the .desktop files provide for Linux etc. That is, you get an icon and a startup script that calls 0launch $url. If you hold the option key down on launch, you get to choose versions. http://afb.users.sourceforge.net/zero-install/interfaces/optionkeydown.xml For command-line programs, it's the same old 0alias shell scripts... File type associations is TODO, would be an AddApp feature I guess ? One current feature of AddApp (provided by external helper programs*) is converting any .png (or .svg) icons to the native .icns format. * http://icns.sourceforge.net/ --anders |
From: Yfrwlf <yf...@gm...> - 2012-01-30 13:11:25
|
On 01/29/2012 08:27 PM, Dave Abrahams wrote: > > > - Using URIs to identify software to be installed is cumbersome Right, what is needed is all three sources of programs: a) Internet package by URL b) Internet package by program name c) local package (b) would be solved with the implementation of a software repo/store(s). I think ZI is fairly flexible so far at fulfilling the other two. > - The fact that you may not be able to run some "installed" software at > all without internet connectivity (because dependencies aren't > installed already) could be a problem I think this is possible now with ZI. You can grab all dependencies for storage locally or for making your own repository. > - Running software through 0launch is cumbersome The reason ZI works along side other package managers now is because it is separate, but for these dual-manager systems it might be helpful if something was done like adding aliases to a user's shell, perhaps amended with a zero or ZI or something? apache2-0, or 0apache? Bare in mind I'm just a lurker here as I sadly don't have enough time to focus on this project much, even though I feel it's very important to Linux adoption to iron out standards, so I haven't been able to tinker and attempt to understand very much. |
From: Thomas L. <ta...@gm...> - 2012-01-30 21:47:02
|
On 30 January 2012 02:27, Dave Abrahams <da...@bo...> wrote: > on Wed Jan 18 2012, Dave Abrahams <dave-AT-boostpro.com> wrote: [...] >>> With the ROX-style system, you can just type "TightVNC" and it will >>> download it automatically the first time you use it. >> >> Not what I'm looking for, I don't think. I don't want to have a bunch >> of executable aliases in my path just to get easy access to >> installation. That's /too/ easy. Don't know about Macs, but note that most Linux systems already work this way. e.g. (Fedora) $ konqueror bash: konqueror: command not found... Install package 'kdebase' to provide command 'konqueror'? [N/y] (some have more or fewer steps; Ubuntu prints a command to type if you want to install it rather than just asking you as Fedora and 0install do; while OpenSUSE prints a command to type to find out what command you need to type to install it...). >> When I want to install, I want to explicitly ask for it. Why? If you know it's already installed, do nothing. If you're not sure, or are sure it isn't, do e.g. $ konqueror --version (assuming konqueror was available through 0install) >> Even if the ROX model were somehow objectively better, I think not providing the >> other model, which so many people are used to, is going to be a huge >> adoption killer. Note that it's not really "the ROX model"; it's just that ROX-Defaults is one example that happens to work that way. > * Implicit installation on-demand is not going to be acceptable to many > > - It may not even be possible depending on the user's privileges If it's not possible on demand, then it wouldn't be possible with the user choosing from a catalogue either. > - People want explicit control over what's installed on their systems Nothing gets installed without confirmation first. > - The non-uniform performance characteristics (first run is an order > of magnitude slower) could be a problem > - The fact that you may not be able to run some "installed" software at > all without internet connectivity (because dependencies aren't > installed already) could be a problem Both apply to all possible systems, of course. > * People want to be able to easily use their installed software > > - Running software through 0launch is cumbersome > - Using URIs to identify software to run is cumbersome > - Creating aliases is cumbersome > - Qualifying package names with alias:, etc., is cumbersome None of which are necessary with the scheme above. > * Having to launch python (via 0launch) just to run any installed > executable is... disturbing. It "feels" like a highly intrusive > design and has worrisome implications for performance. Yes. There's lots of potential for caching and using C for performance if it becomes a problem. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
From: Bastian E. <ba...@ei...> - 2012-01-20 21:32:14
|
> So, I propose we add some kind of do-not-redistribute marker to packages, so that any mirroring/caching/p2p system we might build in the future can ignore them. I was going to suggest putting a '.do-not-redistribute' file at the top-level, but maybe Windows won't like that name. Anyone have a better suggestion? Alternatively, it could be a flag in the feed that causes such a file to be generated. Windows itself has no problem with filenames starting with a dot, however the Windows Explorer does not allow you to name a file in such a way. Instead you have to use the command-line to rename a file. I would prefer a flag in the feed causing such a file to be generated since this would not force anybody to modify their existing release archives in a Zero Install-specific way. |
From: Tim C. <ti...@gf...> - 2012-01-20 23:25:21
|
On Sat, Jan 21, 2012 at 8:32 AM, Bastian Eicher <ba...@ei...> wrote: >> So, I propose we add some kind of do-not-redistribute marker to packages, so that any mirroring/caching/p2p system we might build in the future can ignore them. I was going to suggest putting a '.do-not-redistribute' file at the top-level, but maybe Windows won't like that name. Anyone have a better suggestion? Alternatively, it could be a flag in the feed that causes such a file to be generated. > Windows itself has no problem with filenames starting with a dot, however the Windows Explorer does not allow you to name a file in such a way. Instead you have to use the command-line to rename a file. > I would prefer a flag in the feed causing such a file to be generated since this would not force anybody to modify their existing release archives in a Zero Install-specific way. Agreed, a flag in the feed seems much less intrusive to me. |
From: Tim D. <lim...@gm...> - 2012-01-21 15:06:18
|
On 01/18/2012 05:07 PM, Dave Abrahams wrote: > And, stepping back, isn't there something fundamentally wrong with a > packaging system that can't update itself? I agree, if package managers didn't do that, the user would have to manually update or you would have an infinite recursion of updaters updating updaters. We could change 0install so that, when 0install is ran: if $args contains --no-bootstrap: continue into program code as we do now else: exec: 0install --no-bootstrap run http://0install.net/2007/interfaces/ZeroInstall.xml --no-bootstrap $args As long as ZeroInstall.xml is kept backwards-compatible, older versions will be able to bootstrap into the newest version. Coincidentally, this also makes it much much easier to test local development versions of zero install, as you could simply change the policy on the ZI version and everything would be using the dev version. Also note, the newer ZI can have more dependencies than the installed ZI, as long as the installed ZI can fetch those dependencies. This could possibly be handy for 0bootstrap (provide a basic ZI implementation with very little dependencies that then downloads the newest ZI with dependencies and runs the new one). -- Kind regards Tim Diels |
From: Thomas L. <ta...@gm...> - 2012-01-22 15:23:57
|
On 21 January 2012 15:06, Tim Diels <lim...@gm...> wrote: > On 01/18/2012 05:07 PM, Dave Abrahams wrote: >> And, stepping back, isn't there something fundamentally wrong with a >> packaging system that can't update itself? > I agree, if package managers didn't do that, the user would have to > manually update or you would have an infinite recursion of updaters > updating updaters. > > We could change 0install so that, when 0install is ran: > if $args contains --no-bootstrap: > continue into program code as we do now > else: > exec: 0install --no-bootstrap run > http://0install.net/2007/interfaces/ZeroInstall.xml --no-bootstrap $args > > As long as ZeroInstall.xml is kept backwards-compatible, older versions > will be able to bootstrap into the newest version. This can work (and early versions did work like this). It can add some complexity, however (e.g. does running with -v debug the process of running the application, or the process of running the second 0install?). > Coincidentally, this also makes it much much easier to test local > development versions of zero install, as you could simply change the > policy on the ZI version and everything would be using the dev version. For programs that depend on 0install (e.g. 0compile), that should already work. For running it from the shell, I think some developers do have it set up as you describe, but personally I just run 0install from my Git checkout when I want the dev version. -- Dr Thomas Leonard http://0install.net/ GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 GPG: DA98 25AE CAD0 8975 7CDA BD8E 0713 3F96 CA74 D8BA |
From: Tim D. <lim...@gm...> - 2012-01-23 08:23:09
|
On 01/22/2012 04:23 PM, Thomas Leonard wrote: > On 21 January 2012 15:06, Tim Diels<lim...@gm...> wrote: >> We could change 0install so that, when 0install is ran: >> if $args contains --no-bootstrap: >> continue into program code as we do now >> else: >> exec: 0install --no-bootstrap run >> http://0install.net/2007/interfaces/ZeroInstall.xml --no-bootstrap $args >> >> As long as ZeroInstall.xml is kept backwards-compatible, older versions >> will be able to bootstrap into the newest version. > This can work (and early versions did work like this). It can add some > complexity, however (e.g. does running with -v debug the process of > running the application, or the process of running the second > 0install?). I would bootstrap immediately and after that forget there ever was a first/second 0install process. So I'd debug the second 0install. There is some complexity in the requirement that 0install dependencies should be in a format recognised by the currently installed 0install however. Though I was hoping to use this as auto-self-update, this would form a problem. -- Kind regards Tim Diels |
From: Dave A. <da...@bo...> - 2012-01-30 19:30:14
|
on Mon Jan 30 2012, Yfrwlf <yfrwlf-AT-gmail.com> wrote: > On 01/29/2012 08:27 PM, Dave Abrahams wrote: >> >> >> - Using URIs to identify software to be installed is cumbersome > > Right, what is needed is all three sources of programs: > a) Internet package by URL > b) Internet package by program name What about libraries (installation artifacts that aren't programs?) > c) local package > > (b) would be solved with the implementation of a software > repo/store(s). I think ZI is fairly flexible so far at fulfilling the > other two. >> - The fact that you may not be able to run some "installed" software at >> all without internet connectivity (because dependencies aren't >> installed already) could be a problem > > I think this is possible now with ZI. You can grab all dependencies for > storage locally or for making your own repository. My point isn't that there's no workaround, it's that the ROX model doesn't support standard expectations for an installation system. >> - Running software through 0launch is cumbersome > > The reason ZI works along side other package managers now is because it > is separate, but for these dual-manager systems it might be helpful if > something was done like adding aliases to a user's shell, perhaps > amended with a zero or ZI or something? apache2-0, or 0apache? > > Bare in mind I'm just a lurker here as I sadly don't have enough time to > focus on this project much, even though I feel it's very important to > Linux adoption to iron out standards, so I haven't been able to tinker > and attempt to understand very much. I think the (Python-based) virtualenv project (<http://pypi.python.org/pypi/virtualenv>) pretty much has this stuff nailed. If the ZI developers haven't thoroughly researched it, I think they should, ASAP. You could probably build significant parts of ZI on top of it and throw away some code. -- Dave Abrahams BoostPro Computing http://www.boostpro.com |
From: Dave A. <da...@bo...> - 2012-01-31 05:07:48
|
on Mon Jan 30 2012, Anders F Björklund <afb-AT-users.sourceforge.net> wrote: > * Zero Install should "translate" any setting of LD_LIBRARY_PATH > to DYLD_LIBRARY_PATH when running on Darwin, for easy porting... > > <environment insert="lib" mode="prepend" name="LD_LIBRARY_PATH"/> Other OSes have their own variables used for this same purpose. I suggest a more general mechanism. -- Dave Abrahams BoostPro Computing http://www.boostpro.com |
From: Dave A. <da...@bo...> - 2012-01-31 05:10:12
|
on Mon Jan 30 2012, Anders F Björklund <afb-AT-users.sourceforge.net> wrote: > Dave Abrahams wrote: > >>>> * Having to launch python (via 0launch) just to run any installed >>> executable is... disturbing. It "feels" like a highly intrusive >>> design and has worrisome implications for performance. >>> >>> Having to go through an additional executable does of course have a >>> performance impact but it only occurs once per application launch and >>> is usually below 1 second. >> >> I guess you don't use many shell scripts? It's very easy to imagine a >> shell script launching the same executable thousands of times in a >> second. > > You should be able to set up the executable using the regular PATH, > and LD_LIBRARY_PATH for libraries, and call it in the usual fashion ? [IIUC, you don't intend that to be a question...?] > It shouldn't be a major problem... Can you show me how? Commands and examples please. > But one could use --show or even --get-selections, to cache the > resolving results/environment variables. Sorry, I don't know anything about 0launch internals (yet) and the man page for 0launch gives no clue how those options relate to environment variables. Please explain further. > Something called very often usually gets a custom variable set: > > <requires interface="http://repo.roscidus.com/devel/make"> > <executable-in-var name='MAKE'/> > </requires> > > Then you call it with $MAKE ? Your usage of the question mark is confusing me, sorry. /Who/ calls make with $MAKE? In what context? Obviously merely having the XML quoted above somewhere will not affect the contents of the MAKE environment variable at my zsh prompt? > Slightly more effort for shared libs. Sorry to ask, but if this information is going to be of any use to me I need more specifics and more context. Would you mind? > Should get around to fixing the set up of DYLD_LIBRARY_PATH*, though. > --anders > > * Zero Install should "translate" any setting of LD_LIBRARY_PATH > to DYLD_LIBRARY_PATH when running on Darwin, for easy porting... > > <environment insert="lib" mode="prepend" name="LD_LIBRARY_PATH"/> Thanks, -- Dave Abrahams BoostPro Computing http://www.boostpro.com |
From: Anders F B. <af...@us...> - 2012-01-31 17:16:55
|
Dave Abrahams wrote: >>> I guess you don't use many shell scripts? It's very easy to imagine a >>> shell script launching the same executable thousands of times in a >>> second. >> >> You should be able to set up the executable using the regular PATH, >> and LD_LIBRARY_PATH for libraries, and call it in the usual fashion ? > > [IIUC, you don't intend that to be a question...?] I probably meant "would it work for you?", it's doable if enough. >> It shouldn't be a major problem... > > Can you show me how? Commands and examples please. Okay, will need to write and test some more detailed specifics. >> But one could use --show or even --get-selections, to cache the >> resolving results/environment variables. > > Sorry, I don't know anything about 0launch internals (yet) and the man > page for 0launch gives no clue how those options relate to environment > variables. Please explain further. They print the locations, of the current selection for a feed. >> Something called very often usually gets a custom variable set: >> >> <requires interface="http://repo.roscidus.com/devel/make"> >> <executable-in-var name='MAKE'/> >> </requires> >> >> Then you call it with $MAKE ? > > Your usage of the question mark is confusing me, sorry. /Who/ calls make > with $MAKE? In what context? Obviously merely having the XML quoted > above somewhere will not affect the contents of the MAKE environment > variable at my zsh prompt? Similar to http://0install.net/interface-spec.html#id2735648 (Bindings) >> Slightly more effort for shared libs. > > Sorry to ask, but if this information is going to be of any use to me I > need more specifics and more context. Would you mind? Sure. What I meant was that if you have a statically linked program, you don't need to make sure that any shared libraries are in the path. What program are you eventually looking at running at your zsh prompt ? --anders |
From: Dave A. <da...@bo...> - 2012-01-31 05:42:22
|
on Mon Jan 30 2012, Thomas Leonard <talex5-AT-gmail.com> wrote: > On 30 January 2012 02:27, Dave Abrahams <da...@bo...> wrote: >> on Wed Jan 18 2012, Dave Abrahams <dave-AT-boostpro.com> wrote: > [...] >>>> With the ROX-style system, you can just type "TightVNC" and it will >>>> download it automatically the first time you use it. >>> >>> Not what I'm looking for, I don't think. I don't want to have a bunch >>> of executable aliases in my path just to get easy access to >>> installation. That's /too/ easy. > > Don't know about Macs, but note that most Linux systems already work > this way. e.g. (Fedora) I don't recall my ubuntu installation working that way. > $ konqueror > bash: konqueror: command not found... > Install package 'kdebase' to provide command 'konqueror'? [N/y] Well, at least it asks before going ahead with installation. But I'll bet you dollars to donuts you can configure it not to ask. Oh, and I'll bet you dollars to donuts this is a function of the shell. The executable isn't found, because it isn't there. The way I understand the ROX model, the named executable really /is/ there. > (some have more or fewer steps; Ubuntu prints a command to type if you > want to install it rather than just asking you as Fedora and 0install > do; while OpenSUSE prints a command to type to find out what command > you need to type to install it...). Yeah, but the reason this is OK for those distros is that they have a centralized, standard catalog. >>> When I want to install, I want to explicitly ask for it. > > Why? If you know it's already installed, do nothing. If you're not > sure, or are sure it isn't, do e.g. > > $ konqueror --version > > (assuming konqueror was available through 0install) If the konqueror executable is actually there in the PATH before being installed, that's bad. A configure script might do something like if [ -x $(which konqueror) ] ; then ... and it would be misinformed. I know, it should probably test more thoroughly, but not all such scripts do. >>> Even if the ROX model were somehow objectively better, I think not >>> providing the other model, which so many people are used to, is >>> going to be a huge adoption killer. > > Note that it's not really "the ROX model"; it's just that ROX-Defaults > is one example that happens to work that way. Noted. Do you want me to call it something else, or can we just use "the ROX model" as a shorthand? >> * Implicit installation on-demand is not going to be acceptable to many >> >> - It may not even be possible depending on the user's privileges > > If it's not possible on demand, then it wouldn't be possible with the > user choosing from a catalogue either. Not necessarily so. The user may escalate privileges for installation. Or the user that installs may be a different user from the one that executes things. >> - People want explicit control over what's installed on their systems > > Nothing gets installed without confirmation first. Okay, that helps. I'm still concerned about the pile of stub executables I get with "the ROX model." >> - The non-uniform performance characteristics (first run is an order >> of magnitude slower) could be a problem >> - The fact that you may not be able to run some "installed" software at >> all without internet connectivity (because dependencies aren't >> installed already) could be a problem > > Both apply to all possible systems, of course. Not usually. In most installation systems, "which foo" either comes back with "foo not found" or foo is fully installed and will run without internet connectivity (assuming it's a program that doesn't normally need connectivity) or paying the cost of installation. >> * People want to be able to easily use their installed software >> >> - Running software through 0launch is cumbersome >> - Using URIs to identify software to run is cumbersome >> - Creating aliases is cumbersome >> - Qualifying package names with alias:, etc., is cumbersome > > None of which are necessary with the scheme above. OK, but then there's stub executable pollution, right? And what happens when ROX adds something new to the catalog? How do I install that? >> * Having to launch python (via 0launch) just to run any installed >> executable is... disturbing. It "feels" like a highly intrusive >> design and has worrisome implications for performance. > > Yes. There's lots of potential for caching and using C for performance > if it becomes a problem. Going through a wrapper means doubling the number of processes that have to get set up and run (or does exec actually have no real cost?). How is using C going to get you around that? -- Dave Abrahams BoostPro Computing http://www.boostpro.com |