Re: Autopackage Vs Zero Install
Matthew Tedder <[email protected]> Thu, 30 Jul 2009 15:58:15 -0700
| Newsgroups | gmane.comp.autopackage.devel |
|---|---|
| Message-ID | <[email protected]> |
--0016e6dbdea725b3dd046ff43d22 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit 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 On Thu, Jul 30, 2009 at 9:40 AM, Isak Savo <[email protected]> wrote: > On Tue, Jul 28, 2009 at 10:33 PM, Pablo Garralda<[email protected]> > wrote: > > 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/[email protected] > For additional commands, e-mail: autopackage-dev-help-OfajU3CKLf1/[email protected] > > --0016e6dbdea725b3dd046ff43d22 Content-Type: text/html; charset=ISO-8859-1 Content-Transfer-Encoding: quoted-printable <br>Hmm..=A0 I need to read up on Zero Install to understand that, I think.= .<br><br>What I like about Autopackage is that it's the closest thing t= oward effectively forming a united GNU/Linux software platform.=A0 Having t= o hope my current version of my particular distribution's package repos= itory has the particular version of the app I want is just a very bad... hi= ghly annoying thing for me.=A0 And I think it is the #1 inhibiting factor o= f broader adoption of GNU/Linux as a personal OS: first, there'd be mor= e software for everybody--both FOSS and proprietary apps; second, life woul= d be much easier for the average user for not only having access to more so= ftware but for being able to use it, too; and third, stores could be more w= illing to sell GNU/Linux based hardware not having to worry about software = availability or support problems resulting from the lack of the same.<br> <br>What I think autopackage is missing for this vision to come true are th= e following (understanding not everyone agrees with me on multiple points):= <br><br>(1) Building a central repository is a good idea, given certain con= ditions.=A0 This would help build up critical mass, increasing the exposure= , popularity, and marketability of autopackage's goals.=A0 <br> =A0 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 mai= ntainer until that person can be convinced to do it his/her/its' self.<= br> =A0 b.=A0 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.<br>=A0=A0 c.=A0 A central repository could pro= vide a helpful infrastructure for project maintainers to maintain a project= within and also for users to seek out and compare application packages.=A0= <br> <br>(2) My own view about most open source software applications is that th= ey are seldom (if ever) complete products.=A0 I think it's a fine idea = for someone else to build a solution based off of a typical existing open s= ource applications.. e.g. Open Office with books, video tutorials, and a on= -line support account, etc.<br> <br><br><br>Matthew<br><br><div class=3D"gmail_quote">On Thu, Jul 30, 2009 = at 9:40 AM, Isak Savo <span dir=3D"ltr"><<a href=3D"mailto:isak.savo@gma= il.com">[email protected]</a>></span> wrote:<br><blockquote class=3D"g= mail_quote" style=3D"border-left: 1px solid rgb(204, 204, 204); margin: 0pt= 0pt 0pt 0.8ex; padding-left: 1ex;"> <div><div></div><div class=3D"h5">On Tue, Jul 28, 2009 at 10:33 PM, Pablo G= arralda<<a href=3D"mailto:[email protected]">[email protected]</a>&g= t; wrote:<br> > Hi everybody,<br> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Reading Autopackage F.A.Q. I've jus= t found a link to "Zero<br> > Install" which it seems to have an approach similar to Autopackag= e. In its<br> > site, there is a table comparing several options, including Zero insta= ll and<br> > Autopackage among others. Of course, According to its page, Zero Insta= ll<br> > rocks. ;)<br> ><br> > =A0=A0=A0=A0=A0=A0=A0=A0=A0=A0 Does anybody know the advantages of Aut= opackage over Zero<br> > Install? Better portability, perhaps? Or its just a different approach= ?<br> <br> </div></div>Different approaches to the same problem basically. Zero instal= l tries<br> to remove (or reduce) this whole "i need to install an application<br> before I can use it" mantra that has been around since the operating<b= r> system was invented.<br> <br> Autopackage tries to solve the limitations of centralized software<br> distribution that exist in the linux world, allowing more of windows<br> .msi/setup.exe way of installing apps.<br> <br> That's the fundamental differences IMO.<br> <font color=3D"#888888"><br> -Isak<br> </font><div><div></div><div class=3D"h5"><br> ---------------------------------------------------------------------<br> To unsubscribe, e-mail: <a href=3D"mailto:autopackage-dev-unsubscribe@sunsi= te.dk">autopackage-dev-unsubscribe-OfajU3CKLf1/[email protected]</a><br> For additional commands, e-mail: <a href=3D"mailto:autopackage-dev-help@sun= site.dk">autopackage-dev-help-OfajU3CKLf1/[email protected]</a><br> <br> </div></div></blockquote></div><br> --0016e6dbdea725b3dd046ff43d22--