twitter icon   twitter icon   rss icon

Linux.com Japan

Home Linux コミュニティ ブログ

ブログ

ブログ別アーカイブ l 未来のいつか l Android/OPhone雑記 l l
l アジアのペンギン l 烏龍の旅 l 第三のペンギン l TOMOYO Linux l

 

新着記事



「イノベーターのジレンマ」の経済学的解明、伊神満著、読了、濫読日記風 2018、その20

「イノベーターのジレンマ」の経済学的解明を読んだ。 自分にとっての忘れられない一冊に「イノベーションのジレンマ (―技術革新が巨大企業を滅ぼすとき (Harvard business school press))」がある。日本語訳が出てすぐ読んだ。2000年頃の話だ。 シリコンバレーあたりの経営者は皆読んでいる。(かどうかは統計を取ったわけでもないので実情は知らないが、破壊的イノベーションの怖さを知らずにベンチャーをやっているとしたら、不勉強すぎるし、知っていたとしても自分の組織がその罠にはまらないようにするのは至難の技である。日本では実感としてほとんど理解されていない。(個人的な感想です)) インターネット時代のベスト書籍の一つだ。 ムーアの法則に代表される変化が早すぎる時代にパラダイムが一夜にして変わる時の怖さを豊富な事例で実証している。 現場の人間としては、なるほどそういうことだったのかという腹落ちした理論である。実務家としてはそれ以上でもそれ以下でもなく、ではどうするかが今日の問題になる。 日本の半導体ベンダーが圧倒的な競争力を持っていたのに、没落したのはなぜか。Intelは日本の半導体ベンダーに完膚無きまでやられたにも関わらず生き残ったばかりではなく、CPUで圧倒的な競争力を持つまで復活したのは何故なのか。 「技術革新が巨大企業を滅ぼすとき」というタイトルが付いている「イノベーションのジレンマ」は自分にとってのバイブルだ。 そのバイブルを解説したのが「イノベーターのジレンマ」の経済学的解明である。 前置きが長いね>自分。 本書は「イノベーションのジレンマ」を実証的データを元に検証している。「イノベーションのジレンマ」ファンとしては読まざるを得ない。...
続きを読む...
 

濫読日記風 2018、EVと自動運転、鶴原吉郎著、読了、その19

年末に向けて、読了して日記に感想を書いていなかった本をひたすら記すことにする。(日記の日付はテキトーなので忘備録として自分用にとっておく) EVと自動運転――クルマをどう変えるか (岩波新書)を読んだ。 日本にとって自動車産業は残された希望の輸出産業になっている。かつては家電が世界を制覇していたのだけど、いつの間にかに壊滅的な状況になって、日本の製造業は自動車産業によってかろうじて生き残っているような形だ。(クルマが外貨稼ぎの中心に34ページ) その自動車産業も100年に一度ともゆうべき変化に直面している。EVと自動運転だ。そして自動車産業には大きな弱点がある。 それは、「品質のいい車を競争力のある価格で販売する」という自動車のビジネスモデルが、自動車産業の誕生以来100年以上変わっていないということだ。自動車メーカーはこれまでビジネスモデルの転換を一度も体験したことがなく、その組織は既存のビジネス向けに最適かされているため、新しいビジネスを生み出すことにはあまりにも硬直化している。38ページ なるほど。日本の製造業の強み、それに徹底的にチューニングされたビジネスモデル、組織構造は、新しいパラダイム、情報かと言ってもいいし、産業のソフトウェア化と言ってもいいし、あるいは流行りの言葉で言えばデジタルトランスフォーメーションに対応できていない。 ソフトウェア産業ではAppleはPCのベンダーからいつの間にかにクラウドやスマホのベンダーにピボットしている。ソフトウェア産業のジャイアントのMicrosoftもライセンスビジネスからモバイルファースト、クラウドビジネスへピボット(転身)している。 ソフトウェア産業では10年に一度くらいのパラダイムの転換があり、そのたびに勝者が変わっている。かつてはIBMであり、PC時代にはMicrosoftとIntelであり、インターネット時代にはGAFAと呼ばれるGoogle/Apple/Facebook/Amazonらにピボットした。 フィルムの時代の王者コダックはデジタル時代の今存在しない。富士フイルムは生き残った。 変化が早すぎる時代には栄枯盛衰が早い。 イノベーションのジレンマで知られるある分野でのトップ企業がはるかに規模が小さい新興企業に破壊される状況である。IT業界では、広く知られていて、滅ぼされる側の企業で働いていた人も多いので(自分もそうだ。DECという滅ぼされる側にいた)、実感としてその怖さを経験・理解している。 自動運転によって何ができるかを書かれた書籍は多い。本書はそれだけではなくその技術がどのように産業の変化を促しているかを記している。自分にとっての本書の気づきは、自動車産業が初めてのビジネスモデルの転換を必要としているということだ。 トヨタは生き残るのだろうか。そんな感想を持った。 濫読日記風 2018 知的生産の技術、梅棹忠夫著、読了、濫読日記風 2018、その18...
続きを読む...
 

