Originally, I had intended to write a long, detailed article explaining how to write translators for the BeOS. However, I discovered that such a task would require a great deal of work as well as organizational and literary skills. Instead, I decided I would share with you some things that I've learned while working on the OpenBeOS project. What follows is the list of these things in no particular order.

BeBits is awesome.

There are so many useful apps on BeBits it is crazy. Without these applications, it would have been much harder to get things accomplished. The ones that I use most frequently for development are BeFileGrep, SP-Calculator and HexJuggler . BeFileGrep is great for searching through header files, the Be Book and the Be Newsletters. SP-Calculator is great when I need to do some math and I've found it particularly useful when developing translators because it helps me convert from decimal to hex and vice versa. Lastly, HexJuggler is great hex editor, and it would have been hard to debug my translators without it.

The Be Newsletters are a wealth of information.

There is (was) a ZIP file of all of the Be Newsletters at ftp.be.com/pub/webarchives/BeNewsletterArch.zip. I downloaded and extracted this file to my hard disk so I could easily search through it with BeFileGrep. When I searched for articles about the Translation Kit, I found four of them: Volume II, Issue 26: "Getting Your Translator Add-Ons to Use the Translation Kit" by Jon Watte, Volume III, Issue 38: "Translation Kit Part I: File Panel Fun" by Daniel Switkin, Volume III, Issue 42: "TranslatorPanel: The Revenge" by Daniel Switkin and Volume III, Issue 44: "Translation Kit Add-Ons" by Daniel Switkin. You may find what you are looking for in there as well!

The bdb debugger is extremely useful.

I never knew that BeOS R5 Pro came with a graphical debugger until long after I bought it and months after I started writing code for the OpenBeOS project. I would have saved so much time and effort if I knew about it sooner. You can find bdb in /boot/develop/tools/experimental/debugger/. BeIDE will launch bdb for you when you build your application for debugging and choose Enable Debugger from the Project menu. However, when you are writing something like a Translator Add-On or want to debug a library, such as libtranslation.so, you will want to run bdb manually, and attach to a running process. For example, I recently had problems getting my TGATranslator to write out TGA images. The problem was, I didn't want to write a whole driver program just to debug my TGATranslator. So, I launched ShowImage, then I launched bdb and in bdb's Running Teams window, I double-clicked on ShowImage. At this point, bdb was attached to ShowImage, which had loaded my TGATranslator, and I was able to set breakpoints in my TGATranslator code and properly debug it.

The BeOS is fun to develop for. Really, I'm not just saying that.

Before I joined the OpenBeOS project, I spent a great many hours, across several years, learning Windows programming and developing software for Windows. What I learned was that MFC was pretty much useless and if you wanted anything to work well you had to use the Win32 API functions and structures instead. Also, if you wanted to use the fancy controls that Microsoft puts in their applications, well, you have to write those yourself because Microsoft won't give them to you. I also had a terrible time sifting through the MSDN Library; finding a function for what I wanted to do was always time consuming and often fruitless. Many times, I found a Visual Basic function for what I was looking to do, but nothing for C++.

Although I was happy I could write software to use on my computer at work, the whole Windows development experience left a bad taste in my mouth. It is as if all of the Windows APIs are duct taped together, forming a giant gray sphere. That giant gray sphere isn't shrinking any either.

After I started writing code for the OpenBeOS project, it became more clear to me how unpleasant Windows development was. In BeOS, most everything I need to know is in the Be Book somewhere and if I can't find what I'm looking for by browsing through it with NetPositive, I can use BeFileGrep on the actual headers or on the Be Book itself. There is also the newsletter articles, which are helpful, as well as the sample code. Conversely, with Windows, I have to sort through a huge pile of irrelevant information or spend a lot of money on books, and even then I'm not guaranteed to find what I need.

Well, that is all for now. In the future, I'd like to write more about the Translation Kit and possibly [Open]BeOS development in general. I hope to help ease the learning curve and satisfy people's curiosity. But, for now, I have some programming to do.

Most of you are probably already aware of the existance of chkbfs. This tool checks the file system for errors, and corrects them if possible. Nothing is perfect, so you might not even ask yourself why a journaling file system comes with such a tool.

In fact, it wasn't originally included, or even planned to be included, in the first releases of the new BFS file system. It was added because there is a real need for this tool, and you are advised to run it after having experienced some BeOS crashes.

The reason you need this tool is both a feature of the VFS and a design problem in the BFS: if you delete a file which is still in use by another application, the file's disk space won't be freed until the last user closes its reference to it - until then, only the inode is marked as deleted, and removed from the parent directory, so that it can't be found or opened again anymore.

Since BFS supports only sequential transactions [see Note 1 below], it needs process two transactions to delete the file in such a case: one to remove it from the parent directory, and the other one to free the space occupied by the file. If it left the first transaction open, you couldn't process any write operations (which would require a new transactions to be started) to the disk until the other application closed the file, which is clearly not desirable.

If the system now crashes after the first transaction has been completed, and the second hasn't started yet, BFS cannot know that there is any space left to free - the system won't tell it on next boot (it had already fulfilled its job by telling the file system to delete that file). Journaling a file system does not address this issue, at least in BFS.

So the main reason for the chkbfs tool is to detect this unclaimed free space and put it back to the available free space. If you never use chkbfs, you would waste all the space which is occupied by those "gone" files (which can of course range from some kB to some GB).

