Search:

Here are some assorted notes and ramblings on software management UI in general, specifically, appfolder UI a la MacOS X/NeXTSTEP.

Various rationales given for why we don't implement this on website, they're OK, but no fundamental reasons given except "it's hard"

Basic insight: appfolders/linux fhs are mirror images of each other.

• Filing systems are primitive databases, they can query only on one column (sorta)

• Therefore, how you arrange the filing system dictates which column you can query on

• However, all modern operating systems need to be able to query multiple columns. For instance, "what files make up program foo" and "what programs can open filetype bar".

• Therefore, all modern operating systems require at least two databases, possibly more.

• MacOS chooses "related files" as their query axis: by using the filing system APIs you can select every file that makes up a particular unit of software, or bundle.

  • The extra databases are stored as in-memory Plist files inside the Launch Services daemon. Applications do RPCs to this daemon to query "what apps handle files of type foo" or "what apps can open URLs of scheme bar://".

  • Launch Services tracks appfolders as they are put onto and removed from the system.

  • At least in prior versions the algorithm used wasn't too smart: it was possible to "hide" packages from the OS by putting them somewhere other than the conventional locations.

  • The database is/was rebuilt at startup.

  • The database is constructed by merging together the Info.plist files inside each appfolder

• Linux chooses "file type" as the query axis.

  • It's impossible to connect related files just by looking at the filing system. For that you need an extra database (eg, rpmdb)

  • It's very easy to do queries like "what applications support files of type foo" because every app drops a .desktop file into a well known location (and then updates a cache) so you can scan every app very quickly.

  • Support for things like "man foo" or "exec bar" is trivial to implement because you can instantly query the system for all available manpages or binaries using the filing system APIs. On MacOS X the Apple help center has to query Launch Services to find the help documents that are available.

  • You can usually have multiple "software prefixes", /usr and /usr/local are the most famous. Unfortunately most of the time anything except /usr is broken - various programs don't look there. It's also messy: there's a ton of FOO_PATH variables that must be set.

Given that in both designs, extra databases and extra domain-specific APIs are necessary, is one really any better than the other?

• Linux/FHS

  • Favours ease of implementation. This makes sense. Given very limited manpower, the ability to do a common operating system task like "locate a file of type X for program name Y" with little code is important.

  • Efficient. You can have "update-foo-cache" programs to solve the problem of scaling to potentially hundreds of registered programs. This lets you do queries like "what programs can open image/jpeg files" VERY fast.

  • Suffers problems with namespace conflicts; you can't have two programs with the same name installed at once.

    • Could be solved using "sliding", where programs are not only prefix independent but also name independent. For instance, if a program is installed as /usr/bin/widget-1.2 then it should automatically look in /usr/share/widget-1.2 instead of /usr/share/widget for data files. Rather ugly solution but allows for transparent parallel installs of multiple versions of the same program (or two programs with the same name).

• MacOSX/AppFolders

  • Favours end-user ease of use. No specific UI is required to uninstall software (unlike the autopackage "Manage 3rd party software" applet).

  • Does not have any problems with multiple progams with the same name (ie, two different versions) installed at once, as the user is responsible for preventing namespace clashes within the filing system. Open question: how does Launch Services resolve internal conflicts? Most likely answer is that the path/inode of the appfolder is used as the system-scoped unique ID, unlike Linux in which the "short name" is used.

  • But ... Info.plist files have some kind of reverse-DNS based namespace. WTF?

  • Requires quite a hefty bit of infrastructure to run the system. Launch Services isn't open source and takes a fundamentally different tack to GNOME/KDE - the Linux desktops define open specifications for registering with the desktop by placing files in certain paths. File notification APIs are then used so that interested applications can be notified when new apps are registered. All this is mostly hidden by the GNOME-VFS and equivalent KDE APIs. Same infrastructure, different places (less unified as well ...)

Given that they're in some senses two sides of the same coin, what would happen if we combined the two?

• http://www.fsl.cs.sunysb.edu/project-unionfs.html

• http://www.kernel.org/pub/linux/kernel/people/rml/inotify/README

An appfolderd daemon could slap an inotify watch on the current users $HOME and any mounted media (HAL can tell us when these are added). AppFolders would simply be directories that conformed to some convention: NeXT used the .app extension and that seems reasonable enough, except that they wouldn't be compatible so using the same extension might be confusing. Internally these directories are simply installed prefixes (bin/, lib/, share/appname etc). When discovered, each appfolder is union mounted into /usr. By giving us the ability to join different parts of the filing system tree together, we can increase the expressiveness of file paths as a query language. Put simply it now becomes possible to query both for related files (bundles) and file types (/usr/foo) at once, without any additional databases.

Desktop integration is solved without writing a LaunchServices clone, because the act of joining a directory into the /usr heirarchy would trigger inotify file notifications which GNOME and KDE already listen out for.

This scheme would require (mostly trivial) modifications to various programs, specifically:

• Nautilus would have to be able to recognise a directory and treat it as a file in the UI

• There would have to be some way of shipping the directories around.

  • MacOS X uses "DMG" files which are compressed disk images. Unfortunately Linuxs generally awful binary portability means we can't do this: sometimes the contents of the package will have to be hacked for the current system.

  • We can retro-fit autopackage to do this: by adding an "install in-place" mode, we can simply decompress the package itself to a temporary directory, modify the APIs to do things like binary patching/menu editing in place, delete the original installer package and then move the temporary directory to where the package used to be.

  • The resulting UI is that the user downloads a .package file, opens it, and the package goes through the usual motions of dep checking/resolution before morphing into a launchable directory. This directory can then be moved around at will, or dragged to the trash can if you no longer want it.

This has some pros/cons vs the two other implementations we've come up with:

this VS http://autopackage.org/ui-vision.html

• Con: No obvious "hook" to embed icons/launchers directly into web pages. That's a nice feature. I like that feature. I'd rather not let it go.

• Con: not something other package managers can do, it'd require modifications to autopackage. While a part of me thinks that's actually a good thing, getting modifications into GNOME without effectively forking bits of it would be hard unless it was autopackage-neutral

• Con: need to hack the file manager to treat directories as files (but then again, you'd probably need to hack GNOME to support better drag/drop of launchers anyway) and be able to launch from them.

• Con: you can't email or IM people interesting apps anymore as they really are directories (and non-portable ones at that!)

• Con: some people may view union mounts as a hack (I see it as a natural way of leveraging the power of the filing-system-as-database model)

• Con: requires modifying the distro (in particular, moving /usr to /usr.system or something so /usr becomes a free mount point.

• Pro: no need to write a package garbage collector, as when the user trashes software it really does die

• Pro: probably simpler to implement

• Pro: If the user drags the directory to a CD, to back it up for instance, it'll actually do what they expect (unless they are backing up to change distro ....)

• Pro: allows for elimination of the separate autopackage/rpm/whatever database, which reduces complexity and increases robustness.

this VS amusing-.desktop-file-hacks (the redeeming feature of which is full backwards compatibility)

• Con: requires modification of desktop environments

• Pro: isn't a crappy hack

Let's say no more about that idea.