コグノスケ

オープンソースプロジェクトの持続性

コンパイラ, エディタなど、かつて有料が当たり前だったのに、今やオープンソースが当たり前になっていて、有料だと逆に「なぜ有料なの？」と思ってしまいます。

良い時代になったよなあ、と思う一方で、オープンソースプロジェクトの持続性には疑問があります。

従来のようにソフトウェアを売る、という形での開発費回収が出来ませんから、最初は個人の情熱で維持できても、いつか開発費が捻出できなくなって破綻すると思うんです。

でも、あまり破綻したという話を聞かないのはなぜでしょう？実は零細プロジェクトから静かに破綻していってるけれど、影響力が小さいからニュースにならないだけなのか、それとも何か別の秘密があって、巧妙に回避できているのか…？

メモ: 技術系？の話は Facebook から転記しておくことにした。

systemd

独自ビルドのカーネルだと /sys/fs/cgroup が無いと言われて起動しないので、sysvinit に戻しました。ぶっちゃけ systemd だろうが sysvinit だろうが、どっちでもいいわ…。

しかし udev といい、systemd といい、便利は便利なんでしょうけど、Linux 固有の機能に依存しまくりで面倒です。ブート周りを司るソフトが OS 依存になるのは仕方ないのかなあ？

GRUB2 にやられた

サーバにインストールしていた Debian 32bit 版 の Jessie へのアップデートは一段落したので（systemd を諦めたりしてかなり適当ですが…）、ノート PC の仮想マシンにインストールしていた Debian 64bit 版を apt-get dist-upgrade しました。

無事アップデートできたように見えたので再起動したら、GRUB2 が起動しなくなりました。正確に言うと CUI 画面で止まるようになってしまいました。

grub> ls
(hd0) (hd0,msdos1) (hd0,msdos2) (hd1)

grub> set root=hd0,msdos1
grub> ls /boot
grub/ config-3.16.0-4-amd64 config-3.2.0-4-amd64 
vmlinuz-3.16.0-4-amd64 vmlinuz-3.2.0-4-amd64 initrd.img-3.2.0-4-amd64
System.map-3.16.0-4-amd64 initrd.img-3.16.0-4-amd64 System.map-3.2.0-4-amd64

grub> linux /boot/vmlinuz-3.16.0-4-amd64 root=/dev/sda1
grub> initrd /boot/initrd.img-3.16.0-4-amd64
grub> boot

この時点では上記のように手打ちで起動できたのですが、その後、間違えて grub-install を実行して GRUB1 をインストールしてしまい、なぜか root パーティションの ReiserFS を認識しなくなり、手打ちでも起動できなくなりました。ああー…。

復旧

ダメ元で Knoppix から grub-install してみると、なぜか ReiserFS が読めたので、そこからもう一度 Debian Jessie を起動し（GRUB1 CUI も GRUB2 CUI とほぼ同じ手順で起動できる）て、GRUB2 を入れなおしました。

# apt-get install grub-pc --reinstall
Reading package lists... Done
Building dependency tree
Reading state information... Done
0 upgraded, 0 newly installed, 1 reinstalled, 0 to remove and 0 not upgraded.
Need to get 0 B/220 kB of archives.
After this operation, 0 B of additional disk space will be used.
Preconfiguring packages ...
(Reading database ... 188824 files and directories currently installed.)
Preparing to unpack .../grub-pc_2.02~beta2-22_amd64.deb ...
Unpacking grub-pc (2.02~beta2-22) over (2.02~beta2-22) ...
Processing triggers for man-db (2.7.0.2-5) ...
Setting up grub-pc (2.02~beta2-22) ...
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

# dpkg-reconfigure grub-pc
    - Linux command line: はそのまま空欄で [ok]
    - Linux default command line: はそのまま "quiet" で [ok]
    - GRUB install devices: は [*] /dev/sda ... を選択して [ok]
