
OpenBSD removes Rails from the ports tree - mben
http://marc.info/?l=openbsd-ports&m=135794600931567&w=2
======
inopinatus
I'd like to take this opportunity to highlight BSDPAN, which is how FreeBSD
integrates her own package database with Perl's native module installation.

Since 99% of package management is just files on a filesystem and a bit of
dependency analysis, for the purposes of easing installation, permitting
bidirectional awareness of state, and alerting administrators to security
updates.

I would commend any OS that has the smarts to hook into the package ecosystems
of her guests. RubyGems, CPAN, npm, PEAR, PyPI into APT, RPM and what have
you. Wouldn't it be great if.

Here's an edge case, though. In the specific world of both Ruby and her fat
offspring Rails, the proliferation of versions (and the widespread separation
of sysadmins from developers) means that in practice many Ruby applications
have the runtime language binaries and package dependencies installed in app-
specific or personal home directories, via the likes of rvm. Stick that in
your package management pipe and solve it.

~~~
igravious
I know this is a bit of a me too post but this is something I have thought
should exist for years now.

Another benefit this would provide would be that you'd only have to learn one
set of incantations rather than forgetting and looking up whatever subsystem
it is you're messing with.

For the life of me I don't know why this does not exist yet. I have such a
desire for it that I thought long and hard about building something like this
myself but balked at the prospect, for yea it is daunting.

There are others as well: LaTeX (TeXLive) has a package system too, and I am
sure there are lots more.

~~~
inopinatus
There are workflow issues to generalising the case. In particular, since this
is a devops issue any such solution has to be based on satisfying the needs of
developers (e.g. ease of deployment, version specificity), and the needs of
admins (ease of patching & audit, dependency management) across a wide variety
of packaging mechanisms for both base OS and many language-specific
ecosystems.

It's no surprise to me that the unit of deployment, for many sites, is
becoming the virtual machine template. Since you don't even need to bother
maintaining it; just keep your data separate from your code, rebuild the image
when necessary with latest libs & pkgs, and throw away old ones. This is how
many PaaS providers are doing things.

------
wildchild
Wise decision. Ruby has it's own package system. I believe every developer
using rvm/rbenv for managing ruby versions. Rails should be installed using
rubygems. I always cry seeing pretty outdated rails packages in distributives.
I don't care.

~~~
whalesalad
Yep. I don't know why anyone would want to install something like Rails,
Django etc... via their distribution or OS's built-in package management
system. I think it's silly actually.

Ruby has rubygems, Python has pip, Perl has cpan...

~~~
tedunangst
As somebody who occasionally uses software, besides just developing it,
learning the command syntax and idiosyncrasies of a half dozen package systems
is a pain in the butt. I want to type "pkg_add things I want" and be done with
it.

~~~
chimeracoder
Not to mention that package management isn't a problem that should be solved
at every single level possible - package management for the OS, package
management for developing in $LANGUAGE, package management for extensions of
$PROGRAM written in $LANGUAGE, etc....

Aside from the fact that that's redundant, it's _highly_ error-prone.

~~~
hosh
As a long time Rails dev, I never trust the package maintainer's OS packages
for Rails. I need specific versions of Rails and gems, often times specific
git commits.

In places where the IT staff insists on making sure this isn't "redundant",
they usually use something like fpm to create a deb or an rpm out of the gem
specified by Gemfile. Which you then have to drop into a custom deb/rpm
repository. On top of that, the ops staff don't know how to do that properly,
so they end up with a bunch of testing and development dependencies that the
Rails application doesn't need.

... or, you have the deploy process call, "bundle install"

The redundancy is in the OS packages, not in application dependencies. So it
is actually better to automate such with something like Chef and Puppet. From
there, I can define exactly what the application needs from the OS.

I have seen this play out in a lot of ways, devs vs. sys admin. In the past,
sys admins "win" since compute resources were still scarce. We're in the age
of virtual machines now and configuration automation. Applications get their
own VMs, sometimes in multiple nodes. We don't have Unix high priests guarding
the altar with SSH keys, hand-deploying things in secret early-morning
ceremonies. We have automation to deploy for us, which means we want to make
it easier for the automation to deploy, not necessarily for someone to shell
in and maneuver around with hand installations.

Things being application-centric, the "right" thing is to conform to the
requirements of the dev team's app, not the other way around.

------
PommeDeTerre
This is encouraging to see. If a given port isn't being maintained, and its
security is haphazard to begin with, removing it is a very prudent course of
action.

While I know I can't trust Ruby and the Rails communities to do the right
thing, I know with much more certainty that I can rely on the OpenBSD
developers to.

~~~
byroot
I see your numerous FUD posts about Ruby, Javascript & others since a few
weeks now, and I'm curious:

What is your magical langage / technology that never had any security holes,
nor any misconception ?

~~~
zzzeek
The choice of "security as an afterthought" and "never had any security holes
ever" is a false choice between two extremes that don't actually exist (well,
at least the second). The poster is referring to two very different approaches
to software security. OpenBSD's approach is considered to be the most
uncompromising in the industry, and goes further than probably most of us
would prefer to go, but nonetheless serves as a good example of what's
possible. You can read about it here: <http://www.openbsd.org/security.html>
and there's also some good papers/presentations here:
<http://www.openbsd.org/papers/> .

~~~
wmoxam
I love openbsd but even their proactive approach hasn't made them immune to
remote exploits

~~~
mpyne
It's not about total and complete _prevention_ , it's about reduction of risk.
Your logic taken to its logical conclusion would argue against practically any
risk mitigation measures at all. For instance, even SSL/TLS have not been
immune to exploits.

------
tedunangst
Fun fact: January 11 was three weeks ago.

------
SEJeff
I'm curious how many people run RoR on OBSD web servers. I suspect it exists,
but very rarely

~~~
protomyth
I did for a while, but as the patch suggests, it is probably a better idea
just to install using gem. There is really no need to have rails in the ports
as it doesn't require any special compilation to run on OpenBSD.

~~~
jzwinck
Ironic to see this suggestion when this post is immediately below one on the
front page saying rubygems are not safe to install. It would be too bad if the
security savvy BSD folks pushed their users into a worse situation by using
gem.

~~~
byroot
It's not the role of OpenBSD or any other distribution to provide those gems.

I don't know anyone that rely on system packaging to get gems or eggs or CPAN
module. And it would be silly because you can't run an arbitrary ruby/python
app with and arbitrary version of gems.

And IHMO Debian should take the same decision and stop packaging gems and
eggs.

------
electic
If I am reading this right, this title is wrong. They are talking about
dependencies.

~~~
homosaur
Rails is almost entirely a wrapper for these components like ActiveModel and
Sprockets and such. You can use them apart from Rails but that's why they are
all on the ports tree. It's probably the only thing that uses them.

~~~
steveklabnik
> It's probably the only thing that uses them.

This is very much not true for many of the components. I have a few gems that
rely on ActiveSupport and ActiveModel, Sprockets has integration with other
frameworks, etc.

That said, you're right, the 'rails' gem is really a meta-gem that installs
all the right versions of the other ones.

~~~
homosaur
Yeah but are those other gems in the OpenBSD ports tree? The point is not that
they are not used for other things but that they are probably not used in
OpenBSD

~~~
steveklabnik
Ahhh probably not. Good point.

