The End of OS X

Posted on by

Today I read The End of OS X. I particularly liked the bit about the Unix philosophy:

  1. Make each program do one thing well. To do a new job, build afresh rather than complicate old programs by adding new “features”.
  2. Expect the output of every program to become the input to another, as yet unknown, program. Don’t clutter output with extraneous information. Avoid stringently columnar or binary input formats. Don’t insist on interactive input.
  3. Design and build software, even operating systems, to be tried early, ideally within weeks. Don’t hesitate to throw away the clumsy parts and rebuild them.
  4. Use tools in preference to unskilled help to lighten a programming task, even if you have to detour to build the tools and expect to throw some of them out after you’ve finished using them.

I’m trying to just literally never argue with people

Posted on by

I’m reading this great interview with Marc Andreessen in which he says:

I’ve really been trying hard to spend less time actually arguing with anybody. Because people really don’t want to change their mind. And so I’m trying to just literally never argue with people.

…I thought that was worth making a note of. I think I’m going to take that on board.

Most bugs are in your error handling code

Posted on by

While reading What tools made you better programmer I came across a link to Error Handling in a Correctness-Critical Rust Project which included these two tidbits:

almost all (92%) of the catastrophic system failures are the result of incorrect handling of non-fatal errors explicitly signaled in software.

in 58% of the catastrophic failures, the underlying faults could easily have been detected through simple testing of error handling code.