Linux Application Development

r3lody (Raymond Lodato) writes "Writing Linux applications is not a simple endeavor. The Linux operating system provides a sophisticated framework for running programs, and learning how to take advantage of that framework requires some research. The book Linux Application Development, 2nd Ed., by Michael K. Johnson and Erik W. Troan provides much of what you need to know within its sturdy covers. Pitched to the intermediate to advanced programmer, all of the basic programming APIs are covered -- some in detail, some in brief." Read on for the rest of Lodato's review of this book.

Linux Application Development, 2nd Ed.
author	Michael K. Johnson and Erik W. Troan
pages	736
publisher	Prentice Addison-Wesley Professional
rating	9/10
reviewer	Ray Lodato (rlodato AT yahoo DOT com)
ISBN	0321219147
summary	Covers just about everything intermediate to advanced programmers need to interface with Linux from their applications.

The overall structure has the book divided into four major parts: Getting Started, Development Tools and Environment, System Programming and Development Libraries. Part 1, Getting Started, is a very high-level overview of Linux itself. The three chapters cover barely 20 pages, and discuss the history of Linux, its licensing, and the online documentation.

Part 2, Development Tools and Environment, gets more detailed, but ends up as a medium-level view of what tools you might use to actually create and debug your application. Six chapters covering about 75 pages discuss editors (Emacs and vi), make, the GNU debugger gdb, tracing, gcc options, glibc, memory debugging tools, libraries, and the environment. Each chapter feels a little lightweight except for the one on memory debugging tools. Here the authors dive into the common issues of buffer overflows and underruns, and the various utilities you can use to discover them. Not only the glibc features mcheck(), MALLOC_CHECK_ and mtrace(), but the memory profiler (mpr), Valgrind, and Electric Fence are discussed in enough detail to be useful.

If the first two parts seemed to just skim the surface somewhat, Part 3, System Programming, definitely dives into the deep end of the pool. Each chapter covers its topic in detail, and many code examples are given to clarify the concepts. Part 3 has 13 chapters and covers 450 pages, almost two-thirds of the total book. My major complaint with Part 3 is that related chapters appear to be separated by others. I will discuss them as I see the relationships.

Chapter 10 covers the Unix/Linux process model. Signals, job control, processes and threads are explained in detail. The authors also describe the 'gotcha's involved with setuid and setgid programs. The chapter ends with the first iteration of a sample shell program, ladsh. This shell is expanded as the book progresses to explain newer concepts. This topic should be followed by chapter 15 (Job Control), which goes into job control, including how to stop and start processes, move jobs between the foreground and the background, and handle job control signals.

Skipping back, chapter 11 introduces the file handling metaphor and how it relates to files, pipes, directories, devices, links, and sockets. It also explains inodes, file permissions, file descriptors, and the read/write/seek system calls. Chapter 13 expands on chapter 11 by discussing the advanced topics of multiple file handling, memory-mapped files, file locking, and scatter reads/gather writes. The next chapter goes over directory operations, such as handling the working directory, file name globbing, walking trees and directory change notification.

Signal Processing (chapter 12) discusses simple interprocess communication including signals and handlers. It describes the Linux and POSIX Signal API, real-time signals, and how to transmit data with a signal. Remote interprocess communication occurs over sockets. Chapter 17, Networking with Sockets, shows how to use the socket API, which can be used for IP, IPX, AppleTalk and Unix domain sockets. Michael and Erik show how to write a client and server, how to handle name resolution, the differences between session (e.g. TCP) and datagram (e.g. UDP) communications, and finish with an example tftp server.

Obviously, many programs need to interact with the user, and that's where chapters 16, 20, and 21 come into play. Chapter 16 talks about terminals (tty) and pseudo terminals (ptty) and how to program them. The POSIX termios interface is discussed in depth. Chapter 20 gives you tools to manipulate virtual consoles, which create the abstraction needed to multiplex different sessions on the same keyboard, video, and mouse. The following chapter talks about the Linux Console including text-based screen-drawing with S-Lang and curses, the terminal capabilities (termcap) and terminal information (terminfo) databases, ANSI Escape sequences, as well as direct screen writing.

Chapters 18 covers basic system calls for time/date representation and formatting and timer usage, and chapter 19 covers pseudo-random number generation and its use in cryptography. Finally, part 3 wraps up with chapter 22 discussing how to write secure programs. Common exploits such as buffer overflows and unauthorized directory traversals, and the ways you can prevent them (length checking and chroot, for example) only scratch the surface. The authors recognize this is just an introduction and refer you to another book to fill in the blanks.

