OSNews

This post will be long and somewhat critical/negative. This is by necessity in both cases and it should be noted that no malice is intended.

I have given some thought to a lot of the same issues as mentioned in the article with radically different conclusions (mostly). I wont go much in to what I think but instead try and focus on what makes the article's solution good, bad, or in need of some more thought (a lot of this).


Everyone has his own idea about what makes a 'perfect' OS--or should we just say a better OS? One reason we don't have one like the article describes is that everyone has a *DIFFERENT* idea of what's better.

To me, most of the things he talks about would be VERY BAD! Giant leaps sideways and some backwards. I do *not* want my computer to 'adapt to context'. Context is irrelevant. I will decide what I am doing and TELL my computer that. It should not assume!

Example: Suppose I do go to a directory of audio files. Do I necessarily want itunes-type functionality? Maybe I want a mass tag editor. Maybe I want to zip them up. Maybe I want to do a lot of things. The computer probably *cannot guess what I want* and should not try!

What he's really asking for here is de-monolithicizing (if I may coin a terrible word) which is what BeOS does that's so good. The application should treat things that can be files as files, because that makes application interop much easier (and more logical!). Contrast to Outlook PST or even Mozilla style mail handling and BeMail is obviously superior. But, making Explorer become a mail app when viewing a mail directory... no. No! I don't want to mark my directories as "for mail" or "for pictures." This is tedious, like nepomuk tagging is tedious, and tedious things just get ignored. I don't want the system to 'guess' the way e.g. Windows Explorer now guesses what view mode to use by default based on some of the files in the directory. I don't want browsing to my mail folder to auto-load a GUI I don't necessarily want, wasting my time and computing resources.

The article's passing praise for spatial file management is suspicious and an indication of one major way in which I will always disagree with the author.

2.1 Managing Applications

Oh, horror. I agree that "no branding" is good and generic names are better... when you only have one application of any type and when the difference between types is clear-cut. In utopia there's no conflict, but we do not live in utopia.

Text Editor - vi or emacs or notepad? Wait, what about Wordpad? Or is that Word Processor? But what about Word? No, what about ooo-writer?

Okay, so let's say we only have one good one installed at a time. Which one? What happens when I invent a better way of doing e.g. a music app, because I am a genius like that. Suppose I write it in C and the current one is written in Java. I can't just patch the existing one to be like mine (maybe I do not know Java). How do I use mine instead? How do I have them both installed while testing/troubleshooting? What happens if a user wants to use mine today, but their old one tomorrow?

Example: I download the adobe ebook reader and it appears as "E-Books." But, Adobe doesn't support the format used by my favorite e-zine provider! So, I download their E-Book reader and...? Now what?

2.2 App Folders

Preference data is user-generated data. Ignore this fact at your peril.

Games internally store save files? But what about multi-user systems? Are we back to the old "only 4 save slots, sorry" syndrome? What about copying games to a friends' system? What about the fact that game save files are often HUGE?

3. A Better File System Hierarchy

Restricting users to only user data is more or less done today. In Windows you just never leaver %userprofile%, in *nix you never leave $HOME. KDE and GNOME are pretty good about showing you just your home. Now, granted, you could do better at hiding the rest of the real system... but it doesn't require much work on existing systems.

All that said I think it's a bad idea. If you make things discoverable people who want to learn will learn. Just make them hidden-in-plain-sight such that users who don't want to learn will know not to get themselves in trouble. If you are too good at hiding complexity the next generation of developers never emerges...

If you really want to make things simple for the user why don't you get rid of the f--king desktop? Why would you want *devices* on your *desk*? The desktop metaphor is old and very, very broken. Trying to make software work more like the metaphor is as useless as trying to keep extending the metaphor further. This is a real area where a little well placed innovation would be worthwhile. Hint: I have never used a file folder in real life, I don't keep things in desk drawers, I don't have a desk that does anything other than hold a keyboard and monitor... and I probably represent the leading edge here.

The reality appears to be that BeFS is the closest thing we can currently get to a Database Filesystem. Remember Microsoft failing to get WinFS working? That's because this is really, really hard. So, assume you can't get a better technical answer than BeFS and build your better FS layout on its capabilities.

4. A Better File System and File Types

BeOS, as I recall, already stored the mime type of each file as an attribute in the FS. This is what you want, just have a mime-like attribute that stores a less specific mime type (e.g. text, not text/plain) and you're mostly there. Decoding and decomposing other data from files as they are saved would be helpful, I suppose. Would the import process actually te-tag MP3s? It's an interesting idea. You could not guarantee an ability to understand every kind of file that exists, nor are there ways to actually remove some kinds of metadata from some kinds of files. Example: PNGs could save a lot of header information in the FS, but it would not really be a PNG at that point.

The idea of auto-decomposing and recompiling metadata as the file moves in and out of the system is interesting. So far it's the only thing I've heard that would be useful, however impractical. On we go.

5. RISC OS’ Menus

The problem with context menus are well known, I will mention a few:
- not very discoverable
- quickly grow huge (think Windows Explorer's after you've installed a few apps. If you think this would not happen... well, think what you like)
- slows down interaction
- usually hard to access without a mouse
- did I mention really slow?

That said, maybe RISC OS had some answer for this that would survive leaving a niche OS without a lot of chaos. I never used it, so let me know.

6. Viewing / Editing Files

Again, some issues exist.
- I have GIMP and PhotoShop installed. What verbs will be used to differentiate them?
- What if you have a photo-retouching app and a painter app. Both could open images. Which one is Edit depends on who you are, so which is Edit? (And what is the other called?) You could say "Retouch" and "Paint" but sooner or later this question must be answered for the generic case.

7. Window Management

The way to avoid minimize/maximize, etc, is to use a modal interface and multiple desktops/modeviews. I know people will cry "heresy!" but this is the answer I have. No matter what you do you will need to accommodate:
- interaction between multiple app windows on the same screen
- one app consuming the entire screen
- switching between multiple full screen apps
- interaction between multiple app windows on different screens/modeviews.

Case: I want to see a tail -f style log window and a monitoring app for various I/O and my text editor for my code and my IRC client all at once.

Case: Then I want to play Quake 4 and pwn some friends.

Case: I am playing Travian (travian.us) and want to queue up 4 different attacks, requiring 4 different web browser windows with specific sets of tabs. This is a personal one, for me multiple desktops is good enough here.