XPS13 モニター2 (Ubuntu導入編) #DELLアンバサダー

XPS13のQHD+モニターはグレア液晶で、FullHD液晶ならアンチグレア液晶です。 ノートPCを使うのがリビングでベランダを背にする位置が多く、明るい時間帯はかなり反射が眩しくなるのでアンチグレアの方が良かった。 Dellに限らず、2-in-1じゃないクラムシェルモデルはエンタメ性能よりもビジネス性能を重視してアンチグレアにして欲しいと思います。

バッテリーは Ubuntu でも大体10時間位持ちそうです。tlpをインストールしただけで特別なチューニングはしていませんが、1時間あたり10%ずつ減っていく感じです。 なお、BIOS設定画面にタッチパネルを無効化するオプションがあったのですが、体感できる差はありませんでした。 バッテリー時間が長いほうが良い人もFullHDモデルにしておいたほうが良さそうです。QHD+綺麗なんですけどね。。。

さて、Ubuntuデュアルブート化に挑戦したのですが、失敗しました。 Ubuntuは起動するのですが、Windows側を起動しようとしたらBitLockerの回復キーを求められ、記録してなかったのでWindowsを起動できません。 最近はセキュアブート+BitLockerとか、Intelの何かでBIOSSATAモードをAHCIにしないとNVMe SSDが使えなかったり、デュアルブート化するときの罠が多くて大変ですね。 回復ドライブからファクトリーリセットできるはずですが、面倒なのでモニター返却までこのままUbuntu1本で行きます。

Ubuntu 17.04 は最初に起動したときから自動で HiDPI を認識していたようで、2倍のスケーリングがかかっています。 期間限定のモニターであんまり設定に時間をつぎ込みたくないので、設定頑張らなくて良いのは便利。 私はデスクトップ環境にUnityを使っていますが、Gnomeも今のバージョンは整数スケールしか対応してないので、150%とかじゃなくて200%のスケールがちょうどいいQHD+は好都合だと思います。 (ubuntugnomeのHiDPIサポート改善に協力しているらしいので今後はまた変わってくると思いますが。)

一方、タッチパッドの使用感は良いものの、タイピング中の誤爆を結構してしまいます。 テーブルの上で使っているときは少し意識的に手首を浮かせていれば問題ないのですが、ソファで膝の上に置いたりすると結構な頻度で邪魔されます。 適当にググって見つけたPalm Detectionの設定は導入してみたのですが、うまく動いてないのかまだ誤爆はあります。

ACアダプタは、他のレビューでも叩かれていますが、AC側がミッキーコネクタな上にゴツいです。 あと、XPS 13はUSB PDでの給電にも対応しています。 試しに はんぺんさんの記事 で規格適合と紹介された PowerPort Speed 1 PD30 を試してみたところ、きちんと充電することができました。 30Wだと充電してくれないノートもあるらしいですが、XPS13は大丈夫だったので、モバイル時の荷物が減らせそうです。 ただ、このACアダプタはコンパクトな代わりにかなり熱くなって怖いので、普段は付属のACアダプタを使っています。

XPS 13 のモニターに当選しました #DELLアンバサダー

DELLアンバサダープログラムでXPS13のモニターに当選し、今日届きました。これから約1か月モニターしていきます。

モニターに応募した理由は、ちょうど今使っている ThinkPad X 250 の次のノートを物色していたからです。 XPS 13 以外の候補は、 X1 Carbon (14インチなのに1.13kgと軽い!), hp の Envy 13 (大きさ重さはほぼ同じだけど、12万円台でSSDが512GBにできる!), MateBook X (高いけど1kg台と軽くてモニターが3:2!)とどれも魅力的なので、XPS13も次のモデルではマイチェンじゃなくてもっとせめて欲しいところ。(あとできれば Ryzen mobile APUにしたい)

ちなみに、モニター終わったら貰える/安く買い取れるとかそういうのはないので、変に気を遣わずに X250 や会社で使っている MBP 13" (多分 2013 late) と比べて気になる点は厳しくガンガン書いてしまいます。

ThinkPad X250 と比べると、フットプリントはほぼ同じで、液晶が12.5インチから13.3インチに拡大しました。まだ日本語の読み書きしかしていないので、このサイズ差が生産性に影響するかは未知数です。 厚さも、X250のキーボード側の厚さがちょうど XPS13 の厚さくらいで、今どきの Macbook や ZenBook 3 みたいな感動的な薄さではないものの、十分スタイリッシュになりました。

