4 ms·

I tried switching to rbenv, but I kept getting frustrated with the process.

FooBarWidget 13y ago
And this is exactly the problem with all those "simpler" alternatives to RVM. They all claim to be simpler and doing less "unnecessary" stuff. And they are simpler, from a technical point of view. But unless you, the user, is very skilled at Unix and knows exactly how environment variables, shell sessions, bashrc etc works, it's going to be more confusing. RVM is more complicated because it does more, in order to make it easier for users. Notice that most of the people who like rbenv/chruby are exactly the kind of people who are already intimately familiar with the Unix environment. I write C++ for a living and use the command line daily. Last time I used rbenv, I quickly gave up because I had to manually mess with $PATH, bashrc and other stuff that RVM always took care for me. I know how that stuff works, but the whole point of tools is to make my life easier. If I have to do so much stuff manually then why should I use rbenv? Back to RVM for me.
- bobbyi_settv 13y ago
  The fact that RVM "does more" means that users need to understand more in order to fix problems that it causes. If you install RVM and other things on your system break due to its tampering with .bashrc, you need to understand what it has done. If I didn't understand $PATHs, etc., I would still be unable to use "man" due to $MANPATH being broken from the last time I installed RVM.
  - FooBarWidget 13y ago
    Correct, but it also means that the authors take responsibility for fixing those problems. That's the attitude we have for Phusion Passenger: it does a lot of stuff for you so that you don't have to. And if things break because of our fault, we take the responsibility of fixing it so you don't have to and can concentrate on your own business. Have the RVM authors not fixed the problems you experienced?
    - bobbyi_settv 13y ago
      I don't use RVM anymore and don't know whether this specific bug was fixed. The point of my example wasn't "RVM sucks because I once encountered a bug". The point was that RVM's model of tampering with the user's environment in a global way is problematic because when bugs inevitably arise, as they do in all software, they break unrelated software in ways that an inexperienced user wouldn't be able to tie to RVM. This is what I think your Python example below misses. If Python is slow because it doesn't have a JIT and that causes someone's program to run too slowly, they can see that the problem is that Python is slow. Python's lack of a JIT would never cause "man traceroute" to stop working in a shell session where the user hasn't done anything related to Python and couldn't possibly guess that Python is the culprit.
    - brandonbloom 13y ago
      > we take the responsibility of fixing it so you don't have to Surely you must say no to some people... I can't take the risk that person might be me and then be left up the creek without a paddle. Do you have an SLA? What if I have an issue in production and the core contributors are all sleeping? Can I wake you up? Can I pay you for the right to wake you up? Even if you are awake and willing to help on my schedule, can you do so reliably without breaking everybody else? As your complexity (and popularity!) grows, your ability to take responsibility shrinks. EDIT: A quick Googling suggests that you do offer commercial support. Take my comments above more generally for the wider array of open source projects out there that real businesses depend on.
      - FooBarWidget 13y ago
        It is exactly as you say. It is a double edged sword, with both benefits and drawbacks. RVM is one example. Another example is Python. Why does Python still have a global interpreter lock after all these years, and why does it not have a JIT? One of the reasons is because it makes development easy, keeps the architecture simple and makes contributions easy. Writing a language implementation without a GIL, and with the latest state-of-the-art garbage collector and JIT, makes the code and architecture more complex also. The drawback of this is... that Python has a GIL and has no JIT.
