Slashdot Mirror

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.

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.

Stupid /. bug that is twice today it has been right in preview and then bad when I hit submit. Oh well. They did in fact do Debian

No the did Debian . Just seems that the author of the article did not mention it. BTW the O'Reilly book is much better just don't use the CD. Get a standard install of 2.2, the online version or the O'Reilly book, and Running Linux and you will be good to go much better than the dummies book.

A friend of mine wrote the following book Crytography for Visual Basic: A Programmer's Guide to the Microsoft CryptoAPI and got into a fight with his publisher over the name of the book.

While I agree the final name is a bit wordy, it's much more descriptive than the publisher's suggested title: Securing Your Applications -- no reference to VB or Cryptography.

I took part in the earlier phase of the project, that found the trillionth digit, and was impressed by the fact that the person behind it, Colin Percival, was only 16 or so at the time. That wasn't so long ago -- I doubt he's even 20 by now. This may not be earth-shattering knowledge, but I'm impressed by the fact that someone so young is doing something so impressive.

It reminds me of a large-scale version of the mathimatical riddles that Paul Erdos is said to have constantly posed -- check out The Man Who Only Loved Numbers some time, it's a really good book. This kid may be on track to be the same caliber of mathematician. Who knows, the next puzzle he solves might not be trivial -- maybe he'll prove or disprove the P vs NP conjecture & break or affirm modern cryptographic systems. Maybe he'll find the real proof to Fermat's last theorem. I look forward to finding out...

Hehe you get involved in one little book project and suddenly find yourself interesting.

Seriously, though, I love to make myself available to user groups when travelling, like I did when I came down here to Dallas in May for a friend's wedding (the fact that I found a job here and wound up moving back is another story). I suspect most authors, open-source-project-leaders, et al have similar attitudes: catch me when I happen to be in Pennsylvania (or wherever), and I'd love to give a presentation.

OF course, that makes it incumbent upon us (as potential speakers) to publicize our travel plans, a la Randal Schwartz -- something I'm guilty of neglecting myself, and I should probably get around to updating. Taking it a step further though, that makes for a lot of work on the part of the program chair of a user group: you still have to wade through all of the homepages of each potential speaker until you find one who will happen to be in the neighborhood. Perhaps someone would like to undertake building a "Random Sightings" website where people who wouldn't mind giving talks while travelling could enter their travel info into a database (and prog chairs could subsequently browse the same)?

MOO;IANAL.

Expert C Programming: Deep C Secrets

Which is one of the best and funniest books on C that I have ever read. I mean, it actually made me laugh out loud many times.

"If I were stranded on a desert island and could only take one data structure with me, it would be the hash table."

I couldn't recommend it more highly.

Keep your Amazon-boycott-conscience clear and consider buying it at Fatbrain.

-Dan

From the article:

D , the number of spatial dimensions in our universe-- that is, three. "Life could not exist if it were two or four," contends Rees.

Not having read Rees' work in its entirety, I'm still surprised that Rees could make this sort of comment. I can imagine staring at a piece of paper, re-reading Flatland&l t;/a>, and saying "Okay, I can't imagine life existing in only two dimensions." But four?

This books seems to be coming from the other side of the anthropic cosmological principle argument, which is explained very nicely in all its forms in the Barrow and Tipler book The Anthropic Cosmological Principle . In a nutshell Barrow and Tipler talk about how our very existence puts constraints on some of the fundamental constants, because if they were any different then we wouldn't be here. It is a very good book BTW.

... then you need to read The Anthropic Cosmological Principle, a serious and fascinating discussion of the question of why our universe is the way it is; whether or not you agree with the authors' conclusions, it will at least give you the necessary tools to think further about it. Sort of like James Morrow does for Christian theology. Though not as funny.

On the flipside, it's not like Xerox has ever capitalized on having this asset. PARC claims invention of Ethernet, laser printer ...

Xerox botched the laser printer business, sure; but even in botching it, they made billions (Brits: thousands of millions) of dollars in their big (e.g., series 9700, priced at $100K up) high volume laser printers in the early 1980s. PARC was a very profitable investment for Xerox.

Great book on PARC: Michael Hiltzik's Dealers of Lightning: Xerox PARC and the Dawn of the Computer Age (buy where ever you'd like).

