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.

Comments

75 pages on emacs vs vi?

[Neil Blender]

Let me guess... emacs is covered in 74 of those pages and the vi page simply reads: Use emacs.

Re:75 pages on emacs vs vi?

[Anonymous Coward]

Yeah, that one last page said: run vimtutor, no more
escape-meta-alt-control-shift

Re:75 pages on emacs vs vi?

[Anonymous Coward]

75 pages on emacs vs vi?

No.

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.

See: subset.

Re:75 pages on emacs vs vi?

[Anonymous Coward]

escape-meta-alt-control-shift

I think you forgot the -shit at the end.

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

[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

[Anonymous Coward]

You sir should put away your gcc, g++, perl, javac, etc and only use as

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

[Anonymous Coward]

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.

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

[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

[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 subject.

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 looks like you are re-implementing proprietaryLibraryFuncInOurCompanyArchitecture()" All that without being as annoying as the MS version it is patterened on. Much better than having our cheif architech complain when he discovered I did such a thing.

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

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

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

[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

[mr.newt]

The man pages are just that - manual pages. Not "learn by example" pages. And mods, PP was not informative, it was a troll. (Did you look at the guy's user name?)

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 using them if not for the fact that I'm no longer running 4.2BSD.

Re:question

[Anonymous Coward]

Why not the author say "if the public buys n,000 or more copies of this book, I allow my work to be copied or modified into any OSS program's man page for free under whatever license that works."

Re:question

[riteshsarraf]

man pages aren't horrid. Yes, they are technical but they are very very userfriendly. Tell me something, when once you are used to Linux/Unix, how often do you require to refer to remember what actually is the switch to `ls` to display in human-readable format and distinguish between directories, files and executables. Very often, right ?? Can you keep opening book very often ?? NO! And man is online pages.

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 wonder how I'd be branded if I further voice my opinion that xwindows needs to be replaced by something newer and fresher because the X code base is a disgusting hackjob. But hey my opinions shouldn't be judged on merit they should instead be judged on my user name, uid, race, religion, creed, political affiliation, sig, anything else you can use to toss a label on me.

Re:question

[mr.newt]

I didn't call you a troll for stating your opinion, I called you a troll for using adjectives like "horrid" and "disgusting" to describe other people's work.

Your statement about xwindows is also a troll, not because you think xwindows is bad, nor because you state that it's bad, but because you specifically use the phrase "disgusting hackjob." Obviously, a lot of people put a lot of work into that code, and calling it that just makes you look like an asshole. Pointing out technical flaws is one thing, making sweeping, emotionally inciteful comments is a troll.

As to that last bit about being branded by your user name and "tossing a label on you"...you gave that user name to yourself, and I'm quite sure you knew the associations with it, so I can only assume that you intended those associations to be given to you.

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.

Obviously, a lot of people put a lot of work into that code, and calling it that just makes you look like an asshole.

Very well, but me being an asshole doesn't change the fact that X has been poorly maintained and NEEDS a rewrite or discarding in favor for something new(this is my preference). The amount/quality of the work is diminished by the poor job in which the code was added and maintained making what we have today. Which is in fact a disgusting hackjob. The linux kernel was kept clean, organized even through major additions failing to do so with X makes it undesirable and in my opinion unsavable. X is a hackjob. because features and changes were "hacked" in without any thought or care as to the future maintainability and without a clear vision of good structure.

As far as name association goes lets try one on you. We can infer from your name that you are small, slimy. Traditionally using newt as a descriptor of a person was an insult which could basically be equivalent to dim-witted. So thats my assessment you are small, slimy and dim-witted.

Re:question

[mr.newt]

Nobody suggested you sugarcoat anything. But the fact is that you dropped those adjectives without anything to back them up. Now you're coming back with comments with some substance, which is what you should have done in the first place (to avoid being a troll).

You being an asshole or not has no bearing whatsoever on X or how it was maintained, you're right. But you being an asshole or not has direct bearing on whether or not your posts are insightful comments that are worth reading, or just flamebait.

As to the last comment, thanks for the chuckle.

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 info pages.

DT

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!

Re:Review?

[Anonymous Coward]

You must be new here.

This book is insecure.

[bigtallmofo]

It talks about programming in C and C++ and is therefore insecure.

Re:This book is insecure.

[Anonymous Coward]

This book is insecure.

Yeah I know, the other day I saw my roommate reading the book in root mode highlighting text and folding pages.

LWN Review

[Corbet]

Just FWIW, I reviewed LAD2 in LWN about a month ago.

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?

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: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

[Necroman]

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

Those are books with nice titles...

[Anonymous Coward]

There is one proverb in Russian "Let we live some time and see how is it!" - (sorry for poor translation of "Pojivem pospotrim")

You see "OSTG" earned some money for paied article, publishers will also earn something, even autors will get some money... if they are realy good life will show and we will have 2nd edition etc.

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?

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

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

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

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

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

[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 arcane and fragile desktop environments and there are no parents or next-door neighbors out there that are going to run Linux because of the difficulty of managing the working environment. That's the reason I use Linux as a server and Windows for desktop stuff. Even though I know how to manage X, desktops, etc., I just don't really care to deal with it.

Re:Application development?

[Bitchslap_69]

I meant to add to that last... The very reason I looked at the review of the book was to see if there was finally a book that included both application internals and exposing those internals (that is, making the functions of the application available thru manipulation of the inputs and presentation of the outputs) through the GUI.

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?

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

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 doubt that's how most people do it.

Daniel

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.

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?

[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 do this, but this is much better than Visual Studio).

And if you're designing applications to be cross-platform, you'll want to break everything up into individual shared libraries so that can be rebuilt separately and used for both command line and GUI applications.

Then the only purpose your GUI code serves, is to connect the event handlers to your library functions.

Re:Application development?

[Anonymous Coward]

That's the definition for "applications", with an 's'. Look at the example usage that follow to see the distinction.

Above that, for the word "application" (without the 's'), it says:

7. Computer Science. A computer program with a user interface.

Way to deliberately ignore stuff that doesn't support your argument.

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?

[Anonymous Coward]

I've been doing commercial Linux application development for about 5 years, and the vast majority of it has involved writing daemons, client/server apps, small console "tools", device drivers, etc.

I contend that most beginning commercial Linux developers prefer a book that doesn't contain a single "Hello, World" GUI example.

Maybe it's different for open source programmers or Windows code monkeys...

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 interfaces aren't just what Microsoft has tried to train you to believe they are.

PS, a great user interface is still just an interactive picture without an application.

Re:Application development?

[Bitchslap_69]

Considering that interacting with network sockets is done entirely by libraries that handle such things for you if you know what you're doing and you'll realize that what you're talking about just isn't programming, it's gluing together other people's libraries. Unless you're writing machine code that directly addresses the hardware layer, you're standing on the shoulders of giants.

But if you've ever created a relatively complex user interface, you're not just "drawing buttons" or just doing design. Sure, there's a design component to it, but there's a design component to everything in application development (at least if done properly; I've worked on enough projects where there clearly wasn't a design component before implementation and that's as nightmarish as a slapped-together user interface). And if you're creating something for people to use directly (word processing, music, or graphical interaction such as drawing, graphics manipulation, or CAD/CAM) as opposed to accessing through some other means (e.g., a service that's accessed through an API on an application server and exposed through a Web interface), then there's a need for a graphical interface of some sort. Hell, even server and daemon apps benefit greatly from a robust graphical interface for configuration and administration.

Look, it's a stupid argument: maybe some people are too cool to use GUIs, but lots of people, including professional developers, want them and need to create them, if for no other reason than that people who aren't as cool as you find them to be a necessity for interacting with the system. As such, creating a GUI is clearly a part of the application stack. If you don't want to write a GUI (or even if you do), then go ahead and get this book. What the OP and I and others want, though, is a book that addresses all parts of the application stack, even the uncool parts.

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.

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.

The dedication turned me off.

[Anonymous Coward]

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.

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.

[Anonymous Coward]

Science??? You haven't attended any real science classes or done any real science in your life if you think this passes for science. It appears you have no education or faith, must be fun to be you. You're dumb and you don't have anything to live for!

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 "light of my life". All very untechnical. Do these offend you too? All I can read into your complaint is that you are incredibly sensitive to the idea that someone may discuss something you don't want to hear about.

Re:The dedication turned me off.

[dankelley]

Jealous because so few books are dedicated to Anonymous Coward?

Re:The dedication turned me off.

[mr.newt]

I agree with your sentiment, but who did you say the dedication was directed at, again? His dead grandmother?

Why this book?

[boohiss]

There's hundreds of programming books released all the time. Why is Slashdot interested in this particular one?

--
Earn a free iRiver

Re:Why this book?

[mozingod]

I don't think it's Slashdot, so much as the author of the review. These are submitted by readers after all...

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.

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.

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?

[Anonymous Coward]

TCL ?
Java ?
Perl ?
bash ?
glade ?
Mozilla/CGI ?

Rad enough for ya?

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

[pclminion]

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

Here you go.

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, 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?

[Anonymous Coward]

REALBasic. Right?

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

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?

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

[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/-/1572 31995X/qid=1107987162/sr=8-4/ref=sr_8_xs_ap_i4_xgl 14/102-6770576-5407306?v=glance&s=books&n=507846 (no referrer link or anything)

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

[Anonymous Coward]

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

It's Gambas. Maybe the name should be changed to Visual Linbasic or something more...memorable. :D

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

[Bitchslap_69]

The Unix shell is fine for geek work: editing confs, shell scripts, etc., even doing application development with emacs and all that. But end-user apps are not of the same nature. For stuff that you want regular users to use instead of just geeks, you need some sort of GUI, supporting mouse interaction, hot keys, graphical presentation (i.e. pictures, charts, video, etc.). The easiest way to manage that is with a good RAD system. That's what the original poster was asking about. I know that I'm aware of the shell, since that's what I do 99% of my work in Linux with (ssh into the server box from my Windows dev machine). I actually use IntelliJ's GUI designer to create Java-based GUIs for the stuff that I want to have a nice windowed interface. This works pretty well, but Java GUIs are not generally too high performance, e.g. CAD or graphics apps need much better response.

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

[Anonymous Coward]

check out www.guptaworldwide.com

They have recently released a RAD tool on Linux. Currently runs on WINE. But a native version is planned next year

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

[cakoose]

Gambas. I really wish it wasn't based off of Basic, though.

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

[Mishura]

Basic? You mean that 10 PRINT Hello World! 20 GOTO 10 thing?

People still code with THAT?!?!? Man last time I touched basic, I was 6 years old, and on one of those "PreComputer" deals that they pushed on kids as a "computer".

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

[Anonymous Coward]

"It's called Qt and its found at TrollTech. 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."

No, you're stuck with C++, meaning you'll be using a dangerous language that compiles slowly, is overly dependent on hacks (like the preprocessor), etc, and then you'll have to use QT's hack (moc) to get around C++'s shortcomings. Give me Pascal or even BASIC any day.

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

[Anonymous Coward]

There are plenty of RADs. But first you need to decide on a programming language.

Ada:
Glade

BASIC:
Gambas
Phoenix
Rapid-Q

C:
Glade

C++ (why?):
Glade
Kylix
QT Designer

Pascal:
Kylix
Lazarus

Python:
python-glade

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?

[lachlan76]

Yeah, I was surprised too ;)

Re:Magic

[Anonymous Coward]

NO, It's called the FARGATE. Get it straight!

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 =)

"development"?

[flacco]

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

Re:"development"?

[Anonymous Coward]

apt is a cow, not a faerie.
And it has neat powers.

Re:Hahahaha!

[Anonymous Coward]

You realise google will only cache posts at +1 due to slashdot's default settings?

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

[GigsVT]

Ask a lawyer why legal documents seem cryptic.

If you are communicating a complex idea, the language you use must be precise. "Dumbing it down" often leaves vague areas, not something good in documentation or in legal documents.

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. Which lead to another term. Soon, I'd be trying to figure out the "big picture" design of all of these thousands of cryptic terms all over the place, just so I could figure out the one thing I was investigating in the first place.

Anyone who uses Linux extensively has less problems, no doubt, due to a fundamentally broader understanding of the operating system, it's approaches, and terminology. But for an outsider trying to figure out how to do one specific thing (like install a program without compiling several DLLs etc.), it's difficult.

The Art of Unix Programming..

[rjshields]

.. gives a good overview of the subject

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

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?

Re:Don't forget...

[Anonymous Coward]

That's cheaper than Rat Had's Lunix. Where can I get 10,000,000 licenses?

Isn't it time to move on?

[As Seen On TV]

Based on how Slashdot readers have responded to my other comments today, I'm fairly sure I'm going to get some hate mail for this, but here goes anyway.

It seems to me that now, in 2005, all the useful command-line programs have been written. There are no more useful command-line programs out there to write. So why does a book like this even bother discussing the writing of command-line programs? Isn't it a big waste of time?

The way I see it, the useful software that exists right now falls into three broad categories: embedded software, server software and applications. Embedded software is stuff like aircraft avionics. There's no user involved. Server software includes stuff like Oracle and WebObjects. There's a user involved, but not directly. And applications are what we all use on our desktops and laptops.

Nowhere in there is there room for a command-line program that hasn't yet been written. All the basic tools for dealing with files and stuff have already been perfected (at least to the extent that they're going to be).

So why even waste any energy on it? Isn't it kind of like having a chapter at the beginning that discusses the right way to encode your program onto punch-cards?

Re:Isn't it time to move on?

[Anonymous Coward]

for basic things, file I/O etc, you're probably right. But what about implementing algorithms in specific domains of study (finance, statistics, computer science). Lots of these don't require anything fancy, in fact, all they need is an input file or database. The program then just crunches the numbers. This is what the command line is best at.

Re:Isn't it time to move on?

[Anonymous Coward]

This is why the application should be split into it's appropriate tiers so that the presentation layer, which could be a command line, a GUI or a web page, is relatively interchangable.

Re:Isn't it time to move on?

[Anonymous Coward]

yeah, and we should close the patent office, since it's all been invented...... Hey! 1899's calling, they want their short-sightedness back.

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 or compiled, is that they don't suffer from bloat of either code or usage. In the Windows world, it seems, the command line utility is some inferior life form.

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.

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.

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

In any case, your Unix way of doing things doesn't sound any better to me. But what do I know? I'm a MacOS user.

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 Unix way of doing things
> doesn't sound any better to me. But what do I
> know? I'm a MacOS user

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

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 seems easier to me than editing the registry. (Of course, XP has a GUI for that setting.)

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, doing the specific job they were built for. custom applications abound!

[all the linux press/hooplah these days does tend to overlook the customer-built installs of linux, i think .. distro war or none, linux is involved in running a lot of the empire of man, i would say ..]

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

[LilMikey]

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

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
• Mono's GTK+ sharp page
• Mono docs
• gotmono

Re:Magic

[Anonymous Coward]

wtf does your retarded comment have to do with the parent post?

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 command line now.

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 been written.

A very strange claim to make, considering it can be trivially disproven by counterexample.

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. It's the open-source MPEG2-video (i.e. DVD) creation package. You'll have to look at the CVS version to see my latest contribution, though; it's not officially released yet. It's called y4mdenoise; you can browse the CVS version here. It's a new temporal noise-reduction tool for digital video, that does such a good job of inferring clear images from several noisy examples of them, that it can make a videotape look like it came from a LaserDisc. No kidding.

You remind me of the head of the U.S. Patent Office in 1899, who said that everything that can be invented has been. I wish people like you would get the heck out of the way of people like me.

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

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 philosophy and capabilities, and so you know where to start looking with man.

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.

Linux apps are easy!

[Anonymous Coward]

the hard part is getting that JVM installed.

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.

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

Interesting

[Anonymous Coward]

The first part freaked me out

Writing Linux applications is not a simple endeavor

Um. What?

I've found writing Linux applications rather simple to be honest. Pick any well-known distribution and you instantly have a solid development environment within which to work. Everything you need is "right there". You even get a great wealth of knowledge to base your development on. Want to code a network driver? Just take a look at the source code! Want to go high-level? There are a plethora of tools and libraries all with source, as well as a veritable treasure trove of documentation. On top of this you have IRC and USENET!

Compare this to writing a device driver in Microsoft Windows. You start from scratch. Everything is closed. Try to find someone knowledgeable, and you're met with eother hostility or blank looks. Anything you want to do means shelling out a lot of hard earned cash - and thats just to get a development environment!

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->next_thread->lock);
pthread_cond_broadcast(&inf->next_thread->cond);
pthread_mutex_unlock(&inf->next_thread->lock);
pthread_join(inf->next_thread->id, NULL);
}
return NULL;
}

struct thread_info *build_chain(const char *str)
{
struct thread_info *inf;

if(!*str)
{
return NULL;
}
inf = calloc(1, sizeof(*inf));
pthread_mutex_init(&inf->lock, NULL);
pthread_cond_init(&inf->cond, NULL);
pthread_mutex_lock(&inf->lock);
inf->ch = *str;
pthread_create(&inf->id, NULL, do_thread, inf);
inf->next_thread = build_chain(str + 1);
return inf;
}

int main()
{
const char *str = "Hello, world!\n";
struct thread_info *chain;

chain = build_chain(str);
pthread_cond_broadcast(&chain->cond);
pthread_join(chain->id, NULL);
return 0;
}

Really Insightful!

[Anonymous Coward]

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.

I agree to the first statement; this is probably why documentation *always* sucks, both the electronic and the print versions.
But there are a few books worth reading, mainly those about standards. X11 protocol (and Xlib), POSIX or network books with 'cleaned up' versions of important RFCs provide knowledge beyond the next major version of $foo.
I guess that's why I really like standards.

Re:Magic

[Anonymous Coward]

Well, it's not Hello World, but here is the factorial function presented as The Evolution of a Haskell Programmer

Problems with Linux Development Books

[Anonymous Coward]

But I just want to give a different perspective.
How useful would this book be to the average developer,
I mean really, really ? I have a book on my shelf called
Linux Programming By Example (2000)

Its a good 5 years older than this book but the book reviewed doesnt seem to improve much on it. The same topics (more or less ) are covered from systems programming , process management and using Berkley DB. I havent really read the book , opened it once or twice to find out about the Berkley API ( information I could easily have found on the net ) and thats about it. All I did was refer to it, I found it a bit to boring to read.

Now why is it that? IMHO I think that these books try out to do what the internet does already well, that is provide a good solid reference for programming tasks.

Almost everything I have learnt about Linux development has been from internet resources and not from books that I have bought or read. I think there should be more books
out there that show you how to stitch things together,
or use the different ( commonly used ) technology together to solve particular problems.Not algorithmic problems but just general application architecture from
Linux Dev perspective.. How do I build a robust application,scalable application using Open Source tools?

And most of the problems I have encountered in Linux Dev is in GUI dev. Very few books , intelligently touch on WxWindows, QT dev or even how to use GTK2 in the context of application development.

Very few books show us how to integrate our applications into a Linux Desktop environment. A lot of OSS apps
seem to give the feeling that the interfaces took less
than week to do after skimming thru the GTK or QT tutorials.

I digress, back to my main point. We need to know how to
stitch things together with what we have.

Bollocks

[Peaker]

Qt, KDE and PyQt/PyKDE are far better GUI development solutions than anything Microsoft has ever put out, .NET included.

Re:Bollocks

[Bitchslap_69]

Bollocks to you. This shows that you really don't know what you're talking about. .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.

But I'll assume you're talking about Visual Studio .Net. I haven't used PyQt/PyKDE, but from what I can see, it's Python-based. That's fine if you know Python (and I do), but not everyone does. VS.Net offers 3 or 4 different development languages that easily work together. YOU like PyQt/PyKDE, but that doesn't make it "far better" for everyone's purposes. It just means that you like it.

And your point is basically immaterial to the main thread: there's a ton of support and information for and about developing Windows GUI applications, that is, the full application chain from front-end to back, and there's a paucity of such information for Linux. Want proof? Do a Google search for PyQt/PyKDE. There's no definitive set of resources, little or no professional documentation, etc. That's precisely my original point and what I was hoping the new edition of LAD would address (not PyQt/PyKDE itself, but just any good GUI solutions as part of the application stack).

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 right language for GUI and most of the other non-performance-critical applications.

VS.Net offers 3 or 4 different development languages that easily work together.

Besides for Python.NET, the rest are statically typed and otherwise very difficult to program in (compared to Python, ofcourse) and thus a very poor choice for high-level code such as GUI code.

YOU like PyQt/PyKDE, but that doesn't make it "far better" for everyone's purposes. It just means that you like it.

No, PyQt/PyKDE are better objectively in terms of API consistency, simplicity, power and expresiveness.

When I like something I say I like it. PyQt/PyKDE are simply better than all Microsoft GUI solutions out there.

And your point is basically immaterial to the main thread: there's a ton of support and information for and about developing Windows GUI applications, that is, the full application chain from front-end to back, and there's a paucity of such information for Linux

That is because a ton of information is needed to program Windows GUI applications as the Windows API's are so horribly broken and difficult to use.

As for Linux lacking documentation (more accurately PyQt/PyKDE as those are portable to non-Linux systems unlike Microsoft GUI tools), I did try a Google search and this is the first result.

Note that this documentation, unlike the MSDN has a consistent format, is usable as a reference and as a tutorial and is comprehensive and complete uniformly across all aspects of Qt. Can you claim this about Microsoft's documentation?

Re:Bollocks

[Bitchslap_69]

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

No, you weren't "obviously" talking about the GUI libraries and RAD tools available for .Net. You assume that everyone reading your posts knows your entire context. So when you say, "This rules! That sucks!" you sound just like any other fanboy moron. I have no way to evaluate the soundness of your argument besides that. My guess, based on your demeanor and argument, is that you're a dickhead. Hell, you might be right. But that doesn't mean you're not a dickhead.

And .Net CLEARLY is not the GUI libraries and RAD tools: .Net is CLEARLY something else entirely, just the same as the various windowing APIs and development tools for *nix systems are CLEARLY different from the underlying system architecture, which is what this whole discussion is about. I would expect someone who fancies themselves an engineer or developer or whatever to be more precise.

Qt is a C++ library usable from many languages. PyQt is its Python bindings. Not everyone does, but everyone should, because it is the right language for GUI and most of the other non-performance-critical applications.

OK, I'll be sure to let everyone know. Your initial arguments ("Bollocks! .Net sucks! PyQt/PyKDE rule!") were certainly convincing. And knowing that "it" (by which I assume you mean Python, although your language is again not very clear) is the right language should certainly convince everybody to drop everything else they're doing and get on the PyPeaker train.

Actually, I've done a fair bit of Python development (not for GUI development, but for various scripting and task automation uses), but I'm starting to drop it in favor of Ruby. So let me just interject: Ruby is the new right language! Can you refute my reasoning?

No, PyQt/PyKDE are better objectively in terms of API consistency, simplicity, power and expresiveness... When I like something I say I like it. PyQt/PyKDE are simply better than all Microsoft GUI solutions out there.

OK, that convinced me! It's objectively better (and objectively is bold, which means it must be true). You like it, you've said so, and it's simply objectively better. Were you a debating champion? These are very very convincing arguments. In fact, I'll drop all other development solutions I've seen and switch to this based completely on these very salient and perceptive points: objectively better and you like it.

That is because a ton of information is needed to program Windows GUI applications as the Windows API's are so horribly broken and difficult to use.

And the windowing APIs for Linux have historically been wildly easy to learn and access. Uh huh. Which is why I and others have been looking for a good book on GUI development on Linux for years and not finding it. Maybe PyQt/PyKDE is the answer I've been looking for. Dunno, I've never heard of it before, which proves the problem that the tools for GUI development on Linux are wildly fragmented and inconsistent overall. So thanks for the reference and I'll look into it.

As for the Windows API being broken, I really don't know about that anymore. The windowing libraries and development tools in VS.Net, Borland C++/JBuilder, and IntelliJ are really smooth, so I do most of my GUI development on Windows in C# or C++ or sometimes in Java if it's either cross-platform or just for myself. The fair comparison then would be a comparison between either the Win32 windowing APIs and the base X windows APIs or between the higher-level windowing libraries provided in RAD tools for both platforms (it's also an area I'm familiar with, having worked on the first few years of API libraries at Borland, including the big revisions of the OWL libraries).

As for Linux lacking documentati

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:Oh yeah? What's this, then?

[As Seen On TV]

You're either a troll or a dimwit.

Sigh. This is such a friendly place.

It's the open-source MPEG2-video (i.e. DVD) creation package.

Um. That's nice and all, but it sounds from skimming the marketing hoo-hah that it's drastically inferior to products like Compressor and Cleaner. No real-time preview, no support for other codecs, no queueing or batch-processing facilities, no user-friendly interface.

It's a new temporal noise-reduction tool for digital video, that does such a good job of inferring clear images from several noisy examples of them, that it can make a videotape look like it came from a LaserDisc. No kidding.

I'm sure you're not kidding, because Sonic has had that tool for at least seven years now. I first saw it in 1998. And they had a real nice application wrapped around it, too, which is more than I can say for "mjpegtools."

Development jungle

[Anonymous Coward]

It always kinda strikes me as odd when someone tries to cover Linux application programming in one book. I mean, look at the ridiculous number of choices one has to make before even writing the first line of code.

1) KDE(QT), Gnome(GTK), or others
2) What distros will this work on... "this won't work on anything short of Red Hat 9 unless you upgrade all these libs"
3) Are there any nice pre-written components to let me get this on the shelf sooner... well yes but this ones written in QT and I've decided to do my project in GTK.
4) Lastly... "I need help with this error message I'm getting". Community response: sign up to this major domo newsletter and maybe someone will answer (if were not already tired of answering your dumb question for the last guy that asked).

