DSL, Rox, Inodes, Directions

DSL 4 uses dfm for desktop and file management. Previous versions used xtdesk for icons on the desktop and emelfm for file management (midnight commander is available in DSL 4 as well as previous versions). The change to dfm integrates the desktop and file management, which is definitely an improvement for those who run X.

I lobbied for a different direction for DSL. That direction would focus on increasing modularity. I saw that as a reasonable evolution.

The problem was in the execution. First, I was told DSL has to remain useful off the CD. I would’ve traded utility for updating the kernel and base libraries. I didn’t see this as a net loss considering how most users use MyDSL extensions to replace what DSL offers and DSL comes with a script that allows users to create their own MyDSL CDs. What I proposed wasn’t too far from this.

Second, I would’ve moved desktop management to rox. This was shot down over issues related to older hardware and too many inodes from rox’ application directories. The developers also didn’t seem to like the fact that the executables would no longer be called by their normal names but rather AppRun. All of’em!

I didn’t see that as a hindrance at all, particularly when considered in the context of my previous point about modularity.

My solution isn’t unreasonable or impractical.

  1. Recompile applications as compressed ISOs so they use /opt/Apps for their “menu” directory. This isn’t so strange since DSL’s UCIs go to /opt already. The only thing that would change is the prefix (/opt/Apps/name) and the bindir (it would need to go to the same parent directory). So if you compiled application “foo,” your binary would be /opt/Apps/foo/foo instead of /opt/Apps/foo/bin/foo. Then the binary foo would be renamed AppRun — making the directory executable in rox.
  2. Apps would remain compressed until a user chose to use them. This should mitigate any concerns about inode issues. Why load firefox uncompressed if it’s not being used? Especially if it the user chooses another browser.
  3. What about for users who don’t run rox or need to use an extension and don’t want to type /opt/Apps/foo/AppRun? Easy. Symlink that binary back to /opt/bin/foo. You don’t need /opt/Apps in PATH for that, and DSL already sets up PATH to include /opt/bin. Many MyDSL extensions already set symlinks there. How is that any less elegant than the status quo?

Since the applications would all be bundled up in their own directories, users who install (frugal or hard drive) could discard them in favor of applications they prefer. You use thunderbird instead of sylpheed? Delete sylpheed, install thunderbird. This increases modularity. It also takes care of the question about inodes because each application is only one file until it’s loaded. That would reduce inode concerns since everything for, say, xmms would be isolated in /opt/Apps/xmms instead of spread throughout /usr like it is now. And it would stay one file (xmms.whatever) until loaded via click by the user.

There are two issues related to handling things that way, particularly console applications and applications that compile into separate binaries. They could be handled pretty much the same way they are now, via shell scripts. In the case of an application with multiple binaries, it also could be compiled without altering the bindir so that the binaries would be in (e.g.) /opt/Apps/foo/bin and then wrappers could be set up in ../foo.

It will take more thinking and a bit more work. I have a running start with it. I think the long and short of it is that it can be done.


Leave a Reply

Please log in using one of these methods to post your comment:

WordPress.com Logo

You are commenting using your WordPress.com account. Log Out /  Change )

Google+ photo

You are commenting using your Google+ account. Log Out /  Change )

Twitter picture

You are commenting using your Twitter account. Log Out /  Change )

Facebook photo

You are commenting using your Facebook account. Log Out /  Change )


Connecting to %s

%d bloggers like this: