Arch is currently not ideal as a Ruby on Rails server

heatdeath · 2010-05-31 04:26:01

Hi all. This is my first post. I hope I am posting in the right place. I have just started using Arch, and I love it! I have used many server distros in the past, have real experience in production environments, and I'd love to use Arch for any servers I need in the future.

There's a problem, though. Best as I can tell, the only version of Ruby available on Arch right now is version 1.9.1. While that's the latest stable, for certain reasons it is not the recommended version on which to run the popular web framework, Ruby on Rails, which I make my living developing in. You can see that for yourself here:

http://rubyonrails.org/download - "We recommend Ruby 1.8.7 for use with Rails."

I'm sure this isn't the first time there have been popular versions of software despite there being later releases. People are often slow to adapt in production environments. However, I couldn't even find a ruby18 package, or anything like that.

I'm not requesting years-old stability or anything absurd like that. In general, I like having the newest software. But in practice, it's sometimes prudent to prefer the next-to-newest software.

In addition, the ruby package installs "rubygems", a separate package management system for Ruby analogous to CPAN in Perl. The problem is, it installs an old version of rubygems, 1.3.1, which is so old it doesn't work. The latest stable version of this is 1.3.7, and version 1.3.2 is required for Rails. I was able to upgrade it using the special rubygems updater ("gem update --system") but I worry this will conflict with pacman, and it shouldn't be necessary.

In short: please upgrade rubygems, and please provide a 1.8 version of the ruby package.

All of the packages I'm discussing were based on the present pacman versions as of this post. Thanks for your help and for the great distro!

Last edited by heatdeath (2010-05-31 04:27:58)

Allan · 2010-05-31 04:31:11

There is ruby18 in the AUR. Use that.

Also, ruby source packages rubygems and there does not seem to be a way to disable it installing it. We try to package software as upstream suggests so complain in their direction.

heatdeath · 2010-05-31 05:09:16

Allan wrote:

There is ruby18 in the AUR. Use that.
Also, ruby source packages rubygems and there does not seem to be a way to disable it installing it. We try to package software as upstream suggests so complain in their direction.

Thanks for your help, it is appreciated. I just had my first experience with the AUR. It was mostly good, since I got what I wanted out of it, although I had to manually download a patch file, and it would be nice if you could auto-build and install community packages via pacman. I assume I will have to manually build and add updates? I also couldn't find an uninstall feature. And just out of curiosity, is it common practice for AUR packages to be installed in /opt?

As for Ruby upstream, they're an odd bunch...

Allan · 2010-05-31 05:11:03

There are a variety of (unofficial and unsupported) AUR helper tools available to help you keep AUR packages up to date. The wiki has a list.

Installing in /opt is weird, but I guess the maintainer wanted to install ruby18 alongside the ruby package from the repos.

tomk · 2010-05-31 05:56:47

heatdeath wrote:

I have used many server distros in the past, have real experience in production environments, and I'd love to use Arch for any servers I need in the future.

Many users will tell you that Arch is not suitable for production servers. It's up to you to decide if the bleeding-edge, up-to-the-minute nature of Arch is compatible with the stability that is usually expected from servers.

heatdeath · 2010-05-31 07:16:51

tomk wrote:

heatdeath wrote:
I have used many server distros in the past, have real experience in production environments, and I'd love to use Arch for any servers I need in the future.
Many users will tell you that Arch is not suitable for production servers. It's up to you to decide if the bleeding-edge, up-to-the-minute nature of Arch is compatible with the stability that is usually expected from servers.

Yeah, but it's also a lot easier to configure and maintain. I have experience with more traditional server favorites like Debian and CentOS too, but I think they're a bit cumbersome. Call me a renegade. Besides, the stuff I'm running is often pretty bleeding-edge, and I work with small companies; not every app is Google.

heatdeath · 2010-05-31 08:57:04

