Hatena::ブログ(Diary)

mnishikawaの日記 このページをアンテナに追加 RSSフィード

2010-09-27

LinuxCon Japan 2010 Day1

LinuxCon Japan 2010、1日目。

[]LinuxCon2010/Ubiquitous Linux: The New Computing Fabric

Ubiquitous Linux: The New Computing Fabric

Jim Zemlin, Executive Director at The Linux Foundation


コンピューティングのビジョン

これまでのコンピューティングはMSが進化を牽引してきた。

20年前はMSのビジョンがシンプルだった。

このビジョンは21世紀では十分ではない。


”What is Linux Vision”

  • NY,東京証券取引所をはじめとするシステム
    • Linuxのシステムで動いており、経済そのものといえる
    • 航空管制システム、議会などでもシステムとして使われている。
  • 映画「アバター」のデジタルエフェクトはLinuxで行っている。
  • スマートグラッドシステム
  • BMWLinuxをエンタテイメントシステムに使うと発表している。
  • GPSユニットのサーバー側の進化にも貢献


今のLinuxのビジョン

Linuxは、単にデスクトップだけでなく、ロボットスパコンFacebook/Amazon/Googleなどのサーバー、すべてのコンピュータに搭載される。

Linuxコンピュータのfablicとして機能している。

コンピューティングの未来がLinuxで作られている。

インターネットは10億人が接続している。すぐに20億の人が接続されるようになる。

自動車、アプライアンスパイプライン、livestock・・・、これらすべてがインターネットにつながる。

コンピューティングのワークフロー

電力会社の例

  • インターネットを使った電力会社のメーター情報収集の例
    • 100万人のユーザーが月一回、メーターを読むだけで、1200万のトランザクションが発生する。
    • 毎日、人を派遣する労力が節約できる。
    • 情報を随時読めば、使用量のより細かい制御、コスト削減が可能だ。
    • しかし、より細かい情報を読むとトランザクションが増大する。
    • 350億トランザクションになると、まったく違うシステムが必要になる。
    • これがインターネットの世界。

今後のコンピューティングのビジョン、そしてLinuxの役割は?


(1)すべての端末にIPアドレスを割り当てられる

モバイル端末はもちろん、電球、あらゆるものがネットワークにつながる。これでトランザクションが増大する。ネットワークサーバーはより多くのデータをさばくため、より大きなストレージデータマイニングのためのスーパーコンピュータが必要となる。

Linuxはこれらすべての土台になりえる。

Linuxはこのビジョンに最もマッチするOSだ。

モバイルOSとして、スパコンOSとして、最も進化して普及している、

将来有望なアーキテクチャだ。



(2)Linuxはコスト削減に貢献する。

開発コストは機器が複雑になり、爆発的に大きくなっている。

イノベーションのためのコストが上がってきている。

f:id:mnishikawa:20100926095522j:image

最近は、携帯電話を平均14ヶ月しか使わないというデータがある。

これはメーカーに対して大きな開発プレッシャーになっている。

かつては、図の左側。

大きな開発コストをかけて製品を短いサイクルで作っていた。

これからは右側の図。

Linuxはコラボレーションで製品をつくっている。

開発コストを節約するだけでなく、新しい収入源が得れる。

Appstore、新しいサービスを作ることができる。これまでのクローズドなシステムではできなかったことだ。

新しい経済モデルができてきている。

Android、MeeGooのエコシステムに参加してる企業は増えている。



(3)クローズドからコラボレーションへ。”

f:id:mnishikawa:20100926100220j:image

PCクライアントのあり方も変えている。

これまでは、PCがインターネットにつながっていた、

2010年を境に、車、モバイル、家電、すべてがインターネットにつながる。

キラーアプリインターネットだ。

牽引していた企業も、ハードメーカーだった。

これから牽引するのは、Linuxだ。

メーカーがLinuxを使い、市場を作る。

AmazonはLinuxを使い、クラウドプラットフォームを作った。

Googleは、Linuxコミュニティに許可を得たわけではないが、Androidを普及させた。



(4)IT産業自体がサービス産業に進んでいる。

「FREE」

ソフトウェアの無償化だけでなく、ハードウェアも無料になるだろう。

Kindleは100ドルぐらいになった。

アメリカのT-mobileではPCを無料で配っている。

T-mobileは1ヶ月50ドルの無線プランで儲けている

エンタープライズIT企業はこの動きに向かっている。

ITセクターで急成長している企業は、サービスとして利益を得ている。

エンタープライズの分野でもこの動きが顕著だ

Amazon、salesforce.com・・・

サービスを考えさえすれば、Amaoznのサーバーを使ってスタートアップすればよいので、コストが少ない。成功すればサーバーを増やせばよい。

Amazonは新しいことをやったわけではない。Linuxを使っただけだ。


(5)米国のトップ2の重要な戦略

1.クラウド

2.オープンソース

Amazonが.NETをつかっていたら今の成功は無いだろう。

クラウド自体、Linuxが駆動しているからだから。



「Join us...」

いまは始まりを迎えているに過ぎない

Linuxは150億ドルのエコシステムに成長した

この世界のすべてのシステムを駆動している。

Linuxの世界は広がる一方である。

このLinuxConの3日間、新しい世界に目を向けてほしい。

[]LinuxCon2010/Got MeeGo?

Got MeeGo?

Dirk Hohndel, Chief Linux and Open Source Technologist, Intel Corporation


What is MeeGo

MeeGoノキアインテルの共同プロジェクト

もともとやってた、Moblin、Maemoプロジェクトを統合

ネットブック、ハンドセット、タブレットのプラットフォーム、メディアフォン、TVなどがターゲット。

OSS Projectです。


MeeGo governance

MeeGoをはじめるとき、LinuxFoundationのプロジェクトにしたいと思った。

LinuxFoundationの技術ステアリンググループIRCがある。

技術的なこと、方針、モバイルの利用モデルなどをオープンに議論している。

そして、これには企業を限定せず、だれでも参加できる。

publicソースのリポジトリがあり、実力社会だ。


MeeGo Key Elements

  • Reference user experience and application provided
    • ユーザーエクスペリエンスモデルの提示
  • 6ヶ月ぐらいのリリースバージョン
  • C++ベースのQtCreatorで開発する。
  • QEMU、Xephyrでのテスト
  • RPMパッケージング


PlatformEcosystem

f:id:mnishikawa:20100926102816j:image

Upstreamプロジェクトをできるだけ活用して作っていきたい。

まずメインストリームにコントリビュートし、それを活用してMeeGoを作っていく。

そのために、メンテナンスが必要な環境を作っていく。

バックポート作業をやるのではなく、上流から作っていく。

オープンソースのエコシステムを活用し、貢献していく。

この成果はAndroidにも役立つだろう。


MeeGoには1000以上のフルタイムエンジニアが仕事している。

来年はTV、モバイル・・・など、MeeGoで動いているものをお見せしたい。

10年前にIBMが何十億ドルも使ってLinuxエンタープライズシステムを作ったように、

こうしたモバイルプラットフォームの成果が活用されるだろう。

[]LinuxCon2010/10+ Years of Linux at IBM

10+ Years of Linux at IBM

Dan Frye, IBM Vice President, Open Systems Development and Linux Foundation Board Member

f:id:mnishikawa:20100926135313j:image


IBMLinuxに取り組んだ10年をふりかえる

当初、Linuxエンタープライズのエッジで使われていた

今ではミッションクリティカルなコアでも使われている。

IBMでも日本の銀行などでシステムを組んだりして、主要プロダクト,システムであたりまえのように使われている。

1999年にIBMLinuxの組織を作った。

そこから10年、多くの失敗をした。

本にするとすごい量になるだろう。

Linuxはグローバルなビジネスのツールとしても機能しだした。

今では欠かせないものだ。

ここでは、IBMLinuxビジネスの10年をふりかえる。


1998年、インターネットブーム

コミュニティの存在がこれまでにないものになってきた。

たとえば、ファイルシステムの開発者が世界各地で改善を続けていた。

