今日は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 # ★★この行を足した★★
無事メールが送れました。良かった良かった。
この記事にコメントする
目次: ARM
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 | - | - | - | - | - | - |
25年10月15日
25年10月18日
22年5月5日
25年10月19日
23年4月11日
06年4月22日
25年10月17日
25年10月6日
25年10月13日
20年10月23日
25年10月12日
20年8月29日
19年1月13日
18年10月13日
18年9月3日
18年8月20日
18年7月23日
18年7月22日
18年10月14日
18年11月10日
wiki
Linux JM
Java API
2002年
2003年
2004年
2005年
2006年
2007年
2008年
2009年
2010年
2011年
2012年
2013年
2014年
2015年
2016年
2017年
2018年
2019年
2020年
2021年
2022年
2023年
2024年
2025年
過去日記について
アクセス統計
サーバ一覧
サイトの情報合計:
本日: