既知の不具合
開発メモ
223: 65* [load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"] /usr/osxws/share/guile/1.8/srfi/srfi-1.scm:223:1: In procedure dynamic-link in expression (load-extension "libguile-srfi-srfi-1-v-3" "scm_init_srfi_1"): /usr/osxws/share/guile/1.8/srfi/srfi-1.scm:223:1: file:"libguile-srfi-srfi-1-v-3", message: "file not found"といって動かない。 すると gnutls が作れず lftp が作れなく なる。 しょうがないので -disable-guile でしのいだ。
最近の autotools も動きが微妙で、 cross compile させるのが難儀している。
@try{}@catch{}@finally{} に変更して 10.6 へ移植した。
OSXは、管理者＝ユーザというシチュエーションがもっとも一般 的ですが、OSXWSは大学などの端末で管理者が一括管理できると いうことも想定しています。OSXのユーザは、通常ユーザと管理 者の2種類が用意されていますが、OSXWSは/usr以下にファイルを 置くためsu権限が必要という状況です。 まず、大きな違いでは ないですが、/Applications/OSXWS/以下のアプリのアクセス権を su権限ではなく、OSXの管理者ユーザ権限でインストールしてお いてもいいのではないでしょうか？一般的なユーザはこのような 動作を期待していると思います。
また、OSXアプリは、もともと依存関係などの不整合は考えられ ないので、バージョン管理もユーザがアップデートしている可能 性もあるけど、apt-getでも一括でupdateできるというポリシー でうまくいくような気がします。マルチユーザ環境での、通常ユー ザはいずれにせよアップデートする権限はないですし。-Seto
重要な事は、OSXWS の利用者が戸惑わないようにする事（フェイ ルセイフの思想）と「環境」の一貫性を保証する事、です。
それを考えると、アプリケーション独自の自動アップデート機能 を省くのが最もリーズナブルです。手間はそれほどではありませ ん。-Tkoba
実際の OSXWS の利用者（計算機に詳しくない私の近くの物理屋 さん）の利用状況を見ると、一旦仕事の環境ができてしまうと不 具合が生じない限り、手元のソフトのバージョン等は気にしない ものです。そのような大多数の利用者が戸惑わないようにするに は、利用者の不意の操作が OSXWS 管理下にあるものの一貫性と 整合性を崩さないようにしなければなりません。少なくとも、 OSXWS で入れたものを普通に使っているだけなのに OSXWS で構 築した環境の整合性が損なわれる事態は避けねばなりません。
瀬戸さんの思い描いている状況の良さはわかりますが、OSXWS の 最も重要視する視点は「利用者が計算機のお守りから解放されて 自分自身の仕事に集中できる環境を作る事」にあります。ここが 他のディストリビューションと一線を画するところだと自負して います。このことと、私自身のリソースで実現できる範囲内に物 事を収めるバランスが大事です。-Tkoba
これは例えて云えば、一般のソフトウェア開発者はある意味で大工さんであり、 あらゆる地域で住まう事が可能な家を設計するようなものだからです。 寒冷地の北海道から温暖な沖縄でまで「対応可能」な家を理想として 設計するでしょう。
その一方で、OSXWS のようなディストリビューションは、 云ってみれば「京都市」を都市設計し行政サービスを行うようなものです。 ゴミの出し方などの生活に密着したものから、 上下水道・ガス・電気等のインフラの仕様策定と実施・監督までおこない、 「京都市」内にある建物が機能して市民の生活の快適性を最大化するのが 仕事です。 その為にはどのような建物でもある程度「京都市用」にデフォルトから 仕様変更が必要になります。
つまり、個々のソフトウェア開発者は開発物の汎用性を重視しますし、 ディストリビューターは全体の整合性と環境を利用する立場での一貫性を 重視します。
大事なのはそれぞれに限界がある事です。
昨今のソフトウェア開発は、従来のソフトウェア開発の手法をそのまま 環境の整備にまで押し広げようとしています。 TeX live がその好例でしょう。 私に云わせれば「大工さんが外交問題までとりしきっている」ようで ....滑稽に見えます。
かつて mulitcs が破綻して UNIX が誕生したように、 ソフトウェア開発の現場でも「大工さん」と「行政サービス」の分離が 近い将来必要になるでしょう。
一方で、ディストリビューションとしての限界もあります。 rpm とか deb と云った管理ツールの問題ではありません。 それは「京都市」として作ってしまったら、 それはあくまで「京都市」であって、同時に「那覇市」にはなり得ない、 と云う事です。 つまり、その都市の人による好き嫌いは、どうしようもなく出る、 と云う事です。
特に、計算機の世界では、スキルのある人は自分の住み心地の良い環境を 自分で作る事が用意にできるので、他人のお仕着せを好まないのは 当たり前の事なのです。
だからなのでしょう。ディストリビューションと云う ある意味でメタなソフトウェア開発そのものが情報処理の学問分野で 注目される事はこれまで....ありませんでした。 (Linux box を rpm や deb を使わずにすべてソースから構築する事を ほんの少し想像してみれば、rpm や deb などがどれ程画期的なものか 解る筈でなのですが、.......)
私が OSXWS の web 上で姉妹ツリーを呼びかけているのは、 さまざまな「都市」があってしかるべきだと思うからです。
OSXWS はいわば MacOS X と云う大きな国の中の一つの自治州のようなものです。
開発元が直接公開している hoge.app は MacOS X 国向けの 建て売り前の住宅のようなものであるとすると、 OSXWS として再配布される hoge.app は、OSXWS 州の認定と保証と 必要な改修が済んだ即入居可能な住宅に相当するでしょう。 大事なのは MacOS X/hoge.app と MacOS X/OSXWS/hoge.app とは 別物であると認識する必要が「行政」にはある事です。 /Applications/OSXWS を作ったのは、それを利用者側にも 明示的に示す意図があります。
私は OSXWS のディストリビューターですから、 この「行政」の視点を守るのが務めなのです。 それをしなければ、早晩「都市」はスラムになります。
........
> そもそもOSXの場合、OSとアプリケーションという2つの関係しかない
わけですが、
> OSXWSは、ディストリビューターという3つ目の存在ですから、
> そのあり方を考えるためには最初から考え直す必要があるということ
ですね。
....大多数の目からすればそうなのでしょうね。 しかし、一歩引いて考えてみてください。
全てのソフトは「配布されて」初めて使えるようになる訳です。 そしてその配布先には必ず前提とされる「環境」がついて回ります。
私からすると Apple は立派なディストリビューターです。 しかも、ディストリビューターとは何ぞや、と云う本質的な問題に 答えを持っている数少ないディストリビューターだと思います。
ただ、これまで見えにくかったのは、まだまだ計算機環境の本質が ある意味で原始的な状況を引きずっているからだと私は思います。
たとえ話ですが、村が世界だった太古の社会を想像してください。 村のインフラ、例えば水をどうするか等は、村人が集まって議論して、 長老が結論を出してそれに従う方法でうまく行っていたでしょう。 このような状況では「行政」の概念が発生する訳がありません。
しかし、生活の要求水準が上がり、活動範囲が広くなると、 調整役としての行政が必要になってきます。
昨今の計算機を取り巻く状況は、
複数の計算機を有機的につないで利用しようとしています。
いま正に計算機の世界はこの転換期を迎えていると思っています。
http://www.finkproject.org/doc/packaging/fslayout.php?phpLang=ja
http://trac.macports.org/wiki/FAQ#defaultprefix
議論と要望
\usepackage{pdfsync}もtexファイルに記述しています． -Hashi 2010
年12月25日 (土) 01:14 (UTC)
$ pdflatex -synctex=1 hoge.tex -141.40.107.12 2010年12月
23日 (木) 11:42 (UTC)
$pdflatex -synctex=1 pdflatex: unrecognized option `-synctex=1'
This is pdfeTeX, Version 3.141592-1.21a-2.2 (Web2C 7.5.4)
-Hashi 2010年12月23日 (木) 11:38 (UTC)
% emacs -nw Fatal error (11) /usr/osxws/bin/openemacs: line 9: 155 Abort trap /Applications/OSXWS/Emacs.app/Contents/MacOS/Emacs "$@"-133.19.129.23 2010年4月16日 (金) 13:19 (UTC)