Slashdot Mirror

Here is a good link that, although older, explains how bogus this is pretty well.

Here
and here

Here is a good link that, although older, explains how bogus this is pretty well.

Here
and here

You can view certain books by O'Reilly on their Open Book page, located here at http://oreilly.com/openbook/

Logik

Spaff is pretty well known in the Internet, but I am affraid I can't think of a major contribution to computer security from him since tripwire.

Spaff is pretty well known in the Internet, but I am affraid I can't think of a major contribution to computer security from him since tripwire.

Spaff is pretty well known in the Internet, but I am affraid I can't think of a major contribution to computer security from him since tripwire.

Here's probally one of the best lists of books available.

O'Reilly also allows authors to choose whether to make the book freely available. It's part of the contract negotiation process. The most recent example that comes to mind is Free as in Freedom, which is still in print.

Its not too expensive compared to how much technical books cost in some countries outside the US I have visited. The Safari service is about 10 dollars a month (US) for 5 books and 15 dollars for 10, and so on.

Practical PostgreSQL
Using Samba
Personally I thought both were very well written, the samba book has helped me greatly.

As a pretty new user to the linux kernel, i think the above book gives a nice overview. It includes char,block,network drivers and some probing stuff: http://www.oreilly.com/catalog/linuxdrive2/

I also loved the Perl CD Bookshelf, especially the Learning Perl volume. I found myself frequently referring to it.

I understand that TCP/IP Illustrated Volume 1 and Volume 2 are valuable. I own both but haven't yet read either. (sorry for the amazon linking. I don't have anything else handy)

I also loved the Perl CD Bookshelf, especially the Learning Perl volume. I found myself frequently referring to it.

I understand that TCP/IP Illustrated Volume 1 and Volume 2 are valuable. I own both but haven't yet read either. (sorry for the amazon linking. I don't have anything else handy)

I also loved the Perl CD Bookshelf, especially the Learning Perl volume. I found myself frequently referring to it.

I understand that TCP/IP Illustrated Volume 1 and Volume 2 are valuable. I own both but haven't yet read either. (sorry for the amazon linking. I don't have anything else handy)

Personally I'd suggest you go to O'Reilly and Associates' Safari and preview any book that looks interesting. Previews give you a HUGE amount of information at 0 cost. If you subscribe at 5 points it's only $119.88 a year and you can swap out books you're finished with for new ones on a monthly basis but MAKE SURE you preview a bunch of books before you put them on your bookshelf as you will inevitably find a much cooler book two days later. I'm seriously considering sacrificing the money I set aside for a new hard drive to buy a year's subscription. O'Reilly books aren't the only ones you will find there, either which is nice.