Installing for i386-pc platform.
Installation finished. No error reported.
Generating grub configuration file ...
Found background image: /usr/share/images/desktop-base/desktop-grub.png
Found linux image: /boot/vmlinuz-3.16.0-4-amd64
Found initrd image: /boot/initrd.img-3.16.0-4-amd64
Found linux image: /boot/vmlinuz-3.2.0-4-amd64
Found initrd image: /boot/initrd.img-3.2.0-4-amd64
done

その後、再起動して、正常に起動することを確認しておしまいです。

GPS は世界一正確な時計 その2

前回（2015年 3月 9日の日記参照）は GPS モジュールを PC と接続して、情報を取得するところまで試しました。

今回は GPS モジュールからの時刻情報を使って NTP サーバの時刻を合わせたいと思います。

NTP サーバの設定方法

設定はとても簡単で、下記を ntp.conf に書き加えて ntpd を再起動させるだけです。当然ですが gpsd も起動している必要があります。

server 127.127.28.0
fudge 127.127.28.0 refid GPS

設定の 127.127 というのは、決まり文句（ネットワーク上のサーバではない、くらいの意味だと思う）で、その後の 28.0 に意味があります。この 28.0 は共有メモリを使って時刻を取得するドライバを使ってくださいね、という意味になります（NTP のドキュメント参照）。

なぜここで急に共有メモリが出てくるのか？というと、実は gpsd と ntp は共有メモリを介して通信しているからです。

# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

# /etc/init.d/gpsd start
Starting gpsd (via systemctl): gpsd.service.

# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4e545030 3375104    root       600        96         1
0x4e545031 3407873    root       600        96         1
0x4e545032 3440642    root       666        96         1
0x4e545033 3473411    root       666        96         1
0x47505344 3506180    root       666        31616      1

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

# /etc/init.d/ntp start
Starting ntp (via systemctl): ntp.service.

# ipcs

------ Message Queues --------
key        msqid      owner      perms      used-bytes   messages

------ Shared Memory Segments --------
key        shmid      owner      perms      bytes      nattch     status
0x4e545030 3375104    root       600        96         2                 ★★ 1 → 2 に増えた ★★
0x4e545031 3407873    root       600        96         1
0x4e545032 3440642    root       666        96         1
0x4e545033 3473411    root       666        96         1
0x47505344 3506180    root       666        31616      1

------ Semaphore Arrays --------
key        semid      owner      perms      nsems

上記の実行結果を見ると gpsd を起動する前と、起動した後で、共有メモリの領域数が増えていることと、ntp を起動した後で、共有メモリへのアタッチ数（nattch）が 1 から 2 になっていることがわかると思います。

動作確認

実際 NTP サーバが GPS から時刻を取得できているか、確認するときは ntpq コマンドを使います。

     remote           refid      st t when poll reach   delay   offset  jitter
==============================================================================
 127.127.28.0    .GPS.            0 l    -   64    0    0.000    0.000   0.000
*127.127.1.0     .LOCL.          10 l   17   64    3    0.000    0.000   0.002

本来、127.127.28.0 の方に * が付く（* は時刻合わせに使っているという意味）はずなのですが、調子が悪くて GPS で時刻を合わせている状態になりませんでした。

調べてみると、どうも GPS レシーバが壊れたようで xgps で見ても全く衛星を捕捉していません。6000円くらいしたのに…なんてこった…。

お勧めしないデバイス？

さらに gpsd の動作確認済みハードウェアリスト（ハードウェアリストへのリンク）の中に、私が買った Globalsat BU-353-S4 も載っており「感度悪いし、衛星の捕捉も遅いし、絶対買わない方が良いぜ（※）」と紹介されていました。

言われてみれば、かなり開けた窓際、しかも数センチ近くまで持っていかないと衛星捕捉せず、設置場所探しに大変苦労していたのですが、まさかここまでボロクソに書かれるほどのハズレ製品だったとは…。

壊れたのと合わさって、二重のショックです。せっかく買ったのに…ううーん。

（※）引用すると、Has poor sensitivity and takes a lot longer to cold-start than the vendor claim 45 of 45 seconds. Gary Miller rates this device "DO NOT EVER BUY ONE!" だそうです。

今さら気づいたバグ

ずっと気づいていなかった自作 ARM エミュレータ ememuのバグを直しました。

