自分で撮った古い写真を4K画面でだらだら眺めてると面白くて、歴史を感じる。

HT-03A の写真が1枚だけあって、解像度低すぎてビビる。でも、今でも HT-03A サイズのスマフォが欲しいと思ってる。処理速度とかはともかく、なんだかんだいって一番好きな端末かもしれない。これ、画面に表示しているのは fotolife アプリだと思う。id:fixo さんの絵が好きなのでよく見ていた。

京都で雪が降ってクソ寒いときにカメラ持って自転車で写真撮ったりしていた。どう考えてもアホだけど、めちゃくちゃ楽しかった。でもアホだと思う。しかし風邪はひかなかった。

雪といえば春あたりに愛宕山を登ったときは雪が残っていてすべりまくった。頂上に神社があってとにかく最高なのだけど、結局1度しか登らなかった。

オフィスの出口だと思うけどなぜこんなところを写真に撮ったのか不明。

毎週のように自転車で植物園に行ってたけど良かった。いついっても面白い。

これは京都御苑内の神社で撮ったはず。京都御苑はやっぱ散歩スポットとしてクオリティが高すぎた。

きりがないけど、昔の写真を 4K で見るとたのしい。再現像してアップロードしなおすのも面白そうなので、たまにやりたい。空気感が再現されるのは面白い。

  1. トップ
  2. photo
  1. トップ
  2. redeveloped

Time Machine のスナップショット、つまり /Volume/Time Machine/Backups.backupdb/[Machine Name]/2016-05-05-002654/ みたいなやつを手動で削除したいとします。

これを Finder 経由で、ごみ箱に入れてごみ箱を空にするという手順でやると、時間がかかるうえに、途中で「ロックされている項目を削除してもいいか?」と一度確認まで入ります。さっさと削除してくれよという感じがします。

ということで、めんどいなので rm -rf するかと思いきや、これは削除するパーミッションがあっても、 operation not permitted となって失敗します。どうしてかというと Time Machine のスナップショットは専用のカーネル拡張で守られているからです。守られているにはそれなりの理由があるので rm -rf は素直に諦めましょう。

ということで、tmutil delete を使います。

$ cd /Volumes/Time Machine/Backups.backupdb/Alice
$  sudo tmutil delete 2016-05-05-002654/
Password:
Deleting: /Volumes/Time Machine/Backups.backupdb/Alice/2016-05-05-002654

こんな感じで使えます。スナップショット1つ消すのに結構な時間がかかりますが、特に確認は入らないので放置すれば終わります。

余談:なぜ rm -rf がダメか

Time Machine は差分バックアップのためハードリンクを活用します。これはディレクトリに対してもそうで、内容に変化のないディレクトリはハードリンクになります。 (ちなみにディレクトリのハードリンクは標準 ln では作れないので、brew install hardlink-osx で入る hln で試すことができます)

このとき、違うスナップショット間でも同じディレクトリエントリとなるわけなので、このディレクトリエントリ中のファイルエントリを削除 (unlink) してしまうと、このディレクトリにハードリンクしているスナップショット間でもファイルが消えてしまいます。なので rm -rf が禁止されています。

$ mkdir foo bar
$ touch foo/a.txt
$ ls
foo/ bar/
$ ls foo
a.txt
$ hln foo bar/foo
$ ls bar/foo
a.txt
$ rm -rf foo
$ ls
bar/
$ ls bar/foo
# a.txt が消える
  1. トップ
  2. tech
  3. Time Machine のスナップショットをコマンドラインで削除する

コネクタのペアの極性のことをジェンダーといい、それぞれオス(male)とメス(female)に呼びわけられる。変換コネクター(アダプター)はジェンダーチェンジャー(gendar changer)と言う。海外サイトで高周波コネクタを買いたいときはこれで検索するのが確実。

