Sven C. Koehler has started to read "Numerical Methods for Scientists and Engineers". He was so kind to send me a few quotes he likes from the introduction.

 Most books on computing stress the estimation of roundoff,
 especially the bounding of roundoff, but we shall concentrate
 on the avoidance of roundoff.  It seems better to avoid roundoff
 than to estimate what did not have to occur if common sense and
 few simple rules had been followed before the problem was put on
 the machine.

 Another standard algorithmic problem both in mathematics and in the use
 of computation to solve problems is the solution of simultaneous linear
 equations.  Unfortunately much of what is commonly taught is usually not
 relevant to the problem as it occurs in practice; nor is any completely
 statisfactory method of solution known at present.  Because the solution
 of simultaneous linear equations is so often a standard library package
 supplied by the computing center and because the corresponding
 description is so often misleading, it is necessary to discuss the
 limitations (and often the plain foolishness) of the method used by the
 package.  Thus it is necessary to examine carefully the obvious flaws and
 limitations, rather than pretending they do not exist.

update: (sorry, German only;) A big thanks to Sven C. Koehler for this summary

 Ich habe es nun in den groessten Teilen ueberflogen.  Die Ideen sind nicht
 wirklich neu: Umformen von Gleichungen, Vermeiden ungefaehr gleichgrosse
 Zahlen von einander abzuziehen, Approximation.  Beim Loesen von
 Gleichungssystemen schlägt er z.B. vor, ein Verfahren einzusetzen, das
 kein wiederholtes Dividieren benoetigt, dann wird's auch nicht ungenau.
 Trotzdem mag ich das Buch, weil es in mir den Eindruck weckt, dass es
 sehr fundiert ist.  Es ist voll von mathematischen Formeln, die ich alle
 nicht wirklich verstanden habe, aber ich werde in jedem Fall wieder darin
 nach Erklaerungen suchen, wenn ich mal wieder ein Numerik-Problem habe.

 Ich glaube für dich ist as Buch eher langweilig, das meiste kennst du
 bestimmt aus dem Studium. :-)

The bootdisk supports standard (dual)IDE controllers, and most SCSI-controllers with the drivers supplied in a seperate archive below. It does not need any other special hardware, it will run on 486 or higher, with at least 32MB (I think) ram or more. Unsupported hardware: MCA, EISA, i2o may not work. Some newer IDE/SCSI-raid systems may not work either.

Tested on: NT 3.51, NT 4, Windows 2000 (except datacenter?), Windows XP (all versions), Window Server 2003 (at least Enterprise).

DANGER WILL ROBINSON! If used on users that have EFS encrypted files, and the system is XP or later service packs on win2k, all encrypted files for that user will be UNREADABLE! and cannot be recovered unless you remember the old password again

link

 >Reciprocity is not guaranteed on airlines (or toll bridges - it
 >has always amused me that the toll on the Severn Bridge between
 >England and Wales is GBP 4.20 for a car to enter Wales but there
 >is no toll the other way, ie entering England). (Maybe it shows
 >how the two countries value themselves?)

All of the bridges in the San Francisco Bay area only charge toll in one direction. Some genius realized that, on the average, just about as many cars went each way for the obvious reason that most trips across the bridges are round trips. So they doubled the toll and took down the toll booths going one way (except for the Golden Gate Bridge where the toll booths remain, unattended). There has been considerable saving in toll collection costs and the toll booth traffic jams in one direction are gone. Is it possible the Severn Bridge does similarly?

 >>Which brings me to an excellent 'forthism' I once read in a
 >> newsletter.  It stated:
 >>
 >>     "You can do anything in Forth - but you must be prepared
 >>     to do it yourself."
 In a recent discussion in c.l.functional, about why popular languages
 are popular, I summarized the relationship between Lisp and Forth
 more-or-less as follows:
 "From the Lisper's perspective, every other language is a cute subset
 of lisp; whereas from the Forther's perspective, every other language
 is a cute extension of Forth."

• Skolelinux is a network architecture tailored for use in schools.
• Skolelinux is designed to be easy and cheap to maintain.
• Skolelinux gives the students their own usernames, home directories and services.
• Skolelinux includes OpenOffice.org

I just now came across the rubyx website and noticed the logo. Nice!

Rubyx is a Linux-distribution similar to Gentoo, but all based on one ruby script :-).

• Both ssh or telnet into the same (remote) Unix machine and account.
• One enters screen, then starts vim, then the other enters screen -x.
• ctrl-d to exit screen)

Linux Gazette article about screen

link

