Slashdot Mirror

Someone mentioned that you were using the mistaken 'communist == Soviet Union' equivalence. If you want a very interesting take on the differences between communism and capitalism and how they might apply in a world of nanofacturing, read "" by Ken MacLeod. Excellent book with a very European slant on politics.

Why do you consider programming to be something other than art? Sure, a non-programmer may not be able to appreciate the code in raw form, but even a layman can appreciate an intuitive, well-written interface or an efficient-running program.

No matter what field you're in, be it Programming, Painting, Architecture or Demolitions, there is beauty and art to be found. If you ever get a chance to watch a demolitions crew topple a tall building, go see it. Watching a skyscraper coming down is a sight to behold. The fact that the moment is gone when the dust clears doesn't change the fact that it's art.

If you are one that likes to burrow into code, make sure to check out the code for Ogg Vorbis. I don't understand most of the math behind the encoding algorithm, but the structure is beautiful and easy to understand. This code was definitely written by artists. The code for the Apache Foundation's Xerxes XML is another project that I would consider to be great art.

Those who judge programming and art by seperate measures need to go back and read their Zen. It may all come down to differences in the definition of 'art', but I'll always shake my head when someone claims there's something that falls outside the scope of what can be considered art.


Seth

People used to think the world was flat. As it turned out, the best way to teach people the world was round was not mass re-education, but by showing them that if you kept sailing, you wouldn't fall off. Nobody (except a scarce few) believes the world is flat anymore.

There are very, very few examples of societies, regardless of how ancient, that believed the world to be flat. Humans have known the world was round pretty well since they started writing such things down. The idea of people who thought the world was flat was actually circulated during the 19th century, as the result of an ignorant schoolbook publisher.

You don't have to take my word for it. Go to your library and read Jeffrey B. Russell's "Inventing the Flat Earth: Columbus and Modern Historians"

Go to Neumann's page above and search for "Robust" using the "Find in Page" function of your browser.

Neumann is the moderator of The Forum on Risks to the Public in Computers and Related Systems and the author of the book Computer Related Risks, so he should know whereof he speaks.

Please also read Open Source and These United States.

In the previous article, someone suggested the problem of how to compose a letter to congressional representatives to promote open source - perhaps simply printing out that paper and mailing it to them with a brief cover letter explaining how you've found a way the U.S. Government and Military can achieve substantial savings in its software purchases, along with gains in reliability, would be helpful.

Mike

I hate ignorance. Listen, I am not trolling, please trust me.

The concept used in "The Matrix" the movie is not new or original, but it makes a good point. Its based around solipsism - the realization that you cannot know anything outside of your mind. With a little contemplation, you can see that you accept the theories of science on faith alone. Physics is just man's use of his mental concepts (mathematical concepts) to describe the world. If infinity is not mathematical, then the claim that its use in physics justifies it is naive at best.

Stop. Think. How do you know? Ask yourself that. Ask yourself, "What is the foundation of mathematics?" Many men have, and could not answer. Some chose faith, while others choose to understand, to know.

If you are confused, then let me help you, since your schools could not:
Constructive Mathematics
Intuitionism
From Brouwer to Hilbert : The Debate on the Foundations of Mathematics in the 1920s
Trust me, you are confused. Many people are. They have accepted mathematics on faith alone, but you do not have to. The way to understand is easy! I highly recommend checking out/buying the book From Brouwer to Hilbert to truely understand what Intuitionism is. The book consists of a series of papers which carried on a drawn out arguement about the foundations of mathematics. These weren't joe blows arguing. These are arguements of legendary mathematicians, so there is some serious insight in their work that I cannot give you. Finally, the papers in that book are strung together through use narrative of the editors. Its a great buy and you will not regret it.

Now, when you are done checking out all of those links and the book, if you really want to know more, then check out "Brouwer's Collected Works". Its a two volume set. The books are big and out of print, so ask your library. Its worth it.

I hate ignorance. Listen, I am not trolling, please trust me.

The concept used in "The Matrix" the movie is not new or original, but it makes a good point. Its based around solipsism - the realization that you cannot know anything outside of your mind. With a little contemplation, you can see that you accept the theories of science on faith alone. Physics is just man's use of his mental concepts (mathematical concepts) to describe the world. If infinity is not mathematical, then the claim that its use in physics justifies it is naive at best.

Stop. Think. How do you know? Ask yourself that. Ask yourself, "What is the foundation of mathematics?" Many men have, and could not answer. Some chose faith, while others choose to understand, to know.

If you are confused, then let me help you, since your schools could not:
Constructive Mathematics
Intuitionism
From Brouwer to Hilbert : The Debate on the Foundations of Mathematics in the 1920s
Trust me, you are confused. Many people are. They have accepted mathematics on faith alone, but you do not have to. The way to understand is easy! I highly recommend checking out/buying the book From Brouwer to Hilbert to truely understand what Intuitionism is. The book consists of a series of papers which carried on a drawn out arguement about the foundations of mathematics. These weren't joe blows arguing. These are arguements of legendary mathematicians, so there is some serious insight in their work that I cannot give you. Finally, the papers in that book are strung together through use narrative of the editors. Its a great buy and you will not regret it.