ただどうも結構よくどっちがどっちかわからなくなる。コンセントみたいに単に突起が出てるだけ/受ける側は穴が開いているだけなら簡単だけど、SMAコネクタにようにハウジング(ピンを保護したりするための囲い)がついているとややこしくなる。

しかも SMA コネクタの場合 RP-SMA というオス型ピン+メス型ハウジング/メス型ピン受け+オス型ハウジングというカオスな組み合わせがあるのって、どっちがオスでどっちがメスなのかわかりにくい。考えかたとしては内部にピンが立っているほうがオスであっているはずだけど自信がなくなる。

ユーザーが増えると嬉しいものだ!というのはわかるし、そうなんだろうけど、自分に正直に考えてみると、自分はそのことがそれほど嬉しくないようだ。

むしろ、ユーザーが増えるとミスしたときの影響範囲が広くなるので、どんどんコード書くことに対して嫌になっていく。プログラミングは「てこ」であって、小さな労力で大きなことをやることができるが、すなわち負の面では小さなバグで大きな影響を与える。当然、ほとんどの場合は良い方向に作用するし、そうするように作っているつもりだが、バグのないコードを書くことは不可能なので、コードを書けば書くほど、負の作用に怯えることとなる。

「自分のプロダクトがたくさん使われてるのってすごいと思わへん?」と聞かれると、理性の上ではそうですねと思うが、直感的にはまずは辛いという気持ちがでる。

根幹にあるのは、「たくさんの人に使われる」ことが自分の中の承認システムに組み込まれておらず、それを天秤にかけたとき、嬉しさの方に傾かないということだ。

たくさんの人に使われるからといって、技術的にすごいとはいえない、というのもあるかもしれない。ただこの考えかたは美化しすぎで、たくさんの人に使われてバグが見つかってバカにされるのが嫌なだけというのが正直なところだという気がする。

エンジニアの年収がナントカみたいな記事が胸糞悪いので、出てくるエンジニアが担当している全てのサーバが同時に落ちればいいのに。

結局、ああいう劣等感を煽るようなものに付随するなにもかもというのは気にするに値しないはずだけど、劣等感は自動的に反応するので、ここでは攻撃的になるという形で消費しておく

  • ストップザワールド!
  • コンカレントマークアンドスイープ!
  • ジェネレーショナルガベージコレクト!
  • レイジースウィープ!
  • コンパクション!

2016 Q2 には (すなわち6月中には) アップグレードするという話だったのですが、どうやら遅延しているようです。以下はフィリピン版の ZenTalk のスレです。

There has been some changes in the upgrade timeline [ source], they have changed the initial timeline to "from 2nd quarter of 2016" (April onwards). We apologize for any delays that may occur on the update rollout for the following ASUS ZenFone models:

  • PadFone S (PF500KL)
  • ZenFone 2 Laser 6-inch (ZE601KL)
  • ZenFone Selfie (ZD551KL)
  • ZenFone 2 5.5-inch (ZE550ML, ZE551ML)
  • ZenFone 2 Deluxe (ZE551ML)
  • ZenFone 2 Deluxe Special Edition (ZE551ML)
  • ZenFone Zoom (ZX551ML)


The Android M (6.0) upgrade has arrived for these ZenFone models:

  • ZenFone 2 Laser 5-inch (ZE500KL)
  • ZenFone 2 Laser 5.5-inch/5.5 S (ZE550KL)
  • ZenFone Max (ZC550KL)
http://www.asus.com/zentalk/thread-55985-1-1.html

どこが最新の情報なのかよくわかりませんが、このトピックは6/27に更新されていて Sticky にも設定されているので、たぶんこれは最新の情報なのでしょう。一部モデルについてはリリース済みですが、他のモデルは遅延するみたいです。ここで "they have changed..." と言ってますが、これを投稿しているのはフィリピンの担当者のようなので、たぶん they というのはアップグレード担当部門のことを言っていると思われます (違う?)


