やっぱり、MacOS X 最高!

9万円で購入したMacMiniがやってきたので、インストールしているうちに、ああこれはもうダメ、Windowsに戻ることはもう一生なさそう。そう感じました。会社のお客様対応のために使わざるを得ない場合を除いて、Windowsを使うことはもうありません。

かれこれ10年もMacOSから引き離され、砂を噛む様なWindowsと付き合わせられ、やがて無感覚になっていましたが、今思えば何のための難行苦行だったのかと思います。

すでに20年ほど前の時点で、MacOS Xはソフトウェア開発環境としても、またもちろんホビー用にも、最高のOSでした(※個人の感想です)。素性の良い育ち盛りのUnix OSでした。ただ、当時まだ日進月歩で目まぐるしく標準も移り変わっていた周辺デバイスや、各種お仕事用のソフトがMacに対応してくれてなかった。Apple側も世間に合わせる気がまるでない様で、やたら先進性を気取ったインタフェースを押し出し(押し付け)続けてましたっけ。

初対面は17インチ液晶のiMac鏡餅モデル。2002年発売、249000円!と当時の記事にあります。その後20インチiMac、PowerPCと続き、何機も部屋にはべらせて、電気代も気にせず一緒に寝起き。弁当サイズのMacMiniも可愛くて。そこまではインテルじゃなくてPowerPCでした。当時衝撃的薄型としてデビューしたMacBook Air にも飛びつきました。経済観念とか老後への備えと言うモノがなかったですね。

あれから10年、気づくと今回会社用にと導入したソフトは全てMacOS Xにも成熟した版がありました。足りないのは過去を重く引きずり時間が止まっている世界のツールだけ。まずFPGAの開発ツールvivadoですが、これはLinux版があるのでMac上の仮想マシンで動かせる。あと、組み込み系の開発に使って来たARMのKeilですが、これも仮想マシンで動くとARMのサイトに書いてあります(ゲストにはWindows 7を推奨とか書いてあるけど、2017年に)

な〜んだ、Windows 10いらないじゃん。今はもう言える。

バイバイWindows!

Windowsと付き合って楽しかった思い出など、ひとつもありません。
Cygwinには感謝しています。今までありがとう、そしてさようなら。

あー、でもMacを気持ちよく使うのに欠かせないあのキーボード達、全部処分しちゃったので… 早速調達しなきゃ。ウキウキ!

2020-0423 sato@izmoh


健康保険証第一号来る

会社を設立後に速攻で行うべきことは法人として社会保険に加入することで「設立後5日以内」に担当の役所(現在は年金事務所)に届け出すべしとなっています。被保険者となる社員・役員の側としても、健康保険証を携帯してないのは不安なものですから、これは大事です。(少額なら全額払って後で清算でも気になりませんが)

あれ?でも設立日(法務局への登記書類提出日)から登記が完了するまでの日数は不定だし、届け出書に記入を求められている法人番号は登記が完了してもらえるわけです。当社は4月1日に設立、登記完了が3日でした(これすら正式には法務局は教えてくれないのですが、別件でのちょっとした電話のやりとりの後、担当のお姉さまがこっそりもやっと…)。まあ、法人検索サイトで見ればわかるんですが、これにもちょっとタイムラグがある。検索して登記完了が確認できたのは夕方でした。

2020年4月3日は金曜日でしたから、土日をはさんで6日月曜が、登記から5日目にあたります。それが公式デッドライン。ですが、例えば登記が年末年始やゴールデンウィーク前日だったらどうなるんでしょう?規定には、5日間ルールにおいて役所の休日を除くとは書いてないのです。

ぱっと見にどうみてもおかしなルールです。それで、年金事務所に電話して聞いたところ、まあそういう杓子定規な事は無い、みたいななまぬるい回答を頂きました。大丈夫なのかなこの制度(笑)

それはともかく、一日も早く保険証が欲しかったので、ネットで検索して知ったとおり、届け出書類(保険新規適用届)を地元の年金事務所ではなく埼玉のセンターに郵便で直送。かつ、被保険者として私の申請も同封(これは知っててよかった。手間と所要時間の大幅節約)。自動振替え申請は銀行に行くのが面倒だったので(てかまだ法人口座無かったし)見送りでした(クレジットで払えるとよいのに…)

