Footnote to Usability, hierarchies and IO-slaves

It appears that at least one person (Hi Peter!) seems to have misunderstood what I was saying at the end of my last post.

I'm not saying that a new hierarchy should be thought up to supplement (read: in addition to) the current unix filesystem layout. I'm saying that a new hierarchy should completely replace the current unix filesystem layout. This is what GoboLinux and OS X have done. This is also not the same as what system: does. system: is another layer on top of the underlying filesystem layout, which leaves you with a system with a split personality. The GUI presents one version of what the system looks like, while everything below the GUI, such as console programs, uses something completely different.

As for the unix filesystem layout being great for sysadmins and programs, *ahrhumm* I beg to differ. :-) Personally I think it is a relict from the past that should be done away with. To put it lightly. Seriously, the scattergun approach to installing software is a liability requiring dedicated software such as RPM to manage just where the h*ll everything got installed. The only reason why it is still used is backwards compatibility. It has no place on a desktop machine.

(It is probably best that no one ask me what I think of shell scripts. ;-) or what I think of the idea that unix was based on the idea of "small tools doing one task well", emacs and perl anyone?)


One project I keep returning back to, but never actually trying out, is Zero Install, a projects which originates from the
ROX desktop

Curiously enough, one of the implementations of the system (the scarily named Injector) is in Python, though the GUI is written with PyGTK. Maybe it's time to polish those PyQt coding skills, or even conjure up a kioslave for KDE users to use.

By davidb at Tue, 08/16/2005 - 10:52

You sound like you never read up why the software gets installed this way. The approach may be not userfriendly in the sense that you have to grasp the concept, but it's simple and cleanly organized. There's nothing bad with it as you try to tell us.

By carlo at Tue, 08/16/2005 - 13:08

Furthermore, many would posit that when a graphical environmant does its job correctly, one never needs to know the underlying structure.

Consider this: As a systems administrator, I should know the nuts and bolts of the system I am using. Since that is true, it should be expected of me to learn the ins and outs of the somewhat crufty LSB layout. But if I am Joe User, there is really no reason for me to be mucking around in a console. As a matter of fact, I would argue that most Joe Users shouldn't even know the console exists.

Don't get me started on the init+cron+etc system though... rc scripts should definitely be tossed. I thoroughly beleive that Apple is on to something with their unified program launching daemon.

By you at Tue, 08/16/2005 - 13:57

System Administrators are concerned with, what's installed, how it's configured, how it relates to other pieces of the system and how things are chugging along.

In gobo it's easy to know what's installed, you can very easily control what libraries it uses and so on and configuration is basically the same. It's merely a, "if it's this, go here" mentality.

Now if we could get off this "free form" text config file garbage and move to a structured system, eg. xml, everything would be easier to parse and configs could even be patched without a lot of user handholding or a stupid amount of custom tools. Heck you could even have data validation which would reduce mistakes.

If your system is so borked that it won't boot, you can do a full or selective restore from backup, or you can boot the system up with live CD or what have you, and it can be custom tailored to your particular system if you feel like it. So I'm not saying load something as huge as knoppix all the time.

As for rc scripts, well, gobo is one of the few distributions that use runit, it's a bit better, have a look, at the very least the boot times are lightning quick. It's been blogged about by Robert Alsina (SP?) here planetkde.

By S at Tue, 08/16/2005 - 21:59

I too used to think that the OSX filesystem was completely redesigned, until I had occasion to use a Mac for the past couple of weeks. If you look at the root drive in Finder, sure, all you see is System/ and Users/, etc... but if you run "ls -l /" from the term, you'll see the standard UNIX hierarchy. There's even an etc/ dir with rc scripts!

By jaykayess at Tue, 08/16/2005 - 14:33

yes, first thing i thought when reading this blog entry was that Simon hasn't ever used MacOS X very much ;) perhaps he has used it a bit and the OS does such a good job of hiding it's UNIX roots that as a regular user he didn't even notice.

what's nice about having the old UNIX hierarchy there is that you can then go and install UNIX software quite easily. the first time i did that was when i needed postgresql on a machine running 10.1. it went in like a dream

this is really where KDE needs to head as well IMHO: hide the details from the regular user very well. insulate them so they don't have to deal with more complexity unless they _want_ to. and we can do it without dumbing down the system to the point that it's no longer useful (OS X being a case in point there)

our biggest challenge is that we don't have the luxury of controlling the underlying OS. this also a great benefit, however, as it gives us greater coverage than Apple can ever hope to achieve.

By Aaron J. Seigo at Tue, 08/16/2005 - 16:27

I've read a reasonable number of articles about OS X when it came out, but you guys (gals?) are right. I have not used OS X on a daily basis.

Some quick questions. How does OS X differentiate between hidden (bin, dev,etc) and normal dirs (System) in the root dir? So basically OS X support unix style software installation alongside their drag 'n' drop app-folder feature. (What is it called??)

Now, my motivation for starting this thread still remains. To me at least it looks like people are creating extra io-slaves by the day without stopping to think if it is really such a good idea or whether it improves overall usability in KDE. Maybe the bigger picture / strategy has been well thought out, but I don't see much evidence of that. This makes me nervous.

For example. Creating a new "root" dir to present to the user (like system:) which contains easy access to things like disks, cdroms, media, the home directory, maybe settings programs too, could be a really good idea if done right. But doing this impacts other things as well, like the location bar in Konq. A location bar that doesn't show the path to where something is (i.e. home:/, settings:/, or even music:/), isn't very useful. Ok, maybe that means konq should by default not show the location but instead act more like the traditional MacOS (a.k.a. Gnome spatial mode) with each virtual folder opening up in a new window.

Right now I see more of mishmash of different idioms and interaction styles that seem to be headed towards confusion and contradiction for the user.

For the record, I'm not saying that KDE should support one and only One True Interaction Style, it is way cool that KDE can accommodate so many different styles and ways of working. Even the single-clickers and double-clickers alike can feel comfortable with KDE. ;-)

(Aaron, I didn't follow your last point about 'coverage'.)

By simon edwards at Tue, 08/16/2005 - 19:33

Creating extra io-slaves by the day without stopping to think if it is really such a good idea or whether it improves overall usability in KDE.

Exactly, and keep in mind that KIO-slaves can't be accessed by shell utilities and non-KDE apps without doing some serious modifications to those apps, modifications that their maintainers are often unable or unwilling to do. This is especially true when it comes to network file access (see this long thread).

But doing this impacts other things as well, like the location bar in Konq. A location bar that doesn't show the path to where something is (i.e. home:/, settings:/, or even music:/), isn't very useful.

You're right again. Why should Konqueror display media:/hdc/song.mp3 in the location bar when in fact that song is mounted onto the root file system at /media/music_cd/song.mp3?
There's no reason to hide a file's location on the filesystem like that, especially when the physical location makes as much sense as the “virtual

By vladc at Wed, 08/17/2005 - 02:01