There are two ways to solve this issue: BFS could maintain a special action log where it remembers which files should be deleted, and could completely delete the file on next boot. The other solution would be to allow multiple transactions at once.

Both are very desirable goals, and could be combined to improve the speed of BFS in several cases: the former could speed up any index (or directory) updates, because they could be batch processed, and independently from the action that triggered those updates. The latter because it could greatly improve throughput if you have several drives together in a RAID - which is currently not even possible in BeOS.

Unfortunately, the solutions to this problem would require a break in compatibility with BFS - and that's why we won't do this for R1 and we will still need this tool, even with the latest (and only) reincarnation of the BFS.

For later releases of OpenBeOS, we plan to develop a successor to BFS which no longer retains binary compatibility. Although both of these solutions could be explained in very few words, they are actually very complex to implement. And in the case of allowing multiple concurrent transactions, there is not a real need for in current BeOS versions.

You may also know of (or were forced to use) the forcerm command, which is able to delete files you can't access or remove in any other way - as far as I know, this one is not necessary in the sense of chkbfs, but is obviously a work-around for some kinds of bugs in BFS - at least there is hope that this one won't be necessary anymore :-)

Note 1 - Transactions are atomic operations on the disk: they are either done completely or not at all. A journaling file system achieves to guaranty consistent file system structures by performing only atomic operations.

*Apologies to the Rolling Stones

It is a fairly forgone conclusion that "something" has to be done about the burning of fossil fuels. From the environmentally conscious to those who seek to release themselves from OPEC's control, everyone wants out of the fossil fuel business.

The problem is that fossil fuels deliver energy with a (fairly) low pollution content, a reasonable cost and in a fairly convenient manner. Many of the alternatives (solar, biofuels, etc) are not exceptionally feasible at the moment.

What about electric, you may ask? Yes, electric cars exist and are commercially available. Ignoring, for a moment, the battery life (and nasty chemicals that make up said battery) and the issues with lack of power, it is worth noting that electric cars don't actually reduce pollution. They may well increase it! What? How can that be? Electric cars get electricity from power lines. Most power comes from the burning of fossil fuels. Additionally, a vast amount of energy is "lost", converted to heat, when travelling across power lines. Finally, the batteries, themselves, lose some energy over time.

So, if electric cars and solar panels aren't the solution, well, then, what is?

I think that hydrogen is. Why hydrogen? It is easy to make, easy to use and easy and safe to store. What? Easy and safe? Haven't I heard of the Hindenburg or the Hydrogen bomb? Sure, I have. As for the first, I would say that driving or flying around with a big bag of *anything* flammable is a bad choice. If you took the Hindenburg dirgible and filled it full of gasoline fumes and it ignited in the same way, there wouldn't be any news crews around to film the burning wreck - it would blow up in a far more powerful way. About a third more powerful. Yet we think nothing of driving around with 15-20 gallon tanks of unleaded underneath us. As far as H-Bombs, I think that it is safe to say that if a tank of hydrogen could easily become an H Bomb, the earth would no longer exist.

Hydrogen is easy to make - there are several approaches. My particular favorite is electrolysis - applying DC current to water to convert it to hydrogen (H2) and oxygen. The hydrogen is then burned, combining with oxygen in the atmosphere to make water. Nearly perfectly clean (some small amount of nitrogen is combined with the oxygen in this process) and so similar to gasoline or natural gas burning that little needs to change in our usage patterns.

But this leads us to an obvious question. Above, I point out that electric cars aren't the solution and that moving the pollution from the tailpipe to the smokestack is not all that useful. So why is H2 a better idea? Fair question. To answer it, we need a few facts. One fact is that about half of the electricity in the US is wasted in power lines. Resistance in the power lines causes loss of electricity. A lot in the US. That may seem strange to some who live in more densely populated countries; we waste a lot getting power to rural areas. The second fact is that we waste a lot in our houses. Your PC (and I know that you have one) has a power supply. Converting AC to DC. Well, you might ask, why do you have AC power coming in? Because that is what the power company sells you - that is what they can transport cheaply. Your power supply gets warm in the process - that is all waste energy, as is the power to drive the fan to keep the power supply cool enough. And this process goes on in many other appliances; florescent lights, for one. If you had DC (say, 12 volt) running through your house in addition to 120 volts AC, there is a potential to save equipment and electricity.

So, let's assume that hydrogen is the answer. How do we do it? My vision is this - you have a hydrogen tank on your property somewhere. It could be buried or it could be above ground. It is refilled by a tanker truck every 6 months or so. Maybe in a city it comes in a pipe like natural gas does today. A small tube runs to your garage, where your car is refilled every night. Another small tube runs to your generator. Yes, you generate your own electricity by burning hydrogen to turn a turbine. Heat from this process (augmented by burning more H2, if necessary) supplies you with hot water. A final tube supplies your furnace with fuel.

That's it. No power lines. No brown outs. If you have hydrogen, you have all the power you need. Pollutionless (for you, anyway), reliable, comfortable power. The energy company saves money, since they don't have to run power lines and build transformers and step down stations. Solar power can be deployed where it makes sense and the hydrogen transported where necessary. Most gas stations can be shut down. The roads don't smell like gasoline fumes. The price of oil plummets.