4 ms·
No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change th
by nknight 15y ago
No, it's considered a bad thing that Rails had insecure defaults in a recommended code path used by legions of inexperienced developers. You can still change the setting to the old value if you want to, just like you can explicitly ask for a recursive mutex if you want one. Bonus: Asking for a recursive mutex still isn't a security problem.
And since you want to argue based on SO, I'll just leave you with two bits of data from SO:
http://stackoverflow.com/questions/tagged/pthreads http://stackoverflow.com/questions/tagged/pthreads -- 1,525 questions
http://stackoverflow.com/questions/tagged/ruby-on-rails http://stackoverflow.com/questions/tagged/ruby-on-rails -- 66,675 questions
- telent 15y agoGuess what? I consider that a bad thing too. But you're still reading things into my comment other than what I said. (1) Rails had insecure defaults which encourage bad programming (2) pthreads has an API which - at least, in its designer's view - fails to sufficiently discourage bad programming. (3) The post I was originally responding to was suggesting that it would be in some way an unusual mindset ("startling" was the actual word used, I think) for a library author to wish to discourage bad uses of his library. I think otherwise. Rails was pretty much the first (recent, well-known) example that came to mind where a library author had (imo, anyway) not sufficiently discouraged bad uses of his library. That's all. I make no argument about the comparative size of the communities,nor the comparative intellectual smarts of their members, nor the reach/impact of the design decisions that the library authors made in each case. That's all I said. Library authors can and do and should design their libraries to encourage their consumers to do the right thing, and this should not be startling.