2014/5/25 作成
http://www.haiku-os.org/ より、An extensive interview with Haiku developer - Paweł Dziepak の私訳です。訳のおかしいところは、原文を参照ください。

Haiku 開発者との広範囲なインタビュー - Paweł Dziepak

私はポーランド語 Haiku IRC チャンネル (#haiku-pl、Freenode) 上で、私的な会話中に Paweł Dziepak にインタビューしました。私たちは、2014 年 4 月 28、29 日の 2 晩の間話し合いました。Paweł は、pdziepak としてコミュニティーに知られています。Haiku プロジェクトに関わっている多くの卓越した人々がいます。その誰でも、インタビューする価値があり、私は今後インタビューを行うつもりです (Ingo、Axel、Stephan、注意!)。なぜ今回は pdziepak なのか? コミュニケーションの容易さが、その決定における重要な役割です、私たちは同国民なので、IRC チャンネル上で互いによく話します。彼は優れたプログラマーであるだけでなく、ビジョンを持ったエンジニアです! 若いのにもかかわらず、彼はモバイルアプリには興味がありません。彼の興味あるフィールドは、カーネルアーキテクチャーです。あいにく、彼は現在の写真を持っていませんでした。そして、私が自分撮りかエレベータ中でスマートな写真を撮ることを彼に提案した時、No と言いました。

私たちは、Haiku プロジェクトとコミュニティーの状況に関する深く、率直な会話をしました。同様に、私は一般的なオープンソース運動に関して彼に尋ねました。その一部を、以下に示します。

Premislaus: こんにちは、Paweł! いつもの質問で始めましょう: 少しあなた自身に関して書いてください。名前、出身、年齢、どこで何を学んでいますか?

Premislaus: Haiku プロジェクトをどうやって見つけましたか? 第一印象はどうでしたか?

pdziepak: 私は、最初にプロジェクトに関して知ったときを本当に思い出せません。しかし、代替オペレーティングシステムを探して Wikipedia をブラウズした時が間違いなくそうだったと思います。その後しばらくして、私は、参加できるオープンソースプロジェクトを探していました。しかし、正直に言って、古い BeOS との互換性の維持がプロジェクトの主なゴールの 1 つである事実は、私を脅して追い払いました。かなり後で、私は、カーネルの非常に近くで作業できるプロジェクトで、GSoC に参加することに決めました。そのとき、Haiku は、NFSv4 クライアントの実装提案とともに、再浮上しました。それはとても興味深いものでした。当時、Haiku は C++ で書かれた唯一の大きなカーネルでした (私はそのような発言にリスクを負います)。そして、GCC2 および BeOS 互換性の全部がまったく怖くないことがわかりました。私はそのユーザーインターフェースも好きでした。私はシンプルなのが好きです。したがって、'90 年代末風の外観は私にとってはむしろ好都合です。

Premislaus: おや? その前に BeOS について聞いたことはありましたか? もしかすると使っていましたか? BeOS は、少数の面白いソリューションを持っていました。例として、ファイルシステムでの属性サポート、データベースとの共通点、ファイル識別用の MIME 形式、マルチスレッディングおよびソフトリアルタイムを念頭に置いた設計です。おおむね、Haiku は今これらのすべてを備えています。

pdziepak: 私は、主なモチベーションが Haiku より NFSv4 だったことを認めざるを得ません。その当時は、プロジェクトに長くとどまるかどうかは考えていませんでした。BeOS に関する私の知識は、それがかつて存在していたことを知っていた事実に限定されていました。BeOS のソリューションについては、NFSv4 クライアントを実装しようとする際、属性がとても厄介です。つい最近、Stephan の支援と、Ingo の提案で、私は、NFSv4 で属性が動作できる方法を見つけだしました。しかし、完全な実装を書く時間がまだありませんでした。

Premislaus: 私たちにそれに関してもっと何か教えていただけませんか? なぜ Haiku の属性はこの多くの問題を引き起こすのか? 私は、ポーランド語 Haiku IRC チャンネルにあなたが書いたことを思い出します。属性に関してほかの OS が構わないこと、そして、NFSv4 のある次のバージョンまで属性は完全にサポートされないでしょうか?

pdziepak: 残念ながら、その問題は、まさに BeOS および Haiku だけがそのような拡張方法でファイル属性を実装するという事実にあります。結果的にすべてのプロトコルは、属性を適切に実装することを非常に困難にするこの状況を無視します。NFSv4 はといえば、実際それは、"名前つき属性" と呼ばれるものを導入しました。しかし、それに関する 2 つの問題があります。第 1 に、それは私たちが必要とすることにまだ達していません。なぜなら、BFS 属性とは対照的に、"名前つき属性" には型がないからです。第 2 の問題はさらに重大です。"名前つき属性" のサポートはオプションであり、Linux NFSv4 サーバー (それはおそらくもっともポピュラーなものです) は、これを実装していません。

Premislaus: 属性は、Haiku ユーザーにとってなぜそれほど重要でしょうか? 私は、好きなようにビデオライブラリーを並び替えられ、たとえば好きな作家によってムービーを検索できるという事実が好きです。私たちは、People アプリケーションで、コンタクト情報をすばやく追加できます。また、それらのデータはすべて空ファイルの属性として保存されます。さらにパワーユーザーは、自分用の検索式を書くことができます。何万もの電子メールを持っている場合、それが手軽になる場合があります。これをどう思いますか? ほかの OS に同様の機能がありますか? あるいは、もしかすると、よりよいものがありますか?

pdziepak: 確かに、属性は非常に便利でエレガントなソリューションです。しかし、それが適切に作動するために、ファイルを扱うものはすべて属性をサポートする必要があります。たとえば、ファイルシステム、ファイルアーカイブフォーマット (tar、zip、itp)、データ伝送プロトコル (HTTP、FTP、NFS など) です。途中で何かが属性を失うと、それは厄介ごとになり始めます。しかしながら、ある場合には、ファイル属性より自然なソリューションを想像するのは難しいことであり、属性を実装しない世界に属していると、エレガントではないが、より現実的な解決案を考えだす必要がありました。つまり、ファイル自体に属性データを組み込むことです。これが、音楽 (ID3) およびイメージ (EXIF) ファイル中のタグの動作する方法です。

Premislaus: それは本当です。Windows は何度も、私が Haiku で作成したファイル (ほとんどテキストおよびイメージ) を自動的に認識しませんでした。幸運にも、zip アーカイブは属性を適切に格納します。Haiku には、ArmyKnife があります。それはわずかなクリックで、タグを属性に変換します。私が属性に関して好きなほかのことは、ファイルのオリジナルのダウンロード場所の表示です (もし可能になれば)。私は今あなたに尋ねたい、ほかのどの技術を Haiku 中に実装してきましたか? 何を改善しましたか? Haiku 開発で、あなたの興味のあるフィールドは何ですか?

pdziepak: 私の関心分野は広く定義されたカーネル開発です。2013 年の春に、私は、ASLR および DEP を実装しました。そのことは、隠れていたバグの "活性化" により小さな混乱を引き起こしました。しかし、私は、全体として、それは Haiku にとってうまくいったと思います。後で、私は、RTM (Restricted Transactional Memory) ビットをいじりました、それは、Haswell に導入された新しい拡張ですが、使用可能になる前に、コードは多くの作業を必要とするでしょう。10 月から 1 月中旬まで、私は Haiku Inc. に雇われて、スケジューラーへの取り組みと、Haiku の 2 つ以上の論理プロセッサーを備えたシステムへの適用をしていました。とりわけ、私は 8 プロセッサーの限界を取り除きました。それは、BeOS から継承した ABI にとても固く結びついていました。API の変更、および ABI への新しい要素の導入は、さらにある混乱を引き起こしました。しかし、それは避けられませんでした。

Premislaus: あなたのスケジューラーの特徴は何ですか? 以前のものとの違いは? それは、ほかの OS とどのように比較しますか? 主なアイデアはなんでしょうか?

pdziepak: まず、新しいスケジューラーは、以前のようなグローバルな 1 つのスレッドの代わりに、各コアに対して個別のスレッドキューを持っています。これは、キャッシュの利用率を改善し、プロセッサーが互いにより干渉しないようにしますが、円滑なオペレーションのために、優れた負荷分散アルゴリズムを要求します。私はこれを達成するために、あるスレッドが、まるでそれがシステム中でただ 1 つのスレッドであったときのように消費する CPU 時間を推測することに決めました。この情報に基づいて、スケジューラーは、コアにスレッドを割り付ける方法、およびほかのコアにスレッドをいつ移動するかを決定します。これらの決定も、スケジューラーの動作モードによって影響を受けます。システムの性能がもっとも重要な場合、すべての利用可能な論理プロセッサーを利用します。エネルギー消費を削減したければ、できるだけ有効なコアの数を制限すればよいでしょう。特定のコア上のスレッドの時間に関して、このソリューションはありふれた一定時間優先度つきキューを利用します。適切なヒューリスティックスが、あまりにも多くの CPU 時間を消費するスレッドは低い優先度であることを保証します。

Premislaus: GSoC、および請負 (contract) 上でのあなたの協力はどんなものだったか教えてくれますか? Haiku, Inc. やほかの開発者達とあなたの関係はよかったですか? 面白い、または不愉快な状況が生じましたか?

pdziepak: GSoC と請負 (contract) のどちらも、私は課題に取り組むただ 1 人の開発者でした。したがって、協力は、ある変更に関する議論、あるいは API 変更の場合、変更の提案に制限されていました。概して、作業の雰囲気はよかったし、私は何も不満はありません。

Premislaus: 私は Haiku のプロモーションおよび試験に多くのエネルギー、時間、および神経を注いでいるので、次の質問は私にとって非常に難しいです。私は、オープンソースの主な原理が透明性であると信じます。私は企業の営業部ではないので、欠点を隠したくありません。"それはすばらしい!" Haiku プロジェクトでの意志決定プロセス、コミュニケーションおよび管理をどのように評価するでしょうか。すべてがゆっくり起こるのは秘密ではありません。つまり、パッチの追加、意思決定です。ここ数年間進行中の多くのバグがあります。私たちは、HaikuDepot の翻訳が機能していないと報告しました。1 つのパス変更は必要です。2 週間後、そのバグはまだ進行中です! 一般に、Haiku 開発者はコミュニティーに信頼されています。毎年、私たちはより多くのお金を持っています。また、私たちは新しい R1 マイルストーン (スケジューラー、パッケージマネージャー、HTML5 など) に達します。しかし、現在の資源をよりよく管理できるでしょうか? Haiku プロジェクトには持続的で、裕福なスポンサーがいません、私たちはそれに自由時間と貯金をささげます。それにもかかわらず、時々、私は、すべてが慣性によって起こると思います。誰かが IRC に、"パッチ歓迎"、"パッチ求む!"、"そうだね、私たちのワークフローは改善できたかもしれません" と書くのを見るたびに、私は通りに出て、人々を撃ち始めたくなります。そのため、私は、メーリングリストで議論を始めて、ユニットテスト作成のための新しい請負 (contract) と、パッチレビューアプローチへの取り組みの変更を提案しました。どのようにそれを見ますか? 新しい開発者が加わるためのしきい値はあまりに高くありませんか?

pdziepak: 遅いペースは容易に説明できます。フルタイムで雇用される開発者がほとんどいないのです。Haiku が完全なオペレーティングシステムであることを理解する必要があります。また、ほかのソリューションでは、いくつかのコンポーネントは独立した大型プロジェクトですが、ここでは、それらは Haiku の一部だけです。私たちは、"独自の Linux"、"独自の glibc"、"独自の Qt"、"独自の KDE" および多くのものを持っています。ワークフローに関して、私たちが "何かよいもの" についての異なる理解を持っていると私は思いますが、あなたが始めた議論が良いものに結びつくことを望みましょう。まず、私は、新しい開発者のためのしきい値は高すぎるとは思いません、その作業が絶えず修正されなければならない人にリポジトリへのアクセス権を与えても意味がありません。私たちの問題は、喜んで貢献するわずかな人々であり、私たちが何らかの形で追い払った潜在的な開発者ではないと言ってよいでしょう。さらに、私は、Haiku に変更を加えることは、"より困難" であるべきと信じます。特にコミット権のある人々にとっては。誰も完全ではありません。また、ほかの開発者による各パッチのレビューは確かにコード品質をよくするでしょう。残念ながら、再び、開発者がプロジェクトに費やすことができる時間の問題があります。パッチレビューが十分に効率的にならなければ、そのようなワークフローは働かず、有害無益となるでしょう。

Premislaus: "Worse is better" ルールについてはどうですか? Haiku は、"The MIT Approach" をとっています。個人的に、私は、後の理論のほうがははるかによいと思います。緩慢はこのアプローチの代償ですか? 一見、BSD ファミリーは Linux より開発が遅いです。

pdziepak: その問題を分析した後、決定は個々に下されるに違いありません。任意のルール (この 1 つを含む) に盲目的にしがみつくことは好結果をもたらさないでしょう。もちろん、通常シンプルな解決策の方が、実装効率およびインターフェースの "エレガントさ" の両方の点から優れています。しかしながら、しばらくした後、そのような単純な解決策がもはや十分でなく、互換性を維持する必要のために、その改善がささいなことでなくなる場合、問題が生じます。

Premislaus: GCC2 はどうしたものですか? BeOS バイナリ互換性はどれだけ負担になりますか? 多くの人々が、参照 (BeOS) があるので、私たちが OS およびアプリケーションの振る舞いをテストできると主張します。本来なら、これはユニットテストによって達成されるものです。私は、R1 のこの主な目標が、12 年前に決定されたことを知っています。それまでに多くのものが変更されました。私は、今後 BeOS 互換の必要がないと思います。

pdziepak: 一般に、多かれ少なかれ GCC2 は負担です。しかし、プロジェクトの目標の 1 つは BeOS ABI 互換性を維持することです。また、その変更はそんな単純なことではありません。一方、それは、プロジェクトが混乱するのを防ぎます (これに関して GCC2 がどのように手助けになるか確信はもてませんが)。他方では、いくつかのプロジェクトは、不必要であることがわかる可能性があります。GCC は様々なレベルで発展しますが、非常にいらいらすることは、C++03 サポートが不足していることです。GCC4は、現在では不可欠な多くのより優れた最適化を行います。さらに、GCC4 は、新しい CPU 上でよりよく実行するコードを生成します。もちろん、Haiku ビルドは Pentium Pro (それがなぜかは私に尋ねないでください) 上で動かないといけません。しかし、GCC4 はより新しいマイクロアーキテクチャーを利用するコードを生成できますが、新しい命令を使用しない、古い CPU の上で走るコードも生成できます。

Premislaus: あなたの Haiku 開発計画はどういうものでしょうか?

pdziepak: 私は、自分の考えは何かが単に言えるだけです。それらの結果は、私が Haiku にどれだけの時間専念できるかに依存します。まず、私が既に始めた 2 つのこと、NFSv4 クライアント中での属性サポート、およびインテル TSX 拡張サポート (私が以前に言及した RTM を含む) を片付けるのがよさそうでしょう。さらに、私は VirtIO ドライバーに関して考えました。それは、KVM 中で実行するときに、Haiku をより早く動作させるでしょう。汎用の VirtIO インフラストラクチャーは既に構成されています。さらに、私たちは、ちょっとしたネットワークカードドライバーを持っています。また、それを動作させることはやや容易でしょう。別の面白いデバイスは virtio-balloon です。それは、ホストとゲストの間のメモリ交換を許可します。しかし、私は、どれだけの仕事量が必要かをチェックしませんでした。

Premislaus: Haiku の長所であると思うことについて、簡潔に説明していただけませんか?

pdziepak: 第一に、ユーザーインターフェースおよびシステム全体の使いやすさです。Haiku は、反応を良くすべきことを多く必要としません。それは、Haiku が作る印象をほとんど定義します。さらに、Haiku には明瞭なゴールの無いプロジェクトで生じる問題がありません、そしてて、すべての使用事例でよい状態であろうとしています。それは通常うまくいかないことです。

Premislaus: また、短所は何でしょうか?

pdziepak: ベンチマーク結果、コンパイル時間および他のパフォーマンス的なタスクの比較は、かなり悪いです。Adrien の請負 (contract) の前は、WebPositive は、明確に潜在的ユーザーを引きつけなかった残念な光景でした。しかし、大きな進捗があったので、懸案事項はより少なくなりました。

Premislaus: 開発者の視点から、Haiku は Linux、BSD、Windows および OS X とどのように異なりますか?

pdziepak: Haiku は POSIX を実装します。したがって、Unix プログラマーはいくつかの類似性を見つけるでしょう。私たちには、Perl、Ruby、および Python のような移植された高水準言語があるので、ここではどちらも大きな違いはありません。しかし、GUI および C++ で書かれた高レベル API (Kit) となると、それは Qt と比べて異なるソリューションであり、それを学習するためにある程度の時間を費やす必要があります。カーネルに関しては、C と C++ の混在です。不運にも、GCC2 のために、私たちは C++03 と C++11 を使用できません。もちろん、ユーザーモードアプリケーションを開発する場合も、使用できません。

Premislaus: あなたの考えでは、Haiku カーネル中の主なボトルネックは何でしょうか?

pdziepak: 現在のカーネルは、特に、2 つ以上の論理プロセッサー (現在、ほとんどの場合そうです) を扱っている場合は、パフォーマンスを改善するため、多かれ少なかれさまざまな進んだ技術を使っています。たとえば、RCU、特定の CPU へのオブジェクトの賢い割り付け、小さなオブジェクトを保護するための mutex、ロックフリーかつウエイトフリーなアルゴリズムです。Haiku カーネルはその問題について多くを行っていません、そのため、スケーラビリティが極めて不十分です。

Premislaus: できれば、Haiku カーネルをほかのものに取り替えていただけませんか? あるいは、現在のカーネル開発はよりよい考えであると思いますか?

pdziepak: 実際に、私は Haiku が Linux を使用していればよかったと思っていました。10 年以上前は、新しいカーネルを 0 から書くという決定はおそらく正しいものでしたが、その時以来多くが変わりました。もちろん、"外部の" Haiku カーネルの使用は多くの作業を必要とするでしょう。しかし、独自カーネルを競合と同等に維持することはさらに多くの作業を要求します。

Premislaus: Haiku ソースコードの状態をどのように評価するでしょうか? 何か完全な書き直しを必要としますか?

pdziepak: 私はカーネルに関してのみ話すことができます。私が以前に言及したように、私たちは、スケーラビリティを改善するためにより賢い技術を必要とします。これは、次にはほとんどカーネルサブシステム中で、メジャーまたはマイナーチェンジ (やや前者より) を要求します。0 から書き直すことについては、それは必要ではないと思います。よりよいオプションは進化です、ただし、それがいきなりで速いものであればですが。

Premislaus: あなたの意見では、Haiku の長期見通しはどういうものですか?

pdziepak: パッケージマネージャー、および WebPositive の改善により、今やシステムは以前よりずっと日常使用に適したものになっています。私は、すぐに、ナイトリービルドより公式な何かをリリースすることを望みます。長期的な開発に関しては、Adrien がどれくらいの時間 WebPositive について作業できるかということと、ほかの請負 (contract) を始めることが可能かどうかに大きく依存します。Haiku には、忠実なファンのグループがあります。しかし、結果に目立つ進展がないと、彼らは到着するのではなく、減少するでしょう。

Premislaus: なぜ Haiku は支援する価値があるのですか?

pdziepak: 私は単に技術的なやつです、PR はひとつ上の階です。

Premislaus: OK、しかし、なぜあなたはサポートするのですか?

pdziepak: 最初は、Windows、*BSD あるいは Linux ディストリビューションのような主流解決策とは異なったシステムを学習したいという気持ちがほとんどでした。今は、私の視点では、Haiku は "異なって" いません。その主な理由は様々なエリアで、多くのやるべきのことがあるという事実です。私が何に興味を持っているか次第で、(不運にも) 大きな機会があります。それは、Haiku が持っていないか、著しく改善できることです。そのようにして、私は ASLR、DEP および RTM に取り組み始めました。これは、以前に言及したように、欠けている VirtIO ドライバーのうちのいくつかの実証を検討する理由でもあります。

Premislaus: コンピューターに Haiku をインストールして使っていますか?

pdziepak: はい。私は古い Eee PC に Haiku をインストールしています。Windows XP 以外で、Haiku はそのマシンでスムーズに動作するただ 1 つの OS です。

Premislaus: Haiku を開発するために使用する主なオペレーティングシステム、ツールおよびハードウェアは何ですか?

pdziepak: 私は、外部ディスプレイ、キーボード、スピーカー、Ethernet などを備えた "デスクトップノート" を使っています。それには、(Red Hats への感傷のため) Fedora をインストールしています。加えて、私は、Haiku および、私が作業しているほかのプロジェクトを構築するのに使うデスクトップコンピュータを 1 台持っています。私はその上に OpenGrok と buildbot をインストールしています。それらは、私のコミットがメインリポジトリへ移動する前に、何かを壊すかどうかをチェックするのに使います。そのコンピューターは現在 Debian Jessie を走らせています。ツールに関して、gedit はずっと前から私の主なエディターです。私は IDE を使っていません。もちろん、私は git を使用します。また、gitk 以外の "ブースター" は使っていません。

Premislaus: 何が Haiku に欠けていると感じますか? 重要なアプリケーションで利用できないのはどれでしょうか?

pdziepak: まず、ハードウェア仮想化のサポート。さらに、Wireshark と OpenCL が無いのは少し問題です。

Premislaus: Haiku パッケージマネージャーは、Linux のソリューションと比べてどうですか。

pdziepak: それは非常に異なるものです。それは、明確に単純ではありません、それにもかかわらず、私は、それは非常にエレガントであることがわかります。たとえば、その設計方法により、パッケージは NAS 上に格納できます。また、個別の Haiku インストールは互いに干渉することなくパッケージにアクセスできます。これは、ソフトウェアの更新に必要な、ストレージのスペースと所要時間の両方を節約します。

Premislaus: 主にウェブをブラウズするためにコンピューターを使用し、古いハードウェア上でサポートが無い Windows XP を入れ替えたい注文の多くないユーザーに次回の Haiku リリースを勧められますか? あるいは、むしろ軽量の Linux ディストリビューションを勧めますか?

pdziepak: 最近の WebPositive の開発の前進により、Windows XP がオペレーティングシステムの頂点であると信じる人々に、私たちは支障なく Haiku を推薦し始められると思います。残念ながら、まだドライバーに関する問題があります。しかし、それはほとんど運に依存します。

Premislaus: ニッチなオープンソースプロジェクトで作業することが、あなたのプロとしての成功を達成すると思いますか?

pdziepak: 私はそのように望みます。私は、重要なことは私が成し遂げてきたこと、および私がこの時までに学習したものであると思います。そして、プロジェクトの人気はそれほど重要ではありません。プロジェクトはそれぞれ、開発者間の協調に関する独自ルールを持っています。また、様々なワークフローモデルを経験することは明らかに価値があります。つまり、結論を出し、異なるソリューションを利用できます。

Premislaus: ポーランドのコミュニティーとのあなたの関係はどうですか。また、それは仕事をしていると思いますか。古い Haiku-os.pl ニュースを辿っている時、以前私たちのサイトにはより多くの編集者および活動的なユーザーがいたことに気づくでしょう。金融賞 (financial prizes) 付きの開発コンペ (請求書作成アプリ) を組織する試みさえありました。その 1 つは、1000zł [約 250€ - 訳注] の出資がありました。それは大金ではありませんが、そのような賞があったという事実が重要です。それは、BeOS がまだ使用可能な時期だった、Zeta は世の中にあり、さらに Haiku がまもなく出ると思われていました。それから何年も経ち、コミュニティーは縮み、ずいぶん元気が無いように見えます。私たちがなにを間違えているのか指摘することができますか?

pdziepak: 私は、ポーランドのコミュニティーは間違っていることは何もしていないと思います、対照的に、そのような小さな興味で、Haiku の普及を促進することはとても印象的です。問題はプロジェクトそれ自体です。作業の進行が不十分な場合、興味が消えるのは当然です。時々私は、Haiku が "not invented here" 症候群に苦しんでいると思います。あまりにも多くのものが "ネイティブ" (それが何を意味するにせよ) であり、0 から書かれていなければなりません。不運にも、大量の作業なくして、適当な期間で完全なオペレーティングシステムを構築することはできません。しかし、パッケージマネージャーのおかげで、非常にすばらしい Port の数が増えていくのが見られます。

Premislaus: あなたの他の関心、趣味は何ですか? どんな音楽が好きですか、読んでいる作家は誰ですか? 映画やシリーズ物は見ますか?

pdziepak: 音楽に関して言えば、ほとんどがヘビーまたは非常にヘビーなサウンドです。しかしよりライトな例外があります。本の場合には、状況がはるかによいかもしれないとを認めざるをえません。しかし、私が好きな著者- H. P. Lovecraft および J.R.R. Tolkien (ロード・オブ・ザ・リングとホビット以外)-を選べなかったほどは悪くはありません。好きな映画を選ぶのは難しいでしょう、なぜなら、"good" は、非常に主観的な言葉で、あなたに何も伝えないでしょう。私はコメディー (少数の例外あり) およびばかげたアクション映画が好きではありません。

Premislaus: ひょっとすると、コンピューターゲームをしますか?

pdziepak: 私は長い間ゲームをしていません。私は cRPGs を常に好んでいましたが、明らかに、私がこれまでにした最良のゲームは、Planescape: Torment (プレーンスケープ・トーメント) です。

Premislaus: ほかのどのようなオープンソースプロジェクトをサポートしましたか。あるいは、今支援しますか?

pdziepak: さて、あまり多くのオペレーティングシステムはありません。昨年、私は DragonFlyBSD に関する GSoC に参加しました。今年、OSv に関する GSoC が予定にあります。ずっと前に、私は FreeSpace のオープンソースプロジェクトに基づいた、FreeSpace ソースコードプロジェクトに取り組みました。私は、その時のよい思い出があるとは言えません。

Premislaus: なぜ?

pdziepak: Subversion ;-).