Now, when you are done checking out all of those links and the book, if you really want to know more, then check out "Brouwer's Collected Works". Its a two volume set. The books are big and out of print, so ask your library. Its worth it.

This misleading analogy (from a linguist, who should know better) needs to be buried once and for all. That the English word "language" is used to refer to both English and Perl does not make them examples of the same thing. Computer languages control Turing machines; human languages are a very different animal.

this is the bridge pattern applied at the language level. the pattern, as defined by the gang of four:

Decouple an abstraction from its implementation so that the two can vary independently.

from the Eidola front page:

In short, Eidola is a programming language which separates a program's structure from how that structure is presented.

i know i might be stating the obvious to a lot of OOP-savy /.ers, but i had trouble grasping the bridge pattern when i first read it, and wanted to point out this great example.

if you do OOP for a living -- hell, if you're a programmer of any stripe -- i encourage you to read the book.

I agree with you about needing to understand how it works before we can think about its applicability to humanity. But I think it would be fairly trivial to deploy something like this on a large scale. For example, Saturn's Race is a sci-fi book by Niven & Barnes that has a "charitable" corporation donating food and medicines to the third-world. Think about it. Saturn's Race can be found at fatbrian.com.

If a first-world country is your target then think about vaccinnations or "life improvement" pills (e.g., Viagra, Prozac, weight-loss, etc.). For example, in the USA, most kids are required to have certain vaccinnations before they may enter public school.

read this guy's book.

you'll understand his point of view a lot better.

Clearly, you didn't read the book.

Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.

He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.

Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.

So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.

I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.

Clearly, you didn't read the book.

Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.

He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.

Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.

So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.

I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.

Clearly, you didn't read the book.

Beck makes pretty clear that the XP model is not for everybody. He even has a chapter titled When You Shouldn't Try XP.

He also makes many of the same points you make; especially that understanding customer needs is crucial. He goes further to say that the only will way to understand customer needs is to involve them (or, as you say, their representatives) closely in the development process, so that you have lots of feedback.

Because XP has a lot in common with the Evolutionary Delivery lifecycle, it also substantally reduces budget-related risk. Since you are regularly producing high-quality working versions that have successively more features, you always have something to deliver.

So I agree that 'silver bullet' solutions are bad but I disagree that XP is such a solution. It's just a collection of development techniques that are, for the most part, entirely uncontroversial. The only new thing is the emphasis on combining them in a way that they reinforce one another.

I agree that if you have an evil (or willfully clueless) manager, no book will help. But there are a lot of people who manage software projects (or who manage people who manage projects) that are ignorant but willing to learn, especially if it means the difference between success and failure. And for those people, sticking a few books under their noses will help a great deal. For these managers, I give away copies of Rapid Development or The Software Project Survival Guide depending on how technical they are. And if your project is suited to an XP approach, then a book explaining the business case for using XP will help them understand why they should back you, rather then meddling with things they don't get.

I know you just wanted a cheap shot, and hey, this is the audience for it, but I would suggest you read either Writing Solid Code or Code Complete, both published by Microsoft Press, and both supposedly based on internal MS coding practice. They are very good examples of the ways in which you can write easy-to-read, easy-to-debug, easy-to-maintain code.

Regardless of what the front office does and decides as a direction, there are some pretty clever people at Microsoft (not to mention Microsoft Research - Blinn, Kajiya, Gray, and many others).

