Forgot your password?
typodupeerror

Comment: Re:Address space randomization does not help. (Score 1) 98

by igomaniac (#47763253) Attached to: Project Zero Exploits 'Unexploitable' Glibc Bug

1) if you make exploitation less likely than an astroid hitting the earth, then for all practical purposes you can say that it is prevented.
2) 'repeatable crash bug behavior' doesn't matter, it will be repeatable if it is run in valgrind/address sanitizer or via a debugger which is really all that matters to a developer. An end user couldn't care less about repeatable crashes and would prefer if it occasionally/usually continued running.

Comment: Re:So misleading. (Score 1) 161

by igomaniac (#47661139) Attached to: New Watson-Style AI Called Viv Seeks To Be the First 'Global Brain'

I have no idea why you would believe that "our genetic code is a type of program", I don't think anyone working in molecular biology has this interpretation. And even if you view the genetic code as a type of program, then it is a program that primarily deals with how the individual cells that make up our body operates and _not_ how the brain processes input.

Comment: Re:Developers (Score 1) 112

by igomaniac (#42988143) Attached to: New GPU Testing Methodology Puts Multi-GPU Solutions In Question

It's generally desirable to have the AI and physics run at a fixed time step because it allows you to reproduce results exactly. That way you can record gameplay by just recording the inputs. So usually you will have a 'simulation' thread running at a fixed tick rate and a 'render' thread producing frames as fast as possible. I agree about the Vsync, there is not point whatsoever in making frames faster than the display can display them.

And in fact that's the problem with this frame-time benchmarking, if the workload is such that it's artificially rendering more frames than can displayed it doesn't really matter much if they are displayed at a consistent rate. If you want to see how much better a multi-GPU solution is, you need to test a workload that is being rendered at less than the Vsync rate (or at least around that rate).

Comment: Re:Anybody using Ada? (Score 1) 165

by Ada_Rules (#42370551) Attached to: Ada 2012 Language Approved As Standard By ISO
I use it all time The complexity assertion is a bit confusing. I am not sure by what measure you'd rate it more complex than languages like Java. I've hired lots of engineers out of college and none has ever had a problem learning it. There are certainly some bad habits from other languages that carry over in their early work but generally not that big of a deal.

Comment: Re:Avoid UML, unit testing, instant messaging, Git (Score 1) 239

by igomaniac (#40511855) Attached to: Ask Slashdot: What Defines Good Developer Culture?

You're almost right, but the main problem is when a team gets obsessed with other issues than actually writing code. You want as little time as possible to be spent on debugging and rewriting. In order to achieve that you need some tools. To avoid rewriting you need some way of specifying what the software is supposed to do before actually making it. UML can be used for that, but it's not a goal in itself. To avoid endless debugging session you need tests, unit tests can be used, but I've found it far more productive to write code that has a lot of debugging code in it. Since I'm mainly writing C/C++, this will be in the form of asserts and #if DEBUG ... #endif, but the main idea is to catch errors as early as possible during program execution. In my experience it's far more productive to get dedicated testers to test end-user functionality and file bugs than to make the programmers who wrote the code write code that checks if the code they wrote did what they thought it should do. The reason is that most bugs occur because the programmers who wrote the code failed to consider some particular corner case when they wrote the code, and they will likewise fail to write a test to test it...

In conclusion, the primary goal is to develop a product, not to write tests, not to make specifications and not to make clean revision histories. However, when used right, specifications, testing and version control enables you to develop the product faster and with higher quality.

Comment: Thank you gnu (Score 5, Insightful) 192

by Ada_Rules (#39446765) Attached to: GCC Turns 25
I remember the first time I built gcc in college on an decstation (probably around 1990) I was thrilled to have a free compiler with source code. It almost seemed like magic. Several years later when the GNAT project started and promised to bring Ada programming to GCC I was even happier but I never really expected it would turn into the high quality Ada compiler that we have today. While HURD never really worked out, the GCC project alone (never mind the vast quantity of other software covered by the GPL) has been transformational and I think many of the younger generation take the existence of this stuff for granted.

Now, get off my lawn.

Comment: Re:007087 (Score 1) 510

by igomaniac (#39387663) Attached to: Van Rossum: Python Not Too Slow

Yeah, C++ and Java is probably equivalent in the time it takes to solve the actual problem -- but then you spend 4 times as long debugging your C++ code because you have some weird write-past-the-end of an array or use-after-free bug that somehow works most of the time and when it goes wrong it only affects some completely unrelated piece of code from where the bug is that got it's data structures ruined. These classes of bugs can bring down novice programmers who can spend weeks trying to figure out where it's going wrong, and they just don't happen with Java or C# or Python.

An Ada exception is when a routine gets in trouble and says 'Beam me up, Scotty'.

Working...