Can someone explain what changed from 1.9.1 to 1.9.2 with regards to where Ruby finds or resolves other required .rb files? Also there must have also been some changes from 1.9.2 to 1.9.3. I have a lot of .rb files in the same directory, things were working and now it complains that it cannot find a .rb file. thanks
on 2013-06-03 21:56
on 2013-06-03 22:02
That little thing called Google again..... https://www.google.com/search?q=ruby+require+1.9.1+1.9.2 John
on 2013-06-03 22:11
I did indeed google this. I was more confused afterwards. The articles are very poorly written, no specific examples. It seems like there are a lot of google articles. If there were an article on the Ruby forum in a wiki it would be great.
on 2013-06-03 22:47
It is going to take two days to fix one application alone; We have many web apps on Ruby. This is a serious hit on time; and I can imagine there are many other out there that have to dedicate resources to this. Can anyone explain exactly what the "security risk" was and why the Ruby dev team could simply not leave this alone? We cannot afford this type of downtime or resources to rewrite an app everytime some yahoo Ruby dev thinks he is being clever by fixing a security risk that is probably a result of irrational fear of some extremely remote possibility of something happening. --- I have seen enough of Ruby in the week dealing with it and will be making the recommendation to rip it out entirely because of the maintenance headache associated with it and the Ruby core devs who think things like this are a bright idea.
on 2013-06-03 23:08
Why upgrade to 1.9.3 then? Why no testing in advance of the upgrade? Valid points or not concerning any change to the core of the language - it's always your responsibility to ensure things work prior to upgrading major pieces of your infrastructure isn't it? You have made about 3-4 posts today and not one of them has been anything but negative. So you don't like ruby it appears - well that's unfortunate and I'm sure if you took the time you would see the light - but that's not going to help you right now either way. So how about asking some more positive questions on the subject? You said it would take a week to fix this - why so long for 2 small issues you've discussed thus far? The DBI issue seems like a single line of a patch to a single file to remove that issue. And quite frankly I think it makes perfect sense to not be able to add something to a list of items while you are running through that list. And the fix is equally simple to understand - run through a copy and modify the original if needed. 10 minutes and done. And the load path issue (require failing) has been addressed multiple times and it's not that hard - something like this added at the top of your files should solve that issue. Even 100 or so files doesn't take that long to shove something like this in. $:.unshift(File.expand_path(File.dirname(__FILE__))) unless $:.include?(File.dirname(__FILE__)) || $:.include?(File.expand_path(File.dirname(__FILE__))) That simply adds the '.' folder back into your load path. 2-3 hours max here for a lot of files? If you truly have that many files there are always tools like sed and friends that can help (but I hate pulling them out unless I REALLLLLLLLY need to :) ). I understand the frustration - but you certainly are not engendering much help from others with the off the cuff ranting. John
on 2013-06-04 01:11
On 06/03/2013 03:47 PM, J. V. wrote: > It is going to take two days to fix one application alone; We have many > web apps on Ruby. This is a serious hit on time; and I can imagine > there are many other out there that have to dedicate resources to this. You do realize that the change to Ruby that is giving you problems here was released almost 3 years ago, right? Upgrading your application's basic infrastructure after such a lag should be expected to take some time and effort. Try to stay calm. This one has some workarounds available. If you would like to avoid large code changes and accept all the risks, you can play with fire by appending '.' to the library path for Ruby. Locate one of the first files loaded by your application, and add this near the top: $: << '.' Now your library search path is as unsafe as earlier versions of Ruby, and the rest of your application can go about business as before. > Can anyone explain exactly what the "security risk" was and why the Ruby > dev team could simply not leave this alone? Maybe you already ran across this discussion: http://stackoverflow.com/questions/2900370/why-doe... Read it closely because it does explain the reasoning down in the comments. Calling require can happen at any time during the execution of your application. If require looks in the current working directory of the application for files to load, it can be tricked into loading the wrong files or simply failing to load anything at all by the application's working directory being something other than expected at the time require is called. This could be the result of maliciousness, a poorly coded library, race conditions in threads, the user running the application from an unexpected location, or anything else that could trigger even a momentary change of the application's current working directory. While the risk may generally be remote, it is real, and requiring the majority of developers to explicitly exclude the current working directory from the library path because they don't need it is guaranteed to fail somewhere along the way. It's better to start secure and allow those few who need this functionality to tweak their applications to enable it or find better methods so that they don't need it either. Could these changes have been implemented in some way that preserved backward compatibility? Maybe so, but the backward compatibility would eventually need to be removed in the name of security anyway. Would your application have been able to make use of that even after 3 years? Maybe not. There was quite a bit of angst at the time this change went live years ago. You're just a little late to the party. > We cannot afford this type of downtime or resources to rewrite an app > everytime some yahoo Ruby dev thinks he is being clever by fixing a > security risk that is probably a result of irrational fear of some > extremely remote possibility of something happening. I can understand your frustration, but remember that if you truly want help, casting about insults is not going to garner much assistance. Please also consider that in this case you may not actually know better than the Ruby developers on this particular point. > I have seen enough of Ruby in the week dealing with it and will be > making the recommendation to rip it out entirely because of the > maintenance headache associated with it and the Ruby core devs who think > things like this are a bright idea. Best of luck finding an application stack that can be ignored for years and then upgraded without the need to touch any of your own application code to account for API changes. I've been where you are now personally, and I can tell you that your problems can be summarized as: 1) Lack of understanding of the tools you're using (Ruby and its libraries). 2) An application code base that was allowed to bit rot for too long. If your team no longer has any Ruby expertise, it probably makes sense to go with something you know instead. Unfortunately for you, you'll still likely have to support your application in its current form while you rewrite it from scratch. It would be best to accept that and try to avoid alienating those who may help you through this in the meantime. -Jeremy
on 2013-06-04 01:24
On Mon, Jun 3, 2013 at 4:10 PM, Jeremy Bopp <firstname.lastname@example.org> wrote: > ... and I can tell you that your problems can be summarized as: > > 1) Lack of understanding of the tools you're using (Ruby and its libraries). > 2) An application code base that was allowed to bit rot for too long. Not to mention: 3) Lack of (apparently) any production environment change control. 4) Lack of (apparently) any kind of tests, automated or otherwise.