Global 版 ZenTalk だと特別新規のアナウンスはなくて、27/06/2016 . no Android M. というスレで約束は守られるのかとちょっと燃えてます。というのも、元々アップグレードプランのスレの文言は以下のようなものでした。

The following ASUS ZenFone models will receive the Android M (6.0) upgrade in Q2 of 2016

http://www.asus.com/zentalk/thread-68552-1-1.html

これが

The following ASUS ZenFone models will receive the Android M (6.0) upgrade starting from Q2 of 2016:

http://www.asus.com/zentalk/thread-68552-1-1.html

と変わっており (フォーラムのタイムスタンプを見ると 2016/6/28 04:59)、Q2 以降という内容に変わっています。フィリピン版のスレの冒頭はこの文言変更についての言及のようです。

遅延自体はともかく、アナウンスするのに元スレッド書き変えというのはいただけないと思います。普通に考えると新規にスレ立ててアナウンスすべきでしょう。フィリピン版は担当者の裁量?で一応まともなアナウンスが出てるので、Global 版もそのようにしてほしい感じがします。


ここ半月ぐらい毎日アップグレードの確認をしてきましたが、どうも無駄だったみたいなので残念です。いつになるんでしょうね。

  1. トップ
  2. tech
  3. ASUS ZenFone 2 の Android M (6.0) アップグレードは遅延

PC関係だとよく VRM (Voltage Regulator Module) フェーズ数という用語にでくわす。マザーボードやグラフィックボードのレビューを見ると「電源は6+1フェーズ」とかと書いてある。特に説明もないので意味不明である。

結論

先に結論を書くと、フェーズ数は多ければ多いほど良いというものではない。それに電源回路の良し悪しはフェーズ数で決まるわけではない。そういうものなので、こういう表記を見ても無視して良い。

マルチフェーズ同期整流

フェーズ数を理解するためには、マルチフェーズ同期整流について理解しないといけない。そもそもここでいう「電源回路」は定電圧 DC/DCコンバータのことで、外部供給の12VをCPUにあうように低電圧(そして大電流)に変換することを言っている。

同期整流はローサイド(負荷に対してマイナス側)もハイサイド(同じくプラス側)もFETでスイッチすることによって高効率に整流を行うことをいう。このとき、スイッチングによって出力にリプルが発生する。そこで、ハイサイドFET・ローサイドFETのスイッチのセットを複数に増やして、それぞれのスイッチを少しずつ位相(フェーズ)をずらして整流させることで、よりリプルが少なく安定した定電圧電源とすることができる。

つまり「VRM フェーズ数」の「フェーズ」とは「位相」のことになる。1フェーズにつき少なくともFET 2つと、スイッチングコントローラ回路が1つと必要になる。(ただしフェーズが増えてなくてもFETのペアの数をフェーズとしてカウントする間違った宗派もあるっぽい)

基本的にはフェーズ数が多いほうが高級とされている。部品点数が増えるので価格が高くなる。フェーズ数が多いことの利点としては

  • 電源供給が安定する
  • FET 1つあたりの電流を減らせる
    • 発熱が分散するので放熱しやすい
    • 部品の高さを抑えられる

欠点は

  • 部品点数が多いので
    • 価格が高くなる
    • 故障率が上がる
  • スイッチング損が増え、効率が下がる (特に低電流時)

回路まわりは、これが図ありでわかりやすい

6+1 とか 8+2 って表記は何なの?

マルチフェーズ同期整流についてわかっても、この表記は意味不明。

結論からいうと前の数字がCPU(GPU)コア用の電源のフェーズ数 (大電力) で、後と数字はCPU(GPU)のコア以外用のフェーズ数のようだが、この表記を誰が決めて使ってるのかさっぱりわからない。(ソースを探したけどわからなかった)

