converted to 1.6 markup
|Deletions are marked like this.||Additions are marked like this.|
|Line 37:||Line 37:|
|There is a app which does this it is called [http://zero-install.sourceforge.net/ Zero Install]||There is a app which does this it is called [[http://zero-install.sourceforge.net/|Zero Install]]|
The idea is:
:install icons and links in the Debian "start" menu for all of the thousands of world-wide available debian packages. (likely neccessitating a rethinking/reorganization of the hierarchy - for instance: adding more sub categories to apps/net (like 'chat', 'web browsers', 'security auditing', 'tools' etc.).
:none of the applications will actually be installed until the user attempts to use them. the link will actually invoke dpkg to bring the application onto the local machine, replace the link to point to the now installed app, then launch the application (hopefully with little or no user interaction).
:the package will remain on the machine until UninstallOnExpiry.
<b>2003/04/23 11:06 UTC (via web):</b>
The problem is that it will bring lots of informations on the user's computer, thus using more disk space than otherwise. The advantage of a basic Debian GNU/Linux system is the small amount of space it uses, and this quality is lost with such a system.
I think there is another way to achieve the same result, though. I realize that your solution doesn't imply to REALLY install the menu entries. So, imagine a special menu entry which is dynamically composed ONLY when the user goes in it, through some kind of temporary data. I'll take the example of the "Debian" submenus which appears in the KDE's "start" menu. If we create a submenu of this kind in evey submenu like "Office", "Development", "Graphics", ... and if this submenu is in fact empty, but calls a program which reads the dpkg databases to fill it dynamically, then:
- when apt-get update'ing, the menus won't have to be rebuilt (not processing time lost)
- this won't use more disk space for this special functionnality beside the space of this small program
- if the name of the submenu is something clear like "installable", the user WILL KNOW that the package has to be installed (he won't be wondering why it is so slow to start, or why it's internet connection as reached the maximum amount of download !)
- it avoid network/internet access issues (network link down, Debian CD-ROM lost or lent)
- it implies modifications to the Kicker (and probably future Slicker) main menu, as well as for the Gnome-panel main menu.
Finally, the idea was very interesting ! <i>-- Nolard Michel</i>
If there would be a really well-structured install tool with the packages organized in a sufficiently large tree and allowing for one package to be in several places life would be a lot easier.
There is a windows tool called netinstall for this menu oriented install on demand stuff. My experience with it is, that i normally call the installer program and not use the menu, because that way i have more control.
The administrator should be able to configure install on demand rather widely down to package base. This would sensibly be done in the install tool. Also, the whole feature might or might not be installed: This suggests a plugin for the install tool.
All in all a lot of work.
To much stuff under the Debian Start Menu. Would only make it hard to find what you want. Sometimes to much choice can be a confuseing thing for a person. I say do this but have a switch to turn it off and make all the non-installed things go away only leaving the installed apps.
I don't think there is a problem with space the info should be in the apt cache already.
There is a app which does this it is called Zero Install
I can see two problems with zero install.
1) The user can install from all over the internet so the is not a central QA check.
2) The user could chose to use a old app with a known root exploit to get root access.
Using apt-get trough a deamon could help on both problems.
1) Having a trusted party like Debian provide a list of recommended Zero Install sites would be very useful, as would having Debian host their QA'd versions of particularly poorly packaged software themselves so other Zero Install users could access them. Then, everyone could use Debian's patched packages, not just full Debian users, as is the case now.
2) Zero Install never runs any of the downloaded code itself, it just makes it available to users to run themselves, so there's no (additional) risk of root exploits.
Thomas Leonard (Debian user and Zero Install author).