超漢字V、10月27日発売 133
ストーリー by GetSet
大地を揺るがす超漢字 部門より
大地を揺るがす超漢字 部門より
TRON曰く、"パーソナルメディアがBTRON3仕様OSの製品、超漢字Vを10月27日より発売します。前回までのバージョンでは、基本的にOSとして単独利用する製品でしたが、今回のバージョンからはVMware上での利用を前提とした製品の様です。価格は18900円。
超漢字はウェブやマルチメディア関連が非常に弱く、恐らく大部分の利用者からすると他のOSと併用しないと非常に不便なので、良い改訂だと思われます。普通に漢字を扱いたい人や、ハイパーテキスト環境を利用してみたい人は一度試してみると良いと思われます。
ただし、扱えるデータの数が最大で65536と非常に少ないという欠点は解消されていないので、利用には注意が必要です。"
大地を揺るがす超漢字部門 (スコア:5, おもしろおかしい)
実身・仮身システム (スコア:4, 興味深い)
坂村氏はこの仕様を拡張する気がない [wikipedia.org]ようですね。
TRON には詳しくないのですが、いまどきのOSとしてはこの仕様は余りに貧弱だと思います。
坂村氏の思想は好きですが、スーパー301条をいつまでも根に持っている上、
TRONの核となる部分が当時のままで今となっては古臭い気がします。
# 私が無知なだけで実際はそんなことはないんでしょうけど。
健ちゃんの言動 (スコア:5, 参考になる)
坂村健という人は今のところ、今はBTRONに注力していないので、BTRONは拡張する必要はないと言っていますが、仮に拡張ができる様な状態になると、一転して、ファイルがこれぐらい扱えるのはコンピュータとして、当然だと言い始めます。
ユビキタスコンピューティングを実現するという大目標事態は変えないものの、細かい部分については、その時、進めているものや、手を組んでいる人たちに応じて、ガンガン言動を変えるので、細かい部分を気にしてはいけません。長年見てるとこの傾向があるのがわかります。
ある時はマイクロソフトをたたき、今はT-Engine関連で手を組んでいるので叩きません。ユビキタスコンピューティングさえ実現できれば、わりと細かい部分はどうでも良いと思っている人の様なので、真面目な人には毛嫌いされるかなと思います。笑いが取れれば良く、空気に合わせて意見を変えるお笑い芸人と同タイプの人です。
いつも主観で書き込んでいます
Re:健ちゃんの言動 (スコア:1)
『その都度言動を翻していくタイプのひとだよ』と言いたいだけじゃないですか。
なんか無い揚げ足取ろうとしているみたいで、モヤっとしたのでID。
＃『叩いてますが』何だというのか。
# 今日から貴方の幸せな日々が始まりますように。
Re:健ちゃんの言動 (スコア:1, すばらしい洞察)
Re:実身・仮身システム (スコア:4, すばらしい洞察)
ウザイ信者連中も含めて、実際、この件についてはこだわりすぎだと思うね。
もしあの時点でスーパー301条で指名されてなくて、TRONが日本の教育市場に
入り込んだとしても、どのみちDOS/V(とWindows)の黒船は迫ってきていたわけだし、
ただ単に日本のパーソナルコンピューティングがTRONが普及している間だけ、
まるごと遅れてただけだと思うんだよね。
下手をすると完全に世界の情勢から孤立してしまっていた可能性も
あるわけで、俺としてはむしろその方がよかったんじゃないかって思うよ。
そもそもTRONの将来性に自信があるんだったら、TRONを導入した場合の
メリットを単純に世間に訴えつづければいいだけの話なわけで、
不当な扱いを受けたなんて言う必要なんて無いと思うんだよね。
やっぱり健ちゃん自身があんまりBTRONに自信がないのかなぁって思うんだけど、
でも、どうやら健ちゃんはそういう態度は変えそうもないみたいなんだよね。
このままじゃ、近い将来に「もうっ、おじいちゃんたらまた言ってる!」って
突っ込み入れないといけなくなるんだろうかね？
マッドサイエンティストになりきれなかった科学者の悲哀って言うか？
Re:実身・仮身システム (スコア:4, 興味深い)
BTRON搭載コンピュータが普及した場合、実身仮身データ群 を他のOSに持っていくのは厳しいので、それが他の系統のコンピュータの国内販売の障壁になるかと。
これもあると言えば、あるのだけれど、逆に他の産業である様に、BTRON仕様のコンピュータが世界を席巻してた可能性ってのもありますよね。
BTRONはなかなか良いコンピュータだと思うので、 ある程度普及して、人的リソースやお金がつぎ込まれて、進化したBTRON仕様のOSってのは見てみたかったなと思います。今、売られているBTRON仕様のOSは進化に必要な人的リソースや資源がつぎ込まれ(つぎ込め)ないので、ファイル数の件も含めて、使い勝手が悪いとか、色々、欠点や欠陥が目立ちますからね。
いつも主観で書き込んでいます
Re:実身・仮身システム (スコア:1, 興味深い)
船頭多くして船山に上ると言いますが、強力なボスが全体の方針を決めることは重要だと思います。人的リソースも重要だけど、色んな人があーだこーだ言っているだけではうまくいきません。
方針を決める人が最近の重要な概念を理解していることが重要になると思います。先を見越した機能を盛り込む方針を決めて時には批判（そんなの何になるの？旧バージョンでいいじゃんとか）を受けても、断固推進するカリスマがいないと先は暗いでしょう。
ところで、今のTRONプロジェクトはどうなっているのでしょうか。傍から見ていると先見の明のある人には恵まれていないと思います。こういうボスはお金を投入すれば現れるというものではないので、仮にTRONが普及したところで、現在のMicrosoftやApple以上のビジョンを示せるかは怪しいのではないでしょうか。
過去の時点ではTRONは優れていたと思います。でもこれからの10年間、その先に求められるビジョンをいち早く感知して提案できるボスがいるかは怪しいところです。
Re:実身・仮身システム (スコア:3, 興味深い)
豪快で、かなりズバズバ意見を言うため好き嫌いが分かれそうです。ダメなものはダメってハッキリ言いますし。でも、その根拠となる知識は比較的あいまいで、知らないことを知っているつもりになって喋っていることは多々あります。
興味のないことはあまり調べようとはしない感じもします。その結果、喋っていることを聞いて「この人わかってるのかなあ」と思うこともしばしばあります。
＞私が無知なだけで実際はそんなことはないんでしょうけど。
そんなことあるかも知れません。
OSの設計はかなり柔軟な頭が必要だと思っています。これはこういうもの、という固定観念があるといいOSは作れないと新しい意欲的なOSを見ていると思いますが、上述の通り本人も好き嫌いが多いというか、興味のないことをあまり調べようとしない風に見えますので、今後はTRONは置いていかれるかも知れません。
なお、全体的な評価で言うと歯に衣着せない坂村先生は好きなタイプです。別にアンチというわけではありませんが、駿馬も老いては〜というものを感じます。
Re:実身・仮身システム (スコア:1, すばらしい洞察)
……いやぁ、これがまたすごくてね。
下手なバラエティ番組なんかよりもずっと面白かったです。
# 突っ込み所満載で
意図的に都合が悪い事を省いたり誤魔化したりしてる
と、その当時は思っていたのですが
もしかして、ただ単に物知らずなだけだったのかな
Re:実身・仮身システム (スコア:1)
組み込み向けで賑やかだったμITRONも、最近はサードパーティの元気がないですね。
こちらも時間の問題じゃないかと思います。
Re:実身・仮身システム (スコア:2, 参考になる)
ちょうど、次 URL のような生々しい話を読んだばかりでした。
Windows Embedded採用事例 Windows移行を決断したカーナビ開発の現場から － パイオニア － [atmarkit.co.jp]（μITRON から Windows Automotive へ移行）
昔は、健ちゃんのヴィジョンやパワフルさにあこがれて、健ちゃんや TRON を応援していました。最近は、安定供給と発展性（着実なバージョンアップ）も大事だよな…と思うようになっています。
要因はいろいろ言われますが、愚考すると、健ちゃんのフィールドの研究現場と、パーソナルメディアなどによる普及のための開発や産業化がうまくかみあっておらず、これからもかみ合わないままではないかと思います。
Re:実身・仮身システム (スコア:2, 参考になる)
読み直して説明不足かと思ったので、補足します。
TRONWARE という TRON 専門の展示会が毎年1回あって、数年前まで通いましたが、東大坂村研究室からはネットワーク対応 TAD などいろいろおもしろそうな研究が発表されていました。勉強不足かもしれませんが、それらが超漢字に組み込まれたというようなおぼえがありません。
どちらに原因があるのかわかりませんが、研究と実用化がかみあっていないのではないかと思ったのです。
Microsoft や Google は、研究の成果を Windows や自 Web サイトに組み込んで実用化することにためらいがないと思うし（実際はためらいもあるかもしれないけど）、実用化につなげるのがうまいと思います。
Re:実身・仮身システム (スコア:1, すばらしい洞察)
Re:実身・仮身システム (スコア:2, 興味深い)
というか、NTTが持っていたものベースにCTRON仕様が作られたという噂もある。＃違ってたらごめん。
masamic
Re:実身・仮身システム (スコア:3, 参考になる)
当時、一部ファミリー企業に作らせていたDIPS (Dendenkosha Information Processing System) コンピュータの閉鎖性を批判されていた電電公社は、
仕様を公開した後継OS (POPSと呼ばれた)というかその仕様を急ぎ作る必要に迫られていました。
この仕様を策定するにあたり時間と手間の節約と公開性の大義名分のゲットのためにTRON計画に目をつけた電電公社と
TRONの名を売りたい健ちゃんの利害が一致した結果IBMがICBMに化けたわけです。
なのでCTRON仕様はITRON仕様をベースに電電公社の都合にあわせたアレンジ、拡張したものになっています。
健ちゃんのアイデアで作られたものというわけでもないので、TRONの功績といっても間接的なものですね。
すごい文字コードを考えた！ (スコア:4, おもしろおかしい)
64x64ピクセルとしましょう。
その64x64=4096個のピクセルに対して、それぞれ1ビットを
割り当てます。すると、1文字を4096ビットつまり512バイトで
表現できます。
このようにすれば、あらゆる漢字を表現できますし、それにも
かかわらず、字形とコードの対応は自明ですので、目的とする
コードは簡単に見つけることができます。収録文字が多すぎて
目的の文字が探せないなんて問題とも無縁です。
現状のTRONコードでは、Unicodeへのアンチテーゼとしてか、
要望のあった文字は必ず収録するようにしているみたいですが、
この文字コードの場合は、収録の必要すらありません。
あらかじめ、あらゆる文字が収録されているのですから。
この文字コードを、次世代のTRONで採用してもらえないでしょうか？
誰だ、「これなんてビッ...」だなんて言う奴は？
Re:すごい文字コードを考えた！ (スコア:3, すばらしい洞察)
1文字513バイトにすべきです。
Re:すごい文字コードを考えた！ (スコア:1, おもしろおかしい)
なんてものが必要になるんです。64x64とかじゃなくて、たとえば
A4全体くらいをまるまるピクセルで表現してしまうような、
「文書コード」という概念を提案します。
そうすれば、改行文字なんてものは不要になります。
# 拡張子はBMPがいいですか？それともTIF？PNG？
Re:すごい文字コードを考えた！ (スコア:1)
手書き?
天琉陳(Teruching)
Re:すごい文字コードを考えた！ (スコア:2, おもしろおかしい)
Re:すごい文字コードを考えた！ (スコア:1, 荒らし)
Re:すごい文字コードを考えた！ (スコア:1)
256階調も用意する必要はないと思いますが、最低4階調くらいは必要なのでは。余裕を見て8階調とすると、１ピクセルに対して3ビット。
つまり一文字1.5KB。
単に漢字が多いだけでもねぇ。 (スコア:3, 参考になる)
試しにとある中国史論文(漢和辞典でしか見ないような熟語ばかり)を打ち込んで
みたのですが、あるはずの漢字を探すのにどえらい時間がかかり、三ページ打つか
打たないで止めてしまいました。
現代日本語の語彙や文法ならそこそこ行った筈ですけど(VJE-δだった)、
ニッチの要求を満たすにはキツい...と思ったです。
漢字を生かす (スコア:2, 興味深い)
ただ「データの数が65536まで」っていうのはどういう意味なのかな...
個人的には、超漢字よりTRONキーボードの復活を望みたいです。
Re:漢字を生かす (スコア:4, 参考になる)
確か１ディスク上のファイル数。DOS/Windows の FAT みたく「サブフォルダ内で○○個まで」のように階層ごとに管理ブロックを持つんじゃなくて、ディスク単位だったかと。
6万5千という数字は、全方位で考えるとひ弱に感じるけど、狭義の「文書」というデータを扱う上では6万5千もの文書をファイルとして持つというのはなかなかレアなケースだと思うし・・ ま、GISみたくメッシュ切されたファイル群を持ったりする場合は6万なんて少なすぎて即NGですけど。
あと、文字の字体の豊富さが住民票などのデータを扱うのに適しているというのは同意ですが、そのデータ保管のハンドリングまで超漢字で行う必要は無いです。 表示・印字・入力などのフロントエンドとして働けば充分であって、超漢字＆ORACLEのシステムはそういう構成だったりします [chokanji.com]。 この例だと ORACLE は linux上で動作。
戸籍などの字体には (スコア:3, 参考になる)
一般の人が読めない字、書けない字というのは、情報を伝える手段としての文字として存在自体が自己矛盾です。
コード変更のような機械に頼るだけでなく人の意識も変えていかないと。
で、行政の情報システムにはTRONコードが利用できるシステムは最適というのは同感です。
Re:戸籍などの字体には (スコア:2, すばらしい洞察)
ただ、超漢字のように「同定可能な文字」にコードポイントがいくつも与えられるような文字集合で、文字種の豊富さを誇られても率直に言って困ったもんだとしか言いようがない。
Re:戸籍などの字体には (スコア:1, 興味深い)
TRONコードは「正字を全て取り扱えるコード」じゃ無かったと思うなぁ
「(正しかろうが、間違ってようが)過去において文字として扱われた物を(出来る限り)取り扱えるコード」じゃなかったっけ？
# まぁ、包括関係にあるけど。そう解釈すると辻褄が合わないよね
Re:戸籍などの字体には (スコア:5, 参考になる)
「際限なく各種文字コードを取り込める文字コード体系」がTRONコードだったと思うが。
TRONコードの中には，日本の規格（JIS）はもちろん，中国（中共，台湾），韓国，UNICODEといったものが全て含まれています。概要は「TRONコードの概要」 [tron.org]を参照のこと。
「本来誤字だったはずの字が沢山含まれている」責任は，それぞれの文字コードと，その策定者にあります。
Re:戸籍などの字体には (スコア:2, すばらしい洞察)
加えて、TRON コードのページの認識が古すぎて噴飯もの、という気もしなくもありません。
Re:漢字を生かす (スコア:3, 参考になる)
復活する予定です。部外者のとして確認できているのはモックの段階ですが。
基本的にはμトロンキーボードをベースにしているので、フルサイズ版のあの立体的形状やペンタブレットはありませんが。
TRON系雑誌TRONWARE100号と、総合デザイン雑誌AXIS創刊25周年特別増ページ号に記事とデザイン（AXISにはモック写真）が載っています。
masamic
Re:データの数 (スコア:2, おもしろおかしい)
ど、どんな傾向の画像ですか？
Re:データの数 (スコア:1)
# 「はい。これあずかっておきます」って答えてくれる方に需要があると思ったのだけど。
"Patriotism is the last refuge of a scoundrel." - Samuel Johnson
ふと思った。 (スコア:2, 興味深い)
OSじゃなくてアプリケーションにすればいいのに。
Re:ふと思った。 (スコア:1)
Re:ふと思った。 (スコア:2, おもしろおかしい)
VMware Player英語版が同梱されているそうです。 (スコア:2, 参考になる)
VMware Player英語版が同梱されているそうです。
そうなると、VMware ServerやVMware Workstationでも動作すると思います。
私はVMware Server 1.0上でWindows 2000 ProとUbuntu Linux 6.06を動かしていますが、この場合はGuest OSを「Other」、そしてVersionを「Other」を選ぶと良いでしょう。
Super Souya
フレームの元になりやすい「実身／化身」 (スコア:2, 参考になる)
「OSじゃなくてアプリケーションにすれば [srad.jp]」とか「IMEにすれば [srad.jp]」とか言う人がいるけど、実際に超漢字を使っている人の何割かは「字体の豊富さ」ではなくて「実身／化身の概念」を使いたくて使ってるんじゃないかという気がするんだが。
実身／化身の実装はファイルシステム＋αによって実現されるものなので、他OSの一部や他ファイルシステム上への実装は簡単ではないんじゃないかなー。
個人的には実身／化身の恩恵を得るようなデータも作業も持ってないから超漢字には興味がなかったりしますが。
Re:フレームの元になりやすい「実身／化身」 (スコア:3, 参考になる)
すこしコンピュータに興味のある人が手を出せるところにUNIXやWindowsで当たり前の概念と異なるものががあれば目からうろこが落ちる人もいるでしょう。したがって実用的というよりは、アンチテーゼとしてあることが重要だと思っています。
ファイルをパスで管理する方法は問題が山積みです。ファイル名を変えたり移動するとショートカットなどが切れるとか、開いているファイルの移動ができないとか。
MacでもファイルをIDで管理する方式がありました。旧Mac OSではほぼファイルの管理はFSSpecとかFSRef、永続的な追跡が必要な場合はAliasRecordというものを使っていました。メリットを書くと長くなりますが、なかなか優れていたと思います。
Mac OS XではUNIX的な発想が入ってきたのでパスもずいぶん使われますが、FSRefなどは残っています。
65000ファイルの制約を打開する方法 (スコア:3, 興味深い)
そのIDのビット長を増やそうとしないのはなぜなんでしょうね。
先生の発言 [atmarkit.co.jp]によると、128ビット(たかだか16byte)有れば
「毎日1兆個のモノや場所にucodeを付与することを1兆年続けても足りなくなることはない」
という事なのに。
# ucodeのようなアイデアもある一方で、BTRONを直さないのは、単に坂村先生が忙しくて
# 仕様のテコ入れにパワーを割いていないか、先生以外の人で改善した提案を強く主張する人が
# いないだけなんだろうな…と推測。
Re:フレームの元になりやすい「実身／化身」 (スコア:1)
"Patriotism is the last refuge of a scoundrel." - Samuel Johnson
Re:フレームの元になりやすい「実身／化身」 (スコア:2, おもしろおかしい)
s/化身/仮身/g
なフレームが起こりそうと思う。
化けてどうすんだとか突っ込んで。
Re:フレームの元になりやすい「実身／化身」 (スコア:1)
API切り離しでいいのではないかと思います。
全ての機能がバラバラで旨く統合されていない（パラレル）、ドライバがどうしようもない点が致命的だと思います。
それらの欠点を埋めるためにVMwareで動かすのは良いんですが、根本的解決策ではないと思います。
昔はよく使った (スコア:1, 興味深い)
付属のWin95でハイバネ起動するより超漢字を通常起動するほうが圧倒的に速かったから、移動中のメールチェックはそっちでやってた。
機能は貧弱だけど軽いのはなによりだったなぁ。
今の手持ちのハードは富豪化してるので、もう出番はないかな。
VMware上での動作前提ですか。 (スコア:1)
超漢字4をVMware上で動かそうと思っていたのですが、動作確認用ソフトを動かしてみると、NICが使えるかどうか怪しかったので購入を躊躇っていました。
# ググってみると問題なく使えているっぽいですが。
Vはそんな心配なしに思い切って買えそうです。
# と、ここまで書いてから初めてプレスリリースを読んでみました。
# Windows上で動くということがひたすら強調されているため、
# 予備知識がなければVMware上で動くということを見落としていたかも。
巧妙に潜伏したバグは心霊現象と区別が付かない。
実身数が65536なんですが (スコア:5, 参考になる)
# UNIX系のファイルシステムでハードリンクが別パーティションのファイルに作れないのと同じようなもの
65536個の制限は、仕様です、のひと言につきます。 仕様書に16ビット分確保されるように記述されています。 勝手に32ビットなりそれ以上のビット数に拡張することは、 現状においては BTRON3仕様に反します。 なので、超漢字(B-right/V)にその責はありません(ただし表向き)。
# 昔、関係者だったけれど ID
MIYAZAKI Yasushi
Re:扱えるデータの数が最大で65536 (スコア:3, 参考になる)
「ディレクトリまで含めて全てがハードリンクで構成されている」の方が近いと思う。んでファイル自体が実身、リンクが仮見。実身は一つのファイルだけどちょうどwebページアーカイブのように*文字列や画像など一つの文書を構成するデータは全て入ってる。なのでファイルは他のOSと比べてかなり少ない。
問題なのはファイルIDそのものをユーザプロセスが触らなきゃならないメタメタな作りになっているところで、そのために拡張するのにユーザプロセスをいろいろいじらなきゃならなくなってる。カーネルだけの問題ならちょいと直せば済む話。
*なのにどうしてもじらなんか入れたんだろうねぇ...。
Re:扱えるデータの数が最大で65536 (スコア:2, 興味深い)
＃超漢字メールとか
専用アプリでしか扱えないデータにしてしまうと、データ同士の密な参照関係を作り上げることで飛躍的に使いやすくなる実身・仮身システムの利点が失われてしまいます。
BTRONのヘビーユーザーほど巨大な仮身ネットワークを作り上げているので、きつい制限となっている実身数上限の撤廃はユーザーの悲願なのです。
Re:扱えるデータの数が最大で65536 (スコア:1, 興味深い)
まねた、ファイルシステムのエミュレータっぽいものを
OS自体が持てばなんとかならんものかと思いましたが。