あとは保険証が届くのを待つのみですが、4月は新規の申請が集中するので、かなり時間がかかるとの事。次にお医者さんに行くまでに間に合うかしら?と心配していたのですが、その後本業に没頭しているうちに忘れていました。会社への適用通知(株式会社なので強制適用事務所です)については、4月13日付確認のものが届いていました。

そして今日、会社の郵便受けを見ると、協会けんぽからの封書が!
中にこれが入ってました↓

おお、これがその噂に聞いていた水色の保険証かあ。燦然と輝く「番号1」。すばらしい。でも、いつかは違う色のを持てるといなあ。 夢のITS健保組合 (^-^)。

というわけで、届け出(郵送)から10日間で交付され、保険証カードが手元に届いたのは2週間後。思ったよりスピーディでした。

あとは、なんといいますか、会社設立(にかかわる単純作業の分)の手引きやサービス等、ネットで検索して出てくる多くが、こけおどし、ひっかけ、我田引水、知らしむべからず依らしむべしだと感じました。わかりにくいのは、ルールのほうが変だからです (屋上屋九龍城状態時代錯誤) 。実際にはとてもカンタン(面倒だけど高次脳機能が不要という意味で)だったし、わからない事があれば担当部署に直接出向くか電話して聞く(電子メールという文明がまだ導入されてない、もしくは意図的に回避されているらしく)のが最も良い(おおむねが驚くほど親切。特に女性の方々は)と思いました。

登記においてひとつ失敗したなと思うのは、なにげにメニューを選ばされ電子公告のURLを某社のサイトにしてしまったことです。これを変更するのはちょっとまたひと手間ですが、まあそれも一つのエンタメかなと。

それはそうと、健康保険証も免許証も身分証も何もかも、スマホにデータとして入れて使えると良いですね。今で言えばQRコードをぴっとかざせばOK。 紛失や盗難で困ることもないし。 使用時に指紋認証か何かすれば良いから、現在よりもずっとセキュア。どこで使われたか立ちどころにわかりますしね。便利すぎるものはセキュリティ・プライバシーの落とし穴、という一般則はありますが。まあ遅かれ早かれそういう世界になるんじゃないですかねえ。

2020-0422 sato@izmoh

わが社にもギガビット回線が来た

まがりなりにも株式会社たるもの、インターネット接続がメガ単位ではいかん。というような動機ではなく実際の必要性から、遅まきながら回線を1ギガにしました(これまで大家さんの100メガにまがりしてました…)

映像配信など趣味の世界ではもう当たり前の世界なのでしょう。おかげ様で、ギガビットのインターネットなんていうひと昔まえには夢のようだったものが、月数千円で使えるようになりました。

必要性、というのは、遠隔のネットワークドライブを使うためです。経営の方針から、わが社の中央コンピュータに内蔵するディスクは250GBのSSDのみとしています(10万円未満で買えたWin10 Pro入りのレノボ機(これって最高!)の仕様でした)。

実際のところ、わが社で頻繁に使うファイルの総量はその程度のもので、他は外付けポータブルでもリモートであっても構わないのです。クラウド上の各社ドライブは、月1000円位の本来サービスに、おまけで1TBついてくる時代になりました(MS365のおまけOneDriveとか)。もちろんクラッシュの心配もないので、自前のバックアップも不要です。

ただ心配なのがアクセス速度です。10数年前、ギガビットLANの到来とともに100MB/秒でのアクセスできるようになり、ローカルディスクと比べて大きなストレスも感じずに使えるNASがブレークしました。それは100Mbpsの時代には無理でした(まあふた昔前はディスクI/Oは10MB/秒という時代でしたので、ぜいたくな話ではあるのですが)

昔話はともかく、速度を図ってみました。まず100Mbpsネット。

なかなかのものです。看板に偽りなし。実際これを2年くらい使いましたが、ストレスを感じたことはほぼありませんでした。少なくとも前の職場のネットより快適で(^-^)ノシ
そして、ギガビットネット。

おおー、立派立派。それにしてもこのfast.comって偉い。このユーザインタフェースは素晴らしい。しかし、いったいどういう経路になっているのでしょう?