The final part of the book covers the various development libraries commonly available to the programmer. The six chapters cover a wide range of topics. Chapter 23 covers the ins and outs of string handling, including processing regular expressions. A simple grep program demonstrates the ideas. Using S-Lang to handle the terminal is the main interest of the next chapter. Basic input/output handling, and line drawing using text characters seem mundane in this day and age of GUI interfaces, but they have their place. Check out a Red Hat install to see what I mean.

Chapter 25 discusses database interfaces. While gdbm and Berkeley db are better known, Michael and Erik chose to focus on qdbm, which is licensed under the LGPL, making it more attractive. Linux programmers are used to typing in commands with all of their options. Getopt and getopt_long are the standard for processing those options, but popt is detailed due to its extended capabilities, such as nested options which allow libraries to define options for them to handle which the main program can effectively ignore.

The final two chapters cover dynamic loading of shared objects (as opposed to shared libraries) with the advantages that provides, and user identification and authentication, covering id-to-name translation, and Pluggable Authentication Modules (PAM). As usual, example code shows clearly how to use the interfaces.

I know this review is lengthier than usual, but this book has so much packed within its covers, I didn't want to give short shrift to any part of it. When programming, one needs a number of reference books at hand, and Linux Application Development should definitely be one of the handiest. Just about every aspect of how to interface to Linux from your application program is covered, and the numerous code snippets and examples keep things understandable. An extremely useful book such as this deserves a high ranking. My only concerns were how the first two parts seemed skimpy compared to the rest of the book, and the part on System Programming could have been laid out better. That said, Linux Application Development rates a 9 out of 10.

---

You can purchase Linux Application Development, 2nd Edition from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.

question

[3cpo]