真の意味での「イノベーション」がOSSで起こっていて、革新の速度が変わった。

コミュニティがビジネスにおけるゲームを変える原動力であると考え始めた。

1998年9月、小さなチームのリーダーだった。

Linuxが将来のプラットフォームとして注目されていた。

当時はばかげた考えといわれるぐらい、誤解が多かった。

当時の上司に、Linuxとは何なのか、誰がコントロールしているのか、を説明する必要があった。

Linuxは90日間でIBMで「戦略」として採用された。

お客様の中でも使われるようになった。

IBMよりも先に、お客様がLinuxを知るようになった。

  • 当時の疑問点として挙げられた項目
    • 持続性があるのか?
    • コミュニティの人たちが飽きないのか?
    • コントロールは誰がするのか?
      • IBMはコントロールが大好きな会社でした。
      • 結果的に品質をコントロールは不可能だ。
      • しかし、この問題は質問自体が間違っていた。
    • GPL

1999年:IBM gets started

  • 1999年3月、LinuxWorldに参加
  • 1999年後半にはLinuxコミュニティへの貢献(contribution)をはじめた。
  • Linuxテクノロジーセンターを設立

OSSコミュニティはひとつではない。

リーダーシップ、やり方も違う。

カーネルの中でも、メモリマネジメントなど、機能が違うと違うと知った。

次に、教育について考えた

ミスしたことが受け入れられた。


  • 1999年9月に、IBMの戦略がより真剣な方向に向いた

お客様の要望は、想像したよりも大きかった。

もっと投資が必要、よりリソースをさくことが必要だった。

お客様からの信頼も得られてきた。


2000年 Linuxに参入し、お客様からの信頼も得られてきた。

カーネルへのコントリビュートを始めた。

最初はカーネルから離れて別のコミュニティに貢献していた。

Andrew Mortonにも、カーネルへの貢献が遅いと指摘を受けていた。

「本格化」から「加速」に方針転換

IBMの基調講演のなかで、10億ドルの投資を発表。

コントロールではなく、貢献であると明確に方針を示した。


IBMの主要な部門にはLinuxのチームが作られて、

Linuxのビジネスができるようにした。

マーケティング部門もそう。

 


Lesson Learned #1 : Develop in the Open
  • ジャーナルFS

最初、うまくいかなかった。

完成した後でソースを出した。

IBMのファイヤウォール内で作ってから公開というパターン

カーネルコミュニティの反応は、面白い

コミュニティは、インクリメンタルに作り上げていく。

初期で発表して、みんなで作っていかなければならない

  • スケーラビリティ

複数のCPUで動かすための対応

メーリングリストでの議論を進めていく中で、いろいろと違和感があった。

このことについて考えたとき、やり方が間違っていた

社内でのコミュニケーションを禁止した。

コミュニティ向けのE-mailのみでやり取りするようにした。

LinuxではSMPではうまくいかないとLinusも言っていた。

参加の仕方がわるかった。

これをしっかりと見ていけば、問題は解決していく。


    • 早めに目標を設定して
    • 参加して
    • インクリメンタルに
    • 個人として参加し、迅速にフィードバックを反映していく。

2003年 カーネル2.6の開発に参画。

 エンタープライズのエッジから、ミッションクリティカルな分野、Webアプリケーションなど、主要製品に入り込むことができると考えていた。

  この時点では、IBMLinuxについていけてなかった。

  開発コミュニティが先を行っていた。

  さらなる投資を決断、CEO、CTOに説明、

  Fortune500企業にもLinuxが有用であることを説明していった。

  いずれ、Linuxが世界の標準になることを推進

  そのことで、信頼を勝ち得た。




Lesson Learned #2 : Don't reinvent the penguin

ここで学んだのは、十分広い分野をサポートしていたと考えいたのは間違いだった。

コミュニティに貢献する中で、分野は広がっている。

IBMがサポートしていたアーキテクチャ、分野も、公開してみると、他のシステムにも広がっていくことを知った。

  • スケジューラの改善

IBMの社員のコードがコミュニティで拒否されたが、

