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.
Practical Task Scheduling Deployment
One of the best things about the UNIX environment (aside from being stable and efficient) is the vast array of software tools available to help you do your job. Traditionally, a UNIX tool does only one thing, but does that one thing very well. For example, grep is very easy to use and can search vast amounts of data quickly. The find tool can find a particular file or files based on all kinds of criteria. It's pretty easy to string these tools together to build even more powerful tools, such as a tool that finds all of the .log files in the /home directory and searches each one for a particular entry. This erector-set mentality allows UNIX system administrators to seem to always have the right tool for the job.
Cron traditionally has been considered another such a tool for job scheduling, but is it enough? This webinar considers that very question. The first part builds on a previous Geek Guide, Beyond Cron, and briefly describes how to know when it might be time to consider upgrading your job scheduling infrastructure. The second part presents an actual planning and implementation framework.
Join Linux Journal's Mike Diehl and Pat Cameron of Help Systems.
Free to Linux Journal readers.View Now!
|The Firebird Project's Firebird Relational Database||Jul 29, 2016|
|Stunnel Security for Oracle||Jul 28, 2016|
|SUSE LLC's SUSE Manager||Jul 21, 2016|
|My +1 Sword of Productivity||Jul 20, 2016|
|Non-Linux FOSS: Caffeine!||Jul 19, 2016|
|Murat Yener and Onur Dundar's Expert Android Studio (Wrox)||Jul 18, 2016|
- The Firebird Project's Firebird Relational Database
- Stunnel Security for Oracle
- My +1 Sword of Productivity
- Non-Linux FOSS: Caffeine!
- Managing Linux Using Puppet
- SUSE LLC's SUSE Manager
- Murat Yener and Onur Dundar's Expert Android Studio (Wrox)
- Doing for User Space What We Did for Kernel Space
- SuperTuxKart 0.9.2 Released
- Google's SwiftShader Released
With all the industry talk about the benefits of Linux on Power and all the performance advantages offered by its open architecture, you may be considering a move in that direction. If you are thinking about analytics, big data and cloud computing, you would be right to evaluate Power. The idea of using commodity x86 hardware and replacing it every three years is an outdated cost model. It doesn’t consider the total cost of ownership, and it doesn’t consider the advantage of real processing power, high-availability and multithreading like a demon.
This ebook takes a look at some of the practical applications of the Linux on Power platform and ways you might bring all the performance power of this open architecture to bear for your organization. There are no smoke and mirrors here—just hard, cold, empirical evidence provided by independent sources. I also consider some innovative ways Linux on Power will be used in the future.Get the Guide