$ tracert fast.com
Tracing route to fast.com [2600:1417:5d:280::24fe]
over a maximum of 30 hops:
1 <1 ms <1 ms <1 ms its-more [240b:11:cc01:0:0123:0123:abcd:abcd]
2 2 ms 2 ms 5 ms 240b:11:cc01::fffe
3 * * * Request timed out.
4 * * * Request timed out.
5 * * * Request timed out.
6 5 ms 4 ms 4 ms 2404:9200:225:1::1
7 5 ms * * 2001:268:fa00:29c::1
8 * * * Request timed out.
9 5 ms 5 ms 4 ms 2001:268:fc02:52::2
10 4 ms 4 ms 4 ms g2600-1417-005d-0280-0000-0000-0000-24fe.deploy.
static.akamaitechnologies.com [2600:1417:5d:280::24fe]
Trace complete.

どこまでもRTTが5msというのも、世の中が全部IPv6になっているのにも、今更ですが驚きです。Windowsにtracerouteがあるというのにも(^-^)Cygwinで見つからないのでどうしたのかと思いました。

とはいえ、基礎的な通信速度がいくらすごくても輻輳したりなんやかやで律速されて、実際のデータ転送速度は数メガバイト/秒程度(良くても50Mbps以下)がせいぜいというのはありがちな話です。それで、まずは Google Drive (File Stream) で測ってみました。

すると驚きの結果が!これこのような↓

まじで250Mbps出てるですけど…
(いやそもそもこの250って、手元のルータで律速されてやしまいか?)

送り込んでいるデータのサイズは1GBです。圧縮マジックにかからないように乱数を書きこんでいます。(openssl rand 1000000000 > xxx。なお、このCPUでの rand の生成速度は 500MB/秒以上です)。当然ローカルにキャッシュはしているでしょう。見た目に書き込みが終了してから実際に転送が始まるまでに10秒くらい何かしています。

もっとでかいデータを書いてみるとどうかな?とりあえず rand は 32ビット整数の縛りで 2GB しか生成できないみたいなので、生成したファイルを複数 cat して送ってみましたが、やはり回線の使用状況は同じようでした。あとは、ランダムアクセスに耐えるかというところですね。まあ、Stream って名前なので、過度の期待はしませんが…

ただいずれにしても、回線の速度をフルに使いきっているのがすごい感じ。UDPなの?

では他社はどうか?つぎは OneDrive。なんだか凸凹してる↓

いかにもMicrosoftらしく、何か余計な考え事をしているようです。


そしてDropbox。ほとんど200Mbpsに達せず、気合が足りない感じ↓


では複数並列にやったり、各社ドライブ間でやり取りするとどうなるでしょう?

★★★★★ 瞬間最高400Gbps出ました ★★★★
疑ってごめんなさいルータさん。測定の誤差というレベルではないようです。

各種アプリや文書データだけなら、ローカルの256GB SSDに収まりそうなんですが、多数の仮想マシン用のディスクを収容するのは無理です。なにしろ推奨最小が20GBですから。そこでクラウドに置くことにすると、スナップショットを取るのにかかる時間はなんとかなりそうですが、仮想ディスクから実ディスクへのランダム読み書きがどの程度発生するのかが心配です。わが社のマシンは、上の画面にあるように、メモリも8GBしかないからそれはもうー

ディスクの sync 中に手元のPCがクラッシュしたりネットが落ちたりしたらどうなるんだろうかというのも心配というか、興味があるところです。上の画面のように、当社はVMwareユーザなのですが、VMwareの仮想マシンの仮想ディスクとか最近の版でもカンタンに壊れてしまうので、実マシンでのネットドライブに限ったことではないですが。Hyper-Vはどうなのかなとか。それが Windows Pro にした理由の一つでしたし。

ギガビット・インターネットは実用として重要ですが、とりあえずそれ自体がとってもエンタメです。というか、先週4種類試した、WebDavやSFTPをベースにした仮想ドライブソフト達ががあまりにもダメダメだったので、ネットワークドライブというものに疑念を持ってしまっていましたが、今日、大手のクラウドドライブの実力に頭が下がりました。

単なるファイル転送プロトコルとしてのFTPの役割は完全に終焉しました。各種バイナリの配布(特に isoファイルとか)にしても何にしても、リードオンリーなファイルはHTTPで配るとかでなく、クラウドのドライブにぽんとおいておけばよいのではないかと思われます。改ざんしたファイルと区別の付かないハッシュ値とかじゃなく、ちゃんと電子署名して。

