Slashdot Mirror

Start a zoo. BIND, Sendmail, perl, python, if it's got a black and white critter on it, buy it and read it. www.fatbrain.com (now a Barnes and Noble site), has a good selection to get you started. Pull out the credit card, drink a six-pack, and see if your card really does have a limit.

Because amazon is evil. They abuse patents and stuff. Didn't you know that?

How 'bout fatbrain?

Actually I was quite surprised when I got my Differential Equations Textbook came with the entire book as a PDF on the cdrom. Actually there are two editions of the book and it was the one with _more_ chapters on the cdrom. The greatest thing ever.

http://www1.fatbrain.com/asp/bookinfo/bookinfo.as p?theisbn=0932633439&vm=

http://www.xprogramming.com/xpmag/c3space.htm

Seems like a Rudy Rucker book where beings are created from gene-tweaked molds and algae and the flesh is sold at fast food restaurants.

Freeware

Think about it -- We know that MS had full rights to the OS/2 code. AFAWK, they didn't have any rights to VMS. Which codebase would they have used?

This can be illustrated by the examples of photography, film, television, etc, for all of history. It kind of disappoints me that people are using the web to imitate television, books, newspapers, etc, instead of doing more with the medium. Maybe we're still just getting there.

A good, if dated, book on the subject of creativity and possibilities on the net (especially concerning non-linear narrative) is Hamlet on the Holodeck by Janey Murray.

* (referring to artistic works, but I think it applies to other types as well. programming?)

Chris Locke & Ilk are rank amateurs in the use of Bombast Transcripts to reverse the entropy gradient of the Universe. Somebuddy ought to wake them up to the oh, never Mind, it's hopeless.

The Bombast Transcripts: Rants and Screeds of Rageboy pales before Technological Singularity.

I see it as a way to indirectly fund Slash development. New features for subscribers --> new features for those who who use their free software. (Although I guess the 2nd edition of Running Weblogs with Slash will be required sooner than expected.)

I'll see how long the 1000 pageviews last, and go from there. Between NPR, Wall Street Journal Online, and Slashdot, I'm paying for content in several places but I'm getting my money's worth.

I like Slashdot because I don't have to waste my time reading crap (unless I'm moderating). I like Amazon because there are usually enough decent reviews ranked by usefulness to make my shopping experience easier. But I don't think I'd pay Amazon for the privilege of reading user reviews. It's still apples and oranges, though, because I can still get the content free but with annoying ads.

It would be nice to reward those who contribute to the site's success ... the only problem is that karma alone is a truly bad way to decide who's contributing enough to be worth rewarding.

And if you want to hire a web designer, ask them what they think of Jakob Nielsen, and don't touch them if they make a face. "Designers" hate him because he wants them to put their toys away and do their job.

He's got a new book out that's pretty good: Homepage Usability: 50 Websites Deconstructed. As is his previous book: Designing Web Usability: The Practice of Simplicity

Jakob Nielsen's schtick is that his opinions are actually based on useability studies. Everyone else is just guessing, Jakob Nielsen knows.

And if you want to hire a web designer, ask them what they think of Jakob Nielsen, and don't touch them if they make a face. "Designers" hate him because he wants them to put their toys away and do their job.

He's got a new book out that's pretty good: Homepage Usability: 50 Websites Deconstructed. As is his previous book: Designing Web Usability: The Practice of Simplicity

Jakob Nielsen's schtick is that his opinions are actually based on useability studies. Everyone else is just guessing, Jakob Nielsen knows.

You can purchase Running Weblogs with Slash from Fatbrain.

But not from that link =3 But Here's a link that actually works. Additionally, if you want to buy it without an affiliate, here's a link over to Amazon.

You can purchase Running Weblogs with Slash from Fatbrain.

But not from that link =3 But Here's a link that actually works. Additionally, if you want to buy it without an affiliate, here's a link over to Amazon.

I personally found that this survey was more interesting than Dr. Turkle. Turkle talks a lot about the ideas of interface and windows. I got the impression from reading her that she was as messed up as some of the people she was interviewing. I found her to not be very scientific and seemed to mostly write about the most extreme cases. She uses cases like: "'RL is just one more window,' he repeats, 'and it's not usually my best one.'" I found that she seemed to write about people with some serious issues.