O'Reilly's "High Performance Computing" (the harrier book, although I've heard it called the raptor book as well) is an excellent volume on performance. It covers everything from hardware architecture to high level language structures. Excellent starting place for those writing performance critical code; although it expects that you already know how to write properly functional code first. (you might be surprised how many people neglect to ensure code still functions properly after the "improve performance".) There are sections on specific langauges (HPF for example) and environments (MPI, PVM) as well. Also good reading for anyone that has to benchmark code (it explains how to do it right) and those who have to understand benchmarks. Includes an explanation of a number of industry standard benchmarks. I wish marketing people that try to sell something based on benchmarks would read this.

And I don't think you'll find many authors who want to get rid of libraries. Publishing houses, now that's possible. But don't blame the ones who do the grunt work. (Smacks of the artist vs MPAA/RIAA situation, eh?)

And as to the 'used books are killing our business' angle, baloney. If someone reads one of my books and doesn't think it's worth keeping, by all means they should get rid of it. I never sell off old books, but I do give them away to friends a lot. Or my newer trend, when I have a book I consider crap then I'll write one that I'd want to read.

It's much more rewarding.

Even if it doesn't pay squat.

I saw this article, looked over my shoulder at the bookcase that has way too many Oreilly books and thought "Understanding the Linux Kernel. has probably saved me more time than any other book."

Eventually you are going to run into a bug/performance problem that is not in your code, not in the language, and not in the runtime, and you'll need to step into that big scary blob called the kernel. Then you'll read this book and realize that the kernel no different than any other piece of code, find the problem fix it, and go on with your life.

Of course if you're programming on top of a closed source OS then you're out of luck.

-the K&R book for C
-Design Patters by Erich Gamma et al for OO programming in any language
-any of the O'reilly books which are consistently excellent, and can be accessed for a fee at Safari
-the Camel Book for Perl (obviously)
-php & python ... I use the web for these, python.org, php.net, phpbuilder.com, vaults of parnassus, etc.

You want the best books for free?
alt.binaries.e-book.technical

The other computer books will be far too big to hide in your pockets... So you will probably have to carry a bag with you. When the security guards try to come after you, just shoot them. You're a criminal after all, so what do you care?

Come to think of it, why pay for anything when you can steal it? Why even work for a living when you can rob people instead? Yep, the parent poster has it all figured out!

I know PL/SQL doesn't have the highest regard, but Steven Feurstein's Oracle PL/SQL Programming was one of the best introductions/reference books I've ever read.
Got you on your feet quick and took you right to guru-ville.

The O'Reilly books are great for introducing new topics and for delving deeper into topics that you are already familiar with. Well worth a look.

I think part of that problem is the rate at which such information changes in this field, compared with the time it takes for a publishing cycle.

Meanwhile, as your links show, you can always check the book's web page on the O'Reilly site for errata. Just print that page out and keep it with the book (or even go through and make the corrections by hand). Beats paying for a new edition.

The only O'Reilly book I own that I can say sucks is the old MySQL one. I own dozens of O'Reilly titles and that is the only one I ever regretted purchasing.

The only publishers I trust are O'Reilly, Addison Wesley and the in-house publishers (Oracle Press, Sun Press, Microsoft Press). Anything else I typically wait for someone to really reccomend the book before I'll buy it.

O'Reilly does have a book upgrade program where they give you 30% off if you send them the title page. (More Info Here). Although, Bookpool has it on sale for 39% off.

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

Another disturbing trend is that new books don't contain information that is as up-to-date as before. An obvious example is CSS Pocket Reference. Even though it was published last year, it doesn't cover any of CSS2. For some odd reason, the book was published right before IE6 was released, and so doesn't have any information about what will become the most popular browser in the world this year. And don't expect a corrected printing any time soon!

It used to be the case that you could count an O'Reilly books having the most accurate and up-to-date information. Nowadays, that isn't true any more.

Fine.
But next time do your own google search before denigrating others.
If someone uses a term incorrectly, they used the term incorrectly. The media has been screwing up computer related stories for a long time, that doesn't mean they're correct.
Here is proof of my previous statement.
BTW, the MIT hack museum is pretty cool.

There's an upcoming book, if you don't mind waiting a few months : "Creating Applications with Mozilla"

becuase *BSD was being sued by AT&T

See The Lawsuit at the O'Reilly publication of Open Sources: Voices from the Open Source Revolution.

I too am an administrator of many Windows boxen and am very security conscious . The absolute best information I have found about Windows Security, was from this Oreilly book: Securing Windows NT/2000 Servers for the Internet
A Checklist for System Administrators I know its primarilly about creating Windows Bastion hosts, but there is an aweful lot of general Windows security and remote administration information as well. Every Windows sysadmin needs to give it a read!

Perl is real programming language, and as for the readability aspect: Perl doesn't hold your hand. It's perfectly possible to write clear code in Perl. If I was to show you one of my scripts I'm sure anyone with basic programming knowledge would be able to understand it.

Perl is real programming language, and as for the readability aspect: Perl doesn't hold your hand. It's perfectly possible to write clear code in Perl. If I was to show you one of my scripts I'm sure anyone with basic programming knowledge would be able to understand it.

I've ecountered many regexpr's for email addresses, all of them work on your bog standard address, none of them work when deployed - there's always some guy with a % in their email address or some other oddity the author of the regexpr forgot or didn't know about (and lets not even think about trying to make an RFC compliant email address regexpr, it would have to handle "blarg@wibble"@slashdot.org)

Writing an RFC compliant email address regex is possible but not too feasible. In Jeffrey Friedl's book, there's such a beast. At over 2000 bytes (IIRC), it may very well choke some of the less robust regex engines.

However, validating an email address can never be done with a regex. You can't tell programmatically if the supplied address is deliverable, and that's what matters in most cases.

In my CGI scripts, I never make assumptions about how valid an arbitrary email address is. Instead, the script sends mail to it and expects a reply. Only then can I tell the address is indeed valid.

You can't even assume that a valid address has the '@' character present -- it may be a local address (not that usual though), or a bangpath (even more rarely), but these illustrate the fragility of regex validators.

These owls are much, much cooler than this one.

These owls are much, much cooler than this one.

FYI 'the framework part' of Dotnet is not the CLI - frameworks are component libraries not interpreters/compilers.

See .NET Framework Essentials, Thai & Lam, pub. O'Reilly.

This sort of nonsense just plays into the 'Dotnet is a standard' myth.

What joke? This page is official, isn't it?

I think it's because of lack of standard of both Perl and Python.

If Perl is dying - where to go? Ruby? Erlnag? Lisp? I stick with Lisp for while. At least it's very clean, very clear and has a lot of libraries - that's exactly what I need from a language for web management.

BEEP's an impressive protocol framework with even more impressive implementations.

I'm using it in a burgeoning open source project because of it's ability to multiplex bidirectional communication channels in a transparent fashion. Other features such as dynamic client/server roles, authentication, and channel encryption are just icing on the cake. The less I have to muck around with protocol state details the better!

When I first started looking at BEEP I was impressed by the spec but I was suspicious as to the quality and breadth of implementations. After looking through the high level Java abstractions and more specifically BeepCore-Java I was able to throw together a workable protocol that's proven to be extensible and quite robust in just a few days.

The BEEP community is alive and well!

• BEEPCore-Java - Java implementation with a BSD-like license
• BEEPCore-C - C/C++ implementation with a BSD-like license
• PermaBEEP - C implementation with a SleepCat-like license
• BEEP4j with an Apache-like license
• PyBeep for Python with an unknown, but OSI approved, license
• RoadRunner - C and Python implementation with an OSI approved license.
• Beepcore-Ruby - Ruby implementation (though just beginning) with a BSD-like license

There's an excellent IRC channel at OpenProjects with the kitschy name #beepnik.

There's the obligatory O'Reilly book, BEEP: The Definitive Guide.

But the best source for information is the Beepcore.org site which has, among other things, an excellent whitepaper on the justification and design of the BEEP protocol.

For the active geek with some property, nothing beats a small herd of llamas.

No, really.

The ``physical source lines of code'' (physical SLOC) measure was used as the primary measure of SLOC in this paper. Less formally, a physical SLOC in this paper is a line with something other than comments and whitespace (tabs and spaces). More specifically, physical SLOC is defined as follows: ``a physical source line of code is a line ending in a newline or end-of-file marker, and which contains at least one non-whitespace non-comment character.'' Comment delimiters (characters other than newlines starting and ending a comment) were considered comment characters. Data lines only including whitespace (e.g., lines with only tabs and spaces in multiline strings) were not included.

Note that the ``logical'' SLOC is not the primary measure used here; one example of a logical SLOC measure would be the ``count of all terminating semicolons in a C file.'' The ``physical'' SLOC was chosen instead of the ``logical'' SLOC because there were so many different languages that needed to be measured. I had trouble getting freely-available tools to work on this scale, and the non-free tools were too expensive for my budget (nor is it certain that they would have fared any better). Since I had to develop my own tools, I chose a measure that is much easier to implement. Park [1992] actually recommends the use of the physical SLOC measure (as a minimum), for this and other reasons. There are disadvantages to the ``physical'' SLOC measure. In particular, physical SLOC measures are sensitive to how the code is formatted. However, logical SLOC measures have problems too. First, as noted, implementing tools to measure logical SLOC is more difficult, requiring more sophisticated analysis of the code. Also, there are many different possible logical SLOC measures, requiring even more careful definition. Finally, a logical SLOC measure must be redefined for every language being measured, making inter-language comparisons more difficult. For more information on measuring software size, including the issues and decisions that must be made, see Kalb [1990], Kalb [1996], and Park [1992].

Note that this required that every file be categorized by language type (so that the correct syntax for comments, strings, and so on could be applied). Also, automatically generated files had to be detected and ignored. Thankfully, my tool ``sloccount'' does this automatically. 2.3 Estimation Models

This decision to use physical SLOC also implied that for an effort estimator I needed to use the original COCOMO cost and effort estimation model (see Boehm [1981]), rather than the newer ``COCOMO II'' model. This is simply because COCOMO II requires logical SLOC as an input instead of physical SLOC.

Basic COCOMO is designed to estimate the time from product design (after plans and requirements have been developed) through detailed design, code, unit test, and integration testing. Note that plans and requirement development are not included. COCOMO is designed to include management overhead and the creation of documentation (e.g., user manuals) as well as the code itself. Again, see Boehm [1981] for a more detailed description of the model's assumptions. Of particular note, basic COCOMO does not include the time to develop translations to other human languages (of documentation, data, and program messages) nor fonts.

There is reason to believe that these models, while imperfect, are still valid for estimating effort in open source / free software projects. Although many open source programs don't need management of human resources, they still require technical management, infrastructure maintenance, and so on. Design documentation is captured less formally in open source projects, but it's often captured by necessity because open source projects tend to have many developers separated geographically. Clearly, the systems must still be programmed. Testing is still done, although as with many of today's proprietary programs, a good deal of testing is done through alpha and beta releases. In addition, quality is enhanced in many open source projects through peer review of submitted code. The estimates may be lower than the actual values because they don't include estimates of human language translations and fonts.

Each software source code package, once uncompressed, produced zero or more ``build directories'' of source code. Some packages do not actually contain source code (e.g., they only contain configuration information), and some packages are collections of multiple separate pieces (each in different build directories), but in most cases each package uncompresses into a single build directory containing the source code for that package. Each build directory had its effort estimation computed separately; the efforts of each were then totalled. This approach assumes that each build directory was developed essentially separately from the others, which in nearly all cases is quite accurate. This approach slightly underestimates the actual effort in the rare cases where the development of the code in separate build directories are actually highly interrelated; this effect is not expected to invalidate the overall results.

For programmer salary averages, I used a salary survey from the September 4, 2000 issue of ComputerWorld; their survey claimed that this annual programmer salary averaged $56,286 in the United States. I was unable to find a publicly-backed average value for overhead, also called the ``wrap rate.'' This value is necessary to estimate the costs of office space, equipment, overhead staff, and so on. I talked to two cost analysts, who suggested that 2.4 would be a reasonable overhead (wrap) rate. Some Defense Systems Management College (DSMC) training material gives examples of 2.3 (125.95%+100%) not including general and administrative (G&A) overhead, and 2.81 when including G&A (125% engineering overhead, plus 25% on top of that amount for G&A) [DSMC]. This at least suggests that 2.4 is a plausible estimate. Clearly, these values vary widely by company and region; the information provided in this paper is enough to use different numbers if desired. These are the same values as used in my last report. 2.4 Determining Software Licenses A software license determines how that software can be used and reused, and open source software licensing has been a subject of great debate. The Software Release Practice HOWTO [Raymond 2001] discusses briefly why license choices are so important to open source / free software projects:

The license you choose defines the social contract you wish to set up among your co-developers and users ...

Who counts as an author can be very complicated, especially for software that has been worked on by many hands. This is why licenses are important. By setting out the terms under which material can be used, they grant rights to the users that protect them from arbitrary actions by the copyright holders.

In proprietary software, the license terms are designed to protect the copyright. They're a way of granting a few rights to users while reserving as much legal territory is possible for the owner (the copyright holder). The copyright holder is very important, and the license logic so restrictive that the exact technicalities of the license terms are usually unimportant.

In open-source software, the situation is usually the exact opposite; the copyright exists to protect the license. The only rights the copyright holder always keeps are to enforce the license. Otherwise, only a few rights are reserved and most choices pass to the user. In particular, the copyright holder cannot change the terms on a copy you already have. Therefore, in open-source software the copyright holder is almost irrelevant -- but the license terms are very important.

Well-known open source licenses include the GNU General Public License (GPL), the GNU Library/Lesser General Public License (LGPL), the MIT (X) license, the BSD license, and the Artistic license. The GPL and LGPL are termed ``copylefting'' licenses, that is, the license is designed to prevent the code from becoming proprietary. See Perens [1999] for more information comparing these licenses. Obvious questions include ``what license(s) are developers choosing when they release their software'' and ``how much code has been released under the various licenses?''

An approximation of the amount of software using various licenses can be found for this particular distribution. Red Hat Linux uses the Red Hat Package Manager (RPM), and RPM supports capturing license data for each package (these are the ``Copyright'' and ``License'' fields in the specification file). I used this information to determine how much code was covered by each license. Since this field is simply a string of text, there were some variances in the data that I had to clean up, for example, some entries said ``GNU'' while most said ``GPL''. In some cases Red Hat did not include licensing information with a package. In that case, I wrote a program to attempt to determine the license by looking for certain conventional filenames and contents.

This is an imperfect approach. Some packages contain different pieces of code with difference licenses applying to different pieces. Some packages are ``dual licensed'', that is, they are released under more than one license. Sometimes these other licenses are noted, while at other times they aren't. There are actually two BSD licenses (the ``old'' and ``new'' licenses), but the specification files don't distinguish between them. Also, if the license wasn't one of a small set of common licenses, Red Hat tended to assigned nondescriptive phrases such as ``distributable''. My automated techniques were limited too, in particular, while some licenses (e.g., the GPL and LGPL) are easy to recognize automatically, BSD-like and MIT-like licenses vary the license text and so are more difficult to recognize automatically (and some changes to the license would render them non-open source, non-free software). Thus, when Red Hat did not identify a package's license, a program dual licensed under both the BSD and GPL license might only be labelled as having the GPL using these techniques. Nevertheless, this approach is sufficient to give some insight into the amount of software using various licenses. Future research could examine each license in turn and categorize them; such research might require several lawyers to determine when two licenses in certain circumstances are ``equal.''

One program worth mentioning in this context is Python, which has had several different licenses. Version 1.6 and later (through 2.1) had more complex licenses that the Free Software Foundation (FSF) believes were incompatible with the GPL. Recently this was resolved by another change to the Python license to make Python fully compatible with the GPL. Red Hat Linux 7.1 includes an older version of Python (1.5.2), presumably because of these licensing issues. It can't be because Red Hat is unaware of later versions of Python; Red Hat uses Python in its installation program (which it developed and maintains). Hopefully, the recent resolution of license incompatibilities with the GPL license will enable Red Hat to include the latest versions of Python in the future. In any case, there are several different Python-specific licenses, all of which can legitimately be called the ``Python'' license. Red Hat has labelled Python itself as having a ``Distributable'' license, and package Distutils-1.0.1 is labelled with the ``Python'' license; these labels are kept in this paper.

I'd recommend this book: High Performance Computing. It covers this trick and many others -- if your compiler doesn't do them automatically, then you can hand code it.

O'Reilly has a book on PostgreSQL called Pratical PostgreSQL, which was published at the beginning of this year. A bunch of other PostgreSQL books can be found here; Prime Time Freeware has published printed versions of the online documentation (which I did a brief review on the "Use and Administration" portion here.

O'Reilly has a book on PostgreSQL called Pratical PostgreSQL, which was published at the beginning of this year. A bunch of other PostgreSQL books can be found ; Prime Time Freeware has published printed versions of the online documentation (which I did a brief review on the "Use and Administration" portion here.

There's currently a discussion on this very topic on MacSlash, but a few /. people may be interested in some Apple ramblings too:

Strategy: Buy Low, Sell High.
How low can the stock values of companies go? Since last fall, many in the tech sector have certainly been trying to find out. This is a great time to buy companies or technologies and lately Apple has been wisely acting when opportunities arise. Even if Emagic GmbH, Spruce Technologies, Nothing Real, and Zayante in the last year had all been privately held, they would have still been sold at a favourable price compared to buying them before the .bomb bubble burst.

Strategy: Niche Market Growth.
It's clear that Apple wants to defend the Macintosh strength as a music & audio creation tool in the long term. Since pro audio software has been lagging on the march to MacOS X, Apple is at least applying heat to developers if not exactly lighting a fire under them. Logic and associated software & hardware on the Mac will mean that Digidesign, Twelve Tone Systems(Cakewalk), MOTU and Steinberg will have to take the market segment more seriously (although MOTU & Digidesign have historically been great friends of the Mac already). The way it's looking is that a larger majority of pro audio will be done on the Mac. Can Steinberg, Twelve Tone et al. risk being caught with their pants around their ankles if this happens?

Strategy: Technology Cross-Pollination.
Now that Apple has a substantial video-production, streaming, compression, audio & other technologies, they may consider adding many good features from one to another and developing truly feature-rich packages. It dosen't take a dreamer to see the possibilities, from unheard-of professional solutions to trickle-down pro capabilities in new iSoftware (eg. look how technologies purchased from Marcromedia were crafted into Final Cut Pro & iMovie). This is one area that users, down the road, can really cash out with if Apple encourages the flow of technologies between it's new divisions.

Strategy: Sorry, Mac-Only.
One thing that is a bit sad about this, ironically enough, is the immediate cancellation of the Windows versions of some software (notably Shake & Logic) with this strategy. While perhaps more upfront than an MS-style purchase and feature-deprivation in non-Windows versions, Apple still isn't making any friends (and perhaps losing potentially loyal customers & money) by doing this. Still, one cannot say that it's not what happened to Mac users through the late 1990s (even now - look at Bungie) but it would be better karma to be more merciful once the shoe is on the other foot. Apple would be smart to mitigate the anger of Windows users by offering discounts on upgrades to the next Mac version.

Next Strategy: More Vertical Markets.
The Macintosh still has a real chance at gaining significant market share if it can be a strong alternative in enough vertical market segments. Apple is rightly building on it's strenghts, but should diversify enough so that the Macintosh is not pegged as only good for those niches (remember what happened to the Amiga? Games machine!)

A Holy Grail almost as worthy as dominating the business market for Apple is the scientific & engineering markets, often with high software margins all around. A purchase or substantial investment in Autodesk à la the MS $150M in Apple would make Apple a huge player in the professional engineering, architecture, and manufacturing industries overnight. Considering Autodesk is not the most expensive stock right now, with a market cap of approximately USD$1.4B, Apple could conceivably purchase the entire operations in cash and still have about $2B in the bank. Autodesk's Design Segment develops AutoCAD, Autodesk Inventor, Mechanical Desktop, Autodesk Architectural Desktop, Architectural Studio, Autodesk Map, Lightscape, and Autodesk Land Desktop, to name a few (most industry-standard in their fields) and the Discreet Segment develops 3D Studio MAX, Animator Studio, flame, inferno, smoke, combustion, cinestream, plasma, cleaner, MPEG supercharger, Topper, and many others.

With a stable of industry-dominating software products as great as this, such a purchase (or even investment ensuring MacOS X compatibility) would send massive shockwaves across the engineering & architectural markets, and ripples in the scientific & pro graphics markets who are by now used to this. No immediate cancellation of the Windows version would be posible here, rather a years-long strategy to ensure first Mac versions and then Mac feature-parity. A purchase like this too rich for Apple's blood? Try something smaller like privatley-held ESRI (makers of ArcINFO, ArcView, ArcGIS & associated imaging systems), or continue to add strength in the crucial areas of coming scientific importance such as biotech and bioinformatics, in which Macs already have a growing following as you can see.

BTW - O'Reilly has more books on Java programming than .NET programming, and with quite a few Python books.

And let's not get started on how many Perl books they have published. ;-)