アレゲな新コンソールレイヤ 39
ストーリー by Oliver
3270化 部門より
3270化 部門より
yosshy 曰く、 "Linux kernel 2.5 statusをふらふらと眺めていて、Rewrite of the console layerが目に留まったのでリンクを辿ってみました。このプロジェクトは、既存の問題点を解決しつつ、新しい(怪しい)機能を盛り込もうというものですが、
- １つのシステムに複数のキーボードとグラフィックボード(＋モニタ)をつないで作る、バーチャルならぬリアルなマルチコンソール
- (上記に必要な)キーボード毎のキーマップ定義
- グラフィックボードとキーボードのホットプラグ
- 仮想端末毎に異なるフォントとテキストモード
- 漢字や BiDi の直接表示
など、アレゲ花盛りでなかなか痺れます。CPUパワーがあり余る昨今、学校教育機材用に、本体１つ＋画面３つのシステムなんて如何？"
BiDi (スコア:5, 参考になる)
非ヨーロッパ言語系の人々から見ればかなり独善的なことをばしばし言う人ですが、なぜか、けっこう大きな発言力を持っているみたいです。
が、BiDi に関しての、実装は、BiDi に関するターミナルの動作をきちっと定義してからにしろ [xfree86.org]という意見は、まともな意見に思えます。mlterm [sourceforge.net] は「便利だったらいいや」というノリなので FriBidi を使った BiDi サポートを実装しましたが、BiDi に関しては ライブラリによって動作が微妙に違う [nmsu.edu]ということがあるようで、動作を定義しないことにはその上で動くアプリケーションソフトも作れない、といった状況に陥る可能性があります。
ちなみに、オフトピになりますが、全角文字に関して、彼はこんなこと [xfree86.org]を言ってます。つまり、全角文字を横切るようなカーソル移動コントロールコードの動作について、文字単位にすべきか、カラム単位にすべきか、ということです。MS-DOS プロンプトや N88-BASIC(86) や kterm をはじめ、ぼくが知る限りありとあらゆる日本語ターミナルが「カラム単位」の動作をしますが、それは「文字単位」であるべきだ、というのが彼の論旨です。
Re:BiDi (スコア:1)
M-x terminal-emulator で動作するモードのことです。
Re:BiDi (スコア:3, 参考になる)
が、結合文字がはいってくると、ユーザインターフェースとしてどういう動作が好ましいか、ということ自体が分からなくなってきます。
M-x terminal-emulator の動作ですが、それはシェルの動作に依存するのではないですか?
Re:BiDi (スコア:2, 参考になる)
依存するのですが，terminal-emulator は kterm と同様に
ptyを作るし、依存しないはずです。
terminal-emulator で (tty;stty raw -echo;cat) としておいて
別の端末から 漢字混じりのテキストを対応するttyに
リダイレクトして送ると エミュレータ側にテキストが出ます。
そして \bを送ると、確かに一文字ずつ消えます。
手元の GNU Emacs 20.7.2（X版)で確認しました。
Re:BiDi (スコア:1)
ところで、\b ってカーソルを1カラム (1文字?) 左へと移動させるだけで、文字を消すのではないと思いますが、なぜ消えるのでしょうか?
Re:BiDi (スコア:1)
だから，カーソルがどこまで動いたのかを知るためには，文字を上書きしてみせる必要があるのですよ。
たとえば，
とかやってみて (ここで ^H は Backspace 文字を示す。入力時には Control-V Control-H と打ち込む)，出力が
となるか，あるいは
となるかで，^H 一個で「一カラム」ぶん動いたのか，「一文字」ぶん動いたのか調べるわけです。ちなみに，手元の emacs では後者の動作を示しました。(中間に空白は入りませんでした)
しかしまあ，Backspace の動作の話題になると，毎回，
あたりの話がすべてごっちゃになって出てくるのは，何とも言えませんなあ。
Re:BiDi (スコア:1)
全角文字は 1文字で 2セル分なので、バックスペースで
1文字消した後 1セルしかカーソルが戻らないと半文字のところで
カーソルが止まってしまい、動作がおかしくなるという話です。
エディタ等のプログラマにしか関係ない話と言えばそれまでですが...
Re:BiDi (スコア:3, 興味深い)
ユーザインターフェース的には、文字単位の処理になっていることが必要です。というのは、Shift_JIS や EUC-JP では全角文字についてもバイト数とカラム数が一致していたので、Backspace キーを 2 回押すことでなんとかごまかしが効きましたが、UTF-8 ではそれは一致しないですし (かなやハングルや日常で使う漢字のほとんどは 2 カラム 3 バイト、ロシア文字やギリシャ文字やその他多くの文字は 1 カラム 2 バイト)、結合文字 (0 カラム) なんてのもあります。
まさしくプログラマに関係する話です。エンドユーザにはあまり関係しません。
ところで、カラムとセルってどう違うのですか?
Re:BiDi (スコア:1)
> EUC-JP では全角文字についてもバイト数とカラム数が一致していた
あの忌まわしき(いわゆる)半角カナは2バイトですよん。
＃SS2 + JIS 0201 右半面(MSB on)とでも言うか。
Re:BiDi (スコア:1)
まあ、ふつうは ASCII + JIS X 0208 しか使わないということで。
Re:BiDi (スコア:1)
厳密には SS2 なり SS3 なりは CR やら LF やらと同じ制御シーケンスの一種と (ISO-2022 的には) 考えるべきなんじゃないですかね？ もちろん、JIS X 0201 カナや JIS X 0212 補助漢字は 2 / 3 バイトと数える人が殆どでしょうし、実際そのように考えた方が便利だからこそ eucJP が使われるわけですが。
ところで、こういう用途って UTF-8 (というよりも ISO-10646 そのもの) はあんまり向いてないんじゃないですかね？ 下手にきちんと扱い得る潜在能力があるだけに、却って泥沼化しそうな気がするんですけど。
Re:BiDi (スコア:1)
その通りかもしれませんが、いまは、Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、それが正しく実現できさえすれば、どちらの考えに立っても構いません。
なにが「下手」なのか、「泥沼化」とは具体的にどういうことかが分からないのですが、EUC-JP や Shift_JIS においては偶然バイト数とカラム数が (JIS X 0208 について) 一致するという幸運に恵まれてきたわけですが、そういう幸運に頼ることのできない言語があり (タイ語など; 0 カラムの文字がありますが、それらを 0 バイトにすることはできません)、どうせ「きちんと扱」う必要が出てきます。
Re:BiDi (スコア:0)
>Backspace キーを押したときにシェルが内部バッファから何バイト削除しないといけないかという話ですので、
UIに関しては「1文字削除」で問題ないでしょう。
現在の2バイトの日本語文字も、ちゃんと対応してない環境では2回BackSpaceを押さないといけないことがありますが、
そのような動作を本来望んでいるユーザーはいないでしょう。
まして「UTF-8でもBackSpaceは1バイト削除」なんて考えられません。
ただ、「Unicodeの1文字」が「当該スクリプトの削除単位として望ましい1文字」であるかどうかは別ですが。
ともかく、単純なバイト数より上のレイヤ
Re:BiDi (スコア:2, 興味深い)
なるほど。そうですね。
が、これは Unicode のせいではありません。現実に使われている文字が (全角はさておき) BiDi であったり結合文字であったりするので、 Unicode を使おうと、ISO-2022 や TRON コードなど別の文字コードを使おうと、 文字コードの側でそれをなかったことにすることはできません。
まあ、全部いっぺんにつめこむ「だけ」なら、できると思います。 問題は、各々の言語圏で従来まで使われてきた慣例どうしの擦り合わせでしょう。 誰がどこまで妥協すべきか。
Re:BiDi (スコア:0)
>ぼくが知る限りありとあらゆる日本語ターミナルが「カラム単位」の動作をしますが、それは「文字単位」であるべきだ、というのが彼の論旨です。
Xだけなら (スコア:2, 参考になる)
こういうの出来てたようです。
私はデュアルディスプレイで止めて置きましたが(マシンを共有する彼女がいないもので)
unpush] $ /.
確かによさげ (スコア:1)
確かに教育の現場とかには使いでがありそうですね。
私はそのような教育を受けたことがないのでよく分からないのですが、テレビなどで取り上げられている「IT教育」(笑)の現場では二人に一台とかってのが多いような感じがします。
で、アレって効率が悪かろーなーと思ってるのですが、この仕組みがうまく動けば多少はコスト削減出来そうですね。
将来的にはCPU自体も多重化しそうな気もしますし、有り余るCPUパワーの有効利用としては有望かも。
でも、各ユーザごとに仮装マシン上にWin系OSを載っけてってコトになったら、逆にやたらとマシンパワーを喰っちゃうのでそのために高価なマシンを買ってって、アホなことになるか?(笑)
-+- 想像力を超え｢創造力｣をも凌駕する、それが『妄想力』!! -+-
Re:確かによさげ (スコア:1)
# 書いててむなしくなったけどID
Re:確かによさげ (スコア:1)
同一のキーボードや画面を使いまわすという貧乏臭さ(笑)がペアプロの特徴です。
それを阻害(ぉ)するマルチキーボード環境はペアプロには不要っす!!
#画面配色やエディタやキーバインドすら好みのものを使えないなんて、ペアプロって大丈夫なのか？と心配だからG7
Re:確かによさげ (スコア:0)
オフトピ（Re:確かによさげ (スコア:1)
端末の論理デバイス化を進めてVTAMを…
> (…なんでビクついたんだろうか…)
年齢って奴では :)
みんつ
グラフィックボード (スコア:1)
普通のマシンだとグラフィックボードの
チップFANに手が絡まるとか。
高温になったチップをさわってやけどするとか。
かなりリスクあると思うんだが。。
PCにECC Registeredメモリの利用を推奨します。
Re:グラフィックボード (スコア:2, 参考になる)
もちろん、こっちはハードウェア的にホットスワップ可能なだけで、実際に抜き差しするためにはOS側の支援はきっと必要なんでしょうけど。
Re:グラフィックボード (スコア:1, 興味深い)
ホットプラグといっても稼働中のものをそのまんま引き抜くんではなくて、
RAIDのホットスワップと同様にカードへの電源供給を止めて機能を停止させて（場合によっては冷えるまで待って）から交換という形です。
PCIやその延長であるAGPについては各スロットごとに供給有無を決められたはず（未確認）なので、必要性はともかく「可能」ということでしょう。
Re:グラフィックボード (スコア:0, 興味深い)
どこが同様?、うちのはArrayのHDDは稼動中に引きぬいて交換するよ? と思ったのは私だけか。
#動揺を隠せないのでAC
Re:グラフィックボード (スコア:1)
アレイアダプタですので、同様ではないと断言もできないように思いますが、
これらをホットスワップと称するのは抵抗有りですね。
ホットスワップというからには、システムの動作なんぞは知ったことではなく
好きなときにほいほい抜き差しできるべきです。
ハイエンドサーバ用のマザーボードには本当にホットスワップ可能なPCIスロットが
ぶら下がっていたりするようですが。
＃AdaptecのUW-SCSIケーブル目当てでAAA-131をジャンクで買ったのでID
Re:グラフィックボード (スコア:0)
これって、PCIカードの留め具が電源供給ON/OFFになってるんで
（即時電源オフとはいえ）AAA-131とあんまり条件変わらん気が。
Re:グラフィックボード (スコア:0)
> ぶら下がっていたりするようですが。
電気的に・・・・でしょ？
OSがパニくりますよー、ホントにぶち抜いたら。
IBMの技術で将来的には、自律できるようになるでしょうかねぇ？
Re:グラフィックボード (スコア:1)
USBとかでも可能なんじゃないでしょうか。
Re:グラフィックボード (スコア:2, 参考になる)
PCCardじゃなくてCardBusですがI・OデータのCBMLX [iodata.co.jp]とかが該当しますね。
# USB1.1ではバンド幅が小さすぎるかと。
Re:グラフィックボード (スコア:1)
確かにCardBusだと抜いてもよいですね。
PCにECC Registeredメモリの利用を推奨します。
Re:グラフィックボード (スコア:0)
Re:グラフィックボード (スコア:0)
その為、購入後30分で倉庫行きとなりました。
これが進みに進むと (スコア:1)
Re:これが進みに進むと (スコア:1)
VMware GSX Server [vmware.com]ってのはその方向をめざしたものだと思いますが如何。
Re:これが進みに進むと (スコア:1)
一対一でも多対一でもなくて多対多。
Re:これが進みに進むと (スコア:1)
期限の迫ったプログラムのとき、単純なコンパイルエラーだけでJobが終了してしまう哀しさといったら....。納期が目の前の仕事は、なんとかシステム管理部門に「緊急ジョブ申請」をして間に合わせてたなぁ...
nobuo * Who's gonna die first? *
Re:これが進みに進むと (スコア:0)
Re:これが進みに進むと (スコア:0)
あとは、フロントエンドでチャットしてるだけとかさ・・・。
あ、ちゃんとワープロソフトも動かしてあるか・・・。
実（仮想）メモリーが大きければ、特に問題無し。