2010-08-05 :-)
_ 朝ッ
0520 起床
_ レキジョ
轢女
_ ,
dankogai dankogai という認識になっているのでもはや小飼弾と言われてもピンとこない。
_ ,
s/バッファロー/バッキャロー/g
_ C言語のポインタ
ポインタで挫折すると言っても a->b くらいなら普通に使うよね挫折するとかワケワカンナイヨと思ってた時期がありました。
463 デフォルトの名無しさん [sage] 2010/08/02(月) 23:02:44 ID: Be: (void)foo->super(foo)->hoge(foo->super(foo)); (void)(*(*(*foo).super)(foo)).hoge)((*(*foo).super)(foo)); 一時変数使えよって感じだな
(´Д｀；)
_ ,
お。soda さんだ
_ [NetBSD][翻訳]NetBSD Blog - Interview with S.P. Zeidler
S.P. Zeidler へのインタビュー
August 06, 2009 posted by Emile Heitor
Here's the third edition of the "discussions with a NetBSD developer" series. This time, we had the chance to talk to S.P. Zeidler, admin and member of pkgsrc-releng.
第3回「NetBSD 開発者に聞く」。今回は NetBSD admin と pkgsrc-releng のメンバーである S.P. Zeidler に話を聞くことができた。
NetBSDfr: For the readers who don't know you, can you shortly introduce yourself ?
spz: Hi, I'm S.P.Zeidler, call name Petra, also answers to spz or stargazer or Ophiuchi. I'm a member of the NetBSD admins team and of pkgsrc-releng. My archs are amiga, sparc64, amd64 and i386. In other news, I'm Bavarian, mid-fortyish, female, married, 2 cats, no kids.
NetBSDfr: あなたのことを知らない読者のために自己紹介をお願いします。
spz: S.P.Zeidler と言います。Petra と呼んでください。spz か stargazer か Ophiuchi でもいいよ。NetBSD admin チームと pkgsrc-releng チームのメンバーです( 訳: ???? )。持ってるアーキテクチャは amiga, sparc64, amd64 それと i386 です。あと私はバイエルン人で、中年( 訳: ???? )の女性、既婚で 2 匹の猫がいます。子供はいません。
NetBSDfr: Why did you choose to run NetBSD ? How long have you been using it ?
spz: It was the first free Unixoid system that ran on my Amiga, serpens, which has been running NetBSD since February 1995, i.e. since NetBSD 1.0.
NetBSDfr: どうして NetBSD を選んだのですか？ NetBSD を使い始めてどれくらいですか？
spz: NetBSD は、手元の Amiga でいい感じに( 訳: serpens ???? )動いた最初の Unix 系 OS なんです。1995 年の NetBSD 1.0 のころから使ってます。
NetBSDfr: How did you become a NetBSD developer ?
spz: When the admins team was looking for more help, I got asked and didn't run away fast enough :-P
NetBSDfr: どうやって NetBSD 開発者になったのですか？
spz: admin チームがもっと人手を求めていたとき捕まり、逃げ出さなかったためです :-P ( 訳: わからん ???? )
NetBSDfr: Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?
spz: Half an hour daily at least, but depending on things to do; running up 20 hours over the course of a weekend happens quite easily. Both admins and pkgsrc-releng are demand driven, you get requests and you handle them, security updates to servers need to be done as vulnerabilities become known, etc etc. I don't do much programming, if I commit something that's usually a bug fix where I sufficiently hated the bug to unpack the zapper myself instead of just whining about it.
NetBSDfr: NetBSD プロジェクトに携わる時間について何か決めていますか？ 毎日？ 毎週？ 毎月？
spz: いろいろな制約があるけど毎日少なくとも 30 分くらい作業します。週末なら 20 時間以上作業することも楽勝です。admins と pkgsrc-releng チームは両方とも要求が来たときに作業します。vulnerabilities のようにサーバーに必要なセキュリティアップデートなどの作業が要求されたら作業します。プログラミングはあまりできないので、激しく嫌悪するようなバグを解決してフィックスしたらいつも the zapper myself instead of just whining about it してやります。( 訳: ?????? )
NetBSDfr: What is the job of a NetBSD admin ? How many admins are there ? How do you work alltogether ? How do you share the tasks you have to do ?
spz: In the abstract, keeping the servers of The NetBSD Foundation secure, up, and doing useful work. At a closer view, it's plain oldsystem administration with administration of services like eg mail thrown in.
There are currently 5 admins on admins rotation, which means doing a week of looking after user requests in turn, plus 6 more who do specialized tasks like site visits or do emergency repairs if a server or service acts up (like eg putting a stop to a mail loop). We have a ticketing system (RT) that user requests go into; whoever takes a ticket is responsible for resolving it.
For non-user requests, eg mail setup and mail-filtering is done by soda@, and tls@ is looking after hardware; I handle OS and package installation and upgrades.
NetBSDfr: NetBSD admin での作業はどういうことをやっていますか？ admins には何人いますか？ みんな一緒に作業するのですか？ どうやってタスクを分担して作業してるのですか？
spz: おおざっぱにいうと、The NetBSD Foundation のサーバー群をセキュアにし、ちゃんと動作するように保ちます。実際のところはメールなどの古き良き管理サービスを管理しているだけです。現在は、ユーザーからのリクエストについては 5 人で回して作業してます。6 人目は、サーバー自身やサービスの調子が悪いときに復旧させるなど特殊なことをやってます( メールのループを停止したりすることです )。チケット管理システム( RT )を使っていて、ユーザーからの要求については誰でもチケットに着手し問題を解決するようにしています。
メールのセットアップやメールのフィルターなどユーザーからのリクエストではないものについては soda@ がおこなってくれましたし、ハードウェアは tls@ が面倒を見てくれてます。私は OS をいじったりパッケージをインストールしたりアップグレードなどしています。
NetBSDfr: What is the hardware infrastructure of the NetBSD project, in terms of hardware and software ? Where are they located ?
spz: We currently have two main sites, at ISC in Redwood City where the public servers are, and at Columbia University in New York where the TNF owned build cluster is. There is one lonely box in Sweden, hosted by the Lule Academic Computer Society, which provides data backup services.
The servers are a comparably boring bunch of rackmount servers (no fun retro archs at all, unless you count i386 ;), the newer ones amd64 arch and the older ones i386, and they run NetBSD-4 or NetBSD-5 at present, seeing that I am currently installing new servers instead of upgrading the remaining NetBSD-4 machines.
blog.NetBSD.org is a TNF system as of earlier today, and there will be a new ftp and due to reshuffling, new www and mail servers eventually too.
Thanks to everybody who donated funds and made the new machines possible, and of course also thanks to the organisations that host them.
NetBSDfr: NetBSD プロジェクトのインフラにはどのようなハードウェアやソフトウェアを使ってるのですか？ それらはどこに設置されてますか？
spz: 現在はおもに 2 箇所のサイトがあります。公開用サーバーは Redwood の ISC にあり、New York の Columbia 大学には TNF 自身のビルドクラスターがあります。バックアップ用サービスが 1 つだけ Sweden の the Lule Academic Computer Society にホスティングされてます。
これらのサーバーはラックマウントのように詰まらないものです( i386 をカウントしないならば全部枯れたアーキテクチャです )( 訳: 古くてまったく面白みが無いアーキテクチャということ ????????? )、新しいものは amd64 から、古いものは i386 があるんですが、それらは NetBSD 4 または NetBSD 5 で動作してます。いま NetBSD 4 のマシンをアップグレードしてる最中です。
blog.NetBSD.org は TNF システムでは割りと新しいものです。いずれ ftp を刷新し、www と mail もそのうち新しくします。
寄付してくれたみなさんには感謝しています。おかげで新しいマシンを構築できました。もちろんホストさせてもらっている団体にも感謝します。
NetBSDfr: As part of the pkgsrc-releng team, can you tell us more about the way pkgsrc releases are organised ? How is a release tested / validated ?
spz: Unlike releng for the OS, the pkgsrc-releng team does not actually create the releases, it just maintains them. Pkgsrc releases are done roughly quarterly, give and take a week, and get 'cut' after one to two weeks of freeze period during which build and security issues of packages get fixed while the pkgsrc infrastructure itself is static. Build issues get found by the bulk builders, packages not working right get found by community input (if not by their maintainers, who usually use their packages themselves).
The main advantage of a maintained stable branch is that security issues get point fixes, ie you get to replace just the affected package and the rest stays at same version, which makes eg configuration incompatibilities a lot less likely. For production servers, using the stable branch of pkgsrc is definitely a good idea.
NetBSDfr: pkgsrc-releng チームについて聞きたいのですが、よろしければもう少し pkgsrc のリリース行程について聞かせてもらえませんか？ テスト済みのものや認証済みのものはどうやってリリースするのですか？
spz: OS のリリースとは異なり、pkgsrc-releng チームは release を作成しません。ただメンテナンスするだけです。pkgsrc リリースはだいたい四半期ごとに 1 週間かけて作られ、その後 pkgsrc の更新を止め、2 週間かけてビルドしたり( 訳: ???? )パッケージのセキュリティホールを埋めたりし、凍結させ、cut します。( 訳: 「CVS のブランチを作る」などという意味？ )。ビルドの問題については bulk builders が見つけてくれますし、パッケージが正常に動作するかどうかはコミュニティの知らせを見れば分かります( パッケージメンテナーによるものではない場合は彼ら自身がパッケージを使います )。( 訳: ?????????????? )
NetBSDfr: You told us there were no fun retro arch in the machines administered by the project. I'm wondering then how are pkgsrc releases built (if they are) for those retro archs ? Are the pkgsrc releases cross-compiled ? Provided by third-parties ? Not built ? Does it work the same way for NetBSD releases by themselves ? Are all the "fun retro" archs versions cross-compiled ?
spz: NetBSD proper can be cross compiled, the framework exists, and it's being used to provide binaries for all archs (see ftp.netbsd.orgs /pub/NetBSD-daily, we don't just build formal releases :).
pkgsrc has a few packages that have a cross compilation framework, but most don't, and there are several packages with a lot of dependants for which creating such a framework would mean ripping out the entire build system the package brings itself and redoing it, and redoing it for every new version that comes out after it, unless one gets buy-in by the people who create and maintain the software being packaged itself.
One of the headache packages in that space is perl, and it's interesting to see that there is now interest in a fully cross-compilable perl in the perl community itself.
So how do binary packages materialize? Developers who have the hardware bulk-build packages and upload them. You can read about the build reports on the mailing list pkgsrc-bulk.
NetBSDfr: あなたさは先ほど NetBSD プロジェクトには枯れたアーキテクチャのマシンが転がっていると言いました。不思議に思うんですが、どうやって pkgsrc のリリースをそれらのアーキテクチャ向けに( またはそれらのアーキテクチャ上で )ビルドしてるんですか？ pkgsrc のリリースはクロスコンパイルしてるんですか？ それともサードパーティから提供されるんですか？ ほんとはビルドしてないとか？ NetBSD のリリースでも同じことをやってるんでしょうか？ 素敵なアーキテクチャもすべてクロスコンパイルしてるんでしょうか？
spz: NetBSD はすでにフレームワークが整っているのでクロスコンパイルは妥当ですし、全アーキテクチャのバイナリを提供するときにも使っています。( ftp.netbsd.orgs /pub/NetBSD-daily を見てください。リリースに限らずビルドされたものが置いてありますから :)
pkgsrc のいくつかのパッケージにはクロスコンパイルのフレームワークがありますが、ほとんどのパッケージにはありませんし、大量のパッケージに依存しているいくつかのパッケージについてフレームワークを使うように作成すると、ビルドシステム全体をビルドしなおすようなことになりますし、その後 新しいバージョンが登場するたびに同じ作業をおこなう羽目になり、one gets buy-in するひとたちが居ないならば、ソフトウェア自身によってパッケージされるように作成、保守されるようにすればいい。( 訳: ??????????? )
この辺りの話題については Perl が頭痛の種の 1 つで、面白いことに Perl コミュニティ自身の手によって完全なクロスコンパイル環境が構築されています。( 訳: おかしい。前半と後半の意味がつながらない )
で、どうやってバイナリパッケージを準備するか、でしたっけ？ 開発者自身がパッケージの bulk-build するためのハードウェアを持っていて、それらをアップロードしています。pkgsrc-bulk のメーリングリストでビルド報告を見ることができます。
NetBSDfr : In your professional environment, do you work with NetBSD ? How do you think we should promote NetBSD for wider use within companies ?
spz: At my present job I don't work with NetBSB (yet); I'm currently not responsible for internal IT and the customers have existing servers to take care of, where a ninja change of OS is not entirely practical, if occasionally very much desired. :-7 There is lately some pkgsrc, at least.
In my experience, NetBSD gets used in general IT in companies where the sysadmins knew NetBSD previously and appreciated it as a "install - configure - runs" system of minimum ick factor. The more people know and appreciate NetBSD, and the more practical its use on production servers, the more use of that kind it will see. Of course, many companies use NetBSD and have no idea that they do so, since it's part of some "solution device" they use; these tend to be boring from my point of view though, since they tend to be rather black-box like. The makers of these devices will likely differ.
NetBSDfr: あなたは仕事では NetBSD を使って仕事してるんでしょうか？ もっとたくさんの企業に NetBSD を促進するためにはどうしたらよいでしょうか？
spz: 仕事では NetBSD は使っていません( いまはまだね )。社内システム部門( 訳: internal IT )の担当ではないし、顧客が持ってる既存のサーバーの面倒を見るだけだし、a ninja change of OS is not entirely practical ですよ。ときどきものすごくそういう衝動に駆られますけどね :-7 まあ最近はいくつかの pkgsrc を使ってます。
私の経験では、一般的に、NetBSD を知ってるシステム管理者は仕事場でも NetBSD を使ってますし、あまりウンザリしなくて済む「インストールして、設定すれば走る」というのは評判が良いです。ほとんどのひとたちは NetBSD が良いものだということを知ってますし、サーバーとして実用できますし、ほかのことにもほどよく使えるでしょう。もちろん多くの企業が NetBSD を使っていますし、どう使うかという案は持ってないようです、彼らの問題を解決するための装置の一部という扱いだし、これらについては私が見てる限りではウンザリすることになるし、むしろブラックボックスとして扱われるようになります。装置メーカーはこの限りではないようですが。
NetBSDfr: As a conclusion, can you tell us how you forecast NetBSD future ?
spz: That's a hard one, especially as it depends a lot on 'chaotic' nature events of, eg, one developer pulling something out of their hat that proves to be a must have feature for an entire new class of device, or others banding together to make a form of use that is now possible but tedious to set up a snap drop-in; and in the long run, the question where computing is going is also unclear.
I can tell you what I am hoping for, and that is for a NetBSD that is small enough to allow the insertion of daring new ideas in -current, and large enough to mature -current into a rock solid release track system periodically; a project that generates ideas that may spread into the common pool and isn't just a me-too with slightly different wallpaper. That is why I'm spending my time on doing infrastructure, at least.
Oh, and I want cool ARM based netbooks with ridiculously long battery lifetime running NetBSD available soonish. The guilty parties will hopefully get a move on :-P
NetBSDfr: 最後に NetBSD が今後どのようになっていくかあなたの考えを聞かせてください。
spz: 難しいね。何が起きるか分らないし。たとえば、ある開発者は新しいデバイスクラス全体を機能させるためにいざこざを起こすかもしれないし、ほかの誰かは snap drop-in をセットアップするのに飽きて make a form を一緒くたにしてしまうかもしれないし、結局コンピューティングの将来が不明なのと同じだよね。
希望を言えば、NetBSD は -current に奇抜な試み導入できるくらいはじゅうぶん小さくなってほしいし、成熟した -current がリリースごとに定期的にシステムを追えるほど堅固になるくらいじゅうぶん大きくなってほしいし、NetBSD プロジェクトが common pool の範囲内でアイデアを作ってほしいし、私だけに限らないけど少しずつ違った壁紙がほしい。少なくとも、それが、なぜ私がインフラに時間をかけてるかの答えです。
ああ、あと、NetBSD を乗せて長時間バッテリー駆動する ARM のネットブックが欲しいです。これは急務です :-P
Many thanks to Guillaume Lasmayous from NetBSDfr for his hard work in preparing, conducting and translating this interview.
Guillaume Lasmayous は前準備や運営やインタビュー記事を送ってくれて感謝する。
_ [Python][デザインパターン][Adapter]Python でデザインパターン - Adapter
書き換え[ 20090508#p04 ]
#!/usr/bin/python
# -*- coding: utf-8 -*-
# Head First デザインパターンを写経する - 7章 Adapter パターン - ヨタの日々(2009-05-08)
# http://www.area51.gr.jp/~rin/diary/?date=20090508#p04
class Duck:
def quack(self): pass
def fly(self): pass
class MallardDuck(Duck):
def quack(self):
print "ガーガー"
def fly(self):
print "飛んでいます"
class Turkey:
def gobble(self): pass
def fly(self): pass
class WildTurkey(Turkey):
def gobble(self):
print "ゴロゴロ"
def fly(self):
print "短い距離を飛んでいます"
class TurkeyAdapter(Duck):
def __init__(self, turkey):
self.turkey = turkey
def quack(self):
self.turkey.gobble()
def fly(self):
for i in range(5):
self.turkey.fly()
def main():
duck = MallardDuck()
turkey = WildTurkey()
turkeyAdapter = TurkeyAdapter(turkey)
print "Turky の出力..."
turkey.gobble()
turkey.fly()
print "\nDuck の出力..."
testDuck(duck)
print "\nTurkeyAdapter の出力..."
testDuck(turkeyAdapter)
def testDuck(duck):
duck.quack()
duck.fly()
main()
出力
% python adapter.py Turky の出力... ゴロゴロ 短い距離を飛んでいます Duck の出力... ガーガー 飛んでいます TurkeyAdapter の出力... ゴロゴロ 短い距離を飛んでいます 短い距離を飛んでいます 短い距離を飛んでいます 短い距離を飛んでいます 短い距離を飛んでいます