フェーズ数以外のVRMの要素

  • FETの数や性能
    • 具体的にはオン抵抗、並列にすれば減らせるが部品は増える
  • 同期整流コントローラの性能
    • 負荷追従性など
  • PWM 周波数
    • 高いほどコイルが小さくでき負荷追従性が上がるが、FETでのスイッチング損失が増えて効率が下がる。ノイズにも関係ある。
  • コイルの性能 (Q値)
    • コイルの直流抵抗値が低いほど低損失だが部品が大きくなる
    • コアの材質でも損失が出る
  • コンデンサの性能
    • ESR (等価直流抵抗) が低いほど負荷追従性が高く、リプルが減る

ちょっと考えただけでもいろいろ要素がありすぎるので、フェーズ数だけで何かを判断することはできない。

所感

最近のマザーボードは重要な機能はチップセットに殆ど統合されたしまったので、表面にほとんど部品が載ってない。そうすると見た目的にインパクトがあるのが電源回路だけになる。

マルチフェーズにするとFETとコイルが並んでかっこいいので、マルチフェーズがもてはやされるみたいなところがありそう。インターフェイス (M2 とか PCI-E とか) が進化しても、マザーボードの見た目的にはインパクトがないんで、電源を盛るみたいなことだと思う。

  1. トップ
  2. tech
  3. 電源 VRM フェーズ数ってなんなのか

もうダメだ。

それはともかく、ここ数週間のやる気のなさがひどい、まるっきり趣味のコードも書いていないし、仕事の進捗もおそろしいぐらいにない。たびたびこういうことがあってどうしようもない。どうすればいいんだ。

こうなってて、バージョン 1151 をインストールするから再起動しろとなっているけど、再起動しても何も起きず普通に起動してインストールされてない。

Windows クソいなと思うこと多々あるけど、組込みの自動アップデートがうまく動かないとか、やっぱクソだと思う。

もしかすると、この表示でもまだダウンロードが終わっていないとか? なんにせよさっぱり情報がなくて「詳細」をクリックしても「再起動が必要」としか書かれていないので、どうしようもない。これは「失敗」しているわけではなくて、そもそもインストールが行われている形跡がない。なんで Windows はいちいちこんな目にあわせられるのか…… つらすぎる。ログがどこに出てるのかもわからんし (ログとかあるの?)

ヘルプもクソ

それでさ、ググると更新プログラムのインストールに関する問題のトラブルシューティング というのがでてくる。で「その情報は新しい場所に移動しました」って書いてあるからクリックするじゃん? そうすると Access denied とか言われんの。なんなのか

時間を置いたら見れた。けど結局解決できそうな内容ではなかった。意味がない…

Windows Update はいつマトモになるのか

前のPCのWindows Update もちょいちょいおかしくて、失敗してインストールされなかったりしていたけど、Windows7からのアップグレードだったからおかしいのかと思っていた。

今回、クリーンインストール直後でもこのありさまなので、Windows Update って基本的にダメなんだなということを認識した。

しばらく放置してから「今すぐ再起動」をしたらインストールが走った。やっぱダウンロード中だったんだろうか。そうならそうと表示がおかしいんだけど、よくわからない……

man pmset して理解した内容を記録しておく。これが正確かは実際の挙動をちゃんと確認してないのでアレだけど、man 読んでないだろみたいなのよりはマシなはず…

Mac のスリープの種類

  • ディスプレイスリープ
  • スリープ
  • セーフスリープ
  • ディープスリープ

「ディスプレイスリープ」は画面の表示だけ消えている状態。ディスプレイのバックライトが消えて他のスリープと似た状態となるのでスリープの一種としたが、CPUはスリープしない。

「スリープ」はメモリへ電力供給したままCPUをスリープさせている状態。

「セーフスリープ」は「スリープ」と似ているが、来たるディープスリープに向けてメモリ内容を書き出した状態。この状態だと急に主電源消失してもディープスリープからの復帰と同じになるので、作業が失われないという意味でセーフ。復帰はメモリからなので早いが、書き出しがあるのでそこが遅い。

