I'm afraid I don't understand. What does is mean to "depend on other packages" if and when everything (including the so-called shared or dependent package) is in the single directory for the application?
Like this:
You open the directory/uri/0install/rox.sourceforge.net/apps in your file manager (it's like a URI you'd enter into a web browser).
You see an application called Edit inside it. Edit is actually a directory, which contains everything that is part of the Edit program (but not libraries Edit uses).
When you run Edit, it loads some code from/uri/0install/rox.sourceforge.net/lib/ROX-Lib2. This directory contains all the code that is part of ROX-Lib, which Edit depends on.
Everything is downloaded and cached the first time it is accessed (files actually come in groups to reduce round-trip time and the chance that dial-up users will miss something they need once off-line).
Usually, ~/Choices/ROX-Filer/Options.xml, etc. Choices cascade (/usr/local/share/Choices,/usr/share/Choices, ~/Choices). You can change the location with CHOICESPATH.
In future, we'll probably move over to the (very similar) freedesktop.org base dir system, which defaults to ~/.config instead but is otherwise pretty-much the same.
Are you all guys seriously claiming that first
a) finding right foo for your system,
b) downloading foo,
c) knowing where it went,
d) knowing where to drag it,
e) actually dragging it
is simpler than cryptic
a) "install foo"?
[ b) enter root password and hope it doesn't mess up your system ]
a) You don't have to find the right version for your system, just run the application. It will try to access the appropriate binary and that will get cached.
b) Downloading happens automatically, just like viewing a web page through a web cache.
c) It goes in the cache directory, whose structure mirrors the URI scheme (eg/var/cache/zero-inst/gimp.org/bin/gimp). You shouldn't care though, any more that you care about the structure of squid's web cache.
d) Drag it where you want it. On your desktop, panel, start menu, etc.
e) You could just run it where it is, without creating a short-cut at all.
Talk about encouraging waste.... The article states:
The apps are all self-contained in their own directory; binaries, docs, source code and all. * * * This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial.
What happened to the idea that we wanted programmers and users to share libraries and code? To solve rather than avoid dependancy problems?
Applications are self-contained in that everything from a single package is in a single directory, rather than being spread over/usr/bin,/usr/share, etc. They can still depend on other packages.
Without Zero Install, this means that although installing an individual package is quite easy, you may then have to install dependant packages in a similar fashion. With Zero Install, you get automatic dependancy resolution and freedom from install scripts.
I'm the author of Zero Install (and much of ROX) so I'd better clear up a few points here.
The main one is that there are actually two installation systems being discussed in the article:
ROX uses application directories (bundles). That means that instead of downloading gimp.tgz and then copying the files inside it all over the place (/usr/bin,/usr/share, etc), they stay in a single directory and you access them from there. That allows drag-and-drop installing, and uninstalling by deleting the directory.
Zero Install is a caching network filesystem, where all software is available at a fixed, globally unique, location (like web pages).
ROX application directories can be made available via Zero Install. In that case, running the application is a lot like running a program from a network share (but more aggressively cached). Or, you can DnD them onto your local disk manually (without Zero Install).
You can also use Zero Install for non-ROX type applications.
Secondly, when we say that application directories are self-contained, we mean that a single.tgz download corresponds to a single installed directory. Application directories can (and do) still depend on shared libraries (possibly other application directories).
Without Zero Install, after installing an application by drag-and-drop, running it may tell you that you need to install some other library
before it will work.
With Zero Install, the application just tries to access it from its fixed location (URI) and it gets fetched.
What makes a type error "nasty"? It is not the degree to which the types are different, but the potential consequences of overlooking their difference.
Yes, that's exactly how I'd define 'nasty'.
In my view, the principal practical advantage of static type checking system (as implemented in current languages) is their ability to catch boundary conditions. Have you ever called a Python method and forgot that it might return None? Your program works fine for a while, but it will eventually trip because you forgot to test if the return value was None.
Umm. Java does the exact same thing, except it calls it Null instead of None.
It will probably just crash with an uncaught exception, but in the process may mangle or lose data. (Users tend not to like that.:)
For desktop applications, exceptions are caught
at the event loop and displayed in a dialog box. The application continues running, without losing data (in my experience) and the bug gets reported. This is usually the case with Java too, though.
You can usually classify type errors reported by the compiler into:
Errors you would have immediately spotted after the compile when you ran the code the first time.
Errors only due to the static checking system (eg, forgetting a cast), which don't affect dynamically typed languages in the first place.
Errors you would have spotted later, but which would have been just as easy to fix then as now.
Errors that would have caused you problems if the compiler had missed them.
I find type errors rarely fall into the last group.
Python is much faster, both starting and running, and seems to use less resources.
What are you smoking?! In this benchmark Java was 7 times faster than Python, and that was the 1.4 JVM, 1.5 is even better.
OK, I only read the start of the article you referenced. From the first paragraph Unfortunately, the trigonometry performance of Java 1.4.2 can only be described as dismal. It was bafflingly bad--worse even than fully interpreted Python!.
However, that's not important. We're talking about desktop applications here, not math-intensive stuff. Python is fast because it off-loads critical sections into C libraries (using map(), etc). If you compare low-level Python with Java (ie, code that doesn't use library functions), Java will win.
But, outside of Java-benchmarks, little code is actually like this. In practice (which is what people care about), Python is usually much faster.
When I start a Python application, it usually appears instantly. Java apps usually take two or three seconds just to open a window, and perform just as sluggishly when running.
Well, Python is dynamically typed for one. Dynamic typing is great for scripting languages because the language gets out of your way and the rules are laxer, so you can work quicker. It's not so great for larger or more complex pieces of code where robustness is more important than having fewer rules.
Nasty type errors are really rare, though. Normally, you've either done something stupid and the code doesn't run at all (and you have to test everything at least once), or the types are right.
Of course, some languages can be really helpful with their type checking. Haskell often gives some insight into the nature of some code by giving it a more general type. But I find Java tells you nothing you didn't already know.
Python has a few other problems. It's (a) slow even with tools like Psyco.
I've looked at the output of some code from psyco and it looked just like C (provided you stick to C-compatible types, of course). Python tends to off-load critical loops into C libraries (map(), etc). Java tends to be much slower, perhaps because most of its standard library is interpreted?
C# is a good language, but it is a far cry from Python, for example. Little, me-too babysteps is not the way to approach this. You need to be bold. Choose something with big wins and big advantages.
From the blog, Havoc writes:
My view, which will doubtless get me flamed, is that these languages [python, etc ]aren't really the right thing for writing large desktop apps such as GNOME or OO.org
I'd be really interested to hear Havoc's reasons for this comment. I've written quite a lot of (smallish) desktop apps in Python (most of the ROX ones, in fact), and it seems ideal. I've also used Java quite a lot.
Python is in many ways similar to Java:
Platform-independant bytecode.
Fully OO.
But it has differences too:
Python is much faster, both starting and running, and seems to use less resources.
Python programs seem less prone to runtime errors (NullPointerException), and are generally more solid.
Python is much quicker to write, easier to understand and easier to debug.
True, you loose static type checking. However:
You can usually run your unit tests in Python in less time than it takes just to compile your Java. So you actually get more checks in less time!
pychecker can spot many static errors.
There is much less need for ugly work arounds from limitations of the type system, so less errors in the first place.
What could be useful is - dare I suggest it - holding essential OS kernel files in ROM. Slightly awkward if you want an upgrade, but not insurmountable with socketed chips. If you use UV-erasable ROM chips, you can still burn upgrades at home but remote hacking is impossible.
...unless you have the ability to load extra stuff from disk at startup/login, at which point there is no advantage (your computer is only virus free for the first 2 seconds after power on).
(if you can design your ROM code well enough that it won't allow a remote attack to take control from it, then it didn't need to be in ROM in the first place)
OS in ROM is good for other things, though (speed, impossible-to-mess-up failsafe boot, etc).
It's the classic n00b getter. Send them a message that warns of imminent doom, promises something wonderful or what have you and try to get them to run your app. That app then does as you please.
This is the kind of vunerability that we'll basically never be able ot get rid of, barring some kind of orwellian palladium thing. Dumb users will run shit they shouldn't, and infect their boxes. You can do things to reduce the probability, but you can't eliminate it.
Palladium is only bad because it's done in hardware. You can do all the same things in software, except prevent the owner of the machine from controlling it (which is the point for the companies pushing it, of course).
For something like this, you just need to be able to run applications with restricted permissions (we already do this with Java applets, after all).
If the program tries to access your GPG private key, delete your files or send an email, the sandbox can ask the user to confirm ("This program wants to read your email address book, which is not world-readable. OK?")
This is much better than the current vague warnings users get ("This program might destroy your computer. Or it might be safe. Guess you'll just have to trust it. OK?").
I don't know what the solution is, but I do know that users, like developers, prefer the freedom of the bazaar. It seems to me users won't get this freedom unless developers are willing to give up some of theirs.
Zero Install (see sig) will do what you want. Distributions don't fight over file locations, because everything is namespaced using DNS.
Anyone can run anything in Zero Install on any distribution.
There's nothing about your system that can't be tracked down by a little intelligent scriptwork. If package managers worked like that, then you'd be able to ignore them on occasion or even break small pieces and the rest wouldn't come tumbling down.
Or you could just use
Zero Install and forget about the whole problem. Surely this is much better for end-users than either RPM or APT (and more secure, too)?
You get to share packages between distributions (no conflicts due to different install locations)
and you'll never have to reach for a package manager because you forgot to install something.
Thomas, you make some good points about some of the shortcomings of APT, but at the same time, you also set up quite a few straw men to knock APT. For example, the "Security and Stability" section criticizes the Debian model of a centralized, high-quality, well-tested software repository for not being trustworthy enough, but in the "APT is not scalable" section, you critize Debian for making it a little more difficult to be part of the repository.
OK, try this. Log in as 'guest' and run ROX-Filer. Since ROX-Filer isn't in the main repositary, you'll need to edit/etc/apt/sources.list to include a new server (which you might not trust).
But now, when you install ROX-Filer, you're running some of that code as root (not as guest),
possibly risking your whole system.
In Zero Install, you'd just log in as guest and run the filer. Nothing would run as root, and you could test it in safety. Thus, I think both claims are valid.
There's more stuff about this in the security model document, which I forgot to link to before.
"The Zero Install system makes software installation not merely easy, but unnecessary. Users run their applications directly from the Internet from the software author's pages. Caching makes this as fast as running a normal application after the first time, and allows off-line use."
No new commands to learn. All software in the world appears as part of your filesystem (/uri/...) and is cached on demand.
Secure: nothing is run as root (only as the user who runs it), and GPG signatures can be checked automatically when upgrading
Network efficient: only what is needed is fetched (no documentation or headers until you need them, then they get fetched automatically)
Faster: no searching for resources -- everything is referenced by URI; only download package indexes per-site, not for the whole distribution.
Easy to package for: just make your tree available via an HTTP server.
No need for depends/recommends/suggests: whatever is needed is fetched when you access it.
Easy to uninstall: remove anything you don't want from the cache at any time -- it will be fetched again later if needed.
Downloads too much
Are you saying that Zero-install automatically splits packages? Becuase if not you'll have the same problem, sure it might be possible to split pakckages but that doesn't mean people will do it.
Yes, it does. By default it splits by directory, but
you can subdivide further. In particular, this means that documentation is always separate from the binary, since they always go in separate directories anyway.
APT is not scaleable
True to a certain extent. More packages require more maintainers. But your comment that the available packages only represent a small fraction of available software is misleading. Yes its a small fraction of avaliable software but it comprises the vast majority of software that is useable. Who cares if john doe's dinky little text editor is available?
You might not care if it's some minor text editor that's missing, but what if it's a semi-obscure program to calculate chemical properties of some molecule? There may not be a fallback.
And it's not just really small programs missing from Debian. None of my stuff (ROX) is in there, for example. And APT's not scalable because only approved Debian developers can add it... we have to maintain our own Debian packages, but that requires editing sources.list.
A sysadmin wanting to try ROX with Debian must trust our packagers not to mess up his system. A sysadmin wanting to try something via Zero Install can just try it as a guest user, still getting the easy install and dependancy handling.
And what makes you think that john doe will go through the process of making his software available through zero install? It may be easier than creating a.deb but it is still more work than just throwing out the source.
Throwing out the source means running tar and then uploading to your webserver. Making something available via Zero Install involves running 0build and then uploading to your webserver.
Check the packager documentation.
With APT you know that the packages you are installing are at least useable.
Yes, Zero Install moves recommendations and ranking to systems like freshmeat, instead of in the packaging system. Thanks for the comments!
Looks like
Zero Install would solve those problems. (technically, it doesn't make installation easier, since it does away with installation altogether, but I don't think anyone will mind;-)
For those who haven't tried it:
"The Zero Install system removes the need to install software or libraries by running all programs from a network filesystem. The filesystem in question is the Internet as a whole, with an aggressive caching system to make it as fast as (or faster than) traditional systems such as Debian's APT repository, and to allow for offline use. It doesn't require any central authority to maintain it, and allows users to run software without needing the root password."
> This prints '50', showing that g() cannot access the variable in its enclosing scope. > It's not a closure in the true sense. > The only way I could find to make this work was to resort to global variables - gah!
That's the intended behaviour. You can make x a static variable of f:
Python has 'break' and 'continue' like C. But these only affect the innermost loop. Is there a way to break out of an enclosing loop?
Throw an exception and catch it whereever. Eg:
How can I pass a variable by reference? For example, to take a reference to a string, pass it to a function and have that function modify the string passed in.
Everything is always passed by reference. You can't modify a string because strings are immutable.
The 'lambda' keyword won't accept assignment or even sequencing inside the function body. So anonymous functions you might want to pass around can't do much beyond trivial operations.
lambda is a short-hand for def. Use that if the body isn't a simple expression:
So you try to install lynx and find perl is a dependency. wha? ok, so you install perl. You don't really have space for it on this box, but hey, maybe it will come in handy. But the perl rpm says a dozen or so perl modules are dependencies. huh? Those damn things are optional, goddammit.
Sounds like you want something like
Zero Install. It uses the globally unique nature of the Internet's DNS system to remove the need for a central package database, allowing packages to be fetched (and cached) as they're needed, so you never install anything you don't use.
There are no dependancy issues, because applications link to resources by URI, so the system always knows where to get missing files from.
And you don't need to be root to 'install' stuff, because it's just a high-speed network cache, so all users can install stuff easily and safely, and you don't get buggy running-as-root postinst scripts bombing out and messing up your system like on Debian, etc.
And April 1st was probably a bad time for me to announce this;-)
Slashdot Mirror
Sorry to spoil your arguments, but each of your starting assumptions is wrong ;-)
Just a bad idea taken to it's expreme.
If you could point me to the places on the site where you got your information, I'll try to fix them / make it clearer. Thanks.
Like this:
Everything is downloaded and cached the first time it is accessed (files actually come in groups to reduce round-trip time and the chance that dial-up users will miss something they need once off-line).
Usually, ~/Choices/ROX-Filer/Options.xml, etc. Choices cascade (/usr/local/share/Choices, /usr/share/Choices, ~/Choices). You can change the location with CHOICESPATH.
In future, we'll probably move over to the (very similar) freedesktop.org base dir system, which defaults to ~/.config instead but is otherwise pretty-much the same.
a) finding right foo for your system,
b) downloading foo,
c) knowing where it went,
d) knowing where to drag it,
e) actually dragging it
is simpler than cryptic
a) "install foo"?
[ b) enter root password and hope it doesn't mess up your system ]
a) You don't have to find the right version for your system, just run the application. It will try to access the appropriate binary and that will get cached. /var/cache/zero-inst/gimp.org/bin/gimp). You shouldn't care though, any more that you care about the structure of squid's web cache.
b) Downloading happens automatically, just like viewing a web page through a web cache.
c) It goes in the cache directory, whose structure mirrors the URI scheme (eg
d) Drag it where you want it. On your desktop, panel, start menu, etc.
e) You could just run it where it is, without creating a short-cut at all.
The apps are all self-contained in their own directory; binaries, docs, source code and all. * * * This method of partitioning applications in their own directories also allows installing multiple versions of any application trivial.
What happened to the idea that we wanted programmers and users to share libraries and code? To solve rather than avoid dependancy problems?
Applications are self-contained in that everything from a single package is in a single directory, rather than being spread over /usr/bin, /usr/share, etc. They can still depend on other packages.
Without Zero Install, this means that although installing an individual package is quite easy, you may then have to install dependant packages in a similar fashion. With Zero Install, you get automatic dependancy resolution and freedom from install scripts.
The main one is that there are actually two installation systems being discussed in the article:
ROX application directories can be made available via Zero Install. In that case, running the application is a lot like running a program from a network share (but more aggressively cached). Or, you can DnD them onto your local disk manually (without Zero Install).
You can also use Zero Install for non-ROX type applications.
Secondly, when we say that application directories are self-contained, we mean that a single .tgz download corresponds to a single installed directory. Application directories can (and do) still depend on shared libraries (possibly other application directories).
Without Zero Install, after installing an application by drag-and-drop, running it may tell you that you need to install some other library before it will work.
With Zero Install, the application just tries to access it from its fixed location (URI) and it gets fetched.
Oops, I meant pyrex, not psyco. Haven't looked at psyco yet.
Yes, that's exactly how I'd define 'nasty'.
In my view, the principal practical advantage of static type checking system (as implemented in current languages) is their ability to catch boundary conditions. Have you ever called a Python method and forgot that it might return None? Your program works fine for a while, but it will eventually trip because you forgot to test if the return value was None.
Umm. Java does the exact same thing, except it calls it Null instead of None.
It will probably just crash with an uncaught exception, but in the process may mangle or lose data. (Users tend not to like that. :)
For desktop applications, exceptions are caught at the event loop and displayed in a dialog box. The application continues running, without losing data (in my experience) and the bug gets reported. This is usually the case with Java too, though.
You can usually classify type errors reported by the compiler into:
I find type errors rarely fall into the last group.
What are you smoking?! In this benchmark Java was 7 times faster than Python, and that was the 1.4 JVM, 1.5 is even better.
OK, I only read the start of the article you referenced. From the first paragraph Unfortunately, the trigonometry performance of Java 1.4.2 can only be described as dismal. It was bafflingly bad--worse even than fully interpreted Python!.
However, that's not important. We're talking about desktop applications here, not math-intensive stuff. Python is fast because it off-loads critical sections into C libraries (using map(), etc). If you compare low-level Python with Java (ie, code that doesn't use library functions), Java will win.
But, outside of Java-benchmarks, little code is actually like this. In practice (which is what people care about), Python is usually much faster. When I start a Python application, it usually appears instantly. Java apps usually take two or three seconds just to open a window, and perform just as sluggishly when running.
Nasty type errors are really rare, though. Normally, you've either done something stupid and the code doesn't run at all (and you have to test everything at least once), or the types are right.
Of course, some languages can be really helpful with their type checking. Haskell often gives some insight into the nature of some code by giving it a more general type. But I find Java tells you nothing you didn't already know.
Python has a few other problems. It's (a) slow even with tools like Psyco.
I've looked at the output of some code from psyco and it looked just like C (provided you stick to C-compatible types, of course). Python tends to off-load critical loops into C libraries (map(), etc). Java tends to be much slower, perhaps because most of its standard library is interpreted?
From the blog, Havoc writes:
My view, which will doubtless get me flamed, is that these languages [python, etc ]aren't really the right thing for writing large desktop apps such as GNOME or OO.org
I'd be really interested to hear Havoc's reasons for this comment. I've written quite a lot of (smallish) desktop apps in Python (most of the ROX ones, in fact), and it seems ideal. I've also used Java quite a lot.
Python is in many ways similar to Java:
- Platform-independant bytecode.
- Fully OO.
But it has differences too:True, you loose static type checking. However:
Sounds like RISCOS
RISC OS is an operating system. ROM is a medium. In general, you can mix and match. See linuxbios, knoppix, etc.
And no, RISC OS is not a good solution if you want security ;-)
(if you can design your ROM code well enough that it won't allow a remote attack to take control from it, then it didn't need to be in ROM in the first place)
OS in ROM is good for other things, though (speed, impossible-to-mess-up failsafe boot, etc).
This is the kind of vunerability that we'll basically never be able ot get rid of, barring some kind of orwellian palladium thing. Dumb users will run shit they shouldn't, and infect their boxes. You can do things to reduce the probability, but you can't eliminate it.
Palladium is only bad because it's done in hardware. You can do all the same things in software, except prevent the owner of the machine from controlling it (which is the point for the companies pushing it, of course).
For something like this, you just need to be able to run applications with restricted permissions (we already do this with Java applets, after all).
If the program tries to access your GPG private key, delete your files or send an email, the sandbox can ask the user to confirm ("This program wants to read your email address book, which is not world-readable. OK?")
This is much better than the current vague warnings users get ("This program might destroy your computer. Or it might be safe. Guess you'll just have to trust it. OK?").
Zero Install (see sig) will do what you want. Distributions don't fight over file locations, because everything is namespaced using DNS. Anyone can run anything in Zero Install on any distribution.
Or you could just use Zero Install and forget about the whole problem. Surely this is much better for end-users than either RPM or APT (and more secure, too)?
You get to share packages between distributions (no conflicts due to different install locations) and you'll never have to reach for a package manager because you forgot to install something.
OK, try this. Log in as 'guest' and run ROX-Filer. Since ROX-Filer isn't in the main repositary, you'll need to edit /etc/apt/sources.list to include a new server (which you might not trust).
But now, when you install ROX-Filer, you're running some of that code as root (not as guest),
possibly risking your whole system.
In Zero Install, you'd just log in as guest and run the filer. Nothing would run as root, and you could test it in safety. Thus, I think both claims are valid.
There's more stuff about this in the security model document, which I forgot to link to before.
Thanks for the comments,
Once more people start using Zero Install these kinds of problems should go away.
There are also systems like Debian's APT, but they have some serious shortcomings for ordinary users.
Zero Install
"The Zero Install system makes software installation not merely easy, but unnecessary. Users run their applications directly from the Internet from the software author's pages. Caching makes this as fast as running a normal application after the first time, and allows off-line use."
Experimental, but give it a try. See especially the comparison with apt-get and the security model documents.
Are you saying that Zero-install automatically splits packages? Becuase if not you'll have the same problem, sure it might be possible to split pakckages but that doesn't mean people will do it.
Yes, it does. By default it splits by directory, but you can subdivide further. In particular, this means that documentation is always separate from the binary, since they always go in separate directories anyway.
APT is not scaleable
True to a certain extent. More packages require more maintainers. But your comment that the available packages only represent a small fraction of available software is misleading. Yes its a small fraction of avaliable software but it comprises the vast majority of software that is useable. Who cares if john doe's dinky little text editor is available?
You might not care if it's some minor text editor that's missing, but what if it's a semi-obscure program to calculate chemical properties of some molecule? There may not be a fallback.
And it's not just really small programs missing from Debian. None of my stuff (ROX) is in there, for example. And APT's not scalable because only approved Debian developers can add it... we have to maintain our own Debian packages, but that requires editing sources.list.
A sysadmin wanting to try ROX with Debian must trust our packagers not to mess up his system. A sysadmin wanting to try something via Zero Install can just try it as a guest user, still getting the easy install and dependancy handling.
And what makes you think that john doe will go through the process of making his software available through zero install? It may be easier than creating a .deb but it is still more work than just throwing out the source.
Throwing out the source means running tar and then uploading to your webserver. Making something available via Zero Install involves running 0build and then uploading to your webserver. Check the packager documentation.
With APT you know that the packages you are installing are at least useable.
Yes, Zero Install moves recommendations and ranking to systems like freshmeat, instead of in the packaging system. Thanks for the comments!
Heh, I've justing finished writing an article about the problems with APT (What's wrong with APT?).
For those who haven't tried it:
"The Zero Install system removes the need to install software or libraries by running all programs from a network filesystem. The filesystem in question is the Internet as a whole, with an aggressive caching system to make it as fast as (or faster than) traditional systems such as Debian's APT repository, and to allow for offline use. It doesn't require any central authority to maintain it, and allows users to run software without needing the root password."
def f():
x = 50
def g():
x = 40
g()
print x
f()
> This prints '50', showing that g() cannot access the variable in its enclosing scope.
> It's not a closure in the true sense.
> The only way I could find to make this work was to resort to global variables - gah!
That's the intended behaviour. You can make x
a static variable of f:
def f():
f.x = 50
def g():
f.x = 40
g()
print f.x
f()
If you don't want it static, create a new object
to hold it (or store it on g, etc).
Throw an exception and catch it whereever. Eg:
How can I pass a variable by reference? For example, to take a reference to a string, pass it to a function and have that function modify the string passed in.
Everything is always passed by reference. You can't modify a string because strings are immutable.
The 'lambda' keyword won't accept assignment or even sequencing inside the function body. So anonymous functions you might want to pass around can't do much beyond trivial operations.
lambda is a short-hand for def. Use that if the body isn't a simple expression:
Is there a do/while statement in Python?
Some python tutorials I wrote:
Python for BASIC programmers
Writing GTK applications in python
Sounds like you want something like Zero Install. It uses the globally unique nature of the Internet's DNS system to remove the need for a central package database, allowing packages to be fetched (and cached) as they're needed, so you never install anything you don't use.
There are no dependancy issues, because applications link to resources by URI, so the system always knows where to get missing files from.
And you don't need to be root to 'install' stuff, because it's just a high-speed network cache, so all users can install stuff easily and safely, and you don't get buggy running-as-root postinst scripts bombing out and messing up your system like on Debian, etc.
And April 1st was probably a bad time for me to announce this ;-)