2016-02-29

C++標準化委員会の文書: P0033R1-P0059R1

P0033R1: Re-enabling shared_from_this

enable_shared_from_thisの規程を書き直す提案。

enable_shared_from_thisとは、クラスの基本クラスとして使うと、shared_from_thisというメンバー関数が追加され、そのクラスのオブジェクトを現在所有しているshared_ptrが返る。

class X : public std::enable_shared_from_this<X> { } ;

int main()
{
    auto sp1 = std::make_shared<X>() ;

    // sp1とsp2は所有権を共有する
    auto sp2 = sp1->shared_from_this() ;
}

問題は、複数のshared_ptrに所有された場合どうなるのだろうか。

X * ptr = new X{} ;
std::shared_ptr<X> sp1( ptr ) ;
std::sahred_ptr<X> sp2( ptr, [](void *){} ) ;

// sp1とsp2のどちらと所有権を同じくするshared_ptrが変えるのか?
ptr->shared_from_this() ; 

規格はこの場合の挙動について述べていない。既存の実装はすべて、sp2はsp1を上書きする。しかしこの挙動は、単にこの可能性を考えなかっただけにすぎない。Boostのshared_ptrは書きかえない。これはユーザーのフィードバックによるものである。

これを考察すると、最初のshared_ptrが所有権を持つのが自然で、デリーターが何もしないshared_ptrを作りたいことはあるかもしれず、この例が動いてほしい場合はあるが、動かないでいて欲しい場合はない。そこで、最初のshared_ptrから上書きされない決定がなされた。

また、weak_ptrを返すweak_from_thisも追加された。

P0035R1: Dynamic memory allocation for over-aligned data

operator newにオーバーアラインを守るオーバーロードを追加する提案。

問題は、この提案だとだいぶ文法が汚いことになるのではないか。

auto * ptr = new(static_cast<std::align_val_t>(32)) int[128] ;

P0037R1: Fixed-Point Real Numbers

固定少数点数ライブラリ、fixed_point<ReprType, Exponent>の提案。

P0040R1: Extending memory management tools

メモリ管理のためのライブラリとして、デストラクターを呼ぶdestroy, uninitialized_move, uninitialized_value_construct, uninitialized_default_constructを追加。これらはコア言語機能だけでも行えるが、記述が面倒なのでライブラリとしてあると便利だ。

P0046R1: Change is_transparent to metafunction (Revision 1)

連想コンテナーでheterogeneous lookupを許可するかどうかを判断するにはcomparatorにis_transparentというネストされた型名が必要だが、これをpermits_heterogeneous_lookup<T>というわかりやすいメタ関数に置き換える提案。

[PDF] P0052R1: Generic Scope Guard and RAII Wrapper for the Standard Library

汎用RAIIラッパーライブラリの提案。

#include <scope>

int main()
{
    {
        auto file = std::make_unique_resource( fopen("hoge", "w"), &fclose ) ;
    }

    {
        auto memory = std::make_unique_resource( malloc( 100 ), &free ) ;
    }

    {
        auto s1 = std::make_scope_exit( []{ std::cout << "leave scope" ; } ) ;
        auto s2 = std::make_scope_success( []{ std::cout << "leave scope normaly" ; } ) ;
        auto s3 = std::make_scope_fail( []{ std::cout << "leave scope by exception"} ) ;
    }

}

unique_resourceは、ある型のオブジェクトを保持し、破棄されるタイミングでそのオブジェクトを引数に渡してデリーターを呼んでくれる。

scoped_exitは、脱出関数を引数に取り、破棄されるタイミングで脱出関数を呼んでくれる。make_scope_xxxには3種類ある。exitはスコープから抜けたら必ず脱出関数を呼ぶ。successは例外によらずにスコープを抜けた場合にのみ脱出関数が呼ばれる。failは、例外でスコープを抜けた場合のみに脱出関数が呼ばれる。

もうひとつ、make_unique_resource_checked(R r, S invalid, D d)という関数があり、これはrがinvalidに等しい場合、返されるunique_resourceは、すでにreleaseが呼び出されたあとである。

今回の変更点は、unique_resourceのリソースとデリーターは、無例外コピー可能な型でなければならないとするもの。これにより設計が単純になり、無例外コピー可能ではないstd::functionも使う必要がなくなる。また、リファレンスを渡す場合は、std::ref/crefをユーザーが使わなければならない。

P0055R1: On Interactions Between Coroutines and Networking Library

提案されているネットワークライブラリの非同期呼び出しとしてfutureが使われているが、コルーチンを使うようにしたらオーバーヘッドが下がった上にコードも簡潔になったという文書。

[PDF] P0057R2: Wording for Coroutines

コルーチンの文面案。

[PDF] P0058R1: An Interface for Abstracting Execution

スレッドプール、協調型ファイバー、SIMD、GPGPUまで含めた実行媒体を表現できるexecutorライブラリの提案。スレッドからSIMDやGPGPUまでを包括したいいライブラリが設計できるとは思えない。

[PDF] P0059R1: A proposal to add a ring span to the standard library

ring_spanライブラリの提案。

この提案は名前が悪い。ring_viewとでも改名すべきではないだろうか。

いわゆるリングバッファーライブラリなのだが、前回の提案が固定長リングバッファーと動的リングバッファーの2つがあったのに対し、この提案では、ring_spanに統一されてしまっている。ring_spanは連続したストレージ上にリングバッファーを構築するが、ストレージの所有はしない。ストレージはユーザーが用意する。

つまりデフォルト構築もできないコンテナーなのだが、すごく使いづらい気がする。

ドワンゴ広告

来月ドワンゴで開催する予定の勉強会にレーザープリンターを持ち込みたいという猛者がいるので困惑しているが、PostScriptのデモのための実行環境としては極めて普通であり当然予期すべき事態ではある。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2016-02-27

歌舞伎座.tech #9で発表される各言語の簡易的なまとめ

3月20日に以下のような勉強会を企画した。

歌舞伎座.tech#9「異種プログラミング言語格闘勉強会」 - connpass

今回は様々な言語を持ち寄って発表する勉強会にしたかったので、有名な言語の発表枠をいくつか用意して、それ以外の言語での発表は明示的に要求させるようにした。ネタ枠として正規表現とかEsoteric的な何かの言語の発表枠も用意しておいた。

ところが、予想に反して、有名な言語の発表枠が埋まらず、発表されてから数年しか立っていないような先進的な言語やネタ言語が多かった。中には聞いたことのないような言語もあるので、Googleで検索して5分ぐらいでわかるような内容の説明を以下に並べておく。

C++(シープラスプラス)

1983年頃から、ベル研究所内でBjarne Stroustrupにより設計、開発された言語。これ以前のC with Classesの経験を元に一から作られた。我々の知る今のC++は1998年に正式に規格が制定された。そこから規格更新を繰り返して、今は2014年の規格が最新になっている。

C++は低級層のプログラミングや、パフォーマンスが重要な分野に用いられている。

JavaScript(ジャバスクリプト)

1995年に、Netscapeというブラウザーに搭載された言語。Brendan Eichにより、たったの10日間で開発されたと言われている。当初はWebサイトにクライアントサイド側でちょっとした動的なギミックを付け加える程度の用途だったのだが、今ではWebにおける共通言語の地位を確立している。

正規表現(せいきひょうげん)

歴史はコンピューター以前にさかのぼることができる。もともとは数学を記述するための言語として、1956年にStephen Cole Kleeneによって考案された。正規表現がコンピューター上で用いられるようになったのは、Ken Thompsonによって、QEDというテキストエディターの検索機能として実装されたからだ。当時のKen Thompsonの正規表現実装は、高速化のためJITが使われていたという。JITの早期の使用例としても興味深い。なお環境は、IBM 7094でOSはCompatible Time-Sharing Systemである。検索機能として正規表現によるパターンマッチは、他のツールにも取り入れられた。

C++を含む多くのプログラミング言語が正規表現ライブラリを標準で提供している。また、言語によっては、Perlのようにコア言語で深くサポートされているものもある。特に、Perlの正規表現などは、正規表現やマッチした結果を参照できるので、チューリング完全な計算力を持っている。

Esoteric(エソテリック)

これは具体的なプログラミング言語の名前ではなく、難読プログラミングの総称である。例えば有名どころの難読言語としては、Brainfuckがある。Brainfuckはチューリング完全な計算力を持っているので、計算力として根本的に他の汎用的なプログラミング言語に劣ることはない。

