Linuxの最近のブログ記事
2009年12月28日
GoogleのOS「Chrome OS」のオープンソース版「Chromium OS」をインストールしてみた
少し（約一ヶ月）前の話ですが、来年リリースされる予定のGoogleのOS「Chrome OS」のオープンソース版「Chromium OS」を仮想環境でインストールしてみました。 
電源のON/OFFとか。
触ってみた印象だと、思想的にかなり先走ってる感じです。
最近は世間はクラウド、クラウドとか騒がしいですが、もはやOSごとクラウドな感じです。
ブラウザ以外はみんなネットワークのあちら側な感じ。
このOSにはローカルはありません。ほとんど。文書作成や表計算データやメールやPDF、etc...様々なデータを扱えますが、そのデータをPCの中に保存することはできません。
みんなネットワークの向こう側に保存します。
評判どおり起動は本当にあっという間です。
時間は計っていませんが、スペック的に厳しい仮想環境でも、ウチの液晶テレビより起動は早い。
とってもエッヂが効いてていい感じなので、どうか世間の風に流されずにトンがったまま登場して欲しいです。
オペレーティングシステムを選択します。とりあえず上記のような感じ。
終了。
名前を付けて保存。
起動。まじ速ぇ・・・バーチャル環境なのにあっという間に起動します。
メールは有無を言わさずGｍailです。
このブログを表示してみる。フツーに表示可能。
アプリケーション（WEBアプリ）の選択画面。
電源のON/OFFとか。といった感じで起動したOSの中はまんまGoogle Chromeブラウザな感じです。
どこがどう違うとかいろいろ意見はあると思いますが、遠くない将来、PC環境はこうなるだろうと感じます。
この環境を使いこなすには、今はそれなりの創意工夫が必要になると思います。
でも、いずれはほとんどのデータはネットワークのあちら側におくことになるでしょう。
パーソナルコンピューティングの進化の方向を間違いなく向いています。
ただ・・・ほとんどの人に先走り過ぎている印象をあたえるのは間違いなさそうです。
Gmail、Google AppsやEverNote、Flickr、Remember The Milk、MediaMarker等々、クラウドを活用したアプリケーションを使うようになると、今までは当たり前にローカルに置いたデータがなんと不便に感じられることか。
万人に受け入れられることは無いOSだと思いますが、これから様々なOSの思想に影響を与えるのは間違いなさそうです。
2009年10月 2日
Movable Typeの再構築チューニング(MySQL:ストレージエンジン)
MTを使ったサイト構築テクニック (2): ネタフルにおける再構築チューニング
今回は、コグレさんのTwitterをきっかけに、再構築の時間が9時間を超える (テスト環境での実測値) というネタフルの再構築チューニングをお手伝いしたので、それをご紹介します。
９時間の再構築が１時間っ！なっなんですとっ！
ロベルト・モレノでまあまあ満足してたのにミハエル・シューマッハー見つけちゃったフラビオ・ブリアトーレと同じくらいの衝撃を受けたのでさっそく本ブログで検証してみました。
まあ本ブログはだらだらと長く続いてはおりますが、記事数は４００程度とネタフルとは規模が全く違います。が、とりあえず手を動かしてみる事が大事かなと。
まず、現在の状態での再構築時間を計測してみる。
本ブログが設置されているのは最先端IT テクノロジー企業ライフコーポレーションの最先端テクノロジーの粋（スィ）を投入して独自開発した最先端コマンダトーレスーパースペシャルV12気筒仕様専用サーバー・・・。
うそ、ほんとのところは会社で用済みになったPCの部品を寄せ集めて作ったジャンクサーバです。
今ブログ書いてるデスクの裏に置いてある。
CPU:忘れたけどたぶんPen4だった気がする。
メモリ:１G積んだ記憶がある。
OS:Fedora8（だったよな・・・）。
MySQLのストレージエンジンはMyISAM。
１１分５０秒。
とりあえずの叩き台。
インストレーションLAPとしてはこんなもんか？
次に
mysql> ALTER TABLE [テーブル名] ENGINE='InnoDB';
ストレージエンジンをMyISAM→InnoDBへ変更。
Yagishitaさんによると、
シックス・アパートのエンジニアが以前試験したところ、MyISAMよりもInnoDBの方がパフォーマンスがいいという結果を聞いていたので、ワクワクしながら、次のコマンドを実行してInnoDBに変更していきます。
とのことで、当方もワクワクしながら計測してみる。
デフォルトでは innodb_buffer_pool_size は8MBになってました。
１１分４０秒。
まあ若干速くはなってますが、高速化なんていうほどのものではない。
３５億くらい払ってキミ・ライコネン乗せたのにフェリペ・マッサとどっこいどっこいで複雑な気分のフェラーリの監督：ジャン・トッドと同じ気分。
innodb_buffer_pool_read_requests と innodb_buffer_pool_reads の値を見たヒット率は９１．９％。
次にinnodb_buffer_pool_size を１６MBにしてみる。
１１分３９秒。
最終的にこれが本日のファステストLAPになるのですが殆ど誤差ですな・・・。
innodb_buffer_pool_read_requests と innodb_buffer_pool_reads の値を見たヒット率は８３％・・・。
落ちてるし。
innodb_buffer_pool_size を３２MBまで上げてみる。
１１分４５秒。
悪化した。
innodb_buffer_pool_read_requests と innodb_buffer_pool_reads の値を見たヒット率は９３．５と上がってはいるんですが。
本ブログの環境ではこのあたりいじってもあまり高速化はしなそうな雲行きなのでこの辺で。やっぱ今はエンジンよりもエアロかね。
2009年1月20日
suでスーパーユーザーなのに[command not found]
日々の生活の中で、よくやることなのにふと考えると「これって無駄じゃね？」とか思うことってありませんか？
サーバーを管理するときにSSHという接続を使ってログオン後に
と打って"rootへスイッチ"するんです。
「su -」はサーバー管理する人間には「おはようの挨拶」みたいなものなのですが、ふと「-(ハイフン)って必要なのか？」と思いました。
長いこと使ってるツール（コマンド）なのに、当たり前すぎて意味について考えたことが無かったのです。
で、やってみたらハイフンなしでもrootへスイッチできました。
「なんだハイフンなくてもrootにスイッチできるじゃないか。もしかして今まで何万回（もっと？）と打ってきた-(ハイフン)は無駄だったのか？」
と思ったのですが、いろんな作業で「command not found(そんな作業コマンドはねぇ)」と言われてしまいます。
で、ちょっとググってみたら
サーバーを管理するときにSSHという接続を使ってログオン後に
su -
と打って"rootへスイッチ"するんです。
「su -」はサーバー管理する人間には「おはようの挨拶」みたいなものなのですが、ふと「-(ハイフン)って必要なのか？」と思いました。
長いこと使ってるツール（コマンド）なのに、当たり前すぎて意味について考えたことが無かったのです。
で、やってみたらハイフンなしでもrootへスイッチできました。
「なんだハイフンなくてもrootにスイッチできるじゃないか。もしかして今まで何万回（もっと？）と打ってきた-(ハイフン)は無駄だったのか？」
と思ったのですが、いろんな作業で「command not found(そんな作業コマンドはねぇ)」と言われてしまいます。
で、ちょっとググってみたら
「su」でスーパーユーザーになったのに，コマンドを実行すると「command not found」と表示されてしまう
一般ユーザーのPATHに指定されるディレクトリの数は，root（スーパーユーザー）に比べて少なくなっています。rootのPATHには/sbinや /usr/sbinも設定されているため，コマンド名だけですべてのコマンドを実行できます。suコマンドでroot権限に変わるときに，「-」オプションを付けると環境変数はrootのものになります。
-(ハイフン)はやっぱり必要だったのねん。。。
今まで何万回と打ってきた-(ハイフン)は無駄では無かった・・・というお話でした。
