Slashdot Mirror
Linux Appliance Design
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.
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.
I'll enjoy it along with beers from my linux powered refrigerator, making sure to switch off my linux powered cell and watching my wife enjoy herself with her linux powered vibrator.
Tux gets everywhere.
"it's about making an application specific utility, an electronic tool or "appliance" that can be used for a specific task."
So, in other words, in the future, I very well could run Linux on my Toaster!
"No freeman shall ever be debarred the use of arms." -- Thomas Jefferson
One thing I'd like to build is a lirc device that also acts as a power switch. So you can use a remote control to also turn the computer on. This could be useful for things such as a Myth box.
What about a Linux car?
:)
I know who would use Gentoo!
"No freeman shall ever be debarred the use of arms." -- Thomas Jefferson
FREE BEER??
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.
Engineering is the art of compromise.
and watching my wife enjoy herself with her linux powered vibrator.
First post and you have a wife?!? No way, buddy!
No one gives a shit about books
It shows from your post that YOU didn't seem to "give a shit" about books at all.
I think Slashdot could save some bandwidth by getting rid of Anonymous Cowards.
"No freeman shall ever be debarred the use of arms." -- Thomas Jefferson
Do I really need to state the obvious?
Toasting bread with your Linux toaster.. for Dummies
/usr/src/Linux and issue the command:
..... snip few pages later ....
/boot with the command /usr/Linux/src/arch/i386/boot/zImage /boot/newkernel /lib/modules. Next, edit /etc/lilo.conf to add a section like this /boot/newkernel
..... snip few pages later ....
Configuring For Toasting:
Change directory to
make menuconfig
This will build a few programs and then quickly pop up a window. The window menu lets you alter many aspects of toast configuration.
After you have made any necessary changes, save the configuration and follow these instructions--do a
make dep; make clean...
and then, if you are on a toaster slower than 200MHz, go and make a cup of tea. This takes about 20 minutes on a Pentium 90...the toasting kernel has a lot of source code as you may have noticed when downloading it. When this is complete do a:
make modules
This will not take as long.
Installing a New Toast:
Phew, finally! The last step is installing the new kernel to the right place in
cp
then
make modules_install
This will install the modules in
image =
label = new
read-only
At the next reboot, select the kernel 'new' in lilo, and it will load the new kernel. If it works fine, move it to the first position in the lilo.conf so it will boot every time by default.
Summary:
Preparing a toast with your Linux appliance is a relatively simple operation - if you have done it before! At first it can seem daunting, but well within the capabilities of today's average housewife.
Troll, troll, troll your post
gently down the feed
merrily merrily troll along
a life is what you need....
kernel: lp0 on fire
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?
"Prove all things; hold fast that which is good." [KJV: I Thessalonians 5:21]
the problem with many small devices is power... I read an article about "energy harvesting", so that you don't need power cords or batteries to make remote controls for things... this would be really cool for home automation!
energy for free
Back when I was at No Starch Press (an O'Reilly partner), I remember working with Bob Smith, et al. on this book, and it makes me happy to see that it's seen the light of day.
This marks the 2nd time in a couple weeks that a No Starch book has been featured here. I hope to see a bunch more.
-JM
Hyperic Community Manager
"All this fuss over a fullblown OS to do simple tasks?"
It's quite simple - use the best tool for the job. Sub-16bit microcontrollers are fine for a certain class of embedded devices. For others, they are completely inadequate.
It's not a case of using sledgehammers to swat flies. It's a case of using the best tool for the job.
The book itself isn't about a solution for an 8-bit microcontroller. It's for more sophisticated embedded devices. And in that, it provides a new and unique solution to simplifying what had been a much more complex problem.
Most 8-bit uc's don't require a CLI, Web and SNMP interface to them. That's what the book shows you how to do. I presume you're talking sub 16-bits, as UNIX has been around on 16-bit uc's since it was created.
Surely you don't rewrite your software from scratch every single time? That would be Just Plain Stupid. And time consuming with all the bug fixing. And take a lot longer time to market than just grabbing a Free OS and making use of it, and the wealth of tools which come with it.
And honestly, if you seriously think that a TCP/IP stack is just "not that much more than a UART for serial", I question your qualifications. Yes, you can do extremely simple stacks. They are of very limited use.
Why go to the trouble of maintaining your own TCP/IP stack, among lots of other stuff, when you can just throw Linux and an ARM or somesuch board together and go.
The vast majority of applications do not, and even most embedded systems don't. Also, IM protocols aren't really ideal for that sort of thing. Aside from being poorly standardized, they don't really offer anything that plain old smtp doesn't, and smtp can handle connection loss much better. If something requires immediate attention, SMS is better, in case you're not at your desk.
I'm not sure what exactly you plan to do with the knowledge that your coke machine is being molested.