「ディープスリープ」はメモリ内容をファイルシステムに書き出して、コンピュータの全ての電源を切る。次回電源オン時は、ブートプロセスでこのファイルの所在を確認してロードする。コンピュータ全体として消費電力がゼロになる。

メモリ内容を書き出すかどうか、そのタイミングはいつかあたりがポイントになる。メモリ内容を書き出したり、読み戻したりするスリープは、メモリが増えるほど時間がかかることになる。(SSD の場合これによって寿命が縮まることを気にする人もいる)

pmset -g で見れる値との関係

pmset でパワーマネジメントまわりの変数を見ることができる。MacBook Pro で実行すると以下のようになった。

$ pmset -g
System-wide power settings:
 SleepDisabled          0
 DestroyFVKeyOnStandby          0
Active Profiles:
Battery Power           1
AC Power                -1*
Currently in use:
 standbydelay         10800
 standby              1
 womp                 1
 halfdim              1
 hibernatefile        /var/vm/sleepimage
 powernap             1
 gpuswitch            2
 networkoversleep     0
 disksleep            10
 sleep                0 (sleep prevented by iTunes, coreaudiod)
 autopoweroffdelay    14400
 hibernatemode        3
 autopoweroff         1
 ttyskeepawake        1
 displaysleep         10
 acwake               0
 lidwake              1 

「ディスプレイスリープ」はdisplaysleepの値(単位は分)経過後に起こる。

各スリープは sleep の値(単位は分)経過後に起こる。このとき

  • hibernatemode = 0 なら「スリープ」
  • hibernatemode = 3 なら即座に「セーフスリープ」
  • hibernatemode = 25 なら即座に「ディープスリープ」

となる。

ただし「スリープ」や「セーフスリープ」に入っていても、standby = 1 の場合、standbydelay の値(単位は秒)経過後にメモリメージが書き出され「ディープスリープ」に移行する。また autopoweroff = 1 な場合も autopoweroffdelay の値(単位は秒)経過後にメモリイメージが書き出され「ディープスリープ」に移行する。standby との違いがわかりにくいが、standby はバッテリー駆動時の話で、autopoweroff は AC 接続時の話になっている。ErP Lot6 (待機電力基準) 準拠のため、autopoweroff があとから機能として追加されたという感じになっている。

ハイバネーションイメージを作りたくない場合

スリープ入りが遅くてうざい場合

ラップトップだと必ずセーフスリープする関係で、閉じたり開いたりを繰替えした場合になかなか起きてこなくてイラ立つことがある。この場合は常時セーフスリープに入るのがうざいケースなので、hibernatemode だけ 0 にすれば良さそう。

sudo pmset -a hibernatemode 0 

standbydelay / autopoweroffdelay 経過後のスリープはこの意図だと特段無効にする意味はないと思う。

とにかく絶対書き出したくない場合

ハイバネーションイメージからの復帰がそもそも遅いから嫌という場合とか、SSD が痛むのが気になる場合はとにかく無効にするしかない。消費電力が増えるのと、万が一バッテリー切れになった場合は作業内容が失われるのがデメリット。

To disable hibernation images completely, ensure hibernatemode standby and autopoweroff are all set to 0.

と書いてあるので、その通りにする。

以下のようにすると、全ての状況(バッテリだろうがAC駆動だろうがUPS起動だろうが) イメージ書きだしが無効になる。

sudo pmset -a hibernatemode 0 standby 0 autopoweroff 0

ref.

  1. トップ
  2. tech
  3. OS X のスリープの傾向と対策

おれもマインドフルネスするぞ!

認証アプリなどと違って数字を覚えることなしに、ロック解除とダイアログの「はい」を押すだけでよくなるっぽい。

ロックがかかっている端末でも、前もってロックを解除した状態でログインしようとすると、改めてロックコードの確認を求められる。なので、一見「はい」を押すだけでかと思いきや、必ずロック解除を挟む。