2020-0422 sato@izmoh


文書署名サービス・トライアル

その後いくつかの文書署名サービスをちょっとずつ試してみましたが、一言で言えば期待はずれでした。私が期待する使い勝手において致命的に感じるのは、まず署名の応答が遅い and/or こちらの手間がかかる。そして不安感。クラウドサービスとの連携型では、なにやらサインアップさせて他のサービスと抱き合わせてくるし、こちらのアカウントを握られたり機微なコンテンツへの全権アクセスをさせる事の不安感があります。

試したものの中では以下の好感度でした(※個人の感想です)

1位:1-2-3 Signature の Upload+Sign
  - drag&drop のみ / 速い / 手軽 / 安心感
2位: 手元のAcrobatでの署名
  - 使い易くて当然。問題はAcrobatの値段
3位:DocuSign + GoogleDocs
  - 使い易い。ルック&フィールはイマイチw
4位:Dropbox + Adobe Sign
  - Adobe得意ののわけわからなさと面倒臭さ
5位:Dropbox + 1-2-3 Signature
  - 感動するほど応答が遅い。署名に1時間?
6位:Dropbox + HelloSign
  - 日本語対応してない模様。お豆腐製造機

なお、1-2-3 Signatureは OneDrive と GoogleDrive とも連携してますが、私の場合両者とも長らく大量の機微情報を置いて使ってきたので、怖いから試しませんでした。Dropbox は放置ごみ置き場だったから安心。だけど、何年かぶりに見たら、ユニークですごくいい使い勝手にはなってるようでした。

もちろん、クラウド系のサービスは単に一人の署名ではなく、稟議みたいなフローが定義できるところがミソなんでしょうけれど。ですが私が求めているのはそういうものではないし、世の中の需要も(電子署名の普及後は)一人の(パーソナルな)署名が大半じゃないかと思います。

