Welcome to the Slashdot Beta site -- learn more here. Use the link in the footer or click here to return to the Classic version of Slashdot.

Thank you!

Before you choose to head back to the Classic look of the site, we'd appreciate it if you share your thoughts on the Beta; your feedback is what drives our ongoing development.

Beta is different and we value you taking the time to try it out. Please take a look at the changes we've made in Beta and  learn more about it. Thanks for reading, and for making the site better!

Linux Appliance Design

samzenpus posted more than 7 years ago | from the do-it-yourself dept.

Book Reviews 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.

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. 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 is a DIY, hardware hacking, technology blog that showcases links, reviews and project

You can purchase Linux Appliance Design from Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

Sorry! There are no comments related to the filter you selected.

Looking forward to reading it... (5, Funny)

Anonymous Coward | more than 7 years ago | (#18931617)

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.

Linux rice (3, Funny)

Sneakernets (1026296) | more than 7 years ago | (#18931713)

What about a Linux car?

I know who would use Gentoo! :)

Re:Linux rice (1)

bobo mahoney (1098593) | more than 7 years ago | (#19026423)

Free cars that don't crash - I'm in.

yeah, but is it (0)

Brunellus (875635) | more than 7 years ago | (#18931773)



Anonymous Coward | more than 7 years ago | (#18932029)

and watching my wife enjoy herself with her linux powered vibrator.

First post and you have a wife?!? No way, buddy!


Anonymous Coward | more than 7 years ago | (#18932789)

and watching my wife enjoy herself with her linux powered vibrator.
First post and you have a wife?!? No way, buddy!

She could be... busy :-o

Re:Looking forward to reading it... (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18932085)

ur a gey peice of shite

Beowulf Cluster... ? (1)

Chyeld (713439) | more than 7 years ago | (#18932189)

Do I really need to state the obvious?

Re:Looking forward to reading it... (4, Funny)

$RANDOMLUSER (804576) | more than 7 years ago | (#18932225)

...and watching my wife enjoy herself with her linux powered vibrator.
Tux gets everywhere.
Well, I guess that explains why he smells like fish.

Re:Looking forward to reading it... (0)

Anonymous Coward | more than 7 years ago | (#18933279)

I actually believed it would explain why SHE smells like fish...

Re:Looking forward to reading it... (0, Offtopic)

EinZweiDrei (955497) | more than 7 years ago | (#18938741)

Alright, I know you're just bandying back with an old standard by making a vaginal/fish association, but who is perpetuating the fish smell meme, and where can I find him, so that I can destroy him? The taste and smell of a fresh vagina is the finest bouquet there is, and there is nothing piscine about it.

Re:Looking forward to reading it... (1)

Fahrenheit 450 (765492) | more than 7 years ago | (#18940763)

Of course, there's nothing piscine about the smell of fresh fish either (at least what one associates as a "fishy" smell -- I'd suppose the smell of fish in any condition is inherently piscine).

Re:Looking forward to reading it... (3, Funny)

WetSpot (874382) | more than 7 years ago | (#18932425)

So I guess she answers the question, "Got Root?" with "Yes, yes I do"

Re:Looking forward to reading it... (2, Funny)

Anonymous Coward | more than 7 years ago | (#18932639)

When used by only one user, the GNU/Linux vibrator can only run as "sudo". Two or more users, with gender of each user is set by user preferences, are required for true root access.

Rejoice! (1)

Sneakernets (1026296) | more than 7 years ago | (#18931629)

"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!

Re:Rejoice! (1)

repvik (96666) | more than 7 years ago | (#18936235)

You can run linux on beige toasters. []

Nifty book (2, Interesting)

jshriverWVU (810740) | more than 7 years ago | (#18931667)

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.

Re:Nifty book (2, Funny)

CastrTroy (595695) | more than 7 years ago | (#18932159)

Aren't you supposed to leave your Myth box on, so that it can record your shows?

Re:Nifty book (0)

Anonymous Coward | more than 7 years ago | (#18932877)

Aren't you supposed to leave your Myth box on, so that it can record your shows?
Yeah, but to save power, you can turn the Myth box on right before your show comes on, so you're not wasting energy leaving the thing on all the time. Then you can watch it while it's recording, saving even more power since you won't have to turn the Myth box on again to watch the show (how wasteful would that be?). It even saves disk space because you can allow the recorded show to expire as soon as it finishes recording (since you have already watched it). I think this guy is on to something.

Re:Nifty book (1)

PCM2 (4486) | more than 7 years ago | (#18933231)

My Windows Media Center box comes with a remote control that can be used to turn the computer off and on. It communicates with a USB receiver that has the ability to bring the computer out of sleep (including S3). Apparently it's that USB receiver that handles scheduled wake-up/sleep, as well. So when I'm done using the computer as a PC, I hit the sleep button and walk away. It will wake itself up to record my shows and then go back to sleep.

I'm still waiting for Ubuntu to sleep reliably on my laptop. It seems reaaallll close now, and I've had complete success once or twice, but inexplicably it will fail the very next time I try.

Re:Nifty book (1)

itwerx (165526) | more than 7 years ago | (#18937559)

box comes with a remote control that can be used to turn the computer off and on. It communicates with a USB receiver

A lot of motherboards have a BIOS option to wake from sleep on USB activity. It's not a true power on/off but pretty close.
      (Now if MythTV could just use the other BIOS settings for scheduled power on that would be pretty cool!)

Re:Nifty book (1)

CastrTroy (595695) | more than 7 years ago | (#18939219)

It's not that hard from what i've heard. I think it requires echoing something to a file in proc, which will set the next wake up time. I've been looking for something similar for my sagetv windows box. Have it turn itself off when there's nothing to record for the rest of the night and set the bios to turn itself on 5 minutes before the next show comes on.

Re:Nifty book (1)

Ricochet (16874) | more than 7 years ago | (#18932693)

Maybe what you need is my book (boy am I going to catch sh*t for this): Linux Smart Homes For Dummies []

powering small devices - Re:Nifty book (1)

speculatrix (678524) | more than 7 years ago | (#18933693)

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 []

Re:Nifty book (1)

Aluvus (691449) | more than 7 years ago | (#18933773)

Use a relay connected to the motherboard "power switch" header of the target system. A momentary "high" voltage is all you would need. Or if you want to (rudely) shut down all other connected devices, use a relay to shut down the power strip everything is connected to.

Re:Nifty book (1)

ovoskeuiks (665553) | more than 7 years ago | (#18938729)

Actually a solution I've seen is using a PIC micro controller to translate the signals from the IR receiver send signals through to LIRC via serial or USB but when a power signal comes through switch the computer on via the Wake on Lan header on the motherboard

Perhaps useful for some systems (2, Interesting)

EmbeddedJanitor (597831) | more than 7 years ago | (#18931797)

The RTA approach is potentially useful for some very low volume data flows (system monitoring etc), but it is not the way you'd design any performance critical stuff (which many true embedded systems need). Most Linux embedded systems are portable devices that run on batteries, so efficiency is important. Efficient execution translates to longer battery life.

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.

Re:Perhaps useful for some systems (2, Informative)

greg1104 (461138) | more than 7 years ago | (#18932039)

After reading their related RTA description [] , your comments don't make any sense to me. It's an API for exposing stats or other information you collect in your program via a standardized sockets protocol. If no one is actually reading the stats, there is no overhead beyond whatever you already have in your app to collect them. Yes, the app may slow appreciably when someone is connected and reading the data via this interface; as long as responding to that is in a low-priority process, who cares?

Re:Perhaps useful for some systems (1)

ClosedSource (238333) | more than 7 years ago | (#18933879)

I agree. A lot of these devices could be built using an 8051 and much less than 64K of program memory and still be much more appropriate for real-time applications. "Desktop" OS's are great for general purpose use, but overkill for most embedded applications.

Hey you (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18931801)


Why is this section still here? (-1, Troll)

Anonymous Coward | more than 7 years ago | (#18931927)

No one gives a shit about books, why don't you get some common sense and remove this section. I bet 99% of the books reviews that are posted here are of books that no one will bother reading anyway. Save some bandwidth by removing this section. It took a lot of courage to remove the BSD section, as it was dying, I'm sure you felt remorse for a long while, but in the end it was the right decision, removing the books section will also be a smart move just like the firing of Michael Simms. BTW, the word I to type was turrets, what was yours, please post it under this parent post.

Re:Why is this section still here? (1)

Sneakernets (1026296) | more than 7 years ago | (#18932105)

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.

Re:Why is this section still here? (1)

brianez21 (945805) | more than 7 years ago | (#18932529)

Troll, troll, troll your post
gently down the feed
merrily merrily troll along
a life is what you need....

Toasting break with your Linux toaster (1)

suv4x4 (956391) | more than 7 years ago | (#18932219)

Toasting bread with your Linux toaster.. for Dummies

Configuring For Toasting:

Change directory to /usr/src/Linux and issue the command:
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...

..... snip few pages later ....

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 /boot with the command
cp /usr/Linux/src/arch/i386/boot/zImage /boot/newkernel
make modules_install
This will install the modules in /lib/modules. Next, edit /etc/lilo.conf to add a section like this
image = /boot/newkernel
label = new

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.

..... snip few pages later ....


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.

Re:Toasting break with your Linux toaster (4, Funny)

$RANDOMLUSER (804576) | more than 7 years ago | (#18932347)

Making toast the *NIX way:

1. Prepare the soil.
2. Plant the wheat.
3. Weed, fertilize, water.
4. Harvest.
5. Build a flour mill.
6. Grind wheat into flour.
7. Cultivate some wild yeast.
8. Build a brick oven.
9. Mix flour, yeast and water.
10. Bake dough to make bread.
11. Make a knife.
12. Slice bread.
13. Insert bread into *NIX toaster.

Re:Toasting break with your Linux toaster (1)

Burz (138833) | more than 7 years ago | (#18933169)

Step 13 should be broken down into about 7 or 8 (or 28) sub-steps that involve:

* Not finding the desired bread in the bread-package manager.

* Downloading source off author's site

* Realizing it doesn't have the neccessary feature that you heard people talking about, so you need to get the CVS version instead (install CVS and learn it post-haste).

* Chasing down all the supporting library dev packages to get it all to compile.

* Watch as the install process fails to change pertinent system settings (no desktop/menu icon, looks for the wrong /dev devices, assumes use of deprecated audio and video interfaces that require you to use gross wrappers like artsdsp, prints vague/cutesy messages that certain things in /etc will have to be edited ('cuz few of the files are consistent enough to be reliably understood and modified by a script, then have the app tell you that the installed libraries are not the same versions as the -dev references you downloaded to get the app to compile... so you recomile N-libraries in your system realizing the next day that it broke A) your packing system, and B) two other important apps you use throughout the week)...........

Re:Toasting break with your Linux toaster (1)

sminkin (1002497) | more than 7 years ago | (#18933441)

14. Profit!

I prefer the Debian way (0)

Anonymous Coward | more than 7 years ago | (#18935513)

# apt-get install toaster
$ toaster < bread > toast

Shi9t (-1)

Anonymous Coward | more than 7 years ago | (#18932277)

JOIN THE, GNAA!! appeared...saying irrecoverable we need to aadress own lube, beverage,

Could someone tell me why (3, Interesting)

anubi (640541) | more than 7 years ago | (#18933637)

all this fuss over a fullblown OS to do simple tasks?

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 (2, Interesting)

totoanihilation (782326) | more than 7 years ago | (#18935549)

Amen to that.
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.

Sure - I'll tell you why (0)

Anonymous Coward | more than 7 years ago | (#18936581)

"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.

Linux runs on a lot (1)

Rix (54095) | more than 7 years ago | (#18936889)

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.

Re:Linux runs on a lot (2, Interesting)

anubi (640541) | more than 7 years ago | (#18937353)

If I am making ONE of 'em, I really don't care how inefficient I may be, as long as the job gets done.

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.

Coke machines need hard realtime? (1)

Rix (54095) | more than 7 years ago | (#18937947)

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.

Re:Coke machines need hard realtime? (1)

anubi (640541) | more than 7 years ago | (#18964101)


I just try to keep it simple. Very, very simple.

Every time I have tried to do anything I did not understand thoroughly, it has always come back to bite me.

Re:Linux runs on a lot (0)

Anonymous Coward | more than 7 years ago | (#18952283)

Something tells me that you're great at re-inventing the wheel. And that your projects take far longer than they need to. Or what your competition requires.

Your simple TCP/IP stack won't last nearly 50 years. It'll be hacked by some bored high-school or college student within 5 years, giving them all the free soft drinks that they could wish for.

Something also tells me that you have no idea what the current world is like for microcontrollers. But I'd be willing to bet that you're convinced that you think you do.

This ain't the last millenium. There are better ways of doing what you claim you do. You should become familiar with them.

Re:Linux runs on a lot (1)

anubi (640541) | more than 7 years ago | (#18963983)

I reinvent the wheel because the ones offered are so full of legal vomit and enforced ignorance, as well as having so much "flexibility" ( aka "security holes" and "useless complexity" ) as to render them useless for my purpose.

Yes, it might be hacked. Someone else may figure out how to find out how many sodapops I have.

I guess if they are really nasty and clever, they can find the IP my customer is using and DOS it, then he will have to forego the convenience of knowing when one of his sodapop machines is out. Then he has to go change the IP on his machine. Kinda like the frustration a shopkeeper would have if somone wanted to annoy him by supergluing the locks on his business.

As far as hacking me, its like someone telling my cat to log onto my bank account and report my holdings.

Its the problem hackers have if someone ISN'T using IE! Without the Microsoft support, just how does one take over a simple browser? Especially if the TCPIP stack itself only knows ONE simple protocol?

The simple browsers simply do not understand scripting, and ignore the carefully crafted scripts.

If the TCPIP stack doesn't pass muster, it just gets reset for the next packet, along with setting an error code in the log that it got a bad packet. I log a few just for internal troubleshooting purposes.

And being mine run in non-writable ROM, they can't make their attack stick.

I have had NO violations so far, and neither do I expect any. If anyone is successful, I will learn. But, for now, I encode only enough "intelligence" to do the job. No more.

My feelings on security are like my feelings on building a house.

I can buy fire insurance, and have a big company say they will "protect" me from loss.

I prefer to build my house in such a way it won't burn.

Re:Linux runs on a lot (0)

Anonymous Coward | more than 7 years ago | (#18992533)

Sorry, but you really just don't know what you're doing. I wasn't referring to buffer overflows in the browser. I was referring to buffer overflows in the tcp/ip stack itself. I had thought that was obvious to anyone who has actually worked with tcp/ip stacks. This is really an old subject.

If you want some real amusement, grok why ethereal/wireshark got tossed from OpenBSD. It's always nice to know who's listening in. :)

You're also confusing security-by-obscurity with security.

Re:Could someone tell me why (1)

tbuskey (135499) | more than 7 years ago | (#18943873)

I've read the book myself, mostly. It has applications beyond an embedded design.

It could be a tiny file server or a network device. I'd love to have some of the interfaces into my thermostat! As time goes on, more and more devices will offer interfaces to get data/control out to computers. This book provides a good example of what and how to offer it. It can certainly be extrapolated to non linux systems.

Re:Could someone tell me why (1)

bensch128 (563853) | more than 7 years ago | (#18954857)

It puzzles me to see major corps use way, way, way overpowered/overpriced solutions to the simplest stuff.

It's alot more scalable to use a modestly powerful chip and linux then to code everything by hand on a pic controller. In the future, you'll want to add more features. You want process separation so if one process crashes, it won't take down the whole machine, you'll want to add a GUI, you'll want networking, etc etc etc.

From a cost POV, small arm CPUs make more sense then PICs because they are not much more expensive nowadays.


Yes! Finally! (1)

porkrind (314254) | more than 7 years ago | (#18933863)

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.


Re:Yes! Finally! (1)

gtstephenson (1060712) | more than 7 years ago | (#18936967)

I know Bob Smith and John Hardin. I have worked with them both. I know they poured heart and soul into this work. Not for economic gain but for sharing what they know with others. That is the mark of very special people. :-)
Check for New Comments
Slashdot Login

Need an Account?

Forgot your password?