■
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のビジョンがシンプルだった。
- 「すべてのPCでMSのソフトウェアを動かす。」
このビジョンは21世紀では十分ではない。
今のLinuxのビジョン
Linuxは、単にデスクトップだけでなく、ロボット、スパコン、Facebook/Amazon/Googleなどのサーバー、すべてのコンピュータに搭載される。
Linuxはコンピュータのfablicとして機能している。
コンピューティングの未来がLinuxで作られている。
インターネットは10億人が接続している。すぐに20億の人が接続されるようになる。
自動車、アプライアンス、パイプライン、livestock・・・、これらすべてがインターネットにつながる。
（１）すべての端末にIPアドレスを割り当てられる
モバイル端末はもちろん、電球、あらゆるものがネットワークにつながる。これでトランザクションが増大する。ネットワークサーバーはより多くのデータをさばくため、より大きなストレージ、データマイニングのためのスーパーコンピュータが必要となる。
Linuxはこれらすべての土台になりえる。
Linuxはこのビジョンに最もマッチするOSだ。
モバイルOSとして、スパコンのOSとして、最も進化して普及している、
将来有望なアーキテクチャだ。
（２）Linuxはコスト削減に貢献する。
開発コストは機器が複雑になり、爆発的に大きくなっている。
イノベーションのためのコストが上がってきている。
最近は、携帯電話を平均14ヶ月しか使わないというデータがある。
これはメーカーに対して大きな開発プレッシャーになっている。
かつては、図の左側。
大きな開発コストをかけて製品を短いサイクルで作っていた。
これからは右側の図。
Linuxはコラボレーションで製品をつくっている。
開発コストを節約するだけでなく、新しい収入源が得れる。
Appstore、新しいサービスを作ることができる。これまでのクローズドなシステムではできなかったことだ。
新しい経済モデルができてきている。
Android、MeeGooのエコシステムに参加してる企業は増えている。
（３）クローズドからコラボレーションへ。”
PCクライアントのあり方も変えている。
これまでは、PCがインターネットにつながっていた、
2010年を境に、車、モバイル、家電、すべてがインターネットにつながる。
キラーアプリはインターネットだ。
牽引していた企業も、ハードメーカーだった。
これから牽引するのは、Linuxだ。
メーカーがLinuxを使い、市場を作る。
AmazonはLinuxを使い、クラウドプラットフォームを作った。
Googleは、Linuxコミュニティに許可を得たわけではないが、Androidを普及させた。
（４）IT産業自体がサービス産業に進んでいる。
「FREE」
ソフトウェアの無償化だけでなく、ハードウェアも無料になるだろう。
Kindleは100ドルぐらいになった。
アメリカのT-mobileではPCを無料で配っている。
T-mobileは1ヶ月50ドルの無線プランで儲けている
エンタープライズIT企業はこの動きに向かっている。
ITセクターで急成長している企業は、サービスとして利益を得ている。
エンタープライズの分野でもこの動きが顕著だ
Amazon、salesforce.com・・・
サービスを考えさえすれば、Amaoznのサーバーを使ってスタートアップすればよいので、コストが少ない。成功すればサーバーを増やせばよい。
Amazonは新しいことをやったわけではない。Linuxを使っただけだ。
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パッケージング
- AppStoreでのアプリケーションのディストリビューションをサポート
- AppStoreもオープン。独自に運営しても良い。
PlatformEcosystem
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
IBMがLinuxに取り組んだ10年をふりかえる
当初、Linuxはエンタープライズのエッジで使われていた
今ではミッションクリティカルなコアでも使われている。
IBMでも日本の銀行などでシステムを組んだりして、主要プロダクト，システムであたりまえのように使われている。
1999年にIBMでLinuxの組織を作った。
そこから10年、多くの失敗をした。
本にするとすごい量になるだろう。
Linuxはグローバルなビジネスのツールとしても機能しだした。
今では欠かせないものだ。
1998年、インターネットブーム
コミュニティの存在がこれまでにないものになってきた。
たとえば、ファイルシステムの開発者が世界各地で改善を続けていた。
真の意味での「イノベーション」がOSSで起こっていて、革新の速度が変わった。
コミュニティがビジネスにおけるゲームを変える原動力であると考え始めた。
1998年9月、小さなチームのリーダーだった。
Linuxが将来のプラットフォームとして注目されていた。
当時はばかげた考えといわれるぐらい、誤解が多かった。
当時の上司に、Linuxとは何なのか、誰がコントロールしているのか、を説明する必要があった。
Linuxは90日間でIBMで「戦略」として採用された。
お客様の中でも使われるようになった。
IBMよりも先に、お客様がLinuxを知るようになった。
1999年：IBM gets started
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アプリケーションなど、主要製品に入り込むことができると考えていた。
この時点では、IBMがLinuxについていけてなかった。
開発コミュニティが先を行っていた。
さらなる投資を決断、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のベストのサポートが受け入れられるようになる。
]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
- busybox訴訟の例
- OSSライセンス解析ツールを提供
- Fortinet
- D-Link
- 組み込み製品にLinuxが広がっている。
- メーカーもライセンス違反したくないが、エンジニアはライセンス知識を持ち合わせていない。マーケット、顧客は多様である。ライセンスに対する説明能力を備える必要がある。
Solutions Start at home
- リリースサイクルで確認する。
- 解析
- リリースプロセスに解析を組み込む
- 知識
- ドキュメントに残して、ノウハウを共有する。
ツールの紹介
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がモデレータというカーネル開発者パネル。
カーネル界隈の内輪ネタを生で聴けて面白かったです。
パネリストの表記一覧
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回はあるｗ
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の中だけで変更が多すぎる。
混乱してるので、ナンバリングを変えたい。
最初の”２”をとってしまうとか。
B:
Stableなブランチとunstableなブランチもできた。
そのほうが簡単に見えた。
マージウィンドウなどの仕組みもできた。
仕組みでカバーしている、
H:
もともとの開発期間に戻ってきた気もする。
