今日はSocionextの最終勤務日でした。9月末退職ですが、9月末までは年休を取っています(それでも年休は半分以上余った)。
今から9月末までの3週間で、ほとんど土地勘のない東京で家探しをして、引っ越しを終えなければなりません。かなりスリリングな日程です。
Panasonic半導体社とSocionextで過ごした12年間は、ほぼ最初から最後までテレビ開発の仕事だったように思います。私がそうだっただけで、会社には他の仕事もあります。
技術的には幅広く関われました。Androidも多少齧れた(アプリ開発ではなくフレームワーク側)し、メディア再生のミドルウェア開発、デコーダやサウンドドライバ開発、LinuxやOSS活動もできました。面白かったです。
半導体会社はソフト、ハード、ボード設計、何でもやってますから、技術的には面白いところだと思います。機構設計はさすがにやってないか?
企業風土はPanasonic、富士通の流れを汲んでいて、いわゆる「日本の大企業」だと思います。平社員でしたから、他の事業部や組織は知りませんが…。
何で辞めるの?と色んな人に聞かれましたが、別に嫌なことがあったわけじゃないし、特に理由はないです。強いて言えば10年も同じ分野に居たので、他分野にチャレンジしようとは思っていました。今回は偶然チャンスに恵まれただけです。
特に無いと答えると、またまた、そんな嘘を言わなくても良いんだよ!みたいなこと言われます。どうも、私は「常に会社に対して激烈な不満を持っていて」「最近何かがあって、ついにブチ切れて退職した」と思われていたようです。
いやいや、そんな爆弾みたいな奴が10年も会社に居ますか?有り得ないでしょ?ひどい言いがかりだなあ、もう……。
自宅からちょっとしたLinuxのパッチを投げようと思って、さくらのメールサーバーをSMTPサーバーに指定して、git send-emailでメールを送ろうとしたらハマりました。
さくらのメールサーバーはSTARTTLSを使ってSMTP認証をせよ(メールソフトの設定 - さくらのサポート情報)とのことなので、.gitconfigの設定をこんな感じにしました。
[sendemail]
smtpencryption = tls
smtpserver = xxxx.sakura.ne.jp
smtpuser = yyyy@xxxx.sakura.ne.jp
smtpserverport = 587
実行してみると、Diedなんとかかんとか〜が表示され、メールが送れません。なんで??
$ git --version git version 2.18.0 $ git send-email --to 'xxxx' 0001-xxxx.patch ...snip... Died at /usr/lib/git-core/git-send-email line 1523.
こういうトラブルのときは --smtp-debug=1を付ければ大体わかるはずです。
$ git send-email --to 'xxxx' --smtp-debug=1 0001-xxxx.patch ...snip... Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)>>> (decoded) Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)>>> Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)<<< 235 2.0.0 OK Authenticated Net::SMTP::_SSL=GLOB(0x55ddcc6c0640)>>> MAIL FROM:<xxxxxxxx> Died at /usr/lib/git-core/git-send-email line 1523.
なるほどなるほど?これはわかりませんね。どうなってるんだ、このサーバーは?
幸いなことに /usr/lib/git-core/git-send-emailはPerlのスクリプトですので、簡単にデバッグプリントを入れられます。
認証部分に当たりを付けて、小一時間、試行錯誤してみたところSMTP-AUTHにデフォルトでDIGEST-MD5が選択されると、失敗することがわかりました。じゃあ、強制的にSMTP-AUTHをPLAINにすればうまくいくよね?下記のように設定を変えてみました。
[sendemail]
smtpencryption = tls
smtpserver = xxxx.sakura.ne.jp
smtpuser = yyyy@xxxx.sakura.ne.jp
smtpserverport = 587
smtpauth = PLAIN # ★★この行を足した★★
無事メールが送れました。良かった良かった。
目次: ROCK64/ROCKPro64
ROCK64のカーネルを入れ替えていたら、動かないカーネルを書き込んでしまい、起動しなくなってしまいました。
Etcherを使えばSDカードを全て書き換え、起動可能な状態に戻すことができるものの、今までの作業や変更が全て消えてしまいます。
SDカード全書き換えはやりたくありません。なんとかカーネル「だけ」復旧できないでしょうか?
Etcherのイメージファイルからカーネルだけ取り出して、上書きすれば復活するはずです。
Etcherの設定を変えていなければ、ダウンロードしたイメージファイルは、ユーザディレクトリのAppData\Roaming\pine64-installer\downloadedImageにあると思います。私はDebian Mateを使っていたので、files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img.xzというイメージファイル名でした。これをLinuxマシンにコピーします。
$ unxz files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img.xz $ ls files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img # partx -v -a files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img partition: none, disk: files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img, lower: 0, upper: 0 Trying to use '/dev/loop0' for the loop device /dev/loop0: partition table type 'gpt' detected range recount: max partno=7, lower=0, upper=0 /dev/loop0: partition #1 added /dev/loop0: partition #2 added /dev/loop0: partition #3 added /dev/loop0: partition #4 added /dev/loop0: partition #5 added /dev/loop0: partition #6 added /dev/loop0: partition #7 added
圧縮されているのでunxzで展開し、partx -aにてディスクイメージ内の全パーティションをloopbackデバイスに登録(※)しています。
ここまでくればHDDと同じようにマウントできます。
# mount /dev/loop0p6 rock64_boot # ls -la rock64_boot/ total 41654 drwxr-xr-x 3 root root 16384 Jan 1 1970 . drwxr-xr-x 3 katsuhiro katsuhiro 4096 Sep 4 01:15 .. -rwxr-xr-x 1 root root 18606088 Dec 21 2017 Image -rwxr-xr-x 1 root root 18606088 Dec 21 2017 Image.bak -rwxr-xr-x 1 root root 42707 Dec 21 2017 dtb -rwxr-xr-x 1 root root 42707 Dec 21 2017 dtb.bak drwxr-xr-x 2 root root 2048 Oct 12 2017 extlinux -rwxr-xr-x 1 root root 2663325 Dec 21 2017 initrd.img -rwxr-xr-x 1 root root 2663386 Dec 21 2017 initrd.img.bak
ブート用のパーティションは6番目なので /dev/loop0p6をマウントしています。あとは欲しいファイルをコピーすればOK。
# umount /dev/loop0p6 # ls /dev/loop* /dev/loop-control /dev/loop0p3 /dev/loop0p7 /dev/loop4 /dev/loop0 /dev/loop0p4 /dev/loop1 /dev/loop5 /dev/loop0p1 /dev/loop0p5 /dev/loop2 /dev/loop6 /dev/loop0p2 /dev/loop0p6 /dev/loop3 /dev/loop7 # partx -v -d /dev/loop0 partition: none, disk: /dev/loop0, lower: 0, upper: 0 /dev/loop0: partition #1 removed /dev/loop0: partition #2 removed /dev/loop0: partition #3 removed /dev/loop0: partition #4 removed /dev/loop0: partition #5 removed /dev/loop0: partition #6 removed /dev/loop0: partition #7 removed # ls /dev/loop* /dev/loop-control /dev/loop1 /dev/loop3 /dev/loop5 /dev/loop7 /dev/loop0 /dev/loop2 /dev/loop4 /dev/loop6 # losetup -l NAME SIZELIMIT OFFSET AUTOCLEAR RO BACK-FILE DIO LOG-SEC /dev/loop0 0 0 0 0 /home/katsuhiro/share/rock64/files.pine64.org_stretch-mate-rock64-0.5.15-136-20171222-arm64.img 0 512 # losetup -d /dev/loop0 # losetup -l
マウント時と同様にpartx -dでパーティションの登録を解除できます。しかしなぜか /dev/loop0の登録だけが残ります。気にせずlosetup -dで登録を解除すれば特に問題ないようですが、何かやり方が間違っているのかな?うーん…??
(※)losetupと /dev/loop0のみでも、オフセットを指定するとか何とかして、頑張ればループバックマウントはできると思いますが、ディスクイメージにパーティションが複数含まれている場合はpartxを使った方が楽だと思います。
以前、高槻市でのWAKWAKの遅さに嫌気がさして、DTIに乗り換え(2017年6月6日の日記参照)ました。
DTIは時々、名前を逆引きできないIPアドレスを割り当ててくるようです。害はありませんが、WAKWAKのときは無かったことだったので、少し気になって調べてみました。
DTIから割り当てられたIPをwhoisで調べてみると、AT&Tが持っている144.156.0.0/16のアドレスでした。なぜかホスト名を逆引きできません。何でしょうね、このアドレス…?
毎回このアドレス帯なのか確かめるため、VDSL終端装置を再起動したところ、フリービット株式会社が持っている153.151.x.xというアドレスに変わりました。こちらはホスト名を逆引きできます。
何か事情があって2種類(もっとあるかもしれないけど)を使い分けているのでしょうか?不思議な動きです。
宇宙戦艦物語RPGというスマホのゲームをやっています。
攻略Wiki(サイトへのリンク)にダメージ計算式が載っていたので計算してみたのですが、微妙にゲーム中のダメージ値と一致しません。Wikiによると攻撃司令の加算値の計算は、
とあります。その通りに足すと攻撃司令Lv 9999ならば、ダメージ補正値が504900になるはずです。
しかし適当な武器(702式発掘超合剣Lv 1313、攻撃力1100 + 28885)と、計算で求めたダメージ補正値を足しても、ゲーム側で出てくるダメージと一致しません。計算ではダメージは534885になるはずなのに、実際のダメージは534985です。100ほどズレてしまいます。
計算式を色々変えていてLvが100で割り切れるときの加算を変な値にすると、計算結果とゲーム側のダメージが一致することに気づきました。例えばLv 99 → 100のとき、加算は +1ないし +2が素直ですが、あえて +1と +2を両方加算した +3にします。
変な計算式ですが、あえてこの変な計算式で求めると、攻撃司令Lv 9999の場合、ダメージ補正値が100増えて505000になり、計算結果とゲーム側のダメージとも一致しました。変なの。ゲーム側の計算がバグってるように思えて仕方がない。
この加算値の計算はループでやればすぐできますが、Excelで計算を始めてしまったので、Excelで頑張ってみました。意外と面倒です。やり方はいろいろあると思いますが、私の場合は、
MAX(MIN(H2- 0,100),0)* 1+
MAX(MIN(H2- 99,100),0)* 2+
MAX(MIN(H2- 199,100),0)* 3+
MAX(MIN(H2- 299,100),0)* 4+
...
こんな風に99行書いて求めました。セルが編集できないくらい重いです。
100で割り切れるところがバグっているのか、別の法則が発動しているのか、正確なところは確かめていないのでわかりません。
きちんと確かめるなら、攻撃司令のLvを下げていってLv 9900を跨げばわかります。幸いにもこのゲームは、敵に防御力の概念が無い(?)ようで、誰に攻撃をぶつけても攻撃力=ダメージとなります。検証は簡単な部類だと思います。私はそこまでやっていませんけども……。
宇宙戦艦物語RPGはどのように進めていても、いつかは必ず同じ面をグルグル何度も周回するゲームになります。それ自体は構わないのですが、ゲームバランスがマゾすぎます。
一番辛いのは「敵を〇〇体倒せ」系のLv上げで、多いステージでも1回に1500体しか敵が出ないのに、1つの艦種Lvカンストに9999 * 300体(= 300万体)倒さなきゃいけないことです。さらに良くないことに、艦種は23種類もあります。
私にはこのゲームを極めるのは無理そうです。
< | 2018 | > | ||||
<< | < | 09 | > | >> | ||
日 | 月 | 火 | 水 | 木 | 金 | 土 |
- | - | - | - | - | - | 1 |
2 | 3 | 4 | 5 | 6 | 7 | 8 |
9 | 10 | 11 | 12 | 13 | 14 | 15 |
16 | 17 | 18 | 19 | 20 | 21 | 22 |
23 | 24 | 25 | 26 | 27 | 28 | 29 |
30 | - | - | - | - | - | - |
合計:
本日: