2010-12-01 :-(
_ Third Party Software Distributed with NetBSD
NetBSD に含まれるサードパーティ製ソフトウェア
bsd-family-tree なんてものも含まれてるのね。
_ Mastering FreeBSD and OpenBSD Security - O'Reilly Media
NetBSD いらない子... (´・ω・`)
_ /etc/postfix
main.cf が /usr/pkg のころのままだったのでテキトーに整合させるなど。
_ /etc/rc.d
いろいろファイルコピーするなど。
2010-12-02 :-(
_ 午後
1500 ローカルで動作確認
_ 夜
1800 続きは CM のあとで
_ べしゃり
三輪はよくひとのしゃべり方に影響されて、自分のしゃべり方が変わってしまう。という秘技を持っているんだが、最近は Papo さんに影響されている。
2010-12-03 :-(
_ 午後
1400 シミュレーションさせる
_ 夜2
2330 かず母と skype テキストチャット
2400 かず, rosso, SOLARE が skype ボイスチャットやってるらしいので誘われるものの GT5 の会話が盛り上がっておりまったく話についていけないので引き続き かず母とテキストチャット
2500 力尽きる
2010-12-04 :-)
_ 夜
2000 屋敷忘年会
_ よかった探しリース
今年も参加
- リッジレーサー7 チームANSのサイト を作った[ 20100110#p02 ]
- 自家用車に乗ってドライブした
- www.NetBSD.ORG 翻訳プロジェクト に参加し、いくつか commit した
- LPIC-1 に合格した
- LPIC-2 に合格した
- kdmsnr さんの翻訳レビュー に参加した(ている)
2010-12-05 :-)
_ サーバー切り替えた
ルーターのファイアウォールの設定は変更したのに外から繋がらない。なんでだろーなんでだろーと悩んでいたんだが NAT の設定変更し忘れてた。
_ [リッジレーサー7]リッジレーサー7
オンラインバトル。SEKIMANI は逆走ユーザーだったか
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26000 FP
- オンラインバトル勝利数 1140/4017
_ [Panasonic][Let's CF-R4][分解]Let's CF-R4 分解
HDD を取り出したいんだが分解するしか無いらしい。Panasonic レッツノート CF-R4 ハードディスクの交換・換装方法なら分解web を見ながら作業。終わったら組み立て。ふう...
2010-12-06 :-(
_ 午後
1400 プロファイル
_ [cpan][Perl]XML:LibXML
: LibXML.xs: In function 'boot_XML__LibXML': LibXML.xs:1409: error: 'LIBXML_TEST_VERSION' undeclared (first use in this function) LibXML.xs:1410: error: expected ';' before 'xmlInitParser' LibXML.xs:1413: error: 'xmlGetWarningsDefaultValue' undeclared (first use in this function) *** Error code 1 Stop. make: stopped in /root/.cpan/build/XML-LibXML-1.70-7I1j9u PAJAS/XML-LibXML-1.70.tar.gz /usr/bin/make -- NOT OK Running make test Can't test without successful make Running make install Make had returned bad status, install seems impossible Failed during this command: PAJAS/XML-LibXML-1.70.tar.gz : make NO
インストールに苦戦するCPANモジュール#1(XML::LibXML)
% ls -ld /usr/pkgsrc/*/libxml2 drwxr-xr-x 4 root wheel 512 Dec 1 20:23:08 2010 /usr/pkgsrc/textproc/libxml2/ % cd /usr/pkgsrc/textproc/libxml2 % make install clean-depends
cpan
: PAJAS/XML-LibXML-1.70.tar.gz /usr/bin/make install -- OK :
good!
2010-12-08 :-(
_ 夜
1800 自社で面談
1900 退勤
1930 買い物
2000 仮眠
2100 飯
2200 memcpy のパフォーマンス最適化をググる。この辺かなあ Daniel's Software Blog: Fast memcpy in c memcpy performance - Intel® Software Network
2010-12-09 :-(
2010-12-11 :-)
_ [リッジレーサー7]リッジレーサー7 ARC 2010 師走GP
やってた。最近 B2 さんが参加してくれない。飽きたか (´・ω・`)
- rosso 190
- CONTI4X 142
- ANSΩmiwarin 109
- SOLARE 105
- ANSΩ三嶋出雲 97
- zero 88
- かず 73
- Locus 66
- knhtymh 62
- megu.Girls 37
- ANSΩ八雲藍 29
- 【T.H.C】初号機-K 6
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26077 FP
- オンラインバトル勝利数 1147/4043
_ [NetBSD][翻訳]NetBSD Blog - Interview with a NetBSD developer: today, Amitai Schlair, aka schmonz@
December 08, 2010 posted by Guillaume Lasmayous
A few months after Thomas Klausner's interview, please welcome today Amitai, better known as schmonz@.
Thomas Klausne のインタビューから数ヵ月たちましたが、今日は schmonz@ として知られる Amitai です。
NetBSDfr: For those of our readers that don't know you, can you introduceyourself briefly ?
NetBSDfr: 読者のみなさんに自己紹介をお願いします。
I grew up in a suburb of Chicago. Both at school and at home, my childhood computing skewed Appleward. The exception was Texas Instruments graphing calculators. By the end of high school, I had a nearly complete set.
シカゴの郊外で育ちました。学校でも自宅でもコンピュータを使って Appleward [ ???? ] したひねくれた生活してました。でもテキサツインスツルメンツの Instruments graphing calculators は別でした。高校の最後にやったんですが、もう少しで完了しそうだったんです。{ TIがそういうコースやってるのかしら }
NetBSDfr: How did you discover NetBSD ? How long have you been using it ?
NetBSDfr: どうやって NetBSD と出会ったのでしょうか? NetBSD を使い始めてどれくらいになりますか?
Programming TI calculators led to involvement with ticalc.org, a volunteer project. The server was running Linux (a 1.x kernel). I couldn't contribute because I had no idea what was going on, so I asked my fellow staffers how I could learn Unix when the only semi-capable machine I owned was a Mac IIci. They suggested NetBSD (at the time, 1.1). It was good advice. But of course there are still Linux systems where I have no idea what's going on. ;-)
ボランティアプロジェクトの ticalc.org で TI calculators led のプログラミングやってました。そこのサーバーは Linux でした( 1.x カーネルです )。どうしていいか分からなかったので、とくに何も貢献しませんでした。だから私は、どうやったら自分の Mac IIci のように専用のマシンで Unix を学べるか教授たちに聞いたんです。そうしたら NetBSD を勧められました。(あのころは 1.1 でした) 良い助言でした。だって私はいまだに Linux システムをどうするか考えてなかったんですから ;-)
NetBSDfr: How did you become a NetBSD developer ?
NetBSDfr: どのようにして NetBSD 開発者になったのでしょうか?
Several years later I'd learned a thing or two, had been using NetBSD in earnest on both desktop and server, and started sending problem reports and patches for pkgsrc. Apparently they were reasonable patches. I still remember where I was -- and how giddy I felt -- when I read the email inviting me to become a developer. It was quite an honor to be included in a group of smart people who work together to build something of significance, relevance, and quality. Still is.
数年後 NetBSD をデスクトップとサーバーの両方で使えるようにするためにはどうすればよいか真面目に考えてたので、pkgsrc の問題報告とパッチを送り始めました。ぱっと見てパッチは有効だったようです。あれはいまだに忘れもしない、そして目もくらむような思いをしたんですが、あるとき [ NetBSD ] 開発者への招待メールが届いたんです。それは [ NetBSD のなかで ]重要で、適切に、高品質にするために作業しているひとたちの仲間に入れるということだったんです。いまでもそうです。
NetBSDfr: Do you have an idea of the time you spend working on the NetBSD project daily, weekly, monthly ?
NetBSDfr: NetBSD に関わる時間としてはどのように考えてますか? 毎日? 毎週? 毎月?
Depends how many itches I need to scratch, and how badly -- and whether I instead ought to be having my broken arm set in a cast, or at least brushing my teeth, or whatever else I can do to overextend this metaphor. There's a lot of variance: days and weeks go by where I do little to nothing, while more than a handful of weekends have disappeared while working on NetBSD stuff. The average is probably no less than a few hours per week.
痒みと、それに苦しむ時間によるし、骨折した腕を固定しなければならないし、それで歯を磨かなければならない。いや失礼。まあ日々いろいろやることがあるのであまりやれることは無いです。週末もいろいろやることが増えたので、NetBSD スタッフとして活動できる時間もなくなってしまいました。ここ最近の週末はだいたいこんな感じです。
NetBSDfr: Can you explain us the role of pkgsrc-pmc, and your role in this organisation ?
NetBSDfr: pkgsrc-pmc での役割と、NetBSD.org での役割を教えてください。
pkgsrc-pmc is a committee that oversees pkgsrc development, akin to NetBSD's core. Our main responsibilities are to set the technical direction for the project (insofar as that is meaningful for a volunteer project) and to adjudicate the rare technical dispute that can't be resolved by the disputants. We don't assign specific roles within the PMC. I occasionally have an idea or two about technical direction, as you saw at pkgsrcCon last month.
pkgsrc-pmc は NetBSD コアチームのように海外の開発者たちによる委員会です。我々のおもな仕事はプロジェクト [ ここでの「プロジェクト」は pkgsrc のことかしら ] の技術的な環境を整えることです(ボランティアプロジェクトのために出来る限りのことをします) 。そしてたまに口論が起きるので仲介します。PMC の中ではとくに役割を決めていません。先月の pkgsrcCon であなたが言ったように、私はたまにアイデアを出したり、技術的な方向づけをしたりしｍさう。
NetBSDfr: As far as I know, you're responsible for the NetBSD wiki. Can you tell us where you are on the road with it ? How will the transition with wiki.netbsd.se be handled , now that we know it's gonna be shutdown at the end of month (Note: Interview was held a few weeks after pkgsrcCon 2010) ?
NetBSDfr: 私の記憶では、あなたは NetBSD wiki もやってましたよね? よろしければどのような経緯があったのか教えてください。どのようにして wiki.netbsd.se を移行したのでしょうか? 今月末に終了しますよね? (注意: このインタビューは pkgsrcCon 2010 の数週間後におこなわれた )
Yes, I've been leading the charge to roll out an official wiki for the NetBSD Project. Our environment has fairly particular requirements, which means it's not just a matter of installing $WIKISOFTWARE and calling it a day. In addition to choosing the wiki implementation carefully, we have to do a fair amount of work to tie it neatly into our setup. The big pieces are in place: CVS integration, appearance and styling, and web authentication (shared across several services). That would've been good enough to go into production, except that in the interim we grew some new requirements.
ええ。私は NetBSD プロジェクトの公式 wiki を立ち上げる作業を率いました。$WIKISOFTWARE をインストールするだけではなかったので、作業に特化した環境を作りました。wiki をきちんと立ち上げるために wiki は実装しやすいようにしました。CVS を導入したことにより、統合、出版、整形、そして web 認証 (複数サービスにまたがったもの) が楽になったことが大きいです。wiki を立ち上げるには十分なものでした。これでしばらくの間は新しい要求があってもすぐに反映できます。
Originally, the official wiki wasn't intended to replace the unofficial one. People who wanted to contribute to a NetBSD wiki had been doing just fine without us. That's no longer the case. We want these people to be able to keep contributing to NetBSD as they have, so we're adapting our wiki plans to make room for everyone. This entails some careful rethinking -- every other official Project resource is, by design, writable only by developers -- followed by a fresh batch of integration work. We'd hoped to have time to prepare for a smooth transition from wiki.netbsd.se; alas, it's not in the cards. Instead, we're working as quickly as we can to make it possible for everyone to participate in the official NetBSD wiki.
もともとは非公式 wiki を公式に置き換えるつもりはなかったんです。NetBSD wiki に貢献したいと思っていたひとたちには我々が必要になったというだけです。もうそのようなことはありません。我々は彼らのように NetBSD に継続的に貢献してくれるひとを求めており、だからこそ我々の wiki 計画に加えたのです。これは考えを改めることになりました。すべての非公式リソースは、開発者のためだけに書かれたものですが、これを統合する作業がいるのではないかと。wiki.netbsd.se からの移行を円滑に作業するために準備の時間がいりました。しかしそれはもうありません。我々は公式 NetBSd wiki をすべての人々へすぐに届けることができる。
A smooth transition would also, at minimum, involve moving worthwhile content to the new wiki and providing HTTP redirects at the old URLs for a while. Of course, these require a modicum of assistance from the administrators of wiki.netbsd.se. For users' sake, I hope assistance will be forthcoming.
円滑に移行するためにはコンテンツを新しい wiki へ移動させるのと、古い URL から HTTP リダイレクトさせることも必要でした。これはもちろん wiki.netbsd.se 管理者の協力が必要です。ユーザーのために協力してくれるならば誰でも歓迎です。
NetBSDfr: In your professional environment, do you work with NetBSD ?
NetBSDfr: 仕事では NetBSD を使ってますか?
My workplace has a standardized computing environment that doesn't include NetBSD. But two of the people I work with most closely are NetBSD developers, and unprivileged pkgsrc makes me approximately a bajillion times better at doing what I need to do.
私の仕事場は NetBSD が置いてない、普通のオフィスです。でも私のすぐ近くに 2 人の NetBSD 開発者が居て、私が作業しやすいように pkgsrc のためにたくさんの時間を割いてくれています。
NetBSDfr: As a conclusion, can you tell us how you do foresee NetBSD's future ?
NetBSDfr: 最後に今後 NetBSD はどうなっていくと思いますか?
We have a bunch of very smart people working productively on interesting problems. That's only a prerequisite for a bright future, not a guarantee thereof, but it's by far the most important prerequisite -- all the more so because we're so heavily dependent on the efforts of volunteers. Very smart developers are attracted to communities where other very smart developers can work on what they want and enjoy it. We're lucky to have that kind of community. We must defend it with everything we've got.
我々は興味深い問題にとても優秀なひとたちと取り組んでいます。輝かしい未来のためだけにやっているのであって、それ以外ではありません。それより重要なことは、全員がボランティアであるということです。とても優秀な開発者がとても優秀な開発者と交流し、影響しあって、楽しんで作業してくれることを望みます。このコミュニティに出会って運がよかった。我々はこのすべてを守らねばならない。
I got involved with NetBSD because it appealed to my better nature. I've stayed involved because I find it seriously fun. If we can keep it that way, we'll keep attracting the right people. If we keep attracting the right people, we'll do fine.
私が NetBSD に取り組んだのは、それが私にとって自然のことだったからです。私がとどまり続けるているのは、とても楽しんでいるからです。我々がこのままでいる限り、ひとびとを魅了し続けるでしょう。ひとびとを魅了し続けるために我々は走り続ける [ もう少しマシな訳はないか.... ]
Thanks for answering our questions.! The french (translated) version can be found on NetBSDfr.org website [0 comments]
質問に答えてくれてありがとう。フランス語に変換したものは NetBSDfr.org で読めますよ。
2010-12-16 :-)
_ [翻訳][NetBSD]NetBSD Blog - nxr update
nxr 更新
December 15, 2010 posted by Zafer Aydogan
Dear Readers,
やあみんな
The NetBSD Cross Reference service has recently been updated to use the latest version of OpenGrok from pkgsrc.
先日 NetBSD Cross Reference が pkgsrc の最新 OpenGrok で更新された。
In addition to the main NetBSD-current sources, the following development branches have now been indexed:
そして NetBSD-current のソースには以下の開発者向け branches がインデックスされた。
Have fun searching and grokking !
レッツパーリィ!
2010-12-19 :-)
_ [oprofile]oprofile
仕事場で処理時間短縮云々という話題があってそこで oprofile の名前が出てきたのでググってみた。
おうちの環境は CentOS5/vmware なんだけどそれはそれで bk があるらしい
普通にパッケージをインストールしてアプリケーションをプロファイルするだけなら --no-vmlinux でいけた。
カーネルも込みでプロファイルするにはカーネルに組み込むか、またはカーネルモジュールを利用する。パッケージをインストールすると漏れなくカーネルモジュールもインストールされるぽい。カーネルビルドする手間が省けた。とりあえず動かしたいのでこれでよし。やったねたえちゃん
2010-12-20 :-)
_ 夜
2000 RR7 EO TA... SYOURYU さんから刺激されたので走ってみたが 30 秒とか無理
2030 RR7 オンラインバトルしようと神出鬼没ルーム入ってみたら逆走常連が居た。蹴ってくれないようなのでそのまま退室しておいた。
2100 月は出ているか
2200 飯。豚肉の生姜焼き
_ 月は出ているか
2010-12-21 :-)
2010-12-22 :-)
_ 33歳なう
ども
_ 夜
1800 ケーキ買う玉川高島屋
1830 鶏肉買う近所の肉屋
1900 コーヒー
2000 RR7 EO TA...もう無理かもしんない
2100 飯。母さん、明日は弁当いらないのだよ
2200 録画しておいた NHK 追跡！AtoZ はやぶさ快挙はなぜ実現したか を見た
2010-12-23 :-)
_ [リッジレーサー7]リッジレーサー7
オンラインバトルなど。ジャクチョーさんルーム入ったら ANGELUS 限定のような空気になっていた。
- 走行距離 97656 km
- RSGP 進行度 100.0 %
- 名声 26017 FP
- オンラインバトル勝利数 1158/4058
_ [NetBSD][翻訳]hubertf's NetBSD blog - Microsoft offers download for NetBSD/eMIPS
マイクロソフトからの NetBSD/eMIPS ダウンロード請け負い申し出
NetBSD has quite a number of mirror sites, but I wasn't aware that Microsoft (yes, THE Microsoft) is also offering NetBSD for download: ``NetBSD for eMIPS - This download contains the ISO CD image for installing NetBSD 4.0.1 on an eMIPS processor system. The download works for the Xilinx XUP board and the Giano simulator.''
NetBSD はたくさんのミラーサイトがあるんだが、まさかマイクロソフト( そう、マイクロソフト だ )までもが NetBSD をダウンロードできるようにしてくれるとは思ってなかった。曰く「 eMIPS 用 NetBSD です。eMIPS プロセッサシステム用の NetBSD 4.0.1 インストール CD イメージをダウンロードできるようにしました。これは Xilinx XUP ボードや Giano シミュレーターで動作するものです。」
A bit dated, but hey! More information about the "extensible MIPS" project is also available on Microsoft's website.
extensible MIPS プロジェクトについての詳細は マイクロソフトのサイト を参照。
Maybe it's time to update my 2005 research WRT NetBSD at Microsoft? (Thanks for the initial hint, Volkmar!)
たぶんこれは 2005 年の research WRT NetBSD at Microsoft 以来の出来事だよね。( ヒントをくれた Volkmar ありがとう! )
_ [NetBSD][翻訳]hubertf's NetBSD blog - Microsoft on NetBSD
Microsoft での NetBSD
Out of pure fun, I searched for "netbsd" at www.microsoft.com. Here are a few gems from the 72 results found:
"netbsd" を www.microsoft.com で検索してみました。72 ヒットしたうちからいくつか面白いものを抜粋:
- Microsoft's Computer Dictionary, Fifth Edition, says for NetBSD: ``A free version of the BSD UNIX operating system developed as a result of a volunteer effort. NetBSD is highly interoperable, runs on many hardware platforms, and is nearly POSIX compliant. See also BSD UNIX, POSIX.''
- Interoperability with Microsoft Windows 2000 Active Directory and Kerberos Services claims to show some config examples tested on NetBSD 1.4 and Solaris 2.7. The examples show extraction of a file "AD.tar.gz", but all they offer are two EXE files, Ad-unix.exe and AD.exe. Huh?!? (Thanks to logix for noticing that "unzip" will work on them!)
- LandMARC Success for Lancaster University: The Contribution of Mobile IPv6 Source Code to Microsoft Windows Server and Windows CE .NET mentions that ``Like most other academic research groups, the Lancaster team traditionally employed Unix--based operating systems--typically NetBSD, FreeBSD or Linux'' (in that order - they don't seem to like Linux :-). The question arises if the listed order of operating systems gives any hints on preference of operating systems inside Microsoft, or even a source of their Mobile IPv6 code?
- gssMonger - Tool for verifying Kerberos authentication interoperability between Windows and other platforms: This one comes with actually usable sourcecode in a real .tar.gz file, and apparently Microsoft cares that software runs on NetBSD: ``Makefiles included to compile on Linux and NetBSD for Cybersafe, Heimdal, and MIT Kerberos.'' (The page is from Sept. 2004)
- マイクロソフト電子辞書第 5 版 では NetBSD のことを「ボランティアによって開発されたフリーの BSD UNIX オペレーティングシステム。NetBSD は高い互換性を持っており、たくさんのプラットフォーム上で動作し、POSIX 準拠である。BSD UNIX と POSIX も参照。」
- Visual Studio .NET 2003 の新機能 には NetBSD IPv6 Networking FAQ へのリンクがある (ノ∀`)
- Microsoft Windows 2000 Active Directory と Kerberos Services の相互運用 には NetBSD 1.4 と Solaris 2.7 でのいくつかの設定例がある。設定例は AD.tar.gz を展開すれば読めて、Ad-unix.exe と AD.exe という 2 つの EXE ファイルにまとまっている。なん...だと...?
- Lancaster 大学での LandMARC 成功例: Microsoft Windows Server と Windows CE への Mobile IPv6 の .NET ソースコード配布 では「他の多くの研究グループと同じように Lancaster チームは NetBSD, FreeBSD, Linux といった Unix ベースのオペレーティングシステムを採用した」とある。まあ彼らは Linux は好きではないようだ :-) 疑問なんだが、ここに挙げられたオペレーティングシステムは Microsoft のオペレーティングシステムや Mobile IPv6 コードの役に立ったんだろか?
- gssMonger - Windows とそれ以外のプラットフォーム間での Kerberos 認証用ツール: どうもこれは実は .tar.gz ファイルになっていて、Microsoft は NetBSD で動かしていたようだ →「 Linux と NetBSD で Cybersafe、 Heimdal、そして MIT Kerberos をコンパイルするための Makefile が含まれている」( 2004年9月のページ )
Before we get dumped into the same bin as M$, let me assure you that (as far as I know) NetBSD is not sponsored in any way by Microsoft. (Not that we couldn't need the money for a lot of things :-)
M$ から同じようにバイナリを取得したけど、ええと、Microsoft はスポンサーになってなかったよね。ということで NetBSD のために 寄附してください ね :-)
2010-12-24 :-)
_ 夜
1900 飯
_ 33歳誕生記念宴会
＠神田某所
miwarin, takumiK, Namiki, Nabeyan
集まってもらった。ありがとな (ノωT)
ここが話題の某所か。日本酒がハイパーうまかった。新酒が飲みやすくて非常にキケン(良い意味で)
2010-12-25 :-)
_ 夜
1700 ケーキ仕込み
1800 飯支度
2000 ローストチキン
2100 ショートケーキ
2200 兄に車貸し出し
2300 area51.gr.jp を名前解決できたりできなかったり違う応答が返ってきたり。イミフ
2010-12-27 :-)
2010-12-28 :-)
_ 夜
1720 アニメイト川崎
1800 飯支度
1900 翻訳
2200 飯
2300 MONOMUSIK on USTREAM: 作曲家浜渦正志の番組を配信します／Masashi Hamauzu on USTREAM.
_ [翻訳][NetBSD][GCC][PCC][コンパイラ]hubertf's NetBSD blog - Article: Competition Among Open Source Compilers
オープンソースコンパイラの競争
Not exactly related to NetBSD, but definitely relevant: David Chisnall's article Competition Among Open Source Compilers talks about some alternatives to the GNU C Compiler (GCC), and why they are of interest to the operating system community (and thus NetBSD, too). Mentioned candidates include TenDRA, the Portable C Compiler (PCC), the Low Level Virtual Machine (LLVM), clang. The summary:
NetBSD 限定ではないのだが、いくらか関連する話題として David Chisnall の オープンソースコンパイラの競争 という記事がある。これは GNU C Compiler (GCC) の代替としてのいくつかの実装と、なぜオペレーティングシステムコミュニティ( もちろん NetBSD も含む )に採用されているのかを話題にしている。TenDRA { TenDRA Compiler - Wikipedia, the free encyclopedia } 、the Portable C Compiler (PCC)、the Low Level Virtual Machine (LLVM)、clang についても触れている。概要はこう:
`Not having to rely on GCC is likely to benefit the BSD family quite a lot. GCC is designed fairly closely with GNU libc in mind, so the project is hesitant to accept improvements that don?t work with glibc (and, by extension, with most Linux systems).
「多くの BSD 系 OS が GCC を利用していると思う。GCC は GNU libc 環境で使われることを前提として設計されているので、glibc が動かない環境での改良には二の足を踏んでいる。( 多くの Linux システムの拡張然り )。
Competition is usually a good thing; in open source projects, where ideas (and, ideally, code) can flow freely between the projects, everybody wins in the end. The more advanced architecture of LLVM makes it a good long-term bet for future systems, and the simple codebase of PCC makes it a good systems compiler. Both are likely to carve out a significant portion of market share in the next few years, giving developers more of choices for compiling their code.''
オープンソースプロジェクトにおいて、競争は普通 良い方向に働く。アイデアとコードはプロジェクト間を自由に行き来できるので、結局はみんなが幸せになれる。LLVM のより進んだアーキテクチャは長い目で見れば将来のシステムに有益であり、シンプルなコードをもとにした PCC は良いシステムコンパイラとなる。これらは今後数年の市場で重要な位置を占め、開発者たちがコードをコンパイルする選択肢はもっと増えるだろう。」
Those interested in trying PCC with pkgsrc can set "PKGSRC_COMPILER=pcc", see Jeremy Reed's blog entry and the the CVS commit log for more information. Also, see (hear :) bsdtalk interview with Anders "Ragge" Magnusson
pkgsrc では "PKGSRC_COMPILER=pcc" とすると PCC を使えるようになる。詳細は Jeremy Reed のブログ記事 や CVS コミットログ を参照。もちろん bsdtalk interview with Anders "Ragge" Magnusson もよろしく :)
_ [GCC][PCC][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > The BSD Issue (1)
オープンソースコンパイラの競争 (1)
Since its creation, the C language has been tightly tied to UNIX. C was designed as a portable assembly language for reimplementing UNIX, to make it easier to port to different platforms.
プログラミング言語 C は UNIX のために作られた。C は、 UNIX を再実装するための可搬性のあるアセンブリ言語であり、これにより異なるプラットフォームへの移植を容易にした。
In 1984, Richard Stallman began the GNU (GNU's Not UNIX) Project to provide a clone of the UNIX operating system using entirely Free Software. Because a C compiler is a core component of any UNIX-like operating system, he wrote one: the GNU C Compiler (GCC).
1984 年 Richard Stallman はフリーソフトウェアのみを使った UNIX オペレーティングシステムのクローンを作るために GNU (GNU's Not UNIX) プロジェクトを開始した。C コンパイラはあらゆる UNIX ライクオペレーティングシステムのコア部分であり、それを GNU C コンパイラ( GCC )と呼んだ。
Over the years, GCC was rewritten a few times, and support for various languages was added. When it began to support more languages than just C, the name was changed to the GNU Compiler Collection, keeping the same GCC abbreviation. As with other parts of the GNU Project, GCC uses the GNU General Public License, although it has a special exception for any parts of the compiler that are embedded in the compiled output.
数年間で GCC は何度か書き直され、いくつかの言語サポートを追加した。もはやサポートする言語は C だけではないので、GNU コンパイラコレクションと名前を変更した。GCC という略称はそのままである。他の GNU プロジェクトと同様に GCC は GNU General Public License を使用する。ただし、GCC で生成された成果物には GPL は適用されない。
The BSD Issue ( BSD の場合 )
Although the GNU Project has GCC, and most proprietary UNIX systems have their own compilers, the BSD projects typically have none. In the base system of any BSD system, GCC is the largest piece of GPL'd code. Over the years, it periodically looked as though TenDRA might replace it. TenDRA, a BSD-licensed C compiler originally started by the Defence Evaluation and Research Agency (the institution that used to be the UK's equivalent of DARPA) focuses on correctness, and would be a good match for systems like OpenBSD, but progress has been slow.
GNU プロジェクトには GCC がある。多くのプロプライエタリな UNIX システムには独自のコンパイラがある。しかし BSD プロジェクトには無い。BSD のベースシステムにおいて、GCC は最大の GPL コード量を占める。TenDRA が数年かけてこれを置き換えた。TenDRA は防衛評価研究局 (DARPA が利用する機関) により始められた 正しく実装することを目標とした BSD ライセンスの C コンパイラである。これは OpenBSD にうまくマッチした。しかし進捗は遅かった。
Recently, another option appeared from an unexpected direction. Back in the 1970s, Stephen Johnson of Bell Labs wrote the Portable C Compiler (PCC). Unlike many earlier compilers, it had a clean separation between the parser and code-generation stages, allowing it to be ported to new architectures easily - a feature present in most newer compilers. This compiler was included with a lot of UNIX variants, including 4.3BSD-Reno.
最近 別の発展を遂げたコンパイラがある。1970 年 ベル研の Stephen Johnson が Portable C Compiler (PCC) を書いた。他の既存のコンパイラと違い、解析部とコード生成部が綺麗に分割されており(最新のコンパイラでも採用されている)、新しいアーキテクチャへの移植が容易だった。PCC は 4.3BSD-Reno を含む多くの UNIX に導入された。
PCC never underwent the same degree of growth as GCC, and remains a very small project. The source code is under 1 megabyte (compressed), and compiling it on a 1 GHz machine takes only a few seconds, whereas compiling GCC on the same machine takes most of an afternoon. PCC isn't as strong in terms of optimization as GCC, but its small size makes it much easier to verify that the output is correct.
PCC は GCC と別の発展を遂げ、いまだにプロジェクトは非常に小さいままである。ソースコードは 1メガバイト以下 (圧縮して) だし、1 GHzのマシンであっても数秒でコンパイルが終わる。それに比べて GCC で同じコードを同じマシンでコンパイルすると、午後が潰れる。PCC は GCC ほど最適化に力を注がない。その代わりにサイズが小さいので、成果物が正しいのか検証が容易だ。
In September 2007, PCC was imported into the OpenBSD source tree, with the aim of evaluating it as a GCC replacement for future releases. A simple compiler is very attractive to the BSD communities - particularly one that's portable. GCC has a habit of changing the interface to the back end, orphaning architectures. This behavior has resulted in some ports of NetBSD, for example, having to stick with old versions of GCC, since no one with the expertise to maintain the compiler port is willing to do so.
2007 年 9 月 PCC は OpenBSD のソースツリーに取り込まれた。将来のリリースで GCC を置き換えるために評価中である。シンプルなコンパイラは BSD コミュニティにとって非常に魅力的である(可搬性があればなおよい)。GCC はマイナーなアーキテクチャにたいしてはインターフェースをよく変更してくれる。NetBSD のいくつかの port ではこの影響を受けた。たとえば、port 用のコンパイラをメンテナンスできるひとが居ないときに古い GCC を持ってなければならなくなる。
It's difficult to overstate the relative complexity of GCC versus PCC. The codebase for GCC is almost 100 times the size of the PCC codebase. The OpenBSD team hopes that this difference in scale will make getting involved with PCC development a lot less daunting than getting involved with GCC.
GCC と PCC についてさらに深く掘り下げることは難しい。GCC のコード量は PCC 100 倍もあるのだ。OpenBSD チームは、このコード量の差異から、GCC を深追いするよりも PCC を開発するほうが楽になってくれることを期待している。
PCC began life on the VAX, and didn't support x86 until very recently. The port took one person less than a week, which makes supporting other architectures seem quite plausible; the total amount of x86-specific code comes to less than 4,000 lines.
PCC は VAX とともに生を受け、最近になるまで x86 をサポートしていなかった。移植はたった 1 人の人間が 1 週間もかからずに完了させた。他のアーキテクチャもすぐにサポートできるようになるだろう。x86 用のコードは 4000 行にも満たなかったのだから。
_ [BSDライセンス][GPL][ライセンス][GCC][LLVM][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > An Advanced Architecture (2)
オープンソースコンパイラの競争 (2)
An Advanced Architecture ( 先端のアーキテクチャ )
The GCC design has gradually evolved since the project's creation, and adopted some more modern design principles. Static single assignment (SSA) was one of the more recent large changes, back in 2005. The principle of SSA is that each variable should hold only one value ever. This rule is enforced in the language in something like Erlang, or in the intermediate form in a C compiler. Consider some C code of the following form:
GCC は作成されてからモダンな設計を取り入れながら徐々に発展してきた。2005 年の Static single assignment (SSA) { 静的単一代入 - Wikipedia } は最近ではかなり大きな変更である。SSA の基本思想は、各変数がたった 1 つの値を持つ、というものである。これは Erlang が似たような規則を採用しており、C コンパイラでは中間状態として使われる。以下のような C コードがあるとする:
a = b; a += c;
This code doesn't conform to the SSA principle, so the compiler would replace it with something like this:
このコードは SSA の規則に当てはまらないので、コンパイラは以下のように置換する:
a1 = b; a2 = c;
All future uses of a would be replaced with references to a2, until the next assignment to a. This form allows a number of optimizations to be accomplished quite easily. Describing it as "new" is somewhat misleading, however; the original paper proposing it was published in 1985. Most modern compilers, including the newer versions of PCC, use some kind of SSA form.
これ以降 a に値が代入されるまで、置換された a2 への参照を使うことになる。これにより、最適化がかなり容易になる。このアイデアは新しいように見えるが、じつは最初の論文は 1985 年に書かれている。新しいバージョンの PCC を含み、モダンなコンパイラはほとんど SSA を利用している。
While GCC has accreted design components, another compiler was written from scratch based on the latest ideas in compiler research. The Low Level Virtual Machine (LLVM) is designed to focus heavily on optimization. Like Java and .NET, it uses a virtual machine to define an intermediate form; however (as the name suggests), this machine is quite low-level, and not tied to any particular language.
GCC が巨大化していく一方で、他のコンパイラは最新のコンパイラ研究にもとづいて 1 から書かれた。Low Level Virtual Machine (LLVM) は最適化を重要視して設計された。Java や .NET のように仮想マシンを内部に持つ。しかし (名前から分かるように) LLVM は低レベルすぎて他の言語には使いづらい。
Originally, LLVM used code taken from GCC to handle parsing. This approach changed slightly with release 2.1 in September 2007. A new, Apple-developed front end was introduced, with support for C, C++, and Objective-C, under the name clang.
もともと LLVM は、解析するために GCC からコードを受け取っていた。このアプローチは 2007 年 9 月の release 2.1 で多少変更された。C、C++、そしてObjective-C をサポートするアップルの開発用フロントエンド clang に取り込まれた。
Part of the motivation for developing clang came from a criticism often leveled at GCC: that it's difficult to separate out the front-end and back-end code. When you edit code in something like Microsoft's Visual Studio, you can use the same code for parsing the code to generate syntax-highlighting information as you use for code generation. The same is true of most LISP and Smalltalk environments. This isn't the case with something like Apple's Xcode, however, which has to implement its own parser for syntax highlighting and code completion. This setup is less than ideal for developers, because parsing errors in the IDE don't necessarily correspond to code that won't compile, and vice versa.
clang を開発するモチベーションの一部は GCC への「フロントエンドとバックエンドを分離しづらい」という批判から来ている。Microsoft の Visual Studio でコードを書くとき、コードが解析され、シンタックスハイライトにより、まるであなたがコードを書いたように見えるだろう。これは LISP や Smalltalk 環境とまったく同じである。アップルの Xcode は多少違う点があるが、Xcode 独自の解析部によりシンタックスハイライトが機能し、コードを補完する。これにより、IDE で解析エラーになるので、いちいちコンパイルする手間が省け、開発者の負担が減る。コンパイラの負担も減るのである。
Extracting the front end from GCC for this purpose is difficult for two reasons. First, GCC is released under the GNU General Public License, which means that any other program built using it is required to be under the same license. Second, GCC intentionally ties the front and back ends into the rest of the code quite closely, to avoid "semi-proprietary" forks. In contrast, LLVM is BSD-licensed and has comparatively clean separation between the various layers.
GCC からフロントエンドを分離することは、2 つの理由により難しい。1 つは、GCC の最初のリリースが GNU General Public License に基づいており、GCC でビルドだれたプログラムを使うためには同じライセンスを適用しなければならないということ。{ ????? } 2 つめは、フロントエンドとバックエンドが密結合しており、準プロプライエタリとして派生させて使えないということ。対照的に、LLVM は BSD ライセンスで、いくつかの層{ フロントエンドとバックエンドのことか ? }は比較的綺麗に分離されている。
_ [VM][仮想マシン][LLVM][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > A Low-Level Virtual Machine? (3)
オープンソースコンパイラの競争 (3)
A Low-Level Virtual Machine? ( LLVM って? )
The concept of something that is both "low-level" and a "virtual machine" (VM) is slightly strange. Most virtual machines are either very abstract or consist of only very thin abstraction layers. Perhaps the lowest-level virtual machine is Xen, which has the same non-privileged instructions as x86, but different privileged ones.
「低レベル」と「仮想マシン(VM)」のコンセプトは多少違う。ほとんどの仮想マシンは、高度に抽象化されているか、または高度に抽象化された層を持っている。おそらく最も低レベルな仮想マシンは Xen で、Xen は 1 つの特権命令と x86 と同じ非特権命令を持っている。
At the opposite extreme is something like the Java virtual machine. Java bytecode runs on a virtual-stack-based machine (all of the real stack-based machines except x87 having died out a long time ago). This is very different from any real machine, although it has some passing similarities to old LISP machines. The Java VM makes a number of assumptions about the code running on it, making it difficult to run anything that's not a strongly typed language with a Java-esque system.
Java 仮想マシンとまったく違う点である。Java バイトコードは virtual-stack-based で走る ( x87 以外の real stack-based machines はだいぶ前に滅びた )。これは実際のマシンとは大きく異なる。むしろ昔の LISP マシンをシミュレートしていることに近い。Java VM は、Java-esque システムであればどのような言語でも走らせることを可能にするための基盤である。
The abstract machine presented by LLVM is somewhere between the two. It's close to an unlimited register machine (URM), which is a fairly common theoretical model for computing. A few things mark it as being different from a real computer:
LLVM による抽象マシンは 2 つ異なる点がある。レジスタマシン ( unlimited register machine (URM) ) に閉じたものであり、これは理論計算機のモデルである。{ ?????????? } 実際のコンピュータと異なる点をいくつか挙げる:
- Each register is typed. In most computers, registers are typed to the extent that they are integer or floating-point quantities, but the LLVM type system goes far beyond this level.
- Each register is single-assignment. As discussed earlier, this form makes it much easier to perform a number of classes of optimization.
- 型付けされたレジスタ: ほとんどのコンピュータは、レジスタは整数か浮動小数点の幅を持った型になっている。LLVM ではこのレベルを超えている { ?????? }
- レジスタは 1 つの値を持つ: 先にも書いたが、これにより最適化が容易になる
Compiling with LLVM is a two-stage process:
LLVM の 2 ステージプロセスでのコンパイル
1. The first step is to compile a program from source code to bytecode for the abstract machine. For some languages, this process may be two steps, going via a language-specific bytecode. After this, there are a few options.
1. 最初のステップでは、抽象マシン向けにソースコードをバイトコードへコンパイルする。いくつかの言語では language-specific バイトコードを生成するために 2 ステップかかるだろう。この処理のあといくつかオプション処理があったりする。
2. The LLVM bytecode can be interpreted directly. This is nice for debugging, since the entire state of the machine can be inspected, and none of the type information has yet been lost.
2. LLVM バイトコードはダイレクト割り込み可能である。これはデバッグ時に嬉しい。マシン全体の状態を調査でき、型情報をまったく損なわない。
The bytecode also can be compiled to native code, either as a single-step operation or as part of a profiling-directed optimization pass. This arrangement allows the optimizer to examine the runtime behavior of the code and compile it on the fly. Alternatively, of course, it can be distributed in bytecode form, which is hardware-agnostic, and then compiled at install time, or JIT-compiled as it runs with the additional profiling information.
バイトコードはネイティブコードとしてもコンパイルできる。1 ステップでプロファイルと最適化がおこなわれる。これにより最適部がコードを実行しながら評価したり、じかにコンパイルできる。{ ???????? } もちろん ハードウェア依存のバイトコードとしても配布できるし、インストール時にコンパイルしたり、{ ?????? } JIT コンパイルすればプロファイル情報を付加することもできる。
_ [GCC][翻訳][コンパイラ]InformIT: Competition Among Open Source Compilers > The End of GCC?
オープンソースコンパイラの競争 (4)
The End of GCC? ( GCC の終焉? )
Before predicting the end of GCC, it's important to understand the role it fills. One big reason for using GCC is that it's portable. You can use the same compiler on a wide collection of operating systems and architectures. GCC isn't bad at optimization, either, although less-portable compilers tend to do better on the specific platforms they target. Having to support only a single compiler can reduce development costs, however.
GCC の終焉を語る前に、1 つ役割を理解しておくことが重要だ。GCC を使う大きな理由として、可搬性がある。GCC は、幅広いオペレーティングシステムとアーキテクチャ上で利用できる。GCC の最適化は、可搬性に欠けたプラットフォーム上のコンパイラと比較しても悪くない。それに 1 つのコンパイラだけを使うことにより開発のコストを下げることができる。
The main reason that GCC exists is to be Free Software. The GNU Project requires a compiler that's capable of building the GNU system. Both of the compilers I've discussed in this article are Free Software, but they're available under the permissive terms of BSD-style licenses. This fact makes them less attractive to the Free Software Foundation, because these licenses permit making proprietary forks.
GCC のおもな存在意義は、フリーソフトウェアであるということだ。GNU プロジェクトは GNU システムをビルドするために有能なコンパイラを求めている。私がここで言っているコンパイラはどれもフリーソフトウェアだが、寛容な BSD ライセンスである。これらのライセンスはプロプライエタリなものを生成できるので、はフリーソフトウェア財団からはあまり宜しく思われていない。
While the Free Software Foundation is nominally in charge of GCC, a lot of development is funded by the likes of Apple and Red Hat. Making a closed-source fork of the compiler is not in the best interest of either of these companies, since they don't sell compilers - they give them away, to encourage people to write software for their platforms. (Red Hat also gives the rest of the platform away, to encourage people to pay for Red Hat support.) Apple, on the other hand, would very much like to be able to use components of the compiler combined with other, proprietary components. This desire is what attracted Apple to LLVM as a compiler for OpenGL shaders (code which is now making its way into the open source OpenGL clone Mesa), and led do development of the clang front end for LLVM.
フリーソフトウェア財団は建前上は GCC を担当しているが、実際にはアップルやレッドハットよって大部分が開発されている。これらの会社はコンパイラを売っていないので、クローズドソースなコンパイラを作ることはこれらの会社からはよく思われない。彼らのプラットフォームでコードを書くように仕向けているのだ{ ?????? }。( レッドハットはプラットフォーム以外でコートを書く場合は Red Hat にサポート料金を支払わせるようにしている )。他方、アップルは、GCC のコンポーネントとプロプライエタリなコンパイラコンポーネントをうまく組み合わせられるようにしている。これによりアップルは、 OpenGL シェイダーコンパイラのために LLVM を作った ( このコードはオープンソースとして、OpenGL クローンの Mesa になった )。LLVM のフロントエンド clang の開発を引率するようになった。
Another strength of GCC is the languages it supports. With GCC, you can compile C, C++, Objective-C, Fortran, Java, and Ada. It also has some support for Pascal, Mercury, COBOL, Modula-2, Modula-3 VHDL, PL/1, and UPC. In contrast, PCC supports only C, with experimental support for Fortran. LLVM supports C and C++, with experimental support for Objective-C and Stacker (a stack-based language).
他にも GCC の強みとして言語サポートがある。GCC を使えば C, C++, Objective-C, Fortran, Java, そしえｔ Ada をコンパイルできる。また、Pascal, Mercury, COBOL, Modula-2, Modula-3 VHDL, PL/1, そして UPC もいくらかサポートしている。対称的に PCC のサポートは C のみだ。Fortran サポートはまだ実験的である。LLVM は C、C++、そして実験的であるが Objective-C と Stacker ( スタックベースの言語 ) をサポートしている。
From my perspective, one of the most interesting things about GCC at the moment is that it's the only Objective-C compiler that works with either Apple's Cocoa or GNUstep. This situation is likely to change soon, as the clang front end becomes more mature, which is likely to benefit all Objective-C developers as a result of competition between the projects.
個人的には、GCC のもっとも面白いのは、アップルの Cocoa か GNUstep では Objective-C をサポートしているのが GCC のみであるとうことだ。clang フロントエンドが熟せばこの状況は変わるだろう。Objective-C 開発者たちにとってプロジェクト間の競争となり、よい結果をもたらすだろう。
Not having to rely on GCC is likely to benefit the BSD family quite a lot. GCC is designed fairly closely with GNU libc in mind, so the project is hesitant to accept improvements that don't work with glibc (and, by extension, with most Linux systems).
多くの BSD 系 OS が GCC を利用していると思う。GCC は GNU libc 環境で使われることを前提として設計されているので、glibc が動かない環境での改良には二の足を踏んでいる。( 多くの Linux システムの拡張然り )。
Competition is usually a good thing; in open source projects, where ideas (and, ideally, code) can flow freely between the projects, everybody wins in the end. The more advanced architecture of LLVM makes it a good long-term bet for future systems, and the simple codebase of PCC makes it a good systems compiler. Both are likely to carve out a significant portion of market share in the next few years, giving developers more of choices for compiling their code.
オープンソースプロジェクトにおいて、競争は普通 良い方向に働く。アイデアとコードはプロジェクト間を自由に行き来できるので、結局はみんなが幸せになれる。LLVM のより進んだアーキテクチャは長い目で見れば将来のシステムに有益であり、シンプルなコードをもとにした PCC は良いシステムコンパイラとなる。これらは今後数年の市場で重要な位置を占め、開発者たちがコードをコンパイルする選択肢はもっと増えるだろう。」
2010-12-29 :-)
_ 午後
1200 買い物。「0830 ～ 1300 まで生コン流しこみ作業します」とあったので「じゃあ 1300 まで作業してそれから撤収するから作業車が居なくなるのは 1400 といったところか」と思ったら 1230 には撤収していた。はや
1400 部屋片付け
1500 コーヒー
1600 パプリカを見る
_ コミケ 1 日目
行かない
2010-12-30 :-)
_ 夜
1700 模擬試験
1800 飯支度
1900 アニメ見る
2000 GT5 プレイしようとたら 1.0.5 あたりのアップデートが入り結局未プレイ
2100 飯。グラタン
2200 明日の準備
_ 買い物
＠文教堂 溝の口
コミケのために小銭を作るつもりがガッツリ買ってしまった。
4047264881
4047267260
4086305399
4086305798
4044748217
4044748276
4840135894
4840134871
2010-12-31 :-)
_ 午前
0600 起床
0750 国際展示場
0820 Namiki たちと合流。サークル手伝い。西駐車場へ行くのに手間どいスタッフに道を尋ねるなど。そういえば @emi_kun はスタッフだったか
1000 コミックマーケット 3 日目開始
_ 午後
1300 おひる。寒かったので国際展示場すぐそばのベローチェに入ってみたら意外とさくさく回転していた。店に入ったら従業員から「45 分で退店するでゲソ」などといったことを聞かされた。
1400 サークルで留守番するなど。オーガスト は FORTUNE ARTERIAL (※ただしアニメのほう )以外のネタが分からんのが弱い。なお 副会長 はサクっと売り切れたらしい。さすが
1600 コミックマーケット 3 日目終了。お疲れさまでした。
_ 2010自分が好きだった音楽ランキングベスト10
( via キノさんとこ )
例によって last.fm のチャートから 過去 12 ヶ月のトラック からキャプチャ。あいかわらず RR7 のアレを通勤中はほぼ毎日聴いてるのでこうなる。
B000NA6PEC
_ 大晦日
よいお年を
_ ちくわGTきつね野郎 [スカイプやってたんですか 惜しいことしちゃったぜー 乱入させてもらえばよかったorz]
_ みわ [だからもっと積極的に絡めと]