2016年12月29日木曜日

Intel HD Graphics のマシンで,Wine の DirectX をいいかんじにやってもらいたい(ArchLinux)

実は,数年前より,フリーのグラフィックスライブラリである Mesa において,DirectX 9 がネイティブに扱えるようになっています.と,言うのも,Mesa が導入した Gallium 3D というもののおかげです.

これは,OpenGL や DirectX のバックエンドとなる,3D 描画一般の標準的な API を提供するレイヤです.そこで,Wine についても,この Gallium を使って DirectX 9 をネイティブに描画する,Gallium nine patch というものが存在しています.
# pacman -S wine-staging-nine
このパッチが当たった wine では,winecfg の staging タブで Gallium Nine を有効化するだけで使えるようになります.しかし,Intel HD Graphics のマシンでは,
ilo: driver missing
と出てしまい,DirectX を使うアプリケーションの起動が失敗するようになってしまいます.
そこで,解決方法は,次の通りです.

  1. # pacman -S abs && abs /var/abs/ にパッケージビルドレシピをダウンロード
  2. $ cp -r /var/abs/extra/mesa $HOME/
  3. PKGBUILD を編集し,--with-gallium-drivers= へ,ilo を追加
  4. $ makepkg -i によりパッケージビルド,インストール
これで,Wine で DirectX をいいかんじにやってもらえるようになります.ただし,已然として不具合や欠けている機能の多いものなので,正しく動作しない可能性も高いです.その場合は,Gallium Nine を無効化して,諦めて従来の描画方法に頼りましょう.

2016年12月26日月曜日

インドのふたつのカレー

カレー Advent Calender 2016 22 日目の記事です.

カレー†1の本場と言えば,言わずもがな,インドです. インドカレー屋は,案外街のあちこちにあったりして,馴染み深い人も多くなったんではないでしょうか.ところで,インドカレーと一口にいっても色々あります.大きく,北インド南インドでそれぞれ分けられます.北インドでもパンジャブ地方のパンジャブ料理と,ムガル帝国†2の宮廷料理であるムガル料理など,いくつか種類がありますが,タンドールを使った料理,ナンや,バターチキンカリーといったものを生み出したパンジャブ料理は日本でよく知られています.
この,南北ふたつのカレーについて,特徴を紹介しようと思います.

スパイス

北インドカレー

インドカレーの南北をそれぞれ象徴付けるのは,やはりスパイスです.北インドカレーでは,カルダモンクローブシナモンローリエといったものが,よく使われるようです.カルダモンは,スパイスの女王と呼ばれる,さわやかな香りが特徴的です.
カルダモン - 画像は Wikimedia commons より
クローブは,肉料理によく使われ,臭み消しだったりします.中国だと丁子
クローブ - 画像は Wikimedia commons より
ローリエはあの冠とかに使われる月桂樹の葉っぱ,と言えば通りが良いかと思います.この画像のような大きめの葉っぱが煮こまれて入ってるカレーとか,インド料理レストランで食べたことないですか?
ローリエ - 画像は Wikimedia Commons より
シナモンはみなさんご存知ですね.エジプトでミイラ保存料として使われたり,聖書に出てきたり,歴史の古いスパイスです.甘い香りがして,おかし作りなどに出てきますね.
シナモン - 画像は Wikimedia Commons より

こういったスパイスを,ホール(粉にしない,実や葉,樹皮のようなスパイスのそのままの形)で使うのが北インドカレーです.それも,最初に油でこれらを炒めて,作った香油を,鶏肉など材料に絡めて,調理していくというのが,大きな特徴となります.ちなみに,ここで書いた中でも,カルダモンやクローブ,シナモンは,ハウス食品や S&B が瓶詰めのスパイス粉として発売している「ガラムマサラ†3」の中によく入ってます.
東京都,神田神保町のインド料理屋,マンダラ.筆者撮影.

南インドカレー