今回の発表でどのような言語を使うのかは、まだ知らない。

Elixir(エリキサー)

この言語は2012年に公開されたばかりで、相当に新しい。作者はJosé Valimだ。この言語の現時点でのおそらく唯一の実装はErlang VM上で動くバイトコードを生成する。Erlangの既存の資産を活用しつつ、Erlangより使いやすい言語が欲しかったのが開発動機だそうだ。

Go(ゴー)

2009年に発表された言語。Googleにより開発されていて、設計者はRobert Griesemer, Rob Pike, Ken Thompsonの3人だ。まだ言語としては発表されてから7年しか立っていないが、巨大な民間企業の後ろ盾を得た開発により、すでに現場で使えるほどの品質になっている。Googleによる実装はすでにGoでセルフホストされている。libcにも依存しないかなり独立性の高い言語となっている。

Nim(ニム)

2008年に公開された。設計者はAndreas Rumpfだ。現在の実装は、コンパイル結果としてCかC++かObjective-Cのコードを吐くようになっている。実装はNimでセルフホストされている。

Crystal(クリスタル)

2014年に公開された。設計者はAry BorenszweigとJuan Wajnermanだそうだ。文法はRubyに影響を受けている。強い静的型付けはあるが、変数の型は明示的に指定しなくて良いようになっている。

シェルスクリプト

ここでいうシェルとは、UNIXとUNIX風の環境におけるシェルのことで、そのシェルが提供する言語だ。筆者のデフォルトのシェルはbashだ。こだわりの強い情報強者たる読者はもちろんもっと強力なシェルを使っていることだろう。

ただし、この発表者のいうシェルスクリプトとは、POSIX規格の範囲内のシェルスクリプトだ。/bin/shがbashへのシンボリックリンクになっている環境も多い中で、POSIXの規程によるシェルスクリプトとプログラムだけを使ってコードを書くのは大変だ。

F#(エフシャープ)

2005年公開。主要な設計者というかプロジェクトの管理者はDon Symeだ。ML、とくにOCamlの影響を強く受けているという。実行環境としては.netフレームワーク上で動く。

歴史もそれなりに長く、Visual F#としてWindows環境でとても有名なIDEであるVisual Stdioに同梱されているそうだが、私はMLの分野をよく知らないためどの程度使われているのかわからない。

Pony(ポニー)

2013年に公開されたらしい。背景事情の情報が不足しているが、作者はおそらくSylvan Clebschではないか。

capabilities-secureな言語であると謳っているが、これは別に権限を細かく分割して必要最小限度の権限しか持たないCapability-based securityをサポートした言語という意味ではなく、単に型安全、メモリ安全、例外安全、データ競合フリー、デッドロックフリーのような意味を持つらしい。紛らわしい変な言葉を発明しないでもらいたいものだ。

Frege(フレイガ)

2011年公開。作者はIngo Wechsung。公式に、JVM用のHaskellを謳っていて、文法もほとんどHaskell互換性だ。。外部依存のないHaskellコードはそのままコンパイルできるか、僅かな修正だけで動くことを目指している。また、JVMにかかわらないFregeコードは他のHaskell実装でも実行できるのだという。

それでもHaskellという名前を使わないので、完全互換は目指していないのだろう。Fregeという名前は、Gottlob Fregeに由来する。

Rust(ラスト)

2010年に公開された。もともとの原案の設計者としてはGraydon Hoareで、開発はMozillaの支援を受けている。最初の実装はOCamlだったが、すぐにRustでセルフホストされるようになった。コード生成などのバックエンドはLLVMを使っている。

目標は、並列化処理を安全に書ける言語だそうだ。文法的にはCやC++にかなり似ている。

Nemerle(ネマール)

2003年公開。ヴロツワフ大学の学生と教授が開発したらしい。言語の名前はUrsula K. Le Guin著のゲド戦記、A Wizard of Earthsea(影との戦い)に出てくるキャラクターに由来するそうだ。英語表記ならばこの読みでいいのだろうが、ポーランド人が読むとネメレあたりの発音になるのだという。

それはともかく、言語的には.Net上で動く。関数型かつオブジェクト指向な言語だそうだ。MLの影響が強い。

Postscript(ポストスクリプト)