- brandonbloom 13y ago
  > unless you [are] very skilled at Unix I don't understand this mentality. rbenv isn't advanced shell scripting by any means. Every working programmer should have the minimal unix skills required to read and understand rbenv in its entirety in one sitting. It should take no more than a week of concerted effort to learn your way around bash: You can read `man bash` linearly in an afternoon or two. For such a small price, you can gain hugely disproportional leverage. > had to manually mess with $PATH, bashrc and other stuff Personally, I wish Unix had a better framework for these sorts of environment/dependency/versioning needs, but altering $PATH in your bashrc is about as easy as it gets. It's not nearly as nice as a union mount plan9-style, but it's what we're stuck with, and it should take you no more than 5 minutes to understand and install rbenv. If not, then you should `man bash` and invest that time. Again, for such a small investment, you get a tool that is non-magic enough to trust on your production server too, rather than putting the rvm mystery box in to the wild.
  - FooBarWidget 13y ago
    > I don't understand this mentality. rbenv isn't advanced shell scripting by any means. Every working programmer should have the minimal unix skills required to read and understand rbenv in its entirety in one sitting. I used to think that way too. It's so simple. Why don't people spend a little time to learn their tools? It's not that complicated! Then, over the years, I realized that that's the wrong attitude. You shouldn't expect users to learn stuff no matter how much you think they should. They already have enough other stuff to worry about. They already have their hands full learning other stuff. And the reason why I thought it was easy, was because I already knew it. Expecting other people to go out of their way to learn the things you know is disrespecting their time. Therefore, software should be easy to use for new users. Software should have a learning curve that's as low as possible. Software should not expect people to learn things that you think is important. I am very firmly in the pro-usability camp, even for developer tools. You said that rbenv isn't advanced shell scripting. You are right, it isn't - for us. However, that doesn't mean that it can be utterly confusing for a lot of people. The concept of environment variables are easy, until you get to the common edge cases. Did you know that environment variables are inherited on a per-process basis, so changing them in your shell does not affect already-running processes, and doesn't affect cron? Did you know adding environment variables to bashrc has no effect on cron, init scripts and the like? Lots and lots of people don't realize that. Do you want those people to give up in frustration? I'd say no. I'd say we should help those people with good documentation, and software that just works. For example, at the Phusion Passenger mailing list, we regularly get questions from people asking why they get "command not found" errors. Apparently a lot of people don't understand what PATH is, or what environment variables are, or that sudo resets them. So we ended up writing this: http://www.modrails.com/documentation/Users%20guide%20Apache.html#about_environment_variables http://www.modrails.com/documentation/Users%20guide%20Apache...

And this is exactly the problem with all those "simpler" alternatives to RVM. They all claim to be simpler and doing less "unnecessary" stuff. And they are simpler, from a technical point of view. But unless you, the user, is very skilled at Unix and knows exactly how environment variables, shell sessions, bashrc etc works, it's going to be more confusing. RVM is more complicated because it does more, in order to make it easier for users. Notice that most of the people who like rbenv/chruby are exactly the kind of people who are already intimately familiar with the Unix environment. I write C++ for a living and use the command line daily. Last time I used rbenv, I quickly gave up because I had to manually mess with $PATH, bashrc and other stuff that RVM always took care for me. I know how that stuff works, but the whole point of tools is to make my life easier. If I have to do so much stuff manually then why should I use rbenv? Back to RVM for me.