In addition, she did not seem to have a very good understanding of technology, for example she talked about the "electrodes" in computers. What are the electrodes in computers?

With not exactly the same areas covered, William J. Mitchell's City of Bits: Space, Place, and the Infobahn. I thought Mitchell had a better grasp of the technologies involved and their overall influence. I am probably pretty biased though, Mitchell's writing was more geek and less psychologist.

She seemed to be studying "MUDs" more than RPG gamers, but maybe that is what you meant. She called them MUDs, but she seemed to be spending more time on MUCKs from what I gathered.

I think it's a gift option that's always overlooked, primarily because the buyer isn't sure what the recipient would want. But I've always believed that books can be a timeless gift, treasured for years. Whether it be fiction, non-fiction, reference, or a little of each, I know that I always appreciate books. Heck, go to FatBrain to find a huge collection of technical books, or maybe to ThinkGeek for options like fiction, non-fiction, programming reference, and so on. And if you're not sure, DO get a gift certificate for your loved one at a bookstore (or even for the aforementioned websites!). Then they can pick out the books themselves, and they can't hardly go wrong.

Good luck.

Fatbrain publishes Apple Mac OS X documentation, a couple of which are relevant to administration:

There is also a document on understanding Netinfo and info on administrator training.

Fatbrain publishes Apple Mac OS X documentation, a couple of which are relevant to administration:

There is also a document on understanding Netinfo and info on administrator training.

Well, yeah, but the problem is that an unfair trade practice is rather broadly defined. For example, patents are considered fair to have by a small business to protect its R but they become unfair once the owner company gets too big. So when the DoJ goes to trial over monopolies, licensing patents at a much lower price to competitors is often part of the deal when settling out of court. Another example is bundling, eg selling someone a piece of hardware, and including the software and service/maintenance as part of the deal. Again, that's a good business practice to win customers, but when you get to big the argument is reversed, and suddenly you find yourself "unfairly blocking people who want to compete on just the software".

I don't have a monopoly myself, I learned this by reading these :) Father, Son and Co (IBM's Watson biography), Barbarians led by Bill Gates (Basically Marlin Eller's story but also describing Bill's surprise at the case).

Well, yeah, but the problem is that an unfair trade practice is rather broadly defined. For example, patents are considered fair to have by a small business to protect its R but they become unfair once the owner company gets too big. So when the DoJ goes to trial over monopolies, licensing patents at a much lower price to competitors is often part of the deal when settling out of court. Another example is bundling, eg selling someone a piece of hardware, and including the software and service/maintenance as part of the deal. Again, that's a good business practice to win customers, but when you get to big the argument is reversed, and suddenly you find yourself "unfairly blocking people who want to compete on just the software".

I don't have a monopoly myself, I learned this by reading these :) Father, Son and Co (IBM's Watson biography), Barbarians led by Bill Gates (Basically Marlin Eller's story but also describing Bill's surprise at the case).

You can purchase True Names at Fatbrain.

It looks like VA * has struck a deal with Fatbrain to advertise here on Slashdot. Michael's review seems to be the first editor review that contains this kind of fatbrain link. Could it be that VA * has found a way to stave off bankruptcy for another quarter?

Keep those reviews coming, guys! I want my Slashdot!

The P3 adds SSE (yeah, like that is used a lot) and brings the cache on-die with the Copper[less]mine processors.

Actually, this brings up an important issue-- compiler technology, and the run-time libraries (RTL's) they use (in the case of C/C++, the standard libraries, in the case of Pascal/Delphi, the RTL and possibly parts of Borland's VCL/CLX). The problem, it seems to me, is that compiler authors don't seem to take advantage of architecture specific improvements like they used to (and as they should). Sure, some libraries/RTL's take advantage of it (and the compiler may have switches to emit optimized code), but if the standard libraries/RTL's are re-compiled (or even re-written) to take advantage of it, then it's all for nothing.