そこから提案のより改善されたコードが、コミュニティで作られた。

誰が作ったということは重要ではない。

結果にこだわるのであれば、コミュニティ全体の成果を考えることが重要であることを学んだ。

OSSディベロッパのマネジメントは時間がかかるが、個人、企業にとっても意味があることになる。

これは、コミュニティに参加することで得られるメリットである。

新しいプロジェクトを作るのではなくて、すでに活動を続けているコミュニティに参加し、そこで一緒により良いものを作るのが、最も効率的に成果を得られる。

経験のあるプログラマに手伝ってもらうには、参加しないといけない。


企業の開発者、経営者にアドバイスしたいのは、

コミュニティへの参画が、最も効率が良い」と伝えたい。



2004年〜2005年

Linuxは特別プロジェクトとして開発するチームでした。

”Emerging Business Opportunity”

→重点的分野として、特別に短期的に投資するチームとなった。




Lesson Learned #3 : Work with the process

Linuxは責任者ではない。

影響力を持っているが、意思決定の責任は無い。

社長ではなく、裁判所のような立場が近いだろう。

会社として効果を得るには、コミュニティで信頼を得ることが必要だ。

コミュニティで信頼された開発者が、コミュニティの中で「議論」をしていかなければならない。

ハードウェアのサポートなど、コミュニティの中で仕事をしなければ取り入れられない。


ほとんどのこと(ロードマップなど)は予想ができるものである。

コントロールはされていないが、コミュニティの向かう方向は読めてくる。

IBMコミュニティの進み方に慣れてきた。

ハードウェアのチームも心配しなくなった。

だいたいはきちんと対応できることがわかってきた。

ハードウェアはかなり早い段階でサポートしなければならない。

それで初めてpatchが受け入れられ、Linuxのベストのサポートが受け入れられるようになる。



2006-2007

  • Linuxは主要なプロダクトとなった。

メインストリームとして、退屈なぐらい仕事が続いてきた。

現在は、プラットフォームとして大きな信頼が得られている。

IBMの収益の柱になっている。

多くの顧客、業界で使われている。

市場規模とか、もうLinuxサーバーが何台あるとかは数えなくなった。

増えすぎて数えても意味がない。


  • KVMが重要な役割を示す

ハイパーバイザーとしてカーネルを動かす。

KVMがアップストリームに入ってから、

セキュリティ、パフォーマンスなど、驚くべきスピードで進化を続けている。

    • IBMクラウドテクノロジーのコアである。
    • KVMIBMのテクノロジーセンターでも最大のチーム。
    • LinuxはゲストOSとしてもプレミアを示している。



まとめ

  • 早い段階で持ち込むこと
    • その後、議論を続けること。
    • 投げただけで終わらない。
    • デバイスドライバが、リリースごとに保持されることに、最低限でもサポートを続けなければならない。
  • OSS技術者のマネジメントは必要
  • 持続性を持つ
    • 時間がかかる仕事です。

[]]LinuxCon2010/Introducing the Binary Analysis Tool

Introducing the Binary Analysis Tool

Shane Caughlan(gpl-violations.org)


途中でプロジェクタが写らなくなったので、口頭でディスカッションしながらセッションを進めた。


gpl-violations.org

gpl-violations.orgは2004年から開始した。

バイナリを自動で検出するツールを開発中。

27カ国で260人以上のライセンスのプロをかかえている。

オープンソースの法的知識を展開している。


Look Fmiliar

  • OSSライセンスは、プラクティスを共有すれば、あらゆるケースに対応でき、リスクを回避できるはずだ。
  • 組み込み製品にLinuxが広がっている。
    • メーカーもライセンス違反したくないが、エンジニアはライセンス知識を持ち合わせていない。マーケット、顧客は多様である。ライセンスに対する説明能力を備える必要がある。


Solutions Start at home

  • リリースサイクルで確認する。
  • 解析
    • リリースプロセスに解析を組み込む
  • 知識
    • ドキュメントに残して、ノウハウを共有する。


ツールの紹介

http://gpl-violations.org/

