Follow Slashdot stories on Twitter

 


Forgot your password?
Close
typodupeerror
×
Programming Books Media Book Reviews IT Technology

Linux Programming By Example 155

Posted by timothy from the do-what-i-do dept.
Craig Maloney writes "Linux Programming By Example is a book aimed squarely at programmers learning how to program the Linux and UNIX system for the first time." Read Craig's review of Linux Programming by Example (below) to find his take on whether the book delivers on the promise of its title.
Linux Programming By Example
author Kurt Wall
pages 533
publisher QUE (InformIT)
rating 9/10
reviewer Craig Maloney
ISBN 0789722151
summary Linux Programming by Example is a concise and solid introduction to programming under the Linux system. Excellent instructions accompany fully-working examples of code.

There are plenty of books on this topic as any trip to the bookstore will show. Where this book excels compared with other Linux programming books is its consistent focus throughout. Other books tend to explain a multitude of concepts without relating them back to a real-world example. In Linux Programming By Example, the author introduces a concept, and explains it with an example. In the last chapter, the author integrates the knowledge he's presented, utilizing many of the book's concepts in building a simple CD-Database program. Of course, not all of the concepts relate to the final CD database (The chapters TCP/IP Programming, The Sound API and Using the Mouse are not referred to in the final program), but it's helpful for beginning programmers unsure how all of these pieces fit in the bigger picture of a working program.

Begin at the beginning

Linux Programming By Example begins with topics that don't get covered until the end of many books. The book starts by discussing how to use GCC and make on a Linux machine, and how to create a Makefile. It's always puzzled me why some books don't cover the compiler or the make process until the end of the book. What's the point in that? Granted, chapters in debugging and RCS are left to the end of the book, but presenting key concepts in the development process early in the book helps the reader to get a better feel for how all of these concepts interrelate in a Linux/UNIX environment.

Moving forward

From the basics of compilation and making programs, the book moves to the basics of a Linux system in Part II: System Programming. This is where the book truly shines. In the section on processes, Wall discusses the elements that make up a process, how to manipulate a process, and why you would want to do this anyway. The book assumes no prior UNIX knowledge, but doesn't plod along like most introductory texts. In the section on signals, the book defines what signals are, early signal APIs and their issues, POSIX and Linux signal APIs, and how to use signals and signal sets. In this chapter, the author not only lists the signals supported by the Linux system, but also other signals supported by POSIX and other UNIX systems. While this might sound confusing, the author takes time out to explain which signals are really important in a Linux environment. This is a key reason why this book retains its readability without losing depth. Each chapter in the System Programming portion of the book retains this format -- not only demonstrating what the topic is, but also where this fits in a Linux/UNIX system and why you would even bother to know this in the first place.

What's good?

Linux Programming By Example is clearly aimed at getting programmers up to speed on not only programming Linux systems, but also POSIX based systems. Wherever possible, the author makes a point of pointing out the POSIX way. This book could have been easily called POSIX Programming by Example. The author also makes no bones about implementation issues with Linux and the POSIX or System V way of implementation. The book clearly states where Linux falls short of the full POSIX standard, and where pitfalls with porting code from other systems may occur. It's a refreshing change from other beginner texts which assume the reader will discover these pitfalls on their own.

So what's in it for me?

If you're looking for a quick, effective way to get up to speed in Linux and UNIX programming without breaking the bank, Linux Programming by Example is the book to take you there. This book is designed for programmers who are familiar with programming on other systems but haven't dealt with Linux before.

You might have trouble locating this book, since QUE let it lapse for a while, but there should be another batch hitting stores soon. You won't be disappointed.

You can purchase Linux Programming By Example from bn.com. Slashdot welcomes readers' book reviews -- to see your own review here, read the book review guidelines, then visit the submission page.
This discussion has been archived. No new comments can be posted.

Linux Programming By Example More

Linux Programming By Example