You know a way to make 802.11b work as a LAN (ie, not just peer-to-peer) without an access point? Do tell.

Routing is a basic concept of TCP/IP networking. If you are so unfamiliar with it that you don't even know it exists, I would recommend you start here:

TCP/IP for Dummies, Fourth Edition

-

Its easy for him to be interesting, hes basically written a book review but cunningly disguised it as if it were his own insight.

If anyone else was to review this book on slashdot then Poole would get the credit for his authoring skills and insight but instead Katz has managed to take all of Pooles opinions and research and pass them off as his own. The least he could have done was include a link to buy the book that he has reduced to being a JonKatz article

So here is the important bit Katz left out, a link to buy the book at fatbrain.

Given the recent concern about internet privacy brought up by Simson Garfinkel in his book, What is your vision of the future of privacy laws in the US to protect US consumers from the wholesale distrobution of their "digital biobroghies"?

Given the recent concern about internet privacy brought up by Simson Garfinkel in his book, What is your vision of the future of privacy laws in the US to protect US consumers from the wholesale distrobution of their "digital biobroghies"?

Do some research. Almost any US citizen can become financially secure enough to pay for their children's education, live comfortably, and buy some of the toys they've always wanted.

You can do this with an IRA, many /.ers can do this through their employer's 401K programs. The amount you contribute is practically unnoticeable, but the returns of a tax-deferred compound interest plan are staggering! Do the math, you'll probably be surprised. Who wants to be a millionaire? You can, without spending more than a few hours of time arranging it.

I was a complete financial idiot until I read The Wealthy Barber. Everything I've mentioned is discussed there.

It's not hard.


=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=

I read it a little while ago and the jist of it is that a career is a game and what matters is how you play the game. There is alot more to the book than what I can pull of the top of my head but I did use it (and man am I happy I did - I choose a position based on my being productive and happy over money and title and this is the best part - I like getting up in the morning and going to work : ) )

Unless you're a huge investor, the biggest winners in the stock market are the brokers. They win when it goes up; they win when it goes down.

Take a look at the book ``Where Are The Customer's Yachts?, Or, A Good Hard Look At Wall Street''. Or don't. It might make you angry if you think your brokers are on your side.
--

To paraphrase Patterson & Hennessy, No single number can ever encapsulate the speed of a system. Not MIPS, not MFLOPS, not specints. Any single test or single number can be artificially inflated, and this inflation probably won't carry over into general performance.

One simple suggestion: read more books. I'd recommend the late (and sorely missed) Richard W. Steven'sTCP/IP Illustrated, Volume I: The Protocols as a starting point. It's a great book, and really easy to follow. It's $70 that will really help you understand stuff.

Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)

Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.

All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.

That's how to make this change. Here's why you might consider it.

The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)

You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.

Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice ... remember how many choices you really have. --PSRC

Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)

Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.

All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.

That's how to make this change. Here's why you might consider it.

The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)

You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.

Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice ... remember how many choices you really have. --PSRC

Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)

Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.

All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.

That's how to make this change. Here's why you might consider it.

The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)

You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.

Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice ... remember how many choices you really have. --PSRC

Great book, possibly the best, on what makes software development organizations work: Peopleware by DeMarco and Lister. (Link is to Fatbrain, but everyone carries it.) Possibly the most relevant to your new position: the list of ten things you can do to prevent teams from forming. (There's nothing you can do to make teams form, but lots you can do to prevent them.)

Other good reads: Jim Coplien's organization patterns (don't worry about the word "process," Cope doesn't believe that process generates quality), also found in the first PLoP book; DeMarco's The Deadline: A Novel About Project Management ; maybe Jerry Weinberg's The Psychology of Computer Programming ; and (as others have suggested) many books by Steve McConnell.

All these boil down to one thing: You can't do it all. (If you can, you don't need to manage anyone.-) 99.44% of your success will depend on the success of the people who report to you. 99.44% of your job means making sure they're excited, hard working, and pointed in the right direction.

That's how to make this change. Here's why you might consider it.

The best managers (and former managers) I know decided the most important thing about an organization's success was about how the organization worked, not how they as individuals could contribute. They either expressed interest in that, or made an impact without being asked. (The latter is how I got promoted to management in my last job. No one in my group was sure if I was their boss or not. I was happy with the ambiguity. My boss wasn't, so he promoted me.)

