4 ms·

Wow. This is ridiculous. "I've got a weird set up OS for a reason, but this software should work even though no one else would ever run this." "Whatever- this

Wow. This is ridiculous. "I've got a weird set up OS for a reason, but this software should work even though no one else would ever run this." "Whatever- this database should work, even though I'm using a 4 year old version of the free software(that the docs specifically say needs to be a newer version)." "Also, I'm extremely inexperienced installing Rails and Rails apps, and despite the fact that it's a language and server that we literally teach the newest of the new, it's just impossible to do anything with." This isn't a story about the state of web app deployment, this is about the state of the server from hell. This sounds like the kind of thing you hear out of megacorps with 20 year old Mainframes. Should open source be supporting such convoluted, needlessly minor cases of awful environments?

vaxgeek 11y ago
I agree... Docker's 64-bit preference is called out ALL OVER the place... it's true that some people are running on ARM or in 32-bit environments but that is definitely not a normal setup for 99% of Docker users. RVM itself is kind of a hack. Of course, if you have a working Docker environment, no reason to worry about RVM, as each container can have a full Ruby stack with whatever gems you'd like. In an alternate universe where the author had a 64-bit virtual machine (takes about 55 seconds to set one up on Digital Ocean, with Docker pre-installed) I can subtract at least 8 hours from this story, as a prebuilt Ruby image and a prebuilt PostgreSQL image are both available. Docker, like most kool-aid, is best if you buy in completely. * Docker on 32-bit: weird, non-standard deployment * RVM by itself: not the best to begin with * RVM on 32 bit linux: not tested Although I agree with the lack of dependency management on modern stacks and a few other points from this essay -- it seems like the core idea which led to this whole situation: "I have a non-standard environment and it was tough to roll out things to it"
hackerboos 11y ago
"Also, I'm extremely inexperienced installing Rails and Rails apps, and despite the fact that it's a language and server that we literally teach the newest of the new, it's just impossible to do anything with." That's why nearly every newbie tutorial recommends Heroku.
x0x0 11y ago
I tuned out at I actually have a 64-bit kernel, but a 32-bit userspace Eevee right there decided to swim upstream. If you play computers on hard mode, it's gonna be hard.
- eevee 11y ago
  This has never caused any problems before. I'd actually completely forgotten about it until RVM or Ruby or RubyGems (I haven't decided yet who to blame) choked. And it wasn't my choice — I started out 32-bit to save RAM on what used to be a fairly dinky plan. Some years later, Linode said I oughta switch to a 64-bit kernel for some obscure reason I can't remember.
  - justincormack 11y ago
    Its a cloud server, just install a new one, copy your data over and you are done. It is not a long term investment.
- lewiseason 11y ago
  Why should that cause any issues? I run 32-bit applications (built against a 32-bit libc) on my 64-bit machine (with 64-bit kernel) all the time.