エミュレータは、内部に簡易ブートローダを持っているのですが、この簡易ブートローダが変なパラメータを Linux カーネルに渡していたため、Linux のブート時に「Ignoring unrecognised tag 0x00000000」と怒られていました。

[    0.000000] Booting Linux on physical CPU 0x0
[    0.000000] Linux version 3.18.11 (katsuhiro@falcon) (gcc version 4.9.1 20140710 (prerelease) (crosstool-NG linaro-1.13.1-4.9-2014.07 - Linaro GCC 4.9-2014.07) ) #1 Fri Apr 17 03:18:38 JST 2015
[    0.000000] CPU: ARM926EJ-S [41069260] revision 0 (ARMv5TEJ), cr=00003137
[    0.000000] CPU: VIVT data cache, VIVT instruction cache
[    0.000000] Machine: ARM-Versatile PB
[    0.000000] Ignoring unrecognised tag 0x00000000 ★★★これ★★★
[    0.000000] Memory policy: Data cache writeback
[    0.000000] On node 0 totalpages: 16384

古き時代から ARM Linux では ATAG という仕組み（ATAG の仕様はここにあります）でカーネルのロード位置、InitramFS のイメージの位置、カーネルのコマンドラインなどをブートローダからカーネルに渡しています。

このうち、もうパラメータはない、すなわちパラメータの配列の終端を示すための ATAG_NONE の渡し方が間違っていました。わざわざ仕様書にも 0x2 を渡すなよ、0x0 だぞ（※）と強調して書かれているのに、サイズに 0x2 を渡していました。マヌケです…。

このバグに気づいたとき、パラメータの終端が無い状態でも動くのか、さすが Linux などとアホなことを思っていたのですが、実は RAM の初期値が 0 だったため、パラメータの配列の終端を突き抜けた後に、0x00 が 4連続する部分（ATAG_NONE と同じ意味で解釈される）で解析が終了していただけでした。

つまり、今まで動いていたのは偶然！ってことですね。

このバグは現状では問題を引き起こしませんが、今後 RAM を初期化しないが、ブートローダは通る、と言う処理を実装すると問題が起きます。例えば、リセット例外によるソフトリセット処理が当てはまりそうです。恐らく RAM の内容に応じてランダムにクラッシュする厄介なバグとして表面化するでしょう。

（※）引用すると This tag is used to indicate the list end. It is unique in that its size field in the header should be set to 0 (not 2). とのこと。

どういう状況なの？これ

Redmine チューニングの実際と限界を読んで。

プロジェクト分割すれば良いだけなのに…、200万チケットを 1つの Redmine に入れる必要があるって、恐ろしいです…。

メモ: 技術系の話は Facebook から転記しておくことにした。

ピリオドとユーザ名の不思議

Debian のセットアップでユーザ名にピリオドを使ったら「不正なユーザ名」と言われるので、何故？と思って調べたら思いのほか歴史がありました。

元々 BSD では、chown のユーザ名とグループ名の区切りにピリオドを使っていたそうで、ユーザ名にピリオドを使うなど以ての外でした。

しかし POSIX がユーザ名にピリオドも使えるよ、と決めてしまったので、哀れ chown の区切りはピリオドからコロンになりました。

Debian のセットアップスクリプトは安全側、つまりユーザ名のピリオドに対応していない古いツールを考慮して BSD 時代のルールを守っているのだろう、と思われます。

実は誰も直さずに放置されているだけかも知れませんけど…真相はわかりません。

メモ: 技術系の話は Facebook から転記しておくことにした。

GPS 故障？

先日（2015年 5月 8日の日記参照）の日記で壊れているのかと思っていた Globalsat BU-353-S4 ですが、実は壊れていませんでした。

GPS 受信機が受信状態を伝える通信方式には、NMEA 0183 という規格に基づいたテキストデータで送ってくるか、GPS の受信機メーカー独自のバイナリデータで送ってくるか、の 2つがあるようです。