1982年公開。設計者はJohn Warnock, Chuck Geschke, Doug Brotz, Ed Taft, Bill Paxtonで、Adobe Systemsによって開発された。

この言語は人間が手で書くことを想定しておらず、ツールによって生成された上で、プリンターに送信される。プリンターはPostscriptを解釈してページを生成し、印刷する。Postscriptは印刷物のための中間言語としての規格だ。歴史を紐解けば、デスクトップ描画にPostscriptを使ったシステムもあったようだ。

Postscriptはチューリング完全な計算力を持つ。そのため、プログラミングは可能である。

Common Lisp

1984年公開。設計者はScott Fahlman, Richard P. Gabriel, Dave Moon, Guy Steele, Dan Weinrebだ。ANSI規格にもなっている。

軽くまとめるつもりだったが、意外と時間がかかった。

ドワンゴ広告

この記事はドワンゴ勤務外に暇だったので書いた。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2016-02-25

C++標準化委員会の文書のレビュー: P0003R1-P028R1

P0003R1: Removing Deprecated Exception Specifications from C++17

道的な例外指定を取り除く提案。

動的例外指定とは以下のような機能をいう。

void f() throw( int, double, int * ) ;

C++98の規格が制定される頃には、すでに動的例外指定の利用例はほとんどなかった。C++11で、例外指定から動的例外指定に改名された上で、deprecated扱いにされた。

十分な移行期間を与えたので、C++17で取り除く。

P0005R3: Adopt 'not_fn' from Library Fundamentals 2 for C++17

Library Fundamentals TSで提案されているVariadic Templatesを使ったnot_fnを先行して標準規格に追加する提案。

deprecated扱いされたnot1, not2と違い、引数をいくらでも取れる。

template < typename ... Types >
bool f( Types ... args ) ;

int main()
{
    auto g = std::not_fn(&f) ;

    // 任意個の引数に対応
    g(1) ;
    g(1,2) ;
    g(1,2,3) ;
}

P0009r1 : Polymorphic Multidimensional Array Reference

配列のレイアウト(FORTRANの列優先レイアウトとCの行優先レイアウト)や、構造体の配列と配列の構造体(構造体の各データメンバーがそれぞれ配列になったレイアウト)などの差異を吸収するポリモーフィックな多次元配列ラッパーである、array_refライブラリの提案。

[PDF] P0010R0: Adding a subsection for concurrent random number generation in C++17

C++の乱数ライブラリは並列アクセスできないのでその注意を文面に追加する提案。

P0018R2: Lambda Capture of *this by Value as [=,*this]

lambda式に*thisを値でキャプチャする文法の追加。

lambda式は*thisを値でキャプチャーできない。

struct S
{
    int x ;
    auto f()
    {
        return [=]{ return x ; } ;
    }
} ;

int main()
{
    std::function<int()> f ;

    {
        S s ;
        f = s.f() ;
    }

    // 実行時エラー、オブジェクトsはすでに破棄されている。
    f() ; 

}

なぜならば、コピーしている値はthisポインターであって、*thisではないからだ。上記のコードで、[=]と[&]は同じ意味になる。

そのため、新しいsimple-captureとして、*thisを追加する提案。上記のコードは、以下のように書き換えればエラーにならない。

auto f()
{
    return [*this]{ return x ; }
}

P0019R1 : Atomic View

非アトミックオブジェクトに対してアトミック操作を提供するatomic_viewライブラリの提案。既存のコードの変数の定義を変えるのが現実的ではないコードに足して現実的なライブラリ。


int data ; // 変更不可能

void f()
{
    std::experimental::atomic_view adata( data ) ;
    ++data ; // アトミック操作
}

P0020r1 : Floating Point Atomic

浮動小数点数型に対して使えるatomic_viewライブラリ。

P0024R1: The Parallelism TS Should be Standardized

<algorithm>に並列実行版を追加するParallelism TSの実装経験を検討した結果、標準規格に取り入れるべきであるとする提案。

[PDF] P0028R1: Using non-standard attributes

attirbuteの名前空間の省略記法の提案。

独自のattributeトークンを使った独自拡張は、トークンの重複を防ぐためにattribute名前空間を使うことが多い。

void f() {
    [[rpr:: kernel, rpr:: target(cpu,gpu)]]
    do task();
}

