Hmm, waste my unused cycles on background noise for seti@home or contribute some information that has a far greater chance of being useful to folding@home... seti has the pretty decorations so I suppose I'll forego logic (or not resort to binary emulation...) and pass on FAH. Also, seti is a command line app on unices...
> Most of the code is probably simply ages old, probably older than strlcpy and friends, or the OpenBSD project itself.
Considering that Todd Miller and Theo de Raadt implemented strl* in 1996 ( http://www.courtesan.com/todd/papers/strlcpy.html ) and OpenBSD was forked from NetBSD in '95 (which is quite old itself ( http://netbsd.org/Misc/history.html )) I'd say that that's an understatement...
Your refutation only supports my statement. If, when released to the public after "testing", a horrible situation that hadn't been intended to be able to happen does, then those "emergent behaviors" mentioned should be looked at to decide what needs to be done to restore the intended gameplay. Also, solid engineering would be based upon using some well thought-out ideas for solving a problem and becoming more inventive only after the base was thoroughly stable - if after gameplay breaks, despite best efforts to prevent such, then fixes should be applied... "engineering" sounds like a fairly good title for that process to me.
Slashdot Mirror
Hmm, waste my unused cycles on background noise for seti@home or contribute some information that has a far greater chance of being useful to folding@home... seti has the pretty decorations so I suppose I'll forego logic (or not resort to binary emulation...) and pass on FAH. Also, seti is a command line app on unices...
> Most of the code is probably simply ages old, probably older than strlcpy and friends, or the OpenBSD project itself.
Considering that Todd Miller and Theo de Raadt implemented strl* in 1996 ( http://www.courtesan.com/todd/papers/strlcpy.html ) and OpenBSD was forked from NetBSD in '95 (which is quite old itself ( http://netbsd.org/Misc/history.html )) I'd say that that's an understatement...
Your refutation only supports my statement. If, when released to the public after "testing", a horrible situation that hadn't been intended to be able to happen does, then those "emergent behaviors" mentioned should be looked at to decide what needs to be done to restore the intended gameplay. Also, solid engineering would be based upon using some well thought-out ideas for solving a problem and becoming more inventive only after the base was thoroughly stable - if after gameplay breaks, despite best efforts to prevent such, then fixes should be applied... "engineering" sounds like a fairly good title for that process to me.
Simple: whenever not doing so prevents the game from being played as intended