Slashdot Mirror

If I were to teach an OS class using source code I'd point students to BSD first (netbsd or openbsd at least, or even 4.2BSD).

And BSD is obviously a particularly good example for networking code.

If say the speed-limit on a motorway was 70mph, and there was no congestion on the road; why would adding in extra lanes to the motorway increase how fast I get to my destination?

You get the car analogy wrong. A packet of 100 bytes is not similar to a single car. It consists of 800 cars (bits). So if you increase the number of lanes more cars can travel. Each car travels still the same speed (of light) but by allowing more cars at the same time, the delivery (packet) distributed over 800 cars gets delivered faster.

The time a packet takes to get transmitted is roughly: packetsize/bandbidth.

Say you have a 10mbps line and a 1000bytes packet. This will take 8000 bit / 10.000.0000 bit / s = 0,00008 s or 0,8ms (one way). So the latency through the line will be roughly 1,6ms. If you got to 100mbps ethenet or even gigabit ethernet, the time will go down by factor 10 each step.

But there are some side effects: Sometimes packets are packed into larger packets to fill the line better. This will increase the latency. When the speed of the line is high, the time the OS needs to send/receive the packets gets more influence on the latency. Also the latency may occur in your providers network because he overbvooks the service (selling access for more cars than the lanes allow and therfor creating congestion).

To see wether your line is the chokepoint use Traceroute to see where the latency happens. If the latency already occurs close to you, a faster line may improve the latency. Also look for features from your provider as "fastpath".

CU, Martin

P.S. This is a very short overview of the topic. A complete coverage would come as a book. BTW the books have already been written: Richard W. Stevens: TCP/IP Illustrated.

You mean something like portalfs, as implemented e.g. in FreeBSD?

Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson, professor at Cambridge University.

It replaces and expands upon Applied Cryptography by Bruce Schneier, and Practical Cryptography by Ferguson & Schneier to make a more holistic approach to security encompassing the entire system, not just using the latest (coolest) encryption techniques. Most real-life systems are broken by going around or ignoring the encrpytion.

Another classic is

