What We Are and Where We're Going
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.
Getting Started with DevOps - Including New Data on IT Performance from Puppet Labs 2015 State of DevOps Report
August 27, 2015
12:00 PM CDT
DevOps represents a profound change from the way most IT departments have traditionally worked: from siloed teams and high-anxiety releases to everyone collaborating on uneventful and more frequent releases of higher-quality code. It doesn't matter how large or small an organization is, or even whether it's historically slow moving or risk averse — there are ways to adopt DevOps sanely, and get measurable results in just weeks.
Free to Linux Journal readers.Register Now!
- Hacking a Safe with Bash
- Django Models and Migrations
- Secure Server Deployments in Hostile Territory, Part II
- Huge Package Overhaul for Debian and Ubuntu
- The Controversy Behind Canonical's Intellectual Property Policy
- Shashlik - a Tasty New Android Simulator
- Home Automation with Raspberry Pi
- Embed Linux in Monitoring and Control Systems
- KDE Reveals Plasma Mobile
- diff -u: What's New in Kernel Development