告知
日付を数値で表現する方法の表記ゆれは、オンライン上の混乱を招く。そのため、ISOは1988年に数値による日付表記の国際標準を定めた。
これが日付を数値で表記する正しい方法である。
2013-02-27
故に、以下の表記はすべて非推奨である。
2/27/2013 02/27/13 27/02/2013 27/02/13 20140227 2013.02.27 27.02.13 27-02-13 27.2.13 2013.Ⅱ.27. 27/2-13 2013.158904109 ⅯⅯⅩⅢ-Ⅱ-ⅩⅩⅤⅡ ⅯⅯⅩⅢ ⅬⅤⅡ/ⅭⅭⅭⅬⅩⅤ 1330300800 ((3+3))×(111+1)-1)×3/3-1/3^3 [再現断念]
実に、日付表記ゆれは甚だしい。皆早くISO 8601に準拠せよ。
今現在、Twitter API v1が動かない。
Planning for API v1’s Retirement | Twitter Developersにあるように、ブラックアウトテストでもしているのだろうか。まあ、廃止予定の3月までもう何日もないのだが。
OAuth必須で、しかもJSONしか返さないversion 1.1では、RSSリーダーで読むことが出来ないので、そろそろTwitterのやめどきだ。RSSを提供していない頻繁にアップデートされるWebサイトは読む価値がない。
まず、Red HatのDavid Howellsが、マイクロソフトによって署名されたセキュアブート鍵をカーネルに含めてくれるよう、MLで要請した。
ようリーナス。
このパッチセットをpullしてくんね？
セキュアブートモードで動くカーネルに、鍵を動的に追加する機能。鍵をロードするには、新しい鍵はすでに持っていて、信頼されている鍵で署名されている必要がある。この「すでに持っている」ところの鍵は、カーネルに組み込まれているものや、UEFIデータベースにあるものや、あるいは暗号ハードウェアのものが含まれる。
で、"keyctl add"は署名されたX.509認証を受け付けるのだけど、マイクロソフトの署名サービスは、EFI PEバイナリしか署名してくれないんだ。
LKML: David Howells: [GIT PULL] Load keys from signed PE binaries
これに対するリーナスの返事。
もっと議論を深めてからでないとダメだ。
ぶっちゃけ、これはクソすぎんだろ。全体的な設計からして、ドアホな設計のためにクソバカなインターフェース。なんでそんなことしなくちゃなんねーんだ？
すでにあるX.509パーサーですら気に食わんのに、このクソミソ変態インターフェースときた日にゃ、もうお手上げだぜ。
リーナス
LKML: Linus Torvalds: Re: [GIT PULL] Load keys from signed PE binaries
これに、Red HatのMatthew Garrettが返事。
唯一の認証局で、しかもPEバイナリしか署名しないんだ。
LKML: Matthew Garrett: Re: [GIT PULL] Load keys from signed PE binaries
これに対してリーナス、とうとうブチキレたらしく。
おめーら、フェラ大会じゃねーんだぞ。
PEバイナリをパースしたきゃ、やりゃいいだろ。
Red HatがMicrosoftのをしゃぶりたきゃ、そりゃテメーの勝手だ。俺の保守するカーネルには何も関係ねーことだ。オメーらにしちゃ、署名マシンでPEバイナリをパースして、署名を検証して、自前の鍵で結果の鍵を署名することぐらいどうってことないだろ。オメーはすでにコード書いてるしな。このクソpullリクエストはなんだコラ？
何でこの俺が気にかけなくちゃなんねーんだよ？ なんでカーネルが「おれらPEバイナリしか署名しないもんねー」とかいうド低能に付き合わなきゃなんねーんだよ？ X.509はサポートしてる、署名の規格だもんな。
これはtrusted machineのユーザーランドでやれ。カーネルでやる理由は一切ない。
リーナス
LKML: Linus Torvalds: Re: [GIT PULL] Load keys from signed PE binaries
これに対し、David Howellsが説明するが
それには問題があるんだよ。
- マイクロソフトの認証破棄は、PEバイナリのハッシュに対して行われるのであって、鍵ではない。
- 再署名により、鍵はマイクロソフトの鍵ではなく、我々のマスターキーに依存するようになる。すると、マイクロソフトの認証破棄は無意味になる。
- この時点で、マイクロソフトができることは、我々のマスターキーを破棄することしかなくなる。
David
LKML: David Howells: Re: [GIT PULL] Load keys from signed PE binaries
リーナスの返事。
お前はいまだに根本的な問題が分かってない。
- なんでカーネルがやらなきゃならねーんだ？
- なんでMSによるLinuxのカーネルモジュールの鍵署名を気にかけなきゃなんねーんだ？
お前の議論は、このキチガイな前提条件を受け入れなきゃ成り立たない。俺はまっぴらごめんだ。
リーナス
LKML: Linus Torvalds: Re: [GIT PULL] Load keys from signed PE binaries
この話の背景には、Linuxのセキュアブートへの対応方法がある。
Trusted Computing、もといTreacherous Computingは、身元が保証されたバイナリしか実行しない。暗号的にこれを可能にするのが、署名だ。例えば、私があるバイナリを私の身元証明とともに、認証局の秘密鍵で署名してもらい、配布したとする。バイナリを実行する側は、公開鍵で署名を検証することにより、バイナリが署名された時点から一切改変されていないことを保証できる。もちろん、これはソフトウェアが悪意ある動作をしないかどうかの保証ではない。あくまで、バイナリの身元と改変されていないことを保証するだけである。さて、バイナリが悪意ある動作をすることが判明した。その場合、バイナリの作成者である私の悪事がバレたことになる。なぜならば、そのバイナリを作成できるのは、私しかいないのだから。認証局は、そのバイナリの身元である私の認証を破棄できる。これにより、私の身元で署名されたバイナリのみ、実行を拒否することができる。
実際には、私の鍵を盗んだ者のしわざである可能性もある。しかしそのような場合でも、私の鍵で署名されたバイナリの認証をすべて破棄できる。
署名によるトレチャラス・コンピューティングは、ソフトウェアが悪意ある動作をするかどうかを保証するのではなく、ソフトウェアの身元を保証する。身元バレするソフトウェアに悪意ある挙動を仕込みたくはないし、仮に悪意ある挙動を仕込んだとしても、一度バレたら即座に認証破棄され、すべてのバイナリの検証が失敗するので、大規模に広げることも出来ない。
これは、SSLと同じ方法であり、暗号理論的にも正しい方法である。Verisignの認証には、現実の住所が必要になる。たとえ郵送の転送を何度も繰り返したとしても、結局最後は現実の住所が必要になり、そこから足がつく。事実、国家による諜報機関であっても、Verisignからの認証を大真面目に受けるのではなく、他人の認証を盗んで使っている。
さて、これには信頼できる認証局が必要となる。セキュアブートの場合、マイクロソフトがその認証局となる。マイクロソフトとVeriSignが信頼できるとしたならば、マイクロソフトの認証のもとに、あらゆるバイナリの身元が信頼できる。
さて、Linuxをセキュアブートに対応させるには、まずマイクロソフトによってバイナリを署名してもらわなければならない。カーネルのアップデートのたびに署名するのは極めて面倒なので、Linux陣営はまず、簡易ブートローダーをマイクロソフトに署名させ、ブートローダーより後は、自前の鍵で署名するという方法を取っている。そして、すべてのカーネルとカーネルモジュールのバイナリを、自前の鍵で署名、検証する。つまり、Linuxカーネルとカーネルモジュールは、Linux側のマスターキーで署名検証され、マイクロソフトに署名してもらう必要がない。もし検証しなければ、それはどんなバイナリでも読み込めるブートローダーであり、マイクロソフトはそのようなブートローダーの存在を許すはずがなく、ブートローダーへの署名を破棄する。
とまあ、いろいろあるのだが、そのマイクロソフトの署名の規格が、PEバイナリしか受け付けなかったりと、いろいろとド低脳なことになっている。今回の問題は、Red Hatのために署名されたバイナリをカーネルに取り込むpullリクエストであり、リーナスとしては、そんな馬鹿げたことはカーネルの仕事じゃねーッ！、ユーザーランドでやれ、ユーザーランドでッ！ ということだ。
C++1y 軽量Concept - Faith and Brave - C++で遊ぼう
PDF注意:Concepts Lite: Constraining Templates with Predicates
とりあえず型への制約のみを考えた軽量concept。
requireキーワードに続けて、bool型を返すconstexpr関数を指定することにより、型制約を記述できる。従来のSFINAEを用いたトリックよりわかりやすい。従来の方法は、メタプログラミングという概念をしっかりと理解し、C++上でメタプログラミングを行うためのトリックをいくつも知っていなければ書けないが、これなら初心者でも簡単に書ける。
template < typename T >
require Equality_comparable<T>( )
bool equality_compare( T const & t1, T const & t2 )
{
return t1 == t2 ;
}
template < typename T >
constexpr bool Equality_comparable()
{
return has_eq<T>::value &&
Convertible<eq_result<T>, bool>() &&
has_neq<T>::value &&
Convertible<neq_result<T>, bool>() ;
}
conceptがなければ、equality_compareにoperator ==を呼べない型や、呼んだ結果がboolに変換できない型を渡した場合、該当の演算子が存在しないという不可思議なコンパイルエラーになるが、conceptのおかげで、Euality_comparableの制約に合わなかったというエラーメッセージになる。
さらに、式が有効かどうか、型が有効かどうかを調べる方法を実装が提供することにより、表現方法を広げることも提案されている。
lambdaへの型制約の適用については、技術的な問題はないが、適切な文法を考案しなければならないとしている。
感想としては、型制約としてはなかなか悪くない提案だ。C++11がドラフトだった当時、conceptのあまりのややこしさにいやになり、単に有効な式やメタ関数の記述を並べる文法があればいいのにと思っていたのだ。
問題は、この提案で、concept map機能をどうやってつけるのか。Bjarne Stroustrupは以前のインタビューで、concept mapのないconceptなんて使いたくないと答えていたはずだが。
Bypassing Windows ASLR using “skype4COM” protocol handler | GreyHatHacker.NET
不自由なソフトウェアのSkypeをインストールするともれなく入ってくるプロトコルハンドラーの実装、skype4com.dllは、IEにロードされる。しかし、skype4com.dllはASLRが有効になっていないので、ロードされるアドレスが容易に推測でき、rop chainに利用できてしまう。もちろん、そのrop chainを仕掛けるための脆弱性は別に必要になるが、ASLRさえあれば深刻な問題にならなかった脆弱性が、Skypeがインストールされている環境で攻撃に利用できてしまうのは痛い。皆が常に最新のパッチを適用しているとも限らないことを考えれば、IEに読み込まれるdllを書くときは、注意したほうがよい。
しかし、もはやSkypeはMicrosoft傘下なので、これはあまりにもお粗末すぎる。しかし、なぜ有効になっていないのだろう。まさかデバッグ時に無効にしてそのまんまということは・・・まさかな。
まあ、不自由なOSのことはしったこっちゃないが。
Pastafarian denied religious freedom in New Jersey driver's license scandal - Boing Boing
ニュージャージー州の運転免許の写真撮影に、空飛ぶスパゲティモンスター様の神々しい帽子をかぶって写真を撮影することが拒否されたそうだ。しかし、なぜかその写真撮影では、その他の有名な宗教のターバンやスカーフは許されていたというのに、パスタファリズムの帽子は拒否したという。
これは許しがたい宗教差別であり、同じくパスタファリアンである身として怒りに打ち震える所業だ。
パスタファリズムは、他のやれ山の上で十の戒めごとを授かったの、処女にして身ごもったの、水の上を歩いたの、病人を直したの、洞窟で天使の声を聞いたの、白象の夢をみてワキから生まれてきたのというわけわからない宗教とは違い、多くの科学者に信仰されている進化論に対する異説でもあるのだ。
Chromebook Pixelのハードウェアがなかなか興味深い。私はChrome OSは使いたいとは思わないが、このラップトップは使ってみたい。
まず、ディスプレイが239PPIの2560x1700となっている。CPUはi5で、GPUはi5内蔵のHD4000なので、GNU/Linux環境では自由なグラフィックドライバーを使える。SSDの容量だけが少なすぎるが。
また、BIOSが自由なソフトウェアであるCorebootなのもすばらしい。
また、GoogleはChromebookのLinuxサポートにも積極的に貢献している。Corebootに力を入れている理由は、起動速度だ。結局、LinuxカーネルはBIOSを信用せず、使うBIOSの機能は代替の聞かない最小限に止め、ハードウェアの初期化や操作は全て自前で行う。とすれば、ブート時にBIOSによるハードウェアの初期化は無意味であり、そのような初期化を行わないBIOSが望ましい。しかし、既存のBIOSのファームウェアは、互換性のため従来の挙動を維持し、また不自由なソフトウェアなので、改良も出来ない。
[Phoronix] Google Pushes Linux Support For Chromebook Pixel
その他のファームウェアのソースコードの公開もしている。
[Phoronix] Google Designs Its Own Chrome Embedded Controller
ちなみに、Chromebookはデフォルトではトレチャラスコンピューティングとなっており、Googleの署名を受けたバイナリしか実行できない。Chromebookの物理的なスイッチを操作することでこの制限は外せる。ただし、このスイッチを操作した場合、ストレージの中身は全て消去される。なぜならば、制限を外すという事は、トレチャラスコンピューティングの保護から抜けるという事であり、一旦制限を外したあと変更を加えて制限を再び有効にする攻撃の可能性があるので、全消去される。
もっとも、この記事を読む読者は、比較的自由なコンピューターが欲しいのであって、比較的自由なシステムをインストールしたいだろう。Chrome OSのような実質Chromeブラウザーがシェルとなっているシステムを使いたくはないはずなので、特に問題はないはずだ。
Rubber duck debugging - Wikipedia, the free encyclopedia
ラバーダックデバッギング、ラバーダッキング、ラバーダッキーテストとは、ある独特なデバッグ手法の名称である。このデバッグ手法を行うには、ラバーダックのような無機物に対して、コードがいかにして動作するかということを一行づつ逐次説明する。その説明の過程において、間違ったコードに到達した時点で、説明ができなくなる、あるいは説明とコードが合わなくなることを発見することによって、不具合箇所も発見できることを期待したデバッグ手法である。
まさか名前があるとは思わなかった。
Samsung Copy & Paste Bug (AKA Never Trust Samsung) | Terence Eden has a Blog
サムソンの携帯とタブレットのうち、Galaxy Note II, SIII, Note tabletが、20回コピペするとクラッシュするらしい。クラッシュ後はソフトリセットがかかるが、もっと深刻な自体に陥る環境もあるのだとか。
このバグはすでに何度も報告されていて、サムソンは去年の10月29日に公式に声明を出した。「この不具合は報告されており、早期に解決できる見込みです」というのがそれだが、いまだに何の「解決」もない。
workaroundとしては、/data/clipboardディレクトリのパーミッションをリードオンリーに設定すれば、とりあえずクラッシュしなくなる。もちろん、これはクリップボードの機能を無効化してしまうわけだが。
別のworkaroundとしては、/data/clipboard内のディレクトリをすべて削除する方法がある。この削除は、15から19回ぐらいのコピペを行うごとに、逐一行わなければならない。さもなければ、クラッシュする。
Sony Pirates KDE Artwork | blogs.kde.org
音楽CDにルートキットを仕込み、プレイステーションというデジタル制限管理機能付きの所有者が管理者権限を取得できない制限コンピューターを販売している企業であるソニーのWebサイト上で、KDEのシステム設定アイコン用のレンチとマイナスドライバーを組み合わせたLGPL3でライセンスされている画像が使用されている。また、ソニーのコンピューターのUEFIファームウェアにも、このKDEの設定アイコンが使われている。しかし、Webサイトの利用規約には、Webサイト上には、LGPL3ライセンスのことは一切言及せず、またWebサイト上の商標、著作権、その他所有権を侵害した場合には、民事、刑事上の責任を負うと書かれている。
また、ソニーのWebサイトの利用規約には、「このサイトへのいかなるリンクにも、事前に許諾が必要である」としている。
さて、KDEはソニーをLGPL3違反で訴えるのだろうか。Webサイトの方はすぐに利用を中止できるだろうが、UEFIのファームウェアの変更はいかにも難しい。
ただし、ライセンスが文字通り劣ったGPLであるLGPLなので、あまり問題にはならないのではないかと思う。とりあえずライセンスさえ表示しておけばいいのではないか。
ただし、LGPL3ということは、Tivoization対策とか、デジタル制限管理(DRM)を法的にDRMだと認めることを放棄する（DRM破りが違法になることへの対策）はずなので、色々と面白いかもしれない。
[Phoronix] Linux 3.9 Supports Lightweight Suspend, New PM Features
[Phoronix] Intel Driver Works On "PM Suspend Freeze" Support
Linux 3.9にPM_SUSPEND_FEEZEが入ったらしい。
従来のサスペンドは、PM_SUSPEND_MEMORYというもので、これはBIOSの機能支援を受けたサスペンドである。
PM_SUSPEND_FEEZEは、PM_SUSPEND_MEMORYと違い、BIOSのサスペンド機能を使わない、環境に依存しない実装となっている。単にプロセスを止め、デバイスも止め、プロセッサーをアイドル状態にする。これは真のサスペンドであるPM_SUSPEND_MEMORYよりも、省電力という点では劣っているが、復帰が早く、環境依存の機能にも依存しないため、実装の不具合にも強い。
アイドル状態での消費電力が低い環境ならば、かなり使える。
ファームウェアのサスペンド実装の不具合は相当に多そうだ。
注意：この記事はとても怪しいWebサイトを紹介している。眉につばをつけて読むべし。
C++ Grandmaster Certification [CPPGM]
C++グランドマスター認定というオンライン講座が、2013年の3月から始まるそうだ。
これは、12ヶ月から18ヶ月ほどかけて、C++11でフルセットのC++11コンパイラーツールチェインを実装するというコースで、修了の暁には、C++のグランドマスターであることを認証するそうだ。
読むと、文字通りC++11のフルセットのツールチェインを実装するという、にわかに信じがたいオンライン講座らしい。最初のブートストラップを除いて、サードパーティのソフトウェアに依存しない、プリプロセッサー、コンパイラー、アセンブラー、リンカーを作るのだそうだ。もちろん、セルフホスト可能なコンパイラーとなると豪語。
問題を簡単にするため、環境はLinux x86_64と固定されている。
参加費は無料。課題の締め切りがあり、締め切りに間に合わなければ途中でリタイアとなるのだろうか。
一番最初の課題が公開されている。
C++ Grandmaster Certification [CPPGM]
みると、一応は真面目に、Phases of Translation 1, 2, 3までを実装するという課題になっている。スケルトンコードと、テストコードが提供されていて、課題を実装して送るのだという。もしこの調子でやるのならば、おそらくこの先18ヶ月、このクラスのみに専念できる時間が必要だろう。しかし、この調子では本当に18ヶ月で終わるか疑問だ。
しかも、コンパイラーだけならともかく、標準ライブラリをも実装するそうだ。C++11の標準ライブラリなんて18ヶ月かけても一人で実装しきれないと思うのだが。
とまあ、見た目だけは勇ましいが、どこまで本気なのかわからない怪しいオンライン講座。だいたい、参加者がどれだけ集まるかも疑問だ。Hacker Newsのコメントによれば、そもそも以前まで1月締め切りで募集していたのが、何故か3月まで伸ばされているそうだ。またWebサイトでは1万人の参加者がいると主張しているが、それならなぜ締め切りを伸ばしたのか。
さらに別のHNのコメントによれば、実際に登録してみたが、返事はなしのつぶて。ひょっとしたら単にSPAM用の情報収集のための釣りサイトなのではないかというコメントもある。
というわけで、このC++グランドマスター認証は、非常に怪しい。
ちなみに、参考のためにClangをみてみよう。Clangは2005年にAppleの支援のもと始まった、LLVM上のC++コンパイラーである。ソースコードの公開が2007年、自分自身をコンパイルできるようになったのが2009年、セルフホストできるようになったのが2010年である。
AppleやGoogleのような大企業の支援を受けて、Clangの開発をさせるために大企業に雇われた何人もの一流のコンパイラー作者の共同作業であるOSSプロジェクトですら、ここまで時間がかかっている。
著作権、日本まだ敗戦国扱い ＪＡＳＲＡＣ、解消要望へ （朝日新聞デジタル） - Yahoo!ニュース
戦時加算は、むしろJASRACには有利なはずだ。なにしろ、国内で海外の音楽の著作権使用料を徴収するのはJASRACなのだから。それがわざわざ戦時加算撤廃に動くという事は、おそらくアメリカのように、20年ごとに20年、著作権の保護期間を延長する半永久的な著作権保護を実現したいからだろう。
経団連：電子書籍の流通と利用の促進に資する「電子出版権」の新設を求める (2013-02-19)
すでにいまの出版業界が、「契約の期間中。著者は出版社に対して、全著作権を排他的、独占的に、代行管理させる」なんて契約を結ばせている現状で、新しい権利なんて作っても意味がないと思うのだが。ますます著者の権利が制限されるばかりだ。
How Fast is the ISS's Internet? (and Other Space Questions Answered) - Tested
madhatta comments on Do astronauts have internet in space? If they do, how fast is it?
ISSのインターネット環境は、下り10Mbps、上がり3Mbpsほどだそうだ。また、ISSで使っているラップトップは、改造Lenovo T61pだそうだ。
ISSのような微弱重力環境では、コンピューターの冷却方法に気をつけなければならない。ファンレスのパッシブクーラーは使えない。何故ならば、パッシブクーラーは、暖められた空気が膨張して軽くなり、上に移動するという重力に依存した仕組みなので、重力の弱すぎるISS内では動かない。ヒートパイプも動かないし、低音で沸騰する液体を使ったクーラーも動かない。
一円玉の製造、2年連続ゼロ＝電子マネーに押される （時事通信） - Yahoo!ニュース
この二年間、市中向けの1円硬貨が製造されていないそうだ。記念硬貨用には製造されているとか。
Gearbox, Sega ''Lied'' With Aliens: CM Promo Media, Demo
tomshardware.comで、Aliens: Colnial Marinesという不自由なソフトウェアのゲームが、ひどく酷評されている。まあ、パブリッシャーがSEGAなので当然予期すべきことであったが、その状況がなかなか面白い。
なんでも、最終的な製品が、2011年にE3で公開したデモ版よりあらゆる点で劣化しているというのだ。
このため、デモ版はデモのためだけにでっち上げた嘘ではないかと叩かれている。
また、ゲームが宣伝にだけ力を入れて売り逃げするものになっている現状も指摘されている。
しかし、どうもプレイ動画をみていると、まるでDOOM 3のようにみえてならない。実際、DOOM 3そっくりだ。かなりDOOM 3から影響を受けているとみて間違いない。開発に6年かけたといわれているが、6年前といえば、ちょうどDOOM 3のような真っ暗なグラフィックが流行っていた時代だ。いや、流行ってはいなかった。結局、今の浮動小数点数のようなより高い範囲で計算しておいて、後からせまい範囲に落としこむHDRと呼ばれている手法を用いずに、高いダイナミックレンジを表現しようとすれば、画面のほとんどは真っ暗か真っ白になってしまうというだけだ。当時のゲームは、ハードウェアの性能もあり、今のHDR処理をまともにこなせず、それでもやはり広範囲に表現しようとするものだから、画面のほとんどが真っ暗という悲惨な状態になってしまっていた。
ちなみに、ユーザーは単にガンマ補正をかけて遊んでいた。当然だ。誰も真っ暗な画面で遊びたくないからだ。画面はユーザーに対する出力であり、出力が理解できなければ意味がない。
実際、DOOM 3だって、私に言わせれば、知名度ほど面白くなく、売り逃げだったわけだ。同じくidの開発したRageだってそうだ。DOOM 3を参考にしたゲームが、DOOM 3と同じ商法を使うのは、驚くにはあたらない。
と、DOOM 3もRageもAliens: Colnial Marinesもプレイしたことのない人間が、YouTubeのプレイ動画だけをみて批評してみる。
90年代に流行ったギャル語の用例集がほしいが、インターネット上にはほとんど見つからない。貧弱な単語集がちらほらとあるばかりだ。
ただ、おそらく紙の本としては出版されていただろうから、おそらく、Amazonとかブックオフのような最近の本を主に取り扱っている古本屋から収集すればいいと思う。
と思ってAmazonを軽く検索してみたが、ギャル語の用例集のような本はなかなか見つからない。これは危機的な状況だ。やはり実店舗の古本屋を歩きまわって収集するしかないと思う。
Amazonで唯一豊富に見つかるのは、コギャル風の女性の写真集と映像DVDだ。これは本物というより、当時ですらオッサンオバハンだったものが流行に乗っかって作った作品だろうが、90年代に発売されたものならば、ある程度は当時の雰囲気を反映しているのではないかと思う。
ギャル語につけて思い出すのは、ギャラクシーエンジェルのドラマCD、ギャラクシーエンジェルでSHINE!に収録されている、古代言語チョムカだ。
ミント「これは大変な発見ですよ。 この本に載っているのは、 大昔、辺境惑星の小さな島で、特定の若い女性たちが、 わずか数年だけ使っていたという非常に貴重な言語です。 この言語は、あったという伝承だけで、 言語そのものに関する文献がほとんど残っていないんです。 このため学会では、ずっと幻の言語と言われてきました。 こんなに沢山の文例が載っている本が現存してるなんて・・・」
ミント「ん〜。例えばこの文例ですが。これは「この前、嫌いな人からの電話を無視していたら、 『強引に連れていくぞ』と脅されて、とてもハラがたった」といった意味になるんですが。 」
ミント「こんな感じになります」
「このまぇ〜、ウザベル、シカッティングしてたらぁ〜、ラチるとか言われてぇ〜、チョムカ～」
実際、今用例はほとんど見つからず、単語集ぐらいしか残っていないので、古代言語チョムカは本当の話になりつつある。
2013年2月16日に、実に5年ぶりに、GNU Texinfoがバージョン5に更新された。前回の更新は、2008年9月18日のバージョン4.13だ。
2012年中に、Texinfoのうち、従来Cで実装されていたtexi2anyとmakeinfoを、Perlで再実装したそうだ。
Perlで実装したことにより、プログラムは遅くなったが、コードが平易になり、開発に新規参入しやすくなり、拡張もしやすくなったという。また、Unicodeへの対応も、Cでは難しいが、Perlならばとても簡単になる。
まあ、遅くなったといっても、たかだか人の手で書く程度の量のテキストの変換処理であるし、それに大半の人は、texi2anyやmakeinfoを直接使わないし、ドキュメントも含めて完全に自前でソースからビルドするようなシステムだとしても、やはりmakeinfo以外のビルド処理に比べればたかがしれているし、どうでもいいのではないかと思う。
The new implementation is in Perl, requiring Perl 5.7.3 (released in March 2002) and its standard Encode module.
The Perl texi2any/makeinfo both replaces and is intended to be (for all practical purposes) upward-compatible with the C makeinfo. It has many new features not in the C makeinfo. For example, cross-manual references are now fully supported, and allows for extensive customization of the HTML output. See the `Generic Translator texi2any' chapter in the manual (among other places) for more about this reimplementation.
The new program is, unfortunately, noticeably slower at present than the C program was. We hope all the many improvements make the new version worthwhile for users nevertheless.
Reimplementing in Perl
In 2012, the C
makeinfowas itself replaced by a Perl implementation generically calledtexi2any. This version supports the same level of output customization astexi2html, an independent program originally written by Lionel Cons, later with substantial work by many others. The many additional features needed to maketexi2htmla replacement formakeinfowere implemented by Patrice Dumas. The first never-released version oftexi2anywas based on thetexi2htmlcode. That implementation, however, was abandoned in favor of the current program, which parses the Texinfo input into a tree for processing. It still supports nearly all the features oftexi2html.The new Perl program is much slower than the old C program. We hope the speed gap will close in the future, but it may not ever be entirely comparable. So why did we switch? In short, we intend and hope that the present program will be much easier than the previous C implementation of
makeinfoto extend to different output styles, back-end output formats, and all other customizations. In more detail:
- HTML customization. Many GNU and other free software packages had been happily using the HTML customization features in
texi2htmlfor years. Thus, in effect two independent implementations of the Texinfo language had developed, and keeping them in sync was not simple. Adding the HTML customization possible intexi2htmlto a C program would have been an enormous effort.- Unicode, and multilingual support generally, especially of east Asian languages. Although of course it’s perfectly plausible to write such support in C, in the particular case of
makeinfo, it would have been tantamount to rewriting the entire program. In Perl, much of that comes essentially for free.- Additional back-ends. The
makeinfocode had grown convoluted to the point where adding a new back-end was quite complex, requiring complex interactions with existing back-ends. In contrast, our Perl implementation provides a clean tree-based representation for all back-ends to work from. People have requested numerous different back-ends (LaTeX, the latest (X)HTML, …), and they will now be much more feasible to implement. Which leads to the last item:- Making contributions easier. In general, due to the cleaner structure, the Perl program should be considerably easier than the C for anyone to read and contribute to, with the resulting obvious benefits.
暗号ヲタの妄想：
「奴のラップトップは暗号化されてやがる。百万ドルのクラスタ組んで解読しようぜ」
「いやダメだ。これは4096bit RSAだ」
「クソ、我々の邪悪な計画もここまでか」現実に起こりうること：
「奴のラップトップは暗号化されてやがる。パスワード吐くまで、この5ドルのレンチで傷めつけてやれ」
「了解」
ちなみにイギリスでは、暗号文の容疑をかけられたものに復号化鍵を提供しないのは犯罪である。
[Phoronix] Lua Scripting Support Being Added To NetBSD Kernel
NetBSDカーネルがLuaをサポートした。これによりカーネル側のドライバーなどをLuaで書けるようになったそうだ。
Luaをサポートした理由は、ユーザーにシステムを拡張する力を与えたいが、そのためには、C言語はあまりにも難しすぎるためだという。
Browser Wars, the game « Fink @ Mozilla
先日、OperaがWebkitに移行することを発表した。これにより、ブラウザーのシェアは事実上、Firefox(Gecko)か、webkit系ブラウザーに二分されることになる。IEはすぐに死亡するので考えなくて良い。log.mozilla.orgのブログで、このままWebkitがシェアを独占した場合の危険性について書いている。
単一文化は、短期的には優れている。労力を集中させることができるし（みんな同じことに対して働く！）、今日動くリッチなWebアプリを書きたければ、(つまり、今日のブラウザーで動くやつを書きたければ)、状況はだいぶマシになる。
しかし、Webとはプラットフォームである。プラットフォームは、また違った厄介者なのだ。
今、モバイルWebがすべてWebkitになったとする。何が起こるか考えてみよう。
下位バグ互換： ここにひとつのバグがあるとする。幅長が素数の背景SVGイメージは、半透明が無効になるというものだとする。一年後、7328件のWebサイトがこのバグに依存するようになる。誰かが直しました。Webサイトが開発版ビルドでぶっ壊れました。修正は取り消され、単に警告がログに出るだけになる。何も壊れません、世界はWebkitが牛耳ってます、誰も気にしやしません。こうして、バグは今や、Webプラットフォームの仕様となったのであります。
イノベーションの阻害： あるハッカー集団が、2018年のラップトップでは当たり前になっている100コアを効率良く使う新しいブラウザーを開発した。旧態依然のブラウザーは、タブひとつにつきひとつのCPUを使い尽くすのとはえらい違いだ。これは完全な再設計であり、彼らのすんばらしい働きにより、世の中の99%のWebサイトをサポートしている。いや、98%にしよう。さて、Webkitがちょうど新機能を公開したので、皆がただちに製品のWebサイトに使い始めた（使わない理由なんてないだろ？）。おっと、サポート率90%にダウン。あるWebkitのバグは、対処したくないほど汚らしいバグであり、新ブラウザーのスレッド実装では動かない。なんじゃこりゃ？ 80%だと？ 何が起こってるッ！ 急げ、このままだとどんどんサポート率が下がるぞッ！
このハッカー集団はとうとう諦めて、かわりに、求人サイトとか小鳥さんSNSとか、セキュリティ研究者とかに成り下がる。というわけでハッカーは今や、「ともだちんこぶぁい」とか言ってる。
不適切な支配：ある者が複数のストリームを使ってDJアプリを実装できるような同期APIを開発した。Appleの音楽スタジオパートナーは恐れをなし、実現を防ぐため、ブラウザーに付け加えたり、付け加えるforkをだそうとするもの全員に、根拠のない脅しの手紙を送りつける。
複雑化： 標準団体はもはやその目的を失い、死んでいく。いままでに出来なかったことを可能にする新機能はすばらしい。新機能の花が咲き誇る。ある花は他の花の上に咲く。Webサイトごとにてんでばらばらの機能を使う。機能のいくつかは保守しにくいので、カネをたっぷり持っている大企業が依存しているのでなければ、生き残れない。Web開発者は、現在の市場とユーザーの状況から、どの新機能が生き残るかというギャンブルを余儀なくされる。
混乱： CSSセレクターには多くの落とし穴がある。多くのチュートリアルでも言及されているし、regression test suiteにも入っている。そうそう、それとこれと'~'オペレーターを一緒に使えば、最初のはクラスのある要素にしか適用されないよ。規格書をみても乗ってないぜ。なぜなら、この数年アップデートされていないからだ。みんな調べるよりまず書いて試すしね。規格を更新する責任者は、いまCSS5にかかりっきりだよ。第一、規格書なんてyoutubeでチュートリアルをみれないやつのためにあるもんだろ？ だろ？
ゲームクリア： Webは今や、2013年よりはるかに発達した。昨日、発売されたばかりのAppleのハードウェアの新機能も完璧にサポートしてるよ！（去年発売された時代遅れの大昔のパッド(笑)を持ってるなら、さっさとアップグレードしとけよ）。問題を実装する方法はいくつもある。そのうちのいくつかには、なんとまともに動くものもある。一部のwebkitベースのブラウザー限定だけどね。何が何なのか把握するのは難しい。期待通りに動かないことがあったしても、規格書はそこまで詳細を規定しているわけではないし、実装とて何も保証していないのだから。まあ、なんだね。ネイティブAPIはそれなりにドキュメント化されていて、上位互換なんだから、同じアプリをそれぞれのプラットフォーム向けに何度かネイティブに書きなおすのなんてそれほど苦でもないだろ。
これは、皆がWebkitを標準するから起こるのだろうか。否、皆が使うシリコンやTCPも同じだ。あるものが安定していれば、単一文化でも問題はない。まあ、大半は。TCPにもほころびがではじめているとはいえ。この憂慮は、複数のまともな解決方法があり、素早く進化し、今までにない分野にも進出し、実際のアプリからどのように使われるかわからないようなレイヤーに限定された問題であり、複数の独立した存在によって対処されるべきであるのだ。
Evil - Gitorious
Evil - Home - Open wiki - Gitorious
Evil, Almost Full Vim Implementation In Emacs, Reaches 1.0 - Slashdot
Evilとは、Emacs上におけるVimの実装である。Vim本体の機能はおろか、プラグインまでサポートしているそうだ。
どうやら、Emacsにもようやくまともなテキストエディターがやってきたようだ。確かに、EmacsはそれなりのOSではあるが、まともなテキストディタ―を欠くと言われて久しい。よかったよかった。
なぜか多少の冷たいものや熱いもので、歯がものすごく痛むようになったので、歯医者に行った。
この二週間ほどは、以前浅く削って詰めたところに、虫歯が再発したので、その治療をしていた。ただし、この歯は肝心の痛む歯ではない。
今日は、その肝心の痛む歯の治療をした。歯医者さんの言うところには、一見健康そうに見える歯なので、できれば削りたくないとのこと。ただし言うほど痛むのであれば、神経を取るしかないとのことであった。
結果としては、歯に亀裂が入って炎症していたそうだ。炎症しているため麻酔が効きにくいなか、ひどく痛む治療が行われた。
亀裂の入った理由は不明。もっとも多い例としては小石を噛んだためだという。
この年になって歯医者でうなるのも情けないが、とにかく汗だくになるほど痛かった。やれやれ。
とにかく、歯は大切に。
Why So Many Russians Have Dash Cams--And Why They Caught a Meteor
ロシアで車載カメラが流行るわけは、警察の腐敗。
ロシア警察の公道上での賄賂要求がひどく、自衛のためにロシアでは多くの車が、車載カメラを搭載しているのだとか。
よくインターネット上に上げられる、車載カメラによる事故の映像は、多くがロシア産である。なぜかというと、ロシアでは車載カメラが流行しているからだ。今回のロシアの隕石事件で、多くの車載カメラからの映像が出回っているのも、そのためだ。
ひょっとしたら、このロシアの隕石事件は、世界に車載カメラの重要性を気づかせてくれるかもとのこと。
While I was reading kotaku.com, I found this video which reviews proprietary video game Far Cry 3.
Scottish accent is hilarious.
邪悪な不自由ソフトウェアのOperaがレンダリングエンジンとJavaScriptエンジンの内製をやめて、webkitとV8を使うニュースが流れてきた。
しかし、それは単にUIがちょっと違うだけの不自由版Chromiumに成り下がるだけではないだろうか。
いずれにせよ、これでブラウザーといえば、事実上MozillaとWebkitしかなくなってしまったわけだ。
W3C Declares DRM In-Scope For HTML - Slashdot
既存のHTMLMediaElementを拡張して、DRM実装のための基盤を設けるW3C規格のドラフトが、Google、Microsoft、Netflix社員を著者として出された。
もちろん、DRMはその実装方法が秘密であることに頼っている設計上の欠陥であるから、詳細を規定できるはずがない。この規格は、不自由なプラグインであるContent Decryption ModuleとJavaScriptとのインターフェースを提供する規格となっている。結局、このCDMはFlashやSilverLightと同じクソだ。
これはオープンで実装が容易な規格を規定するW3Cの精神に反するものであり、W3Cの領分ではない。
public-html-admin@w3.orgでは、DRMに反対する者と、NetflixとApple社員が激しく議論している。Netflix社員は、秘密の復号化を行うハードウェアを搭載したコンピューター上では、オープンソースなメディアプレイヤーが実装可能だとたわごとをはいている。それは単に秘密の復号化手順を秘密のハードウェアに移譲しただけだ。
public-html-admin@w3.org from February 2013: by date
Digital Rights Management - Private User Agent Community Groupに書いてあるように、この邪悪なDRM規格をサポートしている企業は以下の通り。
Google, Microsoft, Netflix, Adobe Systems, Comcast, CableLabs, Cox Communications, NBCUniversal, BSkyB, Irdeto, Verimatrix, Nokia, Tomo-Digi, MovieLabs, BBC
さもありなんといった顔ぶれだ。
世も末だ。
ネット選挙の与党案判明 「候補者成り済まし」公民権停止 - 47NEWS（よんななニュース）
なんだか非常に怖い方向に向かっている。たとえば、実在の候補者のマネをして漫才を行ったら公民権停止なのだろうか。そして、まったくなりすます意図はなかったのに、「貴様、そのヒゲとメガネと発音が某候補者を連想させる」などと言われて公民権停止になりはすまいか。
今は使っていないが、将来使う可能性のあるソフトウェアの動向をふたつ。記事を分けるのも面倒なのでひとつにまとめる。
[Phoronix] Wine 1.6: This Year With These Interesting Features
2013年内にリリースすることを目標にしているWine 1.6では、Layered WindowsとRaw Input、Monoのサポートを目標にしているそうだ。
Layered Windowsは、非矩形ウインドウを作るのに、通過色を設定できる。一時期はやったデスクトップマスコットによく使われている機能だ。ただし、デスクトップマスコットが流行った当時は、まだWindows 2000以前のOSも使われていたため、確かリージョンとかいうめんどくさい別の方法での非矩形ウインドウの作成も使われていたはずだ。
Raw Inputは、主に一部のゲームに使われている。Wineの利用目的の大半がWindows用のゲームである以上、相当の需要があるはずだ。
Monoは.netだ。
しかし、そろそろ調べるだけではなく、実際にWineを使ってみたいが、不自由なソフトウェアの実行を容易にするのもどうかと思うので、いまだにインストールしていない。ただし、将来Wineは使うと思うので調べている。というのも、不自由なWindowsは近い将来に死滅することに疑いはなく、不自由なソフトウェアである以上、ソースコードごと消えてしまう可能性がある。したがって不自由なWindowsは保存が出来ない。将来、すでにソースコードが消失している多くの不自由なソフトウェア、特にゲームを保存したければ、Wineに頼るしかないと考えている。ソフトウェアの保存は、単にデータを記録した情報媒体を保存するだけでは不十分である。実行環境も保存しなければならない。Wineはその貴重な実行環境になってくれるだろう。
[Phoronix] GNU/Hurd Plans For A Future With USB, SATA, 64-Bit
GNU Hurdの将来の計画も、FOSDEMに合わせて公開されている。興味をひく項目としては、Debian GNU/Hurd Wheezyのリリース、SATA、x86_64、USB、サウンドなどがある。
残念ながら、Hurdカーネルはまだ実用の域には達していない。そもそも、マルチプロセッサ―のサポートもまだだったはずだ。Debian GNU/Hurdも、phoronix.comの実権では、まともに動くハードウェアを用意できず、エミュレーター上で動かすしかなかったという。
Hurdカーネルも、今は使っていないが、将来使う可能性のあるソフトウェアである。なぜならば、Linuxカーネルは時代遅れのGPLv2でライセンスされており、Tivoizationや特許といった抜け道により、実質的に不自由なソフトウェアに成り下がることを許している。Androidのような、Linuxカーネルを使いつつ不自由な制限コンピューターが存在するのも、Linuxカーネルが時代遅れのGPLv2でライセンスされているためだ。将来、著作権や特許はますます、GPLv2が想定していなかった邪悪な方向に進むことは疑いがなく、Linuxカーネルは不自由なソフトウェアに成り下がってしまう恐れがある。そのため、Hurdの動向は調べておくべきだ。
mjg59 | Samsung laptop bug is not Linux specific
まとめ。Windows 8適合のUEFIハードウェアには、少なくとも64KBのUEFI変数用のストレージ容量がなければならない。サムソンのラップトップで、このUEFI変数に、ある程度の量を書き込むと、文鎮化してしまう。
本日、サムソンのラップトップの文鎮化に成功した。これまでのサムソンのラップトップのブート不可の報告とは違い、私はLinuxはブートしていない。すべてWindows上で行われた。どうやら、バグはある意味予想していたよりも単純で、ある意味複雑であるといえる。
とりあえず事情説明から。当初想定されていた不具合は、サムソンのラップトップのドライバーが何かシステムを動作不能にさせているのだと推測されていた。このドライバーは、標準の方法ではアクセスできないラップトップの機能にアクセスするための、サムソン独自仕様にあわせて書かれていた。その動作は、特別なメモリ領域からサムソン独自のシグネチャを探し、もし発見できたならば、テーブルのポインターをたどって様々なマジックナンバーを取り出し、そのマジックナンバーを書き込んで、必要な変更を行うシステム・マネジメント・モードを発動させるものである。これは今時珍しいが、なにもサムソンが始めてというわけではない。問題は、このマジックシグネチャがUEFIシステムでも存在しているのだが、テーブルに含まれているデータを使おうとすると問題が引き起こされるのだ。
この問題の根本的な理由はまだわかっていない。当初、マジックナンバーを書き込むことが問題を引き起こしているのだと考えられた。そこで、サムソンのラップトップのドライバーは、UEFIシステムでは無効になるようにパッチをあてられた。残念ながら、問題は解決しなかった。単に問題を引き起こす最も簡単な方法がふさがれただけだった。問題を引き起こすのは書き込みではなく、その次に行う処理であると判明したのだ。書き込み命令を実行すると、何らかのハードウェアエラーが発生する。Linuxカーネルはエラーを補足してログを取る。昔は、このログは簡単に読めなかった。システムはすぐにフリーズして、ハードドライブへのアクセスは不可能になってしまうので、ディスクに書き出すことができなかったのだ。UEFIシステムでは、読みやすくするための処理がある。深刻なエラーが発生した場合、カーネルは直前のメッセージをUEFI変数ストレージに書き込むのだ。そして、リブートの後、ユーザースペースから読むことが出来、クラッシュの原因の把握を容易にする。
このクラッシュダンプは、UEFIストレージ容量を10Kほど使う。Microsoftは、Windows8システムでは、少なくとも64Kのストレージ容量が提供されているよう要求している。Linuxではクラッシュダンプを一つしか保持しないので、システムがもう一度クラッシュしたら、新しく容量を消費するのではなく、既存のログを上書きする。これはUEFI規格上、完全に合法な処理であり、Appleも自前のハードウェアで似たようなことをしている。残念ながら、一部のサムソンのラップトップは、variable storage spaceに十分多く書き込まれた場合、ブート不可能になってしまうのだ。この「十分多い」というのがどのくらいの量なのかは、まだ判明していない。しかし、Windowsからそこそこ書き込んだところ、問題を引き起こすことができた。サンプルコードを上げておく。それぞれ1KBのランダムなデータを36個書き込んでいる。これをWindowsの管理者権限で実行してシステムをリブートすれば、二度とリブートできなくなる。
明らかにファームウェアのバグである。UEFI変数を書き込むのは、規格上明白に許されており、OSが変数を埋めたからと行って、ファームウェアがブートを拒否するような挙動をしていい理由はない。昔、Intelのリファレンスコードに似たようなバグがあったが、去年の初め頃修正された。今のところ、安全のためには、サムソンのすべてのラップトップで、UEFIを使ってはならない。もしWindowsを使っているのなら、再インストールしなければならない。
UEFI変数へのアクセスは、Linux上ならば、efivarsカーネルモジュールをロードした上で、/sys/firmware/efi/varsディレクトリ下にアクセスすればいいようだ。
Unified Extensible Firmware Interface - ArchWiki
不自由なOSであるMicrosoft Windowsにおいては、Win32 APIのGetFirmwareEnvironmentVariableEx/SetFirmwareEnvironmentVariableExでアクセスできる。
GetFirmwareEnvironmentVariableEx function (Windows)
SetFirmwareEnvironmentVariableEx function (Windows)
ちなみに、Windows上で問題を再現するサンプルコードは、これだけ。SetFirmwareEnvironmentVariableExのサンプルコードとでもいったほうがいいような短さだ。コードの半分はSetFirmwareEnvironmentVariableEx利用に必要な権限取得のためなので、実質半分。
#include "stdafx.h"
#include <Windows.h>
#include <WinBase.h>
/* Write 48 UEFI variables of 1K each */
/* The worst case outcome of this should be an error when the firmware runs out of space */
/* However, if run on some Samsung laptops, this will cause the firmware to fail to initialise and prevent the system from ever booting */
int _tmain(int argc, _TCHAR* argv[])
{
char testdata[1024];
char name[] = "TestVarXX";
BOOL result;
HANDLE handle = NULL;
TOKEN_PRIVILEGES tp;
ZeroMemory(&tp, sizeof(tp));
if (!OpenProcessToken(GetCurrentProcess(), TOKEN_QUERY | TOKEN_ADJUST_PRIVILEGES, &handle))
printf("Failed to open process\n");
/* Writing to UEFI variables requires the SE_SYSTEM_ENVIRONMENT_NAME privilege */
if (!LookupPrivilegeValue(NULL, SE_SYSTEM_ENVIRONMENT_NAME, &tp.Privileges[0].Luid))
printf("Failed to locate privilege");
tp.PrivilegeCount = 1;
tp.Privileges[0].Attributes = SE_PRIVILEGE_ENABLED;
if (!AdjustTokenPrivileges(handle, FALSE, &tp, 0, NULL, 0))
printf("Failed to adjust privileges\n");
for (int i=0; i<48; i++) {
/* Fill variable with 1K of random data */
for (int j=0; j<sizeof(testdata); j++)
testdata[j] = (char)rand();
/* Generate a unique name */
sprintf_s(name, sizeof(name), "TestVar%d", i);
/* Actually write the variable - this calls the SetVariable() UEFI runtime service */
result = SetFirmwareEnvironmentVariableExA(name, "{12345678-1234-1234-1234-1234567890ab}", testdata, sizeof(testdata), 0x07);
if (!result) {
printf("Received error code %ld\n", GetLastError());
break;
}
}
if (result)
printf("Success");
return 0;
}
今年のFOSDEMで、Wine開発者のStefan Dösingerが、Wineにおけるゲームの実行について語っている。
WineではDirectXはOpenGLに変換しなければならないので、その分オーバーヘッドがある。
WineはいまだにDirectX 10/11に対応していない。
nVidiaの不自由なドライバーはマシだ。パフォーマンスも優れている。ただし、不具合報告への返事が少々遅い。
AMDの不自由なドライバーはダメだ。数年前よりはマシになってきているが、やはりダメだ。ただし、不具合報告への対応は返事が早い。AMDの不自由なドライバーはWindowsにおいてすらOpenGLの実装がおろそかだという。
オープンソースのMesa/Gallium3Dドライバーは、OpenGL対応が遅れている。
"Apple... No!" AppleのOpenGL実装はあまりよろしくない。不具合報告のリストが公開されていないし、返事は、実際に問題が修正されるまで返ってこない。そのため、開発者の間で不具合報告が重複する。もし修正された場合、不具合を報告してから、忘れた頃に「おーい、こないだの不具合報告、修正しといたから」と返事が来る。「お・・・おう。知らせてくれてありがとな」というしかない。
mjg59 | The Samsung laptop issue is not fixed
SamsungのラップトップにLinuxをインストールしようとすると文鎮化してしまう問題は、UEFIのセキュアブートとは直接関係がない不具合である。その問題を回避するためのLinuxカーネルのパッチは、不完全であることが判明した。
また、どうもこの問題は、Windows上のユーザースペースからでも引き起こせるのではないかと疑われている。詳しいことはいまだに調査中。
いずれにせよ、現段階では、どのOSを使うにせよ、Samsungのラップトップでは、安全のために、EFIモードは使わず、BIOSモードを使うことが推奨されている。
伝説のゲームプログラマー、John Carmackは、Twitter上で、Linuxネイティブに移植するより、Wineの精度を上げたほうがマシだと発言して、物議を醸していた。
Improving Wine for Linux gaming seems like a better plan than lobbying individual game developers for native ports.Why the hate?
— John Carmack (@ID_AA_Carmack) February 5, 2013
このtweetを参照するredditの投稿に、John Carmackがコメントを残している。
id_aa_carmack comments on John Carmack asks why Wine isn't good enough
Linuxがまともだといいのだけれど、現実としては、まあ僕の優先度のトップテンにも入らないね。Armadillo AerospaceのフライトコンピューターにはLinuxを使ってるけど、日常作業のデスクトップには使ってない。RageがWineで動くと聞いたので嬉しい限りだが、特にサポートのための努力はしていない。
技術的な理由から、Linuxへ移植したい衝動にかられる。Valgrindをまた使いたいし、Nvidiaの言うことには、興味のある実験的GPU機能をR&Dで使うにはLinuxの方が色々と都合がいい。時間があれば、オープンソースのLinuxのOpenGLドライバーにもまた参加したいものだ。
でも、今のメインストリームのゲームで公式にLinuxをサポートすることにビジネス上の利点があるとは思えないし、Zenimaxには、Idのような、「非公式バイナリ」というポリシーはない。僕も利点は色々と主張してるのだが（主に実験的なWindowsの機能利用だが、Linux向けのものもある）、まあ僕としてはId Softwareのオープンソースコードのリリースの方が、未サポートLinuxバイナリよりはよっぽどマシだと思う。
Zenimaxはどうにもならない。奴らはMac用ゲームはやらない（Aspyrとパートナー結んでる）。そんなわけで、彼らが公式にLinux用ゲームをやるなんて言い出す日にゃ驚きだね。単なる移植は一週間か二週間ででっち上げられるだろうけど、公式なサポートというレベルには、もっともっと多大な労力が必要だ。今のところの通説としては、ネイティブのLinuxゲームは、あまりうまい市場ではないということだ。Id Softwareはこの通説に、Qake ArenaとQuake Liveで二度挑戦した。通説は正しかったことが証明された。この二つの例では十分ではないというハンロンもあるだろうが、まあ真面目に試したのだ。
もしLinux移植にまともなビジネス上の機会があると信じるなら、パブリッシャーに提案すればいい。ちゃんと仕事してサポートすればいい。AspyrがMacで、LokiがLinuxでやったのと同じだ。でも、売上六桁保証できなきゃ、トップテンのパブリッシャーはメールの返事すら返ってこないだろうね。まあ、おかしいと思えるかもしれない。「2万ドルを見逃すのか？」。でも、現実としては、法務、経理、管理、サポートの労力と釣り合わなきゃならないわけで、一千万ドル単位の仕事の時間を減らす価値はないね。
Linuxにおけるゲームは、何らかのエミュレーションの方が技術的にまともな方向だと思うね。サポートするにも現実的だし、特に技術的にダメなわけでもない。ネイティブ移植にしたって特に変わらないよ。僕らのゲームはOpenGL使ってるし、winsockは単にBSDソケットだし、windowsのスレッドはpthreadになって、入力やオーディオインターフェースだってそんなに変わらないし(XInputとXaudio2はよさげなAPIだよ)。ドライバーの品質に比べれば、良いシミュ・レイヤーの方がはるかにパフォーマンスへの影響は少ないよ。
D3DからOpenGLへの変換は非効率的なこともあるけど、違いをしっかり認識して、何らかの形でOpenGLのD3D interop拡張なんかを作れば、完全にリファクタしたハイパフォーマンスのネイティブ移植より簡単になる。
理想の上では、正しいガイドラインに従えば、開発者がLinux版をサポートするのは、例えばWindows XPをサポートするより簡単になる。適切に啓蒙して、Steamという商用流通プラットフォームがあれば、まあこの辺が現実的な方向だね。
John Carmack
まあ、John Carmackが何と言おうとも、もはやWindowsは死につつあるOSだ。今後ますますWindowsのシェアは激減し、誰からも省みられなくなるだろう。もはや、Windowsに将来がない以上、Windows用のソフトウェアにも将来はない。
Why do game developers prefer Windows? | Hacker News
Braidの開発者であるJonathan Blowが、Hacker Newsのコメント上で、Linux向けのゲーム開発の問題点について書いている。
最大の問題はデバッガーの質だという。事実上標準のデバッガーであるgdbは使い勝手が最悪だということだ。gdbを使いやすくするフロントエンド的なIDEも多数出ているが、そもそもgdb自体にフロントエンドを実装することを考えたインターフェースが備わっておらず、どれもクソだとしている。
だれか現状を核爆して更地にし、IDEのためのライブラリ用APIが用意されていて実行ファイルを容易に検証できるような、まったく新しいデバッガーを開発するべきだ
既存のシステムを捨てて新しく開発するのは現実的ではないが、そこまでしなければ解決できないほど、Linux環境のデバッガーの現状はクソだそうだ。
さらに、Linuxディストロの安定性の問題も挙げている。有名なディストロの長期サポート版をインストールしてすらなお、wi-fiやらオーディオやらが動かないことがよくある。特に、Linux環境におけるサウンドは悲惨であるとしている。
逆に、OpenGLにはそれほど問題はないとしている。というのも、モダンなゲームを多プラットフォーム展開したければ、どうせDirect3DとOpenGLの両方に対応することは必須であるからだそうだ。
まあ、たしかにVisual Studioの操作が簡単なデバッガーが恋しくなることはよくある。
YouTubeに、2000年から2013年までの、様々なグラフィックデモやベンチマークをつなぎあわせた、二時間もある長い動画が上がっている。すべて、PC上でリアルタイム描画されているものだ。リアルタイム描画の進化をみることができる。
リアルタイム描画はどこまで行くのだろうか。
母「ダメよ行っちゃダメ」
子「でも友達はみんな・・・」
母「あんたの友達がみんな橋から飛び降りたら、あんたもそれに続くっていうの？」
子「そりゃ、たぶんね」母「なんですって？ 何でよ？」
子「だってみんなやってるから」
子「一体そんな状況がどういう状況なのか考えてみなよ」子「俺の友達が一人残らず、いつもは落ち着いている奴や高いところ苦手な奴までみんな、同時にアタマ狂っちゃったのか・・・」
子「・・・もしくは、橋が燃えているのか」
母「えっと・・・それは・・・」
子「CNNで、『みんな車から降りて橋から飛び降りたんです。飛び降りなかった人たちは・・・』とか流れたとして」
子「残った奴らが何かいい目をみたとでも思うの？」
母「たぶんクッキーを見つけたんじゃないかしら」
子「わかったよ、お前残りゃいいだろ。俺行く」
友達がみんなやっているとすれば、それは友達がみんなバカだからやっているのではなく、状況的にやらざるを得ない可能性のほうが高い。それに、友達がみんな揃って同じ事をしたとき「友達は大丈夫か」と考えず、「友達はみんなバカだ、俺だけはまともだ」と考える人間の人格はどうかしている。
Top Linux and open-source programs survey results | ZDNet
2012 LinuxQuestions.org Members Choice Award Winners
LinuxQuestions.orgという、Linux関連の質問フォーラムで、人気のソフトウェア調査が行われた結果が公表されている。今回、Linuxと呼ぶのは、GNUに依存しないシステムも含まれているからだ。
手っ取り早い一位の一覧はこちら：
2012 LinuxQuestions.org Members Choice Award Winners
2位以下も含めた円グラフはこちら：
LinuxQuestions.org - 2012 LinuxQuestions.org Members Choice Results
zdnet.comもまずいちばんに挙げているように、デスクトップ用ディストロの一位が非常に興味深い。なんとSlackwareが一位だ。LinuxQuestions.orgのユーザー層のややかたよった傾向がうかがえる。一位といっても、20%程度なので、寡占状態ではないのだが。LinuxSlackware以外には、UbuntuやLinux Mint、Debian、Fedoraといったところが票を集めたようだ。
サーバー用ディストロの一位はDebianだが、ここでもやはりSlackwareが強い。
モバイル用途では、Androidが堂々の一位になっている。
データベース用ソフトウェアはどうか。最近、WikipediaやFedoraが閉鎖的なMySQLから離れて、MariaDBに移行する気配が見えるが、このサイトの結果は、MySQLが票の40%を得ている。MariaDBはSQLiteにすら劣る得票率。まあ、いくらMySQLのforkで挿げ替え互換性があるとはいえ、既存のソフトウェアの置き換えは一朝一夕にはいかない。FedoraのデフォルトパッケージがMariaDBになれば、少しは変化があるかもしれない。
NoSQLはMongoDBが一位だが、そもそも票数が極端に少ない。まあ、NoSQLの利用者が少ないからだろうが。
ブラウザーはFirefoxが一位、残りの票はほとんどChromeとChromiumとOperaが得ている。Operaは不自由なソフトウェアなので論外だが、結局、自由で本格的なブラウザーといえばMozillaかWebkitになる。
VoIPアプリケーションの一位が不自由なSkypeなのは憂うべき現状だ。
人気のデスクトップ環境はKDEが余裕で一位だ。Slackwareが一位になるようなユーザー層なのだから、もっとライトウェイトなデスクトップ環境が人気になっていてもよさそうなものだが。Gnome Shellはそれほど人気ではない。むしろ、Cinnamonに脅かされている。
テキストエディターはvimが圧倒的に一位だ。まあ、これは当然の話だ。もしvimが一位でないとするならば、このアンケートの妥当性を疑うところだ。
プログラミング言語はPythonが一位。バージョン管理システムはgitが一位と、まあこの辺はとくに驚きはない。ターミナルエミュレーターの一位がKonsoleなのは、KDEが一位だからだろう。
オープンソースハードウェアはRaspberry Piが圧勝。まあ、知名度からいえば当然だろうが。
もし可能であればいつ、インターネットの帯域がFedExに打ち勝つのか？
—Johan Öbrinkテープを満載したワゴン車の帯域をあなどるなかれ。
—Andrew Tanenbaum, 19812040年
数百ギガバイトのデータを転送したいとしたら、通常はインターネット越しに送るより、FedExでHDDを送るほうが速い。これは何も目新しいアイディアではなく、スニーカーネットと呼ばれているもので、Googleが内部的に大量のデータを転送するのにも使っている手法だ。
しかし、今後も常にそうだろうか？
Ciscoの推定によれば、インターネットの総トラフィックは、毎秒167テラビットである。FedExは654機の貨物飛行機を所有しており、一日あたり120万キログラムもの積載容量がある。重さ78グラムのラップトップ用のSSDは、1テラバイトの容量がある。
つまり、FedExは、毎日150エクサバイト、または毎秒14ペタビットのデータを転送できるわけで、これは現在のインターネットのスループットの百倍近い量だ。
ハイエンドのラップトップ用ドライブ： 136個
容量： 136テラバイト
コスト： 13万ドル
（プラス靴の値段40ドル）コストさえ気にしなければ、この10キログラムの靴箱には、インターネットが何個も入るわけだ。
MicroSDカードを使えば、容量効率は更に上がる。
MicroSDカード: 25000枚
容量: 1.6ペタバイト
コスト: 120万ドルこの親指サイズのチップは1キログラムあたり160テラバイトの容量があり、すなわちMicroCDカードを積んだFedEx貨物機は、毎秒177ペタビット、または毎日2ゼッタバイト転送できる。現在のインターネット帯域の千倍以上だ。(これを処理する装置は面白そうだ。Googleは巨大なカード処理場を必要とするだろう。)
Ciscoの推定によれば、インターネットの帯域は毎年29%増えているそうだ。この増加割合では、FedExの転送量には、2040年に到達する。もちろん、ドライブが保持できる容量も、その時には増えているだろうが。FedExに追いつくためには、転送量がストレージ容量より増加しなければならない。これは、まずないだろう。ストレージと転送量は密接に関係しているからだ。データはすべて、どこかからやってきて、どこかに収まる。もちろん、将来の利用の形態を予測するなんてことは出来ないが。
FedExは今後数十年は広帯域でありつづけるだろうが、技術的には、より広い帯域を構築できる。実験的なファイバークラスターは、毎秒1ペタビット以上出している。このクラスターを200本使えば、FedExに勝てる。
もし全米の飛行機運送業者を雇ってSDカードを輸送させれば、スループットは毎秒500エクサバイト--1ゼッタバイトの半分--に達する。この転送量を実現するには、上記のペタビットケーブルは50万本必要になる。
純粋な転送量の結論としては、インターネットがスニーカーネットに打ち勝つ日はやってこないだろう。もちろん、ほぼ無限の帯域には、80000000ミリ秒のping時間という欠点もあるのだが。
トントン
「インターネットのお届け物でーす」
「あ、新しいHALOのデータね」
「あたしの撃ったプラズマ銃は誰かにあたったかしら」
「荷物がやってくるってのは嬉しいことだね」
「Ebayから1ドルで送料無料のアイテムを検索するスクリプト書いた」
「365ドル設定したので、毎日、なにか適当なものを買うってわけさ」
「ゴミばっかりだったらどうするの？」
「誰かにあげるさ。でも中には掘り出し物もあるはずだ」1日目: ゴムホース
「まあ、家周りに使えるか」2日目: スキーマスク
「今は春だけど、まあ、まあ」3日目: 罠
「ははぁ」4日目: ペンタゴン観光マップ
「ええー」5日目: 潤滑油
「FBIの要注意リストに載る前にやめるか」
Amazonガチャが話題なので。
ちなみに、titleのbobcatについては、xkcd: A-Minus-Minusを参照。
[Phoronix] Wine On Android Is Coming For Running Windows Apps
今年のFOSDEMで、Wine開発者のAlexandre Julliardにより、開発中のAndroid上で動くWineのデモが行われたそうだ。
デモは、Apple MacBookでAndroidエミュレーター環境で行われたので、極めて遅かったそうだ。
まあ、x86エミュレーターのqemuを使うのだろうから、実機で実行しても、やはりそれなりに遅いだろうが。
C++ containers that save memory and time
cpp-btree - C++ B-tree - Google Project Hosting
Googleが、B-tree実装のSTLコンテナー(map, set, multimap, multiset)を発表した。
多くのSTLの実装では、map, set, multimap, multisetは、Red-Black treeで実装されている。Googleの発表によれば、B-tree実装のコンテナーは、赤黒木実装に比べて、速度が上がり、しかもメモリ消費量も削減できるとしている。
紹介まで。
B木は一つのノードに複数の要素を格納する。これにより、ポインターなどのオーバーヘッドを低減でき、メモリ消費量の削減につながる。また、複数の要素を一括してノードに詰め込むため、速度向上もあるのかもしれないが、そのへんはよくわからない。小さな要素を多数扱う際には好都合かもしれない。
STLのコンテナーをB木で実装する欠点としては、メンバー関数emplace系が実装できなくなることだ。というのも、B木ではひとつのノードに複数の要素が格納され、さらにノード単位でバランスを取っているので、単純に任意の順序を取る要素ひとつの都合だけで、ノードのつなぎ変えができない。つまり、置き換えはいかにも無理だ。
Boost 1.48から1.52までのBoost.Localeライブラリには脆弱性がある。
boost::locale::utf::utf_traitsは不正なUTF-8シーケンスを受け付けてしまう。
これらの関数をUTF-8入力の検証に使うアプリケーションは、不正なUTF-8シーケンスが適正であると誤認する恐れがある。
このバグは次のBoost.1.53で修正される。
より詳しくは、#7743 (utf_traits::decode does not check for correct UTF-8 trailing bytes) – Boost C++ Librariesを参照。
Users who can't upgrade to the latest versions may apply the following patch to fix the problem.最新のバージョンにアップグレードできないユーザーは、以下のパッチを適用して、問題の修正を行える。
Future of Boost Windows Installers
BoostProの出資者のDave Abrahamsが、Appleに行く事になったので、BoostPro社をたたむらしい。Boostユーザーへの直接の影響としては、Windows用のBoostの簡易インストーラーがなくなることだろう。インストーラーを構成するスクリプトなどは、boostpro/installer · GitHubで公開されるそうなので、誰かが引き継ぐかもしれない。
とはいっても、もはや不自由なWindowsに未来はないので、どうでもいいことだが。
mjg59 | The current state of UEFI and Linux
Matthew Garrettが、UEFIの実装の現状と、一部の悲惨な実装について語っている。
まとめ：大方、問題なく動く。
既知の問題：
いくつかのサムソンのラップトップ。サムソンのラップトップのドライバーはちょっとばかりヘンテコになっている。問題のラップトップが出荷された2010年では、大半のベンダーは、ファームウェアに、ACPIにしろ、WMIにしろ、何らかのアブストラクション機構を作っていた。サムソンはいまだに時代遅れの手法を使っていた。特定のアドレス領域が与えられており、そのアドレスを読み込んでオフセット集を取得する。そして、そのオフセットを元にマジックナンバーをマジックシステムIOポートにオフセットを元になんとかすれば何かが起こる。その書き込みはシステム・マネジメント・モードを発動させる。これは特別なx86 CPUモードであり、プロセッサーがOSからは見えず、OSのあずかり知らぬまま、メモリー上のコードを実行するのだ。これ自体は特に目新しいことではない。（システム・マネジメント・モードは1990年に386slとして初出している）。しかし、これはシステムベンダーがインターフェースを変更しないことに依存している。どうやら、サムソンはUEFIに移行する際、プラットフォームのインターフェースを変えたらしいのだが、昔のドライバーの挙動から保護するはからいはしなかったらしい。モダンなサムソンのラップトップでこれらの操作を行うと、修復不可能なマシンチェック例外が発生し（結果的にはラップトップを文鎮化してしまう）。まあ、サムソンの前科を考えれば、驚くにはあたらない。
吉報としては、この問題はセキュアブート以前にも発生していたのであり、セキュアブートの問題ではないということだ。
いくつかの東芝製は、Linuxをブートできない。これは、東芝内か、あるいは東芝のサードパーティベンダーの技術力不足によるものだ。東芝は署名鍵をバイナリを検証するデータベースに入れたままにしておき、ホワイトリストとブラックリストのアップデートにつかうデータベース用の署名鍵もそのまま残しておくという失態をしでかしたのだ。吉報としては、これは明白にMicrosoftのWindows 8認証ガイドライン違反であり、おそらく東芝側にBIOSを修正するよう圧力がかかるだろう。凶報としては、いま世の中に出回っているコンピューターはいまだに壊れたままで、東芝はどうも出回ったハードウェアにファームウェアアップデートを提供したくないようなのだ。
いくつかLenovo製は、WindowsやRed Hat Enterprise Linuxしかブートしない。私は大いに痛飲することを推奨する。というのも、Lenovo側に修正する動きはいまだもってまったく見られないからだ。
まあ、あまり嬉しくない既知の問題だが、私の知る限り、これで問題は全部だ。いくつかのサムソン製と、一時期の東芝製と、一時期のLenovoデスクトップを除いては、Linuxは問題がないはずだ。もし、他にFedora 18をインストールできないUEFIシステムがあれば、教えてくれれば、我々は問題を検証する。
Lenovo製のコンピューターがUEFIブートで、WindowsとRed Hat Enterprise Linuxしかブートしないというのは、クソなファームウェア実装によるものだ。本来ファームウェアがパースすべきでないブートエントリの表示名としての文字列をパースして、WindowsやRed Hatでデフォルトで使われている文字列と一致しなければブートを拒否するというタコな実装になっている。詳しくは本の虫: LenovoのUEFIのアホくさい実装を参照。
また、サムソンの前科の例としては、Slashdotに詳しいコメントがある。
Linux: Booting Via UEFI Can Brick Samsung Notebooks - Slashdot
サムソンのeMMCファームウェアにバグがあり、セキュア削除コマンドを発行した際、ウェアレベリングが正しく動作せず、ハードウェアが動作不能になってしまうという問題で、サムソンはいまだにこの問題を積極的に修正していないというものだ。
まあ、これは、セキュアブートの問題と言うよりは、規格通りに正しく実装していないハードウェアベンダーのファームウェア上のバグと、問題が発覚したにもかかわらず修正をしない無責任なハードウェアベンダーの問題である。さらに、UEFIの規格がやたらと複雑なのも、規格違反の実装を出す一因になっているだろう。もっとも、BIOS時代だって規格違反、不具合だらけの実装が修正されずに出回り、OS側での対処を余儀なくされているのだから、問題は変わっていないのだが。
追記：ハードウェアベンダーがLinux対応を謳っているかどうかは関係がない。UEFI規格違反であり、したがってUEFI対応を謳っているにも関わらず規格違反の実装をしている欠陥品ということになる。
rdar://13128709: OSX apps (TextEdit) crashing in spell-checker (I think).
OS Xの、おそらくスペルチェッカーに不具合があり、"File:///"（最初のFは大文字）と入力すると、3つ目の/でプログラムがクラッシュするらしい。かなり広範なテキストを入力するOS標準のUIを使っているプログラムが影響を受けるそうだ。
Hacker Newsのコメントでは、SkypeやChromeやSafariはおろか、Mac App Storeの検索バーや、中でも滑稽なのは、この不具合によってクラッシュした結果起動される、OS付属のクラッシュリポーターすらクラッシュさせるらしい。