対して,南インドではどのようなスパイスを使うのでしょうか.ホールスパイスとして使うものとして代表的なのは,マスタードシード赤唐辛子カレーリーフ
マスタードシードは,白芥子の種子です.あのマスタードの原料そのもの.場合によっては,粒入りマスタードなどにも使われる表皮の黒い黒芥子の種子も使われるようです.
マスタードシード - 画像は Wikimedia Commons より
唐辛子は言わずもがなですね.原産は中南米,現在のメキシコあたりなので,実は大航海時代の新大陸発見まで存在は知られてなかった,比較的新しいスパイスです.
赤唐辛子 - 画像は Wikimedia Commons より
カレーリーフは大葉月橘という木の葉っぱ.これはインド原産だそうです.橘という字が入っている通り,柑橘系のような香りが特徴だそうです.
カレーリーフ - 画像は Wikimedia Commons より
南インドカレーでは,これらのホールスパイスを使い作った香油は,料理の最後に入れることで使います.この,ホールスパイスを使うタイミングも大きな違いのひとつですね.
神戸三宮にある南インド料理屋,マドラスキッチン.筆者撮影.

パウダースパイス

色付けのターメリック(ウコン),肉料理の臭み消しでも有名なクミン,そしてコリアンダー胡椒.こういったスパイスを粉にしたパウダースパイスや,カルダモン・クローブ・シナモンなどをあらかじめ粉にしたパウダーのガラムマサラなんかは,北インドカレーでも南インドカレーでも,調理に使います.ホールスパイスと違って,玉葱のような香味野菜やトマトと一緒に炒めまくって使います.ちなみに,実はコリアンダーって中国だと香菜(シャンツァイ)と呼ばれたり,タイ料理だとその葉がパクチーと呼ばれたりします.ご存知でしたか?また,南北ともに,香味野菜やトマト,パウダースパイスを炒めた塊を,マサラといって,これに水を足して煮込めばカレーになります.ここで,香味野菜や具材を炒める段階でホールスパイスの香油を入れるか,最後に煮込んだあとにホールスパイスの香油で香り付けするかが,北と南を分けることとなります.

具材

北インドカレーは,鶏肉やマトン(羊)が中心.カシミヤで有名なカシミール地方も元はムガール帝国の版図ですし,パンジャブ料理のタンドールなどは現在のパキスタンとインド両方で使われましたからね.今は,立派な紛争地帯ですが…….対して南インドは,魚介類や野菜がメインです.とはいえ,サグ(ほうれん草)を使う,チキン・サグのように,北インドカレーだから野菜を使わない,というわけでは全くありません.ただ,メインの食材が違うということになりますね.

主食

北インドでは前述の通りタンドールの発祥でもありますし,ナンのようなものをカレーと共に食べますが,実は南インドカレーではご飯と一緒に食べます.とはいっても,勿論米はインディカ米ですね!スパイスの節で掲載した画像も,それぞれナンの付いたカリーと,ごはんの付いたカリーになってますね?

インドカレーのススメ

さて,スパイスや具材,調理手順から,北と南,ふたつのインドカレーを紹介しました.ところで,インドカレーって基本的にレストランで食べて,おうちカレーは日本カレー,という方が多いと思います.しかし,実は試してみるとそれっぽいカレーは案外おうちでも作れたりします.パウダースパイスの節でも書きましたが,炒める,煮込む,これだけなので,あとはスパイスを揃えるだけですね(これが大変なのですが).とはいっても,これまで書いたように,インドカレーは多様です.そこで,次の本は,自宅でインドカレーを作るのにとっても役立ちます.

これは,銀座のカレーレストラン,「ナイルレストラン」のシェフによるレシピ本で,北インドカレーと南インドカレーの違いも含めて,様々なレシピが紹介してあります.カレーだけでなく,カレーとあともう一品,というときのインド料理の一品や,インド料理の主食などのレシピも紹介されており,とても素晴しいです.

ちなみに,芸能界屈指のカレー通として有名なタモリさんは独自のレシピを考案したりしていますが,カレー粉はナイル商会のインデラ・カレー粉とこだわっているそうです.このナイル商会のカレー粉は,「ナイルレストラン」初代オーナー G. M. ナイル氏との出会いによって生まれたそうで,公式サイトにナイル氏のコメントが寄せられています.
筆者が作ったタモリさんレシピのカレー.インデラ・カレー粉を通販で買いました.
筆者がタモリさんのレシピのカレーを作ったときの様子はこの記事です.

おまけ