It seems to me that Intel has the right idea (the FPU is really useless if you know HOW to use SSE and SSE2 properly), and that if anything, it's poor software authors and poor compiler writers that are to blame for the lackluster performance of code on Intel's CPUs. It's saddening to me to see the optimization skills software engineers *used* to have back in the day diminishing year by year as the ability to right crappy code is justified by ever-faster CPU's. (Why spend the weeks or months needed to engineer everything to run properly now, when Intel/AMD will have a 'fix' for our sloppy code out in a few months?)

I wish authors such as Michael Abrash still released optimization guides for assembly language (or even just updated versions for C/C++ and assembler).. his 'Zen of Code Optimization' (ISBN: 1-883577-03-9 *or* FatBrain.com's description (out of print)) was probably the best investment *I* ever made.

Nope.

It is based on PKD's "We Can Remember it for You Wholesale" which can be found in Citadel Twilight's "The Collected Stories of Philip K. Dick, Volume 2".

Refactoring is not re-writing. Refactoring is a methodical approach to moving, redesigning, and making the code cleaner. It's not throwing away and starting from scratch. The two words are wholly semantically different.

In his book, Refactoring, Martin Fowler talks about how code "smells". He identifies a whole slew of reasons why code can "smell" bad, such as having a method that's too long, having a method on the wrong object, incorrect use of polymorphism, etc. He then outlines "Refactoring Patterns" which can be applied to certain "smells" to make the code more managable.

The last project I managed was a 3 month re-write of over 75,000 lines of code for an auction component that had gotten way out of control. The original component integrated with a very very poorly written (yet still very expensive) auction engine, and our task was to take it out.

Because there was no time allotted to proper requirements gathering, the powers that be decided that we could use the existing system as a requirements base, and just make the new system "act" like the old one.

So I was thrown two things: A staff that was inexperienced in design, and a lack of requirements. We were re-writing from scratch -- throwing all of the code away and starting again. I'm one of the only ones on my team that actually knows what refactoring means, let alone how to apply it.

So we built the new system based on a solid design. We even did the design in UML. But that only goes so far. Given a properly designed system, there is still another lower step -- how to actually implement the code. Invariably, the design doesn't take into account helper methods that are necessary, other objects, etc. Because we were on a tight schedule, I left it up to each developer to design these new tidbits.

If they had known what they were doing, everything would have been fine, but there are several places where the code is absolutely abysmal. It's not that it will perform poorly or is totally unmanagable, but in some places it's close.

Granted, the business rules for the system are some of the most complex I've ever seen, but if the developers had known more about refactoring, they might have made better choices.

There's a whole notion of Quality here that should be discussed as well. Most good has a good enough quality, and though it looks ugly, I'd throw it away. There's an interesting interview by Joel (a former microsoft programmer) which tackles these problems of Quality head on. I also reccommend reading Zen and the Art of Motorcycle Maintenence: An Inqiry into Values for a pretty good discussion of the whole notion of quality.

I'd say just keep the codebase unless you are totally switching languages (or in our case taking out a 3rd party integration). Otherwise if you re-write you'll wish you hadn't. The new codebase will end up being in the same state as the old codebase, it'll just take a little bit more time to get there.

I'd also reccommend just doing a performance test of the site, and find out which modules really need to be re-written. The 80/20 rule will invariably apply -- 80% of the execution time will be spent in 20% of the code -- so at a minimum just re-write the 20% of the code that's executed on the most frequent paths. Leave the rest alone. Re-writing it will just be a waste of time, and you have to fix all the old bugs that were re-introduced during the re-write.

Refactoring is not re-writing. Refactoring is a methodical approach to moving, redesigning, and making the code cleaner. It's not throwing away and starting from scratch. The two words are wholly semantically different.

In his book, Refactoring, Martin Fowler talks about how code "smells". He identifies a whole slew of reasons why code can "smell" bad, such as having a method that's too long, having a method on the wrong object, incorrect use of polymorphism, etc. He then outlines "Refactoring Patterns" which can be applied to certain "smells" to make the code more managable.

The last project I managed was a 3 month re-write of over 75,000 lines of code for an auction component that had gotten way out of control. The original component integrated with a very very poorly written (yet still very expensive) auction engine, and our task was to take it out.

Because there was no time allotted to proper requirements gathering, the powers that be decided that we could use the existing system as a requirements base, and just make the new system "act" like the old one.

So I was thrown two things: A staff that was inexperienced in design, and a lack of requirements. We were re-writing from scratch -- throwing all of the code away and starting again. I'm one of the only ones on my team that actually knows what refactoring means, let alone how to apply it.

So we built the new system based on a solid design. We even did the design in UML. But that only goes so far. Given a properly designed system, there is still another lower step -- how to actually implement the code. Invariably, the design doesn't take into account helper methods that are necessary, other objects, etc. Because we were on a tight schedule, I left it up to each developer to design these new tidbits.

If they had known what they were doing, everything would have been fine, but there are several places where the code is absolutely abysmal. It's not that it will perform poorly or is totally unmanagable, but in some places it's close.

Granted, the business rules for the system are some of the most complex I've ever seen, but if the developers had known more about refactoring, they might have made better choices.

There's a whole notion of Quality here that should be discussed as well. Most good has a good enough quality, and though it looks ugly, I'd throw it away. There's an interesting interview by Joel (a former microsoft programmer) which tackles these problems of Quality head on. I also reccommend reading Zen and the Art of Motorcycle Maintenence: An Inqiry into Values for a pretty good discussion of the whole notion of quality.

I'd say just keep the codebase unless you are totally switching languages (or in our case taking out a 3rd party integration). Otherwise if you re-write you'll wish you hadn't. The new codebase will end up being in the same state as the old codebase, it'll just take a little bit more time to get there.

I'd also reccommend just doing a performance test of the site, and find out which modules really need to be re-written. The 80/20 rule will invariably apply -- 80% of the execution time will be spent in 20% of the code -- so at a minimum just re-write the 20% of the code that's executed on the most frequent paths. Leave the rest alone. Re-writing it will just be a waste of time, and you have to fix all the old bugs that were re-introduced during the re-write.

Maby the speeling is rong becuase Eenglish isn't the posters frist langauge...

But seriously, if the point of language is to convey a thought, and he conveyed his thought, his language is fine. Perhaps it conveyed to you a little more than his intended thought...like that he's an ass too lazy to check his own spelling. I give the benefit of doubt...to me it conveyed that he didn't know the dictionary spelling of a few words and is perhaps a bit redundant (most best), but then I've known some friggin' smart people who couldn't speel they're weigh oot uv a payper baag.

BTW, anyone intent on helping others understand language should read The Language Instinct by Steven Pinker. There's a lovely chapter on people who insist on correcting the grammar/spelling of others.

At any rate, while I agree that presentation says a lot about you, I hardly think /. is a place to be miffed about another's grammatical and spelling errors.

I hate being a grammar/spelling Nazi too...so I stopped.

Well...it might not be his real name, but he has published books under that name (This one and That one) that a lot of us have read...

So, if he used his real name here, we wouldn't care what he thinks about BeOS (as it is, I'm not sure I do anyways, but some here might)

