2010-07-01 :-)
_ 朝ッ
0520 起床
_ IRC wide 最後の日だった
2010/07/01 00:18 masapon_> 本日0時をもってirc.fujisawa.wide.ad.jpおよびirc6.fujisawa.wide.ad.jpのサービスを停止いたしました。長い間のご利用ありがとうございました。
あつ
ref. WIDE : Press Release : WIDEプロジェクトIRCワーキンググループによるIRCサーバ運用終了について
_ [NetBSD][翻訳]hubertf's NetBSD blog - BSD Magazine archive available 翻訳
BSD Magazine のアーカイブができたよ
Olga Kartseva writes: ``BSD Magazine archives available without subscribing to BSDMag newsletter for freebsd-announce subscribers!'' Here are direct PDF links:
Olga Kartseva 曰く: 「 freebsd-announce の諸君。BSDMag newsletter への登録しなくても BSD Magazine のアーカイブを利用できるようになったよ」 PDF への直リンはこちら:
- Hosting BSD
- BSD as A Desktop
- BSD as Servers
- Infinity. Freedom. FREEBSD
- BSD Security
- Guide to FreeBSD
- PC-BSD Uncovered
- Explore NetBSD
Enjoy - and remember: more NetBSD content is good content, authors are always welcome!
ゆっくりしていってね!!
あと忘れないでほしいのだけど、 NetBSD の記事はなんでも OK なので執筆者は歓迎するよ。
_ 2010年夏アニメ
手当たりしだい
_ こんにゃくゼリーの窒息事故、85%が重症 ※ただしこんにゃくゼリーは全体の 0.8%
( via つっちぃんとこ )
以前調べたんだけど[ 20080930#p11 ]データ更新されたのでメモしなおす。
食品安全委員会 - 食品安全委員会：食品による窒息事故に関するワーキンググループ：第７回食品による窒息事故に関するワーキンググループ ここの 資料１−３：一口あたり窒息事故頻度の算出について[PDF] ( PDF でかいです )
たとえばこう。
2010-07-03 :-)
_ [JNUG][NetBSD]日本NetBSDユーザーグループ第十二回定期総会 および NetBSD BoF 2010
コードでは貢献してないんだけどせっかくだから行っているアレ
第十二回定期総会 - jun
- NetBSD
- 日本人開発者 38人
- JNUG 会員 50人くらい
- 各地 OSC などの報告
- PS2/PS3 NetBSD とか
- ヤフオクには古い計算機がたくさんあるのでポチると良い
2010/07/03 NetBSD BOF 2010
OpenBlockS 600 現状説明 - kiyohara
- OpenBlockS 600 - OpenBlockS
- CPU: PowerPC 405EX
- 耐塵 耐熱されていて素敵
- OpenBlockS 266 をルーターにしたり
- USB は組み込み用
- EHCI が無い
- CF が IDE じゃなくて USB になっており umass として扱う
- ( Armadillo ってどうだっけ )
- ブートローダーは uboot
- uboot 用イメージを作るツールは NetBSD current にあるとかなんとか
- FreeBSD は ACPI の先に pcihostbus を生やしているとか
NetBSDのSTR81xx/91xxへの対応 - rsh
- STR9105とか
- ナントカいう製品
- 中身は Linux
- シリアルつないでタスクスイッチ押しながら起動したら uboot したとか
- Linux の野良ブランチカーネルを参考にしながら NetBSD へ
NetBSD goes POSIX.1-2008 and C1X - tnozaki
- POSIX とはなんぞや
- Portable Operating System Interface
- POSIX - Wikipedia, the free encyclopedia
- Open Standards ここにほとんどの文書がある
- Command Line Interface と Application Programming Interface を規定
- POSIX 2008
- 旧 SUS ( tnozaki さんがよく言っている「仕様」 )
- The Open Group Base Specifications Issue 7
- XBD, XSH, XCU の 3 部構成
- Extend part 4
- locale とかその周辺
- C1X
- C言語の仕様 3rd edition
- C1X - Wikipedia, the free encyclopedia
AsiaBSDCon 2011 - hrs
- whoami
- cvs ミラーとか *allbsd.org
- allbsd.org - homepage
- FreeBSD core team: 喧嘩をおさめるだけ
- AsiaBSDcon
- 論文数
- FreeBSD > OpenBSD > NetBSD
- NetBSD はかなり少ない
- OpenBSD 多いのは意外
- BSDCan
- FreeBSD ばかり
- OpenBSD は昔バトルがあったので参加者ほとんど居ない
- NetBSD は純粋に居ない
- EuroBSDCon2010
- 「○○してみた」という使い方が多い( HowTo みたいな )
- 悩みの種
- 参加者からどういう需要があるのか分からない
- チュートリアルとか何やると人が集まるのか
- ドライバの書き方とか需要あるのか
- keynote
- 日本人いない
- 最初が村井純だったのでそれから *落とす* のもアレだし
- ( 最初が村井純かよ! )
- 話してもらいたいひとが居たとしてそのひとにどうコンタクトとればいいのか
- ( 私から 2hop するとエライひとに到達するような気がすんだが )
- 募集中
- WP( working progress 「作業中のもの」 ) は盛況。5 ～ 10分の発表でいい( LT か )
- 誰かに「これを話してもらいたい」とか
- 企画
- スポンサー
- 参加者
- おカネ
- Foundation はおカネの使い道を公開しなければならない
- ウェブを見れば書いてある
- 収支はすべて寄付、支出はすべて開発者へ
- FSF の場合: 収支1億円 支出1億円
- FreeBSD の場合: 2500万円くらい
- NetBSD の場合: ぼちぼち
懇親会
いつものとこ
www.NetBSD.ORG 翻訳プロジェクト について okano さんとどうのこうのしたりなど。隣では tnozaki さん が W-ZERO3 インストール大会を開催していた。
あまり写真撮らなかった
2010-07-04 :-)
_ LPIC 201 に合格した
ギリギリ
2010-07-05 :-)
_ 朝ッ
0520 起床
_ 君のあんみら服姿が見たい！
だそうな
_ [RAID][RAIDframe][NeBSD][翻訳]NetBSD Blog - Google Summer of Code: Improving RAIDframe parity handling 翻訳
Google Summer of Code: RAIDframe パリティハンドリングの改善
June 21, 2009 posted by Jed Davis
Summary
概要
A NetBSD system, in order to tolerate disk failures, can use the software RAID driver raid(4). Currently, if that system is shut down uncleanly (e.g., loses power or crashes), then when it comes back up it will have to check the entire RAID set's redundancy information. This process can take many hours, during which it imposes a substantial load on the system. It is also a distinct disadvantage to using NetBSD in server applications, and the inclusion of a journaling filesystem in NetBSD 5 makes it all the more prominent.
NetBSD システムは、ソフトウェア RAID ドライバ raid(4) を使うと、たまにディスク不良を見逃す。いまのところ、きれいにシャットダウンしなかった場合は( 例えば、電源断したとかクラッシュなど )、バックアップが使われ、そのバックアップ全体( 冗長性の部分も含めて )に対してチェックが走る。この処理はものすごく時間がかかり、その間システムにはものすごく負荷がかかる。これは NetBSD をサーバーとして使用するうえで不利にもなるし、NetBSD 5 で採用されたジャーナルファイルシステムを使った場合はもっと顕著になる。
The goal of my Summer of Code project is to shorten that check from hours to minutes.
私の Summer of Code project の目標は、数時間かかるこのチェック時間を数分に短縮することだ。
More Detail
さらに詳細
The problem is due to a fundamental limitation of RAID: if the system is abruptly halted in the middle of writing to several independent disks, there is no way to tell afterwards which of those write operations were actually performed short of reading the actual data involved. This is especially problematic for RAID-5 and similar, where a mismatch between data and parity will result in garbling part of that data when (not if) it has to be reconstructed after a disk failure.
この問題は RAID が持つ根本的な制限による: 独立した複数のディスクへの書き込み途中でシステムが突然死した場合、書き込み処理が実際には完了していた short of な読み込み中の実データが巻き添えを食らうので、それ以降利用する方法は無い( 訳: ??????????? )。これはとくに RAID-5 やそれと似た構成で問題になる。データとパリティの間に差異があると、ディスク不良が発生したあとに再構築されたデータについては間違いなくデータが化ける。
The solution taken in the RAIDframe codebase used by NetBSD is simple: while a RAID device is configured and in use, the entire thing is marked as needing a parity rewrite — even though only a small part, or perhaps none at all, has write operations in progress at any given time.
NetBSD では RAIDframe をもとにすると解決方法は簡単だ: RAID デバイスを設定してる間か使用している間は、RAID 全体をパリティ再書き込み要求させるようにマークをつけておけばいい。まあ全体に対してではなく一部に対してのみだけど、それでも書き込み処理はその特定の時間のうちは処理が進む。( 訳: ???????? )
Thus, my fix is to record a better approximation of what parts of the RAID are being written to at any given time. Except that now the RAID driver has to update that record as writes are done, rather than just once on boot and once at shutdown, and if this approximation is too fine-grained then that will noticeably reduce performance — all of the time, not just after unplanned reboots.
( 訳: 力尽きた )
Status
状態
At the time of this writing, I have a prototype implementation of just such a parity map; it's not fit for general consumption at this point, but the basics are working. Next up is more testing and performance evaluation, to refine the parity map algorithm. Eventually there will need to be an interface for the system administrator to configure this feature, and the code will need to correctly handle a RAID set being moved between kernels with and without parity map support, but these should be relatively straightforward and are scheduled for later in the summer.
これを書いているいまは、パリティマップ実装のプロトタイプが出来上がっている。ただ、いまの時点では一般的な使用( 訳: general consumption ???? )には適さないんだけど、基本的な部分は動いている。次に、パリティマップアルゴリズムを改善するために、もっとテストし、パフォーマンスを評価する。最終的に、管理者がこの機能を設定するためのインターフェースも必要になるだろうし、パリティマップサポート済みカーネルと未サポートのカーネル間で RAID セットを移動したとしてもハンドルを正確に収集できるようにしたいのだけど、比較的単純に実装しても、日程としては夏終盤になる。
Some additional minor improvements to the RAID system are also planned, time permitting, pertaining in particular to the handling of spare disks and reconstruction after a disk failure. In any case, by the end of the summer, a notable weakness of NetBSD will have been corrected.
あといくつか RAID システムの多少の改善も計画していて、時間があれば、とくに予備のディスクのハンドルに関連することと、ディスクが死んだあとの再構築について実装したい。ともあれ、夏の終わりには、欠陥がないように NetBSD が修正されるだろう。
_ AsiaBSDCon
hrs へメール投げてみた。
2010-07-06 :-)
_ 朝ッ
0520 起床
_ ねぶそく!!
okano さんからのメール読んでたら寝るのが遅くなった。
_ 愛飲
リポD
_ ,
カスれよグーグル
_ ,
あのひと病気なの?
_ メールトランスファーエージェント
「メイル」と書こうとしたけど「メイド」を「メード」と表記する新聞のように「メイル」を「メール」と書くことにした。もちろん（）
補足しとくんだが、qmail は以前使ってたし今は Postfix 使っていて sendmail については私んなかでは アンリミテッド・サガ のような扱いにしてある。つまり、内容はわかってるんだけど奇々怪々なもの。
_ NetBSD ドキュメント翻訳
マニュアルなんぞは man の英語を解読できないならば Linux JM や FreeBSD jpman を参考にすればいいし( man 8 ホゲホゲとかオプションとかはいくつか違うけどたいていこれで足りる ) むしろ本格的にマニュアルを翻訳できないならばやらないほうがマシではあるんだが、じゃあ何が翻訳されてると嬉しいかと云うとやはり The NetBSD Guide はどうにかしたい。
2010-07-07 :-)
_ 朝ッ
0520 起床
_ 七夕らしいので願いごとを考えてみた
家内安全 交通安全
_ 願い
願いごとを神などにお願いする場合はせっかくだから人間の努力ではどうにもならないような運頼みの事象をお願いするようにしている。たとえばこう:
- 空から女の子が降ってきますように
- 出会い頭に食パンを咥えた女の子と衝突しますように
これらは自分自身の努力でどうにかなるものではない。いやもちろん空から降ってきた女の子を受け止めるだけの体力と根性を事前に備えておくことは自分の努力でどうにかしなければならないし、社会で生活して曲がり角があるような路上へ移動するための交通手段を確保するのも自分の努力しだいなのだが、じゃあそれらを備えたからといってちゃんと空から女の子が降ってくるか、出会い頭に食パンを咥えた女の子が出現するかどうかは自分の努力ではどうにもならない。ひょっとしたら空からムスカが降ってくるかもしれないからだ。女の子が降ってくるか、それともサングラスをかけた中年男性が降ってくるかは神のみぞ知るセカイである。
しかし実際に上記のようなことを本気( マジ )で考えている奴は頭がどうかしてるのでこんなことを願っている奴は居ないだろうけど、では現実的な願いとして何があるかといえば
- 家内安全
- 交通安全
などがそうなのである。まとめて「厄除け」でもいいんだろう。交通安全は安全運転を心がけるなど自分の努力でどうにかなる部分はたくさんあるが、しかし酔払い運転をしたキチガイが突っ込んでくるなどという事象は自分の努力では避けられることではない。つまり神頼みすることは「不運に見舞われませんように」だ。もちろん空から女の子が降ってくることも願ってなくはない。
_ tech-userlevel: Re: static vs. dynamic runtime linking, again (was: PAM and su -K)
スタティックリンク vs. 実行時ダイナミックリンク 再戦
( via めもがき:2010年6月6日分 )
だいぶ前ですが
先日リンク貼った
我が天敵Ulrich Drepper氏の Static Linking Considered Harmfulを
www.NetBSD.ORG 翻訳 Projectの miwarinさんが 日本語訳していいただいたようで、すばらしー。
full dynamic rootへ舵を切ったNetBSDでも未だstatic linkに固執する人もいるけどね。
過去にさんざtech-userlevelでフレームになりましたな、 このへんのスレッド参照。
まぁstatic linked root に *BSDらしさを求める人は一部 OpenBSD に流れたりもしましたが
捨ててみるとなんだこんなもんかってーのがstatic linked rootとどどどど童(ry
ということでネタを投下されたので読んでみる。あいかわらず ???? なところが多い (´Д｀；)
Subject: Re: static vs. dynamic runtime linking, again (was: PAM and su -K) To: Jason Thorpe <thorpej@shagadelic.org> From: Greg A. Woods <woods@weird.com> List: tech-userlevel Date: 01/24/2005 16:53:13 [ On Sunday, January 23, 2005 at 10:11:11 (-0800), Jason Thorpe wrote: ] > Subject: Re: PAM and su -K > > As soon as you step up and offer (and follow through) to maintain all > aspects of statically linking the NetBSD universe, then maybe I could > take this argument seriously. But until then, all I'm hearing from you > (and all the other people who irrationally fear an all-dynamic > universe) is an unreasonable demand to increase software maintenance > and development costs in a way that impedes the progress that the > NetBSD Project needs to make in order to stay relevant in the OS world.
> 次の段階になればすぐにあんたは NetBSD すべてをスタティックリンクできるようにメンテナンスしてくれ、と言うだろう。そして私はそれは本気なんだと捉える。だけどこれまでに私があんたから聞いたことは( そして他のひとたちも NetBSD すべてをダイナミックリンクにすることにたいして「ばかげた恐怖」を持っている ) ソフトウェアのメンテナンスや開発コストが理不尽に増大し、NetBSD プロジェクトが OS 界にとどまるためには邪魔だ、ということだ。
There's no "irrational fear" of static linking from me.
スタティックリンクに「ばかげた恐怖」なんて無い。
It's outright dislike and disgust of the clear and dramatic technical consequences and measurable costs and overhead of dynamic linking.
ダイナミックリンクのオーバーヘッドと計測可能なコストと、技術的に劇的な影響を及ぼすことが明確なので、それに対する嫌悪と嫌悪感だ。( 訳: and が続いてどれがどれやら分からない )
Dynamic linking really has no gain whatsoever for a vast and varied class of true real-world production systems, and I'm not just talking about embedded systems but also most day-to-day application servers, internet servers, file servers, etc., etc., etc. In fact it is a very serious pain in the butt more often than not; not to mention being a _constant_ and unnecessary drain on everyone's resources, no matter how plentiful they might seem to be.
ダイナミックリンクは、ものすごくたくさんある実在の製品にたいしてほんとにまったく有益じゃない。私は組み込みシステムのことだけについて話してるのではなく、日常使っているアプリケーションサーバー、インターネットサーバー、ファイルサーバーとかいろいろについても話しているんだ。実際、 _constant_ について触れていないし、たとえたくさリソースがあったとしても全員のリソースを食い潰さないわけではないので、たいていの butt ( 訳: ???? )について深刻だ。
Of course just as loadable kernel modules have their place in making kernel code easier to test and debug, dynamic linking has its place in similar situations as well as in certain specific environments where some resource constraints outweigh others. However it is clearly not the panacea you seem to suggest it to be, nor is it a key feature for "relevance in the OS world". I've never heard anything on this topic so completely ridiculous in my life!
もちろん、ローダブルカーネルモジュールはより簡単にカーネルコードを書いたりデバッグできるようになるし、ダイナミックリンクは、計算機資源が豊富な特定の環境下ならば活躍する( 訳: ???? )。でも、それは銀の弾丸であることを意味しないことは明らかだし、それってほんとに OS ( 訳: "relevance in the OS world" ???? )に関連する重要な機能なの? 私の人生の中でいま話題にしていることほどバカげたことは聞いたことが無い!
Meanwhile contrary to your suggestion the so-called costs and "unreasonable demands" on maintaining an all-static build option are really rather tiny to the point of being non-existent. The only real maintenance cost I've _EVER_ encountered with building static-linked systems (on _any_ platform, including NetBSD) has been the need to bash a few odd (mostly non-*BSD) developers about the ears and get them to learn/remember how to do proper dependency checking and parameter ordering for all their libraries. I welcome you to try to point out any that you think I may have missed, but keep in mind that I'm speaking from a position of considerable experience on this matter, and I don't just mean my recent year or so of experience with building and using static-only NetBSD systems in production environments.
その一方、so を呼び出すときのコストについてのあなたの意見への反論と、すべてをスタティックビルドするオプションをメンテナンスするという ***無茶な要求*** は存否の点に関してはごく些細なことだ( 訳: ???? )。ほんとにメンテナンスコストがかかる部分は、スタティックリンクされたシステムをビルドすることだけど、それはどれくらいのコストが発生するのか把握できるし( NetBSD のあらゆるプラットフォームで )、この件について知っているごくわずかの bash 開発者( ほとんどが BSD じゃない )が必要としているだけだし、どうやってまともな独立性をチェックするのか教えるか思い出させるだけでいいし、スタティックリンクされたライブラリのパラメーターを並べ替えるだけでいい。私が間違ってると思われる部分についてあなたが指摘してくれることについては歓迎する。ただ、私がこの件についてあまり詳しくないことは覚えておいてほしいし、ここ数年のスタティックビルドのみの NetBSD の動向についてはあまり経験もないんだ。
On the other hand almost everything about dynamic linking has measurable and demonstrable costs in many ways, from runtime costs with every program startup to the costs of complexity that impact both developers and system managers (though in different ways for each). This remains true on all kinds of systems, not just *BSDs of course (with the current ld.so mechanism and even with the support of helper tools such as libtool, we're only a very tiny step away from the DLL hell of other systems). In fact for anyone who takes the time to look with an open mind there's a vast mountain of published evidence attesting to the problems and costs of dynamic linking and all the additional tools and complexity it requires.
その一方、ほとんどの手法のダイナミックリンクはコストを計測可能で、そしてコストがかなりかかるということが実証済みだ。すべてのプログラムのスタートアップに費やす実行時のコストは、開発者やシステム管理者( それ以外のひとも )への衝撃は計り知れない。このことはもちろん BSD 以外のすべてのシステムに当てはまる( current の ld.so の仕組みがそうだし、libtool のような補助用のヘルパーツールもそうだ。我々は他のシステムでいう DLL 地獄と隣り合わせなのだ )。実際ダイナミックリンクのコストと、そのほか諸々のツールと、あとそれらを利用する何かについてこの問題を証明するという途方も無い作業があるんだけど、それをおこなうひとたちは随分 心が広いものだ( 訳: ???? )。
Furthermore all the claims that have been made over the years, and which are still being bandied about, for the benefits of dynamic linking are few, of lesser value, with all modern open-source systems.
さらに、これらの要求は何年も前からあるし、いまだに軽く扱われてるし、ダイナミックリンクから得られるものはほとんど無いし、すべてのモダンなオープンソースシステムにとって価値が無い。
Support for static linked executables (and their creation) is a basic, fundamental, requirement for the underlying OS, one that can never really go away -- at least not without completely changing the underlying paradigm of how executable code is loaded by the kernel.
スタティックリンクを実行( とそれらを作る )をサポートすることは OS の基本だし、基礎だし、それが無くなることはホントーーーーーに絶対にありえない。すくなくとも、実行コードがカーネルからロードされるこれまでの方法をすっかり置き換えるということは無い。
Indeed a great number of subtle bugs in many applications can be quickly and easily discovered and often eliminated just by testing that static linking works properly. This is because, unfortunately, the current linker we use does not even warn about missing symbols or duplicate symbols -- it just leaves all those problems, and their consequences, up to the runtime linker, which on the other hand simply assumes naively that _someone_ must have know what they were doing and it blindly makes choices that can, often as not, result in runtime errors, data corruption, etc.
それどころか、たくさんのアプリケーションが持つ大量の奇怪なバグはを早く簡単に発見できるし、たまにテストによって除去できるから、スタティックリンクはうまく機能する。残念ながら、current のリンカは不明なシンボルや重複するシンボルへ警告を出すことはできない。でもこれらはすべて問題じゃなくて、これらがなぜ起きるかというと、それはたんに誰かが何かやったに違いないし、実行時エラーとか不正なデータとか、それ以外の何かのいずれかでしかなく、つまり実行時リンカが悪い。
So, as Greywolf so aptly put it, don't you be cutting my rope for me!
だから、灰色狼も言ったけど「ロープ切らないで！」( 訳: おとぎ話か何かのセリフ? )
Since I do already maintain my own custom static-linked system using the NetBSD source tree as a base (and provided that the underlying technology in NetBSD still to makes this possible, as I have no doubt it will continue to do so), I can make available the fruits of my efforts to the NetBSD project as a whole. I'm not sure how this might be made to work in practice of course, but suffice it to say that there won't be any question that the little bit of maintenance you so fear will in fact be being done by someone anyway. :-)
だから、私はすでに自分用に NetBSD ソースツリーをベースにしたスタティックリンクシステムをメンテナンスしてる( そして、*既存の NetBSD* でこれが出来たので、私は間違ったことをしていないわけだし、このまま作業を続ける )、この作業は NetBSD 全体へ貢献しているのである。この作業をやるべきではないのかもしれないけど( 訳: ???? )、いまはいかなる問いも些細なことだし、メンテナンスはたいした手間じゃないし、それどころか誰がどうやってもこの作業をできるだろう、とだけ言っておく :-)
BTW, if NetBSD (and the rest of the GCC-using free OS projects) really do hope to remain relevant in the OS world while at the same time continuing to try to tout dynamic runtime linkers as a benefit, then they absolutely must work much faster and much harder towards providing proper pre-binding support (ala Darwin et al) along with much better facilities to help increase the locality of reference in massive dynamic-linked address spaces. Without such enhancements none of the very real and ever-present and ever-recurring costs of dynamic linking can ever be mitigated.
ところで、もし NetBSD ( とそのほか GCC を使っているフリーの OS プロジェクト )が実行時ダイナミックリンカが有益であると判断し、それを売り込みつつ、依然の状態を維持し続けることを望むのならば、適切な事前バインディング( いまどきの Darwin みたいな )をサポートするためにもっと早く、もっとハードに作業しなければならない。ダイナミックリンクされたアドレス空間への局所参照の増加を助けるためのにもっと良い機構が必要になる( 訳: ???? )
As for PAM, well it's still a poor solution looking for a problem, and one derived from old requirements that no longer exist in any modern open source systems.
PAM なんぞはこの問題に対してはじつに貧弱な解決策しかないし、これはもはや現存しない古いシステムのために作られたものだ。
If NetBSD had really wanted to follow the published goals for building a better system that had decent "dynamic" (i.e. runtime) controls for selecting different kinds of authentication mechanisms then the better answer would clearly have been the BSD Auth stuff, not this OpenPAM junk.
NetBSD が謳っているようなシステムを構築することをほんとに望むならば、異なる認証機構を選択するために適切な「動的」( 例: 実行時 )を実装することだ。そしてもっと良い答えは BSD 認証機構よりをもっと分かりやすくすることだ。OpenPAM のようなクズじゃなくて。
Maybe there really is enough benefit to some tiny few number of NetBSD users who think they need PAM to have OpenPAM integrated into the official NetBSD source tree, but if doing so forces it down the throats of all NetBSD users then something just isn't right. Such a unilateral move would clearly fly directly in the face of the stated, and widely accepted, goals of NetBSD.
たぶん PAM や OpenPAM が必要なごくわずかの NetBSD ユーザーのために努力するようなことは NetBSD ソースツリーに組み込んでしまうことだ。でももしそれをおこなうとすると、全 NetBSD ユーザーに強制することになるので、それは正しい解法ではない。NetBSD のゴールを受け入れるためにはどちらか一方が clearly fly directly in the face of the stated することになるだろう。( 訳: ????? )
2010-07-08 :-)
_ 朝ッ
0520 起床
_ 「この記事はジョークである」
「この記事はジョークである」ということをわざわざ書かずに、でもこの記事はジョークである、ということを読者に察してもらうためにはどうすればいいのか。
たとえば Chikirinの日記 は冒頭にこう書いてある:
重要： 必ず最初にお読み下さい
このブログは“おちゃらけブログ”といいまして、笑い話が書いてあるブログですから、真に受けないように気をつけて下さい。
こう書いておかなければ「この記事はジョークである」ということを察してもらえないからだ。たぶん
でも bogusnews や 虚構新聞 はわざわざそのような注意書きを書くことはなく、それでも読者は「この記事はジョークである」ということを察する。
何が違うのだろう。
などということを 1億と2千年前から考えていたら鋭いことを言っているひとがいた。
<ixxxxxxx> http://kyoko-np.net/2010070601.html <himorinTs> 児童ポルノ監視員に６千人殺到 警察庁が求人 [AR] <Hxxxx> 虚構新聞いい仕事するねえ <ixxxxxxx> twitterみてるとこれほんとのニュースだと信じてる人がいて <ixxxxxxx> その人のことが心配になってしまう <Hxxxx> いや <Hxxxx> 虚構新聞はいい仕事してるよ。 <Hxxxx> 虚構新聞慣れしてる人じゃなかったら、さくっとかかるとおもう。 <ixxxxxxx> 無職男性（３１）の発言に違和感あるかなぁ <Hxxxx> そこまで読まないと思う <ixxxxxxx> そこまではまったく違和感なかったが <Hxxxx> 虚構新聞はどっか一箇所あからさまに「あぁウソだ」ってわかるポイントいれてるよねー <ixxxxxxx> うん <hxxxxxxx> 今までいろいろひどい目にあったからかな < あからさまに「あぁウソだ」ってわかるポイント <Hxxxx> ぱっと流し読みしてひっかかり、よく読んだら明らかにウソなとこがあって「あぁ、なんだ」と納得できる。って構造はgood <ixxxxxx> これは最初からだます気ないな http://kyoko-np.net/2010040801.html <himorinTs> アシモの「中の人」は語る 独占取材に成功 [AR] <Hxxxx> これはまんま落語ネタだな
_ [NetBSD][翻訳]NetBSD Blog - Interview with Thomas Klausner 翻訳
Thomas Klausner のインタビュー
July 06, 2010 posted by Guillaume Lasmayous
The last interview, Christos', is almost 08 months old. For the first interview of this year, Thomas Klauner, also know as wiz@, has accepted to answer NetBSDfr team's our questions.
最後にインタビューしたのは 8 ヶ月前の Christos だ。今年の最初のインタビューは Thomas Klauner ( 彼は wiz@ として知られている ) だ。NetBSDfr チームの問いに答えてくれた。
NetBSDfr: For those of our readers that don't know you, can you introduce yourself ?
あなたのことを知らない読者のために自己紹介をお願いします。
wiz: I'm Thomas Klausner. I've been a NetBSD developer for over ten years now, focusing mostly on pkgsrc and documentation. I've founded pkgsrc-wip, a project to get more people actively involved with packaging for pkgsrc, see pkgsrc-wip.sf.net. Everyone can get an account there and try out packaging for themselves. I've also found pkgsrc-security, the pkgsrc security team, responsible for keeping pkgsrc users informed about security problems with packages; and pkg-bug-handler, the team responsible for managing incoming problem reports.
Thomas Klausner です。NetBSD 開発者になってから 10 年以上たちました。おもに pkgsrc とドキュメントをやってます。pkgsrc のパッケージングについてより多くのひとたちに積極的に参加したもらうために、pkgsrc-wip というプロジェクトを作りました。詳細は pkgsrc-wip.sf.net を見てください。誰でもアカウントを取得でき、自分自身のパッケージングを試すことができます。pkgsrc security team がパッケージのセキュリティの問題を pkgsrc 利用者のために告知するために pkgsrc-security も作りました。そして報告された問題を管理するために pkg-bug-handler を作りました。
NetBSDfr: How did you discover NetBSD ? How long have you been using it ?
NetBSD を知ったきっかけはなんですか？ NetBSD を使い始めてからどれくらいたちますか？
wiz: Friends of mine pointed it out to me; I tried it out, and on the second try (when one of them helped me setting it up ;) ) stuck with it. That was around 1998/1999.
友人が教えてくれたんです。それで使い始めて、次のとき( 友人が助けてくれたんですが )にはすっかりハマッてました。それが 1998 年か 1999 年ころです。
NetBSDfr: How did you become a NetBSD developer ?
どうやって NetBSD 開発者になったのですか？
wiz:I started using pkgsrc and found some problems, or new versions of packages, about which I sent problem reports. After enough of those, Hubert Feyrer preferred me to commit them myself :)
pkgsrc を使い始めたらいくつか問題を見つけて、新しいパッケージもあったので( 訳: or ???? )問題を報告しました。そうしたら Hubert Feyrer がコミット権をくれました :)
( 訳: 「くれた」まで言ってる？ )
NetBSDfr:Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?
NetBSD プロジェクトに携わる時間をどれくらいにするか考えてますか？毎日？毎週？毎月？
wiz:It varies quite a bit. Sometimes it's half days at a time, sometimes I don't get to work actively on it for a few weeks. There were periods when I spent most of my waking hours on it; nowadays I'd guess about an hour a day, on average.
バラバラです。半日使うときもあるし、数週間なにもしないときもあります。起きている間は最近はだいたい平均 1 日 1 時間くらい使います。( 訳: そんなことを言ってるのか？ )
NetBSDfr:Can you explain us the role of pkgsrc-pmc, and your role in this organisation ?
pkgsrc-pmc の役割と、pkgsrc-pmc でのあなたの役割について教えてください。
wiz: I'm a member of the pkgsrc-pmc, the Project Management Committee for pkgsrc. It currently consists of Alistair Crooks, our fearless leader, Dieter Baron, Amitai Schlair and myself. The point of the PMC is to decide in technical issues, when consent cannot be achieved by the pkgsrc developers, and to handle the pkgsrc freeze.
pkgsrc-pmc は pkgsrc のプロジェクト管理委員( 訳: the Project Management Committee )で、私はそのメンバーです。現在の構成員は Alistair Crooks( *マッチョな* リーダーです )、Dieter Baron、Amitai Schlair、そして私です。ようするに PMC は、pkgsrc 開発者がアーカイブしたり pkgsrc を凍結する同意が得られないとき( 訳: ???? )に技術的な課題を決定することです。
NetBSDfr:Can you tell us what lead to the decision of creating the -wip repository ? Do you have any statistics about the number of package, overall quality.. ?
-wip リポジトリを作るときに何をもって作ると決めるのか、教えてくれませんか？ 多くのパッケージには戦略はありますか？ 細かい品質とか
wiz:There were two main ideas for creating pkgsrc-wip. One was that there was no place to collaborate on incomplete packages, e.g. packages where most of the work was done, but some final steps were missing, or build problems I couldn't fix where I hoped someone else could continue instead of starting from scratch. The other one was to get more people actively involved with pkgsrc. The barrier for becoming a NetBSD developer is quite high, usually, and if you just want to work on a few packages, you normally won't reach it. In pkgsrc-wip you can get access by just sending email to me with your sourceforge username and can get working on packages right away; also, your work will be immediately and easily available for other people.
pkgsrc-wip を作るときの基準はおもに 2 つあります。1 つは、未完成のパッケージを共同で作業するための場所が無い場合です。たとえばほとんどの作業は終わってるけど、いくつかミスがあったり、ビルドに問題があったりして、それが自分では解決できないときは、自分だけで最初からやるよりも誰かに助けを求めたりします。もう 1 つは、pkgsrc にもっとたくさんのひとに積極的に参加してもらいたいときです。NetBSD 開発者が寄り付かない障壁はたいていじつに高く、ごく少数のパッケージを作業したくても、普通は pkgsrc にたどり着きません。pkgsrc-wip では、sourceforge のユーザー名を私へ電子メールで送るだけで pkgsrc-wip にアクセスできるようになり、すぐにパッケージの作業をできるようになります。そしてその作業( 訳: your work )はすぐに、簡単に他のひとが使えるようになります。
NetBSDfr:What are the criterion that make a package move from -wip to pkgsrc ? Who makes the decision ?
-wip を pkgsrc へ移動するときの基準はなんですか？ 誰がそれを決定するんですか？
wiz:Mainly that it works, passes pkglint and a review by an experienced developer. Requests for reviews should be sent to the pkgsrc-wip-review mailing list. There's no formal procedure in place, so the import step happens when a developer becomes interested enough in the package.
おもな作業は、pkglint を通し、熟練開発者にレビューしてもらいます。レビューの依頼は pkgsrc-wip-review メーリングリストへ送られるでしょう。規定した手順はなく、開発者がパッケージに興味を持ったらその作業が始まります。
NetBSDfr:In your professional environment, do you work with NetBSD ?
仕事中は NetBSD を使って仕事してるんですか？
wiz:Sadly not. I use it as my main desktop at home though.
残念ながら違います。自宅のデスクトップで使ってます。
NetBSDfr:As a conclusion, can you tell us how you do foresee NetBSD's future ?
最後に、NetBSD は今後どうなっていくと思いますか？
wiz:I'm not very good with this kind of questions :) I see NetBSD as a very high quality operating system with great and motivated developers, and I think that this is very good base for the future :)
その問いの正解は持ち合わせてないよ :) NetBSD は偉大で情熱的な開発者たちにより高品質なオペレーティングシステムになってるんだから、NetBSD の未来は彼ら次第だろうね :)
補足
pre タグェ....
2010-07-09 :-)
_ 朝ッ
0520 起床
_ [翻訳][NetBSD][インタビュー]NetBSD Blog - BSDtalk interview with Andrew Doran 翻訳
BSDtalk による Andrew Doran へのインタビュー
March 11, 2009 posted by Sarah Cockburn
Will Backman (BSDtalk) interviews Andrew Doran about the upcoming 5.0 release and highlights some of the major features of the new release.
Will Backman ( BSDtalk のひと ) が来るべき 5.0 release と、新しい relase でのいくつかのおもな機能のハイライトを Andrew Doran へインタビューした。
You can listen to the interview here.
インタビュー内容は ここ ( mp3 )で聞ける。
補足
って丸投げかよ！
BSDtalk というサイトがあるんですね。
_ 車好き、マリオ好きのためのブログ 好きなゲームミュージックベスト５！（知らない人は邦楽でもOK！）
僕のブログを見てくれてる方々へ
皆さんはどんな感じですか？ぜひ教えて下さい！ゲームミュージックを知らないという人は邦楽でも構いません。たくさんのコメント待ってます！
いつものｒｙ
総合 はレディアントシルバーガンばかりなので 過去7日 のぶん。FROM DUSK TILL DAWN とか KING STREET/NITE GROOVES TUNES for RIDGE RACER 7 などばかりよく聞いたようだ。
_ mixiのマイミクシィの関係
mixiでやり取りしていて感じたことです。
mixiのマイミク数が増えてくると、さも自分が人気者であるような勘違いをする人がいるようです。
仮に僕で考えると、現在のマイミクが256人くらい。すると、この256人が自分のファンであるかのような勘違いが生まれるそうで。
今までそんな経験がなかったため、つい勘違いをするようなんです。
これって、とても不思議であり、時には自分の致命傷になるような気もします。
前にも書きましたが、どんな人でもどんどんマイミク申請すれば、ある一定の比率でマイミク数は増えてきます。
たまにマイミク数が万の台に達している人がいますが、それはマイミク申請回数も万以上ある、ということですね。
もし自分のマイミク申請数の10倍もマイミク申請されたのであれば、本当に人気者かも知れませんが、そういう人は稀。
そんなやり取りをしながら、自分も勘違いヤローにならないようにしないと、と感じた今日この頃です。
ref. mixiのフォローとフォロワーの関係：「走れ！プロジェクトマネージャー！」：ITmedia オルタナティブ・ブログ
2010-07-10 :-)
_ お散歩マイハウス
先日買ったレンズ Canon EFレンズ 50mm F1.8 II [ 20100707#p06 ]を持って散歩するなど。まあレンズが良いからといって写真の腕が上がるわけではないのでいつもどーりの写真である。
Flickr: Archive of your uploads to Flickr on 10th July 2010
_ [LPIC]LPIC-2 出題範囲とその参考 HOW TO 文書
ref. LPIC-2 出題範囲 - Linux技術者認定機関 LPI-Japan [エルピーアイジャパン]
網羅してないけどこれくらいは読んでおきたい HOWTO ( ※ただし JF に限る )のメモ。LPIC-1 はもう通り過ぎたので LPIC-2 から
201
- Linuxカーネル
- システムの起動
- ファイルシステムとデバイス
- 高度なストレージ管理
- ネットワーク構成
- システムの保守
- ドメインネームサーバー
202
- Webサービス
- ファイルとサービスの共有
- ネットワーククライアントの管理
- 電子メールサービス
- システムのセキュリティ
- トラブルシューティング
_ おまえら仲いいな
2010-07-12 :-)
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
_ ,
そおいえばまだ長谷川さん(仮名)に挨拶してない
_ 居室に閉じ込められた
入室退室時に ID カードを出入り口に設置されているカードリーダーにかざして、入室と退室が必ず対(つい)になるようにしておく必要があるんだが
- 退室しようとしてかざす
- ( 扉の鍵が開く )
- 忘れ物を取りに自席へ戻る
- ( 扉閉まる )
- もう開かない
鍵を持ってるが外に出られないという事態に陥った。他の誰かに開けてもらうしかない。
追記: と思ったらリセットする方法があるらしい。ってそれ 3 年前にも聞いたな
_ [Python][デザインパターン][Singleton]Python でデザインパターン - Singleton
Ruby で書いたアレ[ 20090507#p05 ]を 1 対 1 で書き換える。
こんなんでいいのか？
#!/usr/bin/python
# -*- coding:utf8 -*-
# ruby コードを書き換える
# http://www.area51.gr.jp/~rin/diary/?date=20090507#p05
#
class Singleton:
__instance = None
def get_instance(self):
if Singleton.__instance != None:
return Singleton.__instance
else:
Singleton.__instance = 0
return Singleton.__instance
print Singleton().get_instance()
ActiveState Code にこんなのがあった。ディクショナリを使ってる。
class Singleton(type):
def __init__(self, *args):
type.__init__(self, *args)
self._instances = {}
def __call__(self, *args):
if not args in self._instances:
self._instances[args] = type.__call__(self, *args)
return self._instances[args]
class Test:
__metaclass__ = Singleton
def __init__(self, *args):
pass
ta1, ta2 = Test(), Test()
assert ta1 is ta2
tb1, tb2 = Test(5), Test(5)
assert tb1 is tb2
assert tb1 is not tb2
_ [Python][デザインパターン][Command]Python でデザインパターン - Command
書き換え[ 20090507#p06 ]
#!/usr/bin/python
# -*- coding:utf8 -*-
# ruby コードを書き換える
# http://www.area51.gr.jp/~rin/diary/?date=20090507#p06
#
class Command:
def execute(self):
return
class Command1(Command):
def execute(self):
print "皇帝陛下ですね？"
class Command2(Command):
def execute(self):
print "そうだ。"
class Command3(Command):
def execute(self):
print "妹ロックブーケのカタキです。殺らせていただきます。"
class Noel:
def __init__(self):
self.slot = []
def add(self, command):
self.slot.append(command)
def run(self):
for c in self.slot:
c.execute()
def main():
noel = Noel()
noel.add(Command1())
noel.add(Command2())
noel.add(Command3())
noel.run()
main()
2010-07-13 :-(
_ 朝ッ
0520 起床
_ [NetBSD][翻訳]NetBSD Blog - Interview with Soren Jacobsen
Soren Jacobsen へのインタビュー
June 25, 2009 posted by Emile Heitor
A couple of weeks ago, Guillaume Lasmayous and I threw the idea of interviewing NetBSD developers through our website, NetBSDfr, to promote the NetBSD Project, and to make their work known to the widest possible audience. Today, we are discussing with Soren Jacobsen, snj@, NetBSD 5.0 release engineer.
2, 3 週間前 Guillaume Lasmayous と私は NetBSD の発展のために我々のウェブサイト NetBSDfr で NetBSD 開発者へインタビューしよう、というアイデアを思いつき、より多くのひとに彼らの仕事ぶりについて知ってもらうことにした。今回は NetBSD 5.0 リリースエンジニアの Soren Jacobsen( snj@ ) に話を聞いた。
NetBSDfr: First of all, let me thank you for this interview. We plan to run several interviews of NetBSD developers, I think, one every one or 2 months or so. You've been chosen as the first one. Thanks for accepting to answer our questions.
snj: Thanks for asking me, and thanks for your efforts to strengthen the community. It's great to see efforts like this. Sorry it took so long to get back to you. I wanted to take some time to think over my answers. Please let me know if you think anything needs clarification.
NetBSDfr: まず最初にインタビューに応じてくれたことに感謝します。我々は何人かの NetBSD 開発者へのインタビューを計画しており、2 ヶ月かそのくらいでインタビューする予定です。最初に選ばれたのがあなたです。質問に答えてくれてありがとう。
snj: インタビューありがとう。そしてあなたがたのコミュニティへの尽力に感謝します。これはすごいことです。でもあまりあなたがたへお返しできないかもしれない。ちゃんと答えるためにはもう少し時間がほしい。説明が必要なら言って欲しい。
NetBSDfr: For the readers who don't know you, can you shortly introduce yourself ?
snj: My name is Soren Jacobsen and I am a NetBSD developer and release engineer. I've been part of releng since late 2005, and was the lead release engineer for the 5.0 release.
NetBSDfr: 読者のみなさんへ自己紹介をお願いします。
snj: Soren Jacobsen です。NetBSD 開発者でありリリースエンジニアをやっています。2005 年からリリー作業に携わり、5.0 release のリリース作業を担当しています。
NetBSDfr: Why did you choose to run NetBSD ? How long have you been using it ?
snj: My first experience with NetBSD was 1.5.3, which I guess was around the second half of 2002. Compared to a lot of people, I was a bit late to the party. At the time, I was frustrated with Linux in a number of ways, and NetBSD was a solid operating system with a philosophy that made sense to me. There wasn't any one particular thing about NetBSD that grabbed my attention. It was more that there was nothing that bothered me. It just seemed right.
NetBSDfr: どうして NetBSD の作業をしようと思ったのですか？ また、NetBSD を使い始めてどれくらいですか？
snj: 最初に NetBSD に触れたのは 1.5.3 のときでした。2002 年の半ば過ぎくらいだったと思います。すでにたくさんのひとが携わっていました( 訳: I was a bit late to the party は「このビッグウェーブに乗り遅れた」といった意味か? )。そのとき私は Linux にたくさんの不満を持っており、NetBSD の哲学にもとづいた堅牢なオペレーティングシステムに ぐっときたんです。NetBSD への関心を妨げるものはとくに何もありませんでした。何か困惑することもありませんでした。これはじつに正しいことに思えたんです。
NetBSDfr: Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?
snj: Like most volunteers, the amount I'm able to spend on NetBSD depends on real life and my motivation level. A year ago, at most I was doing 8 hours a week. More recently, 8 hours a day wasn't uncommon. The week leading up to the release was especially hectic; I put in a couple 16 hour days there.
NetBSDfr: NetBSD へどれくらい時間をかけるか何か考えてる？毎日とか毎週とか毎月とか
snj: まさにボランティアみたいなものですから、NetBSD にどれくらい時間をかけるかは、実生活とモチベーションに依存します。去年はだいたい 1 週間に 8 時間費やしました。最近は 1 日 8 時間も使うことはあまり無いです。リリース担当の週は多忙で、16 時間以上費やします。
NetBSDfr: How did you become a NetBSD developer ?
snj: When I started using NetBSD full time as my primary operating system, I became heavily dependent on pkgsrc, our framework for third-party packages. There were a number of packages I wanted to see updated, and I started sending patches against pkgsrc and various small things in the base system. At the end of 2003, I was offered an account, and became a developer in January of 2004.
NetBSDfr: どうやって NetBSD 開発者になったの？
snj: 私の最重要オペレーティングシステムとして NetBSD をフルタイムで使うようになって、サードパーティパッケージ向けの我々のフレームワークが pkgsrc にかなり依存するようになりました。いくつかのパッケージをアップデートしたくて、pkgsrc の基本システムへのいくつかの変更点のパッチを pkgsrc へ投げ始めました。2003 年末にアカウントを貰い、2004 年 1 月に開発者になりました。
To anyone out there who is interested in helping the project: pkgsrc is a great way to get involved. There are so many packages out there, and only a finite number of developers to import and maintain them. Consider submitting PRs against pkgsrc and joining the pkgsrc-wip project. We can use all the help we can get in this area.
NetBSD プロジェクトの手助けに関心のあるすべての皆さんへ: pkgsrc は NetBSD プロジェクトに深く関わるには非常によい手段です。ものすごい数のパッケージが提出され、ごくわずかの開発者がインポートし、メンテナンスします。pkgsrc へ PR を提出することを検討し、pkgsrc-wip プロジェクトに参加してください。我々が手助けします。
NetBSDfr: How did you become member of NetBSD release engineering team ? Are the members of the releng team elected ? chosen among developers ? Does this require specific skills ?
NetBSDfr: どうやって NetBSD リリースエンジニアリングチームのメンバーになったのですか？ リリースエンジニアリングチームによる投票？ それとも開発者から選ばれる？ 何かスキルが要る？
snj: The release engineering team is rather informal. There is no election process, and no strictly defined leader of the group, although people do step up to fill this position. When we feel understaffed, we put out a call for volunteers, and usually a person or two will join.
snj: リリースエンジニアリングチームはくだけてます。投票するということは無いし、ちゃんとしたリーダーというのも居ませんし、みんなこの位置に居座ります。人手不足だと思ったら人員を募集し、いつも 1, 2 人参加してくれます。
Release engineering is not as glorious as a lot of other activities, so we don't normally have people begging to join releng. It's hard to say about specific skills. Like in most other areas, having sound judgment and a good sense of perspective is essential. These are the only strictly required skills. Plenty of others are useful, though: patience, caution, attention to detail, etc. Pretty basic stuff, for the most part. Of course, the more technical knowledge, the better, but this is not as big of a deal as it might seem. I'll explain below.
リリースエンジニアリングは他の活動ほど名誉ある作業ではないので、他のひとたちに参加を勧めることはありません。ある技術については他のプロジェクトよりも難しいところがあって、判断力があり、先見の明があることが必須です。これらが求められる技術です。他にも技術があるほうがいいんですが、まあ、辛抱強さ、用心深さ、細部への注意深さ、とかいろいろあるといいです。基本的にスタッフはこれらが得意です。もちろんもっと技術的な知識があるほうがいいですが、あまり重要ではありません。そこだけははっきりさせておきます。( 訳: ???? )
NetBSDfr: Can you explain us more in details how does NetBSD release engineering process work ?
snj: There are two basic tasks:
- Pulling up changes into branches.
- Releasing.
NetBSDfr: NetBSD リリースエンジニアリングの作業についてもう少し詳しく教えてください。
snj: 基本的な作業はこう:
- current での変更をブランチに反映
- リリース
The first one is rather straightforward, and it is something we do constantly. Developers request that certain changes be pulled up to a given branch. If we agree that the changes should be pulled up, we commit them to the branch. To help track the status of a branch, we maintain a record of every change made to a branch over its lifetime.
最初のは単純明快だし、いくつか定期的におこなっています。開発者は変更点をブランチへ反映することを要求します。変更点を反映すると決定したら、ブランチへコミットします。ブランチの状態を追跡しやすくするために、ブランチの生存期間中はその記録をメンテナンスします。
Putting together a release is a much more complicated task requiring coordination with a large number of people. The main task is to decide the point at which the remaining bugs can safely be ignored. There are lots of other tasks involved here, of course: managing the build cluster, pulling up changes, preparing information about the release, testing, making sure that important fixes find their way to the branch, begging people to work on certain things, paying very close attention to the mailing lists, etc.
release の場合はたくさんのひとと調整することが要求されるのでもっと複雑です。おもな作業は、残っているバグを除去して安全にすることです。もちろんたくさんの複雑な作業があります: ビルドクラスターを制御したり、変更点を反映したり、リリース告知を準備したり、テストしたり、ブランチに重要な fix がされているか確認したり、あることについては誰かに作業してもらったり、メーリングリストへ細心の注意を払ったり、いろいろ。
NetBSDfr: How does the quality assurance process works ? Who decides to include this or that patch to a branch ? This is also linked I think to the following question: how does the releng team decide how many betas, RCs versions are required before declaring a branch is stable ?
snj: No one person can have thorough technical knowledge in all areas of the source tree. Therefore, it's sometimes hard for a person (or small group) to be able to say for sure whether a particular change should be pulled up to the release branch. This is where one of the most important qualities of a release engineer comes into place: the ability to get sound advice from the right people. To some extent, we trust that developers submitting changes for pullup have carefully considered the implications of the change. But at the same time, we try to be very cautious, and being able to effectively consult with other developers is of vital importance.
NetBSDfr: 品質保証についてはどうやってますか？ ブランチにパッチを取り込むことを誰が決めるのですか？ これは次の質問にも関連しますが、ベータ版をいくつ作るのかどうやって決めるのですか？ ブランチが安定したと判断するまでにベータやRCがいくつ必要かを、どうやって決めるのですか?
snj: ソースツリー全体について技術的な知識を持っているひとは誰も居ません。したがって、担当者( または少人数のグループ )がリリースブランチの主な変更点を反映し、それが問題ないということを告知する作業は、ときに困難になります。正式な担当者から信頼できる助言を貰うことは、リリースエンジニアがうまくやってのけるためには最重要の品質のうちのひとつです。じつをいうと、開発者は変更された部分をちゃんと反映してくれてると信じている。しかし、それと同時に、よく注意し、他の開発者にも効果的に相談することがきわめて重要です。
We start the release process when we think the tree is in pretty good shape. At this point, the branch is known as, e.g., 5.0_BETA. At this point, more users start running the code, and we are constantly watching for feedback (positive and negative). Intrusive changes are avoided during all stages of the release process, but they are most acceptable at this point. The general rule is that the further along in the release process we are, the more restrictive we are about changes. Unfortunately, it is impossible to have many hard rules about this. If big nasty bug comes up, you're faced with a choice between ignoring the problem or taking a risk on an intrusive change. Sometimes we take the risk, sometimes we don't. This is another case where no one particular person can have all the answers. To avoid one person making a bad judgment call, members of releng discuss these issues with each other and with other developers.
我々はソースツリーがじゅうぶん良い段階になったらリリース作業を始めます。このときのブランチは、たとえば 5.0_BETA などです。そして、よりたくさんのユーザーがコードを使い始め、我々は定期的にフィードバック( 良い点も悪い点も )を監視します。リリース作業の全体では変更点は受け入られづらいのですが、リリース作業開始初期は変更点を受け入れやすいです。。一般的な規則は、リリース作業について規定していて、変更点についてもっと制限をしています。残念ながら、たくさんの厳密に規則を実施することは難しいです。もし、ものすごく鬱陶しいバグが報告されたとしましょう。あなたはそれを無視するか、もしくはなんとしてでも変更し、そのリスクをとるか、どちらかを選ぶことができます。我々はリスクをとることもあるし、何もしないときもあります。これは、とくに誰もその答えを持っていないときの選択肢です。誰かが悪い意見を言った場合、それを回避するためにリリースチームのメンバーが他の開発者たちと議論します。
A release candidate, by definition, occurs when it is felt that the tree is good enough to release. In practice, this rarely happens. There is almost always a good reason to do at least one more release candidate. In some respects, they're more psychological than anything else. I admit I rushed a couple release candidates out with full knowledge that 5.0 could not be released without further fixes. But when important last-minute changes are made, putting out a release candidate is a great way to get those changes tested. Take 5.0_RC3, for example. At the time, we were aware of a few show-stopping bugs, but there were significant WAPBL changes that needed wider testing, so we felt that RC3 was justified.
release candidate は定義によると、relase するのに妥当だと判断されたソースツリーのことです。習慣ではたまに発生します。たいていいつも 2 回は release candidate を作ります。いくつかの点では、他の何よりずっと心理的です( 訳: ???? )。5.0 がいくつか fix されてないことを承知のうえで release candidate を出したことがあります。重要な点については土壇場で変更し、release candidate を出し、とてもすぐれたテストを得ることができました。たとえば 5.0_RC3 。このときはいくつかの致命的なバグを抱えていましたが、WAPBL の重要な変更があったので幅広いテストが必要でした。だから、RC3 は正しかったと思っています。
In the end, deciding when to declare a release stable comes down to compromise. You have a hard list of requirements that the release must meet. Beyond that, you just have to get to a point where you feel that the remaining bugs are outweighed by all the positives in the new release. This is a hard thing to do, because when you've been tracking every problem raised for months, you tend to be focused on negatives and can easily forget about all the people who are having wonderful experiences. Eventually you have to let go and realize that you'll never have a bug-free release. When you get to that point, you tag the final release and hope that you haven't made a horrible mistake :)
最後に、stable をリリースするのに妥当な線を決定します。リリース必須項目を拝むことが出来ます。それから、新リリースにあるバグのうちいくつかの重要なバグを抱えたリリースを取得するだけです。毎月 何かしらの問題が発生していることがわかるので、これはしんどい作業です。悪い面に目がいくようになり、すべてのひとびとが *不思議な体験* をすることを簡単に忘れます。そして、バグなしのリリースが出来ることは無い、ということを悟るでしょう。そして、最後のリリースにタグをつけ、恐ろしいミスが無いことを祈りましょう :-)
NetBSDfr: As a conclusion, can you tell us how you imagine the future of NetBSD?
snj: We've made a massive jump with 5.0, and 6.0 should continue this trend. NetBSD has been ignored by many people for years, but this is changing. As for more specific predictions, I think we're going to see NetBSD usage increase greatly in the server and embedded worlds. I don't envision any radical shifts in direction, but this is not a problem. NetBSD has always been a great operating system; we just need to get out there and introduce more people to it.
NetBSDfr: 最後に、今後 NetBSD はどうなると思いますか？
snj: NetBSD 5.0 へ向けて大きく飛躍し、6.0 はその流れを汲んだものになるでしょう。NetBSD は何年も間 たくさんのひとびとから無視されてきましたが、これが変わります。もっと予言をすると、NetBSD はサーバーや組み込み機器でもっとたくさん使われるようになるでしょう。急激にそのようになっていくとは思っていないけど、それは問題ではありません。NetBSD はいつだって偉大なオペレーティングシステムです。もっとたくさんのひとびとに使ってもらうことだけが望みです。
Many thanks to Guillaume for his hard work on preparing, conducting and translating this interview and rendez-vous in a few weeks for the next one. I;n the meantime, any names of developers to interview, or questions you'd like to ask, are more than welcome.
Guillaume には作業の合間をぬってくれたことに感謝する。このインタビューは翻訳されて、数週間後に rendez-vous に置かれる。その間にインタビューしてもらいたい開発者の名前や、質問を送ってほしい。
_ Pulling up〜 [current での変更をブランチに反映 (NetBSD 用語で pull up)]
_ how many betas, RCs〜 [ブランチが安定したと判断するまでにベータやRCがいくつ必要かを、どうやって決めるのですか?……安定したからとリリース..]
_ みわ [おお。ありがとうございます。最後のツッコミはspam扱いされてしまっていました。すいません...]
_ テキトーなのでそのまま使われると恥ずかしい [( 訳: they are はどれを刺してる? )they = Intrusive changes リリースプロセス..]
_ みわ [いえいえ。私が書いたほうもほとんど直訳だし誤訳だし。まあでも自分の言葉で置き換えて書くことにします。]
2010-07-14 :-)
_ 朝ッ
0520 起床
_ rails こぴぺ
レイルズ！レイルズ！レイルズ！レイルズぅぅうううわぁああああああああああああああああああああああん！！！ あぁああああ…ああ…あっあっー！あぁああああああ！！！レイルズレイルズレイルズぅううぁわぁああああ！！！ あぁクンカクンカ！クンカクンカ！スーハースーハー！スーハースーハー！いい匂いだなぁ…くんくん んはぁっ！ルビー・オン・レイルズたんの赤色(レッド)まいんの設定をクンカクンカしたいお！クンカクンカ！あぁあ！！
いつ見ても元ネタの壊れ具合はすごいな もみあげチャ～シュ～ : ルイズの派生コピペ集めようぜｗｗｗｗｗ - ライブドアブログ
_ すごい物を見てもへこたれない人
身近な例でいえば、リッジレーサー7 で knhtymh さんの走りを見て「こんなひとには絶対に勝てないからリッジ7 やめた」と考えるか「どうすれば knhtymh さんのように走れるか」と考えるか。という話題である。
knhtymh さんの走りを見て三輪は「こんなひとには絶対に勝てない.... ただし現在は 」と考えているので( TA ではまず勝てないがオンラインバトルで 10 回レースやって 1 回は勝てるかもしれない ) じゃあどうしたら knhtymh さんのように走れるか、を日々考えている。といっても答えは明らかで、走りこみが足りない。knhtymh さんは TA の動画をあげてるので見れば分かるんだが、FP が 3 万ある。それに比べて三輪の FP は 2 万くらい。FP の値を見れば knhtymh さんと三輪の差が明らかである。つまりあと 1 万回くらい走りこめば knhtymh さんに追いつくはず。( そのころには knhtymh さんはもっと遠くへ行ってるだろうけど )
他のことについても「10000万時間費やせばどうにかなる」などという話題があるように( あなたも「天才」になれる？ 10000 時間積み上げの法則 )ともあれそのくらいの情熱をもって取り組めば心配ないよだいじょうぶだよ
2010-07-15 :-)
_ 朝ッ
0520 起床
_ ,
だんすたいっ
_ ,,
ミラクル I just say "エトワール" ♪
_ 呼吸をするように
飯を作って菓子を作ってプログラム書いて歌をうたってゲームして楽器演奏して絵を描いてインターネッツこわい
努力してやるんじゃなくてがんばってやるんじゃなくて気合を入れてやるんじゃなくて呼吸をするようにでゆ。
_ [Adam Hamsik][NetBSD][翻訳]NetBSD Blog - Interview with Adam Hamsik 翻訳
Adam Hamsik へのインタビュー
July 15, 2009 posted by Emile Heitor
After our first interview with NetBSD-5.0 release engineer Soren Jacobsen, it is now Adam Hamsik's turn to be interviewed by NetBSDfr.
NetBSDfr による最初のインタビューは NetBSD-5.0 リリースエンジニア Soren Jacobsen だった。次は Adam Hamsik へのインタビューだ。
Adam is known for his work on porting LVM tools to NetBSD, and for porting ZFS as part of this year's Google Summer of Code.
Adam は LVM tools の NetBSD への移植作業をしていることで知られており、今年の Google Summer of Code として ZFS 移植作業もおこなっている。
NetBSDfr: First of all, thanks for taking the time to answer.
haad: No problem! I think that your effort is great.
NetBSDfr: まず最初にトークの時間を割いてくれたことに感謝します。
haad: いえいえ。あなたがたの活動には敬服しています。
NetBSDfr: For the readers who don't know you, can you shortly introduce yourself ?
haad: My name is Adam Hamsik, I'm 24 years old. I have finished Computer science in Slovak Technical University last month. I'm NetBSD developer since around 2 years. My first bigger project was NetBSD LVM implementation on which I have worked during previous Google Summer of Code.
NetBSDfr: 読者のみなさんへ自己紹介をお願いします。
haad: Adam Hamsik といいます。24歳です。先月 Slovak Technical University のコンピューターサイエンスを卒業しました。NetBSD 開発者になってから 2 年たちました。最初の大仕事は Google Summer of Code へ向けて NetBSD LVM を実装することでした。
NetBSDfr: Why did you choose to run NetBSD ? How long have you been using it ?
haad: I've been using NetBSD for around 4 years. I started with NetBSD 2.0. I tried several linuxes and FreeBSD but any of them truly fit my needs. During one dinner with my old friend he suggested to me that I should try to use NetBSD, because it is pretty good operating system. I tried to use it and found that it is best os for what I need. It is cleanly designed and it is almost Unix.
NetBSDfr: どうして NetBSD を選んだのですか？ NetBSD を使い始めてからどれくらいたちますか？
haad: NetBSD を 4 年前から使っています。NetBSD 2.0 のころです。いくつかの Linux と FreeBSD を使ってみたんですが、私の要望に完全には一致しませんでした。旧友と食事しているときに、彼から NetBSD は素晴らしいオペレーティングシステムだから使ってみてはどうかと勧められました。使ってみたら、これは私の要望にあう最良の OS だと分かったんです。綺麗な設計だし、ほぼ Unix なんです。
NetBSDfr: Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?
haad: These days during GSOC 2009, I'm working on ZFS port project for 4-8 hours per day, sometimes even more. As any other volunteer developer I'm often interrupted with real world thinks, but I'm trying to do as much as I can during this Summer.
NetBSDfr: NetBSD へどれくらい時間をかけるか何か考えてますか？毎日とか毎週とか毎月とか
haad: 最近の GSOC 2009 作業期間中は、毎日 4 から 8 時間( たまにそれ以上 )を ZFS の移植作業のために使っています。他のボランティア開発者たちと同じように、リアル世界ではときどき割り込みがかかりますが、この夏はできる限り作業に費やします。
NetBSDfr: Your work for the project is mainly in maintaining your former GSoC work, or are you involved on other parts of the code ?
haad: I did several smaller patches to base system, proplib, but main part of my work is my former and current GSOC work. Last year I did LVM port for NetBSD and get linux LVM tools working with our device-mapper driver. For those readers who do not know what is LVM, LVM is Logical Volume Manager which allows to manage disk space in a pretty simple way. This year Summer of Code I'm working on NetBSD ZFS port and I have to say that with great help of Andrew Doran we already did pretty good job. Yesterday - Note: the 20th of June, 2009 - I was able to mount (only mount call is supported;) ZFS dataset, create/manage zpools and zvols.
NetBSDfr: あなたの主な作業は前述の GSoC 作業ですが、他にも何かのコードに関わっていますか？
haad: proplib などベースシステムにいくつか小さいパッチを書きましたが、私の主な作業は前述のと、現在の GSOC 作業です。去年 私は NetBSD へ LVM を移植し、NetBSD の device-mapper ドライバーで Linux の LVM tools が動作するようにしました。LVM のことを知らない読者のために説明すると、LVM は Logical Volume Manager といって、これによってじつに簡単な手順でディスク領域を管理できます。今年の Summer of Code では NetBSD へ ZFS 移植を作業しましたが、Andrew Doran による助けがあったおかげで良い仕事ができたということを強調しておきます。昨日( 原注: 2009 年 6 月 20 日 ) ZFS データセットをマウントできるようになり( mount だけですけど )、zpools と zvols を作成、管理することができました。
NetBSDfr: How did you become a NetBSD developer ? following GSoC I assume ?
haad: I became a developer after some time where I tried to find some project for me. I was asked by Bill Stouder-Studenmund if I want to become a developer. Later I started my work on LVM port which later became my GSOC project for 2008.
NetBSDfr: どうやって NetBSD 開発者になったのですか？ GSoC のおかげ？
haad: いくつかのプロジェクトを経てから開発者になりました。開発者になりたいか？と Bill Stouder-Studenmund から聞かれたんです。それから GSOC 2008 プロジェクトとして LVM 移植作業を始めました。
You started LVM port before GSoC 2008 ?
haad: I had some big part of device-mapper driver written before GSOC started.
NetBSDfr: GSoC 2008 以前から LVM 移植作業してたんですか？
haad: GSOC が始まる前には device-mapper ドライバの大部分は書き終えてました。
NetBSDfr: How long did it take to port LVM to NetBSD, overall ?
haad: It is still not finished but around 1.5 year.
NetBSDfr: NetBSD への LVM 移植作業に全体でどれくらいかかりましたか？
haad: まだ終わってませんよ。けど、1 年半くらいかけてます。
NetBSDfr: I'm wondering how you learn about NetBSD internals ? On your own ? At school ?
haad: I have to say that I'm still NetBSD internals newbie :) I know parts of kernel on which I was working e.g. device-drivers, device-mapper. During my work I met several great developers with enough patience to guide me through kernel internals and help me with my problems. I learnt the rest on my own :). I have to say that there are still places in kernel about which I do not know anything e.g. low level stuff, real device-drivers, acpi, uvm etc.. but I already learnt pretty much about locking, vfs and filesystems.
NetBSDfr: あなたがどうやって NetBSD 内部について学んだのか興味があります。独学ですか？ 学校ですか？
haad: NetBSD 内部についてはまだ初心者だと言っておきます :) たとえば device-drivers や device-mapper など自分が作業する箇所に関しては kernel について知っています。私が作業している間に何人かの偉大な開発者たちが kernel 内部について辛抱強く教えてくれたし、私の問題を助けてくれもしました。独学もしましたけどね :) low level stuff, real device-drivers, acpi, uvm などについてはまだまだ知らないことがあることはたしかですが、locking, vfs, filesystems についてはだいたい学びました。
NetBSDfr: Can you give more details about the Google Summer of Code ? How are students nominated ? What are the success criteria, if any ? Do all students get committer access ?
haad: GSOC is program managed by Google where Google pays students to work on Open Source projects like NetBSD. Anyone who is a student can write application and submit it during application submit timeline. Applications are later reviewed by NetBSD mentors (people who guide students through whole GSoC on project side) and defined number of project applications are chosen by some criteria. Not every student get commit access but many of our successful students over past few year got them. GSoC is better described at http://code.google.com/soc/
NetBSDfr: Google Summer of Code について詳しく教えてくれますか？ 学生はどうやってノミネートされるんですか？ 成功の秘訣はありますか？ 全学生がコミット権を貰えるようになるのでしょうか?( 訳: cvs.netbsd.org へのコミット権 )
haad: GSOC は Google によるプログラムで、NetBSD のようなオープンソースプロジェクトの作業について Google から報酬がもらえます。学生は誰でも参加申請できるし、期間内なら枠の数だけ申請が承諾されます。申請は後ほど NetBSD メンター( 学生を指導してくれる GSoC 関係者 )によりレビューされ、プロジェクト申請ごとに番号がふられ、いくつかの基準により選ばれます。すべての学生がコミット権をもらえるわけではありませんが、成功した学生たちの大半はプロジェクトに何年もかけてます。GSoC のもっと良い概要は http://code.google.com/soc/ にあります。
NetBSDfr: What are the evaluation criterion ? Usability? Portability of the code ?
haad: Every student should define their GSoC application must have, nice to have things. Students are evaluated by their mentors. You need to show your mentor that you are working on your project and get at least something done. If you find during Summer that your deliverables are to huge, you can scale them down, but you must work on it :) There are no exact criteria for project evaluation.
NetBSDfr: 何を基準に評価するんでしょうか？ 有用性？ コードの可搬性？
haad: すべての学生は自身の GSoC アプリケーションがよくなるように定義しなければなりません( 訳: define は設計という意味？じゃないよな )。学生は彼らのメンターによって評価されます。自身のプロジェクトにおいてメンターに見てもらい、少なくともプロジェクトを完了させなければなりません。夏の間に終わらせるにはプロジェクトが大きすぎる場合、規模を縮小することができますが、必ず変更後のプロジェクトで作業してください :) まあプロジェクトを評価するための正確な基準は無いですよ。
NetBSDfr: How are you working with ad@, your mentor on the ZFS port project? Is he reviewing your code regurlarly ? Are you requesting the reviews ?
haad: We have meetings once a week on Skype/VOIP where we discuss any big issues. During the week I can regularly talk with him on irc. When I do some bigger change, I ask Andrew for a review.
NetBSDfr: ZFS 移植プロジェクトのメンターである ad@ と一緒に作業してどうですか？ 定期的にコードレビューするのでしょうか？ あなたがレビューを依頼するのでしょうか？
haad: 週 1 回 Skype/VOIP で打ち合わせして、大きな課題について議論します。週の間は定期的に IRC で話します。何か大きく変更した場合は、Andrew にレビューできるか尋ねます。
NetBSDfr: I was about to ask for a status on ZFS. You gave part of the answer earlier in this interview. Do you think you'll reach the goals you've set for ZFS in NetBSD by the end of this year's GSoC ?
haad: I have to say that I'm not sure :) still. ZFS is huge it will take much more than GSoC to get it working but I think that we can get basic part of ZFS working at the end of GSoC. I will do my best to reach our goals :)
NetBSDfr: ZFS の現状について訊きたいんですが。いくつかインタビュー冒頭でも答えてくれましたが、今年の GSoC が終わるまでに NetBSD への ZFS 移植作業を完了させるのでしょうか？
haad: 正直に言ってまだよく分かりません :) GSoC で完了させるには ZFS は大きすぎるんですが、GSoC が終わるまでには ZFS のうち基本的な部分については終わらせるつもりです。完了させるように最善を尽くしますよ :)
NetBSDfr: As a conclusion, can you tell us how you imagine the future of NetBSD?
haad: I think that we did huge step with NetBSD 5.0. Andrew Doran did awesome job on 5.0. Many parts of NetBSD kernel are multi-thread safe these days. On multicore/SMP machines we have very good performance in many types of system workload. There is also another part of NetBSD and it it is portabiliy to embedded devices, there are so many small devices which are running NetBSD and nobody knows it. We need to work hard to get Flash filesystem and many other embedded device stuff done to attract new developers to work and port NetBSD to new machines.
NetBSDfr: 最後に、NetBSD は今後どのようになっていくと思いますか？
haad: NetBSD 5.0 はとても大きく飛躍したと思います。Andrew Doran は 5.0 でとても素晴らしい仕事をしてくれました。NetBSD kernel の大部分は、いまどきのマルチスレッドになっています。multicore/SMP のマシン上では、さまざまな処理についてとても良いパフォーマンスを発揮してくれます。NetBSD の他の部分についても同様で、組み込み機器への可搬性がありますし、とてもたくさんの小型機器で NetBSD が走ることは周知のとおりです。フラッシュファイルシステム上で動作させるために尽力する必要があるし、他のたくさんの組み込み機器で NetBSD を走らせることは新しい開発者を惹きつけますし、NetBSD を新しいマシンへ移植させることにもなります。
NetBSDfr: Well, I think I've run out of questions. Thanks a million for your time Adam
haad: np :)
NetBSDfr: ふむ。じゃあこれで質問を終えようと思います。ありがとう、Adam
haad: いえいえ :)
Many thanks to Guillaume Lasmayous from NetBSDfr for his hard work in preparing, conducting and translating this interview. Rendez-vous in a few weeks for the next interview. Please feel free to suggest developers you would like interviewed and/or questions.
Guillaume には作業の合間をぬってくれたことに感謝する。このインタビューは翻訳されて、数週間後に rendez-vous に置かれる。その間にインタビューしてもらいたい開発者の名前や、質問を送ってほしい。
_ Anyone who is a student can write application～ [ここのapplicationは参加申請のことです。期間内なら誰でも応募できて、決められた枠の数のプロジェクト申請が採..]
_ みわ [ぉぉぅ。Applicationはそのまま訳せばよかったですか。「committer access」は申請が採択された..]
_ committer access [cvs.NetBSD.org の commit 権限のことだと思います。 ここ数年間、成果をあげた学生の多くがNet..]
_ みわ [ありがとうございます。cvs.netbsd.org の文脈まで読み取れなかった (;´Д｀)]
2010-07-16 :-)
_ 朝ッ
0520 起床
_ ,
切込隊長のブログは背景が目に痛い。
_ ,
捨てるオオカミ 拾うオオカミ
_ ARC 2010 のレースは未定です
いくつか今後のレース内容を書いてるけど、日程を決定するまではレース内容を変更する可能性があるます。まあ練習してるひとは居ないと思うけど。
_ [リッジレーサー7]リッジレーサー7
オンラインバトルなど。Papoさんとか意味が分からない速さだよなあ
- 走行距離 93009 km
- RSGP 進行度 100.0 %
- 名声 24018 FP
- オンラインバトル勝利数 920/3324
_ ゲームの食卓 第104回 ノビヨ師匠が作詞作曲、そして歌を！？驚愕のコーナー有り！植松伸夫さん特集最終回！
いまさら聞いた
- ノビヨの一日
- 朝起きる
- うがい
- 養命酒を飲む
- 水を500ml流しこむ
- 内蔵に養命酒が染み渡る
- メール読む
- ヨガをやる
- 幽体離脱の練習をする
- 昼
- 作曲など
- ビール飲みながら食事
- 「河口湖にはうなぎの刺身を食える店がある」
- これか？ うなぎ なかむら
- 職業柄
- 近所のご婦人から「昨日ニコ動で見たよ」と挨拶された
- 娘さんと一緒に見てたらしい
- 親子でそういうことできるのはイイネ
- うちの親だったらこういうことやらない
- 親子でゲームしたり
- リメイクしたFF4では「懐かしいです。子供と一緒にやってます」というひとが居た
- 親は元祖FF4をプレイした世代、子供と一緒にリメイクFF4をプレイ
- 仕事でピンチだったこと
- 坂口さんと一緒に酒飲むと、帰路に記憶が無くなる
- 坂口さんコワイ
- 曲
- 一曲作ったらそこで終了させる
- イソッチ「崎元さんは『煮詰める』と言ってました」
- ノビヨ「完成度が違うんだよ :-) 」
_ 磯村知美
「バカとテストと召喚獣」の霧島翔子だったのか
_ 極上生徒会役員共の一存
- 極上生徒会
- 生徒会役員共
- 生徒会の一存
2010-07-18 :-)
_ ,
寝てない (03:28)
_ [リッジレーサー7]リッジレーサー7
すずめちんと一緒にファタリタ特訓するなど。速いなあ
- 走行距離 93635 km
- RSGP 進行度 100.0 %
- 名声 24649 FP
- オンラインバトル勝利数 926/3344
_ [NetBSD][翻訳]NetBSD Blog - Google Summer of Code project Implementing HTTP support for libsa 翻訳
Google Summer of Code project における libsa の HTTP サポート実装
July 18, 2010 posted by Brett Lymn
Zoltan Arnold NAGY has been busy coding away on his project to add support for booting over HTTP to libsa. Early on in his work he found that the current libsa PXE support used the UDP support functions in the PXE ROM which is unsuitable for HTTP as this requires a TCP transport. Zoltan has written a net_if driver for libsa that uses the PXE UNDI functions to allows both UDP and TCP network packets to be sent. Using the new net_if he was able to boot a kernel using tftp which proved that the basic networking functions were working correctly.
Zoltan Arnold NAGY は libsa へ booting over HTTP サポートを追加する作業のためにひたすらコードを書いていた。。PXE ROM にある current libsa の PXE サポート関数は、HTTP をサポートするのに必要な TCP transport には不適切であることに、彼は作業の当初に気づいた。Zoltan は libsa が UDP と TCP の両方のネットワークパケットを送信させるために、PXE UNDI functions を使うように net_if ドライバーを書いた。新しい net_if を使い、基本的なネットワーク関数がちゃんと動作するようになった tftp で kernel が boot できるようにした。
Once the underlying network layer was available Zoltan moved on to the primary aim of the project, booting over HTTP. He has made good progress on this and reports that he can boot a kernel three out of four times via HTTP, clearly one of the goals for the remainder of the Summer of Code is to get this to a 100% hit rate for booting.
下層のネットワーク( 訳: TCP )については解決したので、Zoltan は本題の booting over HTTP 作業にとりかかった。作業は順調に進み、kernel が HTTP 経由で 4 回のうち 3 回 boot できたことを報告し、Google Summer of Code の残った目標のうち 1 つは、100 % 確実に boot させることが明確になった。
There is still a fair bit of work to be done but I believe that Zoltan is on track to providing a useful factility to libsa. Zoltan posted a link to his patches in a posting to the tech-net mailing list
まだかなりの作業があるが、Zoltan は libsa に有益な機能をもたらしてくれると信じている。Zoltan は a posting to the tech-net mailing list にパッチへのリンクを投稿した。
2010-07-19 :-)
_ [リッジレーサー7]リッジレーサー7
ARC 2010 文月GP を開催した。参加者と点数:
- Locus 152
- OWA 146
- ANSΩB2マンタレイ 132
- CONTI4X 124
- JE4URN 96
- SYOURYU 85
- agumon11 80
- ANSΩ三嶋出雲 64
- 桜上水すずめ 58
- ANSΩmiwarin 52
- ファブリーズ 51
- knhtymh 43
- ANSΩマリアナブルー 13
- ちゃぶマッ 11
- 八雲藍 10
15人なのは、途中でマリアナさんが抜けたため。
やはりみんな速いなあ。最初のほうのレースなんて先頭集団から離されすぎて泣きそうになったよ。
なお、knhtymh さんは最後の 2 レースのみ参加。B2さん、CONTI4X さんは 1, 2 レース回線断絶したので上位はもっと接戦になったかもしれない。マリアナさんは 3 レース以降は回線断絶により不参加、マリアナさんはやはり回線の相性が悪いんだろか...。
- 走行距離 94006 km
- RSGP 進行度 100.0 %
- 名声 24717 FP
- オンラインバトル勝利数 926/3354
2010-07-20 :-)
_ 朝ッ
0520 起床
_ 仕事
0830 出勤
2010-07-22 :-)
_ 朝ッ
0520 起床
_ 天才とはなんぞや
結論: ようわからん
昨晩 kohta な ust で「天才は居るか居ないか」という話題があったんだがその前に「天才ってなに？」という定義から始まった。1 つだけ言えることは努力の成果で得たスキルを指してあいつは天才だと云うのは間違っている。クレア・スタンフィールドもそういっている [ 20041115#p09 ]
「 神なんてのは、世界のどこにもいない。唯一、俺の中にいる。お前から見れば、お前の中にいる。そういうもんだろ？」
「 俺が許せないのは──俺のこの力を「奇跡」だの「神のプレゼント」だので済まされてしまうことだ。俺がこの力を得るまでに、何の努力もしなかったとでも思っているのか？」
「 自分の中の神を呼び出し、支配する儀式──それが「努力」という奴だろう？ 俺は──その儀式を欠かさなかった。それだけだ。」
これは、たしかクレアがリング状の刃物を投げ飛ばして攻撃してくる相手とバトルしているときに、クレアの背中( 死角 )から迫るリングに対し、相手の瞳に移ったそのリングを見て( 実物のリングは見てない。相手の瞳を通してリングの位置を把握していた )、リングの機動を読み、リングを回避した、という離れ業をやってのけたクレアに対し、その相手が「お前は天才か」などということを言ったため、その反論としてクレアが「俺は訓練したんだ」などと言った文脈だったと記憶している。
_ ,
バッカーノ! ってまだ続いてるの?
2010-07-23 :-)
_ 朝ッ
0520 起床
_ ラ・チャター
いまさら「エネルギー」( Linear compilation disc01 - SweepRecordSHOP )のボーカルの声に恋したので(「元気出てきたね☆」)悶々とした日々を送っていたらボーカルのひとは茶太だったのか。茶太いいなあ。
2010-07-24 :-)
_ にっちゅう!!
1100 起床
1200 おひる
1300 買い物
1400 伊藤賢治氏＋佐野信義氏による「ゲームミュージック・トークセッション」を神戸電子専門学校から生中継！
1530 コーヒー
2010-07-25 :-)
_ 朝ッ
0400 起床
_ [Python][デザインパターン][Strategy]Python でデザインパターン - Strategy
書き換え[ 20090504#p04 ]
#!/usr/bin/python
# -*- coding: utf-8 -*-
# Head First デザインパターンを写経する - 1章 Strategy パターン - ヨタの日々(2009-05-04)
# http://www.area51.gr.jp/~rin/diary/?date=20090504#p04
class Duck:
def __init__(self):
self.quack_behavior = None
self.fly_behavior = None
def __init__(self):
pass
def perform_fly(self):
self.fly_behavior.fly()
def perform_quack(self):
self.quack_behavior.quack()
def swim(self):
print "すべての鴨は浮かびます。おとりの鴨でも!"
class FlyBehavior:
def fly(self):
pass
class FlyWithWings(FlyBehavior):
def fly(self):
print "飛んでいます!"
class FlyNoWay(FlyBehavior):
def fly(self):
print "飛べません!"
class QuackBehavior:
def quack(self):
pass
class Quack(QuackBehavior):
def quack(sel):
print "ガーガー"
class MuteQuack(QuackBehavior):
def quack(self):
print "<沈黙>>"
class Squack(QuackBehavior):
def quack(self):
print "キューキュー"
class MallardDuck(Duck):
def __init__(self):
self.quack_behavior = Quack()
self.fly_behavior = FlyWithWings()
def display(self):
print "本物のマガモです"
def main():
mallard = MallardDuck()
mallard.perform_quack()
mallard.perform_fly()
main()
% python strategy.py ガーガー 飛んでいます!
_ [Python][デザインパターン][Observer]Python でデザインパターン - Observer
書き換え[ 20090504#p07 ]
#!/usr/bin/python
# -*- coding: utf-8 -*-
# Head First デザインパターンを写経する - 2章 Observer パターン - ヨタの日々(2009-05-04)
# http://www.area51.gr.jp/~rin/diary/?date=20090504#p07
class Subject:
def register_observer(self, observer):
pass
def remove_observer(self, observer):
pass
def notify_observers(self):
pass
class Observer:
def update(self, temp, humidity, pressure):
pass
class DisplayElement:
def display(self):
pass
class WeatherData(Subject):
def __init__(self):
self.temprature = None
self.humidity = None
self.pressure = None
self.observers = []
def register_observer(self, observer):
self.observers.append(observer)
def remove_observer(self, observer):
self.observers.delete(observer)
def notify_observers(self):
for o in self.observers:
o.update( self.temprature, self.humidity, self.pressure)
def measurements_changed(self):
self.notify_observers()
def set_measurements(self, temprature, humidity, pressure):
self.temprature = temprature
self.humidity = humidity
self.pressure = pressure
self.measurements_changed()
class CurrentConditionDisplay(Observer, DisplayElement):
def __init__(self, weatherData):
self.weatherdata = weatherData
self.weatherdata.register_observer(self)
def update(self, tempreture, humidity, pressure):
self.tempreture = tempreture
self.humidity = humidity
self.display()
def display(self):
print "現在の気象状況: 温度 %d度 湿度%d%%" % (self.tempreture, self.humidity)
def main():
weatherdata = WeatherData()
currentDisplay = CurrentConditionDisplay(weatherdata)
weatherdata.set_measurements(27, 65, 30.4)
weatherdata.set_measurements(28, 70, 29.2)
weatherdata.set_measurements(26, 90, 29.2)
main()
% python observer.py 現在の気象状況: 温度 27度 湿度65% 現在の気象状況: 温度 28度 湿度70% 現在の気象状況: 温度 26度 湿度90%
_ ,
バーカバーカ
2010-07-27 :-(
_ 朝ッ
0520 起床
_ ,
涼宮ハルヒのコミック化作品を読んでショックを受けたので「○○のコミカライズ」といった作品は怖くて手が出ない。
_ 制約事項
ここ数年はジャンクフードを食べると吐き気がするようになったので食べてないし、スナック菓子も食べると胃がもたれるから食べてないし( でもせんべいは食べてるな )、揚げ物や肉料理などもあまり食べ過ぎると胃がヨレヨレするし。
部屋がそれほど広くないから漫画や小説は読んだら処分するし( オーム社やオライリーは躊躇する ) CD はエンコードして処分するし、と言ってもお金がそれほど余ってるわけじゃないから娯楽に費やすお金は割りと減らしてるし、ゲームは好きだけど長時間プレイすると疲れるからあまり長時間プレイしないし、徹夜に強くないから夜中まで遊んでられないし。
などと考えていたら、本人の生活は、つまり 持っているリソースに依存する んだなと当然のことに今更気づいた。まあ翼が無ければ空は飛べやしないということで。
- 金
- 時間
- 空間
- 健康
- 命
- 夢
- 希望
- どこから来て どこへ行く？
- そんなものは このわたしが破壊する！
妖星乱舞は興奮する。
ref.
_ ToDo
埼玉のおっさんについて調べる
2010-07-28 :-(
_ 朝ッ
0520 起床
_ ,
まさかコミケ 3 日目に全力を出す日が来るとは思ってもいなかった。
_ [NetBSD][PAE][翻訳]NetBSD Blog - PAE support for native i386 翻訳
i386 での PAE サポート
July 26, 2010 posted by Jean-Yves Migeon
With kernel revision 5.99.37, the options(4) PAE was added to native i386. It is currently disabled by default.
カーネルリビジョン 5.99.37 で options(4) の i386 に PAE が追加された。現在デフォルトでは無効になっている。
PAE, or Physical Address Extension, is a mode that started to appear with Intel's Pentium Pro processor. When enabled, the i386 memory management physical addresses, including page directory and page table entries, are promoted to 64 bits entities, instead of 32 bits. This allows, in the present state, to address physical accesses with 36 bits -- thus turning the whole physical address space to 64GB (although the userland virtual address space remains with 32 bits addresses, or 4GB).
PAE( Physical Address Extension ) とは、インテル Pentium Pro プロセッサの起動時のモードのことである。これを有効にすると、i386 の物理アドレスメモリ管理は page directory と page table entries を含むようになり、32 ビットエントリーの代わりに 64 ビットエントリーに拡張される。この状態になると、36 ビットでの物理アドレスアクセスができるようになるり、物理アドレス全体を 64GB として扱えるようになる( とはいえ、userland の仮想アドレス空間は依然として 32 ビット( つまり 4GB ) のままなんだけど )。
As NetBSD supported amd64 very early, there was no real urge to add PAE support within the kernel; in early 2002, hosts with more than 4GB were rare, and those that had more than 4GB of memory were already moving to amd64.
NetBSD では amd64 が早くからサポートしており、無茶しない範囲で kernel に PAE サポートを追加できていた。2002 年の初頭では計算機が 4GB 以上( のメモリ )を持っていることは珍しかったし、そういう計算機は既に amd64 へ移行していた。
Historically, the first appearance of PAE was thanks to Manuel Bouyer (bouyer@), for the Xen port. It remains, even today, the only solution to run 32 bits domUs with a 64 bits Xen hypervisor. The situation became even more strict starting with Xen 3.3, where non-PAE support was removed from Xen, effectively forcing the domains (dom0 as well as domUs) to move to full PAE support.
歴史的には、最初に PAE を使うようになったのは Manuel Bouyer (bouyer@) による Xen への移植によるものだ。これはいまだに今日でも 64 ビット Xen hypervisor で 32 ビット domU を動作させるための唯一の手段になっている。非 PAE サポートが除外された Xen3.3 の場合はもっとしっかりしており、domain ( domU と同じく dom0 とか )を完全に PAE サポートさせるように移行している。
Later, Jeremy Morse took interest in having PAE supported within native i386, and proposed a patch on port-i386@ for it. I took the responsibility for merging it within -current, and make it less intrusive with regards to the present code of port-xen.
その後、Jeremy Morse が i386 の範囲内で PAE をサポートさせることに関心を持ち、port-i386 へパッチを投げた。私はその後のやりとりも含めて -current にマージし、port-xen に投げたコードに関してはそれほど問題なく make できるはず。
In essence, adding PAE within NetBSD was not a difficult task; however, it took quite a lot of time for testing and debugging, as the merge with the current required modifications in low level code (boot and initialization, pmap(9) handling), as well as fixes in place where physical address change could mask the upper 32 bits (addresses could not be considered as 32 bits "unsigned long" anymore). Fortunately, the API in NetBSD being very clear, finding out and isolating the problematic parts was easy. Besides, having PAE inside GENERIC forced the implementation to be multi-processor safe, so the Xen port can later take advantage from it and move more easily to the multi processor world.
実際のところ、NetBSD に PAE を追加することは難しいことではない。しかし、テストとデバッグにものすごく時間がかかる。current へマージするために必要な低レベルなコード( boot や 初期化や pmap(9)ハンドリング )を変更したり、物理アドレスの上位 32 ビット( アドレスには符号なし 32 ビット整数を含めることができない )を変更するといった手間がある。幸いにも NetBSD の API は非常に分かりやすく見つけやすいので、問題を簡単に切り分けることができる。さらに、GENERIC の PAE はマルチプロセッサーセーフに実装されており、Xen port はそれを利用できるから、より簡単にマルチプロセッサー環境へ移行できる。
For those interested in small security improvements, enabling PAE on i386 has the benefit of unmasking the 63rd bit in the physical address, called the NX/XD (No-eXecute/eXecute Disable) bit. By marking a physical page with this bit, you can prevent code execution on the page. All CPUs do not support this feature; you can easily spot it through cpuctl(8) -- look for NOX or XD in the features output.
セキュリティに関してちょっと面白いものがある。i386 上で PAE を有効にすると、物理アドレスの 63 ビット目( NX/XD (No-eXecute/eXecute Disable) bit と呼ばれる )のマスクを解除できて嬉しい。このビットによってマークされた物理ページはコードの実行を防ぐことができる。すべての CPU がこの機能を使えるわけじゃないけど、cpuctl(8) を見れば NOX や XD についてわかる。( 訳: cpuctl(8) 読んでもさっぱり分らないんだけど... )
Importing PAE was an interesting challenge, as it raised concerns regarding the stability of the kernel ABI when manipulating physical addresses. Physical addresses are constantly used for device drivers, as they are needed for communication with them over different types of buses. Stabilizing the ABI offers the possibility to develop drivers, or modules, without fear of breaking binary interfaces. Here, it will help modularizing the kernel even further, by providing modules, and hopefully, a kernel, that could fit native, PAE and Xen memory models without needing separate compile and build time options.
PAE を取り込むことはとても挑戦的なことで、物理アドレスを操作する kernel ABI の安定性向上につなげられるとみなすことができる。物理アドレスとは、デバイスドライバが異なるバス間で通信するときによく使われるものだ。ABI を安定させることは、バイナリインターフェースをぶち壊すことを恐れずにドライバやモジュールを開発することができるようになる。これにより、モジュールによる kernel モジュール化をさらに進め、うまくすればそれが標準( 訳: native )となり、PAE や Xen のメモリーモデルはコンパイルとビルドを間髪おかずに実行できるようになる。( 訳: ???? )
_ FMトランスミッターとやらを購入した
FM周波数をオートスキャンしてくれるんだが( オートしかできない ) iPod touch の場合 この液晶に周波数が表示されないのでむしろ手動で設定できるほうがうれしいかもしれない。( iPod は表示されるらしい )
とりあえず設置してみた図
B002UM5THU
2010-07-29 :-)
2010-07-31 :-)
_ ,
知らんがな
_ モバゲーのナムコな TVCM
TVCM ではパックマン、ゼビウス、ニューラリーX、ギャラガが紹介されてる。リッジレーサーには昔のナムコのゲームからのアレンジ曲が使われることが多々あるのでサントラを眺めてみたけど ニューラリーX だけは曲が無かった。
- Galactic Life (RR6) ギャラガ
- Run Pac-man Run (RR6) パックマン
- Eat The World (RR7) パックマン
- Synthetic Life (RRs) ゼビウス、ドラゴンスピリット、ギャラガ
- Eat'em Up! (RR4) パックマン
- MotorPacCity5 (RR5) パックマン
「多々ある」というほどでもないか。
Synthetic Life を BGM にして RR7 で JUJAK で走ってるひとが居た。
_ ,
アニメ声っていうかロリ声でしょ？
_ ,
ようするに「アプリケーションにどうやってシグナルを送るか」という問題なだけ
_ 「釣り始めました」
ネットスラングでいう意味の「釣り」と思ってしまう自分が嫌だ
_ さいき [>奇々怪界と変換 好きなゲームだったなぁ～（違ｗ メ～ルだなぁ～ｗｗｗ ↑さすがに知り合いとのやり取りだけで 会..]
_ みわ [奇々怪界は結局クリアしてないや (・ω・)]