しかし、attribute名前空間をいちいち指定するのは面倒なので、using宣言に相当するような機能がほしい。そこで、この提案は、そのような機能を付け加える。

void g() {
    [[ using rpr: kernel, target(cpu,gpu)]]
    do task();
}

キーワードはとりあえずusingにしているが、変わるかもしれない。

ドワンゴ広告

来月はドワンゴのセミナールームでだいぶ血の気のあらそうな勉強会が開催されます。

歌舞伎座.tech#9「異種プログラミング言語格闘勉強会」 - connpass

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2016-02-23

C++標準化委員会の文書: N4568-N4577

P4568: PL22.16/WG21 draft agenda: 29 Feb-05 Mar 2016, Jacksonville, FL/US

Jacksonville会議の予定のドラフト

[PDF] N4569: Working Draft, C++ Extensions for Ranges

コンセプトを使ったRangeライブラリの提案。個人的には現状のコンセプトがあまり気に入っていないので延期されてほしい。

[PDF] N4570: Oulu Meeting Information

2016年6月にフィンランドのOuluで開かれる会議の案内。

[PDF] N4571: 2016-11 Issaquah meeting information

2016年11月にアメリカ合衆国ワシントン州Issaquahで行われる会議の案内。

[PDF] N4572: WG21 telecon meeting: Pre-Jacksonville

Jacksonville会議前の2時間の電話会議の予定。

N4573: 2017-02 Kona WG21 Meeting Information

2017年2月にハワイで行われる会議の案内。

[PDF] N4575: Networking TS Working Draft

Boost.Asioを元にしたネットワークライブラリのTSへの提案。

[PDF] N4576: Networking TS Editor's Report

ネットワークライブラリTSの編集者の報告書。P0112R1からの変更点は、組版の修正。

[閲覧は標準化委員限定][PDF] N4577: Technical Specification for C++ Extensions for Concurrency

futureにthenとかwhen_allなどのメンバーを追加したり、latchとbarrierを追加したり、atomic_shared_ptrを追加したりする非同期まわりのライブラリ拡張TS。閲覧には標準化委員であることが必要。

ドワンゴ広告

標準化委員会の文書のレビューもしたいのだけれど今は別用もある。

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2016-02-22

歌舞伎座.tech#9「異種プログラミング言語格闘勉強会」開催のお知らせ

しばらく勉強会を開催していなかったので、3月20日に勉強会を企画した。以下のconnpassから参加登録ができる。

歌舞伎座.tech#9「異種プログラミング言語格闘勉強会」 - connpass

今回の勉強会は、銀座松竹スクエアの13Fにあるドワンゴのセミナールームで開催する。去年まで、ドワンゴのセミナールームは歌舞伎座タワーにあったのだが、今年から松竹スクエアという歌舞伎座タワー近くの別の建物に移転した。開催場所が歌舞伎座ではないのに歌舞伎座.techとはこれいかにとツッコミたくなるところだが、「歌舞伎座周辺で開催される技術勉強会」という言い訳が上司から提供された。

今回の勉強会のタイトルは、歌舞伎座.tech#9「異種プログラミング言語格闘勉強会」だ。

これまでC++に特化した勉強会を開催してきたが、さすがに毎回C++だけというのもどうかと思い、今回は前々からやってみたかった勉強会を開催することにした。すなわち、様々な言語を一つづつ発表するというものだ。普段は遭遇しない分野に遭遇できるいい機会を作れるのではないかと考えている。

今回は、有名どころの言語をある程度抑えつつ、Perl 6, 正規表現、何らかのEsoteric言語の発表枠も入れてみた。すべての発表枠が埋まるかどうかはわからない。また、自分の好きな言語の発表枠がない事態に備えて、「俺の好きな言語がないけしからん発表枠」も追加した。

追記:

発表後の反応から、少し方針を変更した。

この勉強会では、様々な言語を取り扱う。それぞれの言語枠で発表する人は、以下のような内容の発表が期待される。

  • 如何にして私は心配するのをやめてこの言語を愛するようになったのか
  • 他の言語と比較したこの言語の優位性
  • この言語ならでは特色、楽に書ける処理
  • 知名度の低い言語の場合、言語そのものの紹介

ドワンゴ広告

ドワンゴは本物のC++プログラマーを募集しています。

採用情報|株式会社ドワンゴ

CC BY-ND 4.0: Creative Commons — Attribution-NoDerivatives 4.0 International — CC BY-ND 4.0

2016-02-18

Appleのマーケティングに騙されてはいけない

Appleがアメリカで容疑者のコンピューターの暗号解除に協力するよう裁判所命令を出されたかどで、Appleは顧客のプライバシーとセキュリティを脅かす命令だとして反対する公開声明をだしている。世間はAppleの顧客のプライバシーとセキュリティを守るようにみえる姿勢を賞賛しているようだ。

しかし騙されてはいけない。これはAppleのマーケティング戦略に過ぎない。Appleは顧客のプライバシーとセキュリティを守る技術的な最善の努力を一切果たしていないので、プライバシーとセキュリティを気にかける人間はApple製品を使ってはならないのはもちろんである。

そもそも、Appleは国家政府に秘密裏に協力していた前科がある。今更顧客のプライバシーを守る云々などと言い出したのは、アメリカ政府による監視の実態を告発した真のアメリカの愛国者Snowdenの登場以降である。顧客のプライバシーとセキュリティをないがしろにしていたのが公になったから、マーケティング上の利益のためにこういった姿勢をみせているに過ぎない。

そもそも、今回のAppleに対する裁判所命令とはなにか。Appleは技術的に実質不可能な暗号解読を命じられたわけではない。今回の技術的な話はこうだ。

ある事件の容疑者のApple製のコンピューターのストレージは暗号化されている。このコンピューターには、復号するためのパスワードの入力に連続して規定回数以上失敗するとデータを消去する仕組みがある。アメリカ国家政府は、可能な限りのパスワードの組み合わせを試してパスワードを探し当てるブルートフォース攻撃をするために、Appleにパスワードの連続した入力間違いでデータ消去を発生させる仕組みを無効にする協力を要求しているのだ。

これは、おそらくAppleにとって技術的に可能である。この仕組みは、おそらくファームウェアかOSで実装されているはずだ。Appleのコンピューターは、ファームウェアとOSに対して、Appleが署名したバイナリでなければ実行されない仕組みになっているはずで、今回アメリカ政府がAppleに要求しているのはそのためだろう。

Appleが本当に顧客のプライバシーとセキュリティを重要視するのであれば、バイナリ署名の鍵はAppleが全顧客で共通の鍵を使うのではなく、顧客が作成、管理するようになっているはずだ。それをしないからこういうことが起こるのだ。

そもそも、今のスマフォにはベースバンドプロセッサーという、まだセキュリティ意識の低かった1990年台に設計された基地局と通信するためのブラックボックスなCPUとソフトウェアが別に積まれている。セキュリティとプライバシーに気を使う人間が携帯電話を所有することはありえない。

まして、Appleの製品は、ソフトウェアが不自由である。ソフトウェアが信頼できるかどうかは、実際に検証されなければならないが、その検証作業を妨害している。

結論:Appleのあの宣言はSnowden以後のマーケティング戦略に過ぎない。

2016-02-11

Warner Music、ハッピーバースデーの歌の著作権を保有していないことを認めて訴訟を降りる

Warner Music Pays $14 Million to End 'Happy Birthday' Copyright Lawsuit - Hollywood Reporter

アメリカ合衆国で、有名なハッピーバースデーの歌(Happy Birthday To You)の歌の著作権使用料を請求していたWarner Musicに対し、同歌の歴史ドキュメンタリーを作成していた映画監督のJennifer Nelsonが、Warner Musicは著作権を有していないとしてクラスアクション訴訟を起こした。

この訴訟では、Warner Musicの提出した、著作権の委託管理を受けたという証拠となる出版物の肝心な部分が画像がやたらボケているので、現物を入手してみたところ、ボケた部分にはWarner Musicの主張するような記述がなかったという証拠まで提出されている。

2016-02-06

最近遊んだ不自由なビデオゲーム

不自由なゲーム専用OSであるWindows箱で最近遊んだゲームを紹介する。

Keep Talking and Nobody Explodes

爆弾解体ゲーム。ビデオゲームというよりはボードゲームに違い。ビデオゲーム側としては、爆弾を解体する操作を提供している。このゲームを遊ぶには最低二人が必要である。一人がコンピューターを操作して爆弾を解体する。爆弾を解体する人は、爆弾の解除マニュアルを読むことができない。