(of course, feel free to add a more illuminating comment if it wasn't just the usual MS==BAD)

I know you just wanted a cheap shot, and hey, this is the audience for it, but I would suggest you read either Writing Solid Code or Code Complete, both published by Microsoft Press, and both supposedly based on internal MS coding practice. They are very good examples of the ways in which you can write easy-to-read, easy-to-debug, easy-to-maintain code.

Regardless of what the front office does and decides as a direction, there are some pretty clever people at Microsoft (not to mention Microsoft Research - Blinn, Kajiya, Gray, and many others).

(of course, feel free to add a more illuminating comment if it wasn't just the usual MS==BAD)

You understand incorrectly. When buying property the lease has restrictive covenants that bind you to certain responsibilities and obligations. In a CID (common interest development (gated communities, condos, developments, etc.)) leases have covenants that state the property owners agree to abide by the rules of the board. You also agree to pay any judgements or fine levied by the board; failure to do so will constitute a contractual violation (of the lease agreement) that can result in eviction. Part of these restrictive covenants is a clause that they must be passed on to any later purchasers of the property, so someone buying it will have to follow the board rules as well. These have been tested in court many times, and people have lost propery and have been forced to pay fines. A good book that talks about the history of CID's the laws that apply to them, and their implications for public and private society is Privatopia by Evan McKenzie.

I didn't really know how to program, I knew a little FORTRAN, C and Basic from doing data analysis during summer jobs, and I didn't really like it all that much. I used to really have to struggle to spend several weeks writing a 500 line program, and I'm sure I'd be embarrassed if I had to look at the source code to those programs today.

I figured I'd program for a while because it paid the rent (I was making $20k a year doing Sun administration and writing image processing software), but when I figured out what I really wanted to do for a living I'd quit programming and get a real job.

That was in 1988. Then some consultant visited and installed GNU Emacs on our machines (two Sun 3/160's, one diskless, both with terminals and no workstation monitor, but with frame grabber cards and NTSC color monitors). He explained about the GNU manifesto.

I thought it was pretty cool but didn't see it affecting me personally in a big way. I was mostly annoyed that I had to wait up while the consultant installed the software on what was supposed to be my day off while a ladyfriend was visiting from away.

Then my friend Jeff Keller, who went to MIT for a while and vaguely knew Richard Stallman, spent an evening with me singing the praises of Emacs. What I really wanted was VI with macros you could program to include conditional branches, and he said it had all though and much much more.

So I learned to actually use Emacs, and soon learned that it was quite extensible, but it wasn't made too clear how to extend it. The online manual was useful mainly to people who already knew what they were doing.

So I read the source code. One thing I was interested in doing was writing C functions that were callable from Emacs lisp as lisp functions. There are many such functions built into Emacs (usually for performance) and you can add your own. There's this big DEFUN macro that even makes the C API look like Lisp.

I learned that and a lot more. I learned what an eloquent statement of software architecture Emacs is.

I learned that there really was something worth my while doing in the way of software.

I wanted to write a program like that someday. Not another big editor, but a program that would someday strike other young programmers the way Emacs struck me.

During the course of reading the source code, one day I stayed at my terminal 24 hours straight, arising only to get coffee and use the restroom, not even eating. I only realized how much time had passed when I started to fall asleep.

That was when I started to take programming seriously. I began to put serious effort into studying programming, and studying it deeply.

For example I would read Knuth's The Art of Computer Programming on the bus on the way to work and I would stay up all night after work learning to program better on my Macintosh at home.

For many years I selected all of my jobs based mainly on what I could learn from them.

I've become a very skilled programmer. You can see this from my consulting business website, my resume (on my resume the place where I first encountered Emacs is the Programmer job at Verde Technologies) and my programming tips pages.

So in a very direct and profound way I owe it all to Richard Stallman and Emacs.

I still haven't written my great program yet. I don't even know what it will be. One project I've worked on peripherally is the ZooLib cross-platform application framework and a project I've just started up but not gotten too far with yet is the Linux Quality Database.

I did finally get my B.A. in Physics, from UC Santa Cruz, but only after being out of school working at a programmer for a number of years.

Michael D. Crawford
GoingWare Inc

1. the network stack isn't covered
2. it'll be out of date soon

The reviewer's second complaint is even dumber. Since the kernel is a construction based in time (rather than something more eternal), descriptions of it are going to be outdated eventually. As will any other linux book out there, when a new version gets out there. Even the New York Times will be outdated tomorrow. Big fucking deal. The authors are tracking the 2.4 changes for the next version of the book - and they plan to keep a website for the book - so everything should be okay. Plus their notes of what's new in 2.4 should be all you need for the time being.

Sorry to vent, but I hate it when reviewers feel obligated to come up with flaws, just to make it seem like they did a super-penetrating read of the text. If you want to come up with flaws, try reading the book past the introduction. I'm sure you'll find a few legitimate ones at least.

1. the network stack isn't covered
2. it'll be out of date soon

The reviewer's second complaint is even dumber. Since the kernel is a construction based in time (rather than something more eternal), descriptions of it are going to be outdated eventually. As will any other linux book out there, when a new version gets out there. Even the New York Times will be outdated tomorrow. Big fucking deal. The authors are tracking the 2.4 changes for the next version of the book - and they plan to keep a website for the book - so everything should be okay. Plus their notes of what's new in 2.4 should be all you need for the time being.

Sorry to vent, but I hate it when reviewers feel obligated to come up with flaws, just to make it seem like they did a super-penetrating read of the text. If you want to come up with flaws, try reading the book past the introduction. I'm sure you'll find a few legitimate ones at least.

1. the network stack isn't covered
2. it'll be out of date soon

The reviewer's second complaint is even dumber. Since the kernel is a construction based in time (rather than something more eternal), descriptions of it are going to be outdated eventually. As will any other linux book out there, when a new version gets out there. Even the New York Times will be outdated tomorrow. Big fucking deal. The authors are tracking the 2.4 changes for the next version of the book - and they plan to keep a website for the book - so everything should be okay. Plus their notes of what's new in 2.4 should be all you need for the time being.

Sorry to vent, but I hate it when reviewers feel obligated to come up with flaws, just to make it seem like they did a super-penetrating read of the text. If you want to come up with flaws, try reading the book past the introduction. I'm sure you'll find a few legitimate ones at least.

The best book I have read about SJ/NeXT is "Steve Jobs and the Next Big Thing" (out of print, get it from your library). This is the "anti-reality-distortion-field" book, and is very condemning of Jobs as a technician, leader, and businessman. While this book is very informative and well-written from these perspectives, it misses a very important perspective.

Those who condemn Jobs as a charlatan and a showman should try considering him from the perspective of someone whose ultimate goal is to make a serious impact on how people look at things, which is typically the role of the "artist" in a society. While Picasso was a bastard of a human being and made plenty of self-indulgent crap as well as revolutionary art, he deserves recognition for introducing powerful and influential new ideas to the culture at large.

So, I think that being the leading "artist for the computer world" is what Jobs is ultimately most interested in, much more so than any particular bottom-line, technical, or political goal regarding computers (though it obviously galls him that the role of "most influential" is not that same as "most successful and dominant").

Now, if someone wrote an analysis of Jobs' performance as an influence on society's changing attitudes and conceptions of computers and computing, I'd buy the book. Of course, the recent "gold rush" mentality has the entire computing community focused on $ and world domination, so I don't see anything not of that perspective coming soon.

Yes, this is the list you can submit your name and address to indicate that you don't want to receive unsolicited commercial postal mail. And to some extent it will cut down on certain types of regular junk mail.

But my old boss at Working Software, Dave Johnson, who wrote the chapter on direct mail in The High-Tech Marketing Companion, says that the Mail Preference Service has the very highest response rate of all - for certain kinds of product offers.

(For a long period of time Working Software made most of its sales through direct mail, and Dave became quite an expert on direct mail. This was after he nearly went bankrupt listening to "channel people".)

What kind of product offers sell through this list?

Studded dog collars, burglar alarms, personal security devices, gun magazines and in general products that are aimed at people who are concerned with personal security and just want to be left alone.

Being on the DMA opt-out list doesn't actually prevent you from receiving mail. Instead, members who care to bother (usually because they don't want to waste money sending mail to people who won't respond) get the list periodically and use it to prune their in-house lists. So for lists whose owners bother to go to the trouble, you will be taken off some lists.

But studded dog-collar vendors just take the list and print up mailing labels!

Michael D. Crawford
GoingWare Inc

... it's been around (and used successfully) for over fifteen years?

As Jim Coplien has pointed out, OO (objected oriented programming / design / analysis) is older today than "structured" programming / design / analysis was when OO first burst upon the scene. (The structured movement first got some serious press in the mid to late 1960s; the classic book by Dahl, Dijkstra, and Hoare was published in 1972. OO started no later than Simula-67 and Smalltalk-72, and first gathered mainstream attention in the 1980 - 1982 timeframe. The first OOPSLA conference was in 1986.)

Yes, some snake-oil salesmen overhype OO ... or whatever buzzword they can apply to their product. Surprise.

No, OO is not a panacea. It's not even always the right tool to apply to a particular design or programming problem. (Coplien's recent book, Multi-Paradigm Design for C++ , is a tough but worthwhile read that addresses this issue.)

You may dislike a particular language that supports OO (Smalltalk, C++, Java, even Perl) but find the paradigm worthwhile in some other language.

For comparison, compare with this message in Risks Digest: "The structured programming revolution is a real bad idea that has been significantly holding back progress for years.... Have there been any double blind studies which unambiguously show that the kind of programs that structured programming partisans enjoy are really more maintainable than some other kind of program? I've heard lots of testimonials, but no real evidence." Sound kind of familiar? (Heh.) --PSRC

A good helping of Howard Zinn's fantastic A People's History of the United States would do this discussion (and most Americans for that matter) a lot of good. It describes how those documents were created for the benefit of the wealthy, to protect them and their fortunes. The corporation just happens to be the best means for accumulating wealth these days. Frankly, we're better off now that many of of the countries more barbaric practices have been eliminated.

Think UNIX by Jon Lasser is one of the best books on this subject. The book is geared toward Windows people who want to learn UNIX.

It not only shows individual commands, but it also explains why UNIX does things this way. It is a very generic UNIX book (would be useful for Linux to Solaris to FreeBSD to AIX).

For any programmer/team that wants to get a handle on how they do things, how long they take, where the defects come from and where they are found, there's probably no better beginning that the techniques of Watts S. Humphreys, starting with Introduction to the Personal Software Process. I like the price at FatBrain.

called Inside Out : Microsoft--In Our Own Words with fascinating tid bits of trivia like, "One rule I've learned in this business is that you cannot be successful in marketing a bad product.", from Brad Chase, a brief history of Bob, and best of all, "There's a little debate that swirls endlessly out there and it goes something like this: Is Microsoft a great software company or a great marketing company? The answer, of course, is both." (TeeHee)

Cal Poly SLO's CSC department uses the 2.0 Linux kernel for our OS classes.

Why use 2.0 and not something bleeding edge? Documentation and commentaries are more available for the 2.0 series. We used David A Rusling's The Linux Kernel online book, Linux Kernel Internals edited by Michael Beck and Tanenbaum's Modern Operating Systems.

Cal Poly SLO's CSC department uses the 2.0 Linux kernel for our OS classes.

Why use 2.0 and not something bleeding edge? Documentation and commentaries are more available for the 2.0 series. We used David A Rusling's The Linux Kernel online book, Linux Kernel Internals edited by Michael Beck and Tanenbaum's Modern Operating Systems.

What, you're ever at a computer without access to TMMM!? :-)

Brooks does mention two mice, but has no pointers to further info. In Chapter 19 (pp. 261--262 in my A-W softcover edition), the section ``Command utterances and the two-cursor problem'' discusses how most commands consist of a verb and a noun---action and object---and how convenient it would be to use two cursors to simultaneously select each. The notes for that chapter are prefaced with ``Material quoted without citation is from personal communications.'' The note from that subsection, says in its entirety:

7. It appears the Apple Desk Top Bus could handle two mice electronically, but the operating system provides no such function.

If you haven't read this book, do so now. If you wonder why, you might check some reviews:

• A collection of reviews at Softpanorama.org. Covers more than just TMMM. Well worth checking out. The general site looks very interesting, too.
• /.'s own review. If anything, understated.
• Ed Yourdon's brief commentary, with an interesting sidelight on how the book got updated.
• Fatbrain.com's sales page $25
• Bookpool.com's sales page $24

Probably Guns, Germs, and Steel.
--
Bush's assertion: there ought to be limits to freedom

I recommend that anyone whose knee-jerk reaction is to flame the above post to read The Transparent Society, by David Brin. It's great book, and unless you're dense as a brick, it will challenge your assumptions on privacy, anonymity, and the role of the citizen on keeping his government and fellow citizens honest.
--
Bush's assertion: there ought to be limits to freedom

You may know TCP/IP fairly well, but you don't know cryptography very well. It is possible for two parties to agree on a common random value without exchanging that value. This is the basic idea put forth in the Diffie-Hellman Key Exchange. Once you have a random number known to the two parties trying to communicate and no one else, you can use that number as an address to route the packets through the network. I don't know if this is what the research group has in mind but it is a possibility. Yes, there are some problems with this system, in particular the initial key exchange is not anonymous, but this makes it much harder to trace the actually data transfer.

The other thing too keep in mind is this: no matter what protocol you're using over the Internet, you can find out where the packets are coming from and going to. This includes ssh (Secure Shell), tunneling, normal TCP/UDP connections and even spoofed packets. This is done by running sniffers on each interface on a router (starting with the target that's being DoSed or whatever) and seeing which interface these packets came in on. You find out what that interface is connected to and start sniffing there. Repeat this process enough times, and you'll find out the source and destination of any packet.

In theory this will work, but once you cross an administrative domain, i.e. from one ISP's network to another ISP's network, you will find that they are so willing to co-operate. Read Cliff Stoll's Cuckoo's Egg for a real world example. It took him over two years to track someone, not because of technical problems, but because of adminstrative problems.

A company I used to work for had three different operating units with three different data centers in one building. To set up sniffers on the networks took two weeks of meeting and getting sign-off from data-center managers, since the managers didn't want their networks touched unless it was to fix a production problem in their network.

The book (or at least its subject) has been made into a 1998 episode of NOVA (here is the Internet Movie Database entry; there's also a transcript on the PBS Web site), and a made-for-TV movie (starring Jeremey Irons) by A&E.

(Sorry for my previous erroneous post. There have been books made from NOVA episodes; I believe Simon Singh, author of The Code Book, adapted the 1997 episode on Fermat's Theorem into a 1998 book.)

• Steven Bellovin, AT&T
• Matt Blaze, AT&T
• David Farber U of Pennsylvania
• Peter Neumann, SRI International
• Eugene Spafford, Purdue University CERIAS

And Peter Neumann I know very well in an online way, as he is the moderator of the Forum on Risks to the Public in Computers and Related Systems which discusses all kinds of topics in software reliability and security, and provides an ongoing archive of known software bugs.

It is also available on the Usenet News as comp.risks and I consider it required reading for anyone wishing to take themselves seriously as a programmer.

This means you.

Neumann also wrote the book Computer Related Risks which draws on material from the forum but discusses it in more depth.

He is also a frequent consultant to the government and military on computer reliability, security and computer policy as you can see from Neumann's home page.

He writes great puns too, which are often found added to Risks submissions.

Now for my contribution - I'd like to suggest you read my page Why You Should Use Encryption.

This page discusses in a way that I hope is clear, approachable and compelling, why everyone - even your mom, even your kids, should use encryption.

Michael D. Crawford
GoingWare Inc

I really wish they didn't name XML during the hypestorm of HTML. I mean, was XML really designed to be an eXtensible Markup Language? XML is almost never used to markup anything; it seems more of a structured data transfer language. I don't care if the book has a red cover and some dorky looking "guru" on the cover, XML is not just "a better HTML".
</soapbox>

I really wish they didn't name XML during the hypestorm of HTML. I mean, was XML really designed to be an eXtensible Markup Language? XML is almost never used to markup anything; it seems more of a structured data transfer language. I don't care if the book has a red cover and some dorky looking "guru" on the cover, XML is not just "a better HTML".
</soapbox>

I really wish they didn't name XML during the hypestorm of HTML. I mean, was XML really designed to be an eXtensible Markup Language? XML is almost never used to markup anything; it seems more of a structured data transfer language. I don't care if the book has a red cover and some dorky looking "guru" on the cover, XML is not just "a better HTML".
</soapbox>

I really wish they didn't name XML during the hypestorm of HTML. I mean, was XML really designed to be an eXtensible Markup Language? XML is almost never used to markup anything; it seems more of a structured data transfer language. I don't care if the book has a red cover and some dorky looking "guru" on the cover, XML is not just "a better HTML".
</soapbox>

Try The Computer Music Tutorial by Curtis Roads. It should give you a good theoretical background for what you are talking about. Implementation is left as exercise to the reader. Welcome to the world of research.

I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:

If you don't take pride in your work you have no reason to be here.

But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.

And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)

I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.

I spoke about that here just a couple days ago in Self-Training is Vitally Important as part of the discussion on What's the Best Way to Retain Trained Employees?

I also discuss it in my article Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.

Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.

My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.

While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.

A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?

I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.

The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.

At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.

I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.

Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.

My final word in this post is that if you want to get a good start on improving the quality of your work, read the Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks

Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.

Michael D. Crawford
GoingWare Inc

I was close friends with a carpenter when I was younger, and he told me that he arrived at a new job site one day and found the following sign posted at the entrance:

If you don't take pride in your work you have no reason to be here.

But my friend thought it was great and said he wished more construction companies would hold such high standards. It happened that this friend took great pains to always learn new skills, and he spent a great deal of money on tools, and always did his best to always have, not just the right tool for the job, but the most obscure tools right on hand so there'd be no time wasted running to the hardware store or doing it a more difficult way.

And guess what? My friend was consistently among the highest paid carpenters for his level of experience. I haven't spoken to him in years but last I heard he's gone back to school because he wants to be a high-energy physicist. (This same fellow taught himself to program in x86 assembly after he bought a 486. I think it says something about his intellect and style that he chose to program in such a low-level language from the very start because it would be the fastest.)

I believe in having the best tools for the software job too, and by this I mean not the machine - a fast CPU is handy but doesn't help that much; what does help is my personal tools - the skills, experience and insight. To that end I work hard to study and sharpen my skills.

I spoke about that here just a couple days ago in Self-Training is Vitally Important as part of the discussion on What's the Best Way to Retain Trained Employees?

I also discuss it in my article Study Fundamentals Not APIs, OSes, or Tools. The gist of that article is that while you must study particular apis or tools to get work done, you shouldn't concentrate on or dive deeply into them but work to improve basic skills that will serve you well on any job.

Perhaps one of the problems these days is the overemphasis on APIs and the lack of emphasis on the basics, like good coding style and efficiency. Two people who know a given API equally well will get dramatically different results if one of them is well-grounded in algorithm analysis as well as having a good understanding of how computers actually work.

My comment about assembly code wasn't meant to say we should all start implementing our products in it. Rather, we should all learn and write some, and do some work with hand-tuning assembly code so that we have a good grasp of what the computer is doing when we write higher level code. Two books that discuss this pretty well are Gary Kacmarcik's Optimizing PowerPC Code and Michael L. Schmit's Pentium Processor Optimization Tools.

While they emphasize assembly code they should give you enough insight into the actual functioning of your computer that it should make your higher-level programming more efficient. And I do mean to say that your overall code will be more efficient on any processor, not that you should hand-tune it for one particular processor at the expense of another as someone here suggested would be the result.

A lot of people in this thread say the reason things have gotten so bad is because of pressure from marketing, management, clients or customers to add features and ship in a hurry. Yes, I acknowledge that such pressure exists and while they share responsibility you cannot blame them because that is their nature, much like the alligator who ate the frog after offering it a ride across the stream. (Frog? But frogs can swim)?

I've been in this business 13 years and there has always been marketing pressure but code quality has not always been so bad.

The quality and efficiency of your product is ultimately your responsibility as an architect and implementor. This is the case whether you're working in a well-funded dot-com or you're writing free software when you get the spare time.

At every step of the way in your software development process, you make choices. All too often we (and I do include myself) take the easy way out and write bad or inefficient code. It is a far better life to live if we strive for excellence in our products, and to do so we must strive for excellence with every choice we make in our software development.

I hope very much for the success of Linux and Free Software in general, but I think that it suffers overall from a severe quality problem. You may find this tolerable because you are a developer, but I'm a developer who has used lots of systems and personally I think Linux sucks as a development environment. It is no where near where it could be taken seriously as a desktop environment.

Now before you curse me for criticising, you should know that I run Linux on two Pentium III machines (Slackware) and I'm going to add LinuxPPC to my Mac soon. This is, in part, because I want to work to make it better. But part of the way I am going to work to make it better, isn't just fixing things directly but also advocating that everyone should take responsibility for their code and make it the very best that it can be.

My final word in this post is that if you want to get a good start on improving the quality of your work, read the Forum on Risks to the Public in Computers and Related Systems also available on the Usenet News as comp.risks

Risks is a very well-moderated list that is frequented by some very serious and experienced experts on computer reliability, safety, fault-tolerance and public policy. But it is also often funny as your just as likely to see the latest UI bug in Word next to a problem with the control system in some nuclear power plant. It will give you a great deal more respect for the problems with computer code but there is also a great deal of discussion as to what can be done about it.

Michael D. Crawford
GoingWare Inc

Am I the only one that thinks that this guy may be a little biased? His email address is an untypable lambda-expression, which has questionable logical meaning ;-)

Ok, actually, I agree with you, Tom. Turing machines are clumsy ways to view computation. The lambda calculus is nice, but it is awkward, whenever you are thinking about heterarchical computational problems (like graph algorithms). However, for heirarchical computational problems, the lambda-calculus works like a charm.

May I suggest an even better formalization of computation: The Fusion Calculus, which is related to Robin Milner's pi-calculus.

The pi-calculus is the result of Robin Milner's work, which he started after initially completing ML back in the late 70s and early 80s. Back then, Milner could see how the lambda-calculus was inadequate, as the foudation of a general purpose programming language.

The most interesting aspect of the lambda-calculus is the Curry-Howard isomorphism, which equated a program with a proof in intuitionistic logic (Brouwer Logic). To make a long story short, the lambda-calculus is sequential in computational nature, and in a way, the Brouwer Logic is a sequential form of proof. Here is the best part!!! Variations of the pi-calculus are showing a similar isomorphism with a newer kind of logic: Girard's Classical Linear Logic. Classical Linear Logic is a parrallel, constructive logic, which can encode Brouwer logic proofs. So we are begining to see that the pi-calculus and Linear Logic are generalizations of the lambda-calculus and Brouwer Logic.

Tom, and anyone else, if you want to learn more about the pi-calculus, then I suggest Robin Milner's new book

Same book available from fatbrain.

Same book for less money at Barnes and Noble.

I must say I'm a little surprised to see such an obvious shill for amazon.com on /. -- especially since their price of $29.95 bites, compared the BN price of $22.75. For $30 you can this book from any number of other online book retailers.

• Linux in a Nutshell
• Red Hat Linux System Administration Guide

If anyone does come up with a course for Linux that's available please let me know.

---

This was in either late '95 or early '96 - but the IBM work on this had been around for a while by the time I read the paper.

This technology is widely available now - read all the way to the end to see how you can try it out.

If you have a jump to a certain offset in a routine, you can move the code where you jump to elsewhere in the file and change the offset you give in the jump. Complicated, because you need to parse RISC machine code, but doable.

It's made a little easier by PowerPC instructions always being fixed at 32 bits with no extension words (a side effect of that is that there's no way to load a 32-bit constant into a register with a single instruction, which makes it hard to scan machine code by eye for constants in an assembly debugger.)

