One thing that has struck me since the inception of the OpenBeOS project is just how good BeOS' user interface is, borrowing from the other Big Three - Unix, Windows, and Mac OS. GlassElevator has prompted a number of people to come up with concept screenshots of what would be a cool user interface for R2 to possess. There tends to be a lot of "guru-ism" in Interface Design without real research, and quite a bit of argument on such things, often prompting a rash of nitpicking over small details like "I don't like the drop shadows in OS X." I've discovered through a lot of reading and observing that something which looks cool isn't always what is in the best interest of the user and his productivity, which is really what most aspects of interface design are all about.

Empty Promises

Software companies make many promises - easier to use, more, better, faster, and a host of others. In theory, their products should provide a user the means to work more efficiently. When a deadline is tight or when under pressure, however, the user often finds himself wasting time "fighting with the computer" or going an entirely different route to arrive at a solution. An example might be when a college student needs to print out labels for a campus group but can't remember how to set it up and isn't quite sure how to find the information on how to do so. Not wanting to go through the effort of asking possibly more than one person to find out, the student ends up hand copying names and addresses, taking ten times longer than it would have by printing them on a printer in the computer lab. Why are computers difficult to make them do what we want? Generally because software developers spend little time on ensuring they have designed their products well.

Lazy Brains

Most Windows users have become so accustomed to the badgering we receive from Microsoft that we tend to forgetfully assume that there are better ways to work out there. An excellent editorial I read recently referred to the children's show Blue's Clues.

For those not in the know, Blue's Clues is very popular in the US, partly because of research on what keeps children's attention. In the article is a quote from Malcolm Gladwell's "The Tipping Point," which explains it all: "Kids don't watch when they are stimulated and look away when they are bored. They watch when they understand and look away when they are confused." It doesn't change when they grow up, either. Adults tune out when too much effort is required to understand a subject, which would explain why a general public library would likely find more usage of the book "Physics for Morons" than another which required some knowledge of calculus to understand.

Badly designed software is the same way. The only time I know a user will tolerate bad software is when he/she has no other choice. While Windows has its good points, it also has a long list of bad ones. The same could be said of Mac OS, Linux, or even our beloved BeOS. I suspect that the list of bad points in BeOS would be minor ones, but considering that I use it 95% of the time, I wouldn't be able to say what they are - one could say that I am too close to the window glass to see the spots on it.

Anthro What?

Anthropology is, in short, the study of how people live. This would include studying how people work. If a program is to make the user's job easier (that *is* our job, right?), then we as a developer community (coders and non-coders alike) must study how the user works using BeOS and how a user *should* work using BeOS for a particular task. A part of Extreme Programming is the User Story, where the *customer* writes around three somewhat general sentences about the needs of a theoretical user. By studying what the user needs to do, one can begin to understand what will be necessary to accomplish the task quickly and with the least amount of thought given to the question, "How do I make the computer do this?"

The Road Ahead

Designing a UI is easy. Designing a good UI is not, and it is also not a small task. It requires going far beyond making a mock screenshot of what it should look like. This is not to say that our new UI should not look good, nor does this imply that making concept screenshots is useless and/or unnecessary. To quote a conversation I once had with Guillaume Maillard (of BlueEyedOS), "The best software doesn't need a manual." Cool isn't always usable, but usable never goes out of fashion.

'YAKA': 'Yet another kernel article'.

What is all the fuss about. Isn't there more than just the kernel? Well yes, there is. It is just that, at this moment, OpenBeOS is not that far developed yet that it makes much sense to write articles about application level programming.

While it is true that a platform needs applications to be viable, there must be driver support for the hardware before application programmers can start writing applications. After all, who wants to use a system that only supports the most basic, low-end hardware? You would have to choose between a) a system that can run OpenBeOS or b) a system on which you can play DOOM III.

That is why it is important for OpenBeOS to get a lot of driver support. Anyone interested in writing drivers for BeOS/OpenBeOS should check out www.bedrivers.com to see which projects have already started, which drivers are on the 'most wanted' list and how you can help.

This article is a tutorial for anyone interested in writing drivers or APIs for drivers. It extends upon the article of Michael Phipps in newsletter 18. In the article, he explains the functions that have to be exported by a driver in order to be able to be used. You should read it first.

Most devices in a computer communicate with the kernel via some protocol. This can be done via USB, PCI, AGP or ISA, but the exact method does not really matter. On an abstract level it is just a matter of reading and writing registers. The difficulty lies in knowing when to read or write which registers with what values.

While it is possible for an application to connect directly to a device driver, there are a couple of reasons why that is not such a good idea:

• Device drivers are interfaced on a very low level. Every application developer that would want to access the device would have to completely understand the device driver.
• Device drivers run in kernel space. A wrong pointer can crash the whole system. In testing my tutorial driver, I crashed my system twice on a stupid copy and paste error. In BeOS, the BSOD (Blue Screen Of Death) is white, not blue. :-)

For these reasons it is a good idea to build a shared library with an API for a specific device driver. Doing this has the following extra advantages:

• You can make the API class based. This makes it easy to use for application programmers.
• You can implement exception based error handling.
• The API will run in userland. Everything that crashes there will not affect the kernel.
• The API can restrict access to the driver. That allows for higher level synchronization, and also takes a lot of synchronization issues out of the driver.
• Not all code has to be in the driver. This is good, since the driver should be as small and performant as possible.

