DLIP: Desktop List of Installed/Installable Programs


    The DLIP (Desktop List of Installed/Installable Programs) is basically three parts:

    - .dlip file format

    - main.dlip central database

    - dlip-lib libraries and/or commands to access the .dlip

    The .dlip file format consists of two parts, the dictionary of commonly used names, and the list of programs.  The dictionary of commonly used names is mostly used to store the names of menus and to define URL types.  The list of programs is indexed and has a huge amount of information for each program.  The information for any field can be omitted, so you have as little or as much data as needed or available.  The format is binary (not human-readable), because human readable would take up too much space and processing and because binary should be very small.

    The main.dlip file is the crown jewel.  It lists all known programs with as much data as is available.  The first listing in the database (listing 0) will refer to the DLIP package itself.  Each program listing will contain the name of the program, description, URLs for download, MD5 checksums, dependencies, conflicts, menu listings, and more.

    The dlip-lib libraries will primarily read the .dlip files, look up listings, search for listings, write, and create new .dlip files.  Secondarily, it might scan for version numbers, installed programs, updates, and other changes.  It may download and install binaries or diff-patches or it may download, compile, and install sources.

    When the libraries are used alone, one can build his own proprietary list of programs.  Listing 0 can even be changed to reflect a different DLIP package server.  An operating system packager may wish to list only approved programs.  Red Hat, for example, is very security and reliability conscious.  They may choose to filter program updates through a proprietary .dlip file.  This differs from the current up2date system, because it can be used to verify programs that are not included with the distribution.  Normally, the libraries are either used with the main .dlip file (main.dlip) or with a slice of the file.  (File slices may be given their own index numbers, but that's currently not part of the plan.)

    The main.dlip file (remember, crown jewel) will list tons of information about all known programs of all types.  Why?  To add menu listings for currently installed programs, to provide a list of programs available for download, to compare installed versions with current available versions, and to verify that installed files have not been corrupted.  For the most part, the list is intended to be static.  The problem with regularly editing the file is that bytes would have to be shifted forward and back.  Of course, the list can be modularized to any extent, so theoretically, the file system could handle all the adding and removing of data by linking files, but that could cause a lot of fragmentation.

    (I'm considering making two versions of the list: The standard version of variable size and the huge file of fixed size.  The huge file would have a good speed advantage, since all entries and indices are in a standard location.  However, if the list has, say 100,000 programs, and if each program has 2K allocated to it, we're looking at 200MB of mostly empty entries.  The standard version file could be improved by adding a buffer to each entry, but that still ends up bloating the file.)



    After installing FreeCraft, dgen, Dark Places, a few other games, a few window managers, and Netscape 7.02, I would normally not make any menu entries or quicklaunch icons, because it's quite frustrating.  Netscape, for example, gets upset if I try to start Netscape with a profile that's already open.  There is a way to launch new browser windows in a running profile, but I don't know it.  Dark Places doesn't seem to run from a launcher right, though it runs fine from a terminal window.  If I have Dark Places, that means I have XFree.  If I have X, that means I probably have a desktop or window manager.  If I have a window manager, I would probably prefer to launch stuff from the menu or an icon instead of from the terminal.  Why doesn't Dark Places automatically make a menu entry?  Probably because there are so many different desktops and window managers.  Should there be only one standard window manager?  No, that's not the Linux way.  ;-)  Instead, the window managers ought to have a very easy, standard way that they can, if they choose, locate programs and create menu entries.  Back in the Windows 3.11 era, Windows would search the drive for programs to create entries for in the Applications menu.  This was generally the same idea, but Windows would often misidentify files, because it only used the name of the executable.  If you have dm.exe, and it's something like "Dungeon Masters" or "Dexxa Mouse", Windows is likely to list it as Disk Manager.  The DLIP idea is just the logical solution.

    While deciding what information ought to go in the list, the whole idea became more important very quickly.  For someone new to Linux, downloading, compiling, and installing a program and making menu entries for it weighs in against the free price tag on most software.  If successful, the DLIP project would put software installation for Linux way above any Microsoft or Apple OS in simplicity.  (I have faith in Apple that they will adopt and embrace DLIP and probably the open-source public-domain community in general.  Microsoft, however, has really dug themselves a trench as they battle against Linux, and that trench could become the grave of the software division.)


    DLIP's main advantage will be it's openness, as in not proprietary.  It's OS independent and modularizable, and none of the datem fields need to be filled.  It's intended to be used with the central DLIP server, but it can be entirely separate from the central server by simply changing the first entry!  If the DLIP format changed radically, downloading the newest version of the package would download the libraries which access it as well, which means that no incompatibilities will arise.


    DLIP has not yet reached it's first release.  Keep in mind that anything can change, but most likely more features will be added.

    -Standard way to search for installed programs

    -Keep your software up to date

    -Install programs from source or binary

    -Verify the identity (and theoretically condition) of executables with an MD5 checksum

    -Retrieve up-to-date documentation and other URLs, such as for online gaming

    -Never worry about package conflicts!

    -Never worry about dependencies!!

    -If the data is kept up to date, then if DLIP can't install it, it's probably very difficult or impossible to install.


    The DLIP package is intended to include just the libraries and/or executibles to read .dlip files and optionally the main.dlip database itself.  Preferrably, anything beyond that will be fielded by the window manager and desktop programmers.


    Benjamin Vander Jagt, that's me, came up with DLIP and submitted it as a public domain project on SourceForge.  You can reach me by telephone at 1(540)667-8388, by mail at P.O. Box 1398, Winchester, VA 22604, or by email at benjaminvanderjagt at adelphia dot net.  (Perhaps my next project will be an alternative email link, perhaps in the form of a GIF file, which spam bots don't read but which can be gleaned for information.)

    Many thanks to SourceForge who have the greatest, most well thought out service I have seen, at least in a long time.  The SourceForge team seems to be very wise and philanthropic.  If they're making profit with, I'd be even more impressed with their wisdom.  ;-)

Legal Stuff

    What legal stuff?  I'm releasing this as public domain.  All software should be public domain.