残りのプレイヤーは、できれば紙に印刷された爆弾解除マニュアルを読む。そして、爆弾を解体する人間と、口頭で通信して爆弾を解除させる。

爆弾解除マニュアルは不必要に回りくどく書かれている。そのため、爆弾解除係とマニュアル読者は不毛なやり取りを繰り返すことになる。例えば、以下は典型的なプレイ中の会話である。

マニュアル係「どんなモジュールがある?」
解体係「えーと、何か線がいっぱいあるやつがある」
マニュアル係「線は横? 縦?」
解体係「横」
マニュアル係「線は何本?」
解体係「5本」
マニュアル係「えーと、最後の線は黒い」
解体係「えーと、線は上から白、赤、黄色、赤、黒」
マニュアル係「最後の線の色は?」
解体係「黒」
マニュアル係「えーと、箱のどこかにシリアルナンバーがあるはずなのだけど」
解体係「シリアルナンバー?」 マニュアル係「そのシリアルナンバーの最後の桁は奇数?」
解体係「シリアルナンバー・・・あ、あった、でなんだっけ?」
マニュアル係「そのシリアルナンバーの、えーと、最後の桁は奇数」
解体係「最後の桁は・・・4」
マニュアル係「4は・・・偶数なので奇数じゃないか。次行って・・・赤い線はある?」
解体係「ある」
マニュアル係「何本ある?」
解体係「2本」
マニュアル係「えーと、じゃこれも違って・・・黒い線はある?」
解体係「ある」
マニュアル係「ということは・・・えーと、最初の線を切って」

これはとても面白い。

BioShock Infinite

待望のBioShockシリーズの第三段。だが期待されすぎた凡作。

グラフィックと音楽はいいのだが、戦闘が極めて退屈で、ストーリーも大して面白くない。エリザベスも可愛くない。

Kerbal Space Program

宇宙開発をするゲーム。ロケットを組み立てて地上から発射し、軌道に載せ、惑星探索をするゲーム。

舞台は地球のような恒星系を持つ惑星Kerbinから始まる。Kerbinは地球の10分の1のサイズなのに表面重力は同じというとても密度の高い物質で構成されている。

とても面白くて中毒性のあるゲームだが、筆者はまだ軌道にすらのせることができていない。軌道は極めて常識に反する。

Grapple

粘性のある球体がGrappling hookを駆使しながらスタートからゴールに移動するだけの面クリア型ゲーム。とても単純だがとても面白い。

Tower of Guns

ランダム生成されるステージ群をクリアしていくFPS。極めて単純だが面白く、息抜きに良い。

2016-02-05

往年のDOSマルウェアをDOSエミューレーター上で実行できる博物館

電子データの収集保存活動をしているInternet Archive(archive.org)が、1980年台、1990年台に流行した秀逸な画面効果を持つDOSマルウェアをブラウザー上でエミュレーターDOSBoxを使い安全に実行可能な状態で展示している。

The Malware Museum : Free Software : Download & Streaming : Internet Archive

とても興味深い。

2016-02-01

Archユーザー、rm -rfしてMSIのラップトップのUEFIのバグを発見する

No POST after rm -rf / / Kernel & Hardware / Arch Linux Forums

No POST after rm -rf / | Hacker News

Mount efivarfs read-only · Issue #2402 · systemd/systemd

Archのインストールを消去したかったので、遊びのためにMSIのラップトップで"rm -rf --no-preserve-root /"してみたArchユーザーのラップトップが文鎮化してしまった。なぜだ。

調査の結果、おそらく/sys/firmware/efi/経由でEFI変数(EFIの規格で定められているマザーボードが提供する小容量の不揮発ストレージ)に書き込みを行ったためだと判明した。

EFI変数に書き込むのは、EFI規格上完全に合法な操作であるが、どうやらファームウェアの不具合で、このMSIのラップトップでEFI変数に書き込むと文鎮化してしまう不具合があるらしい。

3年前にも似たようなことが話題になっていた。本当にEFIの現実の実装はクソだ。

本の虫: UEFIとLinuxの現状

もはやここまで現実の実装がクソであると、EFI規格は脆弱性を発生させるために国家の諜報機関によって意図的に複雑にされていることを疑いたくなる。