確認コードの数字は時間制限があるので、微妙にストレスがかかって嫌な感じでしたが、これはよさそうです。

  1. トップ
  2. tech
  3. Google の新しい2段階認証「Google からのメッセージ」

スリープ復帰時にどうやってもモニタが付かず、モニタの電源を入れなおしたり、ケーブルを繋ぎなおしたりということをしてみた。しかし、どうしてもダメで、ハードリセットをかけた。

DELLのモニタは、バグっておかしくなることはちょいちょいあることだが、電源を入れなおしたりしてもダメだったのは初めてなので、出力側に以上がある?という検討をなんとなくつけた。が、まぁリセットすれば直るだろうという意図だった。

そうするとどうも、何度リセットしてもBIOSの起動画面すら出なくなった。モニタは一瞬起動して、即スタンバイになるような挙動をしていた。主電源を落としてしばらく待ったりしてもダメだった。別のモニタに繋いでもダメなので、モニタの異常ではないという切り分けをした。

そのため、マザーボードまわりの不具合を想定しはじめた。あんまりやりたくはなかったが CMOS クリアを行なった。が、これでもダメで、完全に手詰り感がでてきた。

マザーボード上に2ケタの7セグLEDで起動状況がわかるようになっているのだが、BIOS セットアップ用のキーを押しっぱにすると 99 (スーパーIOの初期化中)、そうではない場合 51 (メモリエラー) となっていた。ここらでマザーボードの故障を疑いはじめ、げんなりしてきた。

故障修理の手続きをやるまえに、まだできることはないかと考えた結果、さらにもう一台別のモニタで検証しようということになった。中華産の低解像度だがHDMI接続のモニタと、短いHDMIケーブルを接続してみたところ、起動シーケンスが表示された。つまりここでようやく、マザー側は問題ないことがわかった。

さすがにここまで検証していた2台のモニタがどちらも壊れているとは考えにくいので、ようやくケーブルを疑い、今まで使っていたケーブルを中華モニタに接続したところ、表示は出るが、コネクタを揺らすと接触不良っぽい挙動をすることがわかった。この中華液晶は自動スタンバイのような気のきいた機能がないため、挙動がわかりやすい。

その後、HDMIケーブルをちょっと動かしてみたりしてひとまずなおった。ただし別途HDMIケーブルを注文して、今のやつは捨てる予定。

トラブルシューティングに時間のかかった原因

最初モニタを疑った段階で、ケーブルの脱着があったため、このタイミングで微妙に接触が悪い状態になったようだ。コネクタは奥まで入っていたので、このとき接触不良まで考えられていなかった。

2台のモニタどちらでもダメだったのが、判断を難しくさせた。このときケーブルは同じものを使っており、コネクタもちゃんと挿せていることまでは確認していたが、そのうえでの接触不良まで疑えていなかった。抜き差しは何度もしてみているので、余計疑っていなかった。

マザーボードのステータスLEDは、正常時の挙動を把握しておらず、99 と 51 が出ることは正常であることを認識できていなかった。99 はBIOSセットアップ画面中にも出るようで、51 はなぜか正常起動でもそういう表示になる。

十分に長いHDMI ケーブルがなぜか手元にそれ1本しかなく、ケーブルを取り替えて検証するのがめんどうだったため、無意識に原因として考慮するのを後回ししてしまった。

対策

  • 接続ケーブルは常に複数本持つこと
  • 「ステータスLED」みたいなものは正常時の挙動を前もって把握すること

オフィスにいるとだんだん体調が悪くなる。15時ぐらいからだんだんひどくなってくる。熱があるかはわからないが(たぶんない)、全身倦怠感がひどい。

インターネットってやつが便利で、グーグルってところに「花かんむり」っていれると作りかたがでてくる。

  1. トップ
  2. photo
  3. 花かんむり