I hate to be too sarcastic... but it really sucks to be a Linux developer don't you think. There are lots more people doing windows development and most of them using alot less different tools to get the job done. Chances are I can find the exact windows error message I'm trying to debug on a website somewhere. People who truly love Linux will point to it's diversity as it's strength. That diversity is a double edged sword however. Yes... you have the freedom to choose from X number of programming environments- but ultimately Linux is losing out the developers can't all get on the same bout. Thank goodness everyone at my company is using the same tools/language/operating system. I guess I'll end my rant now. Moderators please: I do check my replies so please write an intelligent response rather than killing my karma because you don't agree with me.

Are these Linux applications?

[ulatekh]

Seeing as how we're discussing Linux applications and all...how about some URLs for Compressor, Cleaner, or Sonic?

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 call-with-current-continuation)

(define make-writer
(lambda (next-char)
(lambda (k)
(let loop ((k k))
(let ((ch (next-char)))
(if ch
(loop
(begin
(display ch)
(call/cc
(lambda (my-k)
(k my-k)))))))))))

(define make-next-char
(lambda (get-nth-char max-idx start stride)
(let ((retrieve (lambda args start)))
(lambda ()
(let ((idx #f))
(set!
idx
(let ((old-retrieve retrieve))
(let [(k (call/cc (lambda (x) x)))]
(cond
[(number? k)
(and (< k max-idx) k)]
[(not k)
(and idx (retrieve (+ stride idx)))]
[else
(set! retrieve k)
(old-retrieve #f)]))))
(and idx (get-nth-char idx)))))))

(define-syntax make-looper
(syntax-rules ()
((make-looper idx nth-char max-idx)
(lambda ()
(let* ((get-nth-char (lambda (idx) nth-char))
(next-char1 (make-next-char get-nth-char max-idx 0 2))
(next-char2 (make-next-char get-nth-char max-idx 1 2))
(writer-fn1 (make-writer next-char1))
(writer-fn2 (make-writer next-char2)))
(writer-fn1 writer-fn2))
(newline)))))

(define hello-world
(make-looper idx (string-ref the-msg (remainder (* 12 idx) 13)) 13))

(hello-world)

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 (+ stride (call/cc old-final)))])))))))

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.

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

Re: Man pages vs tutorials

[some guy I know]

You don't try to learn a language by reading the respective dictionary from front to back either, don't you ?

Man, I knew that I was doing something wrong!
Arigato, dude; arigato gosaimasu.

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.

It is fun!

[wiredog]

If you're a programmer.

WTF are Info pages for?

[SgtChaireBourne]

I find man pages very useful in most cases. But what on earth is the point of info pages? Is there anything about them that cannot be done in HTML 2.0 and lynx?

Re:Oh yeah? What's this, then?

[Anonymous Coward]

So where's your implementation, cocksucker?

True...

[Ayanami Rei]

although looking at man 3 readline... I don't think you'd need a book to cover that. :-)

Sorry, I didn't read the book. But I mean there are lots of applications which are not GUI oriented... well so most of them are computing environments or expert systems but people pay a lot of money for them! ;)

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 to work correctly? I'd say it's far from sophisticated--it's clunky, ill conceived, and hard to apply effectively.