A thought on "Keeping it Simple", the philosophy that drew me to Arch. While it is certainly "simple" to have only one version of ruby and rubygems available, it is by no means "simple" to set up a Rails server as a result. Which takes priority, minimalism in package maintenance, or practical ease of use? Are there no exceptions to the rule of keeping only the latest stables available, or of not patching upstream updates, even for practical purposes? Does Arch Linux believe itself to be unviable as a server OS by design, and if so, what is its purpose? The about page says, "It is both powerful and easy to manage, making it an ideal distro for servers and workstations." If the community does not really believe this, perhaps it should declare itself an ideological experiment for hobbyists?

byte · 2010-05-31 09:04:55

http://www.archserver.org/

Allan · 2010-05-31 09:09:25

Firstly, none of the devs particularly maintain ruby. I update it if an update becomes available, but I have never written a line of ruby code and nor do I have it installed...

And Arch is viable as a server, provided you know what you are doing and are prepared for breakages. This is running on an Arch server.

So at worst it is "ideal for servers (except using rails)..."

Finally, "Arch is what you make it". It is a community run distro, and so far the community seems to care relatively little for ruby. No community supported ruby repos have sprung up over the years.

Ramses de Norre · 2010-05-31 10:42:27

heatdeath wrote:

Does Arch Linux believe itself to be unviable as a server OS by design, and if so, what is its purpose? The about page says, "It is both powerful and easy to manage, making it an ideal distro for servers and workstations." If the community does not really believe this, perhaps it should declare itself an ideological experiment for hobbyists?

