Screenshot instructions:
Windows
Mac
Red Hat Linux
Ubuntu
Click URL instructions:
Right-click on ad, choose "Copy Link", then paste here →
(This may not be possible with some types of ads)
|
From: Andrew Flegg <andrew@bl...> - 2004-05-20 08:57:07
|
Hi,
I've been thinking about the fact that relocatable AppDirs and shared
libraries packaged as AppDirs are fairly irreconcilable, without hacks
such as "findrox.py" etc.
This'll be a big problem for something like Rox OS - GoboLinux solved it
by still enforcing fixed locations, but we want AppDirs to be
relocatable (and I don't see why this can't be the case for everything).
Unfortunately without compatibility filesystems like GoboLinux, ROX
applications are tied to the traditional Unix filesystem, by virtue of
the fact that apps are increasingly dependent on finding ROX-*Lib in one
of several predefined locations.
There's also the issue of if things like terminal emulators are packaged
as AppDirs, which do you call? How do you know what an AppDir provides?
Half of this is solved by Stephen Watson's new <Dependencies> section in
AppInfo.xml, but alongside that could be a "<Provides>" sections, a la
Debian's similarly named field. Then you could have:
<Dependencies>
<Generic><Name>x-terminal-emulator</Name></Generic>
</Dependencies>
(for example).
The larger problem, though, boils down to the fact that RISC OS got
around this with !AppDir.!Boot files setting system variables. Apart
from the security implications, this won't work in a UNIX process model,
so we need to look at something else.
Suggestion:
~~~~~~~~~~~
* The Filer notes, at a minimum, the location of every AppDir it sees
(perhaps permanently, perhaps solely for the running copy).
This could be into a text file or, even better, into memory available
through a SOAP call.
Obviously there'd need to be a way for ROX-based OSes to `seed' the
table with either all AppDirs in a specific directory, or just
specific locations.
* findrox.py can then query the Filer for AppDirs called "ROX-Lib",
perhaps even supporting minimum versions or even based off the
"<Provides>" sections depending on how much information we decide
the Filer keeps.
For example, findrox.py could do something like:
1) Query the Filer for known copies of "ROX-Lib"
2) Check still present and version numbers (latter only if can't be
done in SOAP call)
3) If none valid, start checking known locations (including
ZeroInstall)
Then, for shared C libraries:
4) Pass a value for LD_LIBRARY_PATH back to be set in AppRun.
Thoughts?
Cheers,
Andrew
--
Andrew Flegg -- mailto:andrew@... | http://www.bleb.org/
|
|
From: Thomas Leonard <tal00r@ec...> - 2004-05-20 09:31:31
|
On Thu, May 20, 2004 at 08:47:18AM -0000, Andrew Flegg wrote:
> Hi,
>
> I've been thinking about the fact that relocatable AppDirs and shared
> libraries packaged as AppDirs are fairly irreconcilable, without hacks
> such as "findrox.py" etc.
You need some code to put up a dialog box if the library isn't installed,
check the version, etc. It's hardly a 'hack'.
> Unfortunately without compatibility filesystems like GoboLinux, ROX
> applications are tied to the traditional Unix filesystem, by virtue of
> the fact that apps are increasingly dependent on finding ROX-*Lib in one
> of several predefined locations.
One of which is at rox.sourceforge.net. Unless you want to let users
redefine the layout of the Internet itself, that shouldn't be a problem.
("predefined locations" is "locations in LIBDIRPATH", of course, so
GoboLinux is free to put it whereever it likes)
> There's also the issue of if things like terminal emulators are packaged
> as AppDirs, which do you call? How do you know what an AppDir provides?
What if terminal emulators *aren't* packaged as appdirs? Then which do you
call?
(answer: use the configured one, or a default if none is configured)
> The larger problem, though, boils down to the fact that RISC OS got
> around this with !AppDir.!Boot files setting system variables. Apart
> from the security implications, this won't work in a UNIX process model,
> so we need to look at something else.
>
> Suggestion:
> ~~~~~~~~~~~
>
> * The Filer notes, at a minimum, the location of every AppDir it sees
> (perhaps permanently, perhaps solely for the running copy).
>
> * findrox.py can then query the Filer for AppDirs called "ROX-Lib",
> perhaps even supporting minimum versions or even based off the
> "<Provides>" sections depending on how much information we decide
> the Filer keeps.
...thus reintroducing the original security problems. If the user didn't
*run* the application, you can't trust it. Just looking at it isn't
enough.
I don't really see the problem here. If the user does nothing, a correct
version of ROX-Lib is fetched from rox.sourceforge.net. If the user wishes
to run a different copy (eg, they have modified ROX-Lib) then they either
set some environment variables to point to their copy, or use 0divert to
redirect all access to ROX-Lib to their modified version.
--
Thomas Leonard http://rox.sourceforge.net
tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1
|
|
From: Andrew Flegg <andrew@bl...> - 2004-05-20 11:27:07
|
On 2004-05-20, Thomas Leonard <tal00r@...> wrote:
> On Thu, May 20, 2004 at 08:47:18AM -0000, Andrew Flegg wrote:
>>
>> I've been thinking about the fact that relocatable AppDirs and shared
>> libraries packaged as AppDirs are fairly irreconcilable, without hacks
>> such as "findrox.py" etc.
>
> You need some code to put up a dialog box if the library isn't installed,
> check the version, etc. It's hardly a 'hack'.
No, indeed - a poor choice of words. Of course, something like "findrox.py" is
needed, however the hardcoding of paths (even LIBDIRPATH) is.
>> the fact that apps are increasingly dependent on finding ROX-*Lib in one
>> of several predefined locations.
>
> One of which is at rox.sourceforge.net. Unless you want to let users
> redefine the layout of the Internet itself, that shouldn't be a problem.
Is ZeroInstall a requirement for ROX, though? (Yes, it's great, but
ZeroInstall actually ends up reneguing on several of the key features of
AppDirs (including the user being able to put them where they like,
self-compiling on different platforms[1] etc.)
> ("predefined locations" is "locations in LIBDIRPATH", of course, so
> GoboLinux is free to put it whereever it likes)
(Disclaimer: don't like GoboLinux, as again the locations are fixed for
/everything/. Yes, some locations need to be fixed for an OS to work,
but one of the *really* good things about AppDirs, IMHO, are the
relocatablity).
However, who sets LIBDIRPATH if shared libraries can be anywhere on the
system? Admittedly, one of my concerns was that Rox OS, with its totally
non-standard filesystem, wouldn't be able to run current AppDirs, but
that's alleviated if LIBDIRPATH is set.
>> There's also the issue of if things like terminal emulators are packaged
>> as AppDirs, which do you call? How do you know what an AppDir provides?
>
> What if terminal emulators *aren't* packaged as appdirs? Then which do you
> call?
But I'm imaginging a future here where any program which requires
support files (eg. not things like sed etc.) are packaged as an AppDir
so they can be relocated and self-compiled.
> (answer: use the configured one, or a default if none is configured)
Any thoughts on how this configuration could work? Debian uses its
/etc/alternatives, but `update-alternatives' isn't very user friendly
IME.
[note which AppDirs have been seen]
>
> ...thus reintroducing the original security problems. If the user didn't
> *run* the application, you can't trust it. Just looking at it isn't
> enough.
Hmm, true. Perhaps some form of lowest common denominator security
model, though (which already exists in ROX in terms of recognising
things as AppDirs): if the AppDir containing the shared lib is owned by
the current user, or some set of trusted users (eg. root) then it's safe
to run.
For non ZeroInstall users, being able to just download ROX-*Lib and some
dependent application, unpack them to some temporary directory and have
the app work without having to fiddle with LIBDIRPATH or putting the lib
AppDir in some "magic" directory, is a big plus point (IMHO).
> I don't really see the problem here. If the user does nothing, a correct
> version of ROX-Lib is fetched from rox.sourceforge.net. If the user wishes
> to run a different copy (eg, they have modified ROX-Lib) then they either
> set some environment variables to point to their copy, or use 0divert to
> redirect all access to ROX-Lib to their modified version.
Perhaps. But again this comes back to a Zero Install almost being an
unstated requirement, which'd be fine - if actually stated ;-)
However, that then leads me on to the various things in Zero Install
which should be looked at:
o [1] compiling different platforms - if I've ZeroInstalled a ROX
AppDir which compiles on Solaris, AIX, Linux/x86 etc. but I can only
compile it on Linux/x86, what does a user of ZeroInstall do on
the non-Linux/x86 OS (even if ZeroInstall never makes it to Solaris,
there's still Linux/PPC, Linux/ARM etc.)? Do they have to copy it
out to writable storage to compile it? (I don't know, don't have
any non-Linux/x86 systems to test on)
o The original concern I had with proxies turns out to be valid in my
usage pattern: proxy needed at work, proxy not needed at home. I
solve this for ROX and my desktop as a whole with a script in my
.xsession which checks an interface's IP for being in the work range
or not, and happily exports http_proxy.
However, /etc/init.d/0install is started at boot, and so'll act on
the settings of /etc/wgetrc. My user ID, obviously, can't edit that
when I log in.
I suppose the sensible thing would be to modify /etc/init.d/0install
to either a) allow calling of an external script to set http_proxy
etc., or b) allow some form of intelligence some other way as to
whether or not a proxy needs to be used by wget.
Cheers,
Andrew
PS. Sorry, this post is probably long and rambly. Shouldn't have resumed
it after a gap for an hour long meeting! ;-)
--
Andrew Flegg -- mailto:andrew@... | http://www.bleb.org/
|
|
From: Thomas Leonard <tal00r@ec...> - 2004-05-20 12:05:19
|
On Thu, May 20, 2004 at 11:23:02AM -0000, Andrew Flegg wrote: > On 2004-05-20, Thomas Leonard <tal00r@...> wrote: > > On Thu, May 20, 2004 at 08:47:18AM -0000, Andrew Flegg wrote: [...] > >> the fact that apps are increasingly dependent on finding ROX-*Lib in one > >> of several predefined locations. > > > > One of which is at rox.sourceforge.net. Unless you want to let users > > redefine the layout of the Internet itself, that shouldn't be a problem. > > Is ZeroInstall a requirement for ROX, though? (Yes, it's great, but > ZeroInstall actually ends up reneguing on several of the key features of > AppDirs (including the user being able to put them where they like, > self-compiling on different platforms[1] etc.) Well I run Zero Install, but I also run the CVS version of ROX-Lib from my home directory, and I even compile my own version of the filer. You're right that self-compiling from zero install doesn't work automatically at the moment for ROX-Filer. You have to drag the filer to your home directory, click on it, and then use 0divert to redirect to your new copy. However, that's just a limitation of the current build process. Edit the filer to build in a tmp directory and store the binary in ~/.cache, and it will work fine just by clicking on it. For relocation, app dirs have only ever allowed you to move directories that you own. Otherwise, you have to copy. Having Edit in Zero Install is no different from having Edit in /usr/local/apps in this regard: as a user, you can't modify either of them, but you can make a copy in your home directory and modify that. > However, who sets LIBDIRPATH if shared libraries can be anywhere on the > system? Whoever trusts the new location. Remember that normally, you don't need to set it at all because most the libraries you use will be unmodified (ie, running directly from /uri/0install). If you do modify a library, then you have to set some value somewhere telling applications to use the modified version. This is just configuration, like any other. It can be done with environment variables, or with some other system (gconf, etc). > >> There's also the issue of if things like terminal emulators are packaged > >> as AppDirs, which do you call? How do you know what an AppDir provides? > > > > What if terminal emulators *aren't* packaged as appdirs? Then which do you > > call? > > But I'm imaginging a future here where any program which requires > support files (eg. not things like sed etc.) are packaged as an AppDir > so they can be relocated and self-compiled. But this has nothing to do with application directories. The choice of xterm vs gnome-terminal is the same whatever technology you use. > > (answer: use the configured one, or a default if none is configured) > > Any thoughts on how this configuration could work? Debian uses its > /etc/alternatives, but `update-alternatives' isn't very user friendly > IME. See http://www.freedesktop.org/Standards/config-spec > [note which AppDirs have been seen] > > > > ...thus reintroducing the original security problems. If the user didn't > > *run* the application, you can't trust it. Just looking at it isn't > > enough. > > Hmm, true. Perhaps some form of lowest common denominator security > model, though (which already exists in ROX in terms of recognising > things as AppDirs): if the AppDir containing the shared lib is owned by > the current user, or some set of trusted users (eg. root) then it's safe > to run. No. Then, if you extract an archive someone gave you, the desktop will instantly trust everything inside it because you now own it (RISC OS went even further by actually running all the !Boot files at this point ;-) If you want to run a modified version of a library, just click on it and it can make itself the default. Until then, it shouldn't be assumed that the user wants it (even if it is 'safe'; it might be the wrong version). Otherwise, we'll get in to the RISC OS problem of applications fighting over who handles what. > > I don't really see the problem here. If the user does nothing, a correct > > version of ROX-Lib is fetched from rox.sourceforge.net. If the user wishes > > to run a different copy (eg, they have modified ROX-Lib) then they either > > set some environment variables to point to their copy, or use 0divert to > > redirect all access to ROX-Lib to their modified version. > > Perhaps. But again this comes back to a Zero Install almost being an > unstated requirement, which'd be fine - if actually stated ;-) Well, you're talking about new systems. For backwards compatibility, of course we support other systems. But Zero Install is designed to fix exactly the problems you're describing, so why not use it? > However, that then leads me on to the various things in Zero Install > which should be looked at: [ compiling; easily fixed ] > o The original concern I had with proxies turns out to be valid in my > usage pattern: proxy needed at work, proxy not needed at home. I > solve this for ROX and my desktop as a whole with a script in my > .xsession which checks an interface's IP for being in the work range > or not, and happily exports http_proxy. > However, /etc/init.d/0install is started at boot, and so'll act on > the settings of /etc/wgetrc. My user ID, obviously, can't edit that > when I log in. Zero Install may be started at boot (you can restart it safely at any time, BTW), but it spawns a new copy of wget for each request. Therefore, you don't need to restart it to change the setup. The easy solution to your problem is to get whatever brings the network up and down (which must run as root) to modify wgetrc (or some more general location) at the same time. It really should do this anyway, or other programs (wwwoffled, etc) will stop working too. You could also make a wrapper script for wget that tests the network state. Changing an environment variable to reflect the new network situation is a hack, and will cause other problems, including: you have to logout when changing the settings, other users don't get the updates, daemon processes stop working, etc. Again, this is probably something you want to store in a general configuration system. -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
|
From: Andrew Flegg <andrew@bl...> - 2004-05-21 09:57:11
|
On 2004-05-20, Thomas Leonard <tal00r@...> wrote: > [snip] > > You're right that self-compiling from zero install doesn't work > automatically at the moment for ROX-Filer. You have to drag the filer to > your home directory, click on it, and then use 0divert to redirect to your > new copy. Is there a need for someone to write a nice GUI for 0divert? (Having never used it myself), or even Filer integration somehow? > For relocation, app dirs have only ever allowed you to move directories > that you own. Otherwise, you have to copy. Having Edit in Zero Install is > no different from having Edit in /usr/local/apps in this regard: as a > user, you can't modify either of them, but you can make a copy in your > home directory and modify that. Yes, of course. >> > (answer: use the configured one, or a default if none is configured) >> >> Any thoughts on how this configuration could work? Debian uses its >> /etc/alternatives, but `update-alternatives' isn't very user friendly >> IME. > > See http://www.freedesktop.org/Standards/config-spec Interesting. > If you want to run a modified version of a library, just click on it and > it can make itself the default. Until then, it shouldn't be assumed that > the user wants it (even if it is 'safe'; it might be the wrong version). How? Whether or not the Filer does this automatically or provides a way for AppDirs to register themselves as "seen" (or it happens automatically upon running, either way...) it still doesn't bypass the problem that unless the app does something evil like persistently make itself default by some form of symlink in a fixed location (eg. ~/lib) there's no way for an app using that library to know that there's a new default it should use. > Otherwise, we'll get in to the RISC OS problem of applications fighting > over who handles what. True. But there are some hard issues to solve here, I don't think (in the long term) they can be solved by saying "the user has to configure whatever they want". Admittedly, distributions should be configuring defaults, which may point into ZeroInstall, however if AppDirs are a suitable replacement for RPMs, debs etc. then we can't rely on `apt-get install some-rox-app' modifying the appropriate files for shared mime info. Also, having code in each app to provide the user the option of sticking some symlinks in CHOICESPATH/MIME-Types/ seems like a redundant duplication of code. > Well, you're talking about new systems. For backwards compatibility, of > course we support other systems. But Zero Install is designed to fix > exactly the problems you're describing, so why not use it? True. Perhaps I'm not thinking fourth dimensionally^W^WZeroInstall enough. > The easy solution to your problem is to get whatever brings the network up > and down (which must run as root) to modify wgetrc (or some more general > location) at the same time. It really should do this anyway, or other > programs (wwwoffled, etc) will stop working too. You could also make a > wrapper script for wget that tests the network state. True. I think I might have to start writing a ROX network configuration tool as there doesn't seem a way of configuring in any of the existing ones "when this network comes up, if the IP address matches "9.*" then set the system proxy to xxx, run this script, make the toast, etc." > Changing an environment variable to reflect the new network situation is a > hack, and will cause other problems, including: you have to logout when > changing the settings, other users don't get the updates, daemon processes > stop working, etc. However since wget and other tools such as lwp-request (in fact LWP::*.pm) don't support the (seemingly) hypothetical fd.o config spec (yet), but do support the (standard) http_proxy variable it is currently the best way. The rest of the problems aren't a concern (in my usage) for my laptop. It gets shut down between home and work, I'm the only user etc. > Again, this is probably something you want to store in a general > configuration system. Agreed. But then everything'll need wrappering, or porting, to use it. Not that that's a bad thing, just that it needs doing :) Cheers, Andrew -- Andrew Flegg -- mailto:andrew@... | http://www.bleb.org/ |
|
From: Thomas Leonard <tal00r@ec...> - 2004-05-21 11:34:28
|
On Fri, May 21, 2004 at 09:48:51AM -0000, Andrew Flegg wrote: > On 2004-05-20, Thomas Leonard <tal00r@...> wrote: > > [Andrew Flegg wrote:] [...] > > If you want to run a modified version of a library, just click on it and > > it can make itself the default. Until then, it shouldn't be assumed that > > the user wants it (even if it is 'safe'; it might be the wrong version). > > How? Whether or not the Filer does this automatically or provides a way > for AppDirs to register themselves as "seen" (or it happens > automatically upon running, either way...) it still doesn't bypass the > problem that unless the app does something evil like persistently make > itself default by some form of symlink in a fixed location (eg. ~/lib) > there's no way for an app using that library to know that there's a new > default it should use. Whenever you have a shared resource, you need *some* well-known place to store its location. Since choosing to use a non-default version of a library is configuration, I suggest storing the new location in the configuration system. (it seems like configuration to me: it should only be changed at the user's request, and it's a per-user setting) > > Otherwise, we'll get in to the RISC OS problem of applications fighting > > over who handles what. > > True. But there are some hard issues to solve here, I don't think (in > the long term) they can be solved by saying "the user has to configure > whatever they want". Why not? Remember that we're talking about 'users' who are running their own modified versions of libraries. This isn't something any normal user is going to be interested in. But if you want to run Stephen's modified version of ROX-Lib (for example) instead of the official one, you should have to do something (eg, click on it) for it to become the default. > however if AppDirs are a suitable replacement for RPMs, debs etc. then > we can't rely on `apt-get install some-rox-app' modifying the > appropriate files for shared mime info. apt-get doesn't allow relocation anyway, though. You can't just start moving around appdirs installed by apt-get. As with zero-install, you need to copy them and set some configuration setting to point to the new one. > Also, having code in each app to provide the user the option of sticking > some symlinks in CHOICESPATH/MIME-Types/ seems like a redundant > duplication of code. ... which is why the code is in ROX-Lib. > > Well, you're talking about new systems. For backwards compatibility, of > > course we support other systems. But Zero Install is designed to fix > > exactly the problems you're describing, so why not use it? > > True. Perhaps I'm not thinking fourth dimensionally^W^WZeroInstall > enough. Try to think of programs as global resources, like webpages. You can view them at their fixed location (http://...) or make a local copy and modify that. [...] > > Changing an environment variable to reflect the new network situation is a > > hack, and will cause other problems, including: you have to logout when > > changing the settings, other users don't get the updates, daemon processes > > stop working, etc. > > However since wget and other tools such as lwp-request (in fact > LWP::*.pm) don't support the (seemingly) hypothetical fd.o config spec > (yet), but do support the (standard) http_proxy variable it is currently > the best way. Put a 'wget' wrapper in PATH: #!/bin/sh http_proxy=`cat /etc/network/http_proxy` wget-real "$@" When fd.o config becomes available, that changes to something like: http_proxy=`fdo-config get /network/http_proxy` wget-real "$@" -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
|
From: Thomas Leonard <tal00r@ec...> - 2004-05-22 14:50:55
|
On Thu, May 20, 2004 at 01:05:05PM +0100, Thomas Leonard wrote: [...] > However, that's just a limitation of the current build process. Edit the > filer to build in a tmp directory and store the binary in ~/.cache, and it > will work fine just by clicking on it. The CVS version of the filer now builds in ~/build/ROX-Filer. You'll probably need to remove all the src/*.o files if you're upgrading with CVS. The binary produced still goes in the same place at the moment. -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
|
From: Andrew Flegg <andrew@bl...> - 2004-05-21 12:27:08
|
On 2004-05-21, Thomas Leonard <tal00r@...> wrote:
> [...]
>> > If you want to run a modified version of a library, just click on it and
>> > it can make itself the default. Until then, it shouldn't be assumed that
>> > the user wants it (even if it is 'safe'; it might be the wrong version).
Right, I definitely agree on this.
> Whenever you have a shared resource, you need *some* well-known place to
> store its location. Since choosing to use a non-default version of a
> library is configuration, I suggest storing the new location in the
> configuration system.
>
> (it seems like configuration to me: it should only be changed at the
> user's request, and it's a per-user setting)
But if running a new copy of the shared resource installs it as the
preferred resource, this should be only for the current session (the
user can take some permanent action, eg. symlink in Autostart if it's
needed to be permanent). Will the fd.o config spec allow temporary
settings like that?
>> True. But there are some hard issues to solve here, I don't think (in
>> the long term) they can be solved by saying "the user has to configure
>> whatever they want".
>
> Why not? Remember that we're talking about 'users' who are running their
> own modified versions of libraries.
Sorry, I was talking about the more general case about AppDirs handling
file types etc. Eg. my "Thwimble" app which handles ".thw" files
(mime-type application/x-thwimble).
>> however if AppDirs are a suitable replacement for RPMs, debs etc. then
>> we can't rely on `apt-get install some-rox-app' modifying the
>> appropriate files for shared mime info.
>
> apt-get doesn't allow relocation anyway, though. You can't just start
> moving around appdirs installed by apt-get. As with zero-install, you need
> to copy them and set some configuration setting to point to the new one.
No, you miss my point: if AppDirs are still to be defined as a possible
replacement for apt-get (whether in ZeroInstall or otherwise) there
needs to be an improvement in the way that they are registered (perhaps
albeit temporarily) for running particular files.
If you use a larger package manager (eg. apt-get) then as part of the
install root can (theoretically) modify the appropriate locations.
>> Also, having code in each app to provide the user the option of sticking
>> some symlinks in CHOICESPATH/MIME-Types/ seems like a redundant
>> duplication of code.
>
> ... which is why the code is in ROX-Lib.
OK, what about non-Python apps? What about UI consistency? The latter is
a particularly important point which, I don't think, is covered in the
style guide (for uninstall - the style guide assumes MIME handlers and
icons will be installed during first run if not otherwise present)
>> True. Perhaps I'm not thinking fourth dimensionally^W^WZeroInstall
>> enough.
>
> Try to think of programs as global resources, like webpages. You can view
> them at their fixed location (http://...) or make a local copy and modify
> that.
That's a good analogy. Hasn't helped shift my mental model from the
traditional filesystem hierarchy though. I'm just trying to imagine how
a whole OS would *neatly* work through ZeroInstall...
(after all, I've got the disk space on a nice fat, reliable pipe...)
>> However since wget and other tools such as lwp-request (in fact
>> LWP::*.pm) don't support the (seemingly) hypothetical fd.o config spec
>> (yet), but do support the (standard) http_proxy variable it is currently
>> the best way.
>
> Put a 'wget' wrapper in PATH:
Yep, that's what I was suggesting. Of course, there still needs to be
something nice written for the user to configure what/how that gets set
to (obviously us power users can just faff about in
/etc/network/interfaces).
Cheers,
Andrew
PS. I've just had a thought on repackaging big, complex things like
(say) XFree86 as an AppDir: there are bound to be issues with
compiling it with a relative path. Would a file system be useful
where you could do something like:
APP_DIR="/home/andrew/tmp/code/XFree86"
ls -l /APP_DIR/share/rgb.txt
ie. any file accesses to /APP_DIR get mapped into $APP_DIR for the
current process.
--
Andrew Flegg -- mailto:andrew@... | http://www.bleb.org/
|
|
From: Thomas Leonard <tal00r@ec...> - 2004-05-21 13:01:37
|
On Fri, May 21, 2004 at 12:15:40PM -0000, Andrew Flegg wrote: > On 2004-05-21, Thomas Leonard <tal00r@...> wrote: [...] > > Whenever you have a shared resource, you need *some* well-known place to > > store its location. Since choosing to use a non-default version of a > > library is configuration, I suggest storing the new location in the > > configuration system. > > > > (it seems like configuration to me: it should only be changed at the > > user's request, and it's a per-user setting) > > But if running a new copy of the shared resource installs it as the > preferred resource, this should be only for the current session (the > user can take some permanent action, eg. symlink in Autostart if it's > needed to be permanent). I'm assuming that there will be some kind of confirmation box, although once you've run a program it can do anything it likes, of course. > Will the fd.o config spec allow temporary settings like that? I'm hoping it will be just an interface, so you can do whatever you like. However, temporary settings are usually cause more trouble (confusion) than they save (the filer used to have Save and OK buttons in the options box, but no one complained when they went). [...] > No, you miss my point: if AppDirs are still to be defined as a possible > replacement for apt-get (whether in ZeroInstall or otherwise) there > needs to be an improvement in the way that they are registered (perhaps > albeit temporarily) for running particular files. Take a look at VideoThumbnail (www.kerofin.demon.co.uk/apps/VideoThumbnail). When you click on it, it pops up a list of types. You unselect any you don't want it to handle and click OK. What's the problem? Archive could do the same thing, but the Zero Install version of ROX-Session associates all the archive types with Archive by default anyway. > If you use a larger package manager (eg. apt-get) then as part of the > install root can (theoretically) modify the appropriate locations. If you're using apt-get, it will create the appropriate symlinks in /usr/shared/Choices. Again, this is configuration and apt already handles it. > >> Also, having code in each app to provide the user the option of sticking > >> some symlinks in CHOICESPATH/MIME-Types/ seems like a redundant > >> duplication of code. > > > > ... which is why the code is in ROX-Lib. > > OK, what about non-Python apps? What about UI consistency? Why not use ROX-Lib? It's only a few lines of code to use it and it's a requirement for ROX anyway. There's no law that you can only use a single language in one program (ROX-Session mixes C and Python for example). For operations which don't require tight integration with the main program, this is fine. > >> True. Perhaps I'm not thinking fourth dimensionally^W^WZeroInstall > >> enough. > > > > Try to think of programs as global resources, like webpages. You can view > > them at their fixed location (http://...) or make a local copy and modify > > that. > > That's a good analogy. Hasn't helped shift my mental model from the > traditional filesystem hierarchy though. I'm just trying to imagine how > a whole OS would *neatly* work through ZeroInstall... Assuming you split it into 'core' and 'applications', it works fine (with 'core' being grub + Linux + XFree86 + glibc + a few other low-level bits; basically everything you need to set up networking). > PS. I've just had a thought on repackaging big, complex things like > (say) XFree86 as an AppDir: there are bound to be issues with > compiling it with a relative path. Would a file system be useful > where you could do something like: > > APP_DIR="/home/andrew/tmp/code/XFree86" > ls -l /APP_DIR/share/rgb.txt > > ie. any file accesses to /APP_DIR get mapped into $APP_DIR for the > current process. There's a LinkFS somewhere that does that (check the zero install archives; it was mentioned there). You probably also want to read the handy "Guide to Making Relocatable Applications": http://autopackage.org/docs/binreloc/ However, XFree86 is a poor example because it needs to run as root, so users won't be making copies of it to run locally, or switching to another implementation elsewhere on the net (which is a shame, I'm sure X developement would speed up no end if it was user-level). -- Thomas Leonard http://rox.sourceforge.net tal00r at ecs.soton.ac.uk tal197 at users.sourceforge.net GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1 |
|
From: Stephen Watson <stephen@ke...> - 2004-05-22 13:06:25
|
Andrew Flegg <andrew@...> wrote: > On 2004-05-21, Thomas Leonard <tal00r@...> wrote: > >> Also, having code in each app to provide the user the option of sticking > >> some symlinks in CHOICESPATH/MIME-Types/ seems like a redundant > >> duplication of code. > > > > ... which is why the code is in ROX-Lib. > > OK, what about non-Python apps? What about UI consistency? The latter is > a particularly important point which, I don't think, is covered in the > style guide (for uninstall - the style guide assumes MIME handlers and > icons will be installed during first run if not otherwise present) I'm aiming to put a mime_handler section into the next release of ROX-CLib and I'm currently working on an AppInfo.xml parser which it will need. The UI should be consistent (modulo C/Python differences) because I also wrote the version in ROX-Lib. -- Stephen Watson http://www.kerofin.demon.co.uk/ If you read this on a mailing list, send any reply back to the list and not to me. Not even CC. |
|
From: Stephen Watson <swatson@ue...> - 2004-05-26 07:59:37
|
In message <20040522145009.GA27367@...>
Thomas Leonard <tal00r@...> scribbled:
> The CVS version of the filer now builds in ~/build/ROX-Filer. You'll
> probably need to remove all the src/*.o files if you're upgrading with
> CVS. The binary produced still goes in the same place at the moment.
I needed to fiddle the CFLAGS to have both -I. and -I${srcdir} on Solaris,
otherwise the include files weren't being found. This didn't happen under
Linux. Is this a gcc problem?
(I also had to change all ~ to $HOME, that's already in CVS).
--
Stephen Watson Physicist
Ultra Electronics Ltd - Signature Management Systems (UESMS)
Tel: +44 (0)1543 878888 (switchboard) Fax: +44 (0)1543 878249
Email: watson@...
|
|
From: Stephen Watson <stephen@ke...> - 2004-05-26 17:53:17
|
Stephen Watson <swatson@...> wrote:
> In message <20040522145009.GA27367@...>
> Thomas Leonard <tal00r@...> scribbled:
>
> > The CVS version of the filer now builds in ~/build/ROX-Filer. You'll
> > probably need to remove all the src/*.o files if you're upgrading with
> > CVS. The binary produced still goes in the same place at the moment.
>
> I needed to fiddle the CFLAGS to have both -I. and -I${srcdir} on Solaris,
> otherwise the include files weren't being found. This didn't happen under
> Linux.
There was a ROX-Filer/src/config.h left around from the old build system.
Under the new system it is created in ~/build/ROX-Filer/config.h and not
found during compilation.
--
Stephen Watson http://www.kerofin.demon.co.uk/
If you read this on a mailing list, send any reply back to the list and not
to me. Not even CC.
|