私は最近,カレー粉(パウダースパイス)に,RAJ というメーカーのスパイスを使ってます.
というのも,JR 秋葉原駅の南側の高架下,ニュー秋葉原センターの奥に,ヒンドゥー系っぽい人が営業している食料品店があったので,つい買ってしまったのです.これが,なかなか本格的な薫りがして,結構気にいっています. これはカレー粉ですが,他にもいろいろ日本のスーパー等でみかけないパッケージのパウダースパイスが置いてあったので,一度足を運んでみると楽しいかもしれないです. 最後に,最近作ったバターチキンカレーの画像でお別れです.

脚注

†1:元々はタミル語.タミル語はドラヴィダ語族に属する.インドの言葉について,主たる公用語であるヒンドゥー語や,仏教で真言を表わすのに使われる悉曇文字の悉曇が指す,古典語のサンスクリット語などといったものは,インド・ヨーロッパ語族に属しているが,これはヨーロッパの人種とも祖を同じにするアーリア人がインド北部に攻め込んだため.タミル語のようなドラヴィダ語族を操る人達は,このアーリア人に追われて南インドまで逃げ込んだ.ここではアーリア人とはインド・ヨーロッパ祖語を話していた人々のことを指す.
†2:16 世紀のパンジャブ含む北インドから始まり 19 世紀まで続いた,最盛期に南インドの一部を除くインド亜大陸と現在のパキスタンあたりをほぼ版図に収めた帝国
†3:熱い(ガラム)+ミックススパイス(マサラ)の意.ちなみにここで紹介したホールのスパイスをまとめてホール・ガラムマサラと言うことも.

参考文献

[1] ナイル善己(2014)「「ナイルレストラン」ナイル善己のやさしいインド料理」世界文化社.ISBN: 978-4418143030

2016年12月20日火曜日

Rust で nostd(と UEFI)

Rust Advent Calender 2016,19 日目の記事です.

Rust で OS 作ったりなんだり,簡単にできるといいなあってことで.

まず,Rust で nostd な環境でどのようにすれば良いのか,なのですが,単純にこれだけならば,Rust の公式ドキュメントに載っています.
https://doc.rust-lang.org/book/no-stdlib.html
基本的には,nostd をコンパイラに指示して,lang_item を使っていくつかの不足のシンボルを定義してあげます. また,ここで panic_fmt をいい具合に定義するときっと panic!() とか使うのに役立つ(と思います).

ここからが,ちょっとした TIPS になります.
実際に本当に使える何かを作ろうとしたとき,何もないと不便で,作りづらいです.そこで,Rust の libcore,つまり core ライブラリを使って, core::fmt::Display でフォーマット文字列使ったり,core::mem::size_of で特定の型のメモリサイズを取得したり, core::ptr::null で null pointer 作ったり core::ptr::swap でポインタの中身を取り替えたり,そういう unsafe な部分も 組込みっぽい場所で必要になるでしょう.しかし,これらを使うにも,クロスコンパイルの時には,Rust のソースを全部もってきたりして,手動で core ライブラリを ビルドしてリンクさせないと使えなかったりするのです.

そこで便利なのが,xargo です.次のように使えます.
$ cargo install xargo
$ export PATH=$HOME/.cargo/bin:$PATH
$ xargo build
普段のcargoの代わりに,ビルドなどにこのコマンドを使うと,cargoのラッパーとして動作し,しかも core ライブラリ等を自動でビルド,リンクしてくれます. 結構地味に便利なので,ぜひ.

最後に,宣伝というか.
UEFI で動かせるナニカを Rust で作りたいなーと思いつつ,放置してたのですが,crates.io に uefi というライブラリがあったので,手を出しはじめました. しかし,実装が全然足りてなかったので,少しづつ足したり直したりしながら使ってます.
https://github.com/orumin/rust-uefi
コントリビューションだとかツッコミだとか,色々手を貸して下さる方がおられるのならとても嬉しいです.

2016年12月8日木曜日

HIL: Designing an Exokernel for the Data Center

遅刻しました.ごめんなさい.
本稿はシステム系論文紹介 Advent Calener 2016,2 日目の記事になります(大遅刻).
今回はHIL: Designing an Exokernel for the Data Center を紹介します.