I asked David Guembel, one of the fathers of the software to email me a short describtion:

 On an abstract level, the idea behind our ganymede system is simple: To make
 an application run under Wine (a free Win32-API layer and Windows
 executable loader), it is neccessary to know what parts of the Windows API
 are actually required by that particular piece of software. Software has a
 modular structure - in this context, a module is a Windows executable
 (.DLL, .EXE, .OCX etc.) - and every module provides (exports) certain
 functionality and requires (imports) functionality from other modules.
 Thus, ganymede internally creates a dependency graph of an application's
 binaries. This method is static and does not require anything but a fresh
 installation of the software to be analyzed.

 Before x-raying a Windows application, ganymede parses and stores an
 analysis of the soure code of one or more Wine versions. It automagically
 determines the implementation state of the APIs provided by Wine. During a
 software analysis, the functionality required by the Windows application is
 compared to what Wine provides, and missing or incomplete APIs are
 reported. By storing Wine versions and the dependency structure of the
 analyzed applications in a database, automatic or manual re-analysis with
 different Wine versions is possible. Via the API ganymede itself provides,
 the collected data is accessible in several ways. One application of that
 API is our tool named sysiphus, which uses ganymede and a GUI-based
 approach to semi-automatically determine the best possible Wine
 configuration while providing for the possibility to re-use already
 licensed Windows DLLs to fill the gaps Wine still leaves.

"The Linux Incompatibility list is a wiki project that attempts to document hardware that is incompatible with Linux rather than list what is compatible. In the wiki, it is possible to add alternitives so as to push hardware manufacturers to make good binary drivers, publish specifications, or even better, publish open drivers."

 >Because it is important for the customer to have an idea of how much
 >> everything will cost ...

 In 99% of the times customer neither needs nor wants "everything"! One
 of the big dangers of BRUF is that it imposes the wrong feeling that
 "everything" is important. This is a major distraction that inevitably
 leads to scope-creep and eventually project failures. When we have the
 first meeting with a new customer we ask the following 3 questions:
 1. What is your biggest pain?
 2. If we solve this and only this pain, will your life get better?
 3. Are you willing to pay X amount of Euros to us to solve this pain.

 If any of these questions is answered with "no" we just thank for the
 coffee and walk away. If all 3 questions are answered with yes, we move
 to the first planning game...

 Put it in another way: I do believe it is extremely dishonest and
 incorrect behavior to conduct 9 months BRUF only to reach the
 conclusion that the customer does not have enough resources to
 continue. It is dishonest because as I wrote in an earlier posting,
 _all_ good developers I know are able to estimate almost immediately
 the scale of any software project without conducting BRUF.

About the $200M Oracle-Ford Desaster: the management did not give them enough power to go fully agile

Chet Hendrickson:

 It was a very frustrating situation.  The team asked Don and me
 to help with preventing the Oracle consutants from making changes
 directly to the production system.  This was about $150 million into the project.

 We tried to sell them on a more agile approach (as you might imagine), but by
 this time they were pretty far gone.

 It was unfortunante that we were not operating at a level in the organization
 that would have allowed us to get the plug pulled sooner.

 chet

Georg Tuparev has a nice case story, too: speak out if you are put on a death march.

 Few years ago I was called to lead a huge team stuck in one and half
 year design phase. The team was supposed to build a control software
 for a network of telecom satellites. Cannot disclosed names and
 resources, but one could imagine ...

 Three days in the project I had a phone conference with the CxO's of
 both companies involved. Told them that the way it is going no
 satellite will ever fly and that I know a better way. After getting
 green line, the design document was burned with a small celebration at
 a BBQ, and 85% of the initial team members were sent to an indefinitely
 long vacation. With the rest (15%) of the team we had the first
 functioning version 2 months ahead of the schedule and 50% lower then
 expected expenses.

 So the lessons:
 - it is never late to change direction of a project in order to save it.
 - I do not agree with Kent that this is a sad story. If you are a good
 programmer put on a death march project you should speak out! If no one
 listens - walk away. There is just one very precious life in front of
 us - do not waste it! And if these folks wasted 2 years of their lives,
 well, it is their business ... but they should not expect my
 sympathies.

 BTW, Philip is right - the project I was telling about had a 9 months x
 40 people "Big Requirements Up Front"!!! Then the design started...

 Just my 0.02

 Georg Tuparev

 "Without test-first and refactoring, clients think
 they must assemble as many program requirements as
 they can afford to have written. This effort snarls
 all relative business priorities together, making
 Scope Control impossible. It obscures opportunities
 for simplification. Designing and implementing many
 features all at once is very hard, leading to our
 industry's reputation for very large failures. Putting
 tests in front of development's inner cycle permits an
 outer cycle of incremental feature growth. That
 relieves the Customer of the responsibility to predict
 the future and guess which complete set of features
 will maximize productivity."

.. Juergens answer:

 Nice description.
 Sometimes I try to explain that to non technical people
 with the following picture:

 If you have only one chance to get your wishes on a
 list, it is like Christmas for a child. You make sure
 you get every little wish on that list and hope for the best.

 If you are sure that you can get your wishes on the list
 at any time. You will just put the most important ones
 there which come to your mind easily.

 I assume this popped up on everyone else's RSS aggregator as well, but...
  From Darrell Norton's blog [1] and Artima developer forum [2]: the
  current issue of CIO magazine is all about agility:
  http://www.cio.com/archive/081504/index.html

 A quote from "Pirates of the Caribbean: The Curse of the Black Pearl":
 --You're pirates. Hang the code, and hang the rules. They're more like
 guidelines anyway.

link

 But anyway, when I last asked Kent what XP is, he said
 "XP is a community of software development practices based on
 values of simplicity, communication, feedback, and courage".
 That was about two or three years ago.

 I look forward to seeing the second edition as well.
 I'm sure it will be enlightening ...