Comments Filter:

  • Chicken and egg (Score:4, Funny)

    by Ed Avis ( 5917 ) <ed@membled.com> on Wednesday October 30, 2002 @12:03PM (#4564765) Homepage
    But where is the 'Reading By Example' that tells you how to read this book?

  • WROX press books also very good on the subject (Score:4, Informative)

    by vasqzr ( 619165 ) <`vasqzr' `at' `netscape.net'> on Wednesday October 30, 2002 @12:04PM (#4564778)

    I've always liked the the red books.

    B&N [barnesandnoble.com]

    • ... the hideously ugly, deformed mutant greaseballs on the covers.

      At least, that's why I buy WROX Press publications. I've got a whole library, and it looks like the bleedin' Chernobyl yearbook exploded on my bookshelf.

  • Excellent (Score:2, Interesting)

    by TerryAtWork ( 598364 )
    I've been looking forward to a book like this - I hope it'll wean me off my years of windows programming and step up into the majors...
    • I hope it'll wean me off my years of windows programming and step up into the majors...

      I'll bite, so why do you feel that years of Windows programming has left you in the minor leagues? I would think your league is somewhat indicated by pay check and years of windows development should pay nicely.

      • Re:Excellent (Score:3, Insightful)

        by TerryAtWork ( 598364 )
        Maybe I'm pathetically striving for geek chiche, but I have always felt that the *nix school is the next level up.

        They seem so free of the weird little troubles that plague windows people, they are in charge of their own systems and not spoon fed like windows users, they run the entire Internet (at least the bedrock of it), and they have a system that has remained fundamentally almost unchanged for 30 years in this turbulent industry.

        I interpret that as a sign of evolution into perfection, or something like it.
        • Maybe I'm pathetically striving for geek chiche, but I have always felt that the *nix school is the next level up.

          They seem so free of the weird little troubles that plague windows people, they are in charge of their own systems and not spoon fed like windows users, they run the entire Internet (at least the bedrock of it), and they have a system that has remained fundamentally almost unchanged for 30 years in this turbulent industry.

          I interpret that as a sign of evolution into perfection, or something like it.

          Don't get mixed up between perfection and people who affect an air of superiority/snobbery.

          There's a big difference. Perfection? Unix ain't it.

          Simon
          • It's the closest you'll find to perfection.
            • It's the closest you'll find to perfection.

              In what régime?

              It's certainly not the 'perfect' OS by any stretch. There are systems with more cohesive GUIs out there. There are systems with better handling of removable media out there. There are systems with better real-time support out there. And woebetide you if you try to run Linux on a parallel processor machine.

              There's no such thing as perfection. It's an abstract concept. Everything is a shade of gray somewhere in a continuum of choices.
              • It's the closest you'll find to perfection.

                Sorry if that's not clear. I never said it was the perfect OS. In fact it is far from perfect, but read the first sentence again. Closest to perfection.

                In reply to better GUIs. Most Unices exceed in their lack of GUI. Nothing like a headless machine when you are limited on keyboards and monitors. If you need a GUI there is plenty of window managers out there.
      • It's an academic thing. Windows might be a commercially successful platform, but from an academic point of view, it's ugly. One look at Win32 is enough to see that it is a utilitarian API, not a clean, elegant one. Sure, Windows development may pay well, and I don't mean to slight Windows developers in the least, but there is a difference between a VB code monkey and a professor of computer science. In most people's minds, Windows and UNIX are representative of that distinction. Is this view arrogant? Undoubtedly. However, that arrogance is not entirely unjustified, and may be useful in pushing people to a higher standard.
  • His examples are clear and useful and I look forward to the day when most Linux programmers will have been taught using this book. I wish there was a way to get current Linux programmers to read it, because his advice is very sound and would make for much higher quality software than you see in the Linux world today.

    The current Linux programming wisdom comes from Richard Stevens, a know-nothing hack who spends more time talking about the out-dated concept of filesystem permissions and socket programming than he spends on GUI design! I mean, for crying out loud, Dick, this is the Aughts! We "aught" to be optimizing for the user experience, not ivory tower "engineering principles"!

    Anyway, throw away your copy of Linux Kernel Internals because this book replaces it...and then some!

    • a know-nothing hack who spends more time talking about the out-dated concept of filesystem permissions and socket programming than he spends on GUI design! I mean, for crying out loud, Dick, this is the Aughts! We "aught" to be optimizing for the user experience, not ivory tower "engineering principles"!


      BE SILENT spawn of MSCE! A good user experience is dependent on a good design. A bad GUI in a good design can be replaced/redesign easily. A good GUI in bad design is hopeless.

      It is just like a woman - you need a good body for that pretty face. (Thats the best analogy I could think of. It is not very good, however. I don't think it is easy to replace the head... No matter how good the body might be) /Rumagent
    • The current Linux programming wisdom comes from Richard Stevens, a know-nothing hack who spends more time talking about the out-dated concept of filesystem permissions and socket programming than he spends on GUI design! I mean, for crying out loud, Dick, this is the Aughts! We "aught" to be optimizing for the user experience, not ivory tower "engineering principles"!

      Linux programs are by and large written in c and c++. These require very little UNIX knowledge as Linux is built for portability. The "current Linux programming wisdom" comes from a variety of places not from one place. I learned C on my one and what I know of OS design I learned from Tanenbaum. "Engineering principles" can be used while designing for user experience, if they are not the end result is an OS that crashes when a program errors out (remember Commodore 64?).
      • "Engineering principles" can be used while designing for user experience, if they are not the end result is an OS that crashes when a program errors out (remember Commodore 64?).

        Remember Windows? You know, there are a lot of slashdotters that simply aren't old enough to remember the C-64. Around here you might as well say "Remember the PDP-7?" I mean, geez, you could at least use an example people can relate to!

        (FWIW, I am old enough to remember the C-64, but I never used one. I was too busy hacking Basic on my TRS-80 (the cartridge slot didn't work, so there was nothing else I could do with it!). In fact, the only Commodores I ever used were the PET in my 4th grade classroom and my friend's Amiga 1000 (now that was a sweet machine!))

        • Remember Windows? You know, there are a lot of slashdotters that simply aren't old enough to remember the C-64. Around here you might as well say "Remember the PDP-7?" I mean, geez, you could at least use an example people can relate to!

          Well, if you mention windows or Linux you have stuck yourself in one group and joined an ideological argument as far as most are concerned. Also, fwiw, I have never met any serious computer enthusiast who did not know what C 64 was.
    • Uhm.... is the parent post +4 informative or +4 sarcastic?

      I have another book for beginners called "Beginning Linux Programming" by Wrox press. It too had an example of a CD database. I guess CD databases make great real life examples.

  • Outdated? (Score:5, Informative)

    by ksplatter ( 573000 ) on Wednesday October 30, 2002 @12:08PM (#4564815)
    This Book Was published in 1999.

    It might be a little outdated. This review seems to be a couple of years late

  • I enjoyed... (Score:5, Informative)

    by cerebralsugar ( 203167 ) on Wednesday October 30, 2002 @12:08PM (#4564822)
    Advanced Linux Programming, from CodeSourcery/New Riders. It wasn't a "beginning/intro" book but still very easy to read and quite informative. Lots of great code samples too. The finale of the book is actually coding a bare-bones http server.

  • Other good Linux programming books (Score:5, Informative)

    by TraderElron ( 595546 ) on Wednesday October 30, 2002 @12:09PM (#4564832)
    I've used two Linux programming books, and would recommend both: 1. "Linux Application Development" by Johnson and Troan. A bit more advanced than "Linux Prog by Example," but I was able to use it effectively coming from NO linux/UNIX programming experience. 2. "Advanced Programming in the UNIX Environment" by Stevens. An excellent reference.

  • Linux Programming By Example????? (Score:3, Funny)

    by isa-kuruption ( 317695 ) <kuruption@@@kuruption...net> on Wednesday October 30, 2002 @12:10PM (#4564836) Homepage
    Who is Example? Is that some kind of hacker nick? What qualifications does he/she have to write a book about Linux programming? I'm confused!

  • Finally. (Score:2, Informative)

    by kpansky ( 577361 )
    Its nice to have an acceptable concise and accurate book that holds your hand through learning how to program in *nix. Programming is one clear advantage that *nix has over windows, especially since the tools are free and come installed by default.

    • over other *nix's though is that there are no such "defaults." Everybody rolls their own. Ain't it cool? I've used a number of small distros, for various advantages they held, that did *not* include gcc as a default and by not doing so performed certain design parameters of the distro all the better for it.

      gcc is *typically* installed by default by the major distros. There is something of a "protocol" to do so ( and even then a couple of distros aimed at the desktop newbie have also failed to include it at all, even as an install option).

      No matter what though, even if it isn't included with your distro as an *option* at install you can always just go download it.

      Now *THAT* is what is the coolest about Free/Open/Artistic/Whatever software.

      KFG

  • learning by example... (Score:3, Funny)

    by MosesJones ( 55544 ) on Wednesday October 30, 2002 @12:13PM (#4564856) Homepage
    I have always found that the best way to manage a team is by example. First person who breaks the build, smash his hands. Second person, shoot in the head... sure enough everyone learns from that example and works extra hard.

  • Makefiles.... (Score:5, Insightful)

    by idfrsr ( 560314 ) on Wednesday October 30, 2002 @12:13PM (#4564857)
    Probably the most evil and wonderful thing of programming in *nix environments.

    I am going to get this book because it covers make in the begining. I have always had trouble getting my makefiles to work properly in the few instances of linux programming that I have done. And even then I copied an existing one and adjusted it to my needs.

    I suppose the "there is only 1 makefile" saying exists for a reason...
    • hm. I don't know a shit about makefiles, but I use autoconf & automake rather succesfully in my applications. And I'd suggest same to you =)

    • Re:Makefiles.... (Score:2, Insightful)

      by ville ( 29367 )
      Learn how to use autoconf and automake ( http://www.gnu.org/ ) then you don't have to do the Makefile by hand. These tools will create the depencies for each object etc. // ville
      • Ick. Learn to structure your programs well, and to write portable code, then you don't have to ship tons of convoluted autocrap with your sources.

        The "just let automake take care" mindset is getting really annoying. There are already too many packages out there with an half-an-hour-./configure and shell scripts starting with #!/bin/bash. Duh.

        • Re:Makefiles.... (Score:3, Informative)

          by Zathrus ( 232140 )
          The problem is, even if your code is portable the compiler may not be. Or the linker. Not everyone is up to full ANSI compliance still.

          Ever worked on AIX using xlC? And libtool? They're totally different from the rest of the known universe and so even if your code will happily compile on Linux, Solaris, etc. then the makefiles have to be absurdly complex to handle AIX's weirdness.

          Of course, you may want to do dynamic linking since libtool and templates don't play well together. But, looky, xlC doesn't play well either so you have to have a separate .cpp that excercises all the templated functions you're going to use on a per-library basis. Don't need that for any other OS, but you damn well do for AIX.

          Automake and autoconf save us from most of the nightmare here. Oh, and we're also linking against Oracle and MQSeries. More fun.

          Yes, avoiding things like #!/bin/bash (or even ksh) is wise, but automake/conf have come into existence for a very good reason. Makefiles are godawful.
          • The problem is, even if your code is portable the compiler may not be. Or the linker. Not everyone is up to full ANSI compliance still.


            This is why almost every shop I've worked in (which is several in a variety of industries) uses gcc. Even when I worked for a company that was actually antagonistic towards free software the projects that were Unix based use gcc.

            This is also why it seems like most of the shops are closing down their compiler teams. Maybe I'm wrong. I know Sun used to have their own compiler (that cost extra), HP used to have their own (that was extra), IBM had their own as well (what do you know, it cost extra). I don't know how many companies still sell their own compiler; however, I don't see how they can afford to any more.
            • Because the compilers generate code that is considerably faster than gcc.

              We have gcc compiled here... but it takes twice as long to compile our code as it takes xlC, and the resultant code core dumps as soon as something actually happens. We haven't had time to trace the issue down yet, but we still hope to move to gcc because of issues we have with IBM's xlC and dbx (as in - dbx usually doesn't work).
    • I suppose the "there is only 1 makefile" saying exists for a reason...

      One makefile to rule them all
      One makefile to find them
      One makefile to bring them all
      And in the darkness bind them

      Don't get mad. It was either that or "All your makefile are belong to us."

      • I've seen that makefile. It evolved from the hands of one of my fellow tutors when we were teaching kernel-programming. It was only a single makefile but it compile an entire kernel, not by itself, but by spawning offsprings into every subdirectory and then executing the new makefiles one by one.

        I am not sure, but after a year or so, I think it grew concious and started modifing itself. I didnt understand it or any of it's offsprings any longer, but I am quite sure it was evil. And it never liked me! In the end I had no choice but to kill it and there was much rejoycement as the students had feared it as well. I had to write new makefiles for the subdirectories myself And though the new makefiles was simpler, had less features and required a more rigid structure of subdirectories everybody breathed more easily after that.

        I just fear some careless student might have a taken a backup and that it is still breeding evil offspring somewhere. Someday it might come back to revenge the murder of it's copies everywhere. So beware!

  • Not Stocked (Score:3, Informative)

    by TheKubrix ( 585297 ) on Wednesday October 30, 2002 @12:13PM (#4564860) Homepage
    The link to BN.com doesn't have the book in stock, get it at amazon.com [amazon.com] instead, only $9

  • 9/10 ? (Score:5, Informative)

    by Brandon T. ( 167891 ) on Wednesday October 30, 2002 @12:17PM (#4564886) Homepage
    I have this book, and I definetly would not give it a 9/10. The text is plagued with errors. Most of them are corrected easily enough, but it is still a hassle to type in some sample code and not even be able to compile it without debugging first. To make matters worse, the url in the book given to download the sample code (and the errata) doesn't work. Take a look at some of the amazon reviews [amazon.com] to gauge popular opinion on the book. I picked up my copy on sale for $10 at frys, but I would wait for a second edition or look at another book if you're planning to pay full price.

  • Make ? (Score:3, Informative)

    by tmark ( 230091 ) on Wednesday October 30, 2002 @12:19PM (#4564903)
    I don't know about other readers, but when I hear that a book has a section on Makefiles, I really wonder whether it is specialized and focused on a specific programming area (as "Linux Porgramming" would suggest), assuming general programming knowledge, or whether it is a general programming book aimed at capitalizing on interest in the particular subject area. Sounds like it is the latter. Is the book more about "Linux programming", or more about "programming on machines that happen to be running Linux" ??

    Here's the acid test, does it contain a "Hello world" program or something similarly trivial ?

    • Re:Make ? (Score:1, Insightful)

      by Anonymous Coward
      There are lots of operating systems out there, but in the world most beginning programers are in, there are two, linux and windows, if a begginning programmer is coming from the windows world s/he won't have the slightest clue what a makefile is. So I find it a tad difficult to understand your logic here... and to me, linux/unix programming by example sounds like a begginners text no matter how you cut it. I've never heard of an advanced "by example" book. Advanced programmers should be able to figure out how to code their own examples and should be able to expect them when needed from a decent book.

  • this can also be had (Score:3, Informative)

    by da_Den_man ( 466270 ) <dcruise@hotcoffee.WELTYorg minus author> on Wednesday October 30, 2002 @12:22PM (#4564930) Homepage
    Half.Com [ebay.com]

  • What's in a name? (Score:2, Insightful)

    by Anonymous Coward
    Can we stop saying "Programming Linux" or "Programming Unix" and start saying "Programming _in_ Linux" or "Programming _in_ Unix"? The former makes me think this is a book on programming an operating system.
    • Actually, "in" would be inappropriate for the use you describe. Using "in" would imply that "Linux" or "Unix" are programming languages. It would be better to use "under" or possibly "on". "Programming under Linux" or "Programming on Unix in C".

      I agree with your basic point, however, that simply saying "Programming Linux" implies development work on the core components of a Linux system. If you really wanted to be pedantic about it, it would imply simply the Linux kernel.
      • "Programming for Linux" would be even better because it specifies the target environment. I can program "under" or "in" Linux or Unix without the target being Linux or Unix. So the best choose would really be "Programming for Linux using Linux".
    • I suppose if you want to get really technical, if you are programming (in) Linux, you are kernel programming.

    • the real title should be
      "Programming GNU/LINUX"
      or
      "Programming GNU/LINUX with GNU tools"
      or better yet
      "Programming GNU/LINUX with GNU tools while using
      GNU/EMACS"

      nbfn
    • Actually, you can also read the statement as in "Programming Linux - to do something". In that case, the title is entirely valid.

  • great (Score:5, Funny)

    by tps12 ( 105590 ) on Wednesday October 30, 2002 @12:28PM (#4564967) Homepage Journal
    I've been looking for good working examples of source code for Linux programs.

  • Standard Store Linkages (Score:2, Interesting)

    by BShive ( 573771 )
    Amazon: Used & New from $8.49 [amazon.com] [referral]
    B&N: Not Stocked [bfast.com] [referral]
    Bookpool: Not Stocked [bookpool.com]

    Looks like the best bet is going to be half.com or a used bookstore - kind of an old text.

  • Alternatively... (Score:5, Informative)

    by vbweenie ( 587927 ) <dominic,fox1&ntlworld,com> on Wednesday October 30, 2002 @12:47PM (#4565100) Homepage

    The Wrox P2P title Beginning Linux Programming [amazon.co.uk], by Richard Stones and Neil Matthew, covers some similar ground: makefiles, shell scripts, some basic C, Perl and TCL (not really basic - they show you how to use these languages to do some typical linux-y things, rather than explain about structs and scalars), an introduction to GTK and a chapter at the end on writing device drivers. If you're an intermediate-level programmer unfamiliar with Linux as a programming environment, this book offers a good way in; recommended for VB weenies with a conscience.

    • As a non-VB weenie (;) -> Java and formerly C/C++ - I can't but agree with you. Stones and Matthews book is a reference when I need to bone up on things like multi-threading and signals under POSIX.

      A really great book.

      I wonder how their 2nd book Professional Linux Programming is? (Hint hint /. )

  • system level programming (Score:3, Interesting)

    by yonnage ( 131665 ) on Wednesday October 30, 2002 @12:55PM (#4565183) Journal
    Discusses how LINUX works at the system level by learning how and when to manipulate processes, send and catch signals, and use calls, and how to manipulate and read pipes and FIFOs.

    This book actually sounds really good, for advanced and beginner programmers that are new to linux/unix...

  • Book selling out! (Score:5, Funny)

    by Sean Clifford ( 322444 ) on Wednesday October 30, 2002 @12:56PM (#4565192) Journal
    Man, did everyone just go to Amazon and order this? Read BN was out, now Amazon - I was lucky enough to get one for ~$14; seems like every time I added to my cart a book was gone a few seconds later. Damn, this is the first time I've seen inventory slashdotted. :)
    • seems like every time I added to my cart a book was gone a few seconds later. Damn, this is the first time I've seen inventory slashdotted. :)

      Such a cart does not model the real world very well: somebody can take stuff that you already have in your cart?

      Perhaps it is based on New York shopping culture.

  • My Impressions of this book (Score:3, Informative)

    by starX ( 306011 ) on Wednesday October 30, 2002 @01:34PM (#4565538) Homepage
    Neither outstanding or terrible, it ranks as a decent, average book on programming on the linux system. Although I would recommend Beginning Linux Programming by Wrox over this one, based solely on the fact that it covers so much more material in roughly the same amount of detail. Still, Linux Programming By Example costs a little bit less (at least when I got it), and while the Wrox book covers more, LPbE does cover a few things that the Wroc book doesn't.

    On the whole I would say it really deserves a 6.5 or a 7. It's worth getting if you're looking to learn about programming on a POSIX system, but if you already have a book on the topic, you might want to save your money.

  • Kernighan and Pike also good (Score:3, Informative)

    by pjc50 ( 161200 ) on Wednesday October 30, 2002 @01:36PM (#4565556)
    I'd reccomend "The Unix Programming Environment". Despite being written in 1978, it's still an extremely good introductory text.

  • BN, what about Amazon? (Score:3, Interesting)

    by Chacham ( 981 ) on Wednesday October 30, 2002 @01:45PM (#4565635) Homepage Journal
    You can purchase Linux Programming By Example from bn.com

    I started to purchase books from Amazon.com once I realized that BN doesn't post bad reviews. Maybe they do now though.

    As much as Amazon may have patented a stupid thing, they don't seem to censor comments. Many books have many bad comments. And, that is why I am happy to buy from them.
    • Amazon censored my comment...

      I submitted a seriously thought through review on "Dekalog" (these are my favourite films I've ever seen) - though no-one could call them "happy!"

  • Bought it back in 2K, definately a good read (and helpfull). Having a chapter on NCurses and screen manipulation was a bonus.
  • One of the flaws that I've found while dealing with Linux - and to a lesser extend, the BSDs - is that they lack a comprehensive API. Having a solid API framework is one of the reasons that Windows and the Macintosh OS have been so successful.

    One of the hurdles that Linux has been unable to overcome is the fact that the various parts of the OS are kludges together. There is no synergy. X for example isn't well integrated into the rest of the OS. Consequently one winds up with inconsitent behavior: Sometimes right clicking cuts-and-pastes; othertimes it doesn't. There are other examples of this. A quick search of Google can help you find them.

    I would like to see Linux succeed. Hopefully the main development team will work on getting a solid API in place so that when I develop for Linux I can spend my time writing my program, not writing code that should already exist.

    Thanks,

    ET
    • I'm not sure what you're talking about. Your makeshift example about clipboards only tells us that different programs behave differently. I've seen Windows programs that didn't support copy-paste, albeit rarely - it's not an OS feature. And this has nothing to do with the OS (as in Operating System), but everything to do with a graphical user session and inconsistencies found there, which are admittedly a major problem for Linux in the desktop market.

      When you talk about Linux's API, you're on fuzzy ground. Do you mean the kernel, or possibly libc6 or some other centrally standardized libraries? Or all of them together? Which libraries, in that case?

      If you're worried about reinventing the wheel, don't be. Linux is equipped with pretty standard libraries that do much more than stock Windows libraries do. You just need to know which library contains the functionality you need. Just like in Windows, except you'll need to start making your own code much later, since the libraries provide you with much more ready-made functionality.

      Anyway, the library APIs are free (as in speech) for one thing! You can actually look at the source and see that the method the API documentation talked about actually exists, and you can see exactly what it does.

      Of the thousands of Windows libraries, only a portion is documented. MS has huffed and puffed this autumn and released several hundred new libraries with press releases to boost. But still parts of Windoze are undocumented to the developers at large. And rare are the people who have actually seen the source code that makes up even a minor part of Windows. And you call this a "solid API"?
      • When you talk about Linux's API, you're on fuzzy ground. Do you mean the kernel, or possibly libc6 or some other centrally standardized libraries? Or all of them together? Which libraries, in that case?

        (Begin obligatory rant)

        Why focus on the OS? API's and tools should try to be OS-independent. True, if you are writing device drivers or fast games it matters. However, for most things I think we are at the stage where API's and protocols can *hide* most of the OS guts. File systems, GUI's, etc. should all be OS-neutral protocols. We already have such more or less for HTTP and databases, for example.

        Kill Windows by making it irrelavent or invisible, not by adding yet more incompatible features to *nix. That won't work.
    • X for example isn't well integrated into the rest of the OS.

      And for a damn good reason too. X should not be integrated into any other part of what makes up most Linux systems as X is an addon. I should not need X to have a working Linux system and X should not need Linux to work itself. They are designed to be seperate.

      Sometimes right clicking cuts-and-pastes; othertimes it doesn't.

      Hmm ya.. right clicking has never cut os pasted anything for me before... perhaps it has something to do with the fact that the middle mouse button pastes, and the simple act of highlighting copies. This works everywhere too... uncanny how it works eh? If you are speaking of the inconsitancies say between desktop environments such as gnome and kde well... they extend the basic X clipboard in different ways. Gnome and KDE are two different systems, and if you mix them you'll get inconsistant behavior... it's the way these things work. You want consistancy... choose one and stick to it. Besides KDE and Gnome copy and paste are starting to work together lately.

      Hopefully the main development team will work on getting a solid API in place..

      Who? You mean the kernel developers? The XFree86 developers perhaps? Perhaps GNU (they do make glibc and gcc)? Maybe the KDE/Gnome teams... You're post is kind of awkward... I'm having a hard time telling if you are intentionally trying to be funny or really don't have a clue.

      Not even your reveered windows has an all inclusive API. They have GDI, DirectX, etc. etc. Different API's for each job and they usually don't communicate much with eachother either. So I must ask...

      What exactly are you talking about?
    • You have no idea what you are talking about.

      There are problems and the problems are that some API's are not designed well. But this has nothing to do with "comprehensive API" or whatever you are blathering about. Rest assurred that Windows uses a different call for cut/paste than it does to read files, just like Linux.

      X is "integrated" in that it actually uses communication calls that exist in the system and are used by other parts of the system. This is why it works remotely. In this area Linux is vastly superior to Windows for "comprehensive API", in Windows there is NOTHING below the graphics interface that is reusable by anything other than graphics. The fact that X has a horrible interface is certainly true but irrelevant to "comprehensive".

      Also I don't think right-mouse pastes in ANY program. Middle mouse does, and it works in every X program I have ever seen. The inconsistencies are in what Ctrl+V does, not in what middle-mouse does. The fact that you did not know this indicates that you know little or nothing about Linux.

    • He he. Some people like the Java/Win32 way of implementing everything under in one set of APIs. They find it cohesive, consistant, and easy to reference. Other people abhor that model, preferring the C/UNIX way of providing a powerful core and depending on third party extensions. They find it cleaner, more accepting of competing implementations, and easier to maintain over time. The first type of people see the second type of API as a hodge-podge of complexity and redundant effort. The second type of people see the first type of API as monolithic, inflexible, and a sure route to bug-heaven.

      I'm not going to suger-coat the situation in "I'm okay, you're okay" crap. The second type of people are right. The first style of API has its uses (for example, it's not a terribly bad idea in Java, which is used for end-user applications rather than systems programming) but is overall a crappy idea for a system-level API. Just note the difference between UNIX and Windows. How many API's has Microsoft had over less than two decades? DOS, Win16, Win32, MFC, ATL, WTL, .NET, etc, not to mention all the special purpose APIs like DirectX, Windows Media, etc. Compare this to the situation in UNIX. A UNIX developer circa 1980 could, with a little updating, be right at one in a circa 2002 Linux environment. The UNIX APIs, decades after they were invented, are still clean, while the Windows APIs (and even the Java ones, think about AWT or the initial container classes) are unclean even though each only has a shelf life of 10 years at most. Beyond that, bundling all libraries together discourages competing implementations. In UNIX, there are several libraries for every task. Competition breeds libraries that are better than others for particular uses. Lack of competition leads to a "One True Library (TM)" for each purpose that really isn't optimal for any given situation.

  • Surprising to see a good QUE book (Score:3, Informative)

    by James Youngman ( 3732 ) <jay.gnu@org> on Wednesday October 30, 2002 @02:36PM (#4566216) Homepage
    I'm very surprised to see a good review of a QUE book. I find that the ones I've read - and that includes a QUE book of which I was one of several authors - are pretty dire.

    The problem with QUE books (and other Macmillan Computer Publishing imprints) is attention to detail. Their production processes tend to introduce errors (for example, by loading the text into Word and having it change all the backticks to apostrophes - that happened to me!). Also, they don't usually seem to do reprints correcting errors, they just seem either to produce a new edition ("Special Edition", whatever) with a "Featuring FooMatic 97!" badge on the cover.

    Another problem with QUE books is that they just tend to be written and published too fast - no time for doing a good job.

    I should emphasise that Macmillan Computer Publishing, who produce QUE books, are as far as I know completely unrelated to the British publisher, Macmillan.

    Disclaimer: You should know that I've had a bad experience as a contributing author of several MCP books, and have vowed not to have anything to do with them again. So as you can see I'm very biased against them. I have not read the "Linux Programming by Example" book and indeed haven't made any comments about this book in particular.
  • Overall, I'm satisfied with this book, but there are a few annoyances:

    *When they say "by example", they mean it! The discussions are quite brief - most of the book is sample code.

    *I could do without the chapter on makefiles. It's not very informative and doesn't mention GNU autotools. You're much better off RFTM.

    *Likewise, the RCS chapter is a waste. Does anybody actually use RCS anymore?

    *The information on Berkeley DB is very outdated.

    The rest of the book is quite useful, but I'd recommend the Linux Programming Bible instead.

  • QUE?!! (Score:2, Interesting)

    by stonedown ( 44508 )
    I will never buy a QUE book. They publish a lot of "me too" crap, so they can jump on the bandwagon and make money off of whatever is the hot new thing. New Riders and Wrox, on the other hand, have a number of valuable titles on programming. I've bought a few, including: "Beginning Java" (WROX), "Beginning Linux Programming" (WROX), "Advanced Linux Programming" (New Riders), "VI Improved - VIM" (New Riders). These are all very high quality books (especially the VIM book - absolutely outstanding!!!). Well organized and easy to follow. I've noticed that QUE books have the appearance of containing a lot of information, but are disorganized when you sit down to read the material, and they just don't do a good thorough job of covering the topic.

    Interestingly, you can read online the full versions of the New Riders books I mentioned here [newriders.com].

    (If you have trouble with that link, go through the New Riders home page [newriders.com] and search for the titles.)

  • Unix Systems Programming for SVR4 (Score:4, Informative)

    by Zurion ( 2775 ) on Wednesday October 30, 2002 @04:27PM (#4567441) Homepage

    I have to write C/C++ code daily for Tru64 and Linux. Unix Systems Programming [amazon.com] and Programming with POSIX Threads [amazon.com] are two very good books. They aren't Linux-specific books, but I've used these books on a weekly (or daily) basis for a couple of years despite the USP book being written in '96.

  • This book is in the bargain bin at Fry's for $12.49. The Industry store has about 10 of them in stock as of 2:00 this afternoon.
  • ...is another book by Kurt Wall (along with a few other people). It covers the same topics as Linux Programming by Example, and a good deal more. In fact, because one of Linux Programming Unleashed's authors worked on both books (Kurt Wall), several of the sections in Linux Programming by Example were word for word copies of the same section in Linux Programming Unleashed.

    This isn't meant to bash the author. Linux Programming by Example is a very good book for people who know how to program in C, but have never done it for Linux before. I consider it to be the "lite" version of Linux Programming Unleashed. Linux Programming Unleashed contains almost the same information as Linux Programming by Example, in the same accessible, easy-to-understand presentation, plus a good deal more (like how to write man pages for your programs).

    If it comes down to whether to buy one or the other, if you can afford Linux Programming Unleashed ($50, whereas Linux Programming by Example is around $30) buy that. If not, go ahead and get Linux Programming by Example.

Slashdot Top Deals

He has not acquired a fortune; the fortune has acquired him. -- Bion

Close