I think there is a big difference between the server in your basement streaming your video collection or the server at work serving (critical) data to employees and customers. I think arch can be suitable for the first use case (I'd choose arch for it) but I wouldn't choose arch for a critical system such as the second use case.

awkwood · 2010-05-31 16:29:57

Ideal solution - http://rvm.beginrescueend.com/os/archlinux/

The patch you mentioned is required for 1.8.7, more details here:

http://bbs.archlinux.org/viewtopic.php?id=95320

heatdeath · 2010-06-01 01:10:22

I suppose then I will take the community's advice and "not choose Arch" for my Rails installations. Back to Debian and CentOS I suppose. A pity because I think Arch has more potential than just "serving videos from my basement", but it would require some community support which it does not have.

thisllub · 2010-06-01 03:20:55

Ramses de Norre wrote:

heatdeath wrote:
Does Arch Linux believe itself to be unviable as a server OS by design, and if so, what is its purpose? The about page says, "It is both powerful and easy to manage, making it an ideal distro for servers and workstations." If the community does not really believe this, perhaps it should declare itself an ideological experiment for hobbyists?
I think there is a big difference between the server in your basement streaming your video collection or the server at work serving (critical) data to employees and customers. I think arch can be suitable for the first use case (I'd choose arch for it) but I wouldn't choose arch for a critical system such as the second use case.

If you know what you are doing (or at least most of it) then Arch is the ideal choice for many server apps, especiallly if run in a VM or running them.
Lightweight with no unnecessary extras and the best package manager in the business I have migrated dozens of specialised servers to Arch.
To date I have had very few problems with Arch compared with the big 3 server distros.

If you deploy a server without adequate testing you get what you pay for, however I have found that for most server apps Arch is easier to configure and runs in a lighter footprint.

Last edited by thisllub (2010-06-01 03:21:16)

tomk · 2010-06-01 06:07:18

heatdeath - you're not getting the point. If there is something you want from Arch that is not available in the official packages, you become part of the community and do it yourself. It may end up being just for you, or others may also find it useful and help you out, but either way you get what you want, and Arch gets the "community support which it does not have". There have been numerous examples of this over the years.

heatdeath · 2010-06-01 08:10:07

tomk wrote:

heatdeath - you're not getting the point. If there is something you want from Arch that is not available in the official packages, you become part of the community and do it yourself. It may end up being just for you, or others may also find it useful and help you out, but either way you get what you want, and Arch gets the "community support which it does not have". There have been numerous examples of this over the years.

I understand your point, but using the AUR dramatically diminishes the ease of use from the whole setup. I have to manually download the PKGBUILD and any patch files, build it, install it, and then manually keep track of updates, manually delete the installed files (there is no uninstall) and then repeat the process. While it's great that the AUR is there for specialized interests, it seems that things from the AUR should be incorporated into the official packages if they have enough support. My problem is mainly in the selection of "official packages", and the deference to the AUR anything that doesn't meet the strict and dare I say impractical requirements for inclusion therein. There needs to be more respect for widely-used earlier branches, and there needs to be respect for upstream packaging problems such as the rubygems one. And I am here, in the community, voicing my opinion on this issue, but I cannot change the official packages or the philosophy by sheer force of individual will. It's going to require that people consider what I have to say, and consider what Arch should be.

Ruby 1.8, as with many other major releases, continued in its development and had point releases even after Ruby 1.9 came out. Despite being official, these releases are not available via pacman. It remains the dominant form of Ruby in use today, and probably will be for another year or so.

Consider the release of MySQL 5.0. Would you expect everyone to switch from 4.1 immediately to 5.0 once they released their first stable? Or shouldn't it be possible to stay on the prior major version branch and make the conscious decision to switch? At some point, the keyword "mysql" should switch to the newer branch, and the old one should be maintained as mysql4.1 for legacy support for a while; but this should be a while in, after the tide has turned in its favor. I'm certain something like this is already the policy for the Linux kernel, for instance. I'm just asking it also be applied to Ruby.

Instead, I'm relegated as a minority interest to the AUR ghetto. I think Rails and its philosophy has a lot in common with Arch Linux, and I've heard other Rails people speaking of it favorably. They are both focused on ease of use. They could be compatriots, and Arch could benefit from the friendship. Both communities are often interested in using brand new software, when appropriate. Rails is ruthless with its deprecation. But the community for Arch Linux needs to decide whether it can be useful as a young, innovative new server distro for practical use, or whether it's beleaguered by the philosophy that "true" "critical" server distros use "stable" archaic software and sacrifice maintainability, bug fixes, new features, and simple pleasure in the process, and therefore Arch has no place amongst their anachronistic pantheon, doomed to dwell underground forever with Gentoo and the other thoughtful playthings.

I was surprised to find myself being criticized for suggesting I would use Arch as a production server. I think it has the chops, it just needs to commit to the purpose. Don't be defeatist, there are a wide variety of possible production scenarios, many which use fresh new software; let server admins make the decision whether or not Arch is capable of the job.

As for variations on upstream releases (such as fixing this rubygems version problem), I think the best solution is that pacman should have something that allows automatic building, installing, upgrading and uninstalling of community packages -- maybe even binary variants -- so that users can have the ease of use, but also realize they are using something that differs from the official upstream releases. A convention to install in /opt or /usr/local/ would further the mental divide and diminish the risk.

Please understand my criticism comes with respect, and a desire to use Arch. I ache every time I check the replies, knowing I've likely offended people. I apologize for the length of this post. The truth is, if I can't use Arch as a production server, I don't see any point to it. I am an outsider looking in, sharing my thoughts, and I don't expect they will be received warmly, but it would be great if they were. However, so far the impression I get from this thread is that Arch has no interest in being a production server, sees it as a sideline, implausible interest in conflict with its theory.

tomk · 2010-06-01 08:37:46

I've just skimmed you post, I'll admit, but you're still failing to understand what I mean. You want the Arch devs to hand you the ruby packages that you think should be provided - I'm suggesting you do some work yourself, and create the packages, firstly for yourself, and subsequently for the wider Arch community. For example, you could create and host an arch-ruby repo, which ruby enthusiasts like yourself could use.

That's it from me - good luck with whatever you decide.

smakked · 2010-06-01 08:49:43

I understand your point, but using the AUR dramatically diminishes the ease of use from the whole setup.

This makes no sense at all, i think tomk has said it correct , you still dont get what arch is about, did you even read the beginners guide?

packer -S ruby-rails (whatever package you want)

yaourt -S ruby-rails  (whatever package you want)

http://wiki.archlinux.org/index.php/AUR_Helpers

exis10z · 2010-06-01 10:28:04

I also use Ruby and Arch Linux extensively (I'm at a Rails house and we use Arch+Rails) and agree that it's a bit premature to have 1.9.1 as the official repo version in Arch. Most distros still seperate 1.8 and 1.9, and multiple versions should really use RVM because installing another version in a nonstandard place alongside the offical repo version tends to cause erratic problems.

I'd be happy to create and maintain the packages involved, but I don't see any way of doing this outside the AUR, which breaks the simplicity somewhat of Arch. If someone could tell me exactly how I could help here I would. Setting up a Ruby repo sounds like a great idea, but I don't see myself creating AND hosting AND organising mirrors for another repo? Can't we use the existing infrastructure somehow? My apologies if I have misunderstood anything.

Also, somewhat related, I don't understand why we're getting into the habit of compiling everything with the AUR - surely that just makes us a less sophisticated Gentoo? One of the best things about Arch in my opinion is the binary packages.

Allan · 2010-06-01 10:59:56

If someone provides a ruby (1.9) package that makes it easy for people to install 1.8 alongside, then I will package it and put it in our repos. I doubt I will also supply a 1.8 package, bt it should make things simpler for other to provide one.

Allan · 2010-06-01 11:03:56

heatdeath wrote:

I understand your point, but using the AUR dramatically diminishes the ease of use from the whole setup. I have to manually download the PKGBUILD and any patch files, build it, install it, and then manually keep track of updates, manually delete the installed files (there is no uninstall) and then repeat the process.

If you have to manually delete the files belonging to a package, then you are doing it wrong... Read "man pacman".

heatdeath wrote:

Ruby 1.8, as with many other major releases, continued in its development and had point releases even after Ruby 1.9 came out. Despite being official, these releases are not available via pacman. It remains the dominant form of Ruby in use today, and probably will be for another year or so.

The is no Arch developer that cares about ruby. I was maintianing it just because no-one else was and tried hard to get someone to maintain it. There is also nothing stopping a TU bringing more Ruby to the [community] repo, but no-one has. No interest = no packages.

tomk · 2010-06-01 11:32:34

exis10z wrote:

I'd be happy to create and maintain the packages involved

Now that's more like it.

exis10z wrote:

but I don't see myself creating AND hosting AND organising mirrors for another repo?

For a minority-interest repo like that, you don't need mirrors - just get your hosting organised, and publish the URL.

exis10z wrote:

Can't we use the existing infrastructure somehow?

If you successfully apply to become a TU - the Ruby TU, to be exact - you can maintain your packages in the Community repo.

exis10z wrote:

Also, somewhat related, I don't understand why we're getting into the habit of compiling everything with the AUR.

Who's "we"? I use hardly anything from the AUR. Different people have different needs, as always. If an AUR package is popular, it may get promoted to Community - if you think that should be happening with any current AUR package, raise the issue on the aur-general mailing list.

exis10z · 2010-06-01 11:34:07

Allan wrote:

The is no Arch developer that cares about ruby. I was maintianing it just because no-one else was and tried hard to get someone to maintain it. There is also nothing stopping a TU bringing more Ruby to the [community] repo, but no-one has. No interest = no packages.

Allan, I'm not sure I understand your reasoning here. If I look at the package statistics, Ruby actually seems to be very popular (in fact, more so than GIMP) . Lack of developer interest doesn't mean lack of user interest. Suggesting that Trusted Users add packages to [community] is all very well, but that doesn't help end users without significant contributions (and hence not trusted users) like heatdeath and myself. Thus the options are AUR or the official repo version - which as you stated does not have a interested party.

So I guess my question is, what's the best way to move forward with this? Could we consider changing the official version from 1.9.1 to 1.8.7 perhaps?

Last edited by exis10z (2010-06-01 11:42:33)

exis10z · 2010-06-01 11:49:14

tomk wrote:

Who's "we"? I use hardly anything from the AUR. Different people have different needs, as always. If an AUR package is popular, it may get promoted to Community - if you think that should be happening with any current AUR package, raise the issue on the aur-general mailing list.

Thanks tomk, for work-related stuff I find myself using the AUR heavily, maybe as much as 50% of packages I install. Even with tools like yaourt, this is a much more long winded process than pacman -S favouriteapphere. I was just curious as to why the AUR packages couldn't be distributed as pacman packages, and why PKGBUILDs always resorted to manually compiling software (slower and let's face it - less reliable), when in reality architecture is pretty much confined to i686 or X86_64 anyway.

Last edited by exis10z (2010-06-01 11:50:05)

kazuo · 2010-06-01 11:54:38

exis10z wrote:

So I guess my question is, what's the best way to move forward with this? Could we consider changing the official version from 1.9.1 to 1.8.7 perhaps?

Arch philosophy is to follow upstream decisions. And upstream decided to mark 1.9.1 stable, so arch will use this.

http://www.ruby-lang.org/en/downloads/ wrote:

The current stable version is 1.9.1.

If 1.9.1 is not good, this is a upstream problem and need to be solved at upstream level.

exis10z wrote:

I was just curious as to why the AUR packages couldn't be distributed as pacman packages, and why PKGBUILDs

Search the forum for the answer.

Last edited by kazuo (2010-06-01 11:58:58)

exis10z · 2010-06-01 12:29:49

kazuo wrote:

Arch philosophy is to follow upstream decisions. And upstream decided to mark 1.9.1 stable, so arch will use this.
http://www.ruby-lang.org/en/downloads/ wrote:
The current stable version is 1.9.1.
If 1.9.1 is not good, this is a upstream problem and need to be solved at upstream level.

The official arch repos have plenty of packages with an -lts version (or two different branches). Indeed, on the very page you quoted under "Ruby for Linux" it describes the 1.8 installation (in this case via Debian apt-get). Almost every other distro seperates the two. 1.8 is also ubiquitous amongst hosting providers for Ruby on Rails. Just as the Linux Kernel has seperate 2.4 and 2.6 stable branches, they are both used for different environments.

Arch Linux

#1 2010-05-31 04:26:01

Arch is currently not ideal as a Ruby on Rails server

#2 2010-05-31 04:31:11

Re: Arch is currently not ideal as a Ruby on Rails server

#3 2010-05-31 05:09:16

Re: Arch is currently not ideal as a Ruby on Rails server

#4 2010-05-31 05:11:03

Re: Arch is currently not ideal as a Ruby on Rails server

#5 2010-05-31 05:56:47

Re: Arch is currently not ideal as a Ruby on Rails server

#6 2010-05-31 07:16:51

Re: Arch is currently not ideal as a Ruby on Rails server

#7 2010-05-31 08:57:04

Re: Arch is currently not ideal as a Ruby on Rails server

#8 2010-05-31 09:04:55

Re: Arch is currently not ideal as a Ruby on Rails server

#9 2010-05-31 09:09:25

Re: Arch is currently not ideal as a Ruby on Rails server

#10 2010-05-31 10:42:27

Re: Arch is currently not ideal as a Ruby on Rails server

#11 2010-05-31 16:29:57

Re: Arch is currently not ideal as a Ruby on Rails server

#12 2010-06-01 01:10:22

Re: Arch is currently not ideal as a Ruby on Rails server

#13 2010-06-01 03:20:55

Re: Arch is currently not ideal as a Ruby on Rails server

#14 2010-06-01 06:07:18

Re: Arch is currently not ideal as a Ruby on Rails server

#15 2010-06-01 08:10:07

Re: Arch is currently not ideal as a Ruby on Rails server

#16 2010-06-01 08:37:46

Re: Arch is currently not ideal as a Ruby on Rails server

#17 2010-06-01 08:49:43

Re: Arch is currently not ideal as a Ruby on Rails server

#18 2010-06-01 10:28:04

Re: Arch is currently not ideal as a Ruby on Rails server

#19 2010-06-01 10:59:56

Re: Arch is currently not ideal as a Ruby on Rails server

#20 2010-06-01 11:03:56

Re: Arch is currently not ideal as a Ruby on Rails server

#21 2010-06-01 11:32:34

Re: Arch is currently not ideal as a Ruby on Rails server

#22 2010-06-01 11:34:07

Re: Arch is currently not ideal as a Ruby on Rails server

#23 2010-06-01 11:49:14

Re: Arch is currently not ideal as a Ruby on Rails server

#24 2010-06-01 11:54:38

Re: Arch is currently not ideal as a Ruby on Rails server

#25 2010-06-01 12:29:49

Re: Arch is currently not ideal as a Ruby on Rails server

Board footer