bobbyi_settv 13y ago
The fact that RVM "does more" means that users need to understand more in order to fix problems that it causes. If you install RVM and other things on your system break due to its tampering with .bashrc, you need to understand what it has done. If I didn't understand $PATHs, etc., I would still be unable to use "man" due to $MANPATH being broken from the last time I installed RVM.
- FooBarWidget 13y ago
  Correct, but it also means that the authors take responsibility for fixing those problems. That's the attitude we have for Phusion Passenger: it does a lot of stuff for you so that you don't have to. And if things break because of our fault, we take the responsibility of fixing it so you don't have to and can concentrate on your own business. Have the RVM authors not fixed the problems you experienced?
  - bobbyi_settv 13y ago
    I don't use RVM anymore and don't know whether this specific bug was fixed. The point of my example wasn't "RVM sucks because I once encountered a bug". The point was that RVM's model of tampering with the user's environment in a global way is problematic because when bugs inevitably arise, as they do in all software, they break unrelated software in ways that an inexperienced user wouldn't be able to tie to RVM. This is what I think your Python example below misses. If Python is slow because it doesn't have a JIT and that causes someone's program to run too slowly, they can see that the problem is that Python is slow. Python's lack of a JIT would never cause "man traceroute" to stop working in a shell session where the user hasn't done anything related to Python and couldn't possibly guess that Python is the culprit.
  - brandonbloom 13y ago
    > we take the responsibility of fixing it so you don't have to Surely you must say no to some people... I can't take the risk that person might be me and then be left up the creek without a paddle. Do you have an SLA? What if I have an issue in production and the core contributors are all sleeping? Can I wake you up? Can I pay you for the right to wake you up? Even if you are awake and willing to help on my schedule, can you do so reliably without breaking everybody else? As your complexity (and popularity!) grows, your ability to take responsibility shrinks. EDIT: A quick Googling suggests that you do offer commercial support. Take my comments above more generally for the wider array of open source projects out there that real businesses depend on.
    - FooBarWidget 13y ago
      It is exactly as you say. It is a double edged sword, with both benefits and drawbacks. RVM is one example. Another example is Python. Why does Python still have a global interpreter lock after all these years, and why does it not have a JIT? One of the reasons is because it makes development easy, keeps the architecture simple and makes contributions easy. Writing a language implementation without a GIL, and with the latest state-of-the-art garbage collector and JIT, makes the code and architecture more complex also. The drawback of this is... that Python has a GIL and has no JIT.
brandonbloom 13y ago
> unless you [are] very skilled at Unix I don't understand this mentality. rbenv isn't advanced shell scripting by any means. Every working programmer should have the minimal unix skills required to read and understand rbenv in its entirety in one sitting. It should take no more than a week of concerted effort to learn your way around bash: You can read `man bash` linearly in an afternoon or two. For such a small price, you can gain hugely disproportional leverage. > had to manually mess with $PATH, bashrc and other stuff Personally, I wish Unix had a better framework for these sorts of environment/dependency/versioning needs, but altering $PATH in your bashrc is about as easy as it gets. It's not nearly as nice as a union mount plan9-style, but it's what we're stuck with, and it should take you no more than 5 minutes to understand and install rbenv. If not, then you should `man bash` and invest that time. Again, for such a small investment, you get a tool that is non-magic enough to trust on your production server too, rather than putting the rvm mystery box in to the wild.
- FooBarWidget 13y ago
  > I don't understand this mentality. rbenv isn't advanced shell scripting by any means. Every working programmer should have the minimal unix skills required to read and understand rbenv in its entirety in one sitting. I used to think that way too. It's so simple. Why don't people spend a little time to learn their tools? It's not that complicated! Then, over the years, I realized that that's the wrong attitude. You shouldn't expect users to learn stuff no matter how much you think they should. They already have enough other stuff to worry about. They already have their hands full learning other stuff. And the reason why I thought it was easy, was because I already knew it. Expecting other people to go out of their way to learn the things you know is disrespecting their time. Therefore, software should be easy to use for new users. Software should have a learning curve that's as low as possible. Software should not expect people to learn things that you think is important. I am very firmly in the pro-usability camp, even for developer tools. You said that rbenv isn't advanced shell scripting. You are right, it isn't - for us. However, that doesn't mean that it can be utterly confusing for a lot of people. The concept of environment variables are easy, until you get to the common edge cases. Did you know that environment variables are inherited on a per-process basis, so changing them in your shell does not affect already-running processes, and doesn't affect cron? Did you know adding environment variables to bashrc has no effect on cron, init scripts and the like? Lots and lots of people don't realize that. Do you want those people to give up in frustration? I'd say no. I'd say we should help those people with good documentation, and software that just works. For example, at the Phusion Passenger mailing list, we regularly get questions from people asking why they get "command not found" errors. Apparently a lot of people don't understand what PATH is, or what environment variables are, or that sudo resets them. So we ended up writing this: http://www.modrails.com/documentation/Users%20guide%20Apache.html#about_environment_variables http://www.modrails.com/documentation/Users%20guide%20Apache...