One of the difficulties with writing device driver is that it is not easy to get started if you haven't done it before, and that there is no easy way to test what you have created. (The most difficult part is getting documentation from the hardware manufacturer).

To help you become able to experiment with device drivers and APIs I created 3 sample projects.

The first project is the device driver project. The device driver simulates a device with registers that can be read and written. The driver exports a device called 'MyFirstDeviceDriver' in /dev/misc.

The project is excessively documented in the source code. Throughout the code of the device driver there are debug print statements that print information about what is happening in the syslog file. Note that it only does that if it is specified in the driver settings file.

The second project is an API in a shared library that allows class based access to the device. It is set up very simple to demonstrate the concept of creating a class based API for a device driver. Exceptions are generated as C strings. Better exception handling would include an error code, the name of the source file and the line number where the code occurred, and maybe even a text string that gives some more detail about the conditions that caused the error.

The last project is an application project that accesses the device driver via the API. There is not much documentation in the source code. It only demonstrates the usage of the API.

I had planned on adding a big red button labeled 'Do not push this button' that would cause a kernel panic, but in the last minute I decided against it. Most of you would push it anyway and hold me responsible for the resulting crash ;-)

However you can do it yourself as an exercise: define and implement a new IO control operation called op_KERNELPANIC, export it in the API and add the button and the message handling in the application.

Place these projects all along side each other in the folder ~/projects. This is because the include path was set that way. If you change the project include paths, you can place the projects anywhere.

You should be able to compile and build all of them without a problem. To be able to start experimenting, do the following things:

• Build all the projects.
• Create a symlink to the driver in ~/config/add-ons/kernel/drivers/bin and in ~/config/add-ons/kernel/drivers/dev/misc
• Create a settings file in ~/config/settings/kernel/drivers called 'MyFirstDeviceDriver'. Add the line 'set_debug = true' and save the file.
• Create a symlink to the shared lib API in ~/config/add-ons/lib

Using symlinks has the advantage that you don't need to replace the driver and library files each time you rebuild them.

Now you can run the application and perform some basic operations. You can follow all actions in the /var/syslog file. It receives the output of the debug statements in the driver code.

Source Code (Zip format)

Most of sports (I have been told) is mental. There really isn't much difference in professional sports, physically, between a winning team and a losing team. If you compare the "statistics", you will find that the average sprint time, weight lifting ability, that sort of thing to be similar between a great team and a team that is shut out all year.

So what is the difference between a winning team and a losing team? Focus. It is a normal part of human nature to become easily distracted when you have been working long and hard at something. In sports, coaches help their players to deal with this. In OBOS, we have project and team leaders.

It is important for us to stay focused on the goal as it approaches. And I do believe that it is approaching. Kits are getting finished and, as they get finished, their team members are moving onto other teams to get those teams finished, too. Daily CVS changes are accelerating and moving more and more toward finished functionality. Lots of progress is being made.

One of the key resources that OBOS has had, in fact our first resource, was the mailing list (openbeos@freelists.org). There has been some loss of focus on that list as time has gone on. To some degree, this is a result of success. There are more than 500 members on that list. Imagine that - 500. Everytime someone responds to that message, a server at freelists.org sends out 500 copies of that message. As lists grow, their dynamic and needs change.

I saw this with Be's lists. bedevtalk started out as a very small list. It was *common* to see Be's engineers posting long posts explaining things. Most, if not all, of them read the list. This is back in the DR8 days, when all of the devs owned BeBoxes. Everyone on the list was a dev who invested big money ($1500 or so) in buying a computer system that ran only an untried and untested OS. These were hard core people. I learned a *ton* from that list and hopefully contributed some small amount.

The dynamic on the OBOS mailing list has changed, too. It started out as a discussion of where to go and how to get there. Eventually, the key developers made the decision to persue the path that we have embarked on - to clone R5 for a first release. With that topic settled, we moved on to other things - the nature of the OS and that sort of thing. Technical questions and issues abounded.

Lately, though, there have been more and more issues on the list that were not of interest to most of the developers. Some have dropped the list and others have privately mailed me and asked me to intervene. It was brought up, on list, that there was no charter. This is completely true. When we first started, there was no need for one. I consider this to be a growing pain and it has to be dealt with in that manner. This is not a charter to hurt anyone. It is a charter to help keep things appropriately on topic so that the mailing list is productive for everyone. The mailing list is a tool to facilitate OpenBeOS.

So, without further ado:

The OpenBeOS Mailing List is a forum for the discussion of:
Design, coding and testing issues of OpenBeOS and
Discussion of "general business" - issues concerning administration of OpenBeOS the organization

Topics like naming the project, donation discussions and that sort of thing are on topic. Discussion of licensing issues around OBOS are marginal, leaning toward off topic. Politics are definately off topic, as are announcements of BeOS related things (i.e. "Hey All - we just released BeFoo 1.0"). This is a development and organizational list. Not a "all things vaguely BeOS related list". Be had BeDevTalk and BeUserTalk for a good reason. Think of openbeos as similar to what I presume Be had as an internal mailing list "All Be Employees".