もうすこし真面目に (私は Subversion が好きではありませんが)、組織と明瞭なプロジェクトゴールに欠けていました。それは、C が多めの、C および C++ のごちゃまぜでした-動作する限りは、たくさんの癖と、ほとんど 1996-1998 年に書かれたコードとともに書かれていました。私が理解できない理由により、すべては GCC2 よりずっと厄介な、古めかしい MSVC 6 でコンパイルしなければなりませんでした。コードレビューの書式はまったくありませんでした。

Premislaus: Haiku での作業は、あなたが関わっているほかのプロジェクトに役立ちますか? 私は、DragonFlyBSD と OSv が Haiku とは少し異なった目標があることを知っていますが、もしかするとプロジェクト間でいくらかの類似点があるでしょうか? これらのプロジェクトは Haiku よりどの分野で優れていますか? あるいは、劣っていますか? それは、特徴あるいは広範囲に使われていることではありません、しかし、言いましょう、組織についてどうですか?

pdziepak: OSv に関して、このプロジェクトは Haiku と共通点がまったくありません、ライセンスは一致するのですが。コード共有の余地はあまりありません。OSv はカーネルの中で C++11 と Boost を使用しています。DragonFlyBSD の場合には、違いがあまり大きくありません、しかし、カーネル構造が完全に異なっているので、あるプロジェクト中での作業を別のプロジェクトに使用してもあまり意味をなしません。ユーザーレベルでは、OSv と Haiku はなおさら異なります。Haiku は本格的なオペレーティングシステムですが、OSv は実際、VM 上でのみ走る Exokernel であるので、これらのプロジェクトを比較するポイントがありません。確かに、DragonFlyBSD には、完全に異なる目標 - サーバー がありますが、Haiku は間違いなくよりユーザーフレンドリーです。

