2010-06-02 :-)
2010-06-03 :-)
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
メールアドレスを貰った。
秀丸禁止らしいんだが秀丸以外のエディタに慣れていないので乗り換えがなかなかしんどいというかたんに Emacs 風味のキーバインドを使えて日本語文字エンコードを自動でそれなりに認識してくれればなんでもいい。というと割りと限られる。
2010-06-04 :-)
_ 朝ッ
0520 起床
_ 仕事場のひとが RR5 プレイヤーだった
「PS3 欲しい。そして RR7 欲しい」と言っていた。
_ [リッジレーサー7]リッジレーサー7
オンラインバトルなど。OWA さんとか axl Rose さんとか SORALE さんがが居るルームで勝ってもマグレとしか思えない。
- 走行距離 85606 km
- RSGP 進行度 100.0 %
- 名声 23267 FP
- オンラインバトル勝利数 849/3110
_ STANDARD MACHINE'S GRAND PRIX (リッジレーサー7)
6/5
参加しますなのよ
アベイユは諦めた!!!1
無難にフィエラで参戦します。
あとタイトルは修正したけど URI はそのまま
_ Are you a bot?
( via 更新日記 - 日曜プログラマのひとりごと )
@yuka_ are you a bot? ( miwarin )
@miwarin ないわー ( yuka_ )
※ @yuka_ は bot です
_ 不幸自慢
34時間働けますか？ 従業員自殺が止まらないFoxconn、地獄の勤務体制が判明！ : ギズモード・ジャパン
働いたことあるし年間残業 1000 時間とかやったことあるけどしかしまあよく過労死しなかったよなあ 25 歳のときのオレ。なんのおかげで死ななかったんだろう
2010-06-05 :-)
_ 朝ッ
0930 起床
_ 梅酒
@miwarin 梅酒は、家で漬けるですよ〜ヽ(´▽`)/ (suzumecyan)
@miwarin 3年位前に作ったのがまだ残ってるなぁ (NOB_away)
もうそういう時期ですよね．RT @miwarin: 梅酒を自作するひとをタイムライン上に最低2人見かけた (kaz_ka)
旬だねぇ QT @miwarin: 梅酒を自作するひとをタイムライン上に最低2人見かけた (v_motty_v)
ということで自分でもやってみた。
_ [ruby][what_methods]ruby what_methods
( via HsbtDiary )
皆さんはもちろんお使いかと思いますが、使ってない人がいたらエントリを見たついでに使ってみると良いと思います。
なにそれ知りません
ぐぐった
たとえば、3.14を4にするメソッドが思い出せない/分らない場合、どうしたらいいでしょう？
そういうものらしい。
とりあえずインストールしてみる
% gem install what_methods
使ってみる
% irb irb(main):002:0> require 'rubygems' => true irb(main):003:0> require 'what_methods' => true irb(main):004:0> [0,1,2,3].what? [3,2,1,0] [0, 1, 2, 3].reverse == [3, 2, 1, 0] [0, 1, 2, 3].reverse! == [3, 2, 1, 0] => ["reverse", "reverse!"]
すげー
_ [珈琲][コーヒー]NHK教育 極める!石井正則の珈琲学 第1回「豆と焙煎にこだわる」
録画して見た。毎週月曜日だそうな。
- 豆と焙煎にこだわるべし
- 石井「自分がいれると毎回 味が違う」
- 堀口珈琲研究所 にて
- スペシャルティコーヒー
- 生産者を明らかにする
- 畑が異なれば味も異なる
- 国としていっしょくたに扱わない
- カッピング
- コーヒーをテイスティング
- カッパー: カッピングするひと
- 香り: 強い、弱い、とかいろいろ...
- 豆の産地と個性を知るべし
- カフェ・バッハ にて
- 自家焙煎してる
- コーヒーは煎るのが命
- 生かすも殺すも焙煎で決まる
- 焙煎
- 熱で豆の酸味が抜ける
- 浅い: 酸っぱい
- 深い: 苦い
- 生豆
- 色が薄い
- 水分が多い
- 火が通りにくい
- 色が濃い
- 水分が少ない
- 火が通りやすい
- これらが混ざっていると焙煎にムラが出る
- 色が薄い
- 焙煎
- 中深煎りがベスト
- 手で焙煎
- パチパチとハゼ音が鳴り始めたら ok
- 手を休めない
- 一定のリズムで揺らし続ける
カフェ・バッハは南千住か
_ VMwares
_ ゔいえむ!!
と思ったんだが 32bit Windows からそのままファイルをコピーしてきて 64bit Windows で起動させるのはいろいろ発生したのでイチから作り直すことにした。BitTorrent してる。CentOS デカすぎ
_ [リッジレーサー7]リッジレーサー7
STANDARD MACHINE'S GRAND PRIX 。私は総合 3 位だった。詳細は三嶋さんのところ参照→ 企画レース終了！-Midnight Expressway rosso さんと skype しながらプレイしてて rosso さんが「2 周目まではテキトーにトリプルうってればイイ感じです :-) 」などと言ってたんだが、テキトーにやってもそんなにうまく走れないよ。さすがとしか言いようがない （￣ω￣；）キノさんとの回線相性が悪いのは私かなあ...。ううむ
- 走行距離 86015 km
- RSGP 進行度 100.0 %
- 名声 23290 FP
- オンラインバトル勝利数 859/3135
その後 KYO さんの 1111 勝阻止レースで数レース遊ぶなど。Papo さん( 寿司職人 )がオンラインになったので交代。
2010-06-06 :-)
_ 読書
2010年5月24日 - 2010年5月30日の読書メーター
読んだ本の数：1冊
読んだページ数：227ページ
聖剣の刀鍛冶<9>(MF文庫J)
「あああっ どうしたらいいのさ？」アリアのマイペースのような感じが好きだ
読了日：05月30日 著者：三浦 勇雄
読書メーター
_ [静的リンク][スタティックリンク][static link]Static Linking Considered Harmful
( via めもがき )
あたしゃ今時full static linked rootに拘るのは20世紀だよねキャハハちゅーナウなヤングのでOpenBSD向けにこれ以上新しい作業する気はナッシングですが。ここは珍しいことに 例の人と意見が一致している。
ということで翻訳練習してみる。直訳のようになるなあ。
Static Linking Considered Harmful
スタティックリンクは有害だと思う
There are still too many people out there who think (or even insist) that static linking has benefits. This has never been the case and never will be the case. Here are a few reasons why dynamic linking is superior:
あまりにも多くのひとびとがスタティックリンクが有益だと思っている( または主張さえする )。それはこれまでも、今後も本当のことではない。なぜダイナミックリンクが優れているのか、その理由を 2,3 示す:
fixes (either security or only bug) have to be applied to only one place: the new DSO(s). If various applications are linked statically, all of them would have to be relinked. By the time the problem is discovered the sysadmin usually forgot which apps are built with the problematic library. I consider this alone (together with the next one) to be the killer arguments.
(ダイナミックリンクなら)フィックスを適用しなければいけないのは一箇所だけ、つまり新しい DSO (を用意する)だけである。様々なアプリケーションがスタティックリンクされてるならば、すべて再リンクしなおさなければならない。問題が発見されたときになると、システム管理者はどのアプリケーションが問題のライブラリを使って構築されているのか忘れてしまう。これ (と次の論点) だけで、(スタティックリンクを捨てるのに) 十分な論拠だと思う。
Security measures like load address randomization cannot be used. With statically linked applications, only the stack and heap address can be randomized. All text has a fixed address in all invocations. With dynamically linked applications, the kernel has the ability to load all DSOs at arbitrary addresses, independent from each other. In case the application is built as a position independent executable (PIE) even this code can be loaded at random addresses. Fixed addresses (or even only fixed offsets) are the dreams of attackers. And no, it is not possible in general to generate PIEs with static linking. On IA-32 it is possible to use code compiled without -fpic and -fpie in PIEs (although with a cost) but this is not true for other architectures, including x86-64.
セキュリティ対策のようにランダムなロードアドレスは使えない。スタティックリンクされたアプリケーションは、スタック領域とヒープ領域だけがランダムに出来る。すべてのテキスト領域は固定アドレスになる。ダイナミックリンクされたアプリケーションは、カーネルは互いに独立している任意のアドレスですべての DSOs をロード出来る。この場合、アプリケーションはランダムアドレスでロード可能な実行可能( PIE )なコードとしてビルドできる。固定アドレス( または固定のオフセットでさえ ) は攻撃者の標的です。一般的に、スタティックリンクでは PIE を生成することは不可能だ。IA-32 では -fpic と -pie 無しで PIE をコンパイルすれば可能だ( コストかかるけど )。しかし他のアーキテクチャ( x86-64 を含む )ではその手段は使えない。
more efficient use of physical memory. All processes share the same physical pages for the code in the DSOs. With prelinking startup times for dynamically linked code is as good as that of statically linked code.
物理メモリのより効率的な使用法。すべてのプロセスは DSOs 内にある物理ページのコードを共有する。スタートアップをプレリンクされたダイナミックリンクコードは、スタティックリンクコードと同じくらいよいです。
all kinds of features in the libc (locale (through iconv), NSS, IDN, ...) require dynamic linking to load the appropriate external code. We have very limited support for doing this in statically linked code. But it requires that the dynamically loaded modules available at runtime must come from the same glibc version as the code linked into the application. And it is completely unsupported to dynamically load DSOs this way which are not part of glibc. Shipping all the dependencies goes completely against the "advantage" of static linking people site: that shipping one binary is enough to make it work everywhere.
libc のありとあらゆる特徴( locale ( iconv を通して )、NSS、IDN、...） は適切な外部コードをロードするためにダイナミックリンクが要求される。我々は、スタティックリンクされたコードでこうすることに対する非常に限られたサポートをする。しかし、それはダイナミックリンクモジュールを実行時に利用するときに、コードがアプリケーションとリンクしたのと同じ glibc バージョンをによるものでなければならないことを要求する。そして、このように glibc の一部でない DSO をダイナミックにロードすることは完全にサポートされていない。依存するものをすべてまとめて配布することは、スタティックリンク推進者の言う「利点」に真っ向から反している。彼らはこう言う: 「バイナリを 1 つ配布するだけで、どこでも動作する」
Related, trivial NSS modules can be used from statically linked apps directly. If they require extensive dependencies (like the LDAP NSS module, not part of glibc proper) this will likely not work. And since the selection of the NSS modules is up the the person deploying the code (not the developer), it is not possible to make the assumption that these kind of modules are not used.
関連して、ちっぽけな NSS モジュールならスタティックリンクされたアプリケーションから直接使うことができます。彼らが広い依存関係（ LDAP NSSモジュール( 本来の glibc の一部でない ) のように )を必要とするならば、これはたぶん動かない。そして、NSS モジュールの選択権は (開発者ではなく) デプロイする人にあるので、この種のモジュールが使われないと仮定することはできない。
no accidental violation of the (L)GPL. Should a program which is statically linked be given to a third party, it is necessary to provide the possibility to regenerate the program code.
過失による (L)GPLの違反がない。スタティックリンクされたプログラムをサードパーティへ与えるなら、プログラムコードを再構築できるようにしておく必要があるのだ。
tools and hacks like ltrace, LD_PRELOAD, LD_PROFILE, LD_AUDIT don't work. These can be effective debugging and profiling, especially for remote debugging where the user cannot be trusted with doing complex debugging work.
ltrace、LD_PRELOAD、LD_PROFILE、LD_AUDITのようなツールとハックは出来ない。特にユーザーが複雑なデバッグ作業を任せられないようなときにリモートデバッグとして、これらは効果的なデバッグ作業とプロファイリングになる。
There are certainly more reasons. The often used argument about statically linked apps being more portable (i.e., can be copied to other systems and simply used since there are no dependencies) is not true since every non-trivial program needs dynamic linking at least for one of the reasons mentioned above. And dynamic linking kills the portability of statically linked apps.
もちろんより多くの理由がある。しばしば使われる、スタティックリンクされたアプリケーションはよりポータブルだ( たとえば、他のシステムへコピーできるし、依存関係がない ) という理由は、些細ではないプログラムにとってこれまで挙げた理由のうちの少なくとも 1 つの理由のためにダイナミックリンクが必要なので真ではない。そして、ダイナミックリンクはスタティックリンクアプリケーションのポータビリティを生かせない。
Conclusion: Never use static linking!
結論: スタティックリンクを使ってはいけない!
_ [リッジレーサー7]リッジレーサー7
オンラインバトルなど。NANAKI が速すぎる。誰のサブアカなのか
- 走行距離 86191 km
- RSGP 進行度 100.0 %
- 名声 23291 FP
- オンラインバトル勝利数 859/3144
_ ○活
業務時間外に活動しようという話題がどうのこうの。その活動が業務なのか趣味なのか。業務ならやらない。趣味ならやる。
業務( 工数がかかる行為 )をおこなうことについては業務時間なのだから工数が発生するし朝早く会社に来るなどして作業するとたしかに誰も居ない効率的なのだけど勤務時間をシフトできないならばそれはできないしカネを貰えないのに作業してもそれはサービス残業と同じだし勤務時間より早い時間は残業として認められないのでオレはやる気はまったく起きない。これっぽっちも。
趣味ならやる。翻訳したり Python のコードを写経したり本読んだり。
昔「○勝ファミコン」という雑誌があったなあ
2010-06-07 :-)
_ 朝ッ
0520 起床
_ [WindowsXP][インストール][SATA][AHCI]WindowsXP インストーラーが 0x0000007B (0xF78D2524,0xC0000034,0x00000000,0x00000000) で死んだ
WindowsXP にドライバ無いからさ
_ [pcc][NetBSD][翻訳]NetBSD Blog - Portable C Compiler 翻訳( の練習 )
After reading about progress with the Portable C Compiler (PCC) last year, I was inspired to try building it on NetBSD. Gregory McGarry had done some work integrating it into the toolchain though it is not yet useable to build a full release, but the native build framework in external/bsd/pcc was incomplete.
去年ポータブル C コンパイラ (PCC) の進捗具合を読んだので、それを NetBSD でビルドしてみる気になった。完全なリリースとしてはまだ使えないけど Gregory McGarry が toolchain で使えるようにしてくれた。external/bsd/pcc でのネイティブビルドフレームワークでは未完成。( build.sh のこと? )
I updated this a while ago so that it is possible to build a distribution or release containing pcc(1), pcpp(1) and ccom(1) binaries for the target architecture by setting the following two variables in your /etc/mk.conf or passing them to build.sh on the commandline
pcc(1)、pcpp(1) そして ccom(1) バイナリは distribution または release ビルドできるようにしてある。そのためには以下に示す 2 つの変数を /etc/mk.conf に定義するか、または build.sh を実行するときに渡せばよい。
MKPCC=yes MKPCCCMDS=yes
There had been many bug fixes and features added since previous import in September 2009, but the major addition was that GCC compatibility is now enabled by default, and many commonly used attributes and builtin functions are now supported. I had heard of people trying to use pcc to build a kernel without success and went for an alternative approach, building userland programs, as my feeling was that testing smaller code units would be a lot easier. I wrote a script (src/external/bsd/pcc/prepare-import.sh) to configure the PCC sources for import to NetBSD in a consistent manner, and have been using it to follow development for a few months, reporting problems along the way where I could.
2009年9月にインポートしたあとにたくさんのバグフィックスと機能を追加したけど、大きな変更は GCC 互換性をデフォルトで有効にし、そしてたくさんの共通属性と組み込み関数をサポートしたことだ。私はひとびとが pcc を使っての kernel ビルドが成功していないと聞いて、より小さい userland のプログラムならばもっと簡単にビルドできそうだと思ってたのでそのアプローチをとることにした。NetBSD へインポートするために pcc のソースコードを configure するスクリプト ( src/external/bsd/pcc/prepare-import.sh ) を書いて 2,3 ヶ月の間は開発支援として使うことができたので、その途中で問題を報告することにした。
The latest pcc can build all of bin/ and sbin/, most of games/ (except for dab(6) which is C++), and only a few issues remain in usr.bin/ and usr.sbin/. There are still issues outstanding with PIC support on i386 at least, which prevents building shared libraries within the NetBSD framework at this time, though this can be worked around by setting MKPIC=no.
最新の pcc はすべての bin/ と sbin/ をビルドでき、ほとんどの games/ ( dab(6) は C++ だから除外する )、そして usr.bin/ と usr.sbin/ についてはほんの少しの課題があるだけだ。i386 の PIC サポートはまだ著しく問題がある。あらかじめ MIPIC=no を設定しておけばその問題は回避できるんだけど、NetBSD フレームワークのなかだと共有ライブラリのビルドが妨げられてしまう。( ???? )
The in-tree version has been updated and is now at "pcc 0.9.9 [20100603]" which I've been using successfully on i386 though there is support included for amd64, arm, hppa, mips, powerpc, sparc64 & vax CPUs which may also work.
i386 上で成功した "pcc 0.9.9 [20100603]" のバージョンにアップデートしてくれれば amd64, arm, hppa, mips, powerpc, sparc64 & vax CPU もサポートしたものがたぶん動作する。
All the credit and many thanks go to Anders Magnusson who has been working on pcc for many years, he is very responsive to problem reports, sometimes with fixes posted the same day.
すべてのクレジットと感謝は長年 pcc に尽力してくれた Anders Magnusson にささげる。彼は問題報告にとても良く反応してくれたし、ときどきフィックスをポストしてくれた。
_ [翻訳]翻訳のコツを教えてもらった
10年くらい前にも同じことを聞いた気がする。
翻訳むずい。分掌が長くなると脳がスタックオーバーフローする (miwarin)
@miwarin 一気に一文を訳そうとすると難しいですよ。いきなり日本語にしようとせずに、英文の並びで訳して最後に文章化する方が綺麗な文になります。(yoshi3two)
@miwarin いきなり日本語にしようとせずに、単語の並びで訳すんです。下手な翻訳本はいきなり文章を作ろうと訳すのですごく不自然な文章になってます＞＜ (yoshi3two)
_ 会ったことがないマイミクシィ
たぶん全体の 3 割くらい
2010-06-08 :-)
_ 朝ッ
0520 起床
_ たいさく!!
ウェブブラウザが起動したときにそのページを表示するようにしておけばいいんじゃにけ。ファイヤーフォックス的に云えば「Firefoxを起動するとき: 前回終了時のウィンドウとタブを表示する」。まあいままでどおりですが
_ [たべすぎ]2010/6 (a)
自分がむかし書いたメールを読んでいたら、自分でもびっくりするぐらい「イイこと」を書いている部分があった。たとえばこんなの:
Research is an iterative search process. You have to implement your own idea as quickly as possible. It may or may not work, but when it doesn't, modify the code or try something else until you're satisfied (so called re-search). That's how I developed webstemmer. In the beginning, I wasn't even sure if this program was going to work at all. Good luck, Yusuke
研究とは、反復的に探索する作業のことだ。可能な限り素早く自分のアイデアを実装する必要がある。その実装は動作するかもしれないし、しないかもしれない。実装がダメだったとしても自分が満足するまでコードを更新し続けるか、他のことをためすといい( だから "再・探索" と呼ばれる )。それが私が webstemmer を開発した方法だ。最初はこのプログラムがうまくいくか分からなかった(????)。
これは研究活動に対する皮肉かしら。
あわせて読みたい: 研究さん (一休さんの偽物)
_ [NetBSD][rump][翻訳]NetBSD Blog - Kernel Modules Autoload from Host in Rump翻訳
Since early 2009 NetBSD and rump has supported execution of stock kernel module binaries in userspace on x86 architectures. Starting in -current as of today, kernel modules will automatically be loaded from the host into the rump kernel. For example, when mounting a file system in a rump kernel, support will be automatically loaded before mounting is attempted.
2009年の始めに NetBSD と rump を用いて x86 アーキテクチャ上でユーザ領域に溜め込んだカーネルモジュールのバイナリーを実行できるようになった。(今日の) current を使えば、rump カーネル内のホストからカーネルモジュールを自動でロードできる。たとえば、rump カーネル内でファイルシステムをマウントしようとすれば、マウント前に自動でロードが試みられる。
The first issue with autoloading host kernel modules in rump was kernel symbol renaming: to prevent collisions between the application and kernel C symbols, the rump build uses objcopy to prefix symbols with the string rumpns. While running objcopy on a prebuilt kernel module was possible without access to the module's source code, it was a manual step necessary to get a standard kernel module loaded. This was solved by adding a hook to the module loader to adjust the module's string table after it is loaded but before it is linked.
1 つめの課題は、rump 内でカーネルモジュールを自動ロードするとカーネルシンボルがリネームされてしまうことだ: アプリケーションとカーネルとの間で C のシンボルが衝突してしまうことを防ぐために、rump ビルドは、rumpns という接頭文字のシンボルをつけるため( ???? )に objcopy を使用する。標準的なカーネルモジュールロードを取得するためには必要な手順だけど、事前にビルドされたカーネルモジュール上で objcopy を実行している間はモジュールのソースコードにアクセスしなくても出来る。これを解決するために、ロード後のモジュールストリングテーブル( ただしリンクされる前 )を調整するためのモジュールローダーをフックする(仕組み)を追加した。
The second issue was that kernel modules had to be loaded manually by calling rump_sys_modctl(); in contrast kernel modules are commonly autoloaded when necessary. While the standard kernel routines included in a rump kernel would attempt to autoload the module, they would fail because the module files were not available within the rump file system namespace. With some improvements to the rump host file system, etfs, it is now possible to map the kernel module directory (e.g. /stand/i386/5.99.27/modules) inside the rump kernel.
2 つめの課題は、contrast なカーネルモジュール( ? ) 内で一般的な自動ロードをするためには、rump_sys_modctl(); を呼び出だして手動でロードしなければならない。標準的なカーネル関数を含む rump カーネル内で カーネルモジュールを自動ロードしようとしても失敗するだろう。rump ファイルシステム内ではそのモジュールファイルが有効じゃないからだ。etfs のような rump ホストのファイルシステムでは、rump カーネル内ではカーネルモジュールはディレクトリ( 例: /stand/i386/5.99.27/modules ) にマップされるので、これは少し改善される。
Autoloading kernel modules from the host demonstrates a key feature and difference of rump-style lightweight service virtualization: only one full host installation is necessary (although the coexistence of multiple different rump kernel versions is of course possible). This should be contrasted with traditional heavyweight approaches to building virtual services, where each virtual service requires an entire OS installation and maintenance.
ホストからカーネルモジュールを自動ロードするという重要な事例として、軽量な rump スタイルサービスの仮想化についての違いを挙よう( ???? ): 1 つのホストに完全にインストールすることは避けられない( とはいえ、複数の rump カーネルを共存させることは可能だ )。これは、仮想サービスを構築するために従来の重量級な手法とは対称的だ。そこでは各々の仮想サービスは OS の完全インストールが必要だし、それをメンテナンスしなくてはならないという。
2010-06-09 :-)
_ 朝ッ
0520 起床
_ [プログラミング][自習][勉強]もう一つ別の言語を学ぶには
抜粋
- 即座にコーディングを始める
- プロジェクトを立ち上げる
- e.g. C# で FTPクライアント
- ウィンドウ, aero, ソケット, マルチスレッド
- クラスコンストラクタ, 型変換, パスワード暗号化
- プロジェクトを移植
- 1 対 1でもおｋ
- e.g. C# で FTPクライアント
- ほかの人の書いたコードを読む
- SourceForge, Google Code, github
- その言語についての良い本を読む
_ 接骨院行ってきた
肩こりの自覚はなかったんだが( 肩こりがどういうものか分からなかったので自分が肩こりなのかそうでないのか判断できなかった )先日知り合いから「肩こってる」といわれたので診断してもらう意味で人生初の接骨院に行った。当初は整体に行くつもりだったんだけどまあいいや
オレ「肩こってる？(・ω・)」
院長「こってる ヽ( ´ー`)ノ」
_ [hns][tdiary]hns から tdiary へデータを移行した
概要
hns のころの日記を見ようとして【中略】 hns を動作させるのが面倒くさくなったので移行してみることにした。
これ
tDiary-users wiki - hnsから移行したいのですが、データの移行方法はありますか?
環境
- tDiary version 2.3.3.20090826
- Ruby version 1.8.7-p174
ツール
最新(?)の 移行ツールがこちら nemuiDoc: Hns2TDiary
手元だと tdiary データの文字コードが UTF-8 だったりするので変更しておく
--- hns2td.src 2003-05-20 19:06:49.000000000 +0900
+++ hns2td 2010-06-09 20:12:10.000000000 +0900
@@ -22,9 +22,11 @@
# *SUB changed: b -> h4
#
-$KCODE = 'e'
+$KCODE = 'u'
require 'tdiary'
+require 'cgi'
+require 'kconv'
module TDiary
class TDiaryConvert < TDiaryBase
@@ -444,7 +446,7 @@
def convert(filename)
y, m, d = filename.scan(/(\d\d\d\d)(\d\d)(\d\d)/)[0]
@date = Time::local y, m, d
- @body = File::readlines(filename).join.to_euc
+ @body = File::readlines(filename).join.toutf8
@title = ''
@io.transaction(@date) do |diaries|
@@ -466,7 +468,9 @@
end
end
-tdiary = TDiary::TDiaryConvert.new(nil, nil, TDiary::Config.new)
+cgi = CGI::new
+conf = TDiary::Config.new( cgi )
+tdiary = TDiary::TDiaryConvert.new(cgi, nil, conf )
ARGV.each do |f|
tdiary.convert f
移行手順
~/diary-hns に hns のデータがあり、~/diary に既存の tdiary データがある。hns の 2003年5月と tdiay の 2003年5月が重なってるはずなので( そのときに tdiary を使い始めたため ) 念のため tdiary データをコピーしておく( 結局これは杞憂だった。hns2td がイイ感じにマージしてくれるようだ )
% cd ~ % cp ~/diary ~/diary.td % cd ~/public_html/diary % ./hns2td ~/diary-hns/200?/*.hnf
コンバートされた箇所を確認しておく。
rin@hitomi[~]% diff -uqr diary.td diary
結果
hns の「場所」がセクションになったりしてるけど、まあじゅうぶんだろう。
一番古いのはこちら [ 20010801 ]
昔のほうが日記らしかったなあ。
_ RR7愛車の変遷
ビゾンテ
アベイユ
マグニフィコ
ベイヨネット ←DYN車練習開始
エスペランザ
フィエラ
スザク
ベイヨネット ←交流戦前
フィエラ ←交流戦後
アベイユ ←STD車レース前後
フィエラ ←いまここ
2010-06-10 :-)
_ HMV渋谷店閉鎖
( via Togetter - まとめ「HMV渋谷店が8月に閉店で思うこと。」 )
ほう
Lucy 坂本真綾イベントとかFF4イベント[ 20071220#p09 ] 行ったなあ。
_ 半袖シャツを発動した
俺たちの梅雨はこれからだ!!
_ 入力と出力
給与と出費
_ [リッジレーサー7]リッジレーサー7
rosso さんが「メルトファイア速いですよ ( ´ー`)σ)Д`)」と言っていたのでメルトファイアなどで遊んでみた。しかし相手にその rosso さんや owa さんが居たりなど相手が悪すぎた。
- 走行距離 86550 km
- RSGP 進行度 100.0 %
- 名声 23305 FP
- オンラインバトル勝利数 860/3157
_ RR7 下町Rコース
ファタリタ使用
ジャンプ台前のS字終了したところからトリプル発動 よっしゃrossoさん抜いたこのままゴール...! する直前にoh_my_godに抜かされた。
トリプル発動が早かったかというかスリップストリーム入られると勝てないか
2010-06-11 :-)
_ 朝ッ
0520 起床
_ しゅっちょう!!
出張するかもしんないとのこと。神奈川、東京など客先にはしょっちゅう常駐などしているけど出張と呼べるくらいの距離を移動するのは名護へ行ったとき以来か。
_ やつらを敵にまわしてはいけない
iPhone とか Mac とか使ってるひとたち
と思った先日までの tdtds コメント欄 iPhoneを捨ててAndroidにするよ - ただのにっき(2010-04-09)
( 恐怖する、などというんじゃなくて大漁なので相手するのが面倒くさそう )
(( というかまあ炎上だけど ))
_ 仕事場の隣に居るひと(RR7未プレイ)が youtube で RR7 動画を眺めているらしい
餌をまくために私の iPod touch に入れてる動画を見せて「このひとはタイムアタックのほとんどのコース(米)で 1 位である。日本で最速...いや世界最速であろうよ」と kn さんのことを紹介してみた。さあどうだ
米 残りはリバースチャージのひとが占めてる。チャージUでは最速だろう
_ RIDGE RACERS 2 SPECIAL DJ MEGAMIX を買った
「アーティスト」がすべて「NAMCO SOUNDS」だった。泣きたい。大久保博さんの mix なのかなあ (´・ω・`)
2010-06-12 :-)
_ 朝ッ
1100 起床
_ 土曜日は寝る曜日
平日に消耗したHP(またはLP)を回復させるためにひたすらだらだらするのであり日中は活動を控えるのである。
ただ、ここ数年はLPを消耗する生活はしていない。
いや違うか。LPを消耗する生活をしていたときは月月火水木金金だったのでつまり
_ ではいつ休息していたかというと
休息してなかったんである
_ なぜ近年 蔵へ行かないのか
カネがないから
_ NHK 極める 珈琲学(2)
喫茶店を巡る旅
「コーヒーは社交の道具だった」
- 名曲喫茶
- 喫茶ライオン
- クラシック音楽をレコードで聴く
- ゼビウスとかグラディウスのことですね!!
- 西欧文化への憧れ
- ジャズ喫茶
- 1960-70年代
- 学生紛争の時期
- 新しいものを求めた
- ジャズは中毒になる
- 連帯という言葉が流行りだした
- 連帯の時代
- 糊としての喫茶
- 東京カフェマニア
- 1980年代の喫茶
- カフェバーが生まれた
- バブル後は「くつろいでコーヒーを楽しみたい」に戻った
- 2000年以降
- オーナー個人の趣味による店
- マーケティング関係なく
- 個の時代
_ 週末の夜になると多摩川の道路を珍走団がよく走る
22 時ころから喧しくなる。いつから走るようになったのかよく分からんけど。
_ 沼地でホバークラフト
木曜日あたりに仕事場の隣のひとが「俺、この戦いが終わったら沼地に住むんだ...」と言っていたので俺は「じゃあホバークラフトで通勤ですね」と返すなどして遊んでいたんだがそこでこんな話題をハッケソした
2010-06-13 :-)
_ 読書
2010年5月31日 - 2010年6月6日の読書メーター
読んだ本の数：1冊
読んだページ数：339ページ
狼と香辛料〈14〉 (電撃文庫)
エルサとフランが誰だったか思い出すまでに半分くらい消費した
読了日：06月01日 著者：支倉 凍砂
読書メーター
_ 家計簿
( via 絶対誰でも続けられる家計簿管理術!! : ライフハッカー［日本版］ )
はてなグラフ - rin51のグラフ を家計簿として使おうと努力していた時期もあったんだがナニより 入力が面倒くさい ので 1 年で挫折した。むしろ全体でいくら使ったのかとか分からないので分析できない。
結局いまは散財.com を利用している。みわさんの2010年6月の家計簿。これの何が良いのかというと
- ケータイメールから登録できる
- 商品をほどよく分類してくれる
- 支出分析がある → みわさんの2010年6月の支出分析
使うのが楽なのが重要なんである。
支出分析を眺めるとボトルネックは以下であることが分かる。
- 食品(または外食)
- 趣味娯楽
収入が【お察しください】だしボーナスも【お察しください】なので節約しないといけないんだが。ううむ
_ 節約生活
毎月の出費を7万くらいにしたいので
- 趣味娯楽 5000
- 外食 5000
となるようにしてみよう。
1オライリーは5000円なので技術書(?) ならば1冊であるし
1蔵を5000円なので外食は1回できる
_ [シエナ・ウインド・オーケストラ]リリア吹奏楽フェスタ シエナ・ウインド・オーケストラ コンサート
＠川口リリア
ohguchi から「チケット余ったー」と誘われたので行ってみた。川口は久しぶりだのう。
こんな
第一部
- R.シュトラウス: 「ウィーン市の祝典音楽」よりファンファーレ
- R.シュトラウス: 楽劇＜サロメ＞ Op.54より「7つのヴェールの踊り」
- R.シュトラウス: 交響詩「死と変容」Op.24
第二部
- 田島勉「汐風のマーチ」( 2010 年度全日本吹奏楽コンクール課題曲 IV )
- 広瀬正憲「迷走するサラバンド」( 2010 年度全日本吹奏楽コンクール課題曲 I )
- M.ラヴェル: バレエ「ダフニスとクロエ」第2組曲
「ダフニスとクロエ」の第3曲「全員の踊り」なんてほんとに踊れるんだろか。
_ [リッジレーサーズ2]リッジレーサーズ2 でアドホックパーティをやった
韓国のあのフレンドがたまたまオンラインになっていたので招待された。何度「レースを探す」をしても PS3 が PSP を見つけられなくてウダウダやっていたんだが、結局以下のような手順じゃないとダメなようだ。「レースを開催」しないと PS3 が PSP を見つけられなかった。
- PSP の WLAN スイッチ ON
- PSP リッジレーサーズ2 - WIRELESS BATLLE 選択
- レースを開催 ←
- PS3 アドホックパーティから「ゲームを探す」など
また、たまにレースを探しても見つからないときがあるので、 アドホックパーティ側の「ルーム」を一度閉じて、再度作成するとレースが見つかるようになった。
キッドカーで数レースおこなった。キッドカーなんて久しぶりなのでボコボコクラッシュしまくった。
2010-06-14 :-)
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
_ 工場のようなところなんだが
前の職場が製造業だったおかげで現在の仕事場がアレやコレというのが見えてくる。
_ 烈火
劣化
_ ワールドカップシーズン
なのでみんな大好き NHK (※)もワールドカップ仕様になっているのでテレビ見るものがないのでテレビ消してる時間が長い。などと瞑想していたら世間では はやぶさ帰還のビッグウェーブがあったらしい。
※ 俺が大好きっていうだけ
_ [NetBSD][terminfo][termcap]NetBSD Blog - terminfo has replaced termcap
NetBSD-6 will now sport the terminfo interface which removes a lot of the problems with the old termcap which is deprecated by The Open Group. Upgrading existing systems should be quite painless as the old termcap interface is still provided, but there are some caveats.
古き termcap が抱えているたくさんの問題( The Open Group から指摘されている )を解消する( removes )ために、NetBSD 6 では現在 terminfo インターフェースを導入しようとしている。既存のシステムをアップグレードする際の被害を最小限( quite painless )にするためにしばらくは古き termcap は提供されるだろうけど、いくつかの注意点がある:
- $TERMCAP is no longer supported, tset -s no longer exports it. So if you maintain your own terminal definition, you'll need to use tic(1) on a small terminfo database in $HOME.
$TERMCAP はもはやサポートされていないし tset -s ではエクスポートされない。もし自分自身のターミナルの設定( definition )をメンテナンスするならば tic(1) を使って $HOME に最小限の terminfo データベースを作ること。
- NetBSD extensions to termcap are no longer supported. Only 3rd party applications that used these would be affected.
NetBSD はもはや termcap への拡張( 機能追加 )をサポートしていない。これらを使用した 3rd パーティ製アプリケーションのみが影響を受ける。
This should allow pkgsrc not to need ncurses for a fair few console applications, like say tmux.
これまで pkgsrc では tmux のようなコンソールアプリは ncurses に依存していたが、依存させなくてもよくなるはず。
_ リッジレーサー7 禁オンバト
水無月GP (リッジレーサー7) に向けてひたすら自主練。リバースチャージはトリプルニトロたまらない。
2010-06-15 :-)
_ ;;
キーワード のばら
_ [翻訳][negative symbol cache][NetBSD]NetBSD Blog - NetBSD runtime linker gains negative symbol cache 翻訳
The NetBSD runtime linker now has a negative symbol cache. In a nutshell, this has reduced the startup time of the Evolution mail client from around 5 minutes to 3 seconds on my QuadCore amd64 machine. Not many applications have a lot of plugins with a large amount of links to external libraries and I doubt many other applications will gain such a drastic speed bump, but the GNOME desktop as a whole now loads small bit quicker. I would imagine that KDE will now load faster as well.
現在の NetBSD のランタイムリンカ( 訳: ld.so_elf のこと )はネガティブシンボルキャッシュを使うようになった。ようするに、これがあるとメールクライアントの Evolution を起動するのに 5 分かかっていたものが 3 秒で起動するようになる( 私の QuadCore AMD64 マシンの場合 )。大量の外部ライブラリを使うアプリケーションはそう多くないし、他のほとんどのアプリケーションではそれほど劇的にスピードアップすることはないだろうと思っているけど、GNOME デスクトップ全体では微妙に速くなる。KDE は現在のものよりは速くなりそう。
_ [翻訳][negative symbol cache][NetBSD]NetBSD negative symbol cache 翻訳
Significant changes from NetBSD 5.0 to 6.0
ld.so_elf
Implement negative symbol lookup cache [roy 20100227]
[PATCH] ld.elf_so - Cache objects checked
I've been researching why Evolution from GNOME takes over 5 minutes to load on my quad core amd64 beast. It boils down to dlsym looking for a symbol that does not exist directly and as such examining every needed library. However, the current implementation does not remember what libraries it as already checked. Normally this isn't a problem, but with the way Evolution is built the search chain is massive.
なぜ私の Quad core AMD64 の環境で GNOME を起動するのに 5 分もかかるのか調べてた。ようするに、dlsym はシンボルが見つからなかったとっきに必要なライブラリをその都度探しにいくんだが、現在の実装ではどのライブラリがチェック済みなのか覚えてないのだよ。普段はこれは問題にならないのだけど、重量級の環境だと問題になる( 訳: ???? )
As such, I've ported FreeBSD's DoneList cache from their runtime linker to ours. The main implementation difference is we xmalloc + xfree vs their alloca + no free needed. They've been using this for a long time, so the idea + code is pretty solid.
そういうわけで、私は FreeBSD の DoneList キャッシュを NetBSD の( 訳: ours )ランタイムリンカに実装した。
However, I've added a second cache for weak symbols to _rtld_symlook_needed which is where the real performance gain is made for my use case. Whilst this doesn't break my system and I cannot see a flaw in it's design maybe someone can comment?
あと( 訳: However ) 私の使い方で本物のパフォーマンス( 訳: ???? )を引き出すために、さらに weak シンボルのための 2次キャッシュを _rtld_symlook_needed へ追加した。私のシステムで使ってるうちは死ななかったし( 訳: break ) 設計に問題ないように見えるのだけど、何か意見ある？
With this patch, Evolution (without the patches to and a glib I added to pkgsrc a few days ago) loads in under 2 seconds (5 seconds with initial disk thrashing).
添付したパッチを使うと Evolution ( パッチなし glib を数日前に pkgsrc に追加した ) は 2 秒以内に起動する( 初期化のためのディスクスラッシングに 5 秒かかる )
_ weak シンボル
- Weak symbol - Wikipedia, the free encyclopedia
- リンクされているライブラリによってプログラムの動作を変える - bkブログ
- リンクと同名シンボル: weak シンボル編 - bkブログ
weak シンボルについては Linkers & Loaders の6章に以下の解説があります。
ELF では、weak参照のほかに weak定義というもう1つの weakシンボルを追加している。 weak 定義は、通常の定義が存在しない場合に大域シンボルを定義する。通常の定義が存在する場合は、 weak 定義は無視される。
_ [翻訳][NetBSD][ELF]NetBSD Blog - Kernel modules for macppc and shark 翻訳
As of past night, the macppc and shark ports have support for the new-style kernel modules. I've added support for these through a workaround in the build system, which makes the compiler generate long jumps for all calls in the code, avoiding unsupported ELF relocation types. This allows us to use the modules even if the kernel-level loader is not able to deal with such relocations. The kernel-level support is now enabled by default in macppc and shark GENERIC kernels.
昨晩( 訳: ? ) macppc と shark ports に新しいスタイルのカーネルモジュールが取り込まれた。未サポートの ELF 再配置(のタイプ)を回避するために、コンパイラに long jump を挿入したコードを生成させる仕組みを追加した。たとえカーネルレベルローダーが ELF 再配置できないとしても、カーネルモジュールにこの手段を適用できる。カーネルレベルサポートは macppc と shark ports の GENERIC カーネルではデフォルトで有効になっている。
We'll need to revisit this in the future and implement real support for dealing with those relocation types. Why? The modules built with this flag are slower than they should be... but at least they do work.
( この対処については )近い将来また考え直す必要があるし、再配置タイプをちゃんとサポートしないといけない。なぜかって？ このフラグを立ててビルドしたモジュールはノロいし、それに...まあ少なくとも一応動作する。
_ [ELF]ELF
- FreeBSD 2.X、3.X、4.X についての FAQ (よくある質問とその答え)その他の質問 FreeBSD の実行フォーマットの a.out、ELF とはどのようなものですか? また、a.out、ELF を使う理由は何でしょう?
- elf(5) : FreeBSD 一般コマンドマニュアル
- NetBSD ELF FAQ
- ELF - osdev-j (MMA)
- ELF/実行時の話 - osdev-j (MMA)
- The Linux ELF HOWTO
2010-06-16 :-)
_ 朝ッ
0520 起床
_ 乙がポニーテールに見える
(・ω・｀)乙 これは乙じゃなくてポニーテールなんだからね！
_ %ＣＶ
%ＣＶに居ると自分が無知で無能でクズ。アホでバカ。低脳でワーキングプアに思えてくる。まあでも間違ってないか。
_ [NetBSD][LVM][翻訳]NetBSD Blog - NetBSD LVM support 翻訳
NetBSD LVM サポート
NetBSD LVM support was committed in -current for a long time now but it was disabled by default. Today I have set MKLVM variable to yes by default which means that LVM will by included in all builds from now. I have also updated in tree LVM tools to their latest version 2.02.56.
NetBSD の LVM サポートが -current にコミットされてから随分たつけど、現在はデフォルトでは無効にされている。現在の設定以降( 訳: ???? ) すべてのビルドで LVM が含まれるようにするために、変数 MKLVM をデフォルトで yes になるように設定する。あと最新の( 訳: latest ) LVM tools バージョン 2.02.56 ツリーへアップデートもしておいた。
With much appreciated help of Soren Jacobsen and Hubert Feyrer we was able to publish new LVM related chapter of the NetBSD guide. You can find and read it at LVM chapter.
Soren Jacobsen と Hubert Feyrer が NetBSD ガイドに LVM 関連の新しい chapter LVM chapter を書いてくれたので、読んで理解を深めよう。
I'm working on a RUMP based port of NetBSD device-mapper driver to make writing of new targets more easier.
私は現在新しいターゲットをもっと簡単に書きやすくするために、NetBSD device-mapper ドライバーの RUMP ベースの port を作っている( 訳: ここの port は「移植作業」と解釈すべき？ )
_ [NetBSD][wake][翻訳]NetBSD Blog - wake(8), a New Wake-on-LAN Command 翻訳
wake(8): 新しい Wake-on-LAN コマンド
wake is a new command to send Wake-on-LAN frames over an ethernet to Wake-on-LAN capable machines, remote powering them up. This functionality is generally enabled in a machine's BIOS and can be used to power on machines from a remote system without having physical access to them.
wake は Ethernet 上へ Wake-on-LAN フレームを送り、リモートにある Wake-on-LAN を備えた計算機を起動させるためのコマンドである。この機能は一般的に計算機の BIOS で有効にし、物理的にアクセスできない所にある計算機をリモートシステムから起動させるために使われる。
wake is available in NetBSD-current. See the wake(8) manual page for details.
wake は NetBSD-current で使える。詳細は wake(8) のマニュアルを参照。
_ [NetBSD][getdelim][getline][翻訳][NetBSD Blog - NetBSD gets getdelim(3) and getline(3) 翻訳
NetBSD は getdelim(3) と getline(3) を手に入れた
Last night I added getdelim(3) and getline(3) to NetBSD.
昨晩 私は getdelim(3) と getline(3) を NetBSD へ追加した。
A few programs in base system needed to be changed due to having their own getline function, most of which aren't anything like getline(3). Hopefully there won't be much fallout in pkgsrc as a result.
ベースシステム( 訳: /bin, /sbin, /usr/bin, /usr/sbin などのこと? ) にあるいくつかのプログラムは getline(3) 風のものを誰も持っていなかったので、独自の getline 関数が欲しいために各々が変更する必要がある( 訳: ???? たぶん「車輪の再発明」が多発してる、という意味だよね )
getline(3) is prefered over over functions such as fgetln(3) and fgets(3) because it's standards based and you get a dynamic buffer for really really long lines. However, POSIX did drop the ball on making it a standard from the GNU extension - it should return 0 on EOF and more importantly be called fgetline. Oh well.
getline(3) は POSIX 準拠( 訳: standards based )だし、ほんとーにほんとーにものすごーーーーく長大な行について動的にバッファを使えるから fgetln(3) や fgets(3) のような関数よりもかなり望ましい。でも POSIX だと GNU 拡張から来た標準については処理できない( 訳: drop the ball ) 。GNU 拡張のやつは EOF に達すると 0 を返すし、もっと重要なのは fgetline から呼ばれてるということだ。やれやれ( 訳: Oh well )
I shall be rolling getline(3) support into dhcpcd later, but I'll have to do a link test in the Makefile to see if we can use it. I'm unsure if I want to have a mini configure for dhcpcd or to keep using just make extensions ....
最新の dhcpd をサポートするために getline(3) を軌道に乗せようとしているんだけど( 訳: ????)、使おうとする場合は Makefile 内でリンクできるか試さないといけない。dhcpcd のための簡単な configure を書いたり、DHCP Extensions ( 訳: ???? )が欲しいんだけど、それをやる自信が無い...。
2010-06-17 :-)
2010-06-18 :-)
_ 朝ッ
0520 起床
_ [Postfix][NetBSD][翻訳]NetBSD Blog - Postfix 2.7.1 imported into NetBSD-current 翻訳
Postfix 2.7.1 が NetBSD-current に取り込まれた。
Postfix 2.7.1 was imported into NetBSD-current today. The major changes since Postfix 2.6.6 are:
今日 Postfix 2.7.1 は NetBSD-current に取り込まれた。Postfix 2.6.6 からのおもな変更点:
- Improved before-queue content filter performance. With smtpd_proxy_options = speed_adjust, the Postfix SMTP server receives the entire message before it connects to a before-queue content filter. Typically, this allows Postfix to handle the same mail load with fewer content filter processes.
before-queue コンテンツフィルターのパフォーマンス改善。smtpd_proxy_options = speed_adjust にしておくと、Posftfix SMTP サーバーはbefore-queue コンテンツフィルターに接続する前にメッセージ全文を受信する。これにより、同じメッセージに対して読み込むコンテンツフィルターがわずかになる。
- Improved address verification performance. The verify database is now persistent by default, and it is automatically cleaned periodically. Under overload conditions, the Postfix SMTP server no longer waits up to 6 seconds for an address probe to complete.
アドレス検証のパフォーマンス改善。アドレス検証のデータベースをデフォルトで永続するようにし、定期的にクリーンアップするようにした。過負荷時の Postfix SMTP サーバーは 1 アドレスの検証が完了するまでに 6 秒も待たないようにしてある。
- Support for reputation management based on the local SMTP client IP address. This is typically implemented with FILTER transportname: actions in access maps or header/body checks, and mail delivery transports in master.cf with unique smtp_bind_address values.
ローカルの SMTP クライアントにもとづく reputation management 対応( 訳: ホワイトリストのこと???? )。これは通常 FILTER という名前の transport として実装される: アクセスマップ( 訳: /etc/postfix/access のこと ) 又はヘッダー/本文による処理( 訳: action )や、 master.cf 内の smtp_bind_address 値にもとづきメール配送すること。
_ [リッジレーサー7]リッジレーサー7
オンラインバトルなど。勝ちを譲ってもらったり
- 走行距離 87810 km
- RSGP 進行度 100.0 %
- 名声 23393 FP
- オンラインバトル勝利数 866/3176
_ NetBSD ja
> 3. リダイレクトをやめて、/ja/JP/を > www.NetBSD.jp/ に移す > (神戸さんとお話しする必要あり) こういう必要性があったときのために持ってたドメインですので、 何時でも連絡ください。 -- 神戸 隆博 / Takahiro Kambe
なんと
netbsd.jp なんて存在したのか。
( 持ち主は神戸さん )
2010-06-19 :-)
_ 朝ッ
1130 起床
_ 極める!珈琲学(3)
コーヒーの効能
- コーヒーのダイエット効果
- カフェインが脂肪燃焼を助ける
- 実験くん
- 「カメラの前で黙ってるなんて出来ないよっ(・ω・)」
- カフェインなしで計測
- カフェイン260mg摂取後に計測
- 体にカフェインが行き渡るのに1時間かかる
- 結果 ブドウ糖の消費よりも脂肪を消費した
- へえ？
- コーヒーと学習効果
- 実験で算数のテストをした
- カフェイン摂取後のほうが100人中6人は成績良かった
- 6人て誤差じゃないのか
- コーヒーと病気
- コーヒー飲むひとは
- 糖尿病になりにくい
- 肝臓ガンになりにくい
- 心臓病になりやすい
- 腎臓が悪い人はカリウムがさらに増える
- 3〜4杯が無難
_ python 自習
cygwin
% ipython
In [1]: import platform
In [2]: platform.platform()
Out[2]: 'CYGWIN_NT-6.1-WOW64-1.7.5-0.225-5-3-i686-32bit'
In [3]: import os
In [4]: os.uname()
Out[4]:
('CYGWIN_NT-6.1-WOW64',
'kotomi',
'1.7.5(0.225/5/3)',
'2010-04-12 19:07',
'i686')
NetBSD/i386
% ipython
In [2]: import platform
In [3]: platform.platform()
Out[3]: 'NetBSD-5.0.1-i386-32bit-ELF'
In [5]: import os
In [7]: os.uname()
Out[7]:
('NetBSD',
'hitomi.area51.gr.jp',
'5.0.1',
'NetBSD 5.0.1 (GENERIC) #0: Thu Jul 30 01:39:11 UTC 2009 builds@b8.netbsd.org:/home/builds/ab/netbsd-5-0-1-RELEASE/i386/200907292356Z-obj/home/builds/ab/netbsd-5-0-1-RELEASE/src/sys/arch/i386/compile/GENERIC',
'i386')
_ [リッジレーサー7]リッジレーサー7
ARC 2010 水無月GP やった。
結果( ただし、桜上水すずめさん、knhtymhさんは途中参加 )
- ANSΩB2マンタレイ 186
- JE4URN 176
- agumon11 168
- ANSΩmiwarin 157
- ANSΩ三嶋出雲 156
- 桜上水すずめ 84
- knhtymh 68
- ANSΩマリアナブルー 66
- レミリア 50
knhtymhさんはルーターの設定を変更しルームに入れるようになったとのことで、ようやく一緒に遊べた (*´Д｀)
- 走行距離 88170 km
- RSGP 進行度 100.0 %
- 名声 23457 FP
- オンラインバトル勝利数 866/3186
_ [リッジレーサー7]リッジレーサー7 ARC 2010 総合得点
現在の総合得点はこちら リッジレーサー7: ARC2010
この中でこれまでの全レース参加しているのは 4 名。その得点。
- ANSΩB2マンタレイ 556
- JE4URN 411
- ANSΩ三嶋出雲 399
- ANSΩmiwarin 372
B2ェ
2010-06-20 :-)
_ 読書
2010年6月7日 - 2010年6月13日の読書メーター
読んだ本の数：2冊
読んだページ数：554ページ
機動戦士ガンダムUC(4) パラオ攻略戦 (角川スニーカー文庫)
読了日：06月11日 著者：福井 晴敏機動戦士ガンダムUC(4) パラオ攻略戦 (角川スニーカー文庫)
マリーダ・クルスの生い立ち。ぐぬぬ。戦時中とはいえもう少しマシな人生にしてやれよ。ここまで書かないとマリーダ・クルスのキャラを生かせないということなんだろうけど
読了日：06月11日 著者：福井 晴敏
読書メーター
_ 車好き、マリオ好きのためのブログ 好きな音楽アンケート！
チームANSの皆さんへ
皆さんは何か好きな音楽はありますか？ちなみに僕はリッジシリーズやグランツーシリーズ、邦楽ではB'zや嵐が好きですね。皆さんもぜひ聞かせて下さい！コメントの返信もします！
結論からいうと、ゲーム音楽以外聞いてない。
Last.fm からコピペしようと思ったんだけど画像キャプチャした。
アーティストはこう。スクウェア関連とかナムコ関連が多い。AEON は英会話の AEON の教材こと。
アルバムはこう。
_ [Python]Python 自習
手元のプログラムを 1 対 1 で書き直してみるテスト。
とりあえずトップページが Ruby なので Python にしてみた。
まあ。超きたないんだけど platform.system() は NetBSD しか試してない。
#!/usr/pkg/bin/python
# -*- coding: utf-8 -*-
import cgi
import platform
import time
import os
since_this_site_year = "1999"
#this_site_year = time.strftime( "%Y", time.localtime() )
this_site_year, = time.localtime()[:1]
web_master = "RIN"
poweredby = ""
systemname = platform.system()
if systemname == "Linux":
poweredby = '<a href="http://www.linet.gr.jp/~kojima/Plamo/index.html"><img src="./images/plamo7b.jpg" width="100" height="50" align="left">'
elif systemname == "Darwin":
poweredby = '<a href="http://www.apple.com/jp/darwin/index.html"><img src="./images/poweredbydarwin.gif"></a><p>Darwinは、米国およびその他の国で登録されているApple Computer, Inc.の商標です。</p><p>Powered By DarwinバッジはApple Computer Inc.の商標であり、同社の許可により使用しています。</p>'
elif systemname == "FreeBSD":
poweredby = 'freebsd'
elif systemname == "NetBSD":
poweredby = '<a href="http://www.netbsd.org/"><img src="./images/powered-by-netbsd.png">'
else:
poweredby = ""
def print_html_head():
html_head = '''Content-type: text/html
<html>
<head>
<title>
みわの本拠地
</title>
<meta http-equiv="Content-Type" content="text/html; charset=utf-8" />
<link rel=stylesheet href="generic.css" media=all>
<link rel="meta" type="application/rdf+xml" title="FOAF" href="foaf.rdf" />
</HEAD>
<BODY>
ここはみわの公式サイトです。
<center>
<font size=7 color="#00000000">みわの本拠地</font><br>
<p>
</center>
<hr>
'''
print html_head
def print_html_tail():
html_tail = '''
<hr>
<address>
<img src="./images/gmailicon.png">
</address>
<p>
当ページにリンクを貼ることは自由です。<br>
問い合わせは不要です。<br>
文書、画像などの転載は勝手にやってください。<br>
また、こちらから勝手にリンクすることがあります。<br>
「そりゃ困る」という方は上記メールアドレスへご連絡ください。<br>
</p>
<p>
%s
</p>
<script src="http://www.google-analytics.com/urchin.js" type="text/javascript">
</script>
<script type="text/javascript">
_uacct = "UA-690958-2";
urchinTracker();
</script>
</body>
</html>
'''
print html_tail % poweredby
def print_html_body():
contents = [ [ "./about.html", "なにここ" ],
[ "./diary/", "ヨタの日々[ 2001.08.01- ]" ],
[ "./link/", "リンク" ],
[ "./pcmemo/", "計算機云々" ],
[ "./event/index.rb", "予定とか" ],
[ "./cam/", "りんカム" ],
[ "./foaf.rdf", "FOAF" ],
[ "./hiki/", "rin's Wiki"],
[ "./amazon/","Amazon アソシエイト" ] ]
body = '''<p><li><a href=%s>%s</a></p>'''
print "<ul>"
for c in contents:
print body % ( c[0], c[1] )
print "</ul>\n"
print_html_head()
print_html_body()
print_html_tail()
_ [Python]Python 自習のやりかた
cygwin で書く
Python 標準ライブラリ を読みながら使えるライブラリを探す
cygwin 上で ipython をインストールして[ 20100225#p04 ] ipython でチマチマと試す
CGI のテストは python -m CGIHTTPServer してローカルで動作確認 ( Pythonで超簡単にCGIの動作を確認する方法 - TRIVIAL TECHNOLOGIES 2.0 )
_ きゅうけい!!
＠喫茶店 LPIC 201 模擬試験3回目 52点
2010-06-21 :-(
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
シミュレーターで遊ぼう
残業アワー
残業するのが 2 年ぶりくらい[ 20081030#p03 ]であった。
1700 以降の体力の消耗具合がひどい。
残業するための体力がないじゃにか
_ ;
もう夢に出ることはない
_ ;;
だからそのライフ八苦が適用できるかどうかは場合によると何度も言ってるだろう。
_ ,
永遠にたまねぎ剣士
_ [NetBSD][翻訳]hubertf's NetBSD blog - NetBSD 5.1_RC3 binaries available for download 翻訳
NetBSD 5.1_RC3 バイナリがダウンロード可能になった。
NetBSD release-engineer Soren Jacobsen announces: ``The third (and hopefully final) release candidate of NetBSD 5.1 is now available for download at:
NetBSD リリースエンジニア Soren Jacobsen による告知: NetBSD 5.1 の 3番目の release candidate ( これが最後だと願いたい ) がダウンロード可能になった -> http://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.1_RC3/
Those of you who prefer to build from source can continue to follow the netbsd-5 branch, but the netbsd-5-1-RC3 tag is available as well.
ソースからビルドする場合は netbsd-5 ブランチを引き続き使える。netbsd-5-1-RC3 タグも同様に使える。
See src/doc/CHANGES-5.1 for the list of changes from RC2 to RC3.
RC2 から RC3 への変更点は src/doc/CHANGES-5.1 を参照。
Please help us test this release candidate as much as possible. Remember, any feedback is good feedback. We'd love to hear from you, whether you've got a complaint or a compliment. That said, we hope your feedback is positive, as we would like this to be the final release candidate before 5.1. ''
出来るだけたくさん release candidate をテストして、我々を助けてほしい。忘れないでほしいのだが、どんなフィードバックであってもそれは良いフィードバックだ。あなたが抱えている不満や賞賛を聞くことを、我々は望んでいる( 訳: love )。とは言ったものの、5.1 への最後の release candidate にしたいので、なるべくならポジティブなフィードバックのほうがうれしい。
_ [翻訳][NetBSD][無線LAN][ワイヤレス]NetBSD Blog - Switching between wired and wireless automatically 翻訳
有線 LAN と無線 LAN を自動で切り替える方法
I was asked recently how to switch between wired and wireless automatically on NetBSD, and remembered that Hubert Feyrer has a good way of doing it.
NetBSD でどうやって有線 LAN と無線 LAN を自動で切り替えるのか聞いて、Hubert Feyrer が とても良い方法を教えてくれた ことを思い出した。
So please feel free not to send me any chocolate if you don't find this useful.
もしこれが役立たないなら、feel free not to send me any chocolate してほしい( 訳: チョコレート???? )
Comments:
dhcpcd-4.99 in pkgsrc does this automatically - no need to script anything. Just Install and Go (TM) :)
コメント
それ pkgsrc の dhcpcd-4.99 でできるよ。スクリプトとか要らないし。さあインストールしようず!
2010-06-22 :-(
_ 朝ッ
0520 起床
_ ,
らんらんるー
_ ,,
舞太かわいい
_ ,,,
自分をしんじてー
_ ::
ガルデモとはなんだったのか
_ 虹
日比野真琴( ref. ボンボン坂高校演劇部 - Wikipedia )に恋をしたようなので「今度のクリスマスにデートしようず」と誘ってみたら ok という返答を貰い心が躍り MP ( マジックパワー )をどうのこうのするくらいに感激した。というところまでの夢を見た。なぜいまさらボン坂なのか( 1992 年の作品 )、なぜクリスマスなのか、謎は深まるばかりでありよく分からないけどきっと暑さのせいだろう:
@miwarin そういう夢ならしょっちゅう見ますよ！ (aski)
正常らしいので安心した。
_ [NetBSD][testing][ATF][自動テスト][翻訳]NetBSD Blog - Automated testing in NetBSD 5.0 翻訳
NetBSD 5.0 での自動テスト
With the release of NetBSD 5.0, a new testing infrastructure for the operating system will get wide exposure. This testing infrastructure is based on the Automated Testing Framework (ATF), a project that was started as part of the Google Summer of Code 2007 program, and that provides a platform-independent framework to easily write and automatically exercise test cases. As of this release, only a few NetBSD-specific tests are available as ATF-based tests, but they are a good preview of what the future will look like.
NetBSD 5.0 では、NetBSD オペレーティングシステムのための新しいテスティングインフラストラクチャーが拡大された。このテスティングインフラストラクチャーは、Automated Testing Framework (ATF) ( これは Google Summer of Code 2007 の一部として開始されたプロジェクトである )をもとにしていて、プラットフォームに依存しないフレームワークを簡単に書き、テストケースを自動で実行するためのものである。このリリースでは、ごくわずかの NetBSD 限定( 訳: NetBSD-specific )の テストが ATF ベースのテストとして有効で、プレビューしたところうまくいってるように見える。
Starting from this release, you will see a new tests.tgz distribution set during the installation of NetBSD. If you choose to install it, sysinst will populate /usr/tests with a new collection of test programs that are based on the ATF framework. Once installed, edit /etc/atf/NetBSD.conf to suit your system preferences and then, to run the tests, do:
このリリースから使い始めれば、インストール用 NetBSD の中に新しい tests.tgz 配布物があるのが分かるだろう。tests.tgz のインストールを選択したら、sysinst は、ATF フレームワークにもとづく新しいテストプログラム集を /usr/tests へ配置( 訳: populate )する。一度インストールしてしまえば、/etc/atf/NetBSD.conf を編集してテストシステムを設定し、以下のようにテストを実行すればいい:
# cd /usr/tests # atf-run | atf-report
The whole idea of providing the test programs as an installable distribution set is that your specific combination of hardware and software is not available to system developers, so only you can make sure that the system behaves as it should. Furthermore, by successfully running the tests, you can have a good feeling that everything is working as expected!
あなたが使っているハードウェアとソフトウェアの組み合わせはシステム開発者のもとでは使えず、あなたのシステムを機能させることはあなたにしかできないために、テストプログラムをインストール用配布物にして提供するというアイデアにした。
As far as I know, there are some tests in this release that are broken, but I'm not sure if this is because the tests themselves are broken or because the features under test are broken. Help is welcome in this area!
私が知る限りでは、このリリースではいくつかのテストが失敗するのだけど、テストそのものが悪いのか、テストは正常で機能が悪いのか、私には分からない。この辺りについて手助けしてほしい。
There is still a lot of work to do in the automated testing area... but the fact that ATF is now bundled in a formal release of NetBSD raises my willingness to work on it. If only I had enough time... At the very least, expect many more ATF-based test cases in NetBSD 6.0.
自動テストの部分( 訳: area )ではまだ動作しているものがたくさんあるんだけど.... ATF がいまや NetBSD 公式リリースに含まれたことが私を奮い立たせてくれる。( 訳: 前半と後半のつながりがおかしいな )。私にあとほんの少し時間をくれたら、NetBSD 6.0 にはもっとたくさんの ATF ベースのテストケースが入ることを期待してくれていい。
_ [リッジレーサー7]リッジレーサー7
オンラインバトルなど。DYN 車を使ってはいけないような空気だったので空気を読んでひたすら FIERA
- 走行距離 88390 km
- RSGP 進行度 100.0 %
- 名声 23473 FP
- オンラインバトル勝利数 869/3194
_ Wiki - ANSΩFryghtの不定期日記 - Yahoo!ブログ
( コメント書いたら spam 扱いされてしまったのでこっちに書く )
wiki といえば wikipedia が有名だけど、wiki は任意の編集者が適当にページを作ったり編集することができるものです。
@HOME のサイト を眺めるだけでもどういうことが出来るか分かるんだけど
wikiの例として、たとえば私の手元だとこんな感じのものを作ってます rin's Wiki - リッジレーサー7
旅行の日程考えたり rin's Wiki - 沖縄でジンベエザメと握手
でも放置しておくと spam にやられたりします jipgcpyfrb - FrontPage
ちなみにチーム ANS サイトを作るときに「 wikiでもいいか 」と思ったんだけど独自ドメインを使いたいだけのために現在の形になってます (・ω・)
@HOME の KYO さんは、先日 4日連続阻止レースなどといったことをやった方かしら。たまにご一緒するけど
2010-06-23 :-(
_ 朝ッ
0520 起床
_ ,
今週は毎日リポビタンDを飲んでいる
_ ,
むしろたんに夏バテなのかもしれず
_ [ドライビングテクニック]ドライビングテクニック
仕事場の隣のひとがサーキットや峠で走り込みグランツーリスモだけでなくリッジレーサーもこよなく愛するプログラマーらしく、昼休みなどに私が「グランツーリスモ PSP をプレイして初めて気づいたんだが、ドリフトは難しいのだな」と云ふと「よくあること。慣れないひとがドリフトしようとするとハンドルを当てすぎて車体が踊るんだよねアハハ ドリフトするにはカクカクシカジカなので 三輪さんもデミオでドリフトするといいよ」などといった会話をしているんだがそこでこんな助言を貰った:
「コーナーに入るときは急にブレーキを踏むんじゃなくてじょじょに踏む。コーナー中はブレーキを踏まずにアクセルは踏み込み過ぎずに軽く噴かす程度(????)にする」
これ読んでおけと本を勧められた。
4544040442
_ NetBSD blog 翻訳
1 年くらい前の記事も翻訳してるのでちゃんと日付も引用しておかんといかんと。
_ [NetBSD][UDF][翻訳]NetBSD Blog - UDF enhancements (read-write CD/DVD file system) 翻訳
UDF 強化( CD/DVD ファイルシステムを読み書きするために )
July 13, 2009 posted by Reinoud Zandijk
UDF is a full read-write operating system independent file system to be used on CD and DVD media but also very usable on `flash media'. See the OSTA website and Wikipedia for a more in depth overview. A read-only version made it to NetBSD-4.0 and a full read-write version made it to NetBSD-5.0
UDF はオペレーティングシステムに依存しないファイルシステムで、CD や DVD だけでなくフラッシュメディアも非常に便利に扱うことができる。詳しいことは OSTA や Wikipedia を参照。NetBSD-4.0 では読み込み可能な UDF( 訳: 書き込み不可 ) が、NetBSD-5.0 では完全に読み書き可能な UDF が実装されている。
Recent enhancements to UDF available in NetBSD-current and pulled up to netbsd-5 are
NetBSD-current と netbsd-5 で UDF 機能強化に関連することを挙げる:
- Accurate disc space calculation that won't allow overfilling discs that could previously panic the machine.
マシンがパニックになるため、容量いっぱいのディスクにたいして正確なディスク容量が計算できない。
- Rewritten read-modify-write backend.
read-modify-write バックエンドの刷新
- Significant reduction of system time spend when encountering huge numbers of nodes.
とても巨大なノードがあると発生するシステムタイムの浪費を大幅に減らすこと
_ おうちサーバーが死んでいた
fsck が
THE FOLLOWING FILE SYSTEM(S) HAD AN UNEXPECTED INCONSISTENCY
などと言ってるんだがその対象が
/dev/rwd1e /data1
という mount ポイントにたいする処理のようだった。
/dev/rwd1e とか使ってないし。
いまのサーバーにディスク 2 つ以上つけてないし。
たぶん何かの名残り。
2010-06-24 :-(
_ 仕事
0830 出勤
_ ,
リポDなし
_ ,
のみほー
_ こっち見んな
( ﾟдﾟ )
_ 車好き、マリオ好きのためのブログ 好きなゲームランキングベスト１０！
チームANSの皆さんへ
皆さんもどんなゲームが好きか是非僕に教えて下さい！僕はグランツーリスモシリーズ、マリオ関係のゲームが上位になってますね。
- リッジレーサー7
- リッジレーサーズ2
- ファイナルファンタジー XII
- ファイナルファンタジー VI
- ファイナルファンタジー V
- ロマンシングサガ( 初代 )
- サガフロンティア
- ダウンタウン熱血行進曲 それゆけ大運動会
- ルドラの秘宝
- トレジャーハンターG
プレイした時間が長そうな順に並べた。「好きなゲーム」という時点でおっさんは回顧厨にならざるをえない。ていうかスクウェアばかりじゃないか。
_ [翻訳][NetBSD][GPT]NetBSD Blog - Google Summer of Code: GPT bootloader 翻訳
Google Summer of Code: GPT ブートローダー
July 01, 2009 posted by Mike M. Volokhov
About the project
このプロジェクトについて
The GUID Partition Table is a new standard for disk partitioning. The GPT layout provides a set of advanced partitioning features including, but not limited to:
GUID パーティションテーブルはディスクパーティションの新しい標準である。GPT レイアウトは、以下にあげるものに限らず advanced partitioning 機能セットのうちいくつかを提供する:
- modern logical block addressing (LBA)
- モダンな logical block addressing (LBA)
- 64-bit LBA pointers, allowing partitions up to 8 Zbytes in size, and even bigger
- 8 Zbytes ( 訳: 8ゼタバイト ) よりも大きいサイズのパーティションでの 64ビット LBA ポインター
- suitable for disks with sector size, other than 512 bytes
- 512バイトよりも適しているディスクセクターサイズ
- by default up to 128 partitions per disk
- ディスクあたりのパーティションのデフォルトを 128 にする
- backup partition table.
- パーティションテーブルのバックアップ
The NetBSD already has support for GPT disks via dkwedges, but can't boot off a GPT partitioned disk. My GSoC project is to implement a GPT aware bootloader for the NetBSD operating system by extending its existing MBR/disklabel BIOS-based multistaged kernel loader.
NetBSD はすでに dkwedges により GPT ディスクをサポートしているのだが、GPT パーティションのディスクからブートできない( 訳: boot off ???? )。私の GSoC プロジェクトは、BIOS ベースの従来の MBR/disklabel( 訳: existing MBR/disklabel BIOS-based )を使ったマルチステージカーネルローダーを拡張することにより、NetBSD オペレーティングシステムのための GPT ブートローダーを実装することだ。
Please note, although GPT comes from the EFI world and the loader somewhat mimics EFI bootstrap behavior, the project is not about writing a pure EFI loader. Instead, it will be based on BIOS interface and will technically look like an arbitrary MBR loader but with GPT parsing. Such an approach should allow the use of GPT partitioned disks on non-EFI systems as well. On EFI systems NetBSD can be bootstrapped via the Compatibility Support Module.
注意してほしいのだけど、GPT は EFI からもたらされたものであるし、EFI ブートストラップの挙動を真似たところがあるとはいえ、GPT ブートローダープロジェクトは純粋な EFI ローダーを書き起こすプロジェクトではない。むしろ、BIOS インターフェースをもとにするし、技術的には GPT を解釈する任意の( 訳: arbitrary ???? ) MBR ローダーのようなものになるだろう。そのうえ、このアプローチならば EFI ではないシステムの GPT パーティションディスクでも使えるようになる。EFI システム上の NetBSD は Compatibility Support Module から起動できる。
Current status
現状
The project assumes development of MBR (or LBA0), Partition Boot Record, and adopting of 1st stage and 2nd stage loaders.
このプロジェクトは MBR( または LBA0 )の開発、パーティションブートレコード、そして 1st ステージと 2nd ステージローダーを採用した。
Currently, the MBR (LBA0) loader which parses GPT is in a beta stage. It implements the following features:
現在は GPT を解釈する MBR (LBA0) ローダーはβステージに入った。これは以下の機能を実装した:
- locating GPT headers by looking at LBA1 and the last LBA of boot disk
ブートディスクの LBA1 と最後の LBA を見つけ、そこに GPT ヘッダを置く( 訳: ???? )
- checking the GPT header for its signature and validating the CRC32
GPT ヘッダのシグネチャをチェックし、CRC32 を検証する。
- walking through the partition table looking for a bootable partition
パーティションテーブルを見つけるためにブータブルパーティションを横断する
- reading the PBR from a bootable partition, testing its boot capability, and passing control to it if the test was successful.
ブータブルパーティションから PBR を読み込み、ブートできるかどうかをテストし、テストが成功したらテストを通過する。
Code cleanup and CRC32 calculation of GUID partition array (which wasn't included due to space constraints, but likely can be enabled after optimisation) are still required.
コードを整理し、必要であれば GUID パーティションアレイの CRC32 を計算する( 領域を圧迫するほどではないけど、最適化後には有効になるようにする ????? )
It was decided to store the primary loader on an EFI System Partition (which is FAT formatted by convention), and not use NetBSD partitions for bootstrapping. Such behavior will be similar to what EFI bootstrapping does, and the boot path will be as follows:
EFI システムパーティションのプライマリーローダーの格納(場所？)を決定し( 慣習として FAT フォーマットになる )、ブートストラップに NetBSD パーティションを使わないようにする。この挙動は EFI ブートストラップの挙動と同様であり、ブート時の順番は以下のようになる:
BIOS → LBA0 → PBR on EFI syspart → /boot → NetBSD kernel.
Fortunately, the "fatboot" (or bootxx_fat16) loader can do almost all of the required things in place of the PBR and 1st stage loader. The only missing thing is FAT lookup at an arbitrary offset on the disk (right now it assumes LBA0). It was easily implemented by having partition offset passed from GPT MBR or from any other loader through the ecx:ebx register pair. As we can't rely on all other loaders using this mechanism, the offset could be embedded into the PBR itself by installboot(8).
幸いなことに、fatboot ( または bootxx_fat16 )ローダーは、PBR や 1st ステージローダーが動作するところならば、ほとんどすべてのところで動作する。ただ 1 つ失敗するのは、FAT がディスクの不定な位置にあるときである( いまのところ LBA0 がそう )。GPT MBR 以降にパーティションオフセットがあるか、ecx:ebx レジスタペアを経由するそのほかのローダーからより簡単に実装できた。( 訳: 混乱してきた... ) このメカニズムを使った他のすべてのローダーはあてに出来ず、このオフセットは installboot(8) により PBR 内に組み込まれた。
My current efforts are focused on getting gpt.S and fatboot.S (and corresponding management tools) in shape and ready to publish for beta testing. So the future work in terms of the GSoC project will include the following:
現在取り組んでいることは、gpt.S と fatboot.S ( とそれに付随する管理ツール )を整理、βテストのための配布を準備しているところだ。よって、GSoC プロジェクトに関連する今後の作業は以下のようになる:
- code cleanup for gpt.S (LBA0) and fatboot.S
- gpt.S (LBA0) と fatboot.S のコードの整理
- review of bootloader installation tools and updating documentation
- インストールツールのブートローダーのレビューと、ドキュメントの更新
- adding GPT support into boot(8)
- boot(8) に GPT サポートを追加
- more documentation updates and getting code in shape for CVS merge
- さらにたくさんドキュメントを更新して、CVS にマージするためにコードを整理する
Some additional information (including development schedule) can be found at the project home page at: http://netbsd-soc.sourceforge.net/projects/gpt/
開発スケジュールを含む いくつかの追加情報はプロジェクトホームページを参照: http://netbsd-soc.sourceforge.net/projects/gpt/
用語
2010-06-25 :-(
_ 朝ッ
0520 起床
_ 自分探しのたび
こんな感じで google で検索すればいい
site:togetter.com miwarin
site:2ch.net miwarin
site:2ch.net "ANS" リッジレーサー
_ 8/7 今日は一日“ゲーム音楽”三昧
( via ゲーム音楽を聴こう )
今日は一日“ゲーム音楽”三昧
8月7日(土)後0:15～11:00(中断あり)
きたわあ
…しかしながら、ゲー音三昧の8月7日って、DQコンサートと被っているんですよ…！
あ゛
_ [NetBSD][ZFS][翻訳]NetBSD Blog - Google Summer of Code zfs-port project status update 2 翻訳
Google Summer of Code の ZFS 移植プロジェクトのステータス更新(2)
July 01, 2009 posted by Adam Hamsik
ZFS as whole has 2 main ways it can be accessed. The first is ZVOL and the second is ZPL. In my first status update I said that I had ported ZVOL layer to NetBSD, and I was able to create and use ZFS Zpools and Zvols (Logical partitions exported from one disk storage pool called zpool).
ZFS を利用するための方法はおもに 2 つある。1 つめは ZVOL で、2 つめは ZPL だ。私からの最初の報告は、NetBSD へ ZVOL レイヤーの移植し、そして ZFS Zpools と Zvols を作成し、利用できるようにしたことだ( 1 ディスクストレージから出力した論理パーティションを zpool と呼ぶ )。
Over the last few weeks I have worked on a ZPL port. ZPL is ZFS file system layer. I have ported zfs_vfsops.c file and zfs_vnops.c file to NetBSD. Today I have ZFS to state where I can mount ZFS data set, copy whole kernel source tree there and finally build NetBSD kernel on it.
数週間前に私は ZPL を移植した。ZPL は ZFS ファイルシステムのレイヤーである。zfs_vfsops.c ファイルと zfs_vnops.c ファイルを NetBSD へ移植した。手元( 訳: copy )の NetBSD カーネルソースツリーでビルドできたので、現在は ZFS データセットをマウントできるようにしてある。
$ su # modload /mod/solaris.kmod # modload /mod/zfs.kmod # zfs mount test/zfs
# mount /dev/wd0a on / type ffs (local) kernfs on /kern type kernfs (local) ptyfs on /dev/pts type ptyfs (local) /dev/zvol/dsk/test/zfs on /test/zfs type zfs (local) # zfs list NAME USED AVAIL REFER MOUNTPOINT test 391M 1.57G 18K /test test/tank 40M 1.61G 16K - test/zfs 351M 1.57G 351M /test/zfs test/zfs1 18K 1.57G 18K /test/zfs1
# cd /test/zfs/src/sys/arch/i386/compile/GENERIC/
# make making sure the compat library is up to date... `libcompat.a' is up to date. making sure the kern library is up to date... `libkern.o' is up to date.
# compile GENERIC/init_main.o cc -ffreestanding -fno-zero-initialized-in-bss -O2 -std=gnu99 -fno-strict-aliasing -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Werror -Di386 -I. -I../../../../../common/include -I../../../../arch -I../../../.. -nostdinc -DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT -I../../../../lib/libkern/../../../common/lib/libc/quad -I../../../../lib/libkern/../../../common/lib/libc/string -I../../../../lib/libkern/../../../common/lib/libc/arch/i386/string -I../../../../dist/ipf -I../../../../external/isc/atheros_hal/dist -I../../../../external/isc/atheros_hal/ic -I../../../../../common/include -c ../../../../kern/init_main.c
# create vers.c sh ../../../../conf/newvers.sh
# compile GENERIC/vers.o cc -ffreestanding -fno-zero-initialized-in-bss -O2 -std=gnu99 -fno-strict-aliasing -Werror -Wall -Wno-main -Wno-format-zero-length -Wpointer-arith -Wmissing-prototypes -Wstrict-prototypes -Wswitch -Wshadow -Wcast-qual -Wwrite-strings -Wno-unreachable-code -Wno-sign-compare -Wno-pointer-sign -Wno-attributes -Wextra -Wno-unused-parameter -Werror -Di386 -I. -I../../../../../common/include -I../../../../arch -I../../../.. -nostdinc -DMAXUSERS=64 -D_KERNEL -D_KERNEL_OPT -I../../../../lib/libkern/../../../common/lib/libc/quad -I../../../../lib/libkern/../../../common/lib/libc/string -I../../../../lib/libkern/../../../common/lib/libc/arch/i386/string -I../../../../dist/ipf -I../../../../external/isc/atheros_hal/dist -I../../../../external/isc/atheros_hal/ic -I../../../../../common/include -c vers.c
# link GENERIC/netbsd
ld -Map netbsd.map --cref -T ../../../../arch/i386/conf/kern.ldscript -Ttext c0100000 -e start -X -o netbsd ${SYSTEM_OBJ} ${EXTRA_OBJ} vers.o
NetBSD 5.99.14 (GENERIC) #1: Tue Jun 30 20:00:37 UTC 2009
text data bss dec hex filename
8554455 407284 538396 9500135 90f5e7 netbsd
I tried to boot build kernel and it worked like a charm. There is still much work to do port ZFS snapshot support, properly implement security policies for ZFS access, test ZFS ACL support etc.
ビルドしたカーネルでブートし、ちゃんと動作するように取り組んでいる。ZFS スナップショットサポートを移植したり、ZFS アクセスのためのセキュリティポリシーを適切にしたり、ZFS ACL サポートをテストするなど、まだたくさんやることがある。
My work is accessible in my git repository at git://rachael.ziaspace.com/src.git in a branch called haad-zfs. You can easily clone this repo with command git clone git://rachael.ziaspace.com/src.git. To get haad-zfs branch checkout you need to use command git checkout -b haad-zfs origin/haad-zfs from src directory.
私の作業は git リポジトリ git://rachael.ziaspace.com/src.git の haad-zfs ブランチでアクセスできる。git clone git://rachael.ziaspace.com/src.git とコマンドをたたけば簡単に clone できる。ソースディレクトリから head-zfs をチェックアウトするには git checkout -b haad-zfs origin/haad-zfs とコマンドをたたけばいい。
2010-06-26 :-)
_ [はやぶさ]HAYABUSA -BACK TO THE EARTH
( via otsuneさん )
＠サイエンスドーム八王子
「はやぶさ」は2003年5月に打ち上げられた日本の小惑星探査機。
小惑星イトカワに着陸し、岩石を持ち帰る世界初の壮大なプロジェクトを「はやぶさ」の打ち上げから、2010年6月の帰還までを全編CGで描いたドキュメンタリーです。
全天周スクリーンに映し出される迫力ある映像が、あなたを宇宙旅行の旅にいざないます。
ということで行ってきた。はやぶさ帰還後のわりにはかなり空いてた。ネットでアレだけ盛り上がってた連中はどこに行ったんだろう。
全編 CG で地球を出発してから帰還するまでを描いたもの。開発スタッフなどが登場することはなく、あまりドキュメンタリーという感じはしない。ナレーションはドラマチックな口調なのでそこが感動の大安売りのようなセリフだったのが残念。「仕事の流儀」などのように事実を淡々と語ってくれたほうがもっと興奮できたかもしれぬ。まあ子供向けなのだろうけど。途中で「2010年1月 地球へ帰還予定」などとあったので、たぶん当初作られたときは はやぶさ帰還前だったんだろう。はやぶさ帰還後に「2010年6月 はやぶさ帰還」などというのが追加されたようだ。
見どころは、スイングバイの場面と、やはり最期の大気圏突入の場面か。NHK の宇宙関連の番組などでもよく太陽系のはるか上空(?)からの視線でのアニメーションは見るんだが、ここではスイングバイの突入に必要な *道* まで描画しており、それがまるで地球による後押しを表しているようだった。あんな興奮するスイングバイは初めて見た。開発スタッフたちは狂喜したんじゃないだろうかと想像できる。そして最期は回収カプセルを放出し、あとは大気圏へ突入し燃え尽きるだけという はやぶさの姿。はやぶさ帰還の当時 はやぶさについてまったく無関心だったんけどこのアニメーションを見るだけで号泣してしまった。などと言ってみたが私のほうがよほど感情的に書いてるじゃないか。
HAYABUSA BACK TO THE EARTH は他にも何箇所かで上映しているらしい 全天周映像 HAYABUSA -BACK TO THE EARTH-
_ AT車
MT車のときの習慣が抜けず、AT車なのに
- 発進時にアクセルを踏み込み過ぎる
- MT 1速から2速へギアチェンジするタイミングでアクセルから足を離す
むしろどれだけアクセルを踏めばどれだけ加速するのか、という感覚がまだつかめない。
2010-06-27 :-)
2010-06-28 :-(
_ 朝ッ
0520 起床
_ 無限ループ
for( ;; ) ;
_ ,
while( 1 ) ;
_ または
10 nop goto 10
_ オウフ
def func(): func()
_ デュクシ
def hoge(): hoge() return
_ フォカヌポウ
def moge(): return moge()
_ ,
真綾って最近は握手会とかやってるの?
_ ,
Slackware ってまだあるの?
_ ,
死んだ魚の目をしている
_ 目ヂカラ
暗い意味で
_ 夏の思い出語ろうず
- 小学生: 遊んでた
- 中学生: 部活
- 高校生: 部活
- 大学生: バイト
- 会社人: お察しください
中学と高校は部活やってた記憶しかないし大学生のころは遊んだ記憶がまったくない。会社人になってからはひたすらダラダラしている。ということで 夏を無駄に過ごさないために読んでおきたいエントリーまとめ - スチーム速報 ＶＩＰ のような状況は小学生のころにしか体験してない。海? なにそれレイアース?
_ ケータイとか変遷
- DoCoMo
- H"
- au
- DoCoMo
_ なぜガラケーではないのか
もっぱらメールとウェブ( モバツイくらい )しか使っておらず、オサイフケータイとかワンセグとかそういったものをさっぱり使ってないため、ガラケーである必要がなかったというか Xperia が面白そうだったし iPhone はみんな持ってるし。
_ と書いておけば
ガラケー信者が押し寄せてこないかなー
2010-06-29 :-(
_ 朝ッ
0520 起床
_ 通勤
汗だく
_ [ipython][python]いつもの
% wget http://peak.telecommunity.com/dist/ez_setup.py % python ez_setup.py % easy_install ipython
_ ,
ドラッカーが売れてるならそのぶんだけ状況がよくなるとお思いで
_ [NetBSD][テスティング][翻訳][ATF]NetBSD Blog - Testing NetBSD: Easy Does It
NetBSD をテストするのは簡単にできる
June 24, 2010 posted by Antti Kantee
In a software project as large as NetBSD the interactions between different software components are not always immediately obvious to even the most skilled programmers. Tests help ensure that the system functions according to the desired criteria. Periodic automated runs of these tests with results visible on the web ensures both that tests are run in a regular fashion and that the results are available to all interested parties.
NetBSD ほどの規模のソフトウェアプロジェクトにおいて、異なるソフトウェアコンポーネント間の関連は最上級プログラマであってもすぐに把握できるようなものではない。the desired criteria によれば( 訳: 要求仕様???? )、システム関数はテスト可能である必要がある( 訳: ううむ.... )。テストを定期的に実行し、テストとテスト結果をウェブに表示するというやり方はよくやるし、すべての当事者にとって有効である。
This short article explains the NetBSD test strategies and provides a brief overview of the enabling technologies. It also details how effortless it is to run the test suite and why doing so is in every developer's, patch submitter's and system administrator's best interest. The intended audience is people with a keen interest in testing and quality assurance, and a desire to reduce personal headache. The article is written against NetBSD-current as of June 2010 and applies to what will eventually become NetBSD 6.
ここでは、NetBSD のテスト方針を説明し、テストの実現方法の概要を説明する。また、いかに手間をかけずにテストスイートを実行するか、なぜテストがすべての開発者、パッチ提供者、そして管理者にとって有益なのかを説明する。対象とする読者は、テストや品質保証に強い関心があるひと、頭痛の種を減らしたいひとである。この文章は 2010 年 6 月の時点での NetBSD-current で書き直したものであり、いずれ NetBSD 6 にも反映されるだろう。
Automated Testing Framework (ATF)
Automated Testing Framework (ATF)
Julio Merino's Automated Testing Framework (ATF) unifies the interface for running tests, enables customizable test report formats and provides a standard interface for implementing tests. ATF also provides a mechanism for tests to determine if the feature under test, such as hardware, is present in the system and skip the test instead of incorrectly failing it. The goal is to make the tests run conveniently in batch mode without human supervision -- hence the name automated. ATF is shipped with NetBSD and all new NetBSD tests should be written against ATF.
Julio Merino による Automated Testing Framework (ATF) はテストを実行するためのインターフェースを統合したものである。テスト結果をカスタマイズして整形し、テストを実装する標準インターフェースを提供する。ATF はまた、システムに搭載されているようなハードウェアテストのように、テストが失敗した原因を究明するためのテストの仕組みや、誤っていたときにテストを失敗する代わりにスキップする機能も提供する。( 訳: ????? )
ATF tests are found under /usr/tests in a standard NetBSD installation. As pointed out on the ATF website, this is done to enable a system administrator to run the NetBSD test suite for the specific hardware/software setup with minimal effort. Executing the tests should be viewed as insurance for a particular installation and reporting any test failures immediately may save a lot of head scratching down the road.
ATF テストは NetBSD を標準インストールでは /usr/tests にある。ATF ウェブサイトで指摘しているように、システム管理者が最小の労力でハードウェア/ソフトウェアの NetBSD テストスイートを実行できるようにしてある。テストを実行すると、インストール時の insurance を見ることができ、どんなテストが失敗したらすぐに将来頭を抱えることになるものを保存する( 訳: なんのこと????? )
The tests can be run with the atf-run command in the appropriate subdirectory for a partial set of tests or on the top level of /usr/tests for the entire NetBSD test suite. Since the output of atf-run is meant to be post-processed by other tools, the idiomatic command for creating a human-readable report includes a pipe to the report generator:
テストを実行するには、tests set 内の適切なサブディレクトリか、または /usr/tests で atf-run コマンドを実行すれば、NetBSD の test 一式を実行できる。atf-run の出力は、パイプなどを介し、レポート可視化ツールによって post-processed しやすい出力になっている:
atf-run | atf-report
This gives a verdict for all the tests. Also, a summary like the following one is presented:
これによりすべてのテストを評価され、以下のような出力を得られる:
Summary for 25 test programs:
83 passed test cases.
0 failed test cases.
0 expected failures.
2 skipped test cases.
Further documentation for running the tests and controlling the report format is available from the ATF manual pages, specifically atf-run and atf-report.
テストの制御や、出力形式について詳しいことは、 ATF の atf-run や atf-report のマニュアルページに詳細が書いてある。
Automated NetBSD Installation and Test Application (anita)
( 訳: Automated NetBSD Installation and Test Application 自体が固有名詞なのでこれは訳す意味ないよね )
The Automated NetBSD Installation and Test Application (anita) is a tool written by Andreas Gustafsson. When anita is run, a URL to release set binaries is given as an argument. Anita downloads the release sets, creates a disk image, boots the downloaded release in a virtual machine and installs the release. For example, the following command will download and install NetBSD/i386 5.0.2, and boot the resulting installation to a command prompt:
The Automated NetBSD Installation and Test Application (anita)は、Andreas Gustafsson によって書かれたツールである。anita を実行するとき、引数として release set の URL を受け取る。Anita は release sets をダウンロードし、ディスクイメージを作成し、ダウンロードした release を仮想マシン上で起動し、インストールする。たとえば、次のコマンドは、NetBSD/i386 5.0.2 ダウンロードし、インストールし、起動し、実行結果をコマンドプロンプトへ表示する:
anita interact ftp://ftp.NetBSD.org/pub/NetBSD/NetBSD-5.0.2/i386/
Currently, anita supports only QEMU and the i386 port, although there has been interest in adding support for other virtual containers and NetBSD ports. Since installation is done in a virtual machine, the environment is theoretically the same regardless of the host the command is run on. This is both a blessing and a curse: different anita runs are comparable regardless of where they are executed, but features specific to certain machine configurations are not exercised. Nevertheless, if an anita install is successful, there is reasonably high confidence that the release it was executed for works.
現在は anita は QEMU と i386 port のみをサポートしているけど、他の virtual containers や NetBSD port をサポートすることに興味はある。仮想マシンへのインストールが完了したら、その環境は、理論的には anita interact を実行したホストと同じ環境になる。これは幸福でもあり災いでもある: 異なる anita を実行すると、実行された anita と比較的無頓着である ?????????? のだが、あるマシンのための設定をする詳細の機能は動作しない ??????????。それにもかかわらず、anita のインストールが成功したならば、anita の実行結果はそれなりに信用していいだろう。
What makes anita especially effective for testing installation is that it uses "screen scrape" with the sysinst installer. This means the display output of sysinst is read and interpreted by anita, and commands are given as response to the output. This tests that the installation works like a human would be doing it and sets it apart from testers which use various machine scripts to perform test installations.
anita の何がインストールテストにとくに効果的なのかというと、sysinst インストーラーと一緒に screen scrape を使うことだ。sysinst の出力は、anita に読まれ、解釈され、コマンドはその出力への応答として与えられる。このテストは人間のようにインストールをテストし、様々なプラットホームのマシンでのインストールをテストするスクリプトを実行するテスターのためにある。
Test Reports On The Web
ウェブでテストレポートを見る
In addition to anita, Andreas has written a set of tools which fetch the current sources from cvs, build a release, and use anita to install the release and run the ATF tests. The results are currently available on his website. The source revisions committed between each build/install/test run are available behind the "Details" links on the page. Furthermore, if the system build is broken, the tools make an effort to hunt down the exact guilty commit before publishing the result as to when the build was broken.
さらに anita には、Andreas が書いた current ソースを cvs から取得したり、release ビルドしたり、anita でrelease をインストールして ATF テストを実行する、というツール群がある。その成果は彼のウェブサイトで見ることができる。コミット済みのリビジョンのソースでは、build/instlal/test のいずれも実行でき、"Details" リンクを辿ればそのソースを見ることができる。さらに、システムビルドが失敗する場合、そのツールはビルドの失敗を報告する前に失敗する原因を特定しようと試みる。
If despite testing efforts a regression does slip through, the logs from the runs make it easy to track down which commit introduced the regression, even days after it was introduced -- although hopefully it will not take so long to correct things. Once enough logs have been accumulated, they can also provide a source to figure out what breaks often, due to what, and for how long. This information can be used to prevent similar problems for occurring in the future.
レグレッション( テスト? )でもまだ解決しない場合( 訳: ???? )、レグレッション( テスト? )が失敗する原因を追求するためにレグレッション( テスト? )を実行したあとの数日間は実行結果のログが役立つ( 訳: ???? )。けどあまり長期間それが有効であることは期待できない。じゅうぶんなログが蓄積されたのならば、失敗したときになぜそうなり、どのくらいの間そうなっていたのかを解明するための材料となる。この情報により、今後似たような状況になることを防ぐことができる。
Running The Test Suite With Anita
Anita によるテストスイート実行
The results mentioned in the previous section are used as a reference point to determine the current health of NetBSD. Developers and users submitting patches are encouraged to repeat the anita test run to make sure changes do not have unwanted side-effects. Additionally, developers are committed to not causing long-term regressions in the anita test runs -- a clean test report for a submitted patch may further convince that the patch was sufficiently tested and should be included in NetBSD. Nevertheless, common sense is allowed as to when this is necessary.
前節でのテスト結果は、NetBSD の状態を診断するための基準となる。開発者や利用者からパッチが提供されれば、望まぬ副作用が発生していないか確認するために anita でのテストを繰り返して実行することができる。そして、開発者は anita テストを実行し、 long-term レグレッションさせずにコミットできる。提供されたパッチへの全テスト( 訳: clean test ???? )のレポートは、パッチはじゅうぶんにテストされ、NetBSD に入れることについてさらに確信をもてるだろう。とはいうものの、NetBSD 界隈では( 訳: common sense )テストが必須であることを認めるだろう( 訳: ???? )。
Although writing tests is not covered in this article, it is also highly recommended that new features are submitted with the relevant tests in the same package. This is also to the advantage of the submitter since, as mentioned above, developers are required to make sure [future] changes do not cause existing tests to fail.
ただし、テストを書くことについてはこの文書の範囲外であり、新しい機能は関連するテストも一緒にパッケージとすることをお勧めする。( 訳: 前半と後半がうまくつながらない )。これは、提供者の強みである。上述のとおり、開発者は、変更があったとき既存のテストが失敗しないことを要求するからである。
Anita can be found in pkgsrc under misc/py-anita. As of writing this, pkgsrc-current (and what will become pkgsrc-2010Q2) is required. Also, QEMU version 0.12nb3 or later is required due to a bugfix in the CPU emulation -- test runs will hang indefinitely without this bugfix.
Anita は pkgsrc の misc/py-anita にある。この文書が書かれた時点では、pkgsrc-current ( そしてもうすぐ pkgsrc-2010Q2 も ) が必要になる。そして CPU エミュレーションについて bugfix されている QEMU version 0.12nb3 またはそれ以降が必要になる -- bugfix されてないとテストがハングする。
A full anita install/boot/test cycle including the ATF test report is accomplished by using the test option. For example, when build.sh is used to build release sets into /objs/obj.i386/releasedir/i386, the following command would be used to run an install/boot/test cycle:
ATF テストレポートを含めた anita による install/boot/test の全工程は、テストオプションを使うことで完遂できる。たとえば、build.sh は、/objs/obj.i386/releasedir/i386 で release sets をビルドすればいい。install/boot/test をおこなうそのコマンドはこう:
aanita test /objs/obj.i386/releasedir/i386/
If the development host runs NetBSD and is sufficiently up-to-date, it is possible to simply run the ATF tests there. However, due to reasons already mentioned, the results might or might not reflect the anita run. The recommended "no brains necessary" method to make sure that a change does not cause a regression in the anita run is to do an anita run. Since it does not require additional hardware or even disrupting current work due to having to reboot, there is little excuse for not doing so. On the flip-side, the anita run does not test the system configuration of the development host, so ultimately the best choice is to run the tests in both environments. This arguably doubles the amount of necessary command lines from one to two, but still leaves little excuse for not executing both.
開発マシンで NetBSD が動作していて最新に保っているならば、ATF テストを実行するのは簡単だ。しかし、すでに原因が追求されているならば、anita の実行結果については熟慮したほうがいいかもしれない。"no brains necessary" された場合、変更されていても anita を実行したときにレグレッションは発生しない( 訳: ???? )。よって、ハードウェアを追加したり、または reboot によって作業を中断させる必要がない ようにするためにほんの少し作業するだけでいい。その反面、開発マシンのシステム設定のテストを anita で実行することはできない。結局、最善の選択は、両方の環境でテストが走ることだ。この 2 つを間違いなくおこなう( 訳: ???? )ためには 1, 2 行のコマンドラインが必要になるのだけど、まだ両方を実行することはいくつかの理由により出来ない( 訳: ???? )。
Conclusions
おわりに
This short article presented NetBSD testing options and provided a brief introduction to the tools to make it happen. NetBSD testing is done periodically with results available from a web page, but manual execution, either piecemeal or wholesale, is possible and highly recommended. Ultimately tests help ensure the quality of NetBSD, and it is in everyone's personal interest to run tests on their local machines and to include test cases along code submissions.
この文書では NetBSD テストのオプションと、テストツールで何が出来るかをいつくか紹介した。NetBSD テストの結果は定期的に更新され、ウェブページから確認することができるのだけど、とくに、一部分や全体( 訳: ???? )をテストする場合は手動で実行するといい( 訳: ???? )。結局テストは NetBSD の品質を保証できるし、誰でも自分のマシンでテストできるし、コードを配布するとき( 訳: ???? )に含めることも出来る。
Acknowledgments
謝辞
Thanks to Andreas and Julio for their work on these awesome tools and for comments on a draft of this article.
Andreas と Julio の素晴らしいツールとその仕事に敬意を表し、この文書へコメントしてくれたことに感謝する。
2010-06-30 :-(
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
_ そういうのはオタク趣味ではなくポップカルチャーの一種でしかないんだよな。
( 強調は三輪による )
例えば声優で言うなら「僕は茅原美里ちゃん！」とか「僕は中島愛ちゃん！」とか言ってるうちはまだまだで「俺は斎藤千和が」「俺はまだ林原めぐみが捨てきれない」とか言えるようになって初めてという感じか。
｜ω・)
_ ,
chikachan 阻止レースだったのかー
_ 「動画はYoutubeにあるから探すといいよ ＞＜」
それアウトだから！
_ [NetBSD][翻訳][ZFS]NetBSD Blog - Google Summer of Code zfs-port project 翻訳
( 先日の ZFS 報告[ 20100625#p05 ] よりも前の記事 )
June 04, 2009 posted by Adam Hamsik
ZFS-port project introduction
ZFS 移植プロジェクト序説
ZFS is well known file system developed by Sun Microsystems, inc. for Solaris operating system. Its source code was released under the CDDL license. ZFS currently was ported to several other operating systems like Mac OS X and FreeBSD.
ZFS は Sun Microsystems によって作られたファイルシステムとして知られている。ソースコードは CDDL ライセンスのもとにリリースされた。現在 ZFS は Mac OS X や FreeBSD などのようないくつかのオペレーティングシステムへ移植されている。
ZFS port to NetBSD was started in Summer of code 2007 by Oliver Gould. Later Andrew Doran (my mentor in this project) worked on zfs port and released several versions of his work Partial zfs port.
ZFS の NetBSD への移植は Summer of code 2007 で Oliver Gould により始められた。その後 Andrew Doran ( このプロジェクトの指導者 )が zfs 移植作業をし、その zfs port の一部がいくつかリリースされた。
More about ZFS features and how it works can be found at presentation ZFS last word in file systems.
さらなる ZFS の機能と仕組みについて、ファイルシステム内の ZFS の最後の語( 訳: ????? )に説明されていることが分かる。
The ZFS file system contains two major modules ZVOL and ZPL.
ZFS ファイルシステムはおもに ZVOL と ZPL というモジュールを含んでいる。
The ZVOL is Logical Volume Manager module of the ZFS. It creates/manages Logical disk drives created from pools of disk space called ZPOOLS.
ZVOL は ZFS の論理ボリュームマネージャーモジュールである。ZVOL は、ZPOOLS と呼ばれるディスク領域を使い、論理ディスクを作成したり管理する。
The ZPL is file system layer used for creating ZFS file system on a ZVOL volume.
ZPL は、ZVOL ボリューム上の ZFS ファイルシステムを作成するために使われるファイルシステムレイヤーである。
【図は省略】
Deliverables
配布( 訳: ???? )
Mandatory (must-have) components:
必須コンポーネント( 無くてはだめ ):
- Finish port of ZFS ZVOL layer to NetBSD
- NetBSD へ ZFS ZVOL レイヤーの移植を完了させること
- Implement device partition properties. Change newfs, dm(4) and other logical disk drivers.
- デバイスパーティションプロパティを実装すること。newfs や dm(4) や他の論理ディスクドライバーを変更すること。
- Implement device disk(driver:model-revision-serial-etc) ids for identification of zfs disk.
- zfs ディスクのためにデバイスディスク( ドライバーのモデルとかリビジョンとか ) ids を実装すること。
- Port vfsops and vnodeops. ignore getpages/putpages.
- vfsops と vnodeops を移植すること。getpages/putpages は除く。
Optional (would-be-nice) components:
オプションコンポーネント( あればうれしい ):
- Implement getpages/putpages
- getpages/putpages を実装すること。
- Callbacks into arc, for reclaim of memory or kernel virual space.
メモリーまたはカーネル仮想領域の回収のための arc 内でのコールバック
- Maybe changing the order of arguments for pool_cache constructors.
- おそらく pool_cache 構造体の引数の順番を変更することになる。
- Implement nameiat and lookupnameat functions.
- nameiat 関数 と lookupnameat 関数を実装すること。
Progress zvol, modules, wedge like disks
zvol モジュールでディスクのように拡張する。
( 訳: 領域を増やすなどという意味だよね。↓のコマンドを見ると )
ZFS and solaris modules can be loaded to NetBSD system.
ZFS モジュールと solaris モジュールは NetBSD にロードできる。
Zvol is one of two basic parts of ZFS. This subsystem manages disk space added to ZFS pools. Administrator can create Logical Volumes/manage their size just like with LVM. Currently user can create zvols and use them as Logical Volumes for ffs file system.
Zvol は ZFS の基本構成の 1 つである。Zvol は ZFS 領域へ追加されたディスクスペースを管理する。管理者は、まるで LVM のように論理ボリュームを作成し、管理することができる。現在 ユーザーは zvol を作り、ffs ファイルシステムを論理ボリュームのように扱うことが出来る。
I have written small patch to support wedge like devices in newfs and all utilities using getdiskinfo() from partiutil.c file. Commiting patch was discussed here.
newfs でデバイス楔( 訳: ???? )サポートするために少しパッチを書き、すべてのユーティリティは partiutil.c ファイルの getdiskinfo() を使うようにした。コミットしたパッチは議論中。
Examples
例
# zpool create -f test /dev/wd1a
# zfs create -V 200M test/ufs
# /mod/newfs /dev/zvol/rdsk/test/ufs
/dev/zvol/rdsk/test/ufs: 200.0MB (409600 sectors) block size 8192, fragment size 1024
using 5 cylinder groups of 40.00MB, 5120 blks, 9920 inodes.
super-block backups (for fsck_ffs -b #) at:
32, 81952, 163872, 245792, 327712,
# zpool list NAME SIZE USED AVAIL CAP HEALTH ALTROOT test 260M 5.22M 255M 2% ONLINE -
# zfs list NAME USED AVAIL REFER MOUNTPOINT test 200M 27.9M 18K /test test/ufs 200M 223M 5.13M -
# mount /dev/zvol/dsk/test/ufs /mnt/ # mount /dev/wd0a on / type ffs (local) kernfs on /kern type kernfs (local) ptyfs on /dev/pts type ptyfs (local) /dev/zvol/dsk/test/ufs on /mnt type ffs (local)
In example zpool test is created from disk wd1a, later new zvol called ufs is created from it. newfs compiled with my getdiskinfo patch is later used to create file system on this zvol. File system is later mounted to /mnt.
この例で、zpool は wd1a ディスクから作成され、その zpool を使って ufs から呼ばれた新しい zvol が作成される。私の getdiskinfo パッチを当ててコンパイルされた newfs は、その後 zvol でファイルシステムを作成するために使われる。ファイルシステムはその後 /mnt にマウントされる。
Source code
ソースコード
Source code is managed in my own git repository at git://rachael.ziaspace.com/src.git. This code should be only used for review, getting some panics :). Be aware that it is Work in progress code which can panics/deadlocks a lot.
ソースコードは私の git リポジトリ git://rachael.ziaspace.com/src.git で管理されている。このコードはまだパニックするのでレビュー専用にしてほしい :-) このコードはまだ作成中なのでパニックしたりデッドロックすることがあることを知っておいてほしい。
_ いずも★ [なんだかんだで、勝負強いですねぇ～★勝率を見ればそれが伺えます。 企画レースの最終更新です。ANSのHP見ていれば..]
_ みわ [三嶋さんのほうが速いでしょう ('A`) 夜に急用を入れるかもしれないので参加できないかもしれないす。すまぬ。ア..]
_ いずも★ [俺速くねぇしｗｗｗｗあんたの方が速いしｗｗｗｗ 3800回レースしてて、たったの810勝しかしてないんだからｗｗｗ..]
_ ちく(ry [そうだそうだ、あんたの方が速いし(゜ε゜;)]
_ みわ [いずも☆: 私はフィエラとかビゾンテとかアベイユなど速い車ばかり使ってるますもの (´・ω・`) ちくｒｙ: ち..]