debiancdn

AWS, Content Delivery Network and Debian

月別アーカイブ: 2月 2013

LinuxのDistributionは結果で判断されるが、その結果までの道を示すと免責されればいいのに。

先日、Cloudpackさんでイベントがあったのでしゃべってきた。
Cloudpackのsuz_labさんは、随分昔からCentOSベースでカスタマイズしたAMIを作成している。

彼はその取組というかロードマップを話をした。
自分はその話を聞きながら、コメントを付ける形で発表するとおもしろいかとおもって話をしてきました。

正直いって、LinuxのDistributionを真面目にやるのは大変すぎる。
入ってるあらゆるプログラムの脆弱性に対応しないといけないし、どうかするとプログラム自体の使い方がわからないとい言ってくるような人も相手にする状況にも陥る。

自分のDistributionはどんなもので、どのように作ることができるかを宣言していれば何かがあったときにでも「免責になる」というような判例や事例でもあればもっと強く言えるとは思う。

macosxのbrewでいれたruby1.9のgemでいれたrailsのパス解決の方法がスマートじゃない

brewでrails1.9をいれている。結果、

/usr/local/Cellar/ruby/1.9.3-p374/bin/ruby

となっている。

gem install rails

をするとインストールはされるのだがrailsにパスが通ってない。

gem e をすると

$ gem e
RubyGems Environment:
  - RUBYGEMS VERSION: 1.8.23
  - RUBY VERSION: 1.9.3 (2013-01-15 patchlevel 374) [x86_64-darwin11.4.2]
  - INSTALLATION DIRECTORY: /usr/local/Cellar/ruby/1.9.3-p374/lib/ruby/gems/1.9.1
  - RUBY EXECUTABLE: /usr/local/Cellar/ruby/1.9.3-p374/bin/ruby
  - EXECUTABLE DIRECTORY: /usr/local/Cellar/ruby/1.9.3-p374/bin
  - RUBYGEMS PLATFORMS:
    - ruby
    - x86_64-darwin-11
  (以下略)

という具合でEXECUTABLE DIRECTORYにパスは通してある。

結局うまい方法が考えつかず、

$ ln -s /usr/local/Cellar/ruby/1.9.3-p374/lib/ruby/gems/1.9.1/gems/railties-3.2.11/bin/rails .

で、いいことにした。