Linux Appliance Design 53
s1axter writes "A week and a half ago I received Linux Appliance Design by Bob Smith, John Hardin, Graham Phillips and Bill Pierce, published by No Starch Press. This is one of No Starch's latest titles and was released in the beginning of April. As a hardware/embedded systems guy I was really eager to get my hands on the book. For those who don't know what the book is about, it's about making an application specific utility, an electronic tool or "appliance" that can be used for a specific task. The book defines an appliance as "A device designed to primarily perform a single function" and that's exactly what they do." Read on for the rest of S1axter's review.
| Linux Appliance Design | |
| author | Bob Smith, John Hardin, Graham Phillips and Bill Pierce |
| pages | 344 |
| publisher | No Starch Press |
| rating | 9 |
| reviewer | s1axter |
| ISBN | 1-59327-140-9 |
| summary | A text on developing an application specific device, very informative |
The book revolves around Laddie, an example alarm system for a building. The book includes a complete explanation of the system, what design features it uses, and a LiveCD with the final application for your hacking pleasure.
I have to say, Linux Appliance Design is well written and very, very thorough. This is not a beginner text, the authors focus on Linux programmers who understand C and Linux systems and want to take it a step further than conventional software. If you think this is a book for you, you should be a C/Linux guru, or dust off those old textbooks and brush up on your stuff before you pick it up.
When a friend asked me what was in the book I gave him the response, "Everything you need to make a sweet daemon with any interface you want". This is exactly what Linux Appliance Design is, a library in a book. Nostarch.com has a chapter list for the text, so you can see what I mean.
The layout for the text is well organized and starts where every project should, architecture and design. Personally I felt the authors were beating the dead horse after a couple of pages when everything kept coming back to separating interface from implementation, but hey, it's an important point that a lot of people seem to miss.
An interesting chapter is the explanation of the Run-time-access library the authors developed. Modeled from PostgreSQL, the RTA lib is an impressive solution that allows for daemon communication and configuration from any language that can talk to a database. This library is released under the GPL and can be downloaded from the companion site of the book The RTA is also used for the rest of the book, so don't skip it or you'll have no idea what they are talking about.
The text is not only an explanation of the Laddie system using the RTA, it is an all encompassing design text, which I really like. There are chapters dedicated to building different frontend UIs for the system and communication protocol discussion. This is what transforms the text from book into library. Each chapter can almost stand on its own as an application of that language or program. I was quite impressed with the web interface chapter and how the authors compared web servers and designed a system, and also with the framebuffer chapter on how to make a cool graphical interface.
A common theme for all the chapters is the structure. The authors discuss and design each element they use in the system before looking at one program or daemon. For anyone who has written or read development reports the format is very similar; explain what you designed, why you chose those components, why you passed on others, how the systems works and finally what you would do different next time. This format kind of reminded me lab reports in school, cover all question you think your professor audience might ask.
Overall Linux Appliance Design is a well written, detailed and thorough book with a lot of information. I would recommend this title mainly to someone who is interested in daemon development or server design however it can be read by anyone who wants to see a full project develop cycle.
s1axter is the main poster for Geeksinside.com. Geeksinside.com is a DIY, hardware hacking, technology blog that showcases links, reviews and project
You can purchase Linux Appliance Design from amazon.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
Nifty book (Score:3, Interesting)
Perhaps useful for some systems (Score:3, Interesting)
Many embedded systems need very high levels of responsiveness (sub-millisecond) which RTA is unlikely to provide. I've worked on Linux embedded systems that could reliably crank events within 50 microseconds, but that required the use of custom drivers.This responsiveness is why RTOSs and "no OS" solutions will dominate embedded space for a long time yet.
Could someone tell me why (Score:3, Interesting)
This paradigm was overwhelming to me when I was in corporate... this obsession of making simple things, like tying shoelaces, into a federal affair.
For years, I have used simple microcontrollers, like the PIC or AVR to do this stuff. For microwatts. Highly reliable, and I *know* exactly what I told that microcontroller to do. Simple things, like keep the soda pop cold and nag me if I need to service the vending machine. Tell me whats wrong. That sort of thing.
It puzzles me to see major corps use way, way, way overpowered/overpriced solutions to the simplest stuff.
These days, it only takes a microcontroller to do simple stuff, and yes, given a simple TCPIP stack, it commmunicates with the web, pooh, its not that much more than a UART for serial, no??? Especially given one can use IM type protocols for simple quick messages? Sending email is just a little step up.
I shake my head in pity when I see people trying to use sledgehammers to swat flies.
Is this just me, or does every other thinking person on Slashdot see it too?
Re:Could someone tell me why (Score:3, Interesting)
For my final year project at university, we were three groups working on robots to map obstacles in a room. The other teams went all out with FPGA boards and fancy high-tech hardware and bluetooth communications. One team had spent in excess of 1500$ on their hardware.
My team went with a swarm robotics approach, and we built several cheap drones. They were powered by ATMega8's, using cheap RF modules. Total cost? Less than 400$ total for four drones. Now, guess which team had something moving and working?
Simplicity goes a long way in getting things done. You get to know the ins and outs of your hardware and firmware. If something goes wrong, it's a lot easier to debug. The other teams spent countless hours just figuring out how to send data via bluetooth.
Re:Linux runs on a lot (Score:2, Interesting)
But, if I am gonna replicate millions of 'em, I try like the dickens to make a clean design, especially minimizing product cost and dependence on anything proprietary that may cease to be supported over the design life of my product.
Figure 50 years for a sodapop dispenser. Think I'm kidding? I can show you sodapop dispensers made in the 50's STILL IN SERVICE.
I can also show you trash bins of perfectly good computers, thrown away, because one company in particular is withdrawing support for their older OS.
And THOSE are less than ten years old!
It would grieve me for my soda pop machines, with perfectly good vend and refrigeration mechanisms, to be forced into retirement just because some big software company decided to obsolete their OS.
I just had in mind a simple soda pop machine controller... with a simple TCPIP stack which would daily IM me and report how much pop it had, how much money it had collected, the temperature of its pop, etc, or in the case it thought it was being violated, it would IM me for help.
Microcontroller programming is NOT complicated when you know what you are doing.
Of course, if things aren't quite so simple and I need a fullbore computer, my next choice would be some realtime Linux kernel, VxWorks, or similar. Whatever I use, I need to make damm sure that I can support it, as experience has taught me that depending on anyone else to support me, over time, leads to ulcers more than anything else.
I maybe came down a bit hard. The book this article is about goes into the stuff an order of magnitude more serious than the problems I often go after.
I have seen just too many times things get way way way more complex than they need be, leading to stuff so complicated that its useless. If I cannot design simply, my customers won't use my product for the very same reason they leave "12:00" flashing on their VCR.