Well...it might not be his real name, but he has published books under that name (This one and That one) that a lot of us have read...

So, if he used his real name here, we wouldn't care what he thinks about BeOS (as it is, I'm not sure I do anyways, but some here might)

Most of the problems with the B-1 were political in nature or were the result of politics.

Agreed. The politics of the B-1 were thick enough to spawn a book. The B-1 was promised as a plane that could do everything, and that could provide pork-barrel spending for everyone - it has taken twenty years to get past that mess and actually use the plane.

Politics factored heavily in the B-52 work as well, but as this article describes (in incredible, down-to-the-serial-number detail), most of the problems were resolved. Now it's fairly cost-effective. The B-1 is still considered too expensive, and that will probably be what finally kills it.

A problem is NP-complete if it is NP-hard and in NP. A problem is in NP if a guess of the answer can be checked in polynomial time. A problem is NP-hard if being able to solve it in polytime means being able to solve any problem in NP in polytime. To prove P=NP, it is sufficient to find a polytime algorithm for an NP-hard problem. (I believe I have seen a result that suggests that there cannot be a non-constructive proof that P=NP, but I can't offer a reference offhand.)

As other posters have pointed out, "in polytime" is not a panacea: the polynomial might be unbelievably bad, the memory requirements of the algorithm might be unreasonably large, etc. (But n^3 is way better than 2^n even for large n: do the math.) There is a belief in the business known as the Polynomial Thesis which suggests that anytime there's a polynomial algorithm, there's a low-order polynomial algorithm.

All the encryption schemes you have ever heard of are in NP: if you can guess the key, you can quickly check that it works. This is true for both private key schemes (trivially) and public key schemes (guess the factorization of the product of two large primes, and you can certainly check it quickly by multiplication). The crypto arms race would then turn to algorithms that use the power of the NP-solver to encrypt: there are results that suggest that this is possible.

Most practical problems which are compute-bound are in NP, and thus tractable for an NP-solver. This includes such things as production scheduling and many kinds of gene and protein sequencing and folding. A few practical problems are believed or known not to be in NP, such as general-purpose planning (PSPACE complete) and checking computer programs for infinite loops (semi-decidable).

Hope this helps. For more information, check out the classic book by Garey and Johnson.

Steven Johnson? this is the same guy responsible for Interface Culture: How New Technology Transforms the Way We Create and Communicate, a book i've had the misfortune to read. Mr Johnson seems to have the Wired Magazine-style flair for making mountains out of molehills, making blind reaches into that which he knows nothing about (i.e. physics), and making an ass out of himself. do yourself a favor and read something smarter (maybe something from the Oprah Book Club?).

(the fact that most of the comments are clarifications on the HTTP-REFERRER discussion seems to suggest that the book might not terribly engaging to the Slashdot audience anyhow.)

This sounds like something i read in either Disappearing Cryptography or The Data Compression Book (was a while ago, can't remember which one - either way, both decent reads), which i didn't fully understand at the time but kind of related to RAID-5, where you need less disks to rebuild a filesystem generally composed of a greater number of disks.

This sounds like something i read in either Disappearing Cryptography or The Data Compression Book (was a while ago, can't remember which one - either way, both decent reads), which i didn't fully understand at the time but kind of related to RAID-5, where you need less disks to rebuild a filesystem generally composed of a greater number of disks.

I was surprised that Asimov's three laws of robotics were not included in the list. They had such an impact on future s-f stories about robots or A.I.

Dan Simmons even coined the word asimotif (quote from the french edition) in his book "Endymion".

For those who have never heard of these laws, here they are :

The 1940 Laws of Robotics

First Law:
A robot may not injure a human being, or, through inaction, allow a human being to come to harm.

Second Law:
A robot must obey orders given it by human beings, except where such orders would conflict with the First Law.

Third Law:
A robot must protect its own existence as long as such protection does not conflict with the First or Second Law.

If you want to see how Asimov dealt with these, I suggest reading "I, Robot", a little old but still interesting.

I sure hope they're being careful.

I don't think the pursuit of binary computing needs any encouragement. The companies above spend billions on it, products that use it are everywhere, and schools around the world teach students to design binary computers. Binary computing is being refined and improved as fast as it can be, period.

And even if trinary computing goes nowhere, I think it should be explored, if for no other reason than principle. How else are you going to know if it's better? The world needs more variety, not less (check out this book for why), and if you think otherwise I suggest you go work for Microsoft or McDonald's.

I, for one, am interested in alternative approaches not *necessarily* because I think they're better, but because without being exposed to them I won't know if my current assumptions are valid. For that reason *I WANT* to see this kind of thing on /. If something is better, I will use it without marketing's help.

Back in grad school, I used to read comp.theory, and at least once a month, we'd have some jerk post to the newsgroup "NP solved!", followed by some stupid, exponential time algorithm for 3-SAT or something. Invariably, the poster would spend thousands of lines defending his supreme genius in being the person who solved an NP complete problem!

NP complete does not mean unsolvable. It means slow.

Roughly speaking, NP problems are problems for which their is no non-exponential time solution known, but for which solutions can be tested for correctness in polynomial time. (To translate, exponential time means that the time to compute the solution for a problem of size n is bounded by x^n for some n. Polynomial time means that the time for a problem of size n can be bounded by some polynomial of n.)

The travelling salesman is a classic example of an NP problem. Given a set of cities, and the distance between any two cities, compute the shortest route that visits each city once. It's a trivial problem, but as far as anyone knows, it's not possible to write a program that quickly determines the correct shortest route in every case.

NP complete problems are problems which have the fascinating problem that *if* you found a polynomial time solution for that problem, then you would have found a polynomial time solution for all NP problems.

The travelling salesman is, if I recall correctly, slightly *worse* than NP complete. Again, if I recall correctly, if you have a P-time solution to the TSP, then you provably have a P-time solution to any NP-complete problem; but if you have a P-time solution for an NP-complete problem, that doesn't mean that you have a P-time solution to the TSP. The proof is actually quite interesting, so go get an algorithm textbook, and read it. I'd suggest the Corman, Leiserson and Rivest text, which is my personal favorite.

There are perfect, well known solutions for all of the classic NP complete problems. They're just exponential time. (For instance, for the travelling salesman: enumerate all possible routes; compute the length of each route; and pick the shortest one.)

Unfortunately, it isn't that simple. Read the history of the Manhatten Project. The FBI actually succeeded in its goal of not allowing a single leak of information out of the project [1].

You're kidding, right? Anyone who's read Feynman's book on the subject would know that the security was a joke. Fences with holes in them, inattentive guards, insecure safes, and poor whistleblowing policies were all part of the Manhattan Project's "security". Secondly, the security was handled by the military, not the FBI.

It was the lack of published information on atomic research in the US in 1940 and 1941 that told Kurchatov that something was "up"

Neat trick, since the Manhattan Project started in 1942. The absence of public information did tip off Kurchatov, but keeping your people from publishing in journals isn't hard. It's keeping spies from passing secrets to a foreign agent outside a diner 50 miles from the secure facility that presents a problem.

[1] OK, the Soviet Union had spies inside the project before it started, but that doesn't count!

David Greenglass, the mole who provided many of the secrets the Russians obtained from the Manhattan Project (and who served as a prosecution witness against the Rosenbergs), wasn't assigned to the project until 1944. There were of course other spies, and infiltrating before a project starts most definitely does count, but I felt like going after the factual error.

I'm reading a scary and gruesome book right now: Perdido Street Station.

It's got technology, magic, fearsome creatures, true love, betrayal, and tons of grime, dirt, slime, and bodily fluids. Highly recommended.

That's the way it's supposed to work. If you haven't already, give Thomas Kuhn's The Structure of Scientific Revolutions a read.

The growth of the proportion of introns (genetic code which does not directly influence the fitness function) to exons ("relevant" genetic information) as the fitness of the individual grows is a reasonably well-documented phenomenon in GP communities, and is commonly called bloat. "Relevant" because, despite conclusive evidence, most researchers believe that the introns are also relevant to the individual, even if not directly.

For example, mutations can occur on introns without any direct change to the individual. As introns are comprised essentially of copies or parts of original genetic code, they probably provide a place where mutations to possibly beneficial (albeit inactive) genes can occur safely.

Besides that, as bloat increases, the active genetic code decreases in proportion, and as a result you get a kind of 'clustering' of active genes, which is a good thing, because the chances of a disrupting crossing-over go down.

A great book on the subject is Genetic Algorithms + Data Structures = Evolution Programs, by Zbigniew Michalewicz (but I'm not sure if he covers bloat in the text). I remember reading a paper on bloat in one of the Springer-Verlag Lecture Notes on Computer Science about Genetic Programming.

Now, to see some really wacky and interesting things, the book to read is Evolutionary Design by Computers, edited by Peter Bentley, with lots of nice papers to read (and a kickass foreword from THE MAN Richard Dawkins)

Links for the paranoid:
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=3540606769&vm=
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=155860605X&vm=

Carlos

The growth of the proportion of introns (genetic code which does not directly influence the fitness function) to exons ("relevant" genetic information) as the fitness of the individual grows is a reasonably well-documented phenomenon in GP communities, and is commonly called bloat. "Relevant" because, despite conclusive evidence, most researchers believe that the introns are also relevant to the individual, even if not directly.

For example, mutations can occur on introns without any direct change to the individual. As introns are comprised essentially of copies or parts of original genetic code, they probably provide a place where mutations to possibly beneficial (albeit inactive) genes can occur safely.

Besides that, as bloat increases, the active genetic code decreases in proportion, and as a result you get a kind of 'clustering' of active genes, which is a good thing, because the chances of a disrupting crossing-over go down.

A great book on the subject is Genetic Algorithms + Data Structures = Evolution Programs, by Zbigniew Michalewicz (but I'm not sure if he covers bloat in the text). I remember reading a paper on bloat in one of the Springer-Verlag Lecture Notes on Computer Science about Genetic Programming.

Now, to see some really wacky and interesting things, the book to read is Evolutionary Design by Computers, edited by Peter Bentley, with lots of nice papers to read (and a kickass foreword from THE MAN Richard Dawkins)

Links for the paranoid:
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=3540606769&vm=
http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=155860605X&vm=

Carlos

Stroustrup advocated the Resource Acquisition Is Initialization pattern in the canonical C++ manual. It's practically what destructors are for. Anyone who didn't understand that book just isn't qualified to use the language.

If you are new to installing your own kernel, or you want to get started on kernel programming, see http://www.kernelnewbies.org/ and join them on IRC in #kernelnewbies on the Open Projects Network.

Also helpful to newbies, or to convince you it's worthwhile to help with testing, is my other article Why We Should All Test the New Linux Kernel.

And finally there is the Kernel HOWTO.

If you'd like to program or debug the kernel, I recommend a couple of books:

• Kernel Projects for Linux by Gary Nutt, ISBN 0-201-61243-7 - this is a lab manual with hands-on kernel programming projects that address a variety of kernel components
• Understanding the Linux Kernel by Bovet, Cassetti, and Oram, ISBN 0596000022 - I bought a number of kernel programming books, and this seemed to be the best written of the books that covered recent kernels. It's mainly 2.2, with short addenda in each chapter for the changes that were expected at the time of writing for 2.4

If you are new to installing your own kernel, or you want to get started on kernel programming, see http://www.kernelnewbies.org/ and join them on IRC in #kernelnewbies on the Open Projects Network.

Also helpful to newbies, or to convince you it's worthwhile to help with testing, is my other article Why We Should All Test the New Linux Kernel.

And finally there is the Kernel HOWTO.

If you'd like to program or debug the kernel, I recommend a couple of books:

• Kernel Projects for Linux by Gary Nutt, ISBN 0-201-61243-7 - this is a lab manual with hands-on kernel programming projects that address a variety of kernel components
• Understanding the Linux Kernel by Bovet, Cassetti, and Oram, ISBN 0596000022 - I bought a number of kernel programming books, and this seemed to be the best written of the books that covered recent kernels. It's mainly 2.2, with short addenda in each chapter for the changes that were expected at the time of writing for 2.4

Are you really Jon Katz? I just finished reading "Author Unknown: On the Trail of Anonymous" and you two sound a lot alike...
Give it up Jon "They Call Me Bruce" Katz!

I've always been fascinated by Obj-C but I've had little luck finding good intro material.

Apple has published, through Fatbrain, Object-Oriented Programming and the Objective-C Language - it looks like it addresses Obj-C separately from Cocoa, which is a good thing (remember, everyone, gcc supports Obj-C too :).

Also, read PeopleWare, which has some fantastic information about managing people (which, as the above poster says, is a large part of being an architect).

I found Computer: A History of the Information Machine, by Martin Campbell-Kelly and William Aspray gave a good overview of the history of computing ... not too detailed but gives enough to lead you to know what you want to find out more about ...

Solaris 9 Early Access features of great interest to our developers:
* Multiple Page Size Support in the kernel for better memory management
* Improved threading library for better scaling and performance
* Linux APIs, commands, and utilties enabling most Linux applications to easily be recompiled and run Solaris 9 Operating Environment
* Linux compatibility mode which allows Linux Intel applications to run unchanged (no recompilation) on Solaris 9, Intel Platform Edition
* New Reconfiguration Coordination Manager API allows applications to react to Dynamic Reconfiguration events