液晶側は180度までは開きませんが、特別窮屈な感じはしません。カウンターキッチンの上において立ったまま使うときなどでも問題なく使えます。これが狭めのノートだとソファでくつろぎながら膝を立てたところにノートPCを載せて使う時とかに窮屈な感じになってしまうのですが、XPS13は及第点です。

f:id:methane:20170722170704j:plain

液晶は3200x1800のタッチパネルで奇麗です。Windowsで推奨のスケールは250%になってますが、200%にするとちょうどいい感じだし、フルHDの場合に使う125%や150%によくあるボケやレイアウトずれ(文字のはみだし)なんかも200%なら軽減されるんじゃないかなという淡い期待もあります。

一方で、重さはFull HDモデルが1.2kgなのに対してQHD+モデルは1.29kgらしく、スケールメーターを持ってないので計測はできませんが、持った感じはズシリと感じます。X250は1.44kgあるのでまだそれよりは軽いんですけどね。タッチなしのQHD+出ないかなぁ。タッチ欲しい人は2in1買うでしょ。今どきあえてクラムシェル選ぶ人にはタッチ要らないでしょ。(偏見)

その他のスペックはi7/8GB/256GBです。DellオンラインストアではQHD+は16G/512Gのモデルでしか選べないので簡単に入手できるスペックとは違うみたいです。個人的にはCPUがi5で良いので16GB/512GB/QHD+タッチなしが15万以下で選べるようになってほしいところ。 色はピンクゴールドだけど、落ち着いた色で男が使っても違和感無いです。

f:id:methane:20170722171608j:plain

気になるのが、ときどきキーボードの左側(Sキーあたり)からキュルキュル音が鳴ります。なるタイミングはよくわからない。 調べるとコイル鳴き症状があるようでたぶんそれだと思います。

キーボードのストロークは2013年のMBPと同じくらいで、感じはMBPがカシャカシャなのに対してちょっとゴムっぽいクリック感になります。ゴムっぽいといってもグニョっとネバ付く感じはなくて別に悪くないです。キーボードは右側が細くなってますが X250 も同じなので特に問題には感じてません。音もMBPより静かになったと思います。

ただ、エンターキーの右側を押すとキーが水平に下がるのではなく右側が下がる感じになるので、それが気になる。キーボードの右側の少し高くなってる面に小指が当たってしまいます。 MacBook, ZenBook 3, MateBook X みたいに本体の左右ギリギリまでキーボードが広がっている必要はありませんが、それでももう少しだけ余裕が欲しかった。 それ以外の配置はとてもよく、特にスペースキーはホームポジションで両手の親指がちょうどスペースキーの左右に乗せられるのが好印象です。

f:id:methane:20170723010211j:plain

ファンの音はMBP13と同じくらいですが、Chromeでこの記事を書いてる間もずっと回っていて、MBP13よりも回り始めやすい印象。あと、回ってるときに本体を傾けたり、液晶を閉じて持つと、ファンがどこかに干渉してハチが飛ぶ音みたいな音が鳴ります。ファンが壊れそうで耐久性が不安になるのでこれは改善してほしい。

モニタープログラムの決まりで改造は禁止なのですが、質問したところ返却前にリカバリするならデュアルブート化してUbuntuをインストールするのは問題ないそうです。 が、Windowsのディスク管理からパーティションの縮小ができなかったので、とりあえずWindows 10 CU にアップデートして使っています。

go-sql-driver/mysql の v1.3 が出たよ

リリース日が去年の12月なんでもう時間経っちゃってるんだけど、一応日本語でアナウンスしておきます。

MySQLドライバの go-sql-driver/mysql が、 Go 1.8 の新機能サポートの前に安定版リリースしようということで、 v1.3 のタグが打たれました。

master ブランチに昨日 (2017-03-23) から 大きい変更 をマージし始めたんで、glide などの依存管理ツールを使ってる人は、プロダクション/ステージングでは v1.3 に固定しておくことをお勧めします。 (それ以外の人はむしろ master ブランチでテストしてくれると嬉しい。)

Windows では2020年を待たずに Python 2.7 が使い物にならなくなっていく