原論文

J. Hennessey, S. Tikale, A. Turk, E. U. Kaynar, C. Hill, P. Desnoyers and O. Krieger, “HIL: Designing an Exokernel for the Data Center″, in 7th ACM Symposium on Cloud Computing, ser SoCC '16, Santa Clara, CA, USA: ACM, Oct. 2016, pp. 155―168, ISBN: 978-1-4503-4525-5. DOI: 10.1145/2987550.2987588. [Online]. Avaliable: http://doi.acm.org/10.1145/2987550.2987588.

前提

1. Exokernel
まず始めに,表題にもある,Exokernel について説明しなければなりません.Exokernel とは,1995 年に生まれた技術です[1]. 図1を見てください. これは,マイクロカーネルよりさらに一歩進めて,security bindings 以外を全てカーネルから追い出してしまい,従来のカーネルのサブシステムは,全てアプリケーションとリンクするライブラリとしてしまうアーキテクチャです.この,従来の OS の機能を持つライブラリを,libraryOS と言います.リソース管理などの機構をアプリケーション毎に特化させる事を容易にし,また,複数のアプリケーションの,デバイスや計算資源へのアクセスの分離(isolation)とその管理(management)をそれぞれ Exokernel と libraryOS で全く分けてしまえる事が特徴のアーキテクチャでした.

TL;DR

さて,今回紹介する論文は,この Exokernel のような抽象層を,ベアメタルクラウドのデータセンタに導入する試みです.
  • 双方向に信頼されないベアメタルのデプロイメントサービス(OpenStack Ironic, MaaS, xCAT ..)
  • これらサービスでデータセンタの計算資源を効率的に共有
  • 効率化のみならず新しい経済モデル,新しいアプリケーション,新しいセキュリティ特化型の利用,を可能にする(と論文の筆者は信じている)

背景と問題点

現在様々な物理サーバー向けのデプロイ/プロビジョニングのツールがありますが,これらは全て,低レイヤを覆い隠し, また,イメージデプロイツールを通して抽象化することでアプリケーションやサービスを物理システムの上に展開する事を簡単にするという共通の目的があります.
しかし,OpenStack Ironic は勿論 OpenStack ユーザ向けですし,xCAT は HPC 分野でのデプロイのためのツールで,用途によって様々です. 抽象化の実現の仕方も様々ですので,すると例えばクラスタの管理者はソフトウェアのデプロイに Ironic を使うのか MaaS を使うのか決断する必要がありますし,データセンタの管理者達は,それぞれのツールをユーザが使えるように,サーバ群を静的にパーティションして備えるといったことが起こります.
ユーザが新しいツールを使いたかったとしても,さらにサーバ群をいくつか新しいツールのために使えるよう準備しておかなければならないため,結果としてデータセンタ管理者はそれを避けようとします.つまり,新しいツールが出ても中々使えない状況が起こります.
そこでこの論文では,Hardware Isolation Layer(HIL)というレイヤを導入することで,複数のベアメタルデプロイツール間で計算資源の共有を可能とし,データセンタの効率化を果たすというのが目的になります.

概要

2. HIL の概要図
HIL の役割は主に,物理サーバやネットワークの確保と,これら確保したものを複数のデプロイサービス間で分離することです.しかも,その構成について,手動の管理なく再構成が可能になります.具体的には,1) 物理サーバの確保 2) ネットワークの確保 3) サーバとネットワークの接続,が HIL が提供する基本的な機能です.また,追加的な機能としては,1) HIL のマネージドネットワークへの VPN 接続 2) パワーサイクルやブートデバイス選択のようなものを安全に行なうノード管理機能 3) 確保されたリソースの追跡,などがあります.また,サーバープールごとに 1 つの HIL インスタンスを置き,管理することで,巨大なデータセンタを複数の会社や研究グループが管理する状況にも対応します.

構造

3. HIL のデプロイのコンポーネント
HIL の構造について,図3. を見て下さい.HIL のコンポーネントは, 3 つに分類され,コアコンポーネント,システムドライバ,オプショナルサービスとなります.本稿ではオプショナルコンポーネントについては割愛します.原論文を参照ください.

HIL API