Premislaus: マイクロソフトはオープンソースを進めると思いますか?

pdziepak: Linux 中には、GPL ライセンスのマイクロソフトのコードがいくつかあります。もちろん、彼らのプロジェクトのいくつかには公開されたコード (私は、主として Singularity に関してここで考えます) があります、もちろん、それは R. M. Stallman 閣下によって承認されたライセンスでリリースされていません、しかし、それは、誰でもそのコードにアクセスすることができるという事実を変えません。たとえ私が大学への協定の一部としてマイクロソフトシェアード Windows カーネルソースコードを正しくリコールする場合でも。マイクロソフトはオープンソース運動の巨大な、永遠の敵ではありません。しかし、Windows が近い将来にオープンソースプロジェクトになるとは思いませんが。

Premislaus: オープンソース運動の内部で、オープンソフトウェア対フリーソフトウェアなど、ライセンスに関する討論に多くのエネルギーが費やされています。その件に関するあなたの意見はどうですか?

pdziepak: 正直なところ、これらの、GPL 対 BSD、そしてフリー対オープン論争はどうでもいいことです。しかしながら、他人へ自分たちの意見を押し付けないと生きていけない多くの人々がいます。ですから彼らがそうしなければならない場合は、彼らに議論させておきます。確かに、ライセンスの非互換性は時には腹の立つことです。しかし、この問題はそれをたいてい浮かび上げません。私には、自由でないという理由だけで、特定のプログラムを使わないということは考えられません。

