FreeBSDのコア部分からPerlが除去される 83
ストーリー by Oliver
ミニマリスト 部門より
ミニマリスト 部門より
k3c 曰く、 "いろんな ところで 話題になって いますが、FreeBSDのカーネル構築に必要なベース部分からPerlを取り除く作業が行われているようです。年末に出る予定の5.0-RELEASEからは、カーネル構築にPerlは必要なくなるとのこと。
Perlをコンパイルしたことのある方はご存じかと思いますが、Perlをコンパイルすると標準のモジュールも一緒にコンパイルされます。FreeBSDの開発チームは、このためにコア部分のファイルサイズが大きくなりすぎることと、Perlがバージョンアップする度にメンテナンスの手間が発生することから、いっそのことコア部分からPerlを外すことにした、別にPerlが嫌いになったわけじゃない、と説明しています。
なお、CDやDVDから普通にインストールすれば、Perlも今まで通りデフォルトでインストールされるそうです。"
-currentでは (スコア:2, 参考になる)
-currentの方では、すでにperlなしでkernelが作れるようになっています。hintsを作るscriptがまだ残っていますが、kernelを作る時に使うものではありません。
また、この変更はMFCされません。4-stableは最後までperlつきです(多分「CDやDVDでは...」は本当はこういう意味?)。-currentでは近いうちにportsなどによってのみperlをinstallすることになります。
Re:-currentでは (スコア:1, すばらしい洞察)
ってぇことは、perlのpathは/usr/local/bin/perlに戻るわけですね。
#!/usr/bin/perlとしてしまったスクリプトファイルは全部書き換えが
必要なわけだ・・・またそれ用のツール作らにゃ。
Re:-currentでは (スコア:2, 参考になる)
pathを直書きしたのが敗因。
としときゃ良かったのにねぇ。ちなみにrubyのソース付属のサンプルスクリプトはみんなそうなってる。Linuxだと/usrbin/rubyだったりするからね。
Re:-currentでは (スコア:2, 興味深い)
/bin/env な環境もちらほらあるようです。
やはり #! 行はビルド・インストールのプロセスの中で
変えてインストールすべき。
Re:-currentでは (スコア:1)
ま、rubyの場合あくまでサンプルスクリプトの話ですからね。「そのまま動くこと」を保証する必要はないかと。だいたい"#!"を使ってたら、Windowsじゃ動かないっすよ(笑)
# CygwinはWindowsではない、と言っておこう。
そもそもこのサンプルスクリプト群には実行フラグ立ってないし。
Re:-currentでは (スコア:2, 参考になる)
こういうのって、 POSIX で決まっていたりしないのでしょうか。決まっていたからといって準拠していないものを切り捨てていいとはならないでしょうが。
鵜呑みにしてみる？
Tcl/Tk では (スコア:1)
# \
exec wish -f "$0" "$@"
本体
という方法を使うそうです。拡張子を .tcl にしておけば、 Windows でも動きます。(Macintosh も対応するためには、 どうすればいいのでしょう?)
UNIX 系で、/bin/sh がない (パスが違うとかファイル名が違うとか) とか言われるとつらいものがありますが。
Re:-currentでは (スコア:1)
の
Re:-currentでは (スコア:0)
Ruby 1.6.7のsample/の下には #!/usr/local/bin/ruby なものもあるのですが、 1.7.xでは変わったんでしょうか？
Re:-currentでは (スコア:0)
だめ？
Re:-currentでは (スコア:1)
自前でportなどを入れるのならばsymlinkでもいいでしょう。releaseで/usr/binからsymlinkを張るというのは、PREFIX != /usr/localという場合がありうるのでなしになりました。
MTAよろしくwrapperをという話もあったけど、どうなったんだか...
Re:-currentでは (スコア:0)
Re:-currentでは (スコア:0)
FreeBSD システムの側で面倒見てくれないの?
Re:-currentでは (スコア:0)
そのくらい何でもないじゃん…
そのくらいめんどくさがっていたら、
FreeBSDで何にもできないような期がするが
Re:-currentでは (スコア:1)
自分でFreeBSDでサーバーを立ててる人に対してなら「そのぐらいやれよ」でもいいと思います。でもホスティングサービスで /usr/bin/perl と決め打ちした cgi を置いて使ってる人に「設置した人が勝手に直すだろ」では可哀想な気も。やはり symbolic link ぐらい張ってあげないと...
Re:-currentでは (スコア:1, すばらしい洞察)
>決め打ちした cgi を置いて使ってる人に
>「設置した人が勝手に直すだろ」
とかだったら、ホスティングしている会社がsymlinkすればいいだけでないの?
それが嫌なら、告知を出せばすむでしょう。
というか、perlのパスを書き換えることもできないような人が
掲示板を設置しているのは、ちょっとどうかと思う私は駄目?
Re:-currentでは (スコア:1)
# >>でもホスティングサービスで /usr/bin/perl と
# >>決め打ちした cgi を置いて使ってる人に
# >>「設置した人が勝手に直すだろ」
# わざわざそこで引用切らなくても... ^^;;;
# なんて事はどうでもいいんですが。
>というか、perlのパスを書き換えることもできないような人が
>掲示板を設置しているのは、ちょっとどうかと思う私は駄目?
いや、駄目ではないと思います。 私も知ってて欲しいと思います。 でもそれは「emailを使うならRFC2822ぐらい目を通しておいたほうがいいじょ」という程度の意味で「RFC2822を理解してない奴はemailを出すな」とまで言う気はないのと同じです。あくまで第三者としての希望(期待かな?)。
# 逆にちょとどうかと思われる人が可哀想だと思う私は駄目？ :-)
Re:-currentでは (スコア:1)
テキストファイルの 1 行目を書き換える「作業」自体はそれほど困難だとは思いませんので念の為。特に perl script を多少でも知ってる人なら全然困難ではないでしょうね。
ただ cgi を設置してる人全てがそうだとは思ってないだけです。perl を知らないでも設置だけなら出来たりします。(実際にそうしてる人を知ってます) そしてそういう人は仮にレンタルサーバー会社が「perlのpathを変更しました」と告知しても修正出来ないかもしれないので可哀想だと思っただけです。
<余談>
html なんて知らなくても自分のサイトを作り、perl を知らなくても cgi script を持ってくる事が出来るご時世ですからねぇ。便利な世の中になったと言うか、不便な世の中になったと言うか...
</余談>
Re:-currentでは (スコア:1)
私は「RFC2822を理解しろ」とも「パスを書き換えられるようにしろ」とも主張してないのに...
あくまで「/usr/bin/perl が知らぬ間に /usr/local/bin/perl になると対処できない人が可哀想だね」と言ってるだけで ^^; もちろん私の下手な日本語を読んでそう考えてるのを理解しろとは言いませんが ^^;;;
# はい、まともな日本語も書けないくせに文句を言っても
# ノイズになるだけなのでこれ以上言い訳なんてしません ^^;
文化の違い? (スコア:1)
堕落できるところは堕落する Linux と、そうでない BSD の文化の違いでしょうか。
Re:文化の違い? (スコア:2, すばらしい洞察)
そんなこといったら、httpdなんて各OSの提供するportsやrpmとかで
インストールされるディレクトリパスが違うぞ。
linuxの場合ディスストリ毎にperlのパスも違うんじゃないか?
どれも同じパスでっていうならオリジナルソースから
インストールすればいいじゃん。
それなら各OS間の違いも吸収できるし
昨今のLinuxのそのいたせりつくせり状態は
堕落させるじゃなくて、
インストール放置猿 量産の温床な気がするんだが
Re:文化の違い? (スコア:1)
個人的には、2.4系カーネルで
- userlinkが動かねぇ
- ipchainsが使えねぇ
という話と何が違うのか判りません。もちろん、この2点に代替手段があるのは知ってます。でもperlの話だって一緒ですよ？perlでプログラム書く人の都合だけは、OSの開発者が考えてあげなきゃいけないものなんでしょうか？今回の一件はあくまでFreeBSD-current、すなわち今年の末頃を予定している開発ブランチからの次期リリース版でのお話です。Linuxで言えば2.5系カーネル。そこのところ、お間違えなきよう。
Re:文化の違い? (スコア:0)
Re:文化の違い? (スコア:1, 興味深い)
堕落の中に「Linuxしか考えない」は入れないでほしいものだ。
「FHS準拠を前提に決め打ち」てのが増えている気がする。
特にGNOME物は、パスがハードコードされまくりでうんざりする。
(せっかくautoconfを使っているのによー)
最初のうちは地道にフィードバックしていたけど、ハードコード
されたものを生産するペースの方が速いからあきらめた。
(FreeBSD portsも、一括置換で対応してたりするよね)
Re:文化の違い? (スコア:2, すばらしい洞察)
けっきょく、Linux は「いたれりつくせり」なのか、 そうでないのか、どっちだと思っているのですか?
ぼくの意見について言えば、Linux 全般を知っているわけではないのに 「Linux」という言葉を使ったのがまずかったです。 少なくとも、Debian では、たとえば /usr/doc から /usr/share/doc にドキュメントを移動させるという作業を何年もかけてやっていますが、 いまだに、/usr/doc/* -> /usr/share/doc/* へのシンボリックリンクを 提供しつづけています。将来的に廃止されるかどうかは分かりませんが。 そういうことを念頭に置いています。 ちなみに、ディストリ毎 (あるいは OS 毎) に違う、というのは問題にしていません。 バージョンアップの際に変更作業が必要かどうか、というのが 視点ですので。もし OS 間の互換性ということを問題にするなら、 各種 Linux ディストリの間だけでなく、それらと各種 BSD の間の互換性ということも問題になってくるでしょう。
インストール猿ですが、 本質的なところで設定が必要なものは、 Linux でも BSD でも変わらないはずです。 むしろ、本質から外れたところ (/usr/bin から /usr/local/bin に変わったので変更作業が必要だ) に気を使わなくていいとすれば、それだけの時間と注意力を ほかの本質的な部分に割り当てることも可能になります。
apache などのサーバを、デフォルトでインストールするか、 とか、インストールするだけで 何らかのデフォルト設定で動作させるべきかどうか、とか、 そのデフォルト設定の内容がどうか、ということは、 インストール猿対策上、重要なことではあるでしょう。 そして、この点については、BSD な人々の Linux に対する批判は当たっていることが多いと思います。 が、いまはその話題ではありません。 というか、/usr/bin から /usr/local/bin に変更するときにシンボリックリンクを張るなどのことをしない、 ということで、インストール猿対策になっているとお考えでしたら、 それは間違っているのではないかと思います。
Re:文化の違い? (スコア:1)
簡単にいってしまうと既存のperl コードを走らせた時にエラー停止したとします。
その症状を診断できない人がコード書いてる現実は問題ですよね。
この原因をつくっているのはOS ではなく多くの入門書であろうと考えますが
「 perl 本体は、システムによって違いますがほとんどのシステムは
/bin/perl
/usr/bin/perl
/usr/local/bin/perl
のどこかにあります 」
ってのが多すぎる。
ドキュメントに関しては、オンラインドキュメントが基本ですが
そこに頼る必然性は無いわけで。
要するに、「これからのFreeBSD はperl が標準で入っていない」
というアピールが問題なのではないかと。
標準で無いモノのsymlink がOS インストール時に存在するのはナンセンスですし
インストール時にコレを作るのもユーザの好みの問題ですよね。
ほとんどのフリーウエアがそうであるように
インストール時にシステムに対してどのような変更がなされたかは
ユーザが自身が確認するモノではないでしょうか？
切り離したモノに対して簡便さや互換性を求める方がナンセンスに感じます。
Re:文化の違い? (スコア:1)
FreeBSD システムにおける Perl のパスが変更になったから、 「ユーザが勝手に作成した」perl スクリプトの変更が余儀なくされている、 というのがいまの状況でしょう。
Re:文化の違い? (スコア:1)
FreeBSD としてはシステムから Perl を切り離したから、もう Perl の面倒は見ません、 各自の自助努力でやってください、 ということなら、それはそれでありでしょう。 ただその場合、「いま」システムの一部とされているものが、 将来もシステムの一部でありつづけるとの信用を犠牲にしているわけですが。 (Perl の次には何がシステムから削除されるのだろうか...)
まあ、/usr/bin/perl から /usr/local/bin/perl という、どちらも「ありえる」パス同士の変更だから、 いいのかも。/usr/bin/perl から /usr/oreno/katteda/perl だったら、そうもいかないけど。
Re:文化の違い? (スコア:2, 参考になる)
Perlは何時から"FreeBSDのシステム"になったのでしょう。
便宜上同時にインストールしている『外部』ソフトウェアに過ぎないものが不要になったから外したよ、ってことでしょ？
だから
>「いま」システムの一部とされているものが、 将来もシステムの
> 一部でありつづけるとの信用を犠牲にしている...（略）
は、勝手に期待するな、って事で必要であればインストールし、不要であればそのままで良い、って事だと。
スクリプトの１行？
lnするにせよ、スクリプトを直すにせよ、それは管理者（運営者）の仕事であってＯＳディストリビュータの仕事では無いと思うのですが。
# 例えばHTMLはXHTMLでタグに大文字が使えない様に規定されたと
# 思いますが、何時までも「タグに大文字が使えるって信じてた」
# って言うのと同じ気が
Re:文化の違い? (スコア:1)
オプショナルで、/usr/bin/perlをインストールしてくれるものを提供した方が親切ではあるでしょう。
＃が、upgradeインストールしたら、どうせ/usr/bin/perlのこっちゃうからまあええやん、というのはだめか？
Re:文化の違い? (スコア:1)
> すべからく UNIX 系の OS は Linux に合わせなければいけないとでも?
待ってくれ、FHS は Linux 専用の標準ではないよ？
Unix-like operating systems についての標準なんだが。
(ちなみに Linux のディストリビューションの中には FHS に準拠しているものもあるし、
していないものもある)
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:1)
だったら、用が済んだら削除しておけばよかったでしょ。
そうでなければ「この perl は一般の用途で利用すべきではない」とか
ポリシーマニュアルに付け加えておくべき。
で、ポリシーにもない、削除もしなかったことを考えると、
当然その perl を一般に利用して欲しかったんだろう。
> # 例えばHTMLはXHTMLでタグに大文字が使えない様に規定されたと
> # 思いますが、何時までも「タグに大文字が使えるって信じてた」
> # って言うのと同じ気が
「大文字は XHTML では間違い、でも一応表示するよ」というブラウザと
「間違いなので XHTML を書き直さないと表示しないよ」というブラウザ、
一方のやり方が間違ってる、というものではないと思う。
＃ブラウザなら、「ページは表示されるが警告が出る」ということにして
＃ユーザに注意を促し、順次移行させる、という手段もあるかもしれないが…
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:1)
> > 便宜上同時にインストールしている『外部』ソフトウェアに過ぎない
便宜上同時にインストールしただけのものじゃないよ、
その後ユーザが使うことも考えられてるよ、
と逆説的にいってるんでしょ。
> あるいは「使っちゃダメ。使いたいなら別途いれろ」になりますが、
それを言ってるのはこっちの発言 [srad.jp]。
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:1)
> UNIXベンダ・コミュニティへの呼びかけはあったの？
返す言葉もございません。が、
> というか、*本当に* Linux以外で受け入れ可能なもの？
それについては
Debian BSDのML [debian.org]で語られてたっぽい。
＃まだ結論まで読めてない。
# mishimaは本田透先生を熱烈に応援しています
Re:文化の違い? (スコア:1)
どの ac を信じたらいいものやら。 というか、どれとどれが同一人物?
Re:文化の違い? (スコア:1)
たしかにそれは問題になりますね。ただし、如何ともしがたい、 というほど難問でもなくて、たとえばバイナリは /usr/bin/perl4 とか /usr/bin/perl5 とかでインストールするようにして、 /usr/bin/perl -> /usr/bin/perl5 とかいうふうにリンクを張るようにして、 複数のバージョンの perl をインストールしようとするとどちらに symlink するかを尋ねてくるようにしておく、とか。 (後から入れたほうを優先、などの決め打ちでも構わないと思うけど)。
まあ、(Perl に対して) バージョンアップのときに仕様を変えるのはやめてほしいな、 という話もあるけど。
そうですね。 perl の ports をインストールすると自動的に /usr/bin/perl -> /usr/local/bin/perl ができる、というのがいいかもね。
なるほど、そういうのが方法がありましたか... それでもいいですね。 (新規インストールのときにはたぶん問題にならないだろうし)。
Re:文化の違い? (スコア:1)
これは、/usr/bin/perlがなくなりました、というときの作業とそうかわりないのではないでしょうか。
Re:文化の違い? (スコア:1)
> /usr/local/bin/perl に変更になるのではないのですか?
そうとはいいきれないところがあるということでしょう。
/pkg/binとか/opt/binがすきなひととかもいるし。
ただ、おおくのひとはpackages/portsのデフォルトである/usr/local/binにいれることになるでしょうね。
また、4系統でもperl5.6をつかってるひとは、5にアップグレードしても、/usr/local/bin/perl(とか/opt/bin/perl)とかのままパスはかわらないかもしれません。
> 今後も Perl のパス名は /usr/bin/perl なのですか?
そういう選択もできます。
> どの ac を信じたらいいものやら。
むずかしいところです。多分みんなそうまちがったことはいってないとして妥当なモデルをかんがえるしかないかしら。
Re:-currentでは (スコア:1, 興味深い)
ユーザコミュニティ的にはそれでその場は解決するし、それが
正解だけど、そこで止まったらBSDじゃないと思う。
ユーザの中から「なんでこんなに腐ってるんだ」と怒るのが出てきて、
改良案とパッチを引っ提げてデベロッパーデビュー、とならなきゃ。
# 今回のはPerlのパスの一件はあまりに些末な問題だけど。
Re:-currentでは (スコア:1)
そうこうしているうちに、markmがperlをMakefileから外しました。src/Makefile.inc1 rev 1.278 [freebsd.org]とsrc/gnu/usr.bin/Makefile rev 1.67 [freebsd.org]です。
強力すぎるのも困りもの (スコア:2, 参考になる)
サイズやシステムのmakeにかかる時間というのもありますけれど, perlぐらい強力なツールが有ると, クラックされたときの危険性がかなり上がりますから, 使わずにすむならその方が良いという用途は多いと思います(特にjailを構築するような場合)
え, gccが入っていたら同じだって? ははーっ, 御説ごもっともです.
Re:強力すぎるのも困りもの (スコア:1, 参考になる)
Re:強力すぎるのも困りもの (スコア:1)
sh単体ではシステムコール, 特にIPCやネットワーク周りのシステムコールを呼び出すことはできませんが, perlではそのあたりが一通りできてしまいますので危険度が桁違いに高いです.
perlが無い場合に同様のことをやろうとすると, Cのソースを送り込んでコンパイルして実行するということが必要になるので, コンパイル環境が無ければかなり安全になります. でもFreeBSDのシステムのMakefileを眺めてみたのですが, コンパイル環境をインストールしないためのスイッチがちょっと見つからないので, 私がjailを作る際には手抜きでコンパイル環境毎インストールしてしまっています.
Re:強力すぎるのも困りもの (スコア:1, すばらしい洞察)
Cのソースを送り込んでコンパイルして実行するということが必要になるので, コンパイル環境が無ければかなり安全になります.
結局バイナリで送り込まれたら一緒なので、それほど違うかなぁ？って感じはしますが。。。（手順を増やすのは良い事だと思うけど）
そのほうが個人的趣味には合うんだが (スコア:1)
驚いた日が懐かしい。あの日以来、カーネル再構成す
ると何か違和感を覚えるようになった。
インストールが便利になっていくのには、慣れていく
のが嬉しかったけど、あのperlにはまだなじめない。
BSDはいつまでも昔のBSDの雰囲気を残していて欲し
い。絶対にLINUXみたいにはなって欲しくない。
実は、みんな、そう思ってるんじゃないかなあ？
Re:そのほうが個人的趣味には合うんだが (スコア:1, おもしろおかしい)
やな意味でいたれるつくせり (スコア:1)
/usr/local/binにはあらかじめ
* cd /usr/ports/lang/perl(かな)
* make install && $*
をするシェルスクリプトをおいておくとか
(最後の行はうまくいくか不安)
はじめてperl(/usr/bin/perl)を実行したのが一般ユーザだとエラーになる罠になりますが。
-- やさいはけんこうにいちば〜ん！
/usr/bin/perl にしたいなら (スコア:1)
と思って archiver/arc の ports で実験してみたんですが、PREFIX=/usr だと、man を /usr/man/man1 とかにインストールしようとしてしまいます(^^;。う～む。
Re:/usr/bin/perl にしたいなら (スコア:3, 参考になる)
/usr/ports/Mk/bsd.ports.mk にとかいうのがありますね。
/usr/bin/perlはラッパーになりました (スコア:1, 参考になる)
見つからない場合、 pkg_add -r perl でインストールするようにとの説明が出ます。
ということで、とりあえず（5.0-RELEASE で最終的にどうなるかはわかりませんが）一件落着ということで。