HIL の資源は,ユーザの集合に管理される project が基本になっており,この projectnodesnetworks という要素を持っており,nodes,つまりサーバは networks へ接続される NICs を持ちます.REST API を通じて操作され,ユーザは次の操作が可能です.
  • プロジェクト作成・空のプロジェクト削除
  • ネットワーク作成・削除,パブリックネットワークのプロジェクトへの取り込み
  • プロジェクトへのノード確保・プロジェクトからノードの解放
  • ネットワークへの NICs 接続・ネットワークからの NICs 切断
  • パワーサイクルやシリアルコンソールへのアクセスのようなノードの管理
  • 空いてるノードの一覧表示,プロジェクトへのノードとネットワーク割り付け,ノードやネットワークの詳細取得,などのクエリ

コアコンポーネントとドライバ

HIL Server
HIL のロジックの実装の大半と HIL の REST API,データベースのインターフェース,操作エンジン,アウトオブバンド管理1 のドライバを持ちます.
OBM and Auth drivers
HIL は,OBM(=アウト・オブ・バンド管理)ドライバを通してベアメタルのノードを制御します(パワーサイクルや,ネットワークブート,シリアルコンソールのログへのアクセス).OBM ドライバは,IPMI を使って実装され,プログラムインターフェースを提供します.また,認証と認可の決定は,auth driver へ転送されます.リクエストの説明,受け取った決定(認可の可否),オプションで認可トークンをドライバに渡すことで,認可が実行されます.
Operation Engine
ネットワーク構成の変更のような,調整操作のシーケンスへ責任を持つエンジンです.API サーバからキューを通してリクエストを受け取り,リクエスト順に処理を実行し,最終的に完了したらデータベースを更新します.
Switch drivers
operation engine がネットワーク接続の操作を行なう際に実際にその操作を受け持つ実装になります.VLAN などを用いて,他のプロジェクトや外部システムから,プロジェクトへのアクセスを拒否し保護するといった事を実現します.

評価

1. 13 ヶ月間のクラスタで実行された操作の統計
2. 秒当たりの中央値と標準偏差
プロトタイプ実装は 3000 行以下(ただし PoC).48 の Cisco UCS C220 M32 ノードで日々基本的な production に使用されています.表1. は,このクラスタで,HIL を 13 ヶ月間稼動させ取った操作の数の統計で,表2. はこれらのコアの操作について,かかった時間の中央値と標準偏差を取ったものです.これは各操作を 250 回繰り返した場合の統計値です.スイッチと対話しない,データベースの操作のみで完結する操作の場合,数十ミリ秒で操作が終了しており,ネットワークの接続を要する操作も数秒で終わっています.
4. 同期的な API の並列性
5. 非同期的な API の並列性
4. は同期的な API の実行を,クライアント数を増加させた場合の処理にかかる時間を見たものです.基本的に,クライアント数が増えても実行時間は増えておらず,alloc_net と free_net は多少実行時間が増えていますが,スケーリングしていると言えます.ノードの解放だけ異様に実行時間が長いのは,ノードの解放の前に ipmitool を実行してコンソールを接続する必要があるため, 他の操作に比較して 5 倍という実行時間になっているようです.図5. は非同期な API の実行における並列性です.この操作は,ネットワークスイッチへの対話が必要であり,この計測では全てのリクエストが同一のスイッチに向けられていることがボトルネックになってします.スイッチがスケールするより巨大な環境で,HIL に最適化されているのであれば,並列性はさらに向上するのではないかと原論文の著者は推測しています.
6. HIL で区画された環境へ,Hadoop 環境をベアメタルと仮想環境(OpenStack)それぞれ用いてデプロイした時のパフォーマンス
次に,HIL をベアメタルサービスで用いた場合のデモンストレーションについてです(図6.).1) HIL で 8 ノード確保し,2) Foreman を用いて Red Hat Enterprise Linux をプロビジョニングし,3) Apache BigTop でビッグデータ処理環境をベアメタルにデプロイし,4) CloudRank-D ベンチマークを用いた結果となります.比較対象となる仮想化環境は,MOC(Massachusetts Open Cloud)の OpenStack (Kilo リリース版)を同一のクラスタの idle のノードで実行し,同一テストを走らせたものです.仮想の Hadoop 環境は 1 ノード 1 VM で動作され,各 VM はホストの 90 % の資源が与えられています(残りの 10 % はハイパーバイザに予約されている).仮想化によるオーバーヘッドの分,ベアメタルのほうが性能が勝っています.
ところで,HIL そのものは,例えばリクエストに対しどのノードを確保するべきか選択する,といったようなスケジューリングはしません.そこで,HPC クラスタで広く使われている SLURM スケジューラを導入し,HIL リクエストに特別の名前空間を設けることで,HIL と SLURM を共存させることにも成功しています.