This has the effect of speeding up the overall program execution because you group frequently used code blocks together in the executable file, and also in memory once it's loaded. You may find less-commonly used branches of an if-statement put miles away at the end of the file, so that you jump a long ways away and then back in sometimes, but this isn't a big deal because all the frequent cases flow straight along.

The reason this is a big win is twofold. First, you reduce virtual memory paging and the code resident in physical memory because less commonly used code is all grouped together and just sits idly paged out on disk; that which is taking up valuable physical RAM is of a minimum size and being used actively.

Also (and more importantly in small programs, and in CPU-bound cases), you make more effective use of your processor's code cache.

This is because jumping over an uncommonly used branch may load a few unused instructions into the cache at the beginning and end of the branch that's not taken - cache lines (blocks) are of a fixed size and are always aligned by the cache block size, so if you have 32 byte cache lines then the start of any cached code falls at a physical address that is divisible by 32.

If you run even one instruction into the address rangle, you load 32 whole bytes of code into the cache, deleting 32 bytes of code that might be useful later, then if your code is not optimized this way you'll just end up jumping over most of it.

Many people who are trying to make their programs run faster would benefit from knowing more about how the cache works. Gary Kacmarcik's Optimizing PowerPC Code has a good discussion of this that will benefit anyone who programs on modern microprocessors - not just PowerPCs. And while Kacmarcik emphasizes PowerPC assembly, most of the benefit of improving cache use you can do from C, C++ or another higher level language.

