Slashdot Mirror

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

One thing I try hard to do is put good hyperlinks in my posts. Sometimes I have to hit the search engines to compose a post, so it will sometimes take me quite a while to write one up. If I mention a book I usually link to it on fatbrain or amazon or something or at least give the ISBN.

(This, BTW, is how you can get good karma. You don't have to just parrot the party line as the trolls like to say. Actually be informative or insightful, and if you provide hyperlinks then you multiply the value of your post because you take the reader on a tour of the Internet quite outside the slashdot discussion itself. And because these discussions are archived, all these hyperlinks and comments are of immense value for people doing research at a later date.)

BTW - If you think you'll be done with your education when you're done with college, or maybe after a year or two of on-the-job training, guess again! I set into my program of going back to the basics after thirteen years of professional work experience as a programmer. My first full-time programming job was in 1987.

I feel like I'm only beginning to get a grasp of "how to really program." But then I remember I've felt that way several times in the past. What's really going on though is that one enters plateaus in ability, coasts for a while, becomes dissatisfied, enters the "larval phase" again, and eventually reaches a new plateau.

Or maybe not. Many people get proficient enough that they make a living they're comfortable with, and then they stop learning, or at best learn only the minimum needed to keep up with the job market. I pray I will never become one of those people.

I'd further like to say that I think everyone should spend less time concentrating on learning specific API's in great detail, and instead focus on improving your core skills and fundamental understanding of programming.

I used to spend a lot of time learning API's (bought every volume of Inside Macintosh as they came out, and when I was just starting out and broke and hungry, used to read them in the bookstore before I could afford to buy them).

I prided myself on knowing all the little bugs and intricacies of the MacOS so I could just know to code around an OS bug without having to research why my code didn't work. I got so good that I was hired as an OS engineer at Apple where I concentrated on debugging the MacOS system software with MacsBug (a machine level debugger) - I had the MacOS source code at my disposal but that usually didn't help when I was visiting a tester's cubicle to diagnose a machine with a hard-to-reproduce crash.

Then I moved to the BeOS, shipped a product and wrote a lot of code but got fed up with their lack of commitment to their developers. And without getting paid to write BeOS code, I never could keep up with the BeOS API's I wanted to work with, like the new Media Kit (which I do know enough about to say it is pretty cool).

A couple years back I stopped spending much time learning and mostly just cranked out routine code. I felt I didn't want to learn anymore because, as I would sometimes say:

I feel that if I have to learn another API my head will surely explode.

I read Scott Meyers' Effective C++ and More Effective C++ and as I read through each item I inspected my program top to bottom and applied the advice to it (thus fixing a lot of bugs).

I also bought Bjarne Stroustrup's The C++ Programming Language: Special Edition (I recommend the special edition to professional programmers).

I started reading the newsgroups comp.lang.c++, comp.lang.c++.moderated and comp.std.c++ and posting questions there - in one case I found a construction on the very edge of the C++ standard and as a result of a compiler bug managed to instantiate an object of an abstract base class - its pure virtual function had a nil pointer in the vtbl and my program would crash when this function was called. An engineer from the compiler vendor read my post on the newsgroup, agreed that it was a bug that his product would compile my code, and logged a bug.

I didn't used to use the Standard Template Library very much at all. I had read too many mailing list and newsgroup postings from people whose code wouldn't compile when they changed platforms.

But I figured that by now compilers must have matured enough I could reasonably start trying out the STL. I bought STL Tutorial and Reference Guide by Musser and Stepanov and actually only read a little bit of it before I realized that the STL is actually really easy to use (the API is very simple and uniform), so if you know only a very little bit you can go a very long way.

In part because of challenging myself I became overwhelmed with programming stuckness as discussed in Overcomming Programmer's Block? (sic) and I suppose grew a little bit by taking a week off without pay to rest, contemplate, study and take a broader view of architectural issues.

One thing that helped quite a bit was learning about Extreme Programming.

These things have all had direct payoff in my code, both in making my code quicker to write, easier to debug, easier to make my classes more reusable within the one program I've been writing the last few months, and I'm pretty sure more likely to make some of the code I've written reusable in most any program in the future.

It's also made it a lot more pleasant.

But don't listen to the headhunters - what they're looking for is "skill sets" and industry buzzwords (COM, COM+, DCOM, TCP/IP, Visual C++, ASP, SQL, device drivers, CORBA, Unix internals, Java, Perl, PHP, JSP) - I get recruiter calls looking for all kinds of acronyms, most of which I don't mention anywhere on my resume.

Even I advise listing every skill keyword you can legimately claim on your online resume in Market Yourself - Tips for High-Tech Consultants - but while listing skillsets may be a valuable jobhunting tool in your resume, acquiring them should not be your focus.

BTW, when someone asks me whether they should learn Java or C++, I usually advise beginners to learn Java as it's easier to get something working reliably without crashing, but emphasize they should learn both languages as well as at least one kind of assembly code. I stress that it's important to learn both C++ and Java well enough to understand the strengths and weaknesses of each (pop quiz - why does Optimizeit claim to remove memory leaks from Java programs, when Java is a garbage collected language?).

Most new programmers these days are most concerned with which language will make them the most money the fastest. I tell them that they won't go anywhere until they can pick up any new programming language as a matter of course and have at least a couple under their belt.

I've got bad news for you neophytes - friends, just knowing a programming language doesn't win you very much in the work world, you have to understand the concepts and how to apply them, and you have to know how to apply them in a production environment, working in a business under pressure, shipping working products and dealing with people who don't understand anything of substance about computers.

Your focus should be on acquiring skills that will be applicable to any program you write. You should just learn enough of a skill or tool to get the job done and then leave it. Take with you what can be applied anywhere.

BTW - learning the fundamentals and not getting too specialized enables you to develop for any platform, as I do - you can see this from my homepage. (Perhaps one reason why I prefer understanding the fundamentals is that my degree is in Physics, and I've always wanted to understand things at a fundamental level - Quantum Mechanics, Particle Physics, Cosmology and so on.)

One final word of advice - read The Forum on Risks to the Public in Computers and Related Systems. It's often entertaining and funny, occassionally tragic, usually insightful and will make you a more responsible programmer and a wiser computer user. You'll certainly learn to avoid using computers for anything of real importance and take extra caution to protect yourself when you choose to do so.

I'd further like to say that I think everyone should spend less time concentrating on learning specific API's in great detail, and instead focus on improving your core skills and fundamental understanding of programming.

I used to spend a lot of time learning API's (bought every volume of Inside Macintosh as they came out, and when I was just starting out and broke and hungry, used to read them in the bookstore before I could afford to buy them).

I prided myself on knowing all the little bugs and intricacies of the MacOS so I could just know to code around an OS bug without having to research why my code didn't work. I got so good that I was hired as an OS engineer at Apple where I concentrated on debugging the MacOS system software with MacsBug (a machine level debugger) - I had the MacOS source code at my disposal but that usually didn't help when I was visiting a tester's cubicle to diagnose a machine with a hard-to-reproduce crash.

Then I moved to the BeOS, shipped a product and wrote a lot of code but got fed up with their lack of commitment to their developers. And without getting paid to write BeOS code, I never could keep up with the BeOS API's I wanted to work with, like the new Media Kit (which I do know enough about to say it is pretty cool).

A couple years back I stopped spending much time learning and mostly just cranked out routine code. I felt I didn't want to learn anymore because, as I would sometimes say:

I feel that if I have to learn another API my head will surely explode.

I read Scott Meyers' Effective C++ and More Effective C++ and as I read through each item I inspected my program top to bottom and applied the advice to it (thus fixing a lot of bugs).

I also bought Bjarne Stroustrup's The C++ Programming Language: Special Edition (I recommend the special edition to professional programmers).

I started reading the newsgroups comp.lang.c++, comp.lang.c++.moderated and comp.std.c++ and posting questions there - in one case I found a construction on the very edge of the C++ standard and as a result of a compiler bug managed to instantiate an object of an abstract base class - its pure virtual function had a nil pointer in the vtbl and my program would crash when this function was called. An engineer from the compiler vendor read my post on the newsgroup, agreed that it was a bug that his product would compile my code, and logged a bug.

I didn't used to use the Standard Template Library very much at all. I had read too many mailing list and newsgroup postings from people whose code wouldn't compile when they changed platforms.

But I figured that by now compilers must have matured enough I could reasonably start trying out the STL. I bought STL Tutorial and Reference Guide by Musser and Stepanov and actually only read a little bit of it before I realized that the STL is actually really easy to use (the API is very simple and uniform), so if you know only a very little bit you can go a very long way.

In part because of challenging myself I became overwhelmed with programming stuckness as discussed in Overcomming Programmer's Block? (sic) and I suppose grew a little bit by taking a week off without pay to rest, contemplate, study and take a broader view of architectural issues.

One thing that helped quite a bit was learning about Extreme Programming.

These things have all had direct payoff in my code, both in making my code quicker to write, easier to debug, easier to make my classes more reusable within the one program I've been writing the last few months, and I'm pretty sure more likely to make some of the code I've written reusable in most any program in the future.

It's also made it a lot more pleasant.

But don't listen to the headhunters - what they're looking for is "skill sets" and industry buzzwords (COM, COM+, DCOM, TCP/IP, Visual C++, ASP, SQL, device drivers, CORBA, Unix internals, Java, Perl, PHP, JSP) - I get recruiter calls looking for all kinds of acronyms, most of which I don't mention anywhere on my resume.

Even I advise listing every skill keyword you can legimately claim on your online resume in Market Yourself - Tips for High-Tech Consultants - but while listing skillsets may be a valuable jobhunting tool in your resume, acquiring them should not be your focus.

BTW, when someone asks me whether they should learn Java or C++, I usually advise beginners to learn Java as it's easier to get something working reliably without crashing, but emphasize they should learn both languages as well as at least one kind of assembly code. I stress that it's important to learn both C++ and Java well enough to understand the strengths and weaknesses of each (pop quiz - why does Optimizeit claim to remove memory leaks from Java programs, when Java is a garbage collected language?).

Most new programmers these days are most concerned with which language will make them the most money the fastest. I tell them that they won't go anywhere until they can pick up any new programming language as a matter of course and have at least a couple under their belt.

I've got bad news for you neophytes - friends, just knowing a programming language doesn't win you very much in the work world, you have to understand the concepts and how to apply them, and you have to know how to apply them in a production environment, working in a business under pressure, shipping working products and dealing with people who don't understand anything of substance about computers.

Your focus should be on acquiring skills that will be applicable to any program you write. You should just learn enough of a skill or tool to get the job done and then leave it. Take with you what can be applied anywhere.

BTW - learning the fundamentals and not getting too specialized enables you to develop for any platform, as I do - you can see this from my homepage. (Perhaps one reason why I prefer understanding the fundamentals is that my degree is in Physics, and I've always wanted to understand things at a fundamental level - Quantum Mechanics, Particle Physics, Cosmology and so on.)

One final word of advice - read The Forum on Risks to the Public in Computers and Related Systems. It's often entertaining and funny, occassionally tragic, usually insightful and will make you a more responsible programmer and a wiser computer user. You'll certainly learn to avoid using computers for anything of real importance and take extra caution to protect yourself when you choose to do so.

I'd further like to say that I think everyone should spend less time concentrating on learning specific API's in great detail, and instead focus on improving your core skills and fundamental understanding of programming.

I used to spend a lot of time learning API's (bought every volume of Inside Macintosh as they came out, and when I was just starting out and broke and hungry, used to read them in the bookstore before I could afford to buy them).

I prided myself on knowing all the little bugs and intricacies of the MacOS so I could just know to code around an OS bug without having to research why my code didn't work. I got so good that I was hired as an OS engineer at Apple where I concentrated on debugging the MacOS system software with MacsBug (a machine level debugger) - I had the MacOS source code at my disposal but that usually didn't help when I was visiting a tester's cubicle to diagnose a machine with a hard-to-reproduce crash.

Then I moved to the BeOS, shipped a product and wrote a lot of code but got fed up with their lack of commitment to their developers. And without getting paid to write BeOS code, I never could keep up with the BeOS API's I wanted to work with, like the new Media Kit (which I do know enough about to say it is pretty cool).

A couple years back I stopped spending much time learning and mostly just cranked out routine code. I felt I didn't want to learn anymore because, as I would sometimes say:

I feel that if I have to learn another API my head will surely explode.

I read Scott Meyers' Effective C++ and More Effective C++ and as I read through each item I inspected my program top to bottom and applied the advice to it (thus fixing a lot of bugs).

I also bought Bjarne Stroustrup's The C++ Programming Language: Special Edition (I recommend the special edition to professional programmers).

I started reading the newsgroups comp.lang.c++, comp.lang.c++.moderated and comp.std.c++ and posting questions there - in one case I found a construction on the very edge of the C++ standard and as a result of a compiler bug managed to instantiate an object of an abstract base class - its pure virtual function had a nil pointer in the vtbl and my program would crash when this function was called. An engineer from the compiler vendor read my post on the newsgroup, agreed that it was a bug that his product would compile my code, and logged a bug.

I didn't used to use the Standard Template Library very much at all. I had read too many mailing list and newsgroup postings from people whose code wouldn't compile when they changed platforms.

But I figured that by now compilers must have matured enough I could reasonably start trying out the STL. I bought STL Tutorial and Reference Guide by Musser and Stepanov and actually only read a little bit of it before I realized that the STL is actually really easy to use (the API is very simple and uniform), so if you know only a very little bit you can go a very long way.

In part because of challenging myself I became overwhelmed with programming stuckness as discussed in Overcomming Programmer's Block? (sic) and I suppose grew a little bit by taking a week off without pay to rest, contemplate, study and take a broader view of architectural issues.

One thing that helped quite a bit was learning about Extreme Programming.

These things have all had direct payoff in my code, both in making my code quicker to write, easier to debug, easier to make my classes more reusable within the one program I've been writing the last few months, and I'm pretty sure more likely to make some of the code I've written reusable in most any program in the future.

It's also made it a lot more pleasant.

But don't listen to the headhunters - what they're looking for is "skill sets" and industry buzzwords (COM, COM+, DCOM, TCP/IP, Visual C++, ASP, SQL, device drivers, CORBA, Unix internals, Java, Perl, PHP, JSP) - I get recruiter calls looking for all kinds of acronyms, most of which I don't mention anywhere on my resume.

Even I advise listing every skill keyword you can legimately claim on your online resume in Market Yourself - Tips for High-Tech Consultants - but while listing skillsets may be a valuable jobhunting tool in your resume, acquiring them should not be your focus.

BTW, when someone asks me whether they should learn Java or C++, I usually advise beginners to learn Java as it's easier to get something working reliably without crashing, but emphasize they should learn both languages as well as at least one kind of assembly code. I stress that it's important to learn both C++ and Java well enough to understand the strengths and weaknesses of each (pop quiz - why does Optimizeit claim to remove memory leaks from Java programs, when Java is a garbage collected language?).

Most new programmers these days are most concerned with which language will make them the most money the fastest. I tell them that they won't go anywhere until they can pick up any new programming language as a matter of course and have at least a couple under their belt.

I've got bad news for you neophytes - friends, just knowing a programming language doesn't win you very much in the work world, you have to understand the concepts and how to apply them, and you have to know how to apply them in a production environment, working in a business under pressure, shipping working products and dealing with people who don't understand anything of substance about computers.

Your focus should be on acquiring skills that will be applicable to any program you write. You should just learn enough of a skill or tool to get the job done and then leave it. Take with you what can be applied anywhere.

BTW - learning the fundamentals and not getting too specialized enables you to develop for any platform, as I do - you can see this from my homepage. (Perhaps one reason why I prefer understanding the fundamentals is that my degree is in Physics, and I've always wanted to understand things at a fundamental level - Quantum Mechanics, Particle Physics, Cosmology and so on.)

One final word of advice - read The Forum on Risks to the Public in Computers and Related Systems. It's often entertaining and funny, occassionally tragic, usually insightful and will make you a more responsible programmer and a wiser computer user. You'll certainly learn to avoid using computers for anything of real importance and take extra caution to protect yourself when you choose to do so.

I'd further like to say that I think everyone should spend less time concentrating on learning specific API's in great detail, and instead focus on improving your core skills and fundamental understanding of programming.

I used to spend a lot of time learning API's (bought every volume of Inside Macintosh as they came out, and when I was just starting out and broke and hungry, used to read them in the bookstore before I could afford to buy them).

I prided myself on knowing all the little bugs and intricacies of the MacOS so I could just know to code around an OS bug without having to research why my code didn't work. I got so good that I was hired as an OS engineer at Apple where I concentrated on debugging the MacOS system software with MacsBug (a machine level debugger) - I had the MacOS source code at my disposal but that usually didn't help when I was visiting a tester's cubicle to diagnose a machine with a hard-to-reproduce crash.

Then I moved to the BeOS, shipped a product and wrote a lot of code but got fed up with their lack of commitment to their developers. And without getting paid to write BeOS code, I never could keep up with the BeOS API's I wanted to work with, like the new Media Kit (which I do know enough about to say it is pretty cool).

A couple years back I stopped spending much time learning and mostly just cranked out routine code. I felt I didn't want to learn anymore because, as I would sometimes say:

I feel that if I have to learn another API my head will surely explode.

I read Scott Meyers' Effective C++ and More Effective C++ and as I read through each item I inspected my program top to bottom and applied the advice to it (thus fixing a lot of bugs).

I also bought Bjarne Stroustrup's The C++ Programming Language: Special Edition (I recommend the special edition to professional programmers).

I started reading the newsgroups comp.lang.c++, comp.lang.c++.moderated and comp.std.c++ and posting questions there - in one case I found a construction on the very edge of the C++ standard and as a result of a compiler bug managed to instantiate an object of an abstract base class - its pure virtual function had a nil pointer in the vtbl and my program would crash when this function was called. An engineer from the compiler vendor read my post on the newsgroup, agreed that it was a bug that his product would compile my code, and logged a bug.

I didn't used to use the Standard Template Library very much at all. I had read too many mailing list and newsgroup postings from people whose code wouldn't compile when they changed platforms.

But I figured that by now compilers must have matured enough I could reasonably start trying out the STL. I bought STL Tutorial and Reference Guide by Musser and Stepanov and actually only read a little bit of it before I realized that the STL is actually really easy to use (the API is very simple and uniform), so if you know only a very little bit you can go a very long way.

In part because of challenging myself I became overwhelmed with programming stuckness as discussed in Overcomming Programmer's Block? (sic) and I suppose grew a little bit by taking a week off without pay to rest, contemplate, study and take a broader view of architectural issues.

One thing that helped quite a bit was learning about Extreme Programming.

These things have all had direct payoff in my code, both in making my code quicker to write, easier to debug, easier to make my classes more reusable within the one program I've been writing the last few months, and I'm pretty sure more likely to make some of the code I've written reusable in most any program in the future.

It's also made it a lot more pleasant.

But don't listen to the headhunters - what they're looking for is "skill sets" and industry buzzwords (COM, COM+, DCOM, TCP/IP, Visual C++, ASP, SQL, device drivers, CORBA, Unix internals, Java, Perl, PHP, JSP) - I get recruiter calls looking for all kinds of acronyms, most of which I don't mention anywhere on my resume.

Even I advise listing every skill keyword you can legimately claim on your online resume in Market Yourself - Tips for High-Tech Consultants - but while listing skillsets may be a valuable jobhunting tool in your resume, acquiring them should not be your focus.

BTW, when someone asks me whether they should learn Java or C++, I usually advise beginners to learn Java as it's easier to get something working reliably without crashing, but emphasize they should learn both languages as well as at least one kind of assembly code. I stress that it's important to learn both C++ and Java well enough to understand the strengths and weaknesses of each (pop quiz - why does Optimizeit claim to remove memory leaks from Java programs, when Java is a garbage collected language?).

Most new programmers these days are most concerned with which language will make them the most money the fastest. I tell them that they won't go anywhere until they can pick up any new programming language as a matter of course and have at least a couple under their belt.

I've got bad news for you neophytes - friends, just knowing a programming language doesn't win you very much in the work world, you have to understand the concepts and how to apply them, and you have to know how to apply them in a production environment, working in a business under pressure, shipping working products and dealing with people who don't understand anything of substance about computers.

Your focus should be on acquiring skills that will be applicable to any program you write. You should just learn enough of a skill or tool to get the job done and then leave it. Take with you what can be applied anywhere.

BTW - learning the fundamentals and not getting too specialized enables you to develop for any platform, as I do - you can see this from my homepage. (Perhaps one reason why I prefer understanding the fundamentals is that my degree is in Physics, and I've always wanted to understand things at a fundamental level - Quantum Mechanics, Particle Physics, Cosmology and so on.)

One final word of advice - read The Forum on Risks to the Public in Computers and Related Systems. It's often entertaining and funny, occassionally tragic, usually insightful and will make you a more responsible programmer and a wiser computer user. You'll certainly learn to avoid using computers for anything of real importance and take extra caution to protect yourself when you choose to do so.

are increasingly accustomed to tailoring their news consumption: they want information of particular interest to them, at the times they choose to receive it.

A very interesting bit of truth. Neil Postman writes very shocking and telling books on this subject. Important is: Amusing Ourselves to Death and How to Watch TV News which deal with these ideas.

What will surely rise as a problem in the near future is a society disconnected from a common 'world state' (not state as in country, but state as in tense). When people only have interest in seeking out and reading news that is of interest to them we may have a problem. The evening news (for all its obvious ills) provided a common public discourse. When people begin to consume their news information as entertainment, we loose the ability to maintain an idea of a general present state (of society/world). For instance, Slashdotters, myself included, are rabid over the MPAA/DMCA/RIAA/DeCSS/Napster/2600 mess. When we only focus on the problems WE are interested in we loose touch with everything else. Have you ever tried to explain this situation to 'non-slashdot-types'? Painful isn't it. This situation has broad reaching implications and people in the general US population have ZERO idea what the problem is, maybe because they find other things 'more interesting'.

The mainstream media plays to the middle, this topic will NEVER bubble to the top. Now imagine other groups coalescing around whatever topic is of interest to them, by doing so it marginalizes our ability act in force. This will separate people into many disperse groups, unable to communicate. People no longer are aware of the general world around them. We have got to try and maintain a balance between specific news topics/sources (tech - slashdot) by balancing it with more general topics/sources. (bbc/cbc/cnn - environnent/social justice/politics). When a story appears on one of these sources* remember that their is another equally rabid group trying desperately to get US to hear them.

* except the obvious status-quo corporatist propaganda stories foisted by the corporate media(which should be obviously ignored).

Scared of the recent comments by Sony's VP? Yeah, me too. Corporations got you down? Yeah, me too. Why don't you:

are increasingly accustomed to tailoring their news consumption: they want information of particular interest to them, at the times they choose to receive it.

A very interesting bit of truth. Neil Postman writes very shocking and telling books on this subject. Important is: Amusing Ourselves to Death and How to Watch TV News which deal with these ideas.

What will surely rise as a problem in the near future is a society disconnected from a common 'world state' (not state as in country, but state as in tense). When people only have interest in seeking out and reading news that is of interest to them we may have a problem. The evening news (for all its obvious ills) provided a common public discourse. When people begin to consume their news information as entertainment, we loose the ability to maintain an idea of a general present state (of society/world). For instance, Slashdotters, myself included, are rabid over the MPAA/DMCA/RIAA/DeCSS/Napster/2600 mess. When we only focus on the problems WE are interested in we loose touch with everything else. Have you ever tried to explain this situation to 'non-slashdot-types'? Painful isn't it. This situation has broad reaching implications and people in the general US population have ZERO idea what the problem is, maybe because they find other things 'more interesting'.

The mainstream media plays to the middle, this topic will NEVER bubble to the top. Now imagine other groups coalescing around whatever topic is of interest to them, by doing so it marginalizes our ability act in force. This will separate people into many disperse groups, unable to communicate. People no longer are aware of the general world around them. We have got to try and maintain a balance between specific news topics/sources (tech - slashdot) by balancing it with more general topics/sources. (bbc/cbc/cnn - environnent/social justice/politics). When a story appears on one of these sources* remember that their is another equally rabid group trying desperately to get US to hear them.

* except the obvious status-quo corporatist propaganda stories foisted by the corporate media(which should be obviously ignored).

Scared of the recent comments by Sony's VP? Yeah, me too. Corporations got you down? Yeah, me too. Why don't you:

I'm sick to the back teeth of watching all these fevered egos in the KDE and GNOME camps whacking off in public like two troops of rabid spider monkeys. Snipe followed by counter-snipe followed by smug insinuation followed by all-out shit-slinging rarely seen outside the monkey house at the Zoo. Where they get the time to code is beyond me.

Point is, I've tried both and they both suck. Why? Because they are shamelessly ripping off a UI paradigm popularised by Microsoft, a paradigm they ripped off in turn from Apple, who designed for a 128K monochrome machine with a 400K floppy drive. If I wanted my machine to work like Windows, why would I have bothered installing Linux in the first place? Both GNOME and KDE actually boast about the extent to which they follow Windows-- "no retraining-- it works just like Windows!" they crow.

This is cowardly bullshit. Any real user you talk to will tell you how much Windows and the MacOS suck. KDE and GNOME are appealing to the same middle-tier IS management types who mandate the use of Windows throughout their organisation; empty-headed MBA jackals with one hand turning the pages of some gushing ZD publication loaded with "handy" product feature matrices and the other hand tugging at their atrophied genitals. These, all you GNOME and KDE advocates, these are the assholes that put Microsoft on the map, and you are lining up, learning to talk their talk and walk their walk so you can kiss their asses. "No retraining-- it works just like Windows!" You fucking whores!

Why does the Open Source community have such an inferiority complex when it comes to original UI design? Is it because we don't really "get" GUIs? Is it because deep down we'd just be happy with a command line if it wasn't for those pesky users wanting their icons and their flat toolbars? So instead of sitting down and thinking through this whole UI thing, we just clone Windows? Are you so desperate for mindshare and flattering media coverage that you'd take over screwing your users where Bill Gates left off? A reaming from the Free Software community is going to feel much the same as a reaming from Microsoft come morning. "Microsoft spend millions on usability! We don't have the resources!" scream the apologists. You idiots. That's a PR exercise if ever I saw one. Microsoft spend that money to impress the middle managers who are their real customers; the rest can go hang. Do you really think Microsoft ever ditched a single line of interface code because it raised a usability issue? The whole thing is a snow-job; it gives Microsoft plausible denial: "What? You say our products are unusable? Well, we spent squillions on usability last year-- you must be a retard or something."

The 15-year old Mac GUI metaphor is creaking badly; it doesn't scale. I have a 6GB hard disk at home (tiny by today's standards); how am I meant to navigate it, to manage? With a GTK+ tree control? Think again, Mr. GNOME Man. Furthermore, we're stuck with Mac UI dogma that made sense on a 128K box but not on a machine with 32MB or more of RAM. A one-shot Clipboard in this day and age? Puh-lease! You want me to click File, Save every five minutes? Give me a break; I could record every damn keystroke in my word processor including ^H and never run short on hard disk space. File Open dialog boxes? They were a hack because the first MacOS was single tasking and you couldn't get at the shell!

Think, you freaks, think! All this sniping about code reuse and re-inventing the wheel. Both camps started re-inventing the wheel before the first line of GNOME or KDE code was written, and you didn't even notice.

Read this and this and then come back to me.

I'm sick to the back teeth of watching all these fevered egos in the KDE and GNOME camps whacking off in public like two troops of rabid spider monkeys. Snipe followed by counter-snipe followed by smug insinuation followed by all-out shit-slinging rarely seen outside the monkey house at the Zoo. Where they get the time to code is beyond me.

Point is, I've tried both and they both suck. Why? Because they are shamelessly ripping off a UI paradigm popularised by Microsoft, a paradigm they ripped off in turn from Apple, who designed for a 128K monochrome machine with a 400K floppy drive. If I wanted my machine to work like Windows, why would I have bothered installing Linux in the first place? Both GNOME and KDE actually boast about the extent to which they follow Windows-- "no retraining-- it works just like Windows!" they crow.

This is cowardly bullshit. Any real user you talk to will tell you how much Windows and the MacOS suck. KDE and GNOME are appealing to the same middle-tier IS management types who mandate the use of Windows throughout their organisation; empty-headed MBA jackals with one hand turning the pages of some gushing ZD publication loaded with "handy" product feature matrices and the other hand tugging at their atrophied genitals. These, all you GNOME and KDE advocates, these are the assholes that put Microsoft on the map, and you are lining up, learning to talk their talk and walk their walk so you can kiss their asses. "No retraining-- it works just like Windows!" You fucking whores!

Why does the Open Source community have such an inferiority complex when it comes to original UI design? Is it because we don't really "get" GUIs? Is it because deep down we'd just be happy with a command line if it wasn't for those pesky users wanting their icons and their flat toolbars? So instead of sitting down and thinking through this whole UI thing, we just clone Windows? Are you so desperate for mindshare and flattering media coverage that you'd take over screwing your users where Bill Gates left off? A reaming from the Free Software community is going to feel much the same as a reaming from Microsoft come morning. "Microsoft spend millions on usability! We don't have the resources!" scream the apologists. You idiots. That's a PR exercise if ever I saw one. Microsoft spend that money to impress the middle managers who are their real customers; the rest can go hang. Do you really think Microsoft ever ditched a single line of interface code because it raised a usability issue? The whole thing is a snow-job; it gives Microsoft plausible denial: "What? You say our products are unusable? Well, we spent squillions on usability last year-- you must be a retard or something."

The 15-year old Mac GUI metaphor is creaking badly; it doesn't scale. I have a 6GB hard disk at home (tiny by today's standards); how am I meant to navigate it, to manage? With a GTK+ tree control? Think again, Mr. GNOME Man. Furthermore, we're stuck with Mac UI dogma that made sense on a 128K box but not on a machine with 32MB or more of RAM. A one-shot Clipboard in this day and age? Puh-lease! You want me to click File, Save every five minutes? Give me a break; I could record every damn keystroke in my word processor including ^H and never run short on hard disk space. File Open dialog boxes? They were a hack because the first MacOS was single tasking and you couldn't get at the shell!

Think, you freaks, think! All this sniping about code reuse and re-inventing the wheel. Both camps started re-inventing the wheel before the first line of GNOME or KDE code was written, and you didn't even notice.

Read this and this and then come back to me.

personally, i'd be more likely to buy a book called "kickass" than "for dummies"

and kickass must have been on somebody's shelves

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The No BS Guide to Linux - This book is a great introduction to the commandline interface. Nothing much on X, but everything you need to find your way around a shell.

Idiot's Guide to Linux My favorite book. Manuel Ricart wrote this excellent guide to running X on linux with emphasis on KDE. Good tips on backing up, security, and other basics that many books take for granted.

Teach Yourself KDE 1.1 Simply a good guide to learning how to fully use KDE. Each lesson is simple and focused, allowing those that need to learn in short amounts of time a concise lesson.

Apache Server for Dummies A straightforward book on configuring Apache. It's not meant as a handbook for a business, more as a way for someone to understand and configure Apache for the first time to understand the concepts behind the software. It allowed me to get a server up and running and even running CGI scripts for intranet use.

If you are already a GNUGod, you won't need these books. But if you are like me and trying to learn these things without the benefit of live human tutor, these books are handy.

Also, the two of the books deal mainly with KDE. If you like Gnome, bewarned that Idiot's Guide to Linux deals mainly with KDE and not Gnome.

The book Peopleware by Tom Demarco and Timothy Lister has a section with seven chapters about the office environment alone.

This book is a must read for anybody who manages people in the tech industry, wants to manage people in the tech industry or who just want to get additional perspective on how many facets of management, environment and coworkers can affect your productivity and your happiness.

This book is as essential as The Mythical Man Month by Brooks.

If you haven't read this books yet, read them now.

The book Peopleware by Tom Demarco and Timothy Lister has a section with seven chapters about the office environment alone.

This book is a must read for anybody who manages people in the tech industry, wants to manage people in the tech industry or who just want to get additional perspective on how many facets of management, environment and coworkers can affect your productivity and your happiness.

This book is as essential as The Mythical Man Month by Brooks.

If you haven't read this books yet, read them now.

The book Peopleware by Tom Demarco and Timothy Lister has a section with seven chapters about the office environment alone.

This book is a must read for anybody who manages people in the tech industry, wants to manage people in the tech industry or who just want to get additional perspective on how many facets of management, environment and coworkers can affect your productivity and your happiness.

This book is as essential as The Mythical Man Month by Brooks.

If you haven't read this books yet, read them now.

The book Peopleware by Tom Demarco and Timothy Lister has a section with seven chapters about the office environment alone.

This book is a must read for anybody who manages people in the tech industry, wants to manage people in the tech industry or who just want to get additional perspective on how many facets of management, environment and coworkers can affect your productivity and your happiness.

This book is as essential as The Mythical Man Month by Brooks.

If you haven't read this books yet, read them now.

The book Peopleware by Tom Demarco and Timothy Lister has a section with seven chapters about the office environment alone.

This book is a must read for anybody who manages people in the tech industry, wants to manage people in the tech industry or who just want to get additional perspective on how many facets of management, environment and coworkers can affect your productivity and your happiness.

This book is as essential as The Mythical Man Month by Brooks.

If you haven't read this books yet, read them now.

PostgreSQL is the perfect book for you if you use PostgreSQL at work and on your Web sites wherever you expose data on the Web using Linux and Apache. It covers the new features of PostgreSQL as well as the PostgreSQL processor, which defines all necessary objects in a database, to get acquainted with SQL and to test ideas and verify joins and queries. Database developers for corporate and Web applications will find this book useful. It is geared toward intermediate to advanced developers who have designed and administered databases, but not PostgreSQL. The accompanying CD includes PostgreSQL, plus sample databases and modules.

If you just want to use it (and not admin it), O'Reilly's Programming the Perl DBI has some info on accessing a PostgreSQL DB (hint: it's not that different from any other DB when seen through DBI). Oh yeah, MySQL & mSQL, also from O'Reilly has a little bit about it (but not very much at all). I guess readmes, man pages and HOW-TOs are your friends for the next couple months.

If you're really curious, throw it on a test machine and (if possible) "port" some apps to use Postgres instead of MySQL or whatever. You probably won't reach any real conclusion (or do nearly enough work to justify moving to another DB for a production environment), but the effort will very likely get you very familiar with how it works, how to set it up, how to admin it, its performance, its quirks, etc. That's both a good and a bad thing, BTW... :-)

-B

And, if you're interested in finding that
Tim Berners-Lee book without violating the
Amazon boycot you could try Fatbrain:
Weaving the Web

In addition, I would note that while $100M that Columbia receives in patent royalties may seem like a lot, in an institution with annual gross revenues of a few billion dollars (mostly tuition), this is not a dog-wagging tail. This is especially true as most universities actually lose money on research, since providing the infrastructure costs more than grants bring in in indirect cost reimbursement (see below), and those that do make any significant money tend to make almost all of their money on one or two patents---so profit from research becomes a big crap-shoot. The real marketplace value of research to universities is as P.R.

University technology transfer offices are less important for making money for the university than for impressing superstar faculty whom the univeristy wants to hire and who want to know that if they come, the university will support them in their quest to make millions off their research. The millions do not, in general, materialize, but supporting these fantasies is an increasingly significant part of the hiring process.

Even more significant for a university, though, is attracting good students, and here research acts as a loss-leader, as the economists Robert H. Frank and Philip J. Cook describe in The Winner-Take-All-Society . The argument here is that good students, all other things being equal, would prefer to go to a university that produces a lot of Nobel Prizes, even if their tuition is helping subsidize the research (Frank and Cook argue unpersuasively that the increasing importance of research has driven hyperinflating college tuitions, but fail to account for the fact that four-year liberal arts colleges, where much less research is done, have suffered similar inflation). Again, there is nothing new in the .com world that we haven't seen before with the defense industry or biotechnology.

One of the best serious historical looks at the interaction of university research and the commercial sector is the first half of David C. Mowery and Nathan Rosenberg's Technology and the Pursuit of Economic Growth . A more contemporary account of the cutting edge can be found in Lewis M. Branscomb's Industrializing Knowledge: University-Industry Linkages in Japan and the United States . Both books provide strong evidence that Katz's alarmism reflects neither anything fundamentally new nor anything so seriously alarming or threatening as he would have us believe.

In addition, I would note that while $100M that Columbia receives in patent royalties may seem like a lot, in an institution with annual gross revenues of a few billion dollars (mostly tuition), this is not a dog-wagging tail. This is especially true as most universities actually lose money on research, since providing the infrastructure costs more than grants bring in in indirect cost reimbursement (see below), and those that do make any significant money tend to make almost all of their money on one or two patents---so profit from research becomes a big crap-shoot. The real marketplace value of research to universities is as P.R.

University technology transfer offices are less important for making money for the university than for impressing superstar faculty whom the univeristy wants to hire and who want to know that if they come, the university will support them in their quest to make millions off their research. The millions do not, in general, materialize, but supporting these fantasies is an increasingly significant part of the hiring process.

Even more significant for a university, though, is attracting good students, and here research acts as a loss-leader, as the economists Robert H. Frank and Philip J. Cook describe in The Winner-Take-All-Society . The argument here is that good students, all other things being equal, would prefer to go to a university that produces a lot of Nobel Prizes, even if their tuition is helping subsidize the research (Frank and Cook argue unpersuasively that the increasing importance of research has driven hyperinflating college tuitions, but fail to account for the fact that four-year liberal arts colleges, where much less research is done, have suffered similar inflation). Again, there is nothing new in the .com world that we haven't seen before with the defense industry or biotechnology.

One of the best serious historical looks at the interaction of university research and the commercial sector is the first half of David C. Mowery and Nathan Rosenberg's Technology and the Pursuit of Economic Growth . A more contemporary account of the cutting edge can be found in Lewis M. Branscomb's Industrializing Knowledge: University-Industry Linkages in Japan and the United States . Both books provide strong evidence that Katz's alarmism reflects neither anything fundamentally new nor anything so seriously alarming or threatening as he would have us believe.

In addition, I would note that while $100M that Columbia receives in patent royalties may seem like a lot, in an institution with annual gross revenues of a few billion dollars (mostly tuition), this is not a dog-wagging tail. This is especially true as most universities actually lose money on research, since providing the infrastructure costs more than grants bring in in indirect cost reimbursement (see below), and those that do make any significant money tend to make almost all of their money on one or two patents---so profit from research becomes a big crap-shoot. The real marketplace value of research to universities is as P.R.

University technology transfer offices are less important for making money for the university than for impressing superstar faculty whom the univeristy wants to hire and who want to know that if they come, the university will support them in their quest to make millions off their research. The millions do not, in general, materialize, but supporting these fantasies is an increasingly significant part of the hiring process.

Even more significant for a university, though, is attracting good students, and here research acts as a loss-leader, as the economists Robert H. Frank and Philip J. Cook describe in The Winner-Take-All-Society . The argument here is that good students, all other things being equal, would prefer to go to a university that produces a lot of Nobel Prizes, even if their tuition is helping subsidize the research (Frank and Cook argue unpersuasively that the increasing importance of research has driven hyperinflating college tuitions, but fail to account for the fact that four-year liberal arts colleges, where much less research is done, have suffered similar inflation). Again, there is nothing new in the .com world that we haven't seen before with the defense industry or biotechnology.

One of the best serious historical looks at the interaction of university research and the commercial sector is the first half of David C. Mowery and Nathan Rosenberg's Technology and the Pursuit of Economic Growth . A more contemporary account of the cutting edge can be found in Lewis M. Branscomb's Industrializing Knowledge: University-Industry Linkages in Japan and the United States . Both books provide strong evidence that Katz's alarmism reflects neither anything fundamentally new nor anything so seriously alarming or threatening as he would have us believe.

In addition, I would note that while $100M that Columbia receives in patent royalties may seem like a lot, in an institution with annual gross revenues of a few billion dollars (mostly tuition), this is not a dog-wagging tail. This is especially true as most universities actually lose money on research, since providing the infrastructure costs more than grants bring in in indirect cost reimbursement (see below), and those that do make any significant money tend to make almost all of their money on one or two patents---so profit from research becomes a big crap-shoot. The real marketplace value of research to universities is as P.R.

University technology transfer offices are less important for making money for the university than for impressing superstar faculty whom the univeristy wants to hire and who want to know that if they come, the university will support them in their quest to make millions off their research. The millions do not, in general, materialize, but supporting these fantasies is an increasingly significant part of the hiring process.

Even more significant for a university, though, is attracting good students, and here research acts as a loss-leader, as the economists Robert H. Frank and Philip J. Cook describe in The Winner-Take-All-Society . The argument here is that good students, all other things being equal, would prefer to go to a university that produces a lot of Nobel Prizes, even if their tuition is helping subsidize the research (Frank and Cook argue unpersuasively that the increasing importance of research has driven hyperinflating college tuitions, but fail to account for the fact that four-year liberal arts colleges, where much less research is done, have suffered similar inflation). Again, there is nothing new in the .com world that we haven't seen before with the defense industry or biotechnology.

One of the best serious historical looks at the interaction of university research and the commercial sector is the first half of David C. Mowery and Nathan Rosenberg's Technology and the Pursuit of Economic Growth . A more contemporary account of the cutting edge can be found in Lewis M. Branscomb's Industrializing Knowledge: University-Industry Linkages in Japan and the United States . Both books provide strong evidence that Katz's alarmism reflects neither anything fundamentally new nor anything so seriously alarming or threatening as he would have us believe.

You should read Guns, Germs and Steel to see how they faired.

It's actually an excellent book. It changed my view of the necessity of government, and I'm an anarchist of sorts.

• MMM Group at University of Nijmegen [publications]
• Machine Listening @ MIT Media Lab
• Affective Computing @ MIT Media Lab
• Musclefish

• Music, Cognition, and Computerized Sound, Perry R. Cook
• Music, Mind and Machine, Peter Desain and Henkjan Honing
• The Scientist and Engineer's Guide to Digital Signal Processing, Steven W. Smith
• Neural Networks for Pattern Recognition, Christopher M. Bishop

• Tracking Musical Beats in Real Time, Paul E. Allen and Roger B. Dannenberg
• A Model for Musical Rhythm, Jeff A. Bilmes
• Autocorrelation and the Study of Musical Expression, Peter Desain, Siebe de Vos
• A Beat Tracking System for Audio Signals, Simon Dixon
• Prediction-Driven Computational Auditory Scene Analysis for Dense Sound Mixtures, Daniel P. W. Ellis
• A Similarity Measure for Automatic Audio Classification, Jonathan Foote
• Representing Rhythmic Patterns in a Network of Oscillators, Michael Gasser and Douglas Eck
• Adaptive Signal Models: Theory, Algorithms, and Audio Applications, Michael Mark Goodwin
• Recognition of Music Types, Hagen Soltau, Tanja Schultz, Martin Westphal, Alex Waibel
• Irrelevant Features and the Subset Selection Problem, George H. John, Ron Kohavi, Karl Pfleger
• Beat tracking with a nonlinear oscilator, Edward W. Large
• Modeling beat perception with a nonlinear oscilator, Edward W. Large
• Automatic Transcription of Simple Polyphonic Music: Robust Front End Processing, Keith D. Martin
• Musical instrument identification: A pattern-recognition approach, Keith D. Martin and Youngmoo E. Kim
• Music Content Analysis through Models of Audition, Keith D. Martin, Eric D. Scheirer, Barry L. Vercoe
• Musical Sound Information: Musical gestures and embedding synthesis, Eric Metois
• A Machine Learning Approach to Musical Style Recognition, Roger B. Dannenberg, Belinda Thom, and David Watson
• Resonanc e and the perception of musical meter, Large, E. W., & Kolen, J. F.
• Music-Listening Systems, Eric D. Scheirer
• Tempo and beat analysis of acoustic musical signals, Eric D. Scheirer
• Content-Based Classification, Search, and Retrieval of Audio, Erling Wold, Thom Blum, Douglas Keislar, James Wheaton
• Classification, Search, and Retrieval of Audio, Erling Wold, Thom Blum, Douglas Keislar, James Wheaton

• MMM Group at University of Nijmegen [publications]
• Machine Listening @ MIT Media Lab
• Affective Computing @ MIT Media Lab
• Musclefish

• Music, Cognition, and Computerized Sound, Perry R. Cook
• Music, Mind and Machine, Peter Desain and Henkjan Honing
• The Scientist and Engineer's Guide to Digital Signal Processing, Steven W. Smith
• Neural Networks for Pattern Recognition, Christopher M. Bishop

• Tracking Musical Beats in Real Time, Paul E. Allen and Roger B. Dannenberg
• A Model for Musical Rhythm, Jeff A. Bilmes
• Autocorrelation and the Study of Musical Expression, Peter Desain, Siebe de Vos
• A Beat Tracking System for Audio Signals, Simon Dixon
• Prediction-Driven Computational Auditory Scene Analysis for Dense Sound Mixtures, Daniel P. W. Ellis
• A Similarity Measure for Automatic Audio Classification, Jonathan Foote
• Representing Rhythmic Patterns in a Network of Oscillators, Michael Gasser and Douglas Eck
• Adaptive Signal Models: Theory, Algorithms, and Audio Applications, Michael Mark Goodwin
• Recognition of Music Types, Hagen Soltau, Tanja Schultz, Martin Westphal, Alex Waibel
• Irrelevant Features and the Subset Selection Problem, George H. John, Ron Kohavi, Karl Pfleger
• Beat tracking with a nonlinear oscilator, Edward W. Large
• Modeling beat perception with a nonlinear oscilator, Edward W. Large
• Automatic Transcription of Simple Polyphonic Music: Robust Front End Processing, Keith D. Martin
• Musical instrument identification: A pattern-recognition approach, Keith D. Martin and Youngmoo E. Kim
• Music Content Analysis through Models of Audition, Keith D. Martin, Eric D. Scheirer, Barry L. Vercoe
• Musical Sound Information: Musical gestures and embedding synthesis, Eric Metois
• A Machine Learning Approach to Musical Style Recognition, Roger B. Dannenberg, Belinda Thom, and David Watson
• Resonanc e and the perception of musical meter, Large, E. W., & Kolen, J. F.
• Music-Listening Systems, Eric D. Scheirer
• Tempo and beat analysis of acoustic musical signals, Eric D. Scheirer
• Content-Based Classification, Search, and Retrieval of Audio, Erling Wold, Thom Blum, Douglas Keislar, James Wheaton
• Classification, Search, and Retrieval of Audio, Erling Wold, Thom Blum, Douglas Keislar, James Wheaton

Check out Beck's Extreme Programming. In it, he describes a highly interative approach to design and coding. I, too, have experienced coding blocks and my approach is to go ahead with whatever design I have and code what I can. After it's coded, I can easily see what I should change. I usually cannot see that until I've written something. You will throw away code, maybe even a lot of it, but you're first "released" version will be about your third internal version which makes for a much more solid release.

Also, I'm NOT suggesting you ignore design. Design what you can - leave those fuzzy areas out for now. They will be much less fuzzy when you start writing the code around them.

YMMV,
-tim

There are a few things wrong with this... 1) Why on earth do you want to volutnatrily give so much power to a company? They don't want it and you're shoving it down their throats. Big Brother as a government is bad enough. But Big Brother as a company? For the most part the demos are capable of pulling down or keeping a government in check when necessary. But what are you going to do to a huge company? Sure Yahoo! isn't huge, but it'd set precedence. 2) Nobody ever had such thoughts about policing cities/states/countries etc. Except within the last few centuries nobody ever "set out" to make a country. And they certainly had no idea of what the hell they were doing. For a better grasp of how large political organizations came about you might want to check out: http://www1.f atbrain.com/asp/bookinfo/bookinfo.asp?theisbn=0393 317552 Guns, Germs and Steel

MySQL's documentation is bad?? I always thought it was pretty good.

Interbase, on the other hand, looks sparse in the documentation department. There are no books available (one old hit at FatBrain that was never published) and I cannot find anything online at www.interbase.com. There is a grassroots effort here but there is no content!

I haven't installed the RPMs yet - anyone know if there is any documentation installed? I hope I don't have to read man pages to administer this thing.

-tim

Great link! I had no idea that Project Gutenberg existed, but I am certainly interested now.

That said, in my defense I linked to the book at fatbrain , and it is the Dover Thrift classic edition for $1. So if you like having a paper copy to bring with you when you are *gasp* away from a computer, and you don't want to wear out your printer, then this just might be worth it ;)

LL

You may not agree with the law or its interpretation, but that's no excuse for breaking it! If you disagree that badly then there are perfectly legal means to protest which are a lot more effective in the long run. This case certainly proves that point.

You might want to read Civil Disobedience by a Mr. Thoreau as to why there are many many people who disagree with you.

LL

It's hard to explain in a paragraph or two why functional programming is so great. Suffice it to say that it allows for much more reuse than object-oriented programming, opens up whole new ways of abstracting out functionality, and prevents one of the most common sources of bugs--aliasing.

Not all functional programming languages are purely functional. In fact, many programmers program in such functional programming languages like they do in Perl or Python. That can be both bad and good. On the one hand, because functional programming languages are powerful even for procedural programming, they may never be encouraged to learn how to take advantage of functional features. On the other hand, it may be a good way of getting work done.

My recommendation for people wanting to use a statically typed, efficient functional programming language would be OCAML. It has a full object system, yet also offers a full set of functional programming primitives. SML/NJ is another excellent implementation supporting both procedural and functional programming, and very lightweight threads (as an alternative to objects; cf. the GUI system).

Scheme and CommonLisp are also great languages. As a procedural or OO programmer, you can think of them as Python with a different syntax and a much better compiler. MzScheme is an excellent Scheme system for learning, and Bigloo is a powerful Scheme compiler. You can find more information at schemers.org.

For heavy-duty programming, CommonLisp is still better than Scheme, IMO, but it's significantly more complex. You can find a bunch of implementations at cons.org. I recommend CMU CommonLisp highly. For experimentation, CLISP by Haible is a good small interpreter. There are also a few "scripting" implementations of CommonLisp around.

Haskell is absolutely amazing for distilling programs down to 1/10 or 1/100 their size. However, it really requires a very different way of approaching programming. I'm not sure whether to recommend starting programming with it or not, in particular if you come from other languages.

There are also some special-purpose functional programming languages for high-performance computing. Those languages give performance similar to Fortran or C on numerical problems and can actually be parallelized more easily.

Of course, whether any of these links help you depends on whether you can get started using a new language with a reference manual, user manual, short tutorial, and implementation. If not, there are lots of textbooks around. The Haskell site in particular also has lost of link for FP-related resources. Also search Fatbrain.

So, in summary: functional programming languages are definitely ready for many applications. If you want to get started, there are lots of resources available. Try to find a book that you like and experiment. MzScheme or OCAML are fairly traditional ways of getting started (you still get a lot of the features you are used to from procedural languages). I suspect that functional programming is going to be the "next big thing" in programming after OOP, and I also think it's a lot more useful than OOP and a lot more well-founded.

People don't naturally think recursively.

That being said, I actually really like functional languages. I had to learn Scheme in first year Computer Science and found it to be quite an interesting experience:

• It introduced me to emacs, whose paren matching and lisp mode saved many, many, many headaches
• It showed that you can build any sort of data structure out of lists
• You can create any loop construct recursively
• Treating functions as regular data, you can do many cool things
• You don't need a complex syntax to do interesting things with a language

People would be challenged by with the problem they were trying to solve, unlike the C/C++ courses of later years where cries of "Why wont this compile" were oh so common. It's difficult to think why someone would have trouble programming in C now that we've been doing for so many years, but think back to those Comp Sci days and it's obvious that simple, functional languages allowed the profs to teach computer science and not language syntax.

I've been meaning to learn LISP again due to that elegant simplicity that I miss about comp sci. If you're interesting, check out the Structure and Interpretation of Computer Programs. If you've ever wondered what you can do with LISP, this is the book to read.

You're exactly right. For a good synopsis on why it is impossible for the immune system to detect every single cancer, or for that matter to detect every single harmful infectuous invader, read GEB.

http://www1.fatbrain.com/asp/bookinfo/bookinfo.asp ?theisbn=0465039138&from=bbookbuy

You can do some searches on google.com, etc, to find some articles he's written... there should be plenty that turn up... The book is really good though.

The Risks forum should be read by:

• Anyone who uses or depends on computers in their daily lives
• Anyone who programs computers
• Anyone who makes policy decisions involving computers or software
• Anyone who ever depends on the correct functioning of computers for their lives or safety (flown on a modern airplane lately?)
• Anyone who operates computers that affect safety (piloted one?)

You might think such spy stuff as this article is about is out of your realm, but consider this example which likely could have affected most of us:

The scary MSWord residue feature

I recently received a legal document as part of a personal negotiation that I am doing. The document was e-mailed to me in MSWord format. As I was showing it to my lawyer (who happens to be my wife), we decided to put our thoughts inline using the track changes feature of word. After selecting Tools, and Track Changes, we clicked on "Highlight changes in document" and voila, suddenly a whole bunch of red appeared on the screen. We looked at it closely and realized that everything in red represented changes in the document that my counterpart's lawyer had written. We got a good look at the previous version of the contract, as well as a bunch of comments and justifications that the lawyer wrote to his client. It was an eye opening experience.

It appears that instead of selecting "Accept all changes" before sending it to me, the other party to the contract simply turned off the highlighting to the track changes feature.

This is obviously a case of an unsophisticated person misusing a feature. However, it is very dangerous. Lawyers send word documents around all the time, and many of them do not really understand all the features that they use, nor should they have to. I imagine that I was not the first person to see some behind the scenes conversation in an important word document, that I was never intended to see.

• http://www.fatbrain.com
• http://www.barnesandnoble.com
• http://www.amazon.com
• http://www.chapters.ca - in Canada

How in the world did IBM, famous for its entrenched monopolist corporate culture, manage to turn itself around so quickly and fundamentally?

The FreeDOS Kernel is a book about the way the GNU FreeDOS Kernel is designed.

Of course, you can just skip the book and look at code. You can get a free Unix source license for some older stuff at SCO (not x86) or just download a Linux kernel (for the x86)

One of my favourite books about OS design: Inside the IBM PC, by Peter Norton. It's been through many, many editions, and some of the older ones are very detailed about the inner workings of DOS.

Just in general, look at used book stores or the library. You can find some very interesting old books. I seem to remember an old book put out by MS Press, Inside OS/2 or some such, that was pretty good.

Unlike so many books that focus on how to use UNIX, The UNIX Philosophy concentrates on answering the question, "Why use UNIX in the first place?"

When speaking about how likely there are to be intelligent civilizations, people often refer to the Drake Equation. Carl Sagan thought that the equation showed that there should be a significant number of civilizations. Although a recent book, Rare Earth has called into question how probable civilizations are.

This is good news, though, adding a bit to the likelihood of their being other civilizations out there somewhere.

Well, if you can afford more like $9 (or cheaper through some discount places like FatBrain), you might consider my forthcoming book (from O'Reilly) the C VS Pocket Reference. Of course, I'm biased, since I'm the author. And, the book is a reference rather than a tutorial, although it does have some basic "primer" type material in the introduction.

Well, if you can afford more like $9 (or cheaper through some discount places like FatBrain), you might consider my forthcoming book (from O'Reilly) the C VS Pocket Reference. Of course, I'm biased, since I'm the author. And, the book is a reference rather than a tutorial, although it does have some basic "primer" type material in the introduction.

If you're a computer user, you need to read The Forum on Risks to the Public in Computer and Related Systems, available on the web at http://catless.ncl.ac.uk/Risks/ on on the Usenet news as comp.risks

The Risks forum is part of the ACM Committee on Computers and Public Policy.

You should make a special effort to read Risks if you:

• Program computers
• Make policy decisions involving computers (managers, government etc.)
• Depend on computers for your life or safety (do you fly on airplanes?)
• Operate computers in situations where they affect life or safety

USS Yorktown dead in water after divide by zero

The Navy got rid of its more robust warship operating systems and replaced them with Windows NT. As a result of this, when a sailor typed a "0" in a data entry field, the whole shipboard network went down and the proud Yorktown had to be towed back into port.

Security concerns, viruses and the like are discussed extensively in Risks.

Do you use Microsoft Word on Mac or Windows? Do you use it to type confidential documents? Consider this post from a fellow who received a contract from an attorney in Word format:

The scary MSWord residue feature

I recently received a legal document as part of a personal negotiation that I am doing. The document was e-mailed to me in MSWord format. As I was showing it to my lawyer (who happens to be my wife), we decided to put our thoughts inline using the track changes feature of word. After selecting Tools, and Track Changes, we clicked on "Highlight changes in document" and voila, suddenly a whole bunch of red appeared on the screen. We looked at it closely and realized that everything in red represented changes in the document that my counterpart's lawyer had written.

We got a good look at the previous version of the contract, as well as a bunch of comments and justifications that the lawyer wrote to his client. It was an eye opening experience. It appears that instead of selecting "Accept all changes" before sending it to me, the other party to the contract simply turned off the highlighting to the track changes feature.

This is obviously a case of an unsophisticated person misusing a feature. However, it is very dangerous. Lawyers send word documents around all the time, and many of them do not really understand all the features that they use, nor should they have to. I imagine that I was not the first person to see some behind the scenes conversation in an important word document, that I was never intended to see.

New HDTV signal shuts down Baylor heart monitors

On 26 Feb 1998, WFAA TV (Channel 8) in Dallas turned on their new digital HDTV signal. As a result, 12 heart monitors stopped working in a Baylor University Medical Center heart surgery recovery unit; they happened to be on the same frequency. The monitors were made in the mid-1980s, and were slated for replacement. [But the patients weren't?] In the interim, WFAA has stopped transmitting -- because there are no commercial receivers yet anyway. [Source: * Dallas Morning News*, 5 Mar 1998. PGN Abstracting]

It has ISBN 020155805X and you can purchase it online from:

• http://www.fatbrain.com
• http://www.barnesandnoble.com
• http://www.amazon.com
• http://www.chapters.ca - in Canada

Mike

Tilting at Windmills for a Better Tomorrow