Premislaus: IT における多くのソリューションが、様々な理由で採用されませんでした、悪いものが良いものに勝つこともありました。何をもっとも残念に思いますか? 私たちの IRC 会話から、私は、あなたが Itanium を忘れられないのを知っています。

pdziepak: 私は、Itanium が優れていると言うつもりはありませんが、このアーキテクチャーに使われた多くの面白い考え、特に VLIM および投機的実行は認めるでしょう。先に述べた Singularity が続かなかったのは残念です。同様に、Plan 9 は単なる変わり物以上になりえたかもしれません。特に、それは、Ken Thompson および Dennis Ritchie が関わっていたオペレーティングシステムなので。

Premislaus: GCC 4.9 がリリースされた時、あなたは、ポーランド語 Haiku チャンネルにやっと Clang から GCC に戻れると書きました、あなたの見解において、GCC の方がどの領域で優れていますか? 最近、私たちは、GCC を叩いて、Clang を賞賛する傾向を見ることがあります。

pdziepak: 私は、私が取り上げる Clang の魅力が、時々誇張されている気がします。私が GCC を好む技術的な理由は多くありません、それは単に、標準準拠や _Generic 標準解釈の解釈が困難というコード中の警告によって Clang が私をいらいらさせるからです。しばしば、人々は、Clang の内部構造がより明確であると主張します。それは確かに本当です、しかし正直なところ、ユーザーとしては、私はあまり気にしていません。