TCP/IP Illustrated by the late Richard Stevens
Most people need/read only Volume I: The Protocols, but there is also Volume II: The Implementation which is wonderful albeit with a smaller following, though Volume III which is considered a big disappointment to many (I've never read the vol 3) isn't worry buying unless you're specifically interested in its contents.

The only serious alternative to TCP/IP Illustrated is Douglas Comer's series Internetworking with TCP/IP which is the series I learnt about TCP/IP programming with. Still highly recommended.

For Software development, The Mythical Man-Month by computing pioneer Frederick Brooks should be required reading, and Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister should be handed to every new IT/IM or software manager with their promotion or hiring (if they haven't read it already). Computing would suck so much less if we all held ourselves accounting to the basic ideas in these two books.

For historic, 3 books + bonus item that would have to be included are:

Algorithms + Data Structures = Programs by Niklaus Wirth

Cybernetics: Or the Control and Communication in the Animal and the Machine in 1948 by Norbert Wiener

Computing Machinery and Intelligence, by Alan Turing and published in 1950 in Mind

Computer Lib/Dream Machines by Ted Nelson in 1974, is most often pointed to as the "birth" of hypermedia.

The January 1975 issue of Popular Electronics, which featured the Altair 8800 on its cover.

Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson, professor at Cambridge University.

It replaces and expands upon Applied Cryptography by Bruce Schneier, and Practical Cryptography by Ferguson & Schneier to make a more holistic approach to security encompassing the entire system, not just using the latest (coolest) encryption techniques. Most real-life systems are broken by going around or ignoring the encrpytion.

Another classic is

TCP/IP Illustrated by the late Richard Stevens
Most people need/read only Volume I: The Protocols, but there is also Volume II: The Implementation which is wonderful albeit with a smaller following, though Volume III which is considered a big disappointment to many (I've never read the vol 3) isn't worry buying unless you're specifically interested in its contents.

The only serious alternative to TCP/IP Illustrated is Douglas Comer's series Internetworking with TCP/IP which is the series I learnt about TCP/IP programming with. Still highly recommended.

For Software development, The Mythical Man-Month by computing pioneer Frederick Brooks should be required reading, and Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister should be handed to every new IT/IM or software manager with their promotion or hiring (if they haven't read it already). Computing would suck so much less if we all held ourselves accounting to the basic ideas in these two books.

For historic, 3 books + bonus item that would have to be included are:

Algorithms + Data Structures = Programs by Niklaus Wirth

Cybernetics: Or the Control and Communication in the Animal and the Machine in 1948 by Norbert Wiener

Computing Machinery and Intelligence, by Alan Turing and published in 1950 in Mind

Computer Lib/Dream Machines by Ted Nelson in 1974, is most often pointed to as the "birth" of hypermedia.

The January 1975 issue of Popular Electronics, which featured the Altair 8800 on its cover.

Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson, professor at Cambridge University.

It replaces and expands upon Applied Cryptography by Bruce Schneier, and Practical Cryptography by Ferguson & Schneier to make a more holistic approach to security encompassing the entire system, not just using the latest (coolest) encryption techniques. Most real-life systems are broken by going around or ignoring the encrpytion.

Another classic is

TCP/IP Illustrated by the late Richard Stevens
Most people need/read only Volume I: The Protocols, but there is also Volume II: The Implementation which is wonderful albeit with a smaller following, though Volume III which is considered a big disappointment to many (I've never read the vol 3) isn't worry buying unless you're specifically interested in its contents.

The only serious alternative to TCP/IP Illustrated is Douglas Comer's series Internetworking with TCP/IP which is the series I learnt about TCP/IP programming with. Still highly recommended.

For Software development, The Mythical Man-Month by computing pioneer Frederick Brooks should be required reading, and Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister should be handed to every new IT/IM or software manager with their promotion or hiring (if they haven't read it already). Computing would suck so much less if we all held ourselves accounting to the basic ideas in these two books.

For historic, 3 books + bonus item that would have to be included are:

Algorithms + Data Structures = Programs by Niklaus Wirth

Cybernetics: Or the Control and Communication in the Animal and the Machine in 1948 by Norbert Wiener

Computing Machinery and Intelligence, by Alan Turing and published in 1950 in Mind

Computer Lib/Dream Machines by Ted Nelson in 1974, is most often pointed to as the "birth" of hypermedia.

The January 1975 issue of Popular Electronics, which featured the Altair 8800 on its cover.

Security Engineering: A Guide to Building Dependable Distributed Systems by Ross Anderson, professor at Cambridge University.

It replaces and expands upon Applied Cryptography by Bruce Schneier, and Practical Cryptography by Ferguson & Schneier to make a more holistic approach to security encompassing the entire system, not just using the latest (coolest) encryption techniques. Most real-life systems are broken by going around or ignoring the encrpytion.

Another classic is

TCP/IP Illustrated by the late Richard Stevens
Most people need/read only Volume I: The Protocols, but there is also Volume II: The Implementation which is wonderful albeit with a smaller following, though Volume III which is considered a big disappointment to many (I've never read the vol 3) isn't worry buying unless you're specifically interested in its contents.

The only serious alternative to TCP/IP Illustrated is Douglas Comer's series Internetworking with TCP/IP which is the series I learnt about TCP/IP programming with. Still highly recommended.

For Software development, The Mythical Man-Month by computing pioneer Frederick Brooks should be required reading, and Peopleware: Productive Projects and Teams by Tom DeMarco and Timothy Lister should be handed to every new IT/IM or software manager with their promotion or hiring (if they haven't read it already). Computing would suck so much less if we all held ourselves accounting to the basic ideas in these two books.

For historic, 3 books + bonus item that would have to be included are:

Algorithms + Data Structures = Programs by Niklaus Wirth

Cybernetics: Or the Control and Communication in the Animal and the Machine in 1948 by Norbert Wiener

Computing Machinery and Intelligence, by Alan Turing and published in 1950 in Mind

Computer Lib/Dream Machines by Ted Nelson in 1974, is most often pointed to as the "birth" of hypermedia.

The January 1975 issue of Popular Electronics, which featured the Altair 8800 on its cover.

http://www.kohala.com/start/rstevensfaq.html

Because TCP/IP has become the generic name for the IETF managed suite of protocols. BGP is only one of the routing protocols used to route IP packets. If you're going to be a pedant, then at least be accurate: from a traffic perspective it's IP, everything else rides on top of it (except ARP and RARP).

SO, Smart arse: Here's the real deal: MPLS creates effective PVCs that map BGP propagated routes to telco circuits in a deterministic manner, which undermines the fundamental dynamic nature of all Internet routing protocols, of which BGP is only one (and the most brain dead/static). The reason we have such a cluster-bollocks is because Cisco made underpowered, fundamentally single-threaded, routers, and so were wedded to Bellman-Ford/distance vector routing protocols. This is because their routers couldn't handle the demand of link-state algorithms, especially OSPF, which would not have required any of this mucking around with alternate routing protocols, Autonomous System numbers and route reflectors, since it included the concept of stub, not so stubby, and aggregated areas. Instead they had to devise a suite of ever increasingly unreliable/suboptimal routing protocols named IGRP (It Greatly Reduces Performance), EIGRP (Egads! It Greatly Retards Packets), and BGP (Broken Gateway Protocol).

Believe it or not, there were, and may still be, networks that run OSI routing protocols to route IP, like IS-IS, which works pretty well. The problem is, all these require people with clue and background, which the ILECs, in their race to the bottom, have jettisoned wholesale, to be replaced with those who hold vendor certs, and therefore only know one vendor's approach, and nothing of the history or underlying protocols. Before spouting off, go read your Perlman, Stevens, Moy, and anything written by Li.

grap is an implementation of Kernighan and Bentley's language for type- setting graphs, as described in ``Grap-A Language for Typesetting Graphs, Tutorial and User Manual,'' by Jon L. Bentley and Brian W. Kernighan, revised May 1991, which is the primary source for information on how to use grap. As of this writing, it is available electronically at http://www.kohala.com/start/troff/cstr114.ps

It ties in with TeX and troff rather than with fancy word processors though.

The market is currently quite rough, especially to break into. After being laid off when a product tanked on the market, I've gone a few months without having a single resume responded to - and I have almost a decade of professional programming experience that was applicable to the jobs I've applied for (and my resume used to keep the phones ringing daily for months when I posted it - the market has changed a bit).

I've been spending the extra time continuing development on my personal code library and projects, writing open source code, and working on a few products that I expect there to be a market for when they're done. That's how I'd suggest breaking into the field as well.

You have a very special situation though - you know, or can find out if you think about it and ask your colleagues, exactly what one fairly wealthy niche market needs. What software would help you - as a doctor - work more efficiently? What software have you and your colleagues found lacking? There's your first project :)

It won't be easy, and you won't make money fast. My recommendation would be to start learning about computers and computer programming now while thinking about products. As soon as you feel like you can design a useful program and have one in mind - take a shot at it.

Use CVS ( or for Windows, WinCVS ) or some other revision control so you can keep track of all the code you write (I wish I had when I started!). Estimate for yourself how long tasks should take - track those estimates, and figure out why they were right or wrong. Document everything, especially the code.

Once you have a product you think is worthy for your target audience - use it yourself in your work. Then let some colleagues try it out. Fix anything you find wrong with it, and ask your colleagues for suggestions.

Then, set up a website, advertise it, and try to sell it - or set up a project on SourceForge and make it open source - whichever you feel more comfortable with. On SourceForge, you'll be able to enlist the help of other more experienced programmers and together tailor the product towards excellence. If you sell it and it's successful, you'll be able to afford to switch careers to full-time programmer/entreprenuer and just work on your business.

That brings me to another point - if you aren't currently running your own doctor's office, start learning business skills too. They're just as hard to pick up as programming skills - possibly harder for some. Figure out what you'll need to do to start running your own software company. Even if you decide to write your own software as open source and become an employee for someone else professionally, this will help you at the negotiating table.

What I would NOT recommend is dropping out of medicine, getting a BS in computer science, and expect doors to be immediately open when you g

• But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data.

Pathfinder in it's 1997 landing (04JUL1997) suffered a series of unexplained system failures. David Wilner CTO of WindRiver Systems, the creators of WxWorks the realtime embedded system kernel talked to IEEE Real-Time Systems Symposium at a later date explaining how they solved software bugs in the system.

• leaving the "debugging" facilities in the system saved the day

this article explains how they solved the problem - by including the debug code with the os. I remember reading about this on /. some time ago. A detailed account can be read here by Glenn Reeves (JPL Mars Flight SE).

Windriver systems is supplying the OS for the current mission. Lets see how long it takes them to work this one out :)

links:
www.kohala.com/start/papers.others/pathfinder.html
research.microsoft.com/~mbj/Mars_Pathfinder/Author itative_Account.html

• But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data.

Pathfinder in it's 1997 landing (04JUL1997) suffered a series of unexplained system failures. David Wilner CTO of WindRiver Systems, the creators of WxWorks the realtime embedded system kernel talked to IEEE Real-Time Systems Symposium at a later date explaining how they solved software bugs in the system.

• leaving the "debugging" facilities in the system saved the day

this article explains how they solved the problem - by including the debug code with the os. I remember reading about this on /. some time ago. A detailed account can be read here by Glenn Reeves (JPL Mars Flight SE).

Windriver systems is supplying the OS for the current mission. Lets see how long it takes them to work this one out :)

links:
www.kohala.com/start/papers.others/pathfinder.html
research.microsoft.com/~mbj/Mars_Pathfinder/Author itative_Account.html

• But a few days into the mission, not long after Pathfinder started gathering meteorological data, the spacecraft began experiencing total system resets, each resulting in losses of data.

Pathfinder in it's 1997 landing (04JUL1997) suffered a series of unexplained system failures. David Wilner CTO of WindRiver Systems, the creators of WxWorks the realtime embedded system kernel talked to IEEE Real-Time Systems Symposium at a later date explaining how they solved software bugs in the system.

• leaving the "debugging" facilities in the system saved the day

this article explains how they solved the problem - by including the debug code with the os. I remember reading about this on /. some time ago. A detailed account can be read here by Glenn Reeves (JPL Mars Flight SE).

Windriver systems is supplying the OS for the current mission. Lets see how long it takes them to work this one out :)

links:
www.kohala.com/start/papers.others/pathfinder.html
research.microsoft.com/~mbj/Mars_Pathfinder/Author itative_Account.html

Tragically, he died back in 1999. Info at http://www.kohala.com.

And my personal favorite:

Advanced Programming in the UNIX Enviornment

otherwise known as "Why didn't I just start with this in the first place."

In general, I've found that Stevens, as well as Douglas Comer are two authors who can always be trusted to deliver material that is both relevant and enlightening.

And my personal favorite:

Advanced Programming in the UNIX Enviornment

otherwise known as "Why didn't I just start with this in the first place."

In general, I've found that Stevens, as well as Douglas Comer are two authors who can always be trusted to deliver material that is both relevant and enlightening.

1. TCP/IP Illustrated, Volume 1: The Protocols
2. UNIX Network Programming

1. TCP/IP Illustrated, Volume 1: The Protocols
2. UNIX Network Programming

1. TCP/IP Illustrated, Volume 1: The Protocols
2. UNIX Network Programming

In light of the recent RPC issues that Microsoft has been having with the RPC protocol, I thought that this email, from 1995, might be of some(perhaps humourous ) interest. Won't this darned RPC die a graceful death?
rpc-comments
N.B I realize that this refers to the SUN implementation of RPC, and not Microsofts extension/abortion/implementation.
N.B.B. reprinted without permission...
N.B.B.B. I don't much like /. "junk" filter

From (the late) Richard Stevens' site: A friend commented to me that normal evolution would have gone Word to Frame to troff, but instead, the computer industry has gone the other way!

IMHO any information security professional needs to develop a professional paranoia, being thoughtful of potential risks and failures, and understand what might go wrong.

Reading Bruce Schneier's Secrets and Lies is a really good start in this area. It is a not very technical book, written at the level suitable for an IT manager. This is also useful to help explains risks, vulnerabilities, and failures to IT Management.

The ever so ugly covered Hacking Exposed, which explains the basics of what criminals (or attackers) do commonly to gain unauthorized access to (networked) computer systems. This is so you a) know how easy it is, and b) are familiar with an overview of the basic steps and techniques to gain illicit access.

For online resources, RISKS digest (not focused on malicious activities, but how systems fail - very insightful and low volume), and Bugtraq a full disclosure mailing list will show you recent exploits, and vuln notices, but it is fairly lacking in actual educational content, and there are several other mailing lists at SecurityFocus that could also be useful to developing professional paranoia.

Next you need the language and basics of information/computer security. For this textbooks like Computer Security by Dieter Gollmann, Information Security Management Handbook by Tipton and Krause, Practical Unix & Internet Security by Simson Garfinkel, Gene Spafford, Alan Schwartz, and Security in Computing by Pfleeger and Pfleeger.

For procedures look at CISSP study material, BS 7799 / ISO 17799, and security auditing and incident handling materials. Some knowledge of risk management can also be useful.

From these basics, of the right mindset, the common language of infosec, and procedures and policy you can get into the low-level details of firewalls, VPNs, IDS, and network design. For this you should have a good network/internetworking basics, a very detailed understanding of TCP/IP, and understand firewalls, VPNs, and IPsec.

Firewalls and Internet Security: Repelling the Wily Hacker, 2nd ed. by William R. Cheswick, Steven M. Bellovin, and Aviel D. Rubin is a great place to start, and Building Internet Firewalls by Elizabeth D. Zwicky, Simon Cooper, D. Brent Chapman is a great follow-up. An alternative book on firewalls and VPNs is Inside Network Perimeter Security: The Definitive Guide to Firewalls, VPNs, Routers, and Intrusion Detection Systems by Stephen Northcutt, Karen Frederick, Scott Winters, Lenny Zeltser, Ronald W. Ritchey (crowd from SANS).

For networking basics, a Cisco certification like CCNA could useful in providing knowledge about internetworking and Cisco router's IOS. For the gory details of TCP/IP either TCP/IP Illustrated: Volume 1: The Protocols by Richard Stevens or Internetworking With TCP/IP Volume 1: Principles Protocols, and Architecture, 4th edition by Douglas Comer.

For IDS - Network Intrusion Detection: An Analyst's Handbook by Stephen Northcutt and Intrusion Signatures and Analysis by Matt Fearnow, Stephen Northcutt, Karen Frederick, Mark Cooper are the best IMHO.

I am not sure what to recommend for VPNs, other than you need to know about IPsec.

It's hardly a failing of FLTK really...?

Fltk's add_timeout doesn't obey it's own documentation. It's wrong. No one to blame but that library.

Don't you think you should background your socket code into another thread?

I don't think so. Threading could fix this particular problem, but then I'd have to use threading. That would add a lot of complexity, and overhead as slower, re-entrant versions of all library functions are pulled in. The code would also be less portable, since pthread functions aren't really compatible across different Unices.

The style I'm using now is the (originally) recommended way to write Unix network code, as per Stevens. That is, a select() call to check for network input (if any exists). It works fine with programs that use tty, ncurses, Qt, Motif, or Fltk without calling certain blocking function. Fltk plainly continues to exectute during the blocking function, as user-input continues to work. But it's neglecting its promise to keep the timeouts working.

When I was learning UNIX programming and C++ (on Solaris), we were taught how to code (nothing quite like Stevens' APUE, RIP Richard) but nothing about how to edit, not even a tipsheet/survival guide thing. I hated vi so much, I felt like an idiot because I don't know how to quit it. I programmed most of my stuff on a mac and ftp'ed stuff over. I used Alpha on the Mac, glad it's still around at least in some form. Still the best editor I've used, though NEdit (my current fave) comes close. Me has to start looking at new editors, I kind of like the idea of the folding editors, but they all seem to be too heavy with resources. For those with recommendations of emacs, see last statement about too much resources.

>What other books would people recommend for someone
>interested in network security

Definitely start out with TCP/IP Illustrated, Volume 1, W. Richard Stevens, ISBN 0-201-63346-9. I can't say enough good things about this book.

Internetworking With TCP/IP Volume 1, Douglas Comer, ISBN 0-13-01830-6 is another very good book, but Stevens' book is better.

Advanced Programming in the Unix Environment - a bit outdated, but still good; does not cover kernel internals
The Practice of Programming - good tips related to style, algorithms & data structures, debugging, etc.
UNIX System Administration Handbook- actually shows you how to get stuff done
Concrete Mathematics - to help you understand The Art of Computer Programming

You can try reading UNIX network programming by the late Rick Stevens (2nd edition). It covers IPv6 network programming... 1st and 2nd volume.

You can try reading UNIX network programming by the late Rick Stevens (2nd edition). It covers IPv6 network programming... 1st and 2nd volume.

W. Richard Stevens. Amongst other things, wrote the book 'UNIX Network Programming' which is widely accepted as the best of its kind. See http://www.kohala.com/start/.

It's a well known fact that people who know a lot about a subject, and may be able to answer any question you may have if you ask them, simply can't write a book or teach a class to save their lives.

That being said, I've met a lot of people who were good writers but terrible technical communicators. They do a good job of explaining technical concepts, processes, and so on. But when it comes to all the boring little practical details, they just don't have the patience.

There's also issues of ego. Everybody has their own notions of what "everybody knows" or what's the "simplest" explanation. And of course everybody is wrong about these things some of the time. The best writers in the world can screw up in this way. So they need a skilled editor to help them see this issue.

O'Reilly seems to have a particular problem this way. They cover a lot of technologies with a limited audience -- such as T1 -- and they contract leading technical people to do it. Often the very inventors of the technology. It takes a really good technical editor to tell somebody like that, "That's a little unclear" or "You need to organize the material better," without bruising any egos. Not a lot editors that good -- and I don't think any of them work at O'Reilly.

"The number 24 in the first executable line of code above was determined experimentally. I found no mention of it anywhere in the Platform SDK. If it is not present, the program doesn't work. Apparently, the pipe facility requires a 24-byte header on each write to the pipe."

I think this says alot why I don't wanna work with windows pipes... :)
Oh wait I forgot to site this: "Our results showed that Linux pipes are considerably faster than Windows 2000 named pipes, and Windows 2000 named pipes are much faster than Windows XP named pipes."
Anyone who wants to know alot more about pipes in UNIX/Linux should read Richard W. Stevens bible "Advanced Programming in the Unix Environment", any respectable programmer should have read that book at least one time in his/her life.
And finally it would be really interesting to see this experiment done with sockets too. Atleast Im gonna try it out.

And btw, I wouldn't want to be around when Billy G gets his hands on those guys who made this test...

"The number 24 in the first executable line of code above was determined experimentally. I found no mention of it anywhere in the Platform SDK. If it is not present, the program doesn't work. Apparently, the pipe facility requires a 24-byte header on each write to the pipe."

I think this says alot why I don't wanna work with windows pipes... :)
Oh wait I forgot to site this: "Our results showed that Linux pipes are considerably faster than Windows 2000 named pipes, and Windows 2000 named pipes are much faster than Windows XP named pipes."
Anyone who wants to know alot more about pipes in UNIX/Linux should read Richard W. Stevens bible "Advanced Programming in the Unix Environment", any respectable programmer should have read that book at least one time in his/her life.
And finally it would be really interesting to see this experiment done with sockets too. Atleast Im gonna try it out.

And btw, I wouldn't want to be around when Billy G gets his hands on those guys who made this test...

It disappeared for a while after his death, but Gary Wright, co-author from TCP/IP Vol II, put Steven's old home page back up. It's a treasure chest of cool info. The FAQ is good reading if you've read any of his books.

Gary still keeps the Stevens spirit alive too

P.S. The site is still running on a BSDI machine and I used vi to update the pages. :-)

It disappeared for a while after his death, but Gary Wright, co-author from TCP/IP Vol II, put Steven's old home page back up. It's a treasure chest of cool info. The FAQ is good reading if you've read any of his books.

Gary still keeps the Stevens spirit alive too

P.S. The site is still running on a BSDI machine and I used vi to update the pages. :-)

I think the best advice is general. If you want something more concrete, a bio, here's Richard Stevens'.

My advice would be to treat programming as anything else; it is really a simple thing that will be not be considered terribly impressive in the future. If you want the full, head-on experience, pick up a copy of Godel, Escher, Bach by Hofstadter, look at Knuth's Art of Computer Programming. Think about trying out Corewars. (Don't forget to read the old article in Scientific American.)

If you want to know what the metal is thinking (good to finally understand 'why'), find an accessible book on logic/boolean design. I'll be monitoring this message to see if anyone cares about recommendations.

Perhaps most importantly, have a life outside of programming, interests outside of it. Programming is just an example of one system; think on other systems and you will do well in this special case. And for some reason, you should look at this.

In particular, most discussions of programming are BS (especially when the words 'good' and 'bad' are used; is it really bad or just a failure of imagination?), but there is generally a kernel of truth somewhere in them.

Yours,
Tj

Huffman, Postel, Stevens . . . Now P.W. Katz. I feel guilty for not ever considering any of these people beyond what their program does or does not do for me -- or how I benefitted from their books, until after their death. To think that while we're all out there unzipping our latest copy of the Jargon file or stashing a bunch of porn in a password protected ZIP file, this guy was suffering a serious problem which eventually took his life at the age of *thirty-seven*.

I'm only 22. I spend all my time working at a desk. I haven't been in-shape for almost six years. I could be next. I could be next and I haven't offered a damn thing to the computer or internet community. These people -- and many others, have.

I hope that we'll remember these things in subsequent posts in reply to this article. The last thing we need is another disgustingly barbaric replay of the posts we saw when W. Richard Stevens died.

I hope you have peace, Phillip.

W. Richard Stevens Slashdot Article
W. Richard Stevens Home Page
David Huffman Slashdot Article
Jon Postel Slashdot Article
Jon Postel's Home Page

---
icq:2057699
seumas.com

I've had hours to think about it now, and I'm even more depressed by his death than before. So I went to his homepage and dug around some. His FAQ is interesting. My favorite excerpt:

I really believe that my background is fundamental to the success of UNP and my other books. That is, I was not one of the developers at Berkeley or AT&T, so the writing of UNP was not a "memory dump". Everything that is in the book I had to dig out of somewhere and understand myself. This process of digging up the details and learning how things work leads down many side streets and to many dead ends, but is fundamental (I think) to understanding something new. Many times in my books I have set out to write how something works, thinking I know how it works, only to write some test programs that lead me to things that I never knew. I try to convey some of these missteps in my books, as I think seeing the wrong solution to a problem (and understanding why it is wrong) is often as informative as seeing the correct solution.

Surf around some more and you find out he loved to ski (he used to have a GIF of an old ski pass on his home page), he was a pilot, got his Ph.D while working a full time job at Kitt Peak observatory, has lived in Zambia, Utah, New Mexico, Virginia, Michigan, Oklahoma, Georgia, California, Arizona, Connecticut, and South Africa.

And among all the people who understood Unix systems programming and networking in 1988, this was the guy who had the courage to actually sit down and start writing his first book, Unix Network Programming. Just think of all the people who didn't write that book. He was a unique mix of talented engineer,programmer, and author. It's really no suprise that nobody beat him to writing APUE and his TCP/IP series.

And you thought Linus was unique.

I wonder if Richard Steven's family would agree to keep his wonderful Kohala website permanently open as a tribute?

His home page is here, and reading it is to find out what a truly great guy he was. My favorite is his recipe for chocolate chip cookies, which are harder to make than a bug free threaded tcp/ip stack.

His books were the best. Well written with the best exercises of any books out there. I think the reason he obviously put so much thought into the exercises at the end of chapters was because he knew that's where readers did most of their learning. Unlike other fine books like Knuth's, his books actually got used, reread, and handed around to be used again. He accomplished better than any author I can name exactly what he sought to do--teach.

I just wish I'd written and thanked him a long time ago. RIP.

His home page is here, and reading it is to find out what a truly great guy he was. My favorite is his recipe for chocolate chip cookies, which are harder to make than a bug free threaded tcp/ip stack.

His books were the best. Well written with the best exercises of any books out there. I think the reason he obviously put so much thought into the exercises at the end of chapters was because he knew that's where readers did most of their learning. Unlike other fine books like Knuth's, his books actually got used, reread, and handed around to be used again. He accomplished better than any author I can name exactly what he sought to do--teach.

I just wish I'd written and thanked him a long time ago. RIP.

W. Richard stevens provides a free implementation in his book Unix Network Programming. Source is available on the page