恐らく大抵のメーカーは両方に対応しており、NMEA か、メーカー独自バイナリかが選択できます。もちろん Globalsat BU-353-S4 が採用している SiRF Star IV もどちらかを選ぶことができます。

どうも色々いじっているうちにバイナリモードになってしまっていたらしく、NMEA を期待していた GPS のデータ表示アプリなどが「何言ってるのかわからんわ、このデバイス」状態に陥っていました。故障じゃなくて良かったです。

stty -F /dev/ttyUSB0 ispeed 4800 && cat < /dev/ttyUSB0
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPGSV,3,1,12,01,00,000,,02,00,000,,03,00,000,,04,00,000,*7C
$GPGSV,3,2,12,05,00,000,,06,00,000,,07,00,000,,08,00,000,*77
$GPGSV,3,3,12,09,00,000,,10,00,000,,11,00,000,,12,00,000,*71
$GPRMC,,V,,,,,,,,,,N*53
...

もし上記のようにテキストデータが受信されれば NMEA モードになっています。もしグチャグチャの字が受信されるときは、ボーレートが間違っているか、バイナリモードになっている可能性が高いです。

モードの切り替え方

GPS データの通信方式を切り替えるには gpsctl というコマンドを使います。GPS デバイスが /dev/ttyUSB0 として認識されているとして、

# to NMEA
gpsctl -f -n /dev/ttyUSB0

# to Binary
gpsctl -f -b /dev/ttyUSB0

オプション -n は NMEA モードにする、-b はバイナリモードにするという意味で、-f はローレベル（gpsd を介さないという意味らしい）で GPS デバイスにアクセスするという意味です。

ちなみに SiRF Star IV はモード切り替えに数秒〜10秒近くの時間がかかることがあります。さすが「絶対買わない方が良いぜ」と言われるだけのことはある…。

無理やり変えてみる

これで終わりだとあまり面白くなかったので、Globalsat BU-353-S4 の通信方式を gpsctl -n 以外で切り替える方法も試してみます。

ありがたいことに Globalsat US のサイトから SiRF バイナリデータの仕様書を入手できますので、NMEA モードへの切り替えコマンドを送ってみようと思います。仕様書のダウンロードはこちらのサイトの「SiRF Binary Protocol Document」からできます。

ちなみに仕様書の「Switch To NMEA Protocol – Message ID 129」にそのまま使える例が載っていますので、これをそのまま送ってみます。

• A0A20018 - Start Sequence and Payload Length
• 810201010001010105010101000100010001000100012580 - Payload
• 013AB0B3 - Message Checksum and End Sequence

このデータをバイナリエディタなどでファイル（to_nmea というファイル名だとします）に書いておき、

# gpsctl -f -b /dev/ttyUSB0
/dev/ttyUSB0 identified as a SiRF 9GSD4e_4.1.2-B2_RPATCH.02-F-GPS-4R-1301151 01/17/2013 017 at 9600 baud.
gpsctl:SHOUT: switching to mode BINARY.
falcon:~# stty -F /dev/ttyUSB0 ispeed 9600 && cat < /dev/ttyUSB0 | hexdump -C
00000000  a0 a2 00 29 02 00 00 00  00 00 00 00 00 00 00 00  |...)............|
00000010  00 00 00 00 00 00 00 00  00 00 03 36 02 6a 9c 5a  |...........6.j.Z|
00000020  00 00 00 00 00 00 00 00  00 00 00 00 00 01 9d b0  |................|
00000030  b3 a0 a2 00 09 09 00 00  00 00 00 00 00 00 00 09  |................|
...

# cat to_nmea > /dev/ttyUSB0

# stty -F /dev/ttyUSB0 ispeed 9600 && cat < /dev/ttyUSB0
$GPGGA,163721.731,,,,,0,00,,,M,0.0,M,,0000*53
$GPGSA,A,1,,,,,,,,,,,,,,,*1E
$GPRMC,163721.731,V,,,,,,,280515,,,N*43
...

以上のようにバイナリを GPS デバイスに送りつけると、無事 NMEA モードに切り替わります。ちなみに上記の設定例だとボーレートが 4800bps から 9600bps に変わってしまうので注意してください。