Discussion:
Autopackage Vs Zero Install
Pablo Garralda
2009-07-28 20:33:23 UTC
Permalink
Hi everybody,
Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In its
site, there is a table comparing several options, including Zero install and
Autopackage among others. Of course, According to its page, Zero Install
rocks. ;)

Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?

Thanks in advance.
Pablo.
Scott Pakin
2009-07-28 21:10:37 UTC
Permalink
Post by Pablo Garralda
Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In
its site, there is a table comparing several options, including Zero
install and Autopackage among others. Of course, According to its page,
Zero Install rocks. ;)
Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?
If I recall correctly, the two approaches are in fact compatible. You
can create an Autopackage that handles distribution independence and
other portability concerns then use Zero Install to keep track of
whether a new version of your package is available (using version
numbers and hashes), download and install into Zero Install space if
necessary, and run the top-level executable from there.

-- Scott

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/***@public.gmane.org
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/***@public.gmane.org
Matthew Tedder
2009-07-28 22:01:49 UTC
Permalink
I think "autopackage" is a far cooler name that "zero install". I mean,
while their name might sound trendy and all, the autopackage name is
descriptive and thus should live their name... In the end, user's of their
system will just think of Coca Cola Zero.

Matthew
Post by Scott Pakin
Post by Pablo Garralda
Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In
its site, there is a table comparing several options, including Zero
install and Autopackage among others. Of course, According to its page,
Zero Install rocks. ;)
Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?
If I recall correctly, the two approaches are in fact compatible. You
can create an Autopackage that handles distribution independence and
other portability concerns then use Zero Install to keep track of
whether a new version of your package is available (using version
numbers and hashes), download and install into Zero Install space if
necessary, and run the top-level executable from there.
-- Scott
---------------------------------------------------------------------
Isak Savo
2009-07-30 16:40:17 UTC
Permalink
Post by Pablo Garralda
Hi everybody,
           Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In its
site, there is a table comparing several options, including Zero install and
Autopackage among others. Of course, According to its page, Zero Install
rocks. ;)
           Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?
Different approaches to the same problem basically. Zero install tries
to remove (or reduce) this whole "i need to install an application
before I can use it" mantra that has been around since the operating
system was invented.

Autopackage tries to solve the limitations of centralized software
distribution that exist in the linux world, allowing more of windows
.msi/setup.exe way of installing apps.

That's the fundamental differences IMO.

-Isak

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/***@public.gmane.org
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/***@public.gmane.org
Thomas Leonard
2009-07-30 17:56:27 UTC
Permalink
Post by Isak Savo
Post by Pablo Garralda
Hi everybody,
           Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In its
site, there is a table comparing several options, including Zero install and
Autopackage among others. Of course, According to its page, Zero Install
rocks. ;)
           Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?
Different approaches to the same problem basically. Zero install tries
to remove (or reduce) this whole "i need to install an application
before I can use it" mantra that has been around since the operating
system was invented.
Autopackage tries to solve the limitations of centralized software
distribution that exist in the linux world, allowing more of windows
.msi/setup.exe way of installing apps.
That's the fundamental differences IMO.
I think the key design concept of Zero Install is that getting a
program should be side-effect-free. Whereas an Autopackage is entirely
self-installing (you execute the file and it runs a script inside it),
Zero Install packages contain no installation code, and are installed
entirely using external tools. Distribution packages are somewhere
in-between: you start the process with an external tool, but it runs a
script inside the package during the process and package files end up
in key locations on the host file-system.

The advantage of Autopackage is the developer has a lot of flexibility
about what happens when their program is installed (e.g. add a desktop
icon, set up MIME associations, etc). The advantage of Zero Install is
it gives the user a lot of flexibility about what happens, avoids
conflicts, and potentially integrates nicely with security systems.

Both aim to de-centralise the process of getting or distributing
software, and the binary-portability features of Autopackage work
nicely with Zero Install too.
--
Dr Thomas Leonard ROX desktop / Zero Install
GPG: 9242 9807 C985 3C07 44A6 8B9A AE07 8280 59A5 3CC1

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/***@public.gmane.org
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/***@public.gmane.org
Matthew Tedder
2009-07-30 22:58:15 UTC
Permalink
Hmm.. I need to read up on Zero Install to understand that, I think..

What I like about Autopackage is that it's the closest thing toward
effectively forming a united GNU/Linux software platform. Having to hope my
current version of my particular distribution's package repository has the
particular version of the app I want is just a very bad... highly annoying
thing for me. And I think it is the #1 inhibiting factor of broader
adoption of GNU/Linux as a personal OS: first, there'd be more software for
everybody--both FOSS and proprietary apps; second, life would be much easier
for the average user for not only having access to more software but for
being able to use it, too; and third, stores could be more willing to sell
GNU/Linux based hardware not having to worry about software availability or
support problems resulting from the lack of the same.

What I think autopackage is missing for this vision to come true are the
following (understanding not everyone agrees with me on multiple points):

(1) Building a central repository is a good idea, given certain conditions.
This would help build up critical mass, increasing the exposure, popularity,
and marketability of autopackage's goals.
a. If the software maintainer is unwilling to maintain his/her/its' own
autopackage then it's a good thing to try and find a surrogate maintainer
until that person can be convinced to do it his/her/its' self.
b. A surrogate maintained autopackage might act as a handy starting point
for the proper maintainer to take over from or at least learn from in order
to make a proper one.
c. A central repository could provide a helpful infrastructure for
project maintainers to maintain a project within and also for users to seek
out and compare application packages.

(2) My own view about most open source software applications is that they
are seldom (if ever) complete products. I think it's a fine idea for
someone else to build a solution based off of a typical existing open source
applications.. e.g. Open Office with books, video tutorials, and a on-line
support account, etc.



Matthew
Post by Isak Savo
Post by Pablo Garralda
Hi everybody,
Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In
its
Post by Pablo Garralda
site, there is a table comparing several options, including Zero install
and
Post by Pablo Garralda
Autopackage among others. Of course, According to its page, Zero Install
rocks. ;)
Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?
Different approaches to the same problem basically. Zero install tries
to remove (or reduce) this whole "i need to install an application
before I can use it" mantra that has been around since the operating
system was invented.
Autopackage tries to solve the limitations of centralized software
distribution that exist in the linux world, allowing more of windows
.msi/setup.exe way of installing apps.
That's the fundamental differences IMO.
-Isak
---------------------------------------------------------------------
Rykel™
2009-08-04 19:42:58 UTC
Permalink
I am not sure abt Zero Install, but one reason Autopackage rocks because
Autopackage allows a user to install software As User, not (necessarily)
Root User.
Keep it up guys!! :)



Best Regards,


Rykel™
http://bit.ly/howtoinum
Post by Matthew Tedder
Hmm.. I need to read up on Zero Install to understand that, I think..
What I like about Autopackage is that it's the closest thing toward
effectively forming a united GNU/Linux software platform. Having to hope my
current version of my particular distribution's package repository has the
particular version of the app I want is just a very bad... highly annoying
thing for me. And I think it is the #1 inhibiting factor of broader
adoption of GNU/Linux as a personal OS: first, there'd be more software for
everybody--both FOSS and proprietary apps; second, life would be much easier
for the average user for not only having access to more software but for
being able to use it, too; and third, stores could be more willing to sell
GNU/Linux based hardware not having to worry about software availability or
support problems resulting from the lack of the same.
What I think autopackage is missing for this vision to come true are the
(1) Building a central repository is a good idea, given certain
conditions. This would help build up critical mass, increasing the
exposure, popularity, and marketability of autopackage's goals.
a. If the software maintainer is unwilling to maintain his/her/its' own
autopackage then it's a good thing to try and find a surrogate maintainer
until that person can be convinced to do it his/her/its' self.
b. A surrogate maintained autopackage might act as a handy starting
point for the proper maintainer to take over from or at least learn from in
order to make a proper one.
c. A central repository could provide a helpful infrastructure for
project maintainers to maintain a project within and also for users to seek
out and compare application packages.
(2) My own view about most open source software applications is that they
are seldom (if ever) complete products. I think it's a fine idea for
someone else to build a solution based off of a typical existing open source
applications.. e.g. Open Office with books, video tutorials, and a on-line
support account, etc.
Matthew
Post by Isak Savo
Post by Pablo Garralda
Hi everybody,
Reading Autopackage F.A.Q. I've just found a link to "Zero
Install" which it seems to have an approach similar to Autopackage. In
its
Post by Pablo Garralda
site, there is a table comparing several options, including Zero install
and
Post by Pablo Garralda
Autopackage among others. Of course, According to its page, Zero Install
rocks. ;)
Does anybody know the advantages of Autopackage over Zero
Install? Better portability, perhaps? Or its just a different approach?
Different approaches to the same problem basically. Zero install tries
to remove (or reduce) this whole "i need to install an application
before I can use it" mantra that has been around since the operating
system was invented.
Autopackage tries to solve the limitations of centralized software
distribution that exist in the linux world, allowing more of windows
.msi/setup.exe way of installing apps.
That's the fundamental differences IMO.
-Isak
---------------------------------------------------------------------
Mike Hearn
2009-07-30 21:25:58 UTC
Permalink
I would characterize it as autopackage being closer to unix than
ZeroInstall which is ultimately more inspired by RISC OS than anything
else. Not that I think UNIX has a good design, I don't, but it was
built for Linux users so trying to follow all the conventions of unix
seemed to make sense at the time.

There is a whole set of interesting arguments you can have here .....
should a software distribution scheme [a] try and be as "native" as
possible or [b] try and do the Right Thing even if that doesn't fit
well with the host ?

Googles ChromeOS clearly takes the latter approach with an
uncompromising Web Uber Alles design in which there is no installation
because everything is a web app. It's sort of a pure form of the
ZeroInstall model, with the caveat that the web was never really
designed for apps and there'll need to be a ton of extra APIs added to
make it competitive with client-side development (cf. gears, o3d,
nativeclient etc).

autopackage is sort of the opposite extreme in that it's a very
traditional approach, software installation is Big and Complicated but
you end up with an installed app that behaves the same as all your
others.

Which approach you prefer depends largely on personal taste, I think.

---------------------------------------------------------------------
To unsubscribe, e-mail: autopackage-dev-unsubscribe-OfajU3CKLf1/***@public.gmane.org
For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/***@public.gmane.org
Loading...