GPL-violation.orgは、ツールをリリースした。Apache2ライセンス


busyboxを使っているか、どんなコンフィグレーションで使っているか、ライセンスの根拠となる。

シリアルポートから解析できる場合もあるし、

Linuxベースのシステムからネットワークでポートスキャンして解析できることもある。

busyboxカーネルモジュールがどうやってリンクしているかがライセンス判断の要素になる。

プログラム名やバージョンの文字列を取得する。

Linkしてるライブラリシンボル名を参考にする。

動作しているデータから取得するのでリバースエンジニアリングにならないと考えれる?

LZMAで圧縮されたコード、ストリップされているコードても、ある一定の間隔でコードがならんでいる。

GPLのコンプライアンスガイドがフリーのPDFで公開されているので見てほしい


コンプライアンスエンジニアリングの可能性

GPL-violationsでも多くの事例を確認しており、ビジネスの市場は明確にある。

また、コンプライアンスエンジニアリングのノウハウは共有すべきである。

[]LinuxCon2010/Linux Kernel Panel

SCSIメンテナのJames Bottomley(メモでは”B”と表記)、

カーネル開発者でLWNエディタのJon Corbet(メモでは”C”と表記)、

USB & PCIサブシステム、STABLEカーネルのメンテナのGreg Kroah-Hartman(メモでは”G”と表記)、

スケジューラ開発者Peter Zijlstra(メモでは”P”と表記)、

KVMとかやってるChristoph Hellwig(メモでは”H”と表記)、

そして、Rusty Russellがモデレータというカーネル開発者パネル。

f:id:mnishikawa:20100926175320j:image

カーネル界隈の内輪ネタを生で聴けて面白かったです。


パネリストの表記一覧

B: James Bottomley

C: Jon Corbet

G: Greg Kroah-Hartman

P: Peter Zijlstra

H: Christoph Hellwig

R: Rusty Russell


Q: 会場からの質問



パネルメモ


カーネルのリリースについて

R:

 カーネルのリリースは終わった?

B:

 終わらないよ。

 カーネルの半分以上はドライバで、新しいハードウェアが出続ける以上、新しいドライバが必要になってくる。

 インテルとかがデバイスを作らなくなったらカーネルの開発は止まるでしょうけど。


なぜカーネル開発を続けるのか

Q:

 なぜ、カーネル開発を続けられるのでしょう?

H:

 カーネルを開発をやってる人たちと仕事をするのが楽しい

G:

 ドライバでちゃんとハードが動くようになるのがるれしいです。

C:

 システムの中に何があるのかを知るのをうれしい。

B:

 人類のためにといいたいが、給料のためにやってます。



日本人が開発に参加するには?

C:

 コントリビューションの5%は日本から来ていた。

 ここ数年、日本からのコントリビューションが多かった。

Q:

 日本からのコントリビューションが増えているというが、

 どこからはじめたらいいか?

 また、どこが必要とされているか?

G:

 ドキュメンテーションが必要だし、入りやすいだろう。

 何より、自分のやりたいことが一番良いだろう

B:

 メーリングリストに入ることだ。

 メーリングリストを読んで、他の人がコントリビューションしていないかなどを確認してほしい。

 HowToにしても、カーネルの情報が必要だ。

R:

 他の人のパッチをレビューすることも重要だ。

 貢献するひとつの方法だろう。

C:

 パッチのレビューは初心者にとっては恐ろしいものになるかもしれない。

 動作がしない、わからない、といった指摘でも良い。

 これが問題解決につながり、改善につながるだろう。


カーネル開発プロセス

Q:

 最近、StagingTreeなど、新しいカーネル開発の仕組みができたが、どのように運営しているのか?

P:

 新しいドライバで、完全に入れなおしもあったし、

 ごみみたいなコードも多い。

C:

 Stagingツリーは、カーネルに入れるステップというよりも、

 準備のためのツリーとして役には立っている。

B:

 SCSIパッチだと、最初のベンダーコードは使えないことが多い。

 正しい実装になっていない。

 これは誰にも直せない。

 データシートも公開されていない。