The way the profiler works is that an interrupt-driven task is used to check the instruction counter at frequent but random intervals. The samples are saved to a file for later analysis, then a postprocessor makes a histogram which gives the number of samples per basic block of instructions.

(A basic block, essentially, is any code that falls between a pair of curly braces if it came from original C source code. It's more complicated than that in practice but basically it's a chunk of machine code that has one entry point and one exit. It's possible to analyize machine code with a program and divvy it up into basic blocks.)

Then basically what you do is sort the machine code, with the most frequently used basic blocks coming earlier in the file.

Note that the profiling process depends necessarily on the use to which the program is put during the sampling. For best results, you might actually want to prepare several seperate binaries of the same program, each optimized for a different purpose. Or you might want to construct test data or a test script that gives you a good overall average performance.

Now, how do you get this tool? It's more than just theory. It's available for IBM RS-6000's, although I don't remember what they call it.

But if you can spare the cash for an iMac you can get it included with the Macintosh Programmer's Workshop - MPW. The particular tool that's used for this is called MrPlus, which is discussed in Apple's Technote 1174 and Technote 1066

I believe a variant of this is available in the Metrowerks Codewarrior development environment for PowerPC (CodeWarrior also supports Windows, Linux via GCC and lots of embedded systems but I believe the code reordering is only available for PowerPC).

CodeWarrior provides both an IDE (on Windows there's a choice of MDI user interface or Mac style with a global menu bar and free windows, which makes me much happier when I program on Windows) and it also provides command line tools, including the entirety of MPW with mwcc preinstalled so you can do "make" style builds on the MacOS (but with a weird makefile syntax). I don't seem to find any mention of this on Metrowerks' website. I'll ask their friendly support guy if I'm correct about this.

Perhaps you're lusting over using this for Linux. It would certainly be interesting to try using this on the kernel - build the kernel, boot the machine off it, run it for a while under a normal load while you run the instruction pointer sampler, then reorder the instructions in the kernel and boot off the new kernel and you run faster!

This would probably be easiest to do on PowerPC Linux given the availability of published information from IBM and Apple about it, but I don't see why you couldn't do it for any instruction set. Some would just be harder to parse or rearrange correctly than others.

Stop drooling and start studying.

Michael D. Crawford
GoingWare Inc

I attended the Virtual Observatories of the Future conference this past summer and would like to note that:

• Jim Gray has been collabortaing with the astronomical data community for some time.
• The spacial-indexing schemes Jim helped develop for Terraserver will be key to performant queries for a Virtual Observatory
• Jim Gray was well-known in the database community as the guru of pe rforman ce metrics, long before joining Microsoft

The take-home lesson from the Virtual Observatories conference was that the amount of data required to do science with a "virtual observatory" leads to interesting problems in computer science, problems which are only tractable when analyzed by collaborations between statisticians, computer science people, and the astronomers themselves.

Finally, note that this year's historic increase in the National Science Foundation budget is largely due to the new Information Technology Research Initiative. The need for new methods of data managment in the sciences is real.

Sorry for the cut and paste error on the URL:

Feenberg's Books

Also check out the SPT (Which has a decent links section, too)

While I love the Bay Area (let take a moment to point out that San Francisco, not Silicon Valley, is the cultural and intellectual center of the region - the digerati of the Valley mostly live and almost all party in SF), and am in the eyes of many qualified to be a technocrat myself, I must say that this cheerleading and propagandizing for the leaders of the "technoculture" really does underline how irrational and cultish this supposedly rationalist society really is.

This includes not only blindly uncritical social science theses (a bizarre reversal of the "noble savage" trend in favor of techno libertarianism as the guiding ideal of (unattainable) utopian perfection)... my irritation also extends to the followers of the cults of personality which have sprung up around people like Linus Torvalds and Bill Gates. For such a supposedly libertarian community, there certainly is an awful lot of idol worship in the Open Source and Internet worlds.

By painting our culture with these mythological overtones we can conveniently cast issues, and ourselves, in unrealistic, broad strokes and self-congratulatory rants about our positions in the fights between good and evil - which are entertaining for /. postings but do little to achieve real dialogue.

For the most part is irrational, and it is not wise for technologists to get into the habit of not rationally questioning their work. Cultish, unquestioning devotion to ideas (or technologies, or products) stifles creativity and innovation, and can promote lousy, even dangerous, ideas and technologies over reasonable and better alternatives. (Feel free to Microsoftie-bash here, but this is far from the only case...) It also promotes a culture in which those who do not uphold some status-quo are marginalized, and this can be seen increasingly in the "religious wars" about OSes, programming languages, browsers, even games...

Rather than patting ourselves on the back about a new, irrational system of devotion, we should be wondering why we can't advance past these archaic notions of fundamentalism and how we can expect to trust ourselves with powerful new technologies when we can't shake old patterns of irrational behavior.

Even the notion of promoting the techno "way of life" over all else is divisive, and promotes an attitude where all technology is unquestioningly considered "better" than whatever was before and anyone who dares question this is a "neo luddite"

It is part of a familiar, and insidious, pattern of behavior which keeps the powerful entrenched, builds a separate status for a priesthood which can choose between doing the bidding of the leadership or being cast to the confused and "left behind" polity as sorcerers of evil intent... in short, it is no good for anyone, except maybe the very powerful and the very mercenary...

There are lots of good things about the "techno revolution" but religious devotion to technobaubles, technocratic ideology, and various new party lines are not them... If you want to read a serious and interesting discussion of the subersive nature of the techno revolution and how it can be seen philosophically as a means to oppose entrenched power structures, I highly recommend the works of Andrew Feenberg

Kevin Anderson, on the other hand, is just not that good a writer, and neither is Brian Herbert. I have read a few of the solo books of both and can confidently say that I have no interest in reading anything they collaborate on. Sudanna, Sudanna, for example, was amusing, but eminently forgettable. Blindfold was an easier read, but a very generic piece of sci-fi. Of course the people who wrote reviews at Amazon loved them.

Personally I think Candle by John Barnes (which was sort of reviewed here last week) was better than anything by either of these two authors, and Barnes might have the potential to be as much of a classic in his time as Frank Herbert is.