In my experiences with tipping, this simple equation has become quite handy:
Tip = the change you can't be arsed finding space for in your wallet
*doesn't come from a tipping country as well, but has "tipped" overseas* Translation: *doesn't come from a tipping country, but has had food spit in overseas*
In any sufficiently important program, crashing and then throwing up in your lap (assuming the version crashing even was compiled with debugging info) is or should be completely unacceptable. Much better if the program can realize what's going wrong and work around it - whether that means re-asking the user for that input again, retrying reading the IO buffers or emailing a developer.
In any sufficiently important program, if you're catching array bounds exceptions and continuing, you need to fix the underlying bug, or you may be exploited. Exception catching is one mechanism for dealing with such errors, but not one that I consider good practice.
The beauty about exceptions and error codes is that when they occur, you know something is wrong and can do something about it while the program is still running.
If you don't know specifically what is wrong in your exception handler, and you try to keep going, then you are in undefined territory, and you're open to dangerous exploits. Granted, crashing is a kind of exploit (DoS), but a more visible and less dangerous kind than undefined behavior.
No more of this silent, absurdly hard to find corruption of memory going on.
A crash with backtrace should make memory corruption EASY to find, that's the whole point.
Which is also the problem with this approach, you still will be able to perform a buffer overrun, only the application will crash, enabling a denial of service attack. With cryptic error messages etc.
A crash is the best thing for this situation. Much better than undefined (possibly exploitable) behavior. The log should not be cryptic; it should contain a backtrace showing you where your code was when it died. Not very different than a Java exception log.
Java is several orders of magnitude more secure by default than any random C or C++ program.
Do you know what "several orders of magnitude" means? For variety, next time you should write "... exponentially more secure..." or "... takes security to the next level!"
BTW, it's funny you should mention Java performance in this thread -- one of the DieHard authors published this fascinating paper on Java GC performance: http://citeseer.ist.psu.edu/hertz05quantifying.htm l -- executive summary: GC can theoretically be as fast as explicit malloc/free, if you're willing to spend 5x memory size overhead (gulp).
I've been using it for about a month. I moved temporarily from the USA to Botswana, and it's a godsend for my situation. Mail to my permanent address gets forwarded by the USPS to RCM, and then I can view/manage it online. The web interface is not the snappiest or simplest to navigate, and I have yet to exercise the forwarding options. But it works and the scans are pretty good. Overall I would recommend it if you're leaving the USA for a while, or are roaming about.
I'm an author of gameswf, a Public Domain SWF player library (for use in 3D accelerated game engines, not browsing the web). In my opinion based on working with it heavily, the SWF format and supporting software is sweet stuff. It's damn tight and focused on things that are useful to visual designers, but still amazingly capable. Nevertheless, calling SWF an "open standard" is disingenuous.
SWF is, in practice, no more open than MS Word DOC. Macromedia publishes a spec, but unfortunately it's not useful for writing software to interpret SWF, due to legal restraints. My own library has had to rely on a lot of sweat and reverse engineering and help from others, and has still only managed to achieve a subset of SWF compatibility.
Read the license on the Macromedia spec, it comes with many strings attached. For example:
...a nonexclusive license to use the Specification for the sole purposes of developing Products that output SWF.
I.e. they don't allow you to use the spec to implement a player!
Macromedia does some cool stuff and employs some cool people, but the same company engages in heavy-handed corporate scheming. I don't think that's immoral or anything; corporations need to make money somehow. But people need to see the warm-and-fuzzy "open" bullshit for what it is: a convenient marketing story.
BTW the only truly open SWF specs are reverse-engineered ones. The best one is Alexis' SWF Reference
People who actually buy video games. People like me.
Don't forget people who make video games.
I busted my ass for 2.5 years to make an indie game, that was warezed within 2 days of the publisher receiving the gold master. The game didn't reach the shelves until weeks later. And there wasn't a damn thing I could do about it.
I'm no fan of Ashcroft or the major media companies, but as far as I'm concerned, aside from being illegal and inconsiderate, warezing is actually morally wrong.
I'll feel pretty warm and fuzzy inside if some of these people do jail time.
Agreed, WINE is necessary, and Linux sorely needs WINE to keep improving.
There is a pattern where a big complex open source project can spend *years* as an bloated, unstable, weak-featured curiosity, and then in the course of a few months reaches a tipping point, and morphs into a world-class program. E.g. we've seen it with Mozilla, PostgreSQL, possibly Subversion. Hopefully WINE is on the same track.
The developers and users just have to keep chipping away until they reach that tipping point.
Slashdot Mirror
Tip = the change you can't be arsed finding space for in your wallet
*doesn't come from a tipping country as well, but has "tipped" overseas* Translation: *doesn't come from a tipping country, but has had food spit in overseas*
In any sufficiently important program, if you're catching array bounds exceptions and continuing, you need to fix the underlying bug, or you may be exploited. Exception catching is one mechanism for dealing with such errors, but not one that I consider good practice.
The beauty about exceptions and error codes is that when they occur, you know something is wrong and can do something about it while the program is still running.If you don't know specifically what is wrong in your exception handler, and you try to keep going, then you are in undefined territory, and you're open to dangerous exploits. Granted, crashing is a kind of exploit (DoS), but a more visible and less dangerous kind than undefined behavior.
No more of this silent, absurdly hard to find corruption of memory going on.A crash with backtrace should make memory corruption EASY to find, that's the whole point.
A crash is the best thing for this situation. Much better than undefined (possibly exploitable) behavior. The log should not be cryptic; it should contain a backtrace showing you where your code was when it died. Not very different than a Java exception log.
Do you know what "several orders of magnitude" means? For variety, next time you should write "... exponentially more secure ..." or "... takes security to the next level!"
BTW, it's funny you should mention Java performance in this thread -- one of the DieHard authors published this fascinating paper on Java GC performance: http://citeseer.ist.psu.edu/hertz05quantifying.htm l -- executive summary: GC can theoretically be as fast as explicit malloc/free, if you're willing to spend 5x memory size overhead (gulp).
I've been using it for about a month. I moved temporarily from the USA to Botswana, and it's a godsend for my situation. Mail to my permanent address gets forwarded by the USPS to RCM, and then I can view/manage it online. The web interface is not the snappiest or simplest to navigate, and I have yet to exercise the forwarding options. But it works and the scans are pretty good. Overall I would recommend it if you're leaving the USA for a while, or are roaming about.
-T
I'm an author of gameswf, a Public Domain SWF player library (for use in 3D accelerated game engines, not browsing the web). In my opinion based on working with it heavily, the SWF format and supporting software is sweet stuff. It's damn tight and focused on things that are useful to visual designers, but still amazingly capable. Nevertheless, calling SWF an "open standard" is disingenuous.
SWF is, in practice, no more open than MS Word DOC. Macromedia publishes a spec, but unfortunately it's not useful for writing software to interpret SWF, due to legal restraints. My own library has had to rely on a lot of sweat and reverse engineering and help from others, and has still only managed to achieve a subset of SWF compatibility.
Read the license on the Macromedia spec, it comes with many strings attached. For example:
I.e. they don't allow you to use the spec to implement a player!
Macromedia does some cool stuff and employs some cool people, but the same company engages in heavy-handed corporate scheming. I don't think that's immoral or anything; corporations need to make money somehow. But people need to see the warm-and-fuzzy "open" bullshit for what it is: a convenient marketing story.
BTW the only truly open SWF specs are reverse-engineered ones. The best one is Alexis' SWF Reference
Don't forget people who make video games.
I busted my ass for 2.5 years to make an indie game, that was warezed within 2 days of the publisher receiving the gold master. The game didn't reach the shelves until weeks later. And there wasn't a damn thing I could do about it.
I'm no fan of Ashcroft or the major media companies, but as far as I'm concerned, aside from being illegal and inconsiderate, warezing is actually morally wrong.
I'll feel pretty warm and fuzzy inside if some of these people do jail time.
Agreed, WINE is necessary, and Linux sorely needs WINE to keep improving.
There is a pattern where a big complex open source project can spend *years* as an bloated, unstable, weak-featured curiosity, and then in the course of a few months reaches a tipping point, and morphs into a world-class program. E.g. we've seen it with Mozilla, PostgreSQL, possibly Subversion. Hopefully WINE is on the same track.
The developers and users just have to keep chipping away until they reach that tipping point.