Premislaus: Haiku に Eclipse のようなすばらしい IDE がないというのはほとんど共通認識です。私たちには、シンタックスハイライトを備えたエディター Pe、非常にシンプルな IDE Paladin、そして Vim の移植版 (おそらく、ほかのコンソールツールもあります) があります。立派で人気のある IDE を移植するには、どれだけの作業が必要でしょうか? Haiku で利用可能なツールは本当に不足しているでしょうか、もしかすると、それは怠惰、つまり新しいプログラムを学習するのに気が進まないという問題でしょうか?

pdziepak: 私は、それはより習慣の問題であると思います。私のように、フル IDE を使用しない多くの人々がいます。彼らにとっては、単純なエディターで十分です。一方、ほかの多くの人は、IDE を使わないコーディングを思いつきません。私は、それは恥じること、つまり怠惰のサインではないと思います。同様に、プログラムするためにできるだけ Lisp で書かれた、全く新しいオペレーティングシステムを必要とする 3 番目のグループの人々がいます。誰でも自分の習慣を持っていますし、彼らが急にそれらを放棄すると期待するのは難しいことです。しかし、私は、何人かが示唆するような、Haiku 独自の、特別の IDE は必要ないと思います。ほかの java アプリケーションに役立つかもしれない Eclipse を移植することに作業を注ぐほうがよいでしょう。

Premislaus: Emacs がある場合、GNU/Hurd の目的はそれでは何でしょうか?

pdziepak: Lisp インタープリターは何らかの上で実行する必要があります。それが、GNU/Hurd の目的です。

ほかのインタビュー:
https://www.haiku-os.org/community/forum/interview_matthew_madia
https://www.haiku-os.org/community/forum/interview_kallisti5

KapiX による訳 (注:ポーランド語→英語)