経済効果

7. 1 週間での リアルタイムワークロードと HPC ワークロードが必要とした c4.xlarge インスタンスの数
8. 1 週間でのシステムの利益(5000 の Linux がホスト可能な,US-East-1a にある c4.xlarge の EC2 インスタンス)
実際のデータセンタで HIL が使われると仮定します.たとえば,Amazon EC2.現在オンデマンドにインスタンスが借りれますが,HIL によってオンデマンドにクラスタ単位での貸し出しが可能となり,これは大規模ゲームサーバや HPC のようなリアルタイムアプリケーションで有利になります.MMO ゲームは,それぞれ使い方が異なる,極度に特化したソフトウェアを分散サーバファームを通して配信しますし,多くの HPC ライブラリやアプリケーションも同様にとてもハードウェアに寄りの動作をする設計になっているので,OS のドライバやハードウェアのサポートを必須としています.HIL ならば,仮想化されているサービスとそうでないサービスの間で,物理ノードの数を動的に調整できます.つまり,HPC に使われていたノードを,クラウドサービスで使うノードに転用する,ということを,オーバーヘッドをかなり少なく(一時間以内で)行なえるのです(サーバの再起動と再プロビジョニングの分の時間はかかっていますが).
7. はログデータによる,HPC ワークロード(SunGrid Engine)とリアルタイムワークロード(ゲーム,MineCraft)の必要とする c4.xlarge インスタンス数の一週間でのプロットです.
8. は,5000 の Linux を c4.xlarge EC2 インスタンスで貸し出せると仮定した架空の AWS のようなベンダの,一週間での利益を図示したものです(ただし,オンデマンドで貸し出せず,スポット市場3を通して貸し出すものとする).このインスタンスは 5000 を超える物理ノードで提供されると仮定します.さて,図8. の緑の線は,スポット市場で全部のノードが貸し出された場合の利益です.しかし,もし図7. の HPC ワークロードに全て貸し出し,残ったノードを仮想化してスポット市場に貸し出すのなら,赤の線がその利益となり,単純にスポット市場に全部貸し出すよりも 30 % も高い利益が得られます.同様にリアルタイムワークロードで考えると,青い線,50 % の利益向上が見込めるそうです4

まとめ

本稿で紹介した論文では,HIL をデータセンタの基本的な抽象層として導入しました.HIL は異なるハードウェアと仮想プロビジョニングシステムの下のレイヤとなるため設計され,サービス間の強力な isolation を提供することで,新しいデプロイサービスの導入をラクにし,また,異なるデプロイサービス間での資源の移動を効率的に可能にしました.また,HIL によって Hadoop 環境のベアメタルなデプロイサービスとしても動作可能であること,SLURM スケジューラを MaaS や Ironic,Emulab といったベアメタルプロビジョニングツール同様に導入可能であることを実証・議論しました.さらに,異なるサービス間で,サービスのキャパシティを移動させる事についての経済効果も明かにされました.現在(論文の提出された 2016 年 10 月現在)MOC で HIL が 2016 年 1 月より使われ,100 以上のユーザが日常的に使用しているようです.

本稿のまとめ

本稿では,HIL: Designing an Exokernel for the Data Center について紹介しました.実のところ Exokernel に関連する論文だと思ってとりあえず読みながら記事を書いていたのですが,途中でこれは Exokernel から着想を得ただけで分野違ったなーと若干後悔しています.しかしながら,同じシステム系でも OS アーキテクチャとデータセンタでのプロビジョニングは結構違う分野ですが,こうやって着想を得て活用されるというのはなかなか面白いですね.
Web でたまにマイクロサービスとかの話を聞きますが,システムでも機能単位やコンテナ単位で細分化して取り扱おうという試みが増えている気がします.データセンタでもこうやってクラスタを細分化して配分できるようにし,様々な構成で効率的に活用できる,というのは当然の流れかもしれません.個人的には libraryOS はそういった流れを実現するものとして注目しているので,今後も色々論文読んでいきたいと思います.