クラウド系がほぼメールとの組み合わせなところにも、現状、メールが主要な認証基盤としての地位を保っていることを感じさせます。だがちょっと待てよ。署名するためのメール自身が署名付きでなくてよいのものか?(^"^)

2020-0414 sato@izmoh



以下はトライアルの過程の画面集です。少しデリケートな内容なので、弊社代表の証明書で暗号化してあります。

危険なメールを根絶する技術

1993年は MIME メール (多目的インターネットメール拡張規格、Multipurpose Internet Mail extension)の第一版( RFC1341, RFC1342)が出された年でもあり、一方(ほどなくMIMEを転送メッセージ形式とすることとなる)WWW(ウェブ、World Wide Web)、HTTP(Hyper Text Transfer Protocol)が勃興した年でもありました。

それらは世の中を変えました。 とっても便利に、同時にひどく危険に。

端末制御コードを細工した無邪気ないたずらメールやファイルは、はるか昔からありました。しかし MIME によるメールのマルチメディア化(特に添付ファイル)とウェブサイトとの連携を悪用して生まれた狂暴な危険・危機は笑いごとでは無く、今日も未だ収まることがありません。

しかし、そのような危機が顕在化した頃には既に、解決策も存在し、広く使われていました。それは公開鍵暗号を使った電子署名であり、そのデータ(たとえばメールやファイル)を誰が作ったものかを証明する技術です。主に使われていたツールは PGP(Pretty Good Privacy)でした。

メッセージやファイル、あるいはさらにその構成要素毎に署名をしてやり、信頼できる署名の無いものは利用(受け取りや開封など)しないようにすれば、全ては解決するだろうし、枯れた技術だからすぐに広まって、この危機は早晩終焉するだろう、と当時は素朴に考えていたものです。なのにあれからもう四半世紀が過ぎても、状況はそれほど改善しておらず、アンチウィルス業が盛んです。

これってマッチポンプなんじゃないの?と思うこともあります(笑)

ウェブやメールを代表とするアプリケーションの通信の世界では、通信路の暗号化や、サーバやクライアントの電子署名(認証)は早くに実現しました。特に SSL (Secure Sockets Layer) のお陰ですね。一方でコンテンツに対する電子署名は遅れていました。

プロフェッショナルが作るものについては、電子署名や暗号化の技術利用が進みました。一方、メールの大半は、素人エンドユーザが書くものです。素人の世界では、自分の書いたメールや資料に電子署名をして送ったり公開したりするためのインフラの普及が遅れていました。結果的に、受け取るほうも、電子署名を利用できない状態でした。

ですが、少しずつ状況は進歩し、インフラは整いつつあります。特にPDFに電子署名を行う技術はかなり普及しました。(領収書も電子署名されていると良いのに…)メールに署名する技術(特にS/MIME)も、多くのツールに実装されています。あとは、いつ大多数のエンドユーザがそれを使うようになるか、ですね。現状、電子署名用のデータをツールにインストールする作業は超カンタンではなく、素人には少し敷居が高いレベルですが、これも早晩こなれて解決するでしょう。

ラストワンマイルは、ユーザ各人が自分の証明書を手に入れるところだと思います。気になる費用ですが、個人の証明書は一年あたり5千円くらいが昨今の最安値のようです。

などと書いている私も最近まで前職にあった頃は、結構センシティブな情報をやり取りするのに、通常メールやファイルの署名は…。相手方も…でしたから。そもそも組織の人間としての業務には、組織の発行する公式な職員証たる証明書を使うべきですし。
ですが今回、自分の仕事環境をまっさらから作るのを機に、電子署名の環境を整えることにしました。それで、キャンペーンにもつられて少しだけ安く、個人証明書を購入しました。(いや、ハンコを押すのも新鮮に感じられていいんですけどね…)

この費用をどう感じるかですね。また、素人(非営利個人)の場合にはあまり問題になりませんが、そのデータを「いつ」作ったのかが、「だれ」が作ったかと同時に重要になります。特に知的財産の保護のために。それを実現しているのが「タイムスタンプサービス」で、ある時点には既にそれが存在していいたことを証明します。これは署名+時刻に対するさらなる署名で、ネットワーク経由の自動署名で精度は1秒程度のようです。ですが、これも結構お高い。安いところでも一件あたり10円くらいするようです。

自動生成した部品データにも署名したいと考えている、個人的な法人(笑)の私としては、ちょっと10円は厳しいかなと感じます。

自然ななりゆきとして、ウェブ(HTTP)のメッセージにもS/MIMEが使われるようになるのか?に興味がありますが、そういう話は盛り上がっていないようです。そもそも、ページの中のこの部分は誰が書いたもの、たとえば許可を受けた引用部分とかを峻別するためには、MIME/HTTPではなく、コンテンツ(HTMLなど)に署名を仕込む必要があります。MIMEにもマルチパートというデータ型があって、それを使えば入れ子のS/MIMEもできるのですから、やればできるとは思いますが、HTMLでメディアの埋め込みができるようになって、今ではすっかり、マルチパート(特にmixed)は廃れてしまった模様です。

2020-0413 sato@izmoh


そんな中、上記の個人証明書値引きキャンペーン打っている会社では並行して、無償で手軽にタイムスタンプを押してくれるサービスを提供しています。それがキャンペーンに乗った決め手でした。たとえばこの書き物のPDF版に対する署名は、以下のファイルの右肩に表示しています。PDFのリーダで開けば、その署名が本物か確認できますが、そのためにはご自身のPDFリーダに署名者の証明書をインストールする必要があります。自動化する方法もあるようですが、一件だけなら手動でも簡単です。 めっちゃメジャーな証明書業者から買えば、Adobeが証明書をプレインストールしてくれてて、その手間もいらないのかな?高そうだけど。ちなみに、Adobe自身が提供しているタイムスタンプサービスは、とても高価です。

以下が上記PDFの原本です。暗号してますごめんなさい。ヒントは:
"2020/04/13 18:54:20 +09'00'"

いわゆる電子定款には、公証役場の公証人さんが電子署名します。たとえば、弊社の定款PDFをAcrobatで開くと、以下のように表示されます(この場合には、署名をPDF上に重ねていません)。発行者は Registrar of Tokyo Legal Affairs Bureau, Mnistry of Justice(法務省法務局)です。わが社は東京法務局ではないですけどね。

Googleさんはどうしてるかなと思ったら、DocuSignという、クラウド上で署名してくれるサービスと連携してますね。やはりそう来ましたか。零細企業向けプランだと$25/月だそうな。かなりリーズナブルだけど、うーん、むずがゆいところ。富士ゼロックスさんも最近DocuSignと連携してペーパレス化(^-^)始めたみたいだし(一件あたり387円~ってまじか?)。複合機で紙をスキャンすると署名付きでPDFに落ちたりして。
いずれにしても電子署名化は、時代の潮流みたいですね。

とまあ、こういうふうに、まずはウェブページを題材に、ページの魚拓をとって電子署名して、同じページに挿入したりドライブに保存したりメールするフローを自動化・ワンクリック化したい、というのが、いまこれを試行している動機なんです。技術的には単純。このWordPressでもできるんじゃまいか。

最大のネックはタイムスタンプ代。技術的には応答時間…まあ、数秒なら我慢できます。任意のデータに署名するには?例えばS/MIMEをエンベロープにするとか。これをWebDavマウント(仮想ドライブ)と組み合わせれば…

現状、各社のサービスは「大事な文書に人間が大事に署名する」ことを想定しているし、クラウドサービスと抱き合わせです。一方わが社の構想は、「今見ているもの(いろいろ)」の上でワンクリック、特にエクスプローラの上のアイコンで右クリックとか、スマホで拇印押して指紋認証で捺印とか、さらに「機械的に生成したデータに自動的に署名する」というものです。私が証明書を購入した会社さんのコンセプトはそれに合っています。いずれ実現したいものです。
まあ、うちがやらなくても誰かがやる(やってる)でしょうけど…

と、ここまで書いてまた魚拓しました(DocuSign試用版使用)。

ユニークID(1)

学生時代にユニークID(一意識別子, unique identifier, UID)という言葉を知った時、世の中の森羅万象にグローバルでユニークな識別子が付けられると面白いのに、と思ったものだ。 最近、余裕が出来たので(笑)これを再考してみる。

モノを識別する(見分ける、区別する)のは、情報処理の出発点だ。人間の思考においても、コンピュータによる処理においても。思いつくままに書いてくけど、最後には UUID(Universal Unique Identifier)に辿りつきたい。学生さんのレポートみたいな感じだけど、及第点に達するだろうか…

そういえば学生の頃は DEC PDP-11の Unibus とベル研の Unix がめちゃ好きだった。言葉の由来は違うけど。なお、UNIQLO はあまり好きではない。

身近なユニークID

分野や業界の中でのみユニーク(一意)なID(番号)は様々に存在する。

そういう、一意性の通用する範囲を、コンピュータ(プログラミング)の業界では「局所スコープ(視野)」と呼ぶ。ローカル/グローバル、プライベート/パブリック、イントラ/インターという表現もある。

ネットユーザとして身近なものには、固定長ならIPアドレス(32ビット/IPv4, 128ビット/IPv6)やMACアドレス(48ビット)、可変長(1)ならドメイン名(2)やメールアドレス、あるいはURLがある(3)。最近はあまり表に出ないけど、メールのMessage-IDもある。

(1)可変長とは言え、実装から来る制限はあり、最大長は決められている。
(2)今ではユニークID(絶対アドレス)として当たり前に使われているドメイン名も、それほど歴史は古くない。30年くらい前は、相対アドレス(到達経路パス)だった…
(3)World Wide Webが果たした最大のブレークスルーは、HTTPでもHTMLでもなくURL(Universal/Uniform Resource Locator)だと思っている。ハイパーテキストは古くからあったけど、ハイパーリンク(つまりResource Locator)の表現がグローバルにユニークでは無かった。IPアドレスはグローバルにユニークだったけど、識別できる対象の数が少なすぎた。私自身はMessage-IDを使って同じようなことにトライしていたので、URLにはヤラレタ感があった。

消費者としては書籍番号(ISBN, 13桁)、商品番号(JANコード, 13桁)を良く目にする。日本では比較的最近、個人番号(12桁)や法人番号(13桁)が導入され、これも身近なユニークIDになった。電話番号は10桁か11桁。これらはもちろん、十進表記であり、ふつうの人にとって可読性が良く、記憶もできる。

そもそも住所(番地, アドレス)というものはグローバルにユニークなIDとして最古のもののはずだが、可変長であり、簡単に作れず、識別できる対象の粒が荒すぎるという問題がある。

ヒトにやさしいユニークID

よく、人間が短期記憶できるのは7つまでと言われているが、年寄りには長期記憶だって怪しい。ただ、桁ごとの意味を分解して知っていれば、実際に覚えなければならない桁(塊り, chunk)は少ない。例えば192.168.1.32というプライベートIPアドレスで覚えとかないといけないのは、192.168(つまりプライベート)および1という塊りと32という値の3塊だけになる。

また、IP (v4) では32ビットのアドレスを8ビット(バイト)単位で区切って、たとえば16進表記で 0xC0A880A4 のところを、192.168.128.164 のように10進表記して来た。これで上記のように、身近な生活でなじみの深い12桁の10進表記になる。これは、ヒトが誤らずに認識したり書き写したり伝達したりできる限界に関係するのかも知れない。よくあるライセンスキーの多くはこれを超えており、間違わずに入力するのにひどく疲れる。

十進の13桁(10の13乗)は2の44乗(二進44ビット)で表現できる(10,000,000,000,000 == 0x9184E72A000)。これは10テラであり、10,0000,0000,0000 つまり十兆だ。現代の一般人が現実感をもって語れる最大値のように思う。さらにペタ、エクサを耳にすることはあるが、その上がゼタ、ヨタというのを知らなかった。1991年に制定されたばかりそうだし。こんなヨタ話を書き綴るのにふさわしいか(笑)。ヨタは10の24乗、92ビットで表現できる。

コンピュータの世界では32ビット(4バイト)が、長らく数値データやアドレス値の単位「ワード」としての地位にあった。32ビットは約4ギガなので、メモリやファイルのサイズがこれをまたぐようになった過渡期に「64ビット対応」騒動があった。あれは空騒ぎで済んだ2000年問題に前後して顕れた。次に2038年問題が控えているが、私も見届けたいものだ(笑)

全体の桁数とは違うが、視認性も非常に重要だ。12桁をベタに書かれたら認識しにくいが、3桁ずつ4つに分ければ、即記憶はできないにしろ、認識し伝えやすい。その意味を知らず192168128164 を見て手作業で書き写すのは難しい。

ここではとりあえず、ヒトにやさしいユニークIDは8桁程度の数字、という結論にしておこう。そうしよう。

こういう人間工学(エルゴノミクス)的な話は、とっくに出尽くしていると思うので、この辺で自前の考察は停止しよう。とはいえ、そういう事が踏まえられてないような事例もまだ身の回りにあったような…まあ、パスワードとかかな。最近は短いPINとかパスコードが使われる事が多くなったけど。

今回、各種の届出書や申請書に、法人番号を手作業で書き写し間違えて懲りた。ので、その後はPDFを編集するようになった…

コンピュータにやさしいユニークID

ユニークIDには(その良し悪しには)人間向けの側面(短期・長期に記憶できる、間違えずに伝え書き写せる、とか)と、機械での処理向けの側面(入出力、転送時間、記憶容量、とか)がある。いずれにしても、固定長にしろ可変長にしろ、長さには制限がある。

コンピュータにとってやさしい(易しい)ユニークIDって何だろう。

ユニークIDをユニークにするために、その生成(採番あるいは命名)の方法が課題になる。集中管理を行うものと、あらかじめ桁(あるいは階層)ごとの意味を決めておいて(つまりスコープを局所化して)分散管理ができるものに分かれる。

分散してローカルに採番(あるいは命名)した場合には、それをグローバルに公知するシステムが必要になる。ドメイン名においては、DNSだ。DNSのネットワークがおかしくなると、世の中は大混乱に陥ってしまう。

どちらにしても、あまりコンピュータにやさしくない。それと、識別される側に相談せずに勝手に作られたIDは、IDが識別している(指し示している)先のモノが何であるか(個性とか)を、何も表明(証明)していない。そこで登場するのがハッシュ値(ダイジェスト値)だ。

おなかがすいたのでこのへんにしよう。そうしよう。UUIDまではまだ遠い。

2020-0409 sato@izmoh

VIABUS再考

DeleGateの再始動に向けてウェブサイトを整理していたところ、佐藤が過去に作成したプレゼン資料が埋もれているのを発見しました。

そんな中で、昔にやりかけて遂げられなかったいくつかの仕事を思い出しました。その一つが、1991年頃に考えていた「viabus」です。以下は、2004年頃に行ったDeleGateのプレゼン・スライドの中の一枚です。

2004年頃, DeleGateプレゼン資料中のviabusに関する言及

viabusは「アプリケーション層のバス」です。複数のアプリケーションプログラム(のモジュール)同士を、多対多の通信で接続するもので、プログラムの並列化・部品化と動的結合がテーマでした。今でいう「プラグイン」的な機能モジュールの動的追加能力も、考えていたと思います。

当時の技術の中での発想は「リモートプロシージャコール」の多対多版であり、Ethernet上に柔軟に接続できる「Unixワークステーション」間と同様な関係を、アプリケーションプログラムの部品間で実現しようとするものだったと思います。(Ethernetの黄色いケーブルにブスっと針で刺して繋ぐイメージ、今なら仮想ネットワークですけどね)

また、その当時佐藤は電総研の「ポストマスタ」として電子ニュースシステム(inewsとかcnewsとか、uucpとか…)の管理をやっていたため、NNTPプロトコルの ihave/sendme コマンドの影響も受けていました。

固定的なアドレスでは無く、動的に生成されるIDやメッセージの内容でマッチングして接続、通信することを考えていました。そのような接続に使用できる言語・処理系として、当時「Linda」がありました。しかしLindaの処理系が100万円もして、研究費で購入できず悲しかった記憶があります。

プログラムの動的並列化と接続を記述するために、π(パイまたはピー)言語のインタプリタを作ったりとか、自分の実力に見合わない無謀な試みもしました。

このviabusの上に複数の仮想的なディスプレイと仮想放送局を接続して、静止画を流すというようなデモを、当時の新人研修で新人さんに行ったのを覚えています。そのデモ風景の写真は「電総研ニュース」のある号の表紙に使われました。この冊子は国会図書館にもアーカイブされているようですが、なんだか閲覧できません。

それより新しい年代の言葉で言うと、実装上のviabusはいわゆる「リフレクタ」サーバであったと思います。DeleGateで試作した「VSAP(Virtual Socket Association Protocol)」プロトコルは実際、そのようなものであったと思います。

今再考すると、その考え方自体は間違っていない。しかし当時はそれを実現する能力も環境も足りなかった。それに、通信プロトコルというのは使われてナンボのものです。さもなくば、既存の標準プロトコルと互換であることです。佐藤はその後、標準プロトコルに巻かれる方向に流れました。

viabusを作り直すとすれば、現在でもHTTPの中継に使われる「プロキシ設定」や、やはりHTTPプロキシを中継器とする「SSLトンネル」の形で、仮想的なホスト名によってサーバと接続する、メッセージ形式はMIME、というものに落ち着くように思います。

その当時よりは自身のシステム開発能力は落ちたと思いますが、使える言語も環境も飛躍的に向上しており、物事をよりシンプルに実現できる可能性はあります。何にしても Unix v6 の K&R C の時代から40年使い続けたC言語とも、そろそろお別れする時期かと思います。老後は、go言語かな…

2020-0408 sato@izmoh

アンバランス

あちらではああなのに、こちらではこうなのは何故だ?

自身が優位になるアンバランスを作り出そうとする、一方で劣位にあるものが対抗し解消しようとする、それはヒトにとって大きなモチベーションや発想の源の一つであろう。アンフェアでないなら、これは望ましい。「バランスのとれた発展」は実際には発展を阻害し悪平等を招きやすい。

ただ、製品(プロダクト)におけるアンバランスは提供者側の勝手な争いによるものも多く、無意味な多様性によって空間、時間、思考的に分断される利用者側は被害者である。

文明・文化は多様化と統一を繰り返して成長する。現時点は全般に多様化のフェーズにあるように見える。長期的にはそういう繰り返しなんだと納得しつつ、自分がその激流の中に居るのは疲れる。でも反面、面白い。各レイヤが本質的に多様であるべきものであるなら、選択肢があることは良いことだ。

我々は今、最終的(?)に生き残るIT技術を選別するための実験に参加しているのだと思う。トシを取るとそれについていけなくなるのだろうか。しかしシニアは、クダラナイものが流行っては消えて行くのを見て来た。あれらもやがて消えていくのだろうか。それとも自分が消えるのが先だろうか。

2020-0408 sato@izmoh