You can go home again. When I changed companies (the old company rolled the dice on a new technology and lost), the new position was purely technical, and I'm still there and still happy there. Smart companies will let you "step down" in place, somehow preventing it from being a demotion. Dumb companies aren't worth staying at anyway.

Don't do it unless you really want it. Don't do it unless you can make more of a difference where you're pointed than where you are now. (But don't let fear hold you back.) If your boss says you have no choice ... remember how many choices you really have. --PSRC

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Reduce your CVS access to "read"
The best thing you can do for yourself as a technical manager is move into a strategic role. Working as a programmer/manager is an uncomfortable and difficult business -- luckily, with ten years of experience, you can still work with the software architects and as an "expert-on-call." You don't want to lose your technical competency, but accept that you're not going to work as a developer even 20% of the time, let alone 80%.

I think the best description of a technical manager I've read comes from Debugging the Development Process, by Steve Maguire. He likens a TM to the guys who range ahead of "wide load" haulage, "arranging to have overhead power lines disconnected and removing other obstacles" in the way of the truck. Your developers are that truck; you've got to move those power lines.

Be strategic, not tactical
In a strategic role, you are now responsible for the success or failure of the project. You can't beat a deadline by working everybody fourteen to sixteen hours a day, so you'll need to think through all levels of the development cycle. If you're not familiar with the Systems Development Lifecycle (SDLC), and development methodologies such as the Structured Systems Analysis and Design Method (SSADM) or Jackson Structured Programming (JSP -- no, not that JSP!), then get a quick introduction to them. I've listed some resources at the bottom of this post, but the best resources are those who have been through the wringer before -- requirements and systems analysts, project managers, and the like. Even so venerable an institution as the SDLC changes dramatically between organizations, so for every abstract description you get, YMMV (as per the usual).

