Yes we know the bouncing progress bars suck. I yelled at people about that a few days ago. Expect them to disappear as time goes on.
Dialogs same size - not sure there's any point to this. Dialogs that don't fit their content are just weird. Making them all the same window is technically very hard because of the need to run different programs to re-authenticate etc. Yes yes, excuses, but software is compromise.
No cancel button: where is the cancel button? You cannot cancel an install, so there should not be one. The closest I can see is Hide which is different.
Don't ask for passwords: you need the root password for software to be shared, and various things work better when software is installed system-wide. The "No password" button is there for setups where you are not the administrator rather than for home users. Long term authentication-less software installation should happen but it's a big step that neither MacOS X nor Windows have fully taken yet, it requires a lot of thought and technology to ensure it's done correctly.
Progress meters: yes, from a pure UI perspective you are correct. However it's hard to know how long things will take because the packager has complete freedom to do whatever they like. It's not deterministic, in other words. Again, compromise. Long term this whole UI will disappear in favour of drag/drop installs anyway so there's not much point in polishing it too much.
The uninstaller will prompt you for the root password once you hit "Remove". It's just not shown in the Flash demo.
The GNOME APIs aren't unstable, far from it. They are very stable. So this is not a big problem. Now, if you want to use very new APIs not all your users have yet, whilst falling back to the old ones, relaytool can help you there - the Fyre package is a demonstration of doing this for the old/new GTK+ filepicker.
User tweaking functionality, yes you have it pretty much right. With weak linkage stuff will magically start working when you install the right package. Autopackage understands the difference between a required and recommended dependency and will tell the user about missing recommended deps at the end of the install in the summary screen. It's not perfect, but it works. We really need a Desktop Linux Platform to go further here.
We already "fix" or rather workaround a few of the more annoying problems like the Ubuntu/Debian libpng mess, but doing deep surgery isn't our place.
Working around others cockups is just a part of writing software I'm afraid, arguably it's a part of life;)
Long term what I'd like to see is an equivalent to freedesktop.org for distributions, where distro developers can congregate and produce standards on how things should work. That would help a lot. Often the brokenness is needless, one distro just hasn't picked up the right fix or magic script from another. Co-ordination could help a lot.
Sure, that UI is a good one and we want to implement it (and have a concrete implementation idea to back it up). But getting installs reliable and easy is a higher priority, different kinds of UI can come later.
No. If you're aware of any Linux software that's currently shipping with malicious code let me know and it'll go up the priority list. Mirror cracking and so on is already dealt with by using GPG signatures as the Gaim autopackage does.
You can't automatically convert pre-existing packages to autopackages. The process of building an autopackage is rather longer than an RPM because you have to improve the quality of the software at the same time to meet various standards. For instance a dependency audit may be useful, weakening various deps at runtime so you can run without them being present but use them if they are (relaytool) etc etc.
If it was only small distros, maybe we could get away with that. But it's not. It's large distros like Fedora and Debian.
Pretty quickly you realise that every distro is broken in various unique ways - isn't the distro system marvellous? So it's a lot easier to just work around their various faults than wait for the day when they all get their act together (not going to happen).
When it comes back up there's an RPM of the support and developer code on the website, for those who want it (though they aren't required). We're not anti-RPM or anything you know;)
There are already packages of Gaim, Inkscape, and AbiWord. Unfortunately if you want to test them you must download this file manually and then this one, and put it in the same directory as the.package - the redirects we use to stay independent of sunsite have been crushed out of existance by the Slashdot effect. It's a temporary problem, don't worry.
Asking how they stack up is a bit of a biased question. Autopackage isn't meant to compete directly with RPM/DPKG or replace them, it's meant as a complement. They are designed for different things. For instance, a package of gnome-terminal makes no sense because that's a core part of the OS and autopackage is meant for third party applications. Capabilities RPM needs like auto-shlib-dep discovery are done differently in autopackage and vice-versa.
The really big leap in backends would be a distributed repository.
I suspect you are thinking of something like Conary. However... that said, a distributed and decentralised package management system is what autopackage is all about. Autopackages can resolve dependencies in a manner that does not require large monolithic databases: the packages themselves know where to go to find their dependencies if they're missing (and in future they'll be able to use yum, apt-get etc as well just in case).
Basically the apt-get type model doesn't work too well once you start having say >50 repositories all together, as co-ordinating the overlaps becomes too much of a nightmare. A much less tightly coupled system works better, which is what we have here.
That assumes the dependencies are in Debian, aren't broken (eg, unstable/experimental sometimes contain uninstallable packages) and so on.
What the gp is asking for is something like this, I think.
All kinds of UIs become possible once you have the infrastructure in place. Apt-get "name that package" type UIs are of course very handy when you know what it is you want, and NeXT style appfolders are also quite convenient when browsing around. We can support all of them, if we want.
I'm afraid your assumption that distributions "authenticate" software is flawed. Hiding a back door in software of any reasonable complexity is not hard, if you're so determined, and no distribution can protect you from that. Think about it: who in their right mind is going to wade through all 100,000 lines of configure script looking for back doors? Not going to happen.
Now what you may mean is spyware, malware etc. But this thinking is also flawed. Spyware and such is designed to make money by piggybacking on proprietary software. Open source software has no need of revenue to keep it alive, therefore no need of spyware - but proprietary software cannot enter most distro repositories because most distros do not distribute commercial software. Therefore they would never get a chance to filter things out anyway.
If you want to filter out malicious software in the decentralised model, you need to do several things:
Define a policy for what is and is not allowed
Create a certificate authority heirarchy SSL-style. It should be easy to get a package signing certificate: however, it should also be easy to get kicked off if you violate network policy.
Have an auto-update mechanism that downloads whitelists of signing keys: if you aren't in the whitelist, the system will give you big honking warnings.
The danger here is that people try to audit code before giving out certificates. That's clearly bong: you can't do that reliably or scalably, and anyway waiting until somebody has violated the network policy and then kick them off rapidly has much the same effect: the OS stays free of "bad" software.
The LSB really isn't big enough for any non-trivial desktop app, and it shows no signs of growing to meet that challenge. There'll probably ahve to be a different "standard" (yeah yeah, I know) base set, one that builds on LSB but extends it.
# What's wrong with centralized repositories, apt style?
The system of attempting to package everything the user of the
distro might ever want is not scalable. By not scalable, we mean
the way in which packages are created and stored in a central
location, usually by separate people to those who made the
software in the first place. There are several problems with
this approach:
Centralisation introduces lag between upstream releases and actually
being able to install them, sometimes measured in months or years.
Packaging as separate from development tends to introduce
obscure bugs caused by packagers not always fully
understanding what it is they're packaging. It makes no more
sense than UI design or artwork being done by the
distribution.
Distro developers end up duplicating effort on a massive
scale. 20 distros == the same software packaged 20 times ==
20 times the chance a user will receive a buggy
package. Broken packages are not rare: see Wine, which has a
huge number of incorrect packages in circulation, Mono which
suffers from undesired distro packaging, etc
apt et al require extremely well controlled repos, otherwise they
can get confused and ask users to provide solutions manually : this
requires an understanding of the technology we can't expect users
to have.
Very hard to avoid the "shopping mall" type user interface, at
which point choice becomes unmanagably large: see Synaptic for a
pathological example of this. Better UIs are possible but
you're covering up a programmatic model which doesn't match the
user model esp for migrants.
Pushes the "appliance" line of thinking, where a distro is not a
platform on which third parties can build with a strong commitment
to stability but merely an appliance: a collection of bits that
happen to work together but may not tomorrow: you can
use what's on the CDs but extend or modify it and you void the
warranty. Appliance distros have their place: live demo CDs, router
distros, maybe even server distros, but not desktops. To compete
with Windows for mindshare and acceptance we must be a platform.
# What's wrong with NeXT/MacOSX style appfolders?
One of the more memorable features of NeXT based systems like MacOS X
or GNUstep is that applications do not have installers, but are
contained within a single "appfolder", a special type of directory
that contains everything the application needs. To install apps, you
just drag them into a special Applications folder. To uninstall, drag
them to the trash can. This is a beguilingly easy way of managing
software, and it's a common conception that Linux should also adopt
this mechanism. I'd like to explain why this isn't the approach that
autopackage takes to software management.
The first reason is the lack of dependency management. Because you are
simply moving folders around, there is no logic involved so you cannot
check for your apps dependencies. Most operating systems are made up
of many different components, that work together to make the computer
work. Linux is no different, but due to the way in which it was
developed, Linux has far more components and is far more "pluggable"
than most other platforms. As such, the number of discrete components
that must be managed is huge. Linux is different to what came before
not only in this respect, but also because virtually all the
components are freely available on the internet. Because of this,
software often has large numbers of dependencies which must be
satisfied for it to work correctly. Even simple programs often make
use of many shar
So much for sunsite having plenty of bandwidth and fast servers! Well, here are some select pieces from the FAQ:
# What is autopackage?
For users: it makes software installation on Linux easier. If a
project provides an autopackage, you know it can work on your
distribution. You know it'll integrate nicely with your desktop and
you know it'll be up to date, because it's provided by the
software developers themselves. You don't have to choose which
distro you run based on how many packages are available.
For developers: it's software that lets you create binary
packages for Linux that will install on any distribution, can
automatically resolve dependencies and can be installed using
multiple front ends, for instance from the command line or from
a graphical interface. It lets you get your software to your
users quicker, easier and more reliably. It immediately
increases your userbase by allowing people with no native
package to run your software within seconds.
# Is autopackage meant to replace RPM?
No. RPM is good at managing the core software of a distro. It's
fast, well understood and supports features like prepatching of
sources. What RPM is not good at is non-core packages, ie
programs available from the net, from commercial vendors,
magazine coverdisks and so on. This is the area that autopackage
tackles. Although in theory it'd be possible to build a distro
based around it, in reality such a solution would be very
suboptimal as we sacrifice speed for flexibility and distro
neutrality. For instance, it can take several seconds to verify
the presence of all required dependencies, something that RPM
can do far quicker.
# Why a new format? Why do the RPMs I find on the net today only work on one distro?
There are a number of reasons, some obvious, some not so
obvious. Let's take them one at a time:
Dependency metadata: RPMs can have several types of
dependencies, the most common being file deps and package
deps. In file deps, the package depends on some other
package providing that file. Depending on/bin/bash for a
shell script is easy, as that file is in the same location
with the same name on all systems. Other dependencies are
not so simple, there is no file that reliably expresses the
dependency, or the file could be in multiple locations. That
means sometimes package dependencies are
preferred. Unfortunately, there is no standard for naming
packages, and distros give them different names, as well as
splitting them into different sized pieces. Because of that,
often dependency information has to be expressed in a
distro-dependent way.
RPM features: because RPM is, at the end of the day, a tool to
help distro makers, they sometimes add new macros and features to it
and then use them in their specfiles. People want proper integration
of course, so they use Mandrake specific macros or whatever, and
then that RPM won't work properly on other distros.
Binary portability: This one affects all binary
packaging systems. A more detailed explanation of the problems
faced can be found in Chapter
7 of the developer guide.
Bad interactions with source code: because the
current versions of RPM don't check the system directly,
they only check a database, it makes it hard to install them
on distros like Gentoo even when they only use file
deps. Similar problems arise if you compile things from
source.
There are various reasons why a new format was created rather
than changing RPM
Yes, exactly. Firstly it's hard to propogate viruses based purely on such exploits unless there is high market share. Secondly it doesn't tell us much of value about the difference between MacOS X and Windows, as both are written mostly in languages like C/C++ (or Objective-C which isn't inherantly safe from buffer overflows either). Unless you believe that working at Apple magically makes you write less buggy code (there's no evidence that this is the case).
If anything I'd say Microsoft have the upper hand as they have a large and well publicised secure-code training program. I'd guess that Apple don't have an equivalent otherwise they'd probably mention it somewhere (good PR right?).
Being based on BSD has nothing to do with anything, the userland/desktop space is where most exploits have been in recent years and the Aqua shell is no more free from exploits than Explorer is.
In particular, appfolders have had some pretty nasty broken-by-design security exploits like the URL handler variants where an internet enabled DMG would self-mount itself into the filing system and automatically reconfigure URL schemes in Safari, all without the user doing anything other than visiting a web page. I think (hope) they fixed that but it was still several months until all the holes and variants of this technique were "fixed" (really just hacked around). The help system exploits Apple suffered were similar in nature.
Essentially, Apple haven't proven themselves any more skilled at designing secure desktops than Microsoft have. That said, this sort of competition is fairly pointless: being able to "infect" a machine with no action taken by the user boils down to finding buffer/heap overflows and the like in running software. Many viruses propogate with a bit of help from the user, even if all that involves is surfing the web.
I always got the impression most of the remaining work was being bug-for-bug compatible with the Word layout engine, eg agreeing on what margins are and so on rather than actually reading the file data itself.
There's no point playing this sort of word game, it has no intellectual merit. Microsoft employees routinely define "API" as something that is documented and exported by a DLL, and therefore anything that is exported but not documented is not an API regardless of what happens to use it.
The most important, most fundamental point is: did the Internet Explorer team have an advantage over Netscape because they were working for Microsoft? I think you'd have to be naive to claim that wasn't true. The integration IE4 had with Windows 95 wasn't simply a matter of clever use of APIs, it was a matter of a full OS upgrade. Of course, Windows 98 came shipped with it by default and at that point, we disappear into the black hole of semantic pissing matches.
Nobody cares about undocumented calls today: back then integration into the OS was a secret weapon, today it's seen merely as a liability.
Even more specifically Qt isn't using Cairo, it's using its own equivalent TrollTech are writing from scratch (because they have to own the copyright on all the Qt code for their business model to work). However everything below Cairo and GTK+ is independent of GNOME/GTK+ and will work fine for KDE.
Yeah, I mean seriously. IE only uses documented APIs? What's this then?
Can somebody - Dave? - point me to the API that let IE4 add a "Favourites" item to the start menu in Windows 95? I don't mean something that was documented last year, I mean something that was documented... in 1995. I don't think there is such an API. I don't think there ever was.
Can somebody - Dave? - tell me why the IE installer calls the undocumented Extract cabinet.dll function?
As far as I'm concerned this is all very simple. Could Netscape have done to Windows 95 what Microsoft did with IE4? Obviously the answer is no: IE did things that weren't just *adding* APIs, they were replacing core parts of the OS like Explorer in order to add the Favourites menu, Active Desktop etc etc. Dave is full of shit and the sad thing is, he probably believes his own story.
Slashdot Mirror
Dialogs same size - not sure there's any point to this. Dialogs that don't fit their content are just weird. Making them all the same window is technically very hard because of the need to run different programs to re-authenticate etc. Yes yes, excuses, but software is compromise.
No cancel button: where is the cancel button? You cannot cancel an install, so there should not be one. The closest I can see is Hide which is different.
Don't ask for passwords: you need the root password for software to be shared, and various things work better when software is installed system-wide. The "No password" button is there for setups where you are not the administrator rather than for home users. Long term authentication-less software installation should happen but it's a big step that neither MacOS X nor Windows have fully taken yet, it requires a lot of thought and technology to ensure it's done correctly.
Progress meters: yes, from a pure UI perspective you are correct. However it's hard to know how long things will take because the packager has complete freedom to do whatever they like. It's not deterministic, in other words. Again, compromise. Long term this whole UI will disappear in favour of drag/drop installs anyway so there's not much point in polishing it too much.
The uninstaller will prompt you for the root password once you hit "Remove". It's just not shown in the Flash demo.
Thanks for your comments!
Yeah I know ;) But having built the damn things I wanna pimp them
Read the section on static linking - hard disk space may be cheap but memory is at a premium in most systems.
Having applications (as opposed to libraries) installed outside of apt doesn't break anything as they aren't dependencies of things.
Working around others cockups is just a part of writing software I'm afraid, arguably it's a part of life ;)
Long term what I'd like to see is an equivalent to freedesktop.org for distributions, where distro developers can congregate and produce standards on how things should work. That would help a lot. Often the brokenness is needless, one distro just hasn't picked up the right fix or magic script from another. Co-ordination could help a lot.
Sure, that UI is a good one and we want to implement it (and have a concrete implementation idea to back it up). But getting installs reliable and easy is a higher priority, different kinds of UI can come later.
No. If you're aware of any Linux software that's currently shipping with malicious code let me know and it'll go up the priority list. Mirror cracking and so on is already dealt with by using GPG signatures as the Gaim autopackage does.
You can't automatically convert pre-existing packages to autopackages. The process of building an autopackage is rather longer than an RPM because you have to improve the quality of the software at the same time to meet various standards. For instance a dependency audit may be useful, weakening various deps at runtime so you can run without them being present but use them if they are (relaytool) etc etc.
Pretty quickly you realise that every distro is broken in various unique ways - isn't the distro system marvellous? So it's a lot easier to just work around their various faults than wait for the day when they all get their act together (not going to happen).
When it comes back up there's an RPM of the support and developer code on the website, for those who want it (though they aren't required). We're not anti-RPM or anything you know ;)
Asking how they stack up is a bit of a biased question. Autopackage isn't meant to compete directly with RPM/DPKG or replace them, it's meant as a complement. They are designed for different things. For instance, a package of gnome-terminal makes no sense because that's a core part of the OS and autopackage is meant for third party applications. Capabilities RPM needs like auto-shlib-dep discovery are done differently in autopackage and vice-versa.
I suspect you are thinking of something like Conary. However ... that said, a distributed and decentralised package management system is what autopackage is all about. Autopackages can resolve dependencies in a manner that does not require large monolithic databases: the packages themselves know where to go to find their dependencies if they're missing (and in future they'll be able to use yum, apt-get etc as well just in case).
Basically the apt-get type model doesn't work too well once you start having say >50 repositories all together, as co-ordinating the overlaps becomes too much of a nightmare. A much less tightly coupled system works better, which is what we have here.
What the gp is asking for is something like this, I think.
All kinds of UIs become possible once you have the infrastructure in place. Apt-get "name that package" type UIs are of course very handy when you know what it is you want, and NeXT style appfolders are also quite convenient when browsing around. We can support all of them, if we want.
Now what you may mean is spyware, malware etc. But this thinking is also flawed. Spyware and such is designed to make money by piggybacking on proprietary software. Open source software has no need of revenue to keep it alive, therefore no need of spyware - but proprietary software cannot enter most distro repositories because most distros do not distribute commercial software. Therefore they would never get a chance to filter things out anyway.
If you want to filter out malicious software in the decentralised model, you need to do several things:
The danger here is that people try to audit code before giving out certificates. That's clearly bong: you can't do that reliably or scalably, and anyway waiting until somebody has violated the network policy and then kick them off rapidly has much the same effect: the OS stays free of "bad" software.
The LSB really isn't big enough for any non-trivial desktop app, and it shows no signs of growing to meet that challenge. There'll probably ahve to be a different "standard" (yeah yeah, I know) base set, one that builds on LSB but extends it.
http://bylands.dur.ac.uk/~mh/autopackage.org/index .html
# What's wrong with centralized repositories, apt style?
The system of attempting to package everything the user of the distro might ever want is not scalable. By not scalable, we mean the way in which packages are created and stored in a central location, usually by separate people to those who made the software in the first place. There are several problems with this approach:
# What's wrong with NeXT/MacOSX style appfolders?
One of the more memorable features of NeXT based systems like MacOS X or GNUstep is that applications do not have installers, but are contained within a single "appfolder", a special type of directory that contains everything the application needs. To install apps, you just drag them into a special Applications folder. To uninstall, drag them to the trash can. This is a beguilingly easy way of managing software, and it's a common conception that Linux should also adopt this mechanism. I'd like to explain why this isn't the approach that autopackage takes to software management.
The first reason is the lack of dependency management. Because you are simply moving folders around, there is no logic involved so you cannot check for your apps dependencies. Most operating systems are made up of many different components, that work together to make the computer work. Linux is no different, but due to the way in which it was developed, Linux has far more components and is far more "pluggable" than most other platforms. As such, the number of discrete components that must be managed is huge. Linux is different to what came before not only in this respect, but also because virtually all the components are freely available on the internet. Because of this, software often has large numbers of dependencies which must be satisfied for it to work correctly. Even simple programs often make use of many shar
# What is autopackage?
For users: it makes software installation on Linux easier. If a project provides an autopackage, you know it can work on your distribution. You know it'll integrate nicely with your desktop and you know it'll be up to date, because it's provided by the software developers themselves. You don't have to choose which distro you run based on how many packages are available.
For developers: it's software that lets you create binary packages for Linux that will install on any distribution, can automatically resolve dependencies and can be installed using multiple front ends, for instance from the command line or from a graphical interface. It lets you get your software to your users quicker, easier and more reliably. It immediately increases your userbase by allowing people with no native package to run your software within seconds.
# Is autopackage meant to replace RPM?
No. RPM is good at managing the core software of a distro. It's fast, well understood and supports features like prepatching of sources. What RPM is not good at is non-core packages, ie programs available from the net, from commercial vendors, magazine coverdisks and so on. This is the area that autopackage tackles. Although in theory it'd be possible to build a distro based around it, in reality such a solution would be very suboptimal as we sacrifice speed for flexibility and distro neutrality. For instance, it can take several seconds to verify the presence of all required dependencies, something that RPM can do far quicker.
# Why a new format? Why do the RPMs I find on the net today only work on one distro?
There are a number of reasons, some obvious, some not so obvious. Let's take them one at a time:
There are various reasons why a new format was created rather than changing RPM
If anything I'd say Microsoft have the upper hand as they have a large and well publicised secure-code training program. I'd guess that Apple don't have an equivalent otherwise they'd probably mention it somewhere (good PR right?).
In particular, appfolders have had some pretty nasty broken-by-design security exploits like the URL handler variants where an internet enabled DMG would self-mount itself into the filing system and automatically reconfigure URL schemes in Safari, all without the user doing anything other than visiting a web page. I think (hope) they fixed that but it was still several months until all the holes and variants of this technique were "fixed" (really just hacked around). The help system exploits Apple suffered were similar in nature.
Essentially, Apple haven't proven themselves any more skilled at designing secure desktops than Microsoft have. That said, this sort of competition is fairly pointless: being able to "infect" a machine with no action taken by the user boils down to finding buffer/heap overflows and the like in running software. Many viruses propogate with a bit of help from the user, even if all that involves is surfing the web.
I always got the impression most of the remaining work was being bug-for-bug compatible with the Word layout engine, eg agreeing on what margins are and so on rather than actually reading the file data itself.
The most important, most fundamental point is: did the Internet Explorer team have an advantage over Netscape because they were working for Microsoft? I think you'd have to be naive to claim that wasn't true. The integration IE4 had with Windows 95 wasn't simply a matter of clever use of APIs, it was a matter of a full OS upgrade. Of course, Windows 98 came shipped with it by default and at that point, we disappear into the black hole of semantic pissing matches.
Nobody cares about undocumented calls today: back then integration into the OS was a secret weapon, today it's seen merely as a liability.
Even more specifically Qt isn't using Cairo, it's using its own equivalent TrollTech are writing from scratch (because they have to own the copyright on all the Qt code for their business model to work). However everything below Cairo and GTK+ is independent of GNOME/GTK+ and will work fine for KDE.
Can somebody - Dave? - point me to the API that let IE4 add a "Favourites" item to the start menu in Windows 95? I don't mean something that was documented last year, I mean something that was documented ... in 1995. I don't think there is such an API. I don't think there ever was.
Can somebody - Dave? - tell me why the IE installer calls the undocumented Extract cabinet.dll function?
As far as I'm concerned this is all very simple. Could Netscape have done to Windows 95 what Microsoft did with IE4? Obviously the answer is no: IE did things that weren't just *adding* APIs, they were replacing core parts of the OS like Explorer in order to add the Favourites menu, Active Desktop etc etc. Dave is full of shit and the sad thing is, he probably believes his own story.