Archive for the ‘rox’ Category

New Mouse, Rox Revisited

March 11, 2008

Got a new mouse so to put it to good use I decided to install rox-filer again. I’m using rox 2.5 from Debian testing.

I need to do some icon tweaking to reduce and standardize size. My new jwm theme (work in progres) is “pearl” and I’ll post it to my theme thread at the DSL forums when I get it all sorted out. I set up aterm and mrxvt to open maximized, no border, no title; I left xterm alone to “float” on the desktop.

The fourth icon from the left is my wrapper to force-resume screen. To reiterate my pro-WIMP point yesterday, one click on that icon sets into motion everything that it would take multiple keystrokes (and even tabbing for autocompletion) to do. The screenshot was taken and scaled with the same command from my ratmenu entry, piped into my jwm menu (vim rocks); I also have it bound to xbindkeys so I can press one button. Icons are messy and time consuming? I clicked on my home folder and dragged the icon for the image over the gimp icon on the desktop. Voila, I opened the image in gimp and edited ever so slightly.

My impressions of the updates to rox since version 1.2 (which is what I’ve used from MyDSL) are that it’s matured very well. It works fine in Linux even though the RISCOS-centric stuff like application directories aren’t exactly suited for Linux. Among the features that are different, I appreciate the customizable menus. I need to read through the changelogs and see what else has changed. I also have a lot of MIME-types to set up.

FWIW, I have more anti-WIMP window managers installed than I have ones designed for icons and menus and taskbars. And most of what I do in jwm is bound to keystroke (which I’m increasing even more since installing the bloated xbindkeys and related packages yesterday). I don’t agree with the arguments against WIMP because they tend to throw the baby out with the bathwater — there are sensible ways to configure systems to maximize productivity and ease of use. Menus and icons and all the rest can be part of that solution. Dogmatic objection to such use isn’t productive.

DSL, Rox, Inodes, Directions

July 28, 2007

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.

Latest Screenshot

June 20, 2007

I’ve added another page with a screenshot. Nothing fancy. If anything, it’s a few steps back from the direction I’ve been going.

I hope to have more time for blogging and working on more Rox stuff in the next couple weeks. Things have been really hectic the last month.

In Praise of “Obsolete” Computers

June 17, 2007

I came across an article comparing a MacPlus (circa 1986) and a brand new AMD DualCore. The benchmarks are timings focused on user experience — boot times, performing data manipulation in Excel, and performance running Word.

The two decade-old MacPlus — with its 8mhz chip and 4MB RAM (maxed out for this comparison) — performed admirably against the 2×2.4ghz (and 1GB RAM) computer:

For the functions that people use most often, the 1986 vintage Mac Plus beats the 2007 AMD Athlon 64 X2 4800+: 9 tests to 8! Out of the 17 tests, the antique Mac won 53% of the time!

I’m not surprised since the “most common uses” are generally things that don’t require much in the way of resource. Cutting and pasting hasn’t changed significantly in 20 years, and you don’t need amounts of RAM we associated with supercomputing back then to enter text into a word processing or spreadsheet application and then manipulate it. I still use text-based applications (spreadsheet, text editing/word processing, etc.) on computers without GUIs or in situations where I need to conserve the battery on my laptop. I’m not missing anything when I do that, aside from “eye candy” that requires system resources many of my computers lack.

As far as living on the bleeding edge goes, I’ve taken a strong stand that there’s no such thing as an obsolete computer. A computer may be at a dead end with respect to upgrading, but it’s still useful as long as it can boot and the requisite I/O devices (monitors, keyboards, drives) work.

One of the reasons I’ve become such a fan of Damn Small Linux is because of its focus on legacy support and its small size. It’s a modern OS, it’s just spared of the bloat that comes with other distros. I can do everything with the computer I normally use (with a 400mhz Celeron with 128MB RAM) that I can do on this newer machine (Athlon 1.4Ghz with 1GB RAM). The older, under-equipped (by today’s standards anyway) computer boots faster, is more responsive when not overloaded (running Open Office on it is a pain in the neck — and forget about using audacity on it ever again), and gets everything done the same way this one does. The difference is in the bloat. The newer computer runs XP (it’s dual boot, but I seldom use anything else on here) which requires a significantly greater percentage of the available resources than Linux (X11, oroborus, rox, etc.) does on the older computer. That accounts for what Hal Licino found in his tests.

Sure, there are things that require a GB of RAM and the efficiency of a faster CPU. I have applications like audacity, GIMP, and imagemagick installed the two computers mentioned above. There’s no way in the world I’ll ever use audacity on the older computer again, unless I find more RAM for it (and the same goes for sox, a command line equivalent to edit audio files). There are also some image-related tasks I do in XP instead of the old box for the same reason. But for running standard applications, browsing, etc., the old box continues to prove itself very worthy and it admirably performs those kinds of things on par with this faster box.

The problem more often than not isn’t the hardware, it’s the software. Another reason I like DSL is that I don’t have to rush out to buy hardware (upgrades or new systems) just to bring my computer up to date. I can wait for DSL upgrades or do my own (and the latter is usually the case for me — my system is no longer DSL, DSL was just my starting point). My kernel can be upgraded by itself. X11 can be upgraded by itself. My window manager (oroborus is my window manager of choice) can be upgraded by itself. The kernel can support new hardware if I choose to buy some, it doesn’t force me to go out and buy new hardware to make an upgrade. And best of all, the only “bloat” is the crap I chose to install. It wasn’t set there by default.

That’s in stark contrast to what Apple and Microsoft have done. I can’t run OSX on my old Mac (but I can upgrade its case with a Mini-ITX and then run Linux on it — stay tuned for an upgrade page if I do that). I can’t run Vista on my NT box or my “usual” computer (really can’t even run XP on the former, though the latter could limp along with XP). I think this computer would marginally run Vista. And at the end of the day, all the extra resources required to run the upgraded OS don’t increase my typing speed or enhance the ability to cut and paste, copy, etc., the data I work with.

And to be fair, I can’t let a lot of Linux distros off the hook with respect to the above paragraph. They’ve jumped on the bandwagon that expects users to upgrade hardware when they upgrade software. They ignore those who use functional legacy hardware. They make releases with the assumption that everyone uses 512MB of RAM, which is barely adequate for running their default environments much less flashy, spinning windows of doom like Beryl. Their focus is no longer on function, it’s on aesthetics. And it’s at the expense of system resources.

That’s appealing to consumerism, without necessarily increasing function at the same time. It takes the same amount of time to type a document and edit it now as it did in 1986. Consumerism doesn’t change that — that’s a constant. Consumerism may make older hardware difficult to use, maintain, or even keep, but it doesn’t make it obsolete. It’s still usable and useful.

RISCOS 5 Code Released

May 19, 2007

Castle, the company that sells Iyonix computers with RISCOS, and RISCOS Open have released the first batch of code for RISCOS 5. According to the last link, “The first set of components released by RISC OS Open and Castle comprises of major applications and modules that form part of the backbone of the operating system”:

These include utility CloseUp; desktop applications Paint, Draw and Edit; the RISC OS Filer and Pinboard; CDFS, various CD device drivers and CDFS Filer; the MessageTrans and BASIC modules; and Browse fetchers. The software is written in a mix of BASIC, C and ARM assembler.

Under terms of the license under which the code has been released, development is limited to ARM processors, meaning x86, PPC, and RISCOS fans using other architectures are locked out. For non-ARM users, rox is a very good, easy to use, and RISCOS-like environment (options can be set so it’s very familiar to RISCOS users).

Even More Rox Shots

May 19, 2007

I changed icons again and just uploaded more screenshots.