EVと自動運転、鶴原吉郎著、読了、濫読日記風 2018、その19

年末に向けて、読了して日記に感想を書いていなかった本をひたすら記すことにする。(日記の日付はテキトーなので忘備録として自分用にとっておく) EVと自動運転――クルマをどう変えるか (岩波新書)を読んだ。 日本にとって自動車産業は残された希望の輸出産業になっている。かつては家電が世界を制覇していたのだけど、いつの間にかに壊滅的な状況になって、日本の製造業は自動車産業によってかろうじて生き残っているような形だ。(クルマが外貨稼ぎの中心に34ページ) その自動車産業も100年に一度ともゆうべき変化に直面している。EVと自動運転だ。そして自動車産業には大きな弱点がある。 それは、「品質のいい車を競争力のある価格で販売する」という自動車のビジネスモデルが、自動車産業の誕生以来100年以上変わっていないということだ。自動車メーカーはこれまでビジネスモデルの転換を一度も体験したことがなく、その組織は既存のビジネス向けに最適かされているため、新しいビジネスを生み出すことにはあまりにも硬直化している。38ページ なるほど。日本の製造業の強み、それに徹底的にチューニングされたビジネスモデル、組織構造は、新しいパラダイム、情報かと言ってもいいし、産業のソフトウェア化と言ってもいいし、あるいは流行りの言葉で言えばデジタルトランスフォーメーションに対応できていない。 ソフトウェア産業ではAppleはPCのベンダーからいつの間にかにクラウドやスマホのベンダーにピボットしている。ソフトウェア産業のジャイアントのMicrosoftもライセンスビジネスからモバイルファースト、クラウドビジネスへピボット(転身)している。 ソフトウェア産業では10年に一度くらいのパラダイムの転換があり、そのたびに勝者が変わっている。かつてはIBMであり、PC時代にはMicrosoftとIntelであり、インターネット時代にはGAFAと呼ばれるGoogle/Apple/Facebook/Amazonらにピボットした。 フィルムの時代の王者コダックはデジタル時代の今存在しない。富士フイルムは生き残った。 変化が早すぎる時代には栄枯盛衰が早い。 イノベーションのジレンマで知られるある分野でのトップ企業がはるかに規模が小さい新興企業に破壊される状況である。IT業界では、広く知られていて、滅ぼされる側の企業で働いていた人も多いので(自分もそうだ。DECという滅ぼされる側にいた)、実感としてその怖さを経験・理解している。 自動運転によって何ができるかを書かれた書籍は多い。本書はそれだけではなくその技術がどのように産業の変化を促しているかを記している。自分にとっての本書の気づきは、自動車産業が初めてのビジネスモデルの転換を必要としているということだ。 トヨタは生き残るのだろうか。そんな感想を持った。 濫読日記風 2018 知的生産の技術、梅棹忠夫著、読了、濫読日記風 2018、その18...
続きを読む...
 

2018年度OSS貢献者賞を受賞しました

