OSC2005-Fall
OSC、オープンソースカンファレンスに行ってきました。
場所は大久保の日本電子専門学校。いきなり駅の出口逆に行ってしまい迷いました。
OSCは展示会+セミナーで、セミナーは何個も並列して行われるので
どれに参加するのかを事前に予約しておきました。
最初は展示ツアー。
これは展示会場の各ブースにまとめてどばっと行って説明を聴くというもの。
個人で行くとなんか場の空気的に躊躇してしまったり、
まともに説明してもらえなかったり、ということがありがちですが
まとめて来られると流石にちゃんと説明しないわけにも行きませんよね。
欠点としてはちょっと距離が遠いと声が全然聴こえなくてさっぱりなところかな。
回ったところはOpenOffice,もじら,MySQL,PostgreSQL,Ruby,Zope,Xoops,vi,Fink。
Postgresの説明聴いてる時に後に貼ってあった看板が絶妙なタイミングでガタッと落ちて笑えました。
Zopeは内蔵DBらしいけどパフォーマンスはどうなんだろ。
ZETA。
2時間目はZETA。
講師の人が外国人だったので英語だと思ってたのですが、ばりばり日本語でした。
「などなど」とか普通口語では使わない表現とかもあって微妙に癒し系でした。
つか日本語なんだったら1時間目もZETAに参加すれば良かった…
2時間目はZETAの一般的な使い方の説明だけど、
1時間目はZETAでの開発の話らしいので英語はついていけないかなーと思ってたのですが。
でまぁZETAは良いですよ。アトリビュート(メタデータ)最高だね。
ファイルマネージャが住所緑にもなるしメーラにもなるし…可能性はいくらでもある。
アトリビュートは常時インデクシングされているので検索はかなーり高速とのこと。
あとアイコンがSVGで大きさ自由自在だったり。
ディスクボリュームアイコンに使用率グラフがリアルタイムで表示されてたり。
こういうのは地味だけど重要な機能だと思う。
多分今のWindowsだと頑張ってもこういうことってできないよね。
次期WindowsやMacもメタデータ扱えるようになるんでしたっけ。
そうなるとアトリビュートにも互換性が欲しくなってきますが、
後発ながら力はずっと強いWin/MacがZETAに合わせてくるとは思えない罠。
トランスレータという機能もなかなか素晴しい。
これはOSによるデータ変換のサポートで、
D&Dでアプリ間のデータの受け渡しが非常に柔軟になるっぽい。
個人的にはD&Dという操作はあまり好きではないので、
本当に便利なのかはまだちゃんと使ってみないとわからないけど、
PDFの図なりテキストなりを選択してデスクトップにD&Dして、
できたファイルを更に別アプリの中にD&Dとか、ちょっと感動。
BeShareというファイル共有ソフトはアトリビュート対応なのでいろいろ便利そう。
GobeというOfficeライクなソフトもバンドルされててワープロ・表計算・プレゼンツールはOK。
ターミナルは標準でbash。
ターミナル内でのアトリビュートの扱いについてはどこまでできるのか気になったのだけど聞けなかった。
現状ZETAはホームユーザ向けでビジネス用途はあまり狙っていないらしい。
ドイツでは10万人ものユーザがいるとか。
3時間目はOSASK。
立ち見の人続出な人気ぶり。
極小・高速なOS。
OS本体76KB! 1秒で起動完了!
機能的には実用するにはまだまだなのだけど、
それは開発者の川合さんがサイズと高速性について異常なまでの拘りがあるからだと思う。
効率性100%を目指しているとのこと。
CPUのセグメンテーションという機能を活用していることをさかんに売りにしていたけど、
いまいちセグメンテーションとは何かが理解できませんでした。
設計上面白いところとしてはメモリ管理をファイルと同様に扱うというのがありました。
fopenで確保してfread/fwriteで読み書きとか。
リソースのハンドルを渡すのではなくハンドルのポインタを渡すAPIにしてあるとかいう話もしてましたが、
あれもいまいち理解できませんでした。多分わかる人にはなるほどーな内容だったのでしょうけど。
あとは圧縮。OS標準対応でtek5という独自アルゴリズムを使ってます。
プログラムも圧縮データ+展開ルーチンという形式になっていて起動時に展開するようになってるらしいです。
そういやGBAで動かそうとしているとかそんな話も出ました。
川合さんのプレゼンは熱すぎでした。そして楽しすぎ。
なんというかソフトウェア開発に対する姿勢が凄く純粋。
子供の無邪気さというか。
コンピュータ大好きなんだろうなぁと。
こういう人生の過程としてプログラムを作っていきたいものです。
生活は厳しいのかもしれないけど、僕は物凄く憧れました。
4時間目はRuby。
ソース添削。
ライトニングトークスに行こうか迷ったんだけどこっちにした。
なーんか知ってることばかりだったのが残念。
私もRuby使い始めて2年になるので基本は大体押さえられてるってことですかね。
青木さんは細かいコーディングルールや統一性のなさが気に入らないので
直したってのがけっこうありましたが、僕もあれはすごく感じますね。
特に統一性のないソースはかなりストレスになります。
でも仕事だと変えちゃいけなかったりするんですねぇ…あー嫌だ。
統一性が取れないのはルールがないからであって、頼むからメタドキュメントを作れやと。
if notはunlessだろ、とかif-elsifじゃなくてcaseだろ、とかその辺はけっこう微妙なところですね。
確かに少ない単語の方がわかりやすいし意図を明確にするために構文を使い分けた方がいいというのはあるのだけど、
Ruby使う人は全部の構文知ってなきゃいけないの？という話になるわけで。
言語仕様ならまだしもライブラリまでそうなるともう前提知識が多すぎて、それはちょっと違うだろということになってしまいますね。
線引きが微妙。
個人で書いてるんだったら自分のレベルに合わせて気が向いたらリファクタリングすればいいだけの話なんですが。
あとはMONAのストラップ買いました。見た目しかわからんけどMONAも凄いよなぁ。
そういやZETAてオープンソースじゃなくね？とか当然の疑問が沸きましたがまぁいいや。
懇親会は迷ったけど結局行きませんでした。
知っている人が誰もいないとちょっと疲れてしまう可能性が高いので。
>いまいちセグメンテーションとは何かが理解できませんでした。
その場で聞いた訳じゃないのでアレだが、ようするにインテルン用語で言うところの
セレクタかと。これは、リアルモード（16bit MS-DOSの時代）で16Bごとにメモリを
アクセスするオフセットをずらせるようにすることで、最大1MBのメモリ空間をアクセスできるようにしたものだ。
ようするに、セグメントをsgとして、ポインタの中の人をptとすると、物理メモリアドレスは、
(sg * 16) + pt
になる。これは、
(sg << 4) + pt
とも書ける。んで、この法則を使えば、sgが16bitなので、
65536 * 16 = 2 ^ 16 + 2 ^ 4 = 2 ^ 20
となり、ようするに、1MBとなる。なお、
2 ^ 20 = 2 ^ 10 * 2 ^ 10 = 1KB * 1KB = 1MB
だぞ、と。んで、豆知識として、sg = 0xFFFF の時、pt = 0x0010 なら、
0xFFFF0 + 0x0010 = 0x100000 ?
となり、1MB以上をアクセスできそうだが、じつはA20ラインをOFFにしてると
ラップアラウンドで上のアドレスは0になる。
こういうトリッキーなことを利用してBIOS設定を書き換えたりしてるのがあって、まぁ
動くだの動かないだのが出てきたりすることもまれにあった。エミュでだがな～
OSASKはBIOSとか割り込みとかFDDCとかの資料を～と思って出会ったことはあった。
今はチェックしてないんで動なのか全く分からんのだが、実用になるまでの時間つのは
残す所どのくらいなのかしらね。
ま、OS開発はいろいろアレだし、何よりもwin32のものが（そして、遅れれば
win64との互換性までも問題になるだろう）動かないと広まることはありえないので、
そこん所が重要ね。
まーあとは、ドライバーとかの動的なロードとアンロードとかそういう話は
あるんだろうか。エミュＯＳとしてOSそのものがエミュで～つう設計思想つか
そのあたりの文章は、実はなぜか読んでいたりしないでもない。ちなみに、
その時にメモリマップトを推奨していた所とかがあったが、実は欠点もあるんだよなぁみたいな
感じだった。普通の状況では欠点にならないけどな。
まぁあとはソースコードの書式とかの話もあるが、かなり長くなるので簡略化して書くと、
ソースコードの書式を何から何まで共通化させると、開発効率は大幅に落ちるし、品質も
低下する。なので、読む側が利用できるフォーマッタを用意しておいて、
どうしても作り手と読み手が異なる場合に、一括でフォーマッタをかければ良い。つ感じ
の意見です。私は。
移転したらTBとかで自分のエントリに長々とかけるようになるんだが、
いろいろあってもう暫く先になりますん。つわけで、長文すまんと。
送信してから致命的なことに気付いた。勧進のセレクタの説明をしていないじゃないか！！
つ訳でなるべく簡潔に。
MMU(メモリ管理のハードウェア）の持つ機能はいくつかあって、代表的なのは、
「ページ化」と「セグメント化」な訳だ。「ページ化」つのは、メモリを
ある特定の大きさに分割して（IA-32は4KB）、そのページを単位として、
アクセス制御や属性や物理メモリへの割り当てなどを管理する機能。一方の
セグメント化は、開始地点と長さでメモリを区分けして、そこにアクセス制御や属性を割り当てる方式。
ページ化は主にスワップなどが必要になる、仮想メモリアドレス管理に有効。つまり、
仮想メモリアドレス（一般には、全てのプロセスが連続した１つのメモリ空間を持てるので、
リニアアドレス空間とか呼ばれることもあるような無いような）を考えておいて、
プログラマはそれを相手にすると。んで、ハードウェアとしては、仮想メモリアドレスに対応する
物理メモリアドレス（本当のRAMのアドレス）をアクセスする。この対応関係は
OSが管理する。
んで、セグメント化は、用途別にメモリを区分けするという使い方が普通（だと思う）なんだが、
インテルンはなかなか味なことをしていて、セレクタ１つにリニアアドレス空間を
生成することを可能にしているので、実は32bitのCPUのくせに、実際の所は
2 ^ 32 * 2 ^ (16 - 2) = 4GB * 2 ^ 15 = 4 * 32768 GB
の仮想メモリアドレスが利用できる。と、書いていて、なんか数字が変だなと
感じている今日この頃。まぁいいや。
とりあえず、１ページ4GBの大学ノートがあって、ページ数が14ビットで表現されるならば、
ページ数とオフセットの組み合わせで、32bitの限界を超えたメモリを扱えるって
こと。ちなみに、PAE(Physical Memory Extension）を搭載したXeonなどは、
物理メモリを最大で64GB搭載できるのは、上のため。
なお、一度に利用できるのはPCの物理メモリ量までなので、ようするにスワップしまくりの
激遅状態になる訳だが、それでもメモリが欲しいなら上の方法で。つ感じ。
なお、Win32では、３つくらいのセレクタを１つのプロセスに割り当てて、
アドレス空間は共有状態だ。なので、どのセレクタでアドレスptにアクセスしても、
同じ結果が得られる。これは、セレクタを、メモリの区分管理にしか使ってないからな訳だが。
スタック用のセレクタを、コード用のセレクタとずらして管理すると、バッファー
オーバーフローの危険性を多少回避できるかもとかそんなこと考えてみるテスト。
特集組んで説明も出来るが、まぁ移転後だな。やるとしても。なお、
内容は急いで書いたので間違いありそう。
詳しい説明ありがとう。
仮想アドレス空間が広がるのが嬉しいということかな。
OSASKの場合はそういうことは言ってなかったと思ったけど。
ソースの話はまぁ意見が違うねと。
私は読む側でなくて書く側がフォーマッタかませばいいという考えです。
ガチガチに規定しろというんではなくて、まずはメタドキュメントを作れと。最初は空でいいんだから。
それでチーム内でここは統一させたいよねという話が出て意見が一致したら書き込むし、
好みが分かれて統一は難しいようであればそれは各自適当にということには当然なります。
ま、64bit化の波に関しては要するにメモリが足りないからっつーだけの話と
いうことも無きにしも非ずなんで。ただ、セレクタ方式だと、ページの切り替えに関しては
プログラマが意識しないといけないという欠点が無きにしも非ずなんで、
まぁ素直に64bit化を待てといった感じか。
あとは、osaskの説明読んでないけど、もしかすると、メモリリージョンをセレクタで構成して、
より細かいアクセス制御とかみたいなことが出来るという話かもしれないかな。