Your boss is the end user
Make friends with the requirements and systems analysts you'll work with, as well as with the (dreaded) userbase. 40-60% of delays are due to missing, poor, or misleading user requirements. Don't let this happen to you! Every piece of code should map at some level to a functional requirement; every functional requirement should map to a technical requirement; every technical requirement should map to a business requirement. This is probably the most important part of a systems development cycle -- missing a critical user requirement or whiffing an analysis will make you miss your delivery date. (I'm a systems analyst, so I'm quite biased -- but I've also seen what happens with a bad analysis.)

Fight on the beaches, fight on the shores...
Don't lie to your users, don't put your developers on the spot. Don't give in to the temptation to haul in delivery dates or reduce expected costs under pressure from others. If we all budgeted and planned software projects honestly, we'd probably have an 80% hit rate, rather than an 80% failure rate.

Don't Panic!
Most of all, relax. As a manager, you get to help develop the talents of great programmers. As a manager, you get to guide projects into completion, and see them in use. Best of all, you get to ensure that at least four programmers don't have to suffer from clueless, craven managers. That's not such a bad deal.

Resources
Oddly enough, some truly great books on development management come from Microsoft Press (makes you wonder what they'd create otherwise!). Maguire's Debugging the Development Process is a great piece of work, as is Karl Wiegers' Software Requirements. Probably the classic work on software development is Brooks' The Mythical Man-Month, which has been updated with recent content reflecting the rise of OO methodology. Lientz and Rea's Breakthrough Technology Project Management is a much better book than its title suggests, while Liberty's Clouds to Code is the "All Quiet on the Western Front" of project management books -- a grunt-level account of a development project. Also, check if your company has any internal resources for managers -- most large companies have well-defined processes for lifecycle management, and can help you get used to the strategic environment.

For the traditional side of management, try Deming's Out of the Crisis, which should appeal to your quantitative side; Goldratt's constraint-theory masterpiece The Goal is a seminal work for production managers -- the same lesson applies to us. Peter Drucker is also pretty good, though he works the softer side of management.

Stay away from the one-minute anything, and anything having to do with cheese. Those books perpetuate the myth that you can become an effective manager by reading a slim, childish volume written by a agoraphobic psychiatrist ... um, sorry. The point is, being an effective manager takes a lot of work and constant self-evaluation and criticism. Good luck!

Fatbrain has it for $14.95 plus shipping.

Buy a copy of the new edition of "Fire In The Valley" by Paul Freiberger and Michael Swaine, which reprints the letter from Bill to the Homebrewers, and is also one hell of a book (even if it does make the occasional mistake). Along with "Hackers", it's required reading for Personal Computer History 101.

Firstly, it's not easy to update the ports tree itself

You're going about it the wrong way there. Have a look see at the FreeBSD Handbook for CVSup for more details on this. Also, if you don't already have a copy, go pick up "The Complete FreeBSD" from Walnut Creek. It's an outstanding book, and one that I found to be a much easier read than many of the Linux specific books out there. It has a chapter covering the ports tree that I think you'd benefit from.

Mind you, ports do have their problems. All in all, I think that it's a far better approach to software distribution than anything else that I've seen. A more in depth discussion of this, which even relates to this thread, was done a few weeks back right here on Slashdot, "Unified BSD packaging system?". One of the concepts brought up in that discussion I haven't seen mentioned in this one is if there is some way to unify all the *nix world rather than just the various flavors of Linux.

It sure would be cool to see a group work out the best of the best features from the leading methods of distributing software and bring it to all the platforms. Definitely not holding my breath for anyone to actually do this, just a pleasent thought just the same.

On a related note, a book I think everybody who doesn't understand statistics should take is the classic book How to lie with Statistics. For the less mathematical person, it's a good way of showing just how easily and subtly one can shift the results of those fail-proof statistics.
----------------------------

for a great look at the wonderful wierdness of black holes, the fabric of space, and worm holes grab a copy of:

"Black Holes & Time Warps: Einsteins Outrageous Legacy" by prominant physicst Kip Thorne. (There's even a forward by Hawking :)

It's a great non-technical look at all really fun stuff in the cosmos (both fact and theory)

You can look at (and buy) the book at FatBrain by clicking: here

I think they've been experimenting in many more places. I wonder if they're going to come clean there too.

Would sales increase if I put clip-art of a penguin on the virtual cover?

Sensitive, purple prose for purple times.
www.ridiculopathy.com

It's preferable if these are open source, but they don't have to be to suit your purpose; for example Metrowerks PowerPlant is the most popular application framework for the MacOS, and although it is a commercial product it is inexpensively available and when you do buy the Codewarrior development system you get the PowerPlant source code on the installation disk.

You can even develop an open source framework yourself and publish it openly, and invite in contributors publicly, and distribute non-subversive demo and test programs. Alternatively, you can add functionality to frameworks that almost suit the purpose and submit your patches back to the original maintainers.

This will save you work, although you may have to write "adapters" to be able to use someone else's library for your own purposes, it will increase reliability of your product, because the framework will have already been debugged by someone else and also tested under a wider variety of circumstances than it will encounter in your code, and you can concentrate your work on the particularly subversive parts.

Then you post only the "interesting" parts of your source code, and provide hyperlinks to the needed application frameworks in your build instructions. Be sure to include the version numbers needed for this build of your program, and if the sources to any of the frameworks are signed with a public key, include the key which those sources were signed with when you got them. That way you can be sure future programmers can rebuild the same program as you did.

It may well be that you have a large application but only a few source files and some build instructions to upload, which could be done off a floppy disk at a public access terminal. If you upload these to a few free webhosting service pages, then email the URL to a bunch of warez site maintainers, your code will be looked after.

Note: to find lots of warez sites (and even more serialz sites) go to Altavista, click on "Advanced Search" and enter:

download and warez and photoshop and illustrator and crack

Note that if you want to build a Windows application you can build it with Cygwin (a GNU shell environment for Windows including gcc) so you can be sure Microsoft doesn't embed Globally Unique Identifiers in your code. I'd also suggest that when you make a windows build, you buy a brand-new copy of windows 98 (pay cash), install it on a freshy formatted hard drive, build your binary, upload it, low-level format the hard disk you built it on and throw away the Windows 98 installation disk and all the materials that came with it. It's probably hard to get away with installing a development system on a public access terminal.

If you don't want to use a public access terminal (after all, you might be recorded on a surveillance camera, or the coffee shop waiters might remember you skulking around), then use Zero Knowledge Systems' Freedom to anonymize your web access.

Note that the way Freedom works is your HTTP packets are multiply encrypted with the public keys of the Freedom Network's servers, then "unwrapped" one by one as they pass through up to three servers until they are passed unencrypted to the public net at a faraway place.

Freedom provides both anonymous web browsing and anonymous email send and receive.

Some sources for open source libraries:

• Available C++ Libraries FAQ
• The Apache XML Project
• The Free Software Foundation software page
• Walnut Creek CDROM Free Software Archive
• SourceForge
• Freshmeat
• Gnome

On the other hand, when you write new code, it is definitely worth while to snip out little bits and make sure that they will compile and run on their own, or depend only on other readily available libraries. That way you can create a library yourself.

The book More C++ Gems has some articles on Large-Scale Software Architecture that discusses reducing cyclic dependencies in software projects, in part so that the projects can be rebuilt faster but also so that they can be unit tested in smaller parts and the parts can be extracted out and reused in other programs - although the claim is often made that object-oriented software is more reusable, this claim is baseless unless good engineering practices are observed.

This is a comprehensive survey of just about every programming language under the sun. It covers some of their history as well as the syntax and sematics of the languages themselves. It should prove to be a useful starting point for intensive research on language topics.

The bottom line is Amazon is not a monopoly, they have plenty of competition.

So they can charge any damn price they want, reasonable or not. If you don't like it, you can do two things with sound moral ground beneath your feet:

1) Stop doing business with them. (I have, long ago.)

2) Discuss it publicly to show your displeasure to Amazon, and to warn other consumers about the behavior.

Amazon is being assholes again. Is anybody surprised?

Stop doing business with them. Try buy.com or FatBrain.

Or even Barnes and Noble, unless they've screwed you too.

-

I loved A Deepness in the Sky, but A Fire upon the Deep was probably one of the best and most innovative SF books I've ever read. Vinge's Across Realtime is another great book (actually a collection of three shorter stories).

'Hard' SF has dominated the Hugo's in the past and will probably continue to do so. Cryptonomicon was just too real. How long after the book was published did we hear about Sealand and their data haven?

For fatbrain fans, try:
A Deepness in the Sky
A Fire upon the Sky

For out of print books try alibris.com

I loved A Deepness in the Sky, but A Fire upon the Deep was probably one of the best and most innovative SF books I've ever read. Vinge's Across Realtime is another great book (actually a collection of three shorter stories).

'Hard' SF has dominated the Hugo's in the past and will probably continue to do so. Cryptonomicon was just too real. How long after the book was published did we hear about Sealand and their data haven?

For fatbrain fans, try:
A Deepness in the Sky
A Fire upon the Sky

For out of print books try alibris.com

More details on the Star Trek project can be found in Jim Carlton's Apple book. It makes sickening reading, but it's one of the most interesting reads I had in quite a while. It's really quite unbelievable to see just how many times one company can keep repeating the same mistakes over and over again.

There are plenty of reasons not to patronize Amazon..

..unless you're so deeply sunk into middle-American consumerism that you have no awareness whatsoever of the social and political issues that have made Amazon something to avoid for some time now.

If all you want is cheap prices, don't let any other issues get in your way. Let your pocket book think for you.

And as a counterpoint, I've bought scores of books (Sure: Linux is free, but be prepared to spend a fortune on books..) from {*} and I've always received prompt confirmations (how about instantaneous..) and very prompt delivery, using only the standard service.

Maybe you're too blinded by all the baubles and *cheep prices* at Amazon...

t_t_b
--
I think not; therefore I ain't®

t_t_b
--
I think not; therefore I ain't®

The book I'm using is Building Linux and OpenBSD Firewalls (published by Wiley) and I recommend it to anyone getting started with firewalls. It is very well written and is set up in a way that allows to set up a firewall quickly and THEN go back and read about what you've done. I have found it extremely valuable in learning the ins and outs of securing a small network. This book may have even been reviewed on /. at sometime, but I'm too lazy to look right now. I found this book because I've been looking into using OpenBSD for certain tasks, and when I searched at both Fatbrain and Amazon for "OpenBSD", this was the only book that returned. I took and chance and got it, and I'm VERY pleased with my purchase.

Douglas Hofstadter's brilliant book "Goedel Escher Bach" comes to my mind. It's a very good read and could have suggested to Scheider 20 years ago that every formally defined system is going to have holes in it.

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.