This is the second issue of ELJ to hit the newsstand on its own. The excitement started when we did an ELJ supplement attached to our sister publication Linux Journal last year, and it continues to grow.

We are still working on building the ideal editorial team to bring you what you expect in a magazine focused on open-source embedded solutions. This issue, the changes include my move into the position of editorial director and the addition of Dan Wilder as senior editor. Between Dan and I we have about a quarter century of experience in the embedded field spread over the last 32 years. Expect to see at least one more addition to our editorial team that will bring that number up still more.

When I meet with people and talk about embedded Linux, I continue to get asked, ``What exactly do you mean by embedded?'' usually followed by their guess. Better that we start with my guess, and if you feel I am off target, write to me and tell me why I am wrong.

If the person asking is nontechnical, I generally just say that we are talking about a system that doesn't have a keyboard or monitor. Not 100% accurate but a good starting point. After all, a huge majority of embedded systems fit into this category. If you question this, just think about the number of embedded systems in cars, traffic light controllers and microwave ovens on the low end. On the high end, take aerospace and start by counting everything from on-board avionics to air traffic control systems.

Another common question is, ``Are we talking real time?'' Real time is as slippery as ``Our product is better than the competition.'' A better term might be event-driven. For example, a smart telephone connected to the POTS (plain old telephone system) network is clearly an embedded system, and you could say that it is real time because it must respond when a key is pressed or the hook switch is operated. But, as you know, a human is using the keypad and hook switch, and you have a lot of time in terms of CPU cycles before you need to check to see if anything has happened. The mechanical world of milliseconds isn't going to tax the computer world of microseconds or fractions thereof.

I'm going to assume that most of our readers at least appreciate that there are possible hardware/software tradeoffs in most embedded projects. More specifically, responsibility for what might appear to be hard real time on the part of the OS can be shifted to hardware if that makes economic sense. Thus, in the example above, the user of the telephone doesn't care if you use an interrupt controller or poll the hook switch, as long as when they pickup the handset, they get connected to a phone line.

Okay, bottom line--we are talking about solving problems other than desktop computing, and our slant is in the direction of freely available software. By slant I mean that we are more likely to talk about a freely available solution if that is available, but we also appreciate that there are proprietary solutions that are the right tool for the job. For example, many systems will be designed with proprietary software, but the actual product will contain free software. Certainly, the opposite can be true as well.

In the next issue one of the topics we will look at is the use of embedded systems in industrial control. You will see some success stories as well as some HOWTO information so you can use Linux in your applications. Stay tuned.

Our web site (http://embedded.linuxjournal.com) now has discussions linked to every article. I encourage you to go out there and talk about what you are doing, what you like and what you don't like. In order to post to a discussion forum, you need to set up an account. Accounts are free and anyone can do it--we just want everyone to know who they are talking to.

Also, if you just picked up this magazine at a trade show or stole it from your coworker and aren't currently a subscriber, go to the web site and get yourself a subscription. Subscriptions are free to qualified people in North America.