北東アジアOSS推進フォーラム(11月14日〜16日、横浜)で、2018年度OSS貢献者賞を受賞した。ありがとうございました。 http://www.ossforum.jp/2018Yokohama 今回の受賞は「カーネル読書会」の活動などを評価していただいたもので、自分としてはちょっと昔の話なので、光栄ではあるが、若干申し訳ないような(?)感想を持った。*1 カーネル読書会は、ほんの思いつきで始めたLinuxカーネルの勉強会のようなもので、1999年4月に第一回を開催して、やってみたら思いの外、楽しくて、多くの人に参加いただいたこともあって、10年以上不定期に開催できた。近年、自分のモチベーションも下がってきて、勉強会の栄枯盛衰を一人で演じている感じもなくはないが、多くの貴重な経験を積むことができた。 過去の資料など http://www.ylug.org/modules/pukiwiki/?reading カーネル読書会をやってみて強く感じたことは、linuxのようなOSS (Open Source Software)と市井の草の根型読書会(勉強会)と言うのは非常に相性が良く、運営コストもそれほど高くないので、コア主宰者が元気であれば、永続性がある。一方で、運営が一人に集中すると主宰者がボトルネックになって自然消滅する。良くも悪くも主宰者のカラーに染まる。 IT系の勉強会が2000年代中頃から活性化して、コミュニティを形成するようになり、その過程で運営者の運営ノウハウも徐々に流通するようになってきた(勉強会勉強会など)。 勉強会の開催パターンなどは十分言語化されていないので、同じような失敗や苦労が繰り返されているようにも思える。先人の経験は口伝によって緩やかに継承されていくが、他のコミュニティへの伝播スピードは早くはない。 今だにビアバッシュのパターンなどが引用されているが、最近の人々はそもそもビールを飲まないのでビールの人数比なども微調整が必要である。カーネル読書会100回記念にはLinusも参加してくれて自分としては非常に思い出深い。*2...
続きを読む...
 

2018年度OSS貢献者賞を受賞しました

北東アジアOSS推進フォーラム(11月14日〜16日、横浜)で、2018年度OSS貢献者賞を受賞した。ありがとうございました。 *1 http://www.ossforum.jp/2018Yokohama 今回の受賞は「カーネル読書会」の活動などを評価していただいたもので、自分としてはちょっと昔の話なので、光栄ではあるが、若干申し訳ないような(?)感想を持った。*2 カーネル読書会は、ほんの思いつきで始めたLinuxカーネルの勉強会のようなもので、1999年4月に第一回を開催して、やってみたら思いの外、楽しくて、多くの人に参加いただいたこともあって、10年以上不定期に開催できた。近年、自分のモチベーションも下がってきて、勉強会の栄枯盛衰を一人で演じている感じもなくはないが、多くの貴重な経験を積むことができた。 過去の資料など http://www.ylug.org/modules/pukiwiki/?reading カーネル読書会をやってみて強く感じたことは、linuxのようなOSS (Open Source Software)と市井の草の根型読書会(勉強会)と言うのは非常に相性が良く、運営コストもそれほど高くないので、コア主宰者が元気であれば、永続性がある。一方で、運営が一人に集中すると主宰者がボトルネックになって自然消滅する。良くも悪くも主宰者のカラーに染まる。 IT系の勉強会が2000年代中頃から活性化して、コミュニティを形成するようになり、その過程で運営者の運営ノウハウも徐々に流通するようになってきた(勉強会勉強会など)。 勉強会の開催パターンなどは十分言語化されていないので、同じような失敗や苦労が繰り返されているようにも思える。先人の経験は口伝によって緩やかに継承されていくが、他のコミュニティへの伝播スピードは早くはない。 今だにビアバッシュのパターンなどが引用されているが、最近の人々はそもそもビールを飲まないのでビールの人数比なども微調整が必要である。カーネル読書会100回記念にはLinusも参加してくれて自分としては非常に思い出深い。*3 カーネル読書会を続けられたのも(最近はサボり気味で申し訳ないが)、YLUG(横浜Linux...
続きを読む...
 

未経験プログラマがコボルコンパイラを作った話をした #compiler_study