Why so many books cover topics which are described in manuals (I mean man's for linux) ? In my opinion a good book should not repeat those things but describe only structure and philosophy of topic. For further reference you should then read mans.

Re:question

[l4m3z0r]

man pages are notoriously bad, and are all but useless unless you want a haphazard and incomplete list of features without proper examples(this is key in my opinion).

If anything in the OSS/Linux world needs some more thought it is the horrid man pages.

Re:question

[Rakshasa Taisab]

I've always found the man pages to be excellent. (Though i wish i had learned about apropos earlier;)

They are not meant as complete newbie introduction to , but rather as a reminder or dense description of something. It's invaluable when you need some information on how certain library calls work, commands and similar.

Re:question

[l4m3z0r]

And mods, PP was not informative, it was a troll. (Did you look at the guy's user name?)

What does my user name have to do with the quality or content of my post? It's people like you who mod based on username or sig that make /. moderation the horribly biased and awkward system that it is.

I find it funny I'm branded troll for offering my opinion that man pages are inadequate. When someone says RTFM they more generally mean go online and look for real documentation as man pages rarely if ever cut it.

I w

Re:question

[l4m3z0r]

Hey bad work deserves those adjectives, I'm not going to sugarcoat the truth because peoples feelings will be hurt. Fact: many man pages are poorly written and extremely out of date. Good documentation is well written and up to date so therefore documentation that fails those criteria is bad/horrid/terrible whatever adjective you like. Poor grammar, convoluted language or was written(poorly) by a non native english speaker is in fact "disgusting" as in it disgusts me to rely on such poor documentation.

O

Re:question

[DuctTape]

I don't think the man pages are all THAT bad, they're WAY better then the ones that come with Solaris. Then there are the Info pages too, which are often useful, but still pale in comparison to a book. But IMHO they do make a good reference.

Ah, but when do you look at the info page, which may or may not be there? I'm not a big fan of doing a man foo and then an info foo for everything that I want to look up. 'Course there's a note at the bottom of some man pages that say to look at the more extensive in

Re:question

[Wudbaer]

Because the man pages are good references (most of the time at least) but not good for learning ? You don't try to learn a language by reading the respective dictionary from front to back either, don't you ?

I see the greater problem in the fast pace of Open Source development. Lots of books especially on new and developing topics are already outdated once they appear on the shelves.

Re:question

[segmond]

actually, man pages are great for learning. the problem is that people do not know how to read it. Most books don't even cover a decent amount of command. For example, a command might have 20 options and the book will cover 4. If you actually take the time to read the man page, play around and test the options, you will have a decent edge over others.

Re:question

[grumbel]

### actually, man pages are great for learning.

No, in your case the man with the book might only now 4 options, but the man with the man page wouldn't even now that the command exist in the first place. Man pages are good to lookup the options when you already know what you want, for anything else they are quite horrible.

Re:question

[moosesocks]

If you actually take the time to read the man page, play around and test the options, you will have a decent edge over others.

well, gosh, I want to remove this symlink to /
let's look up how to do that in the manpages

$man rm

-R Attempt to remove the file hierarchy rooted in each file argument

hmm. okay. that sounds about right.

$rm -rf /

shit

Re:question

[UnpopularOpinion]

You didn't read his post. He said "unless you want a haphazard and incomplete list of features without proper examples". In other words, not good for learning or as a reference.

answer

[Trolling4Columbine]

Because mans suck.

Really, before you mod me down, do you really believe that the majority of mans provide enough information for people just learning the tool?

Re:answer

[bobs666]

> Because man(page)s suck.

I have to agree, man is not like it was in the old days. Manpages and a few AT&T reports and the 'C' book was all you needed.

But thats was then, and now is now, with all sorts
of stuff hidden away in info pages or some confounded desktop system. Its much harder to
find the clues you need to get things done.

Re:question

[gazuga]

Sometimes a good reference book is much better than the man pages. I can still navigate a dead tree a lot faster than I can a man page, and it's a lot more convenient that way. Not to mention that if I'm looking at multiple topics at once, it's easier to bookmark and flip pages than to open a term for each topic I'm looking at.

Guess when it comes down to it, it's really a matter of preference.

Re:question

[kfg]

Why so many books cover topics which are described in manuals (I mean man's for linux) ?

Because until you have read a well written book you have no idea what the man pages are trying to say. You need to start with a tutorial.

For further reference you should then read mans.

Well see? You knew the answer yourself all along. The man pages are a reference source once you have had a tutorial.

KFG

Re:question

[PornMaster]

I prefer to read ladies... in braille

Re:question

[JustinHoMi]

I disagree. There is only so much you can get from a man page. A good book allows you to gain an understanding of the subject based on the perspective that it is written in. For instance, "PHP For The Enterprise" is going to go in a much different direction than "PHP For Dummies".

Also, a man page is never going to give you thorough enough examples. Most people learn much better by example than technical jargon. No man page is going to be able to provide enough examples to gain any true understanding of the

Re:question

[bluGill]

If I know what command to use the man page is great for telling me the details on using it. (in fopen(3) did I want w+, a, or a+) However if you don't know a that strtol(3) exists you will write one yourself that doesn't work as well.

I don't know if this book covers the above though. I've often wished there was some magical "clippy" that would pop up and say "It looks like you are doing a bad re-write of strtok(3)" everytime I re-invent the wheel. Of course it needs to be smart enough to also do "It

Good introduction aggregates appropriate man pages

[Anonymous Coward]

I found the book an excellent introduction to... well, Linux Application Development.

To become productive on a platform, you need to know what that platform is fundamentally capable of, and the APIs that provide access to that functionality. And, as a programmer, I find a quick and well-ordered tour through key APIs the best way to get a handle on both before diving in to some serious development.

Now man pages become useful - now that you know what you _can_ do, have a rough idea of the platform's design

Re:question

[TheOldFart]

.
For further reference you should then read mans.

Because I hate dragging my DEC Terminal to the bathroom. Besides, my RS232 cable is only 25' long.

btw... "mans"? shouldn't that be "men"?

Re:question

[belmolis]

I don't know why everybody assumes that man pages must be read online. When I really had to learn UNIX seriously, I bought myself one of the five-volume Berkeley manual sets to keep at home. These consisted of the man pages plus various technical reports. In addition to looking things up, I would read through them. It was a great way to get an idea of what the system consists of and what programs, library functions, system calls, and so forth are available. That was very handy set of books. I'd still be us

Review?

[Anonymous Coward]

You call this a review? It's more like a table of contents. "This book covers X, Y, and Z." How's the writing quality? How good are the examples?

Re:Review?

[Anonymous Coward]

That's because the poster only want to get his referal link clicked!

Ans: Excellent, excellent

[mangu]

How's the writing quality? How good are the examples?

I have had this book for three years, and it's excellent in both writing quality and examples. It's strictly console oriented, go somewhere else for GUI programming, but it's by far the best, most clear, and comprehensive source of info for creating programs that need to do Linux system calls.

LWN Review

[Corbet]

Just FWIW, I reviewed LAD2 in LWN [lwn.net] about a month ago.

Application development?

[DrXym]

I would expect a book about application development to concern itself with such matters as how to create a window, draw buttons, respond to keystrokes, draw graphics and well... how to write applications. As in, how to write graphic user interface programs. That is what most people would interpret the title to mean.

While such things as pipes, regular expressions, setting date & time etc. are all fundamentals of any kind of programming, it seems a more apt name for the book would be Linux Command-Line Application Development, or Linux Daemon Development.

Re:Application development?

[segmond]

Nope! You must not be a programmer. "Linux Application Development" brings to mind "Unix System Program" but on the linux platform. Working with the tools, system calls, and APIs, that's what it's about. There is a reason why it's not called "Linux GUI Application Development."

I don't really see the need for these books anymore, the man pages, info pages, online manuals cover all of this. But it's just me...

Re:Application development?

[Daniel]

I think programmers with Unix experience won't need this, but I read a similar book when I started writing Linux software, and it was incredibly helpful. There are a lot of things about the Linux environment that experienced programmers take for granted, but that you have to learn somewhere. Having it all in one place and presented in a logical fashion is a great time-saver. You could probably learn how UNIX processes work, for instance, by reading the manpages for fork(2), exec(2), and so on, but I doub

Re:Application development?

[jdigital]

The beauty of the UNIX development model is that the bulk of your applications are 'command line' applications, so that things can be plugged together to get the job done.

Whilst GUI applications require lots of knowledge to implement correctly, the innards usually need a good understanding of pipes, regex etc.

Re:Application development?

[aled]

If I need to debug a program I fail to see how piping the compiler through the debbuger would help me. Perhaps I should replace my graphical editor where every function is a few clicks away, with sed to really became productive. And my word processor and spreadsheet surely are living fosills. I should be changing my cable modem with Internet thru a pipe to get broadband (get it? bigger pipe).

But don't worry, it must be me.

Re:Application development?

[MikeBabcock]

You've never written Linux applications have you? How many GUI apps are on a Fedora Core 3 installation vs. command-line apps?

How many of those GUI apps use tools from this guide, in spite of being GUI-oriented?

Knowing how to write *nix applications without concerning one's self with the GUI is a necessary issue, regardless of the end-target.

Consider also that "drawing buttons" is done entirely by libraries that handle such things for you if you know what you're doing and you'll realize most of what you're looking for just isn't programming, its GUI design -- and shouldn't be done by programmers anyway. See grip for evidence.

Re:Application development?

[DrXym]

An application is generally considered to be a program with a user interface. Most people would reasonably expect a book with a title Linux Application Development to cover development of such programs. It doesn't.

Perhaps the distinction wasn't so obvious in 1998 or whenever the first edition came out, but it is now.

Fedora does contain console apps such as vi, emacs, mc, etc. that run through curses and respond to user input, but the vast majority are GUI based applications.

Command-line programs like grep, ls etc. are tools, not applications. Programs like sshd, inetd, apache etc. are daemons, not applications.

Re:Application development?

[Bitchslap_69]

I think the attitude displayed IRT GUI development is a good part of the reason that Linux has been so slow to gain widespread user acceptance as a desktop OS. "Why GUIs? I mean, you've got man pages and everything's on the tty anyways!" But GUI development on the Linux desktop is in WORSE shape than Windows app development 10 years ago. Competing standards and APIs, no consensus design patterns or generally compliant interface standards, etc. Add on top of that the inarguably flexible but wildly arcan

Re:Bollocks

[Peaker]

.Net isn't a GUI development solution. There's a lot of different resources out there for understanding what it is, but you can start here with the basics.

Thank you, King Obvious. I was obviously talking about the GUI libraries and RAD tools available for .NET.

but from what I can see, it's Python-based. That's fine if you know Python (and I do), but not everyone does

Qt is a C++ library usable from many languages. PyQt is its Python bindings. Not everyone does, but everyone should, because it is the

Re:Bollocks

[Peaker]

This is Slashdot, nobody expects real discussion here, lighten up :)

Slashdot was always a contest of who yells more towards which side, and I find it fun sometimes to participate in it..

Anyhow I was just responding in the same spirit of "Sadly Windows is far ahead of Linux in the GUI and development department" with the opposite.

If a real discussion is due, I can participate in that as well.

Ruby is a nice language too, but too bad all the sheeple are stuck with C# and other Microsoft-said-so languages.

Re:Application development?

[AuMatar]

No, applications are programs. Period. Thats the accepted industry definition. The fact that you think it has something to do with GUI is irrelevant. The term application predates the development of GUIs.

Re:Application development?

[DrXym]

Thats the accepted industry definition.

Oh sure [reference.com].

Re:Application development?

[AuMatar]

Of or being a computer program designed for a specific task or use

Looks like any program to me. As I said- the term predates GUIs.

So where does it say the UI is graphical?

[Ayanami Rei]

Re:So where does it say the UI is graphical?

[DrXym]

You'd have a point if the book even mentioned how to develop console based applications - curses, termcap and what not. But it doesn't do that either.

So unless your definition of application is restricted to fscanf, the term makes no sense for non-graphical UIs either.

Re:Application development?

[Zangief]

An application is generally considered to be a program with a user interface.

What is the command line then? ...a way for the user, ...to interface with the program. A USER INTERFACE!

I'm sorry, but a lot of programs just need that. If we can get more services the daemons you mentioned, yay for us.

Re:Application development?

[MikeBabcock]

curses is a user-interface environment.

So is Gtk+ and Qt.

And so, by the way, is the CLI.

find /home | afio -ozvECI /tmp/blah.Zafio

That's a nasty looking user interface, but a user interface it is.

cdrecord -v dev=0,0,0 -eject speed=24 /tmp/file.iso

That's also a user-interface.

Incidentally, I always tell my clients to edit files with 'vi' when on the phone, it lets me guide their fingers easier.

"Hit '/', then type 'root:', now hit '$', hit 'a', type 'loser', hit ESC, type ':wq', thanks."

User interface

Re:Application development?

[MankyD]

Application development is not about GUI's - save that for a GUI book. A GUI is just a front end to the application work horse. Pipes, regex, etc are all "fundamentals", you're right. And that's what this book is. It teaches you the basis for creating applications that work in Linux. Use it as a push of point to create more effective programs to which you can attach you're windows, buttons, event watchers, graphics, etc.

Re:Application development?

[fuvm]

Why? That would be a Gnome Application Development book, or an X11 Application Development book, or what have you. This book describes the Linux API. Thus, Linux Application Development.

Re:Application development?

[stephandahl]

I couldn't disagree more. Not all applications have (or need) a GUI. A server is an application, a scheduled task is an application. They don't need qualifiers like "command line" or "daemon".

This book covers the interesting stuff in an application (whether Gooey or CLI).

Re:Application development?

[mikael]

I would expect a book about application development to concern itself with such matters as how to create a window, draw buttons, respond to keystrokes, draw graphics and well..

Have you ever designed applications using Trolltech's Qt? The entire GUI of an application can be designed using editing tools - everything from pulldown menu's to dialog windows, entire pages of tab controls. Not forgetting that entire dialog windows can be made automatically resizable (Maybe there are other design tools that can d

Don't I just want to write Linux apps right now!

[Morphix84]

"Writing Linux applications is not a simple endeavor. The Linux operating system provides a sophisticated framework for running programs, and learning how to take advantage of that framework requires some research." Oh boy, doesn't that just sound like fun.

It is fun!

[wiredog]

If you're a programmer.

Hope it is better than the first edition

[Anonymous Coward]

I read the first edition of this book, and I found it to be lacking in the areas of memory management and IPC. It seemed like it would be a fine overview for developing simple user applications, but for anything heavy on the two areas I mentioned it is not quite sufficient. Perhaps this newer edition is an improvement.

I ended up finding what I needed in the man pages for various memory-related system calls, and in the very good but older Interprocess Communications in Unix by John Gray.

What kind of IPC you really use?

[saigon_from_europe]

I had (or maybe I still have) a plan of writing web-based introduction to Linux programming. Related to IPC, I am wandering, which areas are really important? For instance, pipes are nice, but I used them only for testing, never in real-life app. Basically, I prefer signals, sempaphores and shared memory. I have never used even real-time signals, no matter that they are really better, I had no real reason to use them instead of standard ones.

I would like to know, what do you use in your apps?

Don't want to troll, but... where's the RAD?

[Spy der Mann]

Compare a book describing the "sophisticated APIs" with a "Visual Basic for dummies".

C'mon guys, where's the RAD for Linux?

Re:Don't want to troll, but... where's the RAD?

[pclminion]

C'mon guys, where's the RAD for Linux?

Here you go. [wxpython.org]

Re:Don't want to troll, but... where's the RAD?

[TilJ]

It already exists. It's called the Unix shell (and the tools that run within that context).

Seriously, the Unix "toolbox" metaphor is more powerful that people seem to realize. For one example of how the shell is often underestimated, take a look at The UNIX Shell As a Fourth Generation Language [rdb.com], by Evan Schaffer and Mike Wolf. That's from the 1980s.

Re:Don't want to troll, but... where's the RAD?

[twistedcubic]

Are you kidding? Off the top of my head: KDE has made one for years, IBM has Kylix, Borland has C++Builder, and loads of others.

Re:Don't want to troll, but... where's the RAD?

[anomalous cohort]

I would have thought that a recently published book on application development would talk more about kdevelop and qtdesigner than emacs and vi.

Don't get me wrong. I use emacs every day. It's just that there are literally decades of books written about the "old school" way of command line application development. Do we really need another?

Re:Don't want to troll, but... where's the RAD?

[pHDNgell]

C'mon guys, where's the RAD for Linux?

Same place it is for OS X, in the NeXTSTEP API.

see gnustep [gnustep.org]

I installed gnustep on my FreeBSD box last night and ported one of my Mac GUI apps in just a few minutes.

Re:Don't want to troll, but... where's the RAD?

[arkanes]

Compare this with Programming Windows, an introduction and reference to writing applications with the Windows API. It's invaluable as a learning tool, but to write the really fancy stuff you'll need to exapand a lot on the knowledge it offers. It's 1479 pages.

http://www.amazon.com/exec/obidos/tg/detail/-/157 2 31995X/qid=1107987162/sr=8-4/ref=sr_8_xs_ap_i4_xgl 14/102-6770576-5407306?v=glance&s=books&n=507846 [amazon.com] (no referrer link or anything)

Re:Don't want to troll, but... where's the RAD?

[blackpaw]

No, none of those are even vaguely close to a rad environment.

Where's the open source Delphi ? or even Visual Basic ?

Actually there is a OS VB like environment, can't remeber its name offhand.

Re:Don't want to troll, but... where's the RAD?

[kallisti]

Where's the open source Delphi ? or even Visual Basic ?

It's called Qt and its found at TrollTech [trolltech.com]. I've used Delphi, VB (from versions 1 to 5) and Qt, I like Qt the best of all of them. Create your GUI graphically, define what signals and slots to hook up, write the functions and go. And you aren't stuck with BASIC or Pascal, two languages that should die.

Re:Don't want to troll, but... where's the RAD?

[cakoose]

Gambas [sourceforge.net]. I really wish it wasn't based off of Basic, though.

Re:Don't want to troll, but... where's the RAD?

[lachlan76]

Yeah, I was surprised too ;)

"development"?

[flacco]

i thought the apt-get faerie just creates them out of thin air...

Another must have...

[null etc.]

I strongly recommend that no one purchase this book without also purchasing the industry bible, "Developing Cryptic Man Pages".

Please, do not rely upon the "Linux Man Page Howto". For example, in the "few thoughts about documentation", the following guidelines are given:

Documentation must be accessible.
Documentation must be reliable and accurate.

What about "Documentation must be cryptic!!!" Face it - if you're going to go through the trouble of writing a man page, would you rather have your target audience read it once, or tens and hundreds of times!

Re:Another must have...

[null etc.]

If you are communicating a complex idea, the language you use must be precise.

Ah hah! Perhaps the problem with Linux/Unix is that it requires the absorbtion of too many complex ideas.

Of my many frequent but short-lived encounters with Linux, I'd try to figure out how to do something. Invariably, I'd read the man page. Then, the topic under investigation would refer to some other cryptic term, which I'm sure is well understood by Linux experts, but not me. So then I'd have to research this other term.

The Art of Unix Programming..

[rjshields]

.. gives a good overview of the subject

http://www.faqs.org/docs/artu/ [faqs.org]

Its a "Linux Applications" Crazy-Tent Circus Par..

[torpor]

..ade of Whatever Wondrous Bits and Bobs from Around The Globe You Could Find.

as a linux application developer, 'linux' to me represents a wonderous toolset of marvel.

much as it may pain to state the obvious, the joy to be had in building your own entire OS; literally choosing only the bits you need for your application, cannot be under-valued.

weird to think of it (its gone so fast) but for 10 years i've been designing and building custom linux systems for a living .. and most of them are still running,

Mono GTK+ apps

[digidave]

Anybody got some links that might help developing Mono GTK+ apps? Reply with links. I'm sure some people other than me are looking to get into this stuff.
Here are my links:

• GTK+ sharp homepage [gmdsoft.de]
• Mono's GTK+ sharp page [go-mono.com]
• Mono docs [go-mono.com]
• gotmono [gotmono.com]

I recommend it!

[drakethegreat]

I bought this book a few months ago and its quite nice. It goes through all the system calls and libraries that most Linux Programmers use or will ever need to use. Networking, Processes, Files, the works. Definitely a good resource if you need to reference things as well later on.

Already one the first edition

[webhat]

As I said I already own it, and I though it was so good that I bought it as presents for some of my friend. The first edition is handy and I keep it on my desk as a reference when man pages just don't cut it.

I also own an electronic version so I don't have to take it with me when I have to go out on a job.

If the second edition is as good as the first then I'd advise everybody to get a copy.

autotools ?

[savuporo]

Six chapters covering about 75 pages discuss editors (Emacs and vi), make, the GNU debugger gdb, tracing, gcc options, glibc, memory debugging tools, libraries, and the environment

Huh ? At this time and age, no mention of automake/autoconf at all or did the review just skip that part ?
Who in their right mind still uses handwritten makefiles ?

Re:autotools ?

[Anthony Liguori]

automake is a nightmare.

Autoconf is painful but is still useful. automake is just unneccessary pain.

Sophisticated?

[callipygian-showsyst]

The Linux operating system provides a sophisticated framework for running programs

Is it sophisticated or poorly designed? Has anyone ever seen an X Application that looked and felt as nice as a native Windows (or Mac OS X) application? Has anyone ever gotten stuff like drag/drop between applications or ICCCM [tronche.com] to work correctly? I'd say it's far from sophisticated--it's clunky, ill conceived, and hard to apply effectively.

Re:Magic

[boohiss]

"Finally, part 3 wraps up with chapter 22 discussing how to write secure programs" How come the "secure" part of coding, perhaps one of the most important parts of coding, is always last in the book?

Re:Magic

[th1ckasabr1ck]

Just because the part about security comes last in the book doesn't mean that it is any more or less important.

Maybe the author feels that in order to get the most out of a chapter about writing secture programs you first need a good base in the things discussed in earlier chapters.

Re:Magic

[NewOrleansNed]

For the same reason "Hello World" isn't written as a multi-threaded client/server based program.

You gotta understand the concepts before you understand the dangers associated with them.

Re:Magic

[Rei]

That would be an interesting programming challenge: Write the most pointlessly complicated "Hello World" program. Not to make "Hello World" appear in fancy graphics with special effects or whatnot - just your basic terminal-based "Hello World" :)

I'd probably approach it using shared memory, a cron job, and packets with low TTLs. :)

Re:Magic

[pclminion]

Here's a program that uses recursion, threads, and condition variables to print "Hello, world!"

#include <pthread.h>
#include <stdlib.h>
#include <stdio.h>

struct thread_info
{
pthread_t id;
pthread_mutex_t lock;
pthread_cond_t cond;
int ch;
struct thread_info *next_thread;
};

void *do_thread(void *arg)
{
struct thread_info *inf = (struct thread_info *)arg;

pthread_cond_wait(&inf->cond, &inf->lock);
printf("%c", inf->ch);
if(inf->next_thread)
{
pthread_mutex_lock(&inf

Re:Magic

[Daniel]

Nice try, but that's almost comprehensible ;-). Maybe we could start with something like this...continuations, macros (although I think it could use more of them), and a pointless application of basic number theory to top it off. Wacky indentation courtesy of /.'s spamfilters.

(I thought about doing something totally ridiculous, like having the-msg be a red-black tree indexed by the Nth prime number, but then I realized that would be totally ridiculous)

(define the-msg "H!dlrow ,olle")

(define call/cc cal

Re:Magic

[Daniel]

and for extra fun, use this definition instead. (I'm done now. really)

(define make-next-char
(lambda (get-nth-char max-idx start stride)
(let ((final (lambda (k) (k (- start stride)))))
(lambda ()
(let* ((old-final final)
(new-final #f)
(update-final (delay (set! final new-final))))
(let [(k (call/cc (lambda (x) x)))]
(cond
[(number? k) (and (< k max-idx) (get-nth-char k))]
[else
(set! new-final k)
(force update-final)
(k (+ stri

Re:Magic

[Anonymous Coward]

The security section is exactly where it should be. You have to understand a system before you can secure it. If you try to secure it before you understand it, you will never make it secure. You a Troll?

Re:Magic

[Anonymous Coward]

My guess is hes an MCSE =)

Re:Magic

[The_Whole_Fn_Show]

...out of the Stargate or something.

NO! It is the FARGATE! It is not some other kind of gate from a movie or TV show that I've never seen! Notice that it has a wheelchair and a pink mohawk? We're not getting sued!

No, it is a Fargate! From the makers of Findependence Day!

(Sorry, obligatory ATHF remark)

Re:Magic

[LilMikey]

He can only be killed by the bone sabre of Zuma Kali!

Re:Magic

[Necroman]

It's a Fargate. Not a Stargate like from that movie, or the popular syndicated TV series.

Re:Magic

[fitten]

I always thought it was more like the "Infinite number of monkeys..." thing. I mean... with all the "eyes" that are supposedly on OSS code kinda being like an "Infinite number..." and, well, the average OSS programmer probably kinda smells and acts like a "monkey"... ;)

Re:The dedication turned me off.

[pclminion]

The first edition carries a dedication by Mr. Johnson, which reads "To the memory of my grandmother, Eleanor Johnson, who taught faith in God by example. . ." Proselytization is repugnant wherever it is encountered; between the covers of a science text it is inexcusable.

But proselytization about the evils of proselytization is not? Here you are, in an article about a technical topic, ranting about religion? I'd say that's inappropriate proselytizing, no?

Further:

1. This is not a "science text." Not by any reasonable definition of science.
2. The dedication is a personal statement. It is directed at the dedicatee, not you.

Re:The dedication turned me off.

[InstBrad]

I looked on Websters to find the definition of "proselytization". Turns out that it means "to induce someone to convert to one's own religious faith."

So Mr. Johnson was not proselytizing. There was nothing in his dedication that attempted to sway you to his belief system. His grandmother may have been but even that is debatable since she was simply leading by example.

I picked up a number of computer books from my shelf and about half of them had dedications. Some mentioned "love", one mentioned "l

Re:The dedication turned me off.

[dankelley]

Jealous because so few books are dedicated to Anonymous Coward?

CLI is an INTERFACE.

[waxmop]

Does it make any sense to say all the useful GUI programs have been written? The GUI is just a method of interaction. Having to design for a command-line interface encourages model-view-controller design. IMO, a proper application can be run interactively, through config files and a command-line, or as an API from another program.

Re:CLI is an INTERFACE.

[As Seen On TV]

IMO, a proper application can be run interactively, through config files and a command-line, or as an API from another program.

Okay, well ... that's obviously false. There are tasks that cannot be done with a command line, period. Interactive visualization, compositing ...hell, even games. These cannot be done without a graphical interface.

That's why I say that the command line has been exhausted. All the useful command-line programs have been written. We've moved on to tasks that can't be done on the co

Re:CLI is an INTERFACE.

[pclminion]

Interactive visualization, compositing ...hell, even games. These cannot be done without a graphical interface.

This depends on your definition of "interface." Consider gnuplot. It's a command-line driven program but it displays its graphs in an X window. However, it can also save graphs to PNG files or other formats instead of displaying in a window. Is it, or is it not, a "GUI interface?" I'd say not.

That's why I say that the command line has been exhausted. All the useful command-line programs have b

Oh yeah? What's this, then?

[ulatekh]

You're either a troll or a dimwit.

Nowhere in there is there room for a command-line program that hasn't yet been written.

That's odd, I spend a LOT of time writing code that ends up in command-line programs. I wonder how I do that, given that you say there's no room for such a thing.

Just take a look on the open-source project where I write the most code, mjpegtools [sourceforge.net]. It's the open-source MPEG2-video (i.e. DVD) creation package. You'll have to look at the CVS version [sourceforge.net] to see my latest contribution, t

What?

[Ayanami Rei]

Hello. Welcome to slashdot.
Would you like a clue?

Compressor, Cleaner... say I wonder if I can download a free copy of those to run on my Solaris box.
No? Well, it's back to handrolling an implementation from the ITU MPEG-2 reference documents.

I guess mjpegtools is USELESS then...

Embedded...

[Cryptnotic]

Embedded does not mean that there is no user, rather it just means that the software is part of a device. That device could be a cable box, a PVR, a radar dislay/interface system in an aircraft, the music browsing interface on your digital music player, or any of dozens of other devices. All of these are embedded systems.

(from someone who does embedded software development).

Re:Isn't it time to move on?

[MightyMartian]

On more than one occasion I've had to write a command line utility (often in scripting languages like awk, but sometimes compiled) to handle data translation and massaging. To write a GUI application to do this is not only time consuming and wasteful of resources, but also means that I actually have to have a GUI installed and running.

It seems there is an entire generation of programmers that think that everything they write has to have a user interface. The beauty of command line utilities, interpreted

Re:Isn't it time to move on?

[mrchaotica]

It seems there is an entire generation of programmers that think that everything they write has to have a user interface.

Hey, I resent that remark! I'm a CS student, and I have loved the UNIX command line since the moment I discovered how to use it. In fact, I use Mac OS instead of Windows because of the command line. (Ironic, eh?)

Re:Isn't it time to move on?

[Blakey Rat]

I mean, for Christ's sake, to change basic application parameters, I'm stuck going into the frigging registry editor, while on a *nix box, we have text configuration files, and I can't grab my favorite text editor, alter the settings, kill -HUP the daemon and away we go. I find that Windows and its kazillion GUI frontends and horrific registry are far complex, and the look-alike tools starting to pop up for Samba, MySQL and the like for X on *nix machines are repeating this awful arrangement.

If you're in

Re:Isn't it time to move on?

[MightyMartian]

> If you're in the Registry Editor, either what
> you're doing is not a "basic application
> parameter," or you're going about changing it in
> about the worst possible way. "Man, my car ran out
> of gas! I had to remove the fuel filter, pump gas
> back INTO the tank, then quickly replace the
> filter before it all ran onto the pavement again."

Try this for starters. In Win2k, find out how to change the W32Time service to update via the system clock via an NTP server.

> In any case, your

Re:Isn't it time to move on?

[Blakey Rat]

Good for you. I'm a sysadmin. Strangely, you don't find too many Macs as servers.

Not when you consider Apple's bi-polar position on providing servers (although they seemed to have settled down now) and their lousy support compared to their competitors.

For what it's worth, I sysadmin a bunch of Windows XP boxes at a hospital where we couldn't run MacOS even if we wanted. And I've always just downloaded a 100k utility to set Windows 2000 or 98 or whatnot to change the time based on an NTP server... that s

Re:Isn't it time to move on?

[Tim Browse]

You're right.

I think there is a world market for maybe five new command line applications.