dikaiosune 11y ago
Looking back, open source teams could support those varied environments partly because a) the tools were often small and composeable, and b) huge numbers of people worked to get them nicely packaged in distro package managers. I'm sure this oversimplifies a complex issue, but with the huge proliferation of open source projects that are quite complex, and the fact that packaging for a bunch of distros is a huge chore, I can totally understand why projects have only one or two supported installation methods like Docker. That said, it represents a significant departure from being able to apt-get install foobar for almost anything you'd want. I can understand being nostalgic for that, but the ecosystem was generally smaller then (at least that's how it seems to me).
- csirac2 11y ago
  I've tried to install the exact software the author of this article was trying to install, and he/she/they didn't even encounter the insanity that turned me off. There's giving up on traditional package management, and then there's throwing yourself off the cliff of decent release/config/dependency management that used to be a side-effect of traditional package management. "Works for me on my computer" is now "Works for me with my Dockerfile [ and all the configuration assumptions I couldn't be bothered untangling from my app ]"
  - dikaiosune 11y ago
    I think that's pretty fair. But I still think that using docker is probably better than having the user do that manually. In a more ideal world, the dependency, version and configuration management would be better, but using something to wrap around those defects and get something shipped isn't inherently bad.
    - LoSboccacc 11y ago
      speaking of the ideal world one should be able to start any app, point it to any existing database, possibly a folder for storage and be done with it :D
    - csirac2 11y ago
friendzis 11y ago
I will not stop repeating this: the fact that we can have multiple "brands" of the same software, possibly forked from each other, is both the strength and weakness of open source and we just cannot cover our eyes and pretend only mod_php exists. Open source is a community first. Quoting the same eevee: > If two features exist, someday, someone will find a reason to use them together. I strongly believe that if you find a valid reason to use one specific brand of software, this has to be both clearly documented and explained. From my own experience, Ruby apps tend to be written with rather hard dependencies and are actually hell to deploy if any of the components you have preinstalled (be that process supervisor, message/job queue, web server) differ from recommended ones. Last time I needed to deploy a Rails app, I've gone down the route "bring up a new vm, secure it and deploy on that" and that was a breeze in comparison with attempts to integrate with already installed software.
- dikaiosune 11y ago
  Rails may be a mess, but it's popular and finding a way to control the deployment is in ways a more sensible reaction than attempting to fix open source fragmentation. It's definitely a tragedy of the commons issue, but I can't blame a single team for wanting to make their product work for their users.
- nitrogen 11y ago
  Using rvm makes running multiple Rails apps on one machine way easier. I only do this for development, though; for production, it's VMs or containers.
  - friendzis 11y ago
    My experiences (could be outdated, last time I've tried RVM was at least a year ago) are that setting up a VM is much less painful than convincing different applications to load the same environment. Your mileage may vary
- quaunaut 11y ago
  I won't disagree that it could be better- but doesn't this ring of pie in the sky thinking? If you're the only person who is using a thing, and you want it supported- you'll probably have to do it yourself. Now, if there are simply two features, that if used together, fail for whatever reason? That's clearly a user pitfall, and should be fixed. But to endlessly try to support the Nth scenario is unsustainable. Edit: Also, taking a look at what the author was(here: https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md https://github.com/discourse/discourse/blob/master/docs/INST...), no wonder they want to use a system like Docker- it's an incredibly complex, full-featured setup. This isn't one-purpose software, this is a monolithic solution, that if you want to modify, you've gotta dedicate real time and effort toward. This means that if you don't want to use defaults, you'll be constantly getting further and further away from the master project, which makes updating and maintenance so much more difficult. In which case- aren't you already signing up for the long haul, here?
sklogic 11y ago
In the old days things were supposed to just work. `./configure && make && make install` should always have worked around any local peculiarities.
eevee 11y ago
Yes, my OS is slightly "weird" for reasons I did not choose. Funny story: while I was trying to figure out what the hell RVM was doing, I mostly ran across people running OS X who had the same setup: 32-bit OS on a 64-bit chip. (And for what it's worth, Python native extensions build for the architecture of the Python executable — you know, the thing that has to load them — rather than the architecture of the machine.) I never complained that it didn't work with an old database. Ubuntu's versioning was just a fun surprise. I don't see why it wouldn't work with Postgres 9.1; I just figured I'd do the upgrade while I already had my foot in the door. Maybe if installing Rails apps is still a huge headache after the fourth or fifth time I've done it, something is wrong with Rails. Maybe. I have a fairly mundane server running the latest Ubuntu LTS with all stock vendor packages. If your app is such brittle crap that this is the "server from hell", well, it's no wonder everyone is using Docker.
- codinghorror 11y ago
  I'm sorry it was difficult to get Discourse up and running! If it helps, I'd be glad to throw in a free Digital Ocean $20/month droplet -- I can set it up following our guide at http://blog.discourse.org/2014/04/install-discourse-in-under-30-minutes/ http://blog.discourse.org/2014/04/install-discourse-in-under... and then hand it over to you for everything else. We also have a special Mandrill reseller code so we can give you a Mandrill account with 50k emails/month as part of the package. Just email us at team@discourse.org and I'll make it happen. (Obviously I am a fan, because PHP fractals, man.) Yes, this will require Docker, which means a 64-bit OS and a modern Linux kernel. We initially tried supporting arbitrary Discourse installs but it quickly became a support nightmare for our small 7 person team. We adopted Docker because we saw it as the only way forward to have sane support both internally (for hosting) and externally. We are all-in on Docker, for what it's worth. I'd argue Rails has historically had very little incentive to support super easy server installs; how many large open source Rails projects can you even name? Certainly 37signals nee Basecamp isn't too concerned about how hard it is to install their webapps on a server... Long term, the only real solution is VPS and Docker. I think that has a lot of other benefits for the whole hosting ecosystem, too -- it opens the door to not just Rails deployments but all kinds of alternatives.

vaxgeek 11y ago

I agree... Docker's 64-bit preference is called out ALL OVER the place... it's true that some people are running on ARM or in 32-bit environments but that is definitely not a normal setup for 99% of Docker users. RVM itself is kind of a hack. Of course, if you have a working Docker environment, no reason to worry about RVM, as each container can have a full Ruby stack with whatever gems you'd like. In an alternate universe where the author had a 64-bit virtual machine (takes about 55 seconds to set one up on Digital Ocean, with Docker pre-installed) I can subtract at least 8 hours from this story, as a prebuilt Ruby image and a prebuilt PostgreSQL image are both available. Docker, like most kool-aid, is best if you buy in completely. * Docker on 32-bit: weird, non-standard deployment * RVM by itself: not the best to begin with * RVM on 32 bit linux: not tested Although I agree with the lack of dependency management on modern stacks and a few other points from this essay -- it seems like the core idea which led to this whole situation: "I have a non-standard environment and it was tough to roll out things to it"

hackerboos 11y ago

"Also, I'm extremely inexperienced installing Rails and Rails apps, and despite the fact that it's a language and server that we literally teach the newest of the new, it's just impossible to do anything with." That's why nearly every newbie tutorial recommends Heroku.

x0x0 11y ago

I tuned out at I actually have a 64-bit kernel, but a 32-bit userspace Eevee right there decided to swim upstream. If you play computers on hard mode, it's gonna be hard.

eevee 11y ago
This has never caused any problems before. I'd actually completely forgotten about it until RVM or Ruby or RubyGems (I haven't decided yet who to blame) choked. And it wasn't my choice — I started out 32-bit to save RAM on what used to be a fairly dinky plan. Some years later, Linode said I oughta switch to a 64-bit kernel for some obscure reason I can't remember.
- justincormack 11y ago
  Its a cloud server, just install a new one, copy your data over and you are done. It is not a long term investment.
lewiseason 11y ago
Why should that cause any issues? I run 32-bit applications (built against a 32-bit libc) on my 64-bit machine (with 64-bit kernel) all the time.

dikaiosune 11y ago

Looking back, open source teams could support those varied environments partly because a) the tools were often small and composeable, and b) huge numbers of people worked to get them nicely packaged in distro package managers. I'm sure this oversimplifies a complex issue, but with the huge proliferation of open source projects that are quite complex, and the fact that packaging for a bunch of distros is a huge chore, I can totally understand why projects have only one or two supported installation methods like Docker. That said, it represents a significant departure from being able to apt-get install foobar for almost anything you'd want. I can understand being nostalgic for that, but the ecosystem was generally smaller then (at least that's how it seems to me).

csirac2 11y ago
I've tried to install the exact software the author of this article was trying to install, and he/she/they didn't even encounter the insanity that turned me off. There's giving up on traditional package management, and then there's throwing yourself off the cliff of decent release/config/dependency management that used to be a side-effect of traditional package management. "Works for me on my computer" is now "Works for me with my Dockerfile [ and all the configuration assumptions I couldn't be bothered untangling from my app ]"
- dikaiosune 11y ago
  I think that's pretty fair. But I still think that using docker is probably better than having the user do that manually. In a more ideal world, the dependency, version and configuration management would be better, but using something to wrap around those defects and get something shipped isn't inherently bad.
  - LoSboccacc 11y ago
    speaking of the ideal world one should be able to start any app, point it to any existing database, possibly a folder for storage and be done with it :D
  - csirac2 11y ago

friendzis 11y ago

I will not stop repeating this: the fact that we can have multiple "brands" of the same software, possibly forked from each other, is both the strength and weakness of open source and we just cannot cover our eyes and pretend only mod_php exists. Open source is a community first. Quoting the same eevee: > If two features exist, someday, someone will find a reason to use them together. I strongly believe that if you find a valid reason to use one specific brand of software, this has to be both clearly documented and explained. From my own experience, Ruby apps tend to be written with rather hard dependencies and are actually hell to deploy if any of the components you have preinstalled (be that process supervisor, message/job queue, web server) differ from recommended ones. Last time I needed to deploy a Rails app, I've gone down the route "bring up a new vm, secure it and deploy on that" and that was a breeze in comparison with attempts to integrate with already installed software.

dikaiosune 11y ago
Rails may be a mess, but it's popular and finding a way to control the deployment is in ways a more sensible reaction than attempting to fix open source fragmentation. It's definitely a tragedy of the commons issue, but I can't blame a single team for wanting to make their product work for their users.
nitrogen 11y ago
Using rvm makes running multiple Rails apps on one machine way easier. I only do this for development, though; for production, it's VMs or containers.
- friendzis 11y ago
  My experiences (could be outdated, last time I've tried RVM was at least a year ago) are that setting up a VM is much less painful than convincing different applications to load the same environment. Your mileage may vary
quaunaut 11y ago
I won't disagree that it could be better- but doesn't this ring of pie in the sky thinking? If you're the only person who is using a thing, and you want it supported- you'll probably have to do it yourself. Now, if there are simply two features, that if used together, fail for whatever reason? That's clearly a user pitfall, and should be fixed. But to endlessly try to support the Nth scenario is unsustainable. Edit: Also, taking a look at what the author was(here: https://github.com/discourse/discourse/blob/master/docs/INSTALL-cloud.md https://github.com/discourse/discourse/blob/master/docs/INST...), no wonder they want to use a system like Docker- it's an incredibly complex, full-featured setup. This isn't one-purpose software, this is a monolithic solution, that if you want to modify, you've gotta dedicate real time and effort toward. This means that if you don't want to use defaults, you'll be constantly getting further and further away from the master project, which makes updating and maintenance so much more difficult. In which case- aren't you already signing up for the long haul, here?

sklogic 11y ago

In the old days things were supposed to just work. `./configure && make && make install` should always have worked around any local peculiarities.

eevee 11y ago

Yes, my OS is slightly "weird" for reasons I did not choose. Funny story: while I was trying to figure out what the hell RVM was doing, I mostly ran across people running OS X who had the same setup: 32-bit OS on a 64-bit chip. (And for what it's worth, Python native extensions build for the architecture of the Python executable — you know, the thing that has to load them — rather than the architecture of the machine.) I never complained that it didn't work with an old database. Ubuntu's versioning was just a fun surprise. I don't see why it wouldn't work with Postgres 9.1; I just figured I'd do the upgrade while I already had my foot in the door. Maybe if installing Rails apps is still a huge headache after the fourth or fifth time I've done it, something is wrong with Rails. Maybe. I have a fairly mundane server running the latest Ubuntu LTS with all stock vendor packages. If your app is such brittle crap that this is the "server from hell", well, it's no wonder everyone is using Docker.

codinghorror 11y ago
I'm sorry it was difficult to get Discourse up and running! If it helps, I'd be glad to throw in a free Digital Ocean $20/month droplet -- I can set it up following our guide at http://blog.discourse.org/2014/04/install-discourse-in-under-30-minutes/ http://blog.discourse.org/2014/04/install-discourse-in-under... and then hand it over to you for everything else. We also have a special Mandrill reseller code so we can give you a Mandrill account with 50k emails/month as part of the package. Just email us at team@discourse.org and I'll make it happen. (Obviously I am a fan, because PHP fractals, man.) Yes, this will require Docker, which means a 64-bit OS and a modern Linux kernel. We initially tried supporting arbitrary Discourse installs but it quickly became a support nightmare for our small 7 person team. We adopted Docker because we saw it as the only way forward to have sane support both internally (for hosting) and externally. We are all-in on Docker, for what it's worth. I'd argue Rails has historically had very little incentive to support super easy server installs; how many large open source Rails projects can you even name? Certainly 37signals nee Basecamp isn't too concerned about how hard it is to install their webapps on a server... Long term, the only real solution is VPS and Docker. I think that has a lot of other benefits for the whole hosting ecosystem, too -- it opens the door to not just Rails deployments but all kinds of alternatives.