コンパイラ勉強会というちょっと心をそそる勉強会があったので参加した。勉強会っぽい勉強会(ってどんなだよ)に参加するのは久々だったので、つい出来心でLTでもしようかと思った。LTすれば定員オーバーでも参加できるだろうという下心があった。 https://connpass.com/event/103976/ LTのつもりでいたら、お時間30分も頂いてしまった。困った。モダンなコンパイラのことで話すネタを持っていない。こーゆー時はLLVMのことなどをさらっと話せるようになりたい。そこで温故知新、昔話でお茶を濁すことにした。ごめんなさい。「愚者は経験に学び、賢者は歴史に学ぶ」とかなんとか。*1 新卒で入社したDECでの最初のプロジェクトは日本語COBOLの開発だった。その話をネタにした。若い人はCOBOLという言語の出で立ちなどは知らないだろうから、昔話としてはちょうどいいと思った。COBOLの仕様はフリーだということを恐らく参加者は知らない。COBOL仕様書の謝辞の日本語訳を最初に紹介した。*2 未経験プログラマ(自分のことだ)が入社した頃(1980年代中頃)の実際使用していたマシンの性能は0.3MIPSだ。ムーアの法則によって、30年間で性能は100万倍くらい向上した。その当時、自分はムーアの法則という言葉すら知らなかったけど、計算機は速くなって、安くなって、小さくなった。 未経験開発者はソフトウェア開発のイロハを知らない。ソフトウェア開発をコーディングすることだと思っている。テストもしなければ、コード管理システムにチェックインもしない。そもそもコード管理システム(バージョン管理システム、今で言うところのgitみたいなもの)があるということも知らなければ、それを利用しないといけないという意義も知らない。コードを追加したり変更したらテストをしてコード管理システムにチェックインする。そーゆーことを知らない。 コードを書くことは開発プロセスのごく一部でしかない。 それよりも重要なことは開発環境を作って安定化することだ。ビルド環境を構築し、テスト環境を作る。毎日コードをビルドして毎日テストする。CI(Continuous integration 継続的インテグレーション)という言葉がない時代からCIのようなことを毎日行なっていた。 リグレッションテストを持つことによって、後方互換性を担保する。互換性を破壊するような変更は即座に発見される。コンパイラの開発だけではなく、OSの開発でも、ハードウェアの開発でもリグレッションテストは日々利用される。OSチームはOSの機能のリグレッションテストだけではなく、コンパイラや他の製品のリグレッションテストを実行することによって、OSの変更が他の製品に影響を与えていないか確認する。ハードウェア開発チームですら、OSやコンパイラなどのリグレッションテストを利用して互換性に影響を与えていないか確認する。 開発プロセスの中にバグ分析も組み込まれている。我々は自分が作った製品のバグについてあまりにも無知だ。どのようにバグを作り込んでいるか無頓着である。テストはそのバグを発見してくれる。そして学ぶ機会を提供する。我々はバグから学ぶスキルをもっと身につけなければいけない。 このようなプログラマとしての discipline を開発の中で学んでいく。身につけていく。コードを書いたらテストをする。バグを見つけたら記録して分析する。 30数年の経験で、変わったこと変わらなかったことがある。 計算機のコストが劇的に変化した。安くなったし、速くなった。 インターネットの登場で地球規模の開発が可能になった。地球の裏側の人と協同してプログラムを作ることが特別でもなんでもなくなった。 OSSが当たり前になった。OSSのライセンスが当たり前になった。コミュニティでの開発が当たり前になった。バザールモデルが広く知られるようになった。30数年前はそれが当たり前ではなかった。 もちろん、上記以外にもスマホが登場して世の中が変わった。 一方で変わらないこともいっぱいある。 ムーアの法則は何度も何度も終わったと言われたが、結局最初に提唱されてから50年以上現役でIT産業を牽引している。 プログラマの...
続きを読む...
 

未経験プログラマがコボルコンパイラを作った話をした #compiler_study

