The Linux Desktop Distribution of the Future Part 2
Category: Conceptual Design
This article is part of a four part series intended to provide some thought into how a future Linux Desktop might work. It is not intended to be a comprehensive essay, although all the concepts presented here are considered "doable" by the author.
Part 1: Linux and the Desktop Today
Part 2: Applications
Part 3: File Management
Part 4: The Desktop Interface
Part 2: Applications
Current applications are complicated by not only the packaging system, but by the Linux standard of placing all application files together in a few subdirectories. Commercial Unix distributions long ago realized the difficulties with this scheme and introduced the "/opt" directory under which programs can create their own sub-directories. Unfortunately, no such standard has emerged under Linux.
AppFolders
The best solution yet to emerge for application installation is the NeXT/OS X AppFolder concept. Put simply, the entire application is packaged into an folder with a special extension. When the file browser sees a folder with this extension, it treats it as if it were a special file instead of a directory. As a result, the user sees a single icon for an application, and is free to move or copy this icon to wherever he chooses - even a remote computer. Installation is as simple as extracting the folder and moving it to your favorite location, un-installation is as simple as deleting the folder, and tons of meta-info (such as associations) can automatically be pulled from the directory package.
These features make AppFolders an excellent concept for all desktop systems, Linux included. Unfortunately, there are some issues that make it less than useful in existing Linux distros:
1. Copying one directory over another is currently treated at the individual file level instead of the directory level. This means that if you replace an App with a newer version, the resulting files would be a combination of the original and new files instead of a clean copy of the new directory structure.
2. Linux already has a standardized directory structure (i.e. $prefix/bin, $prefix/lib, $prefix/man, $prefix/share, etc.) that would be difficult to change for a large number of programs.
3. Linux lacks a good method for notifying programs of changes to files and directories.
The Solution
The proposed solution is this. Programs should be compiled normally, but with the "--prefix" setting set to a new folder. For example, /usr/src/build/$APPNAME would be an excellent choice. A standard build will usually produce the /bin subdirectory at a minimum, and optionally /lib, /man, and /share. From this folder, it is possible to execute the program by modifying the PATH and LD_LIBRARY_PATH. Now if we add a standardized shell script executable (say /execute), we now have a method for executing something inside of a given directory.
The job of the execute script would be to investigate it environment, then set up any environment variables that would be needed by the program, For example, most programs have their own variables for identifying where the information stored in /share is kept on the file system. Once the execute script has configured the environment, it will then launch the primary executable. Note that this method quite handily allows for non-native applications such as WINE and Java apps to use the same system.
We now have a highly portable method for executing applications.
Single File vs. Directory
Of course, we have not yet finished solving all of the issues listed above. While point 2 has been effectively addressed, points one and three still loom large. Surprisingly, point one can be quite easily addressed if we ditch the use of folders and move directly to using a single file instead.
If you're scratching your head at that last statement, don't worry. I haven't lost my mind yet. There is a method under which we can have a single file for an application without sacrificing the AppFolder concept we just discussed. Consider for a moment if we created a disk image of the application folder. We'd now have a single, portable file that could be moved to any Linux system. The target system can mount the image, and run the application by calling the /execute script.
The execute script becomes even more important for cross-platform binaries. The script can attempt to detect the architecture and execute the proper binary. The advantage of this method over using the ELF support, is that cross platform compilers are not necessary. The binaries can be compiled on each system, then combined into a single AppFolder/Disk image.
Things aren't all roses, though. If we're going to move to an AppFolder design, then we need to find a method for loading information about the file. For example, what icon should be shown for the disk image? The obvious solution is to detect when the file first appears on the system. Whether it be through the graphical desktop or through a more advanced apparatus such as dnotify (Linux directory notification support), the file should be detected, mounted, the meta-information read, then unmounted. More in the next article about where that meta-information might be stored.
Additional Features
Assuming that a routine is used to detect the type of disk image prior to mounting, a large number of file system features can be supported. CramFS could be used for a read-only compressed disk image, while ext2fs could be used for a writable image (perfect for time limited software). It's even conceivable that an image format could be developed with support for growing the image/file system, password protecting an encrypted disk, and other features only available in a format such as this. Even the existing abilities to freeze the software (no user damage!) and carry information around with the application are very powerful features not seen on other systems.
Existing Work
Unsurprisingly, some work has already been done in this area. Rox Filer has incorporated AppFolders for some time now, though the application selection is still quite small. Klik is a bit newer and has introduced CMG files - an application packed inside a CramFS filesystem. Last but not least, GoboLinux has taken on the challenge of building a stable Linux system that separates all binaries into per-program folders. Hopefully this article will help bring some visibility to these projects, as well as provide useful ideas for their future direction.
Next up, Part 3: File Management
Links:
Rox Filer
Klik
CramFS
GoboLinux
This article is part of a four part series intended to provide some thought into how a future Linux Desktop might work. It is not intended to be a comprehensive essay, although all the concepts presented here are considered "doable" by the author.
Part 1: Linux and the Desktop Today
Part 2: Applications
Part 3: File Management
Part 4: The Desktop Interface
Part 2: Applications
Current applications are complicated by not only the packaging system, but by the Linux standard of placing all application files together in a few subdirectories. Commercial Unix distributions long ago realized the difficulties with this scheme and introduced the "/opt" directory under which programs can create their own sub-directories. Unfortunately, no such standard has emerged under Linux.
AppFolders
The best solution yet to emerge for application installation is the NeXT/OS X AppFolder concept. Put simply, the entire application is packaged into an folder with a special extension. When the file browser sees a folder with this extension, it treats it as if it were a special file instead of a directory. As a result, the user sees a single icon for an application, and is free to move or copy this icon to wherever he chooses - even a remote computer. Installation is as simple as extracting the folder and moving it to your favorite location, un-installation is as simple as deleting the folder, and tons of meta-info (such as associations) can automatically be pulled from the directory package.These features make AppFolders an excellent concept for all desktop systems, Linux included. Unfortunately, there are some issues that make it less than useful in existing Linux distros:
1. Copying one directory over another is currently treated at the individual file level instead of the directory level. This means that if you replace an App with a newer version, the resulting files would be a combination of the original and new files instead of a clean copy of the new directory structure.
2. Linux already has a standardized directory structure (i.e. $prefix/bin, $prefix/lib, $prefix/man, $prefix/share, etc.) that would be difficult to change for a large number of programs.
3. Linux lacks a good method for notifying programs of changes to files and directories.
The Solution
The proposed solution is this. Programs should be compiled normally, but with the "--prefix" setting set to a new folder. For example, /usr/src/build/$APPNAME would be an excellent choice. A standard build will usually produce the /bin subdirectory at a minimum, and optionally /lib, /man, and /share. From this folder, it is possible to execute the program by modifying the PATH and LD_LIBRARY_PATH. Now if we add a standardized shell script executable (say /execute), we now have a method for executing something inside of a given directory.The job of the execute script would be to investigate it environment, then set up any environment variables that would be needed by the program, For example, most programs have their own variables for identifying where the information stored in /share is kept on the file system. Once the execute script has configured the environment, it will then launch the primary executable. Note that this method quite handily allows for non-native applications such as WINE and Java apps to use the same system.
We now have a highly portable method for executing applications.
Single File vs. Directory
Of course, we have not yet finished solving all of the issues listed above. While point 2 has been effectively addressed, points one and three still loom large. Surprisingly, point one can be quite easily addressed if we ditch the use of folders and move directly to using a single file instead.
If you're scratching your head at that last statement, don't worry. I haven't lost my mind yet. There is a method under which we can have a single file for an application without sacrificing the AppFolder concept we just discussed. Consider for a moment if we created a disk image of the application folder. We'd now have a single, portable file that could be moved to any Linux system. The target system can mount the image, and run the application by calling the /execute script.
The execute script becomes even more important for cross-platform binaries. The script can attempt to detect the architecture and execute the proper binary. The advantage of this method over using the ELF support, is that cross platform compilers are not necessary. The binaries can be compiled on each system, then combined into a single AppFolder/Disk image.
Things aren't all roses, though. If we're going to move to an AppFolder design, then we need to find a method for loading information about the file. For example, what icon should be shown for the disk image? The obvious solution is to detect when the file first appears on the system. Whether it be through the graphical desktop or through a more advanced apparatus such as dnotify (Linux directory notification support), the file should be detected, mounted, the meta-information read, then unmounted. More in the next article about where that meta-information might be stored.
Additional Features
Assuming that a routine is used to detect the type of disk image prior to mounting, a large number of file system features can be supported. CramFS could be used for a read-only compressed disk image, while ext2fs could be used for a writable image (perfect for time limited software). It's even conceivable that an image format could be developed with support for growing the image/file system, password protecting an encrypted disk, and other features only available in a format such as this. Even the existing abilities to freeze the software (no user damage!) and carry information around with the application are very powerful features not seen on other systems.
Existing Work
Unsurprisingly, some work has already been done in this area. Rox Filer has incorporated AppFolders for some time now, though the application selection is still quite small. Klik is a bit newer and has introduced CMG files - an application packed inside a CramFS filesystem. Last but not least, GoboLinux has taken on the challenge of building a stable Linux system that separates all binaries into per-program folders. Hopefully this article will help bring some visibility to these projects, as well as provide useful ideas for their future direction.
Next up, Part 3: File Management
Links:
Rox Filer
Klik
CramFS
GoboLinux
posted by AKAImBatman | 8:38 PM
<< Home