昨日 mysqlclient 1.3.10 をリリースしました。 今までは Windows 版の wheel は Python 2.7 だけに提供していたのですが、 1.3.10 からは 3.5 と 3.6 だけに提供して 2.7 はドロップしました。

そもそも今まで Python 3 に wheel を提供できてなかったのは、 MySQL Connector/C の VC14 (VS2015) に対応したライブラリが提供されておらず、 Python 3.5, 3.6 は VC14 でビルドされていて VC12 用のライブラリにリンクすると大量のエラーでるわ自分で手順読みながら頑張って MySQL をソースからビルドしてもなんか動かないわで諦めてたからです。

それが、2年待て、よーーーやく MySQL Connector/C 6.1.9 から VC14 のライブラリが同梱される用になりました。 GPLだから困ったら自分でなんとかしろと言われればそれまでなんですが、もうちょっと早くできなかったんでしょうか、Oracleさん。。。

一方で、 Python 2.7 は VC9 (VS2008) でビルドされています。しばらく前の(具体的なバージョンは忘れた) MySQL Connector/C から、 vc10, vc11, vc12 用のライブラリしか提供されてなかったのですが、 vc10 と無理やりリンクするとリンクエラーも起こらずちゃんと動いてるっぽかったし、特にライブラリ側でmallocしたメモリをPython側でfreeするみたいな明らかな問題も無かったので、vc9とvc10のランタイムライブラリを両方リンクすることでなんとか wheel を提供できていました。

それが、 Connector/C 6.1.9 からは vc11, vc12, vc14 のライブラリだけが提供されるようになり、 vc10 のライブラリが消えました。 一応、 utf8mb4 に対応した後、 6.1.9 以前のライブラリバージョンを使ってビルドし続けることもできるんですが、もともと気持ちよくない構成でビルドしてたので思い切って Python 2.7 wheel のビルドをやめることにしました。

Windows でバイナリ互換性を維持するには VCRT のバージョンを固定する必要があり、 Python 2.7 は 2008 年の VCRT にずっと依存しています。 Python コア開発者は 2020 年まで Python をメンテしていますが、サードパーティーのライブラリは 2020 年まで 2008 年の VCRT をサポートしてくれるわけではありません。 VC++ 2013 や 2015 に移行したライブラリは、 VC++ 2008 では利用できない機能 (<stdint.h> とか) を喜んで使うでしょう。古いバージョンのライブラリを使い続けるのにも、セキュリティ fix をバックポートする努力をしなければ、安全でないものを配布することになります。 (Python 2.7 サポートを望む声に負けて、安全でないライブラリを配布してるライブラリがすでに存在するかも知れません。というか存在すると思います。)

Windows 向けに binary wheel を提供している開発者は、そろそろ Python 2.7 のサポートのために変に頑張るのを止めて、代わりにユーザーに Python 3 への移行を頑張ってもらうべきだと思います。

WindowsPython 2.7 を使っている開発者は、 pip install が成功するからという理由で Python 2.7 を使い続けるのをやめましょう。 「Python 2.7 サポートのためにバグやセキュリティホールのある古いライブラリが使われてないか」をチェックし続ける努力より、 Python 3 に移行する努力のほうが建設的ですよ。

pip 9.1 から msgpack が使われるようです

Adopt cachecontrol 0.12.0 with msgpack support というコミットがありました。

どうやら CacheControl というのが pip が使っている requests 用のキャッシュライブラリで、その最新版が msgpack を使っているようです。

前のバージョンはバイナリデータを base64 した上で json に入れて gzip していたのですが、もともと圧縮されてるバイナリを扱うときに gzipbase64 によって増えた分を減らす以上の効果は期待できない上、 PyPI からダウンロードするファイルってほぼ100%圧縮済みなので、キャッシュファイルの読み書きで無駄なオーバーヘッドがあったみたいですね。

バンドルされてる msgpack は pure Python で実行できる fallback モジュールのみなのでどこでも動くし、 Cython 版じゃないのも今回みたいにファイルが大きい以外はデータは多くなくて単に base64 + gzip の負荷を減らしたいときは完全に安全だし、まさに msgpack の典型的な成功例 (jsonバイナリ詰めたかったら msgpack!) のように見えます。

ということで、 pip 9.1 がリリースされたら msgpack のユーザーが爆発的に増えそうです。

このブログに乗せているコードは引用を除き CC0 1.0 で提供します。