C:

 メーカーにも、ドライバはStagingツリーに入ることを伝えておかないといけないだろう。

 そうすると、ベンダー開発のモチベーションになるだろう。


B:

 ベンダーはStagingツリーの存在も把握して、コンパイルが通るようにして、

 システムを保つべきだろう。


Linuxコミュニティに入るには何から始めるべきか

Q:

 日本の開発者はLinuxコミュニティに入りたいと思っているが、どこからはじめればよいか?

P:

 興味のある分野をやればよい。

C:

 カーネルのBugzillaを見るのもよい。

 バグフィックスは良い貢献になる。

B:

 SCSIがお勧めです!

R:

 メーリングリストを読んでほしい。

G:

 カーネルMLは大事なところだけ読んだら良いのでは?

B:

 サブシステムのメーリングリストもある。

 ある程度こうしたのでなじんでから、発言すればよいだろう

R:

 ネイティブでないひとにはMLは難しい?

 ジョークがわからないとか。

P:

 そんなに難しくないと思いますよ。

 全体としては、開発に言語はそれほど問題にはならない。

B:

 シンプルで丁寧に言葉を使うようにしているし、

 メールは送る前に読んで、考える時間がある。

 時間を割いてください。

H:

 簡単な文章を書くようにしたら良いと思います。

 あなたの将来のためにもなる。



失敗談を教えてください。

Q:

 カーネルコミュニティで経験した失敗を教えてください。

R:

 たくさんありすぎて困るが・・・・

B:

 難しいですね・・・

 メンテナは失敗を成功に持っていくのが仕事ですし。

 また、失敗をわからないようにするのもテクニックだ

G:

 ユーザーのハード・データを壊したことも!

 ユーザのPCを何回も再起動させてしまったり、

 HDD壊したり・・

 少なくとも5-6回はあるw

R:

 カーネルディベロッパに、とんでもないものを作ってると指摘されたことがある。

 ただ、そのおかげで、問題を指摘してもらいやすくなった。

 質問が私のところに来るようになった。




カーネル開発に必要なスキル

Q:

 コントリビューションするには、どんなスキルが必要か?

P:

 「C言語!」

C:

 バグを見つける能力は必要だろう

R:

 バグを見つけるのはすばらしい能力だろう

 あと、継続して修正することがあるので、継続する力が必要だ

P:

 フィードバックを粘り強く聞くという能力が必要だ。

Q:

 ユーザースペースから入るのはどうか?

R;

 TTYもひどいが、ユーザースペースがひどい。

 ユーザースペースでひどいところはSambaだが・・・

 ユーザースペースで仕事するのは退屈だ。

H:

 QEMUなんかは単一テストだけでも難しい。

 開発はデバイスが限定できるので楽だと思うが。

Q:

 Rubyとか、楽しいのでは?

B:

 オレはRuby知ってる。


カーネルデバッグツールは?

Q:

 デバッグはどんなツールを使ってますか?

 printk以外で・・

P:

 「vi

G:

 トレーサを使う。

 でもprintkかな。

H:

 デバドラはどうしてもprintkになる。

 traceをすることで、printkをやめて楽になった。

R:

 ネットワーク系はツールが役立つ

 パケットフィルタとか

C:

 デバッグFSは有効だ。


Linuxのバージョン

Q:

 2.6は次のバージョンに上がらないのでしょうか?


G:

 確かに、2.6の中だけで変更が多すぎる。

 混乱してるので、ナンバリングを変えたい。

 最初の”2”をとってしまうとか。

B:

 Stableなブランチとunstableなブランチもできた。

 そのほうが簡単に見えた。

 マージウィンドウなどの仕組みもできた。

 仕組みでカバーしている、

H:

 もともとの開発期間に戻ってきた気もする。


Linusがリタイアしたらどうする?

Q:

 もしLinusがリタイアするとしたら何しますか?

C:

 続きの開発はお願いしますね!

G:

 そうなったときに考える。

H:

 田舎で住むよ。

C:

 コミュニティはなんとかなるだろう。

 Gregが答えになるだろう?