コンパイラ勉強会というちょっと心をそそる勉強会があったので参加した。勉強会っぽい勉強会(ってどんなだよ)に参加するのは久々だったので、つい出来心でLTでもしようかと思った。LTすれば定員オーバーでも参加できるだろうという下心があった。 https://connpass.com/event/103976/ LTのつもりでいたら、お時間30分も頂いてしまった。困った。モダンなコンパイラのことで話すネタを持っていない。こーゆー時はLLVMのことなどをさらっと話せるようになりたい。そこで温故知新、昔話でお茶を濁すことにした。ごめんなさい。「愚者は経験に学び、賢者は歴史に学ぶ」とかなんとか。*1 新卒で入社したDECでの最初のプロジェクトは日本語COBOLの開発だった。その話をネタにした。若い人はCOBOLという言語の出で立ちなどは知らないだろうから、昔話としてはちょうどいいと思った。COBOLの仕様はフリーだということを恐らく参加者は知らない。COBOL仕様書の謝辞の日本語訳を最初に紹介した。*2 未経験プログラマ(自分のことだ)が入社した頃(1980年代中頃)の実際使用していたマシンの性能は0.3MIPSだ。ムーアの法則によって、30年間で性能は100万倍くらい向上した。その当時、自分はムーアの法則という言葉すら知らなかったけど、計算機は速くなって、安くなって、小さくなった。 未経験開発者はソフトウェア開発のイロハを知らない。ソフトウェア開発をコーディングすることだと思っている。テストもしなければ、コード管理システムにチェックインもしない。そもそもコード管理システム(バージョン管理システム、今で言うところのgitみたいなもの)があるということも知らなければ、それを利用しないといけないという意義も知らない。コードを追加したり変更したらテストをしてコード管理システムにチェックインする。そーゆーことを知らない。 コードを書くことは開発プロセスのごく一部でしかない。 それよりも重要なことは開発環境を作って安定化することだ。ビルド環境を構築し、テスト環境を作る。毎日コードをビルドして毎日テストする。CI(Continuous integration 継続的インテグレーション)という言葉がない時代からCIのようなことを毎日行なっていた。 リグレッションテストを持つことによって、後方互換性を担保する。互換性を破壊するような変更は即座に発見される。コンパイラの開発だけではなく、OSの開発でも、ハードウェアの開発でもリグレッションテストは日々利用される。OSチームはOSの機能のリグレッションテストだけではなく、コンパイラや他の製品のリグレッションテストを実行することによって、OSの変更が他の製品に影響を与えていないか確認する。ハードウェア開発チームですら、OSやコンパイラなどのリグレッションテストを利用して互換性に影響を与えていないか確認する。 開発プロセスの中にバグ分析も組み込まれている。我々は自分が作った製品のバグについてあまりにも無知だ。どのようにバグを作り込んでいるか無頓着である。テストはそのバグを発見してくれる。そして学ぶ機会を提供する。我々はバグから学ぶスキルをもっと身につけなければいけない。 このようなプログラマとしての discipline を開発の中で学んでいく。身につけていく。コードを書いたらテストをする。バグを見つけたら記録して分析する。 30数年の経験で、変わったこと変わらなかったことがある。 計算機のコストが劇的に変化した。安くなったし、速くなった。 インターネットの登場で地球規模の開発が可能になった。地球の裏側の人と協同してプログラムを作ることが特別でもなんでもなくなった。 OSSが当たり前になった。OSSのライセンスが当たり前になった。コミュニティでの開発が当たり前になった。バザールモデルが広く知られるようになった。30数年前はそれが当たり前ではなかった。 もちろん、上記以外にもスマホが登場して世の中が変わった。 一方で変わらないこともいっぱいある。 ムーアの法則は何度も何度も終わったと言われたが、結局最初に提唱されてから50年以上現役でIT産業を牽引している。 プログラマの...
続きを読む...
 

GCC5以降のlibstdc++のデフォルトABI変更について

GCC 5 以降の C++ ライブラリ、libstdc++ はデフォルトの ABI が変更されているため、それ以前の g++ でコンパイルしたバイナリとは(デフォルトでは)リンク互換性がありません。ただし、旧...
続きを読む...
 

GCC5以降のlibstdc++のデフォルトABI変更について

GCC 5 以降の C++ ライブラリ、libstdc++ はデフォルトの ABI が変更されているため、それ以前の g++ でコンパイルしたバイナリとは(デフォルトでは)リンク互換性がありません。ただし、旧...
続きを読む...
 

Ubuntu(x86_64)上でAArch64 Linuxターゲットのcompiler-rtライブラリをビルドする方法

LLVM/Clang/compiler-rt は 3 つがセットになって初めて動作します。LLVM/Clang はマルチアーキテクチャ(例:ARM/AArch64/X86)、マルチターゲット(例:arm-eabi、arm-linux-gnueabi、arm-linux-gnueabihf、aarch64-elf、aarch64-linux-gnu)のコード生成が可能なのですが、ライブラリの compiler-rt だけは、3 つを 1 度にビルドしようとした場合に、1...
続きを読む...
 
10 / 101 ページ
Linux Foundationメンバーシップ

30人のカーネル開発者

人気コンテンツ


Linux Foundationについて

Linux Foundation はLinux の普及,保護,標準化を進めるためにオープンソース コミュニティに資源とサービスを提供しています

 

The Linux Foundation Japan

サイトマップ

問い合わせ先

サイトに関するお問い合わせはこちらまで

Linux Foundation Japan

Linux Foundation

Linux Training

提案、要望

Linux.com JAPANでは広く皆様の提案、要望、投稿を受け付ける予定です。

乞うご期待!