脚注:
†1:アウト・オブ・バンド管理:電源オフ,スリープ,休止状態や,何かの理由で OS が応答できない状況などの時,管理者が管理コントローラへ接続できるように何らかの措置を取る.
†2:10 GbE NIC を備え,デュアル 6 コア CPU(+ハイパースレッディング有効),128 GB RAM,ディスクは 1 つないし 2 つという構成.
†3:現物を取引する市場のこと.対義語は先物市場で,これは株や為替のような,将来のある時期に物を受け渡しする契約を結ぶ取引をする市場を指す(契約時点で物が手元になくても良い).
†4:c4.xlarge インスタンスの価格は Amazon EC2 の 2015 年 7 月 13―20 日に準じている.HPC のコストは AWS HPC のオンデマンドのコスト,リアルタイムワークロードのコストは 3.4 GHz Xeon E3-1270,8GB RAM のサーバを IBM SoftLayer で借りる場合のコストをそれぞれ仮定している

参考文献

^1 D. R. Engler, M. F. Kaashoek, and J. O’Toole Jr, “Exokernel: An Operating System Architecture for Application-Level Resource Management,” in 15th ACM SIGOPS Symposium on Operating Systems Principles, ser. SOSP ’95, vol. 1, Copper Mountain, CO, USA: ACM, Dec. 1995, pp. 251―266, ISBN: 0897917154. DOI: 10.1145/224056.224076. [Online]. Available: https://pdos.csail.mit.edu/6.828/2008/ readings/engler95exokernel.pdf.

2016年11月28日月曜日

Ansible 2.2.0 でホストごとに実行するタスクを切り替える

ansibleで実行対象を切り替える方法 http://tdoc.info/blog/2014/05/30/ansible_target_switching.html

このサイトを参考にしようと思ったのですが古くて現在に似わなかったのでメモ.

when: "'foo' in group_names"
inventory_host でグループ分けするところまでは同じ.
when で条件分けをするにあたって,
group_names はタスクを実行しているホストが所属するグループの配列になってるので,目的のグループに所属しているかどうかを in 演算子で確認する感じです.

2016年11月22日火曜日

フォントが埋め込まれていない PDF にフォントを埋め込む

表題通りです.

古い日本語論文を読むと,90 年代終わりから 00 年代初頭ぐらいのもので,
PostScript プリンタのフォントダウンロードを期待して Adobe 基本 35 書体と
Ryumin-Ligtht と GothicBBB-Medium を指定するが埋め込んでいない,
という PDF を見かけることがある.

ふつうは代替フォントが表示されて終わるのでなんでも良いけれども,
Mendeley の内蔵ビューワーであったり,ブラウザ内蔵ビューワーであったり,
そういう環境では埋め込まれていない和文フォントはそのまま表示できずに空白になる.

次のコマンドで GhostScript を使ってこれを解決.

$ gs -o font_embedded.pdf -sDEVICE=pdfwrite -dEmbedAllFonts=true -sFONTPATH="/usr/share/fonts/Type1:/path/to/your/font/dir" font_not_embedded.pdf
-o の後には出力ファイル名,最後の引数にしているのはフォントが埋め込まれていない,今回操作を行ないたいファイルへのパス.
言うまでもないけれども,-sFONTPATH="" には : 区切りでフォントへのパスを書く.

2016年10月31日月曜日

標準エラー出力を pipe で受け取る

たまに標準出力エラーについて加工したくなることがある.
しかし,単純に|を使っても出力は受け取られないので,加工に使うコマンドの標準入力は空のままである.
次のようにすれば良い.
$ mage? 2>&1 >/dev/null | magemge!
これは,一度標準エラー出力をリダイレクトして,標準出力に投げなおしているだけである.つまり以下でも同じことができる.
$ mage? 2> /dev/stdout 1> /dev/null | magemage!