謎's キッチン

謎のひとりごと。Amazon欲しい物リストはこちら: https://www.amazon.co.jp/hz/wishlist/ls/CCPOV7C6JTD2

Plan 9

まだ斜め読みすらできてないけど、そういうもんだったんだ。知らんかった。
プロトコルまで独自でか。聞く限りすごく良さげに見える。
ただ、/procはLinuxのようなんだったら間違いだと思うんだ。いや、まだ見てないので知らんけど。バージョン情報で型が決まっていて、値をバイナリで返してくれるんなら良いんだけど。
ユーザー空間が気になる。
どっかに日本語のまとまった情報無いかなぁ。




標準化団体って弊害だよなぁ。
POSIXとかGNUの過去の遺産には正直うんざりするからなぁ。_GNU_SOURCEとか_BSD_SOURCEとかなんか悲惨なことになってるし。コマンド類もカオス極まりないし。shもうざったいし(特に各shの構文が違うのに加え、gnumakeとも異なってる。に加え構文をダイナミックに変えたものが出てこなくなってるし(俺が知らないだけ?)。zshは野心的だけど、実装が色々とスマートでないのがなぁ。)。
Linuxだと、現状ではftpなどのマウントはgnome-vfs(もしくはgvfs)レベルやfuseレベルでしか行えなかったはず。カーネルで対応してほしいなぁ。抽象化してコマンドが対応すればローカルなファイルに対しても使えるlftpがでてくるし。似たようなコマンドが増えなくて済むし。
fuseはgmailfsなどの為の必要悪だよなぁ。無くなっては困る。と思ったけど、カーネルにモジュールの仕組みがあるかぎり問題ないか。開発のしやすさはまぁ、開発用プログラム作ればおk。いや、fsのproxyと考えれば問題ないのか?
zipに対応しようとした時に、"/"以外の文字はファイルに使えるために(ryとの話もあったような@kerneltrap。これ、vfsのレイヤの話で、fsのレイヤではまた別かな。bind mountでisoのようにzipなどのloopbackマウントは実装できるのかな? ファイルサイズが固定じゃないから難しい? readだけならなんとかなる?
Xをカーネルに押し込んでほしいなぁ。
webサーバ(TUX web server)もセキュリティや拡張性云々でマージされてなかったような。HTTPの再設計もそろそろ必要な気がする。\r\n攻撃なんてバイナリにすれば防げる。ただ 長さ+データ だと文字数制限が問題かもしれ。フラグ一個付ければ良いけど。それと未だにgzとx-gzipしかサポートしていないんだよな>MozillaApache。bz2やlzmaはいつになったらサポートするやら。
最近curlの地位が上がってきて嬉しさで俺涙目。wgetよ、ばいばい。
SVGの普及は…うーんどうなったんだろ。ちらほら見かけるようになった…かなぁ。
(X)HTMLも再設計まだー? バイナリ最高!テキスト何それおいしい? telnet教の策略?
テキスト <-> バイナリ の仕様を定義するスキーマまだー? 編集/コマンド上がテキストならファイルがバイナリでも問題ないだろ。
SCTPの普及マダー? もっとアプリが対応してもいいと思う。ローカルの通信をする時もTCPより早かったりするのかなぁ。pipeでいいか。
pipeとsocket同一視すれば、echo "test" > localhost:80/test ってできるのか。
型情報と合わせて、フォームの仕様の出来上がり。



ハードウェアに目を捉われて、その上がガタガタ、そのガタガタをその上で整えてる…と。



何か疲れた。書くの終わり。
テキスト <-> バイナリ のスキーマ言語 と 変換コマンド を作るのが第一だな。うん。これTODO。
ここは俺の日記帳…と。でもこれ、Google検索のスパムになりそうだよなぁ。順位高くなって困る。

sectionheaderとdataって分けた方が良いのかなぁ。
sectionheader data sectionheader data ...とするか、[sectionheader sectionheader ...] [data data ...]とするか(後者の場合はヘッダ用とデータ用の二つのポート使う)。
後者はsectionheaderがsectionheader.sizeof * indexでアクセス可能。セクション結合が容易。
前者は2倍2倍で線形だっけ? 後者は線形*2で二倍時間喰う? malloc的には一つの方が効率良いはず。でも大量の結合が必要だろうから後者かなぁ。ストリームの操作も後者の方が簡単なはず? でもどうせ逐次処理するために固定バッファに取り出して処理するなら前者の方が良い気がするが。
レイテンシよりスループット重視するなら徹底して逐次処理やめれば良いと。でも現実的には、処理できなくなったらsleepを使って、バッファが来たら起こしてをしてと、両立させるべき所なんだろうなぁ。で、できるだけ処理をするのに関数型が向いてる…と。でも関数呼び出しの連鎖させるとオーバーヘッドが増えるのが難点。だから一つの大きなdelegateを渡すのがベストかなぁ。
んでできるだけ処理をするのには後者の方が向いてると。
IOがcallbackになるとして、sandbox化が課題だよなぁ。fork + システムコール + pipe通す とかか。でもマルチスレッド固定となると色々厄介だよなぁ。


ミスったcallback意味茄子。やっぱ、キューがスマートなのか。