コンパイラ, エディタなど、かつて有料が当たり前だったのに、今やオープンソースが当たり前になっていて、有料だと逆に「なぜ有料なの?」と思ってしまいます。
良い時代になったよなあ、と思う一方で、オープンソースプロジェクトの持続性には疑問があります。
従来のようにソフトウェアを売る、という形での開発費回収が出来ませんから、最初は個人の情熱で維持できても、いつか開発費が捻出できなくなって破綻すると思うんです。
でも、あまり破綻したという話を聞かないのはなぜでしょう?実は零細プロジェクトから静かに破綻していってるけれど、影響力が小さいからニュースにならないだけなのか、それとも何か別の秘密があって、巧妙に回避できているのか…?
メモ: 技術系?の話は Facebook から転記しておくことにした。
独自ビルドのカーネルだと /sys/fs/cgroup が無いと言われて起動しないので、sysvinit に戻しました。ぶっちゃけ systemd だろうが sysvinit だろうが、どっちでもいいわ…。
しかし udev といい、systemd といい、便利は便利なんでしょうけど、Linux 固有の機能に依存しまくりで面倒です。ブート周りを司るソフトが OS 依存になるのは仕方ないのかなあ?
サーバにインストールしていた 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
その後、再起動して、正常に起動することを確認しておしまいです。
前回(2015年 3月 9日の日記参照)は GPS モジュールを PC と接続して、情報を取得するところまで試しました。
今回は GPS モジュールからの時刻情報を使って 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 から転記しておくことにした。
先日(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」にそのまま使える例が載っていますので、これをそのまま送ってみます。
このデータをバイナリエディタなどでファイル(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 に変わってしまうので注意してください。
管理者: Katsuhiro Suzuki(katsuhiro( a t )katsuster.net)
This is Simple Diary 1.0
Copyright(C) Katsuhiro Suzuki 2006-2021.
Powered by PHP 5.2.17.
using GD bundled (2.0.34 compatible)(png support.)