2018/10/05(金)天寿を全う(?)しました。

このボードを外気温・室内温度計測装置に使っていたのですが、ついに・・・逝ってしまった模様。
異変に気付いたのは、昨日の午後。。orz
計測装置の稼働状態を遡ると、どうやら、9/18 頃から調子が悪くなっていった模様。。
20181005.png


2003(平成15)年12月上旬から、ほぼ休みなく連続稼働させている状態での使用で、14年11ヶ月ほど使用できたことになります。
交換部材はもう生産されていない代物なので、これが壊れたら次は無いため、次世代モノに対応すべく一部の改造などやらないといけません。
再利用できそうなのは、2つのICですかね。ただ、ICそのものを再試験とかやらないと何とも言えません。

他にも部品取りで使えるモノはあるのですが、一社会人として忙しくさせて頂いているので、昔なら意気込んだものの、今はそういう気にもなれないですね。。

2018/09/08(土)北海道胆振東部地震―被災しました。。

2018/09/08 2:15 未分類
管理人が住む地域は「震度5強」でした。隣の地域は「震度6弱」。
地震直後に停電、9/7 21:00 に復旧。ラジオ放送が唯一の情報源になっていました。

電源復旧したら管轄設備の復旧作業をすぐやらなければならない責務があるため、まともには寝れませんでした。。
下記左側が地震直後の作業場所、右側は復旧直後、液晶ディスプレイに電源入れた際の状態。。
20180908_1.png
 
20180908_2.png


赤枠の部分は逝ってしまっています。。グラフ描いているのではないんです。
買い替えないと業務にならんなぁ。。orz

2018/07/23(月)北海道内自治体 Webサイトの https:// 化状況

2018/07/23 22:08 インターネット
明日から明後日にかけて、話題(?) の Chrome68 がリリースされる予定です。
何が話題になっているかといえば、https:// で接続していない Web サイトには無条件で「安全な接続ではありません」というような警告が出るようになるから。

ところが、https:// 化していない自治体サイトは、現時点でも概ね半分程度あり、北海道庁の Web サイトも https:// 化していません。
リンク等を修正していたのですが、https:// 対応状況に地域差があるようなので、アホなマップを作ってみました。
それが以下の図。(緑色が https:// 対応済み自治体)
20180723.png


非対応が目立つ地域は、旭川市を中心とする上川地方、帯広市を中心とする十勝地方、あとは渡島半島の西部と北部。
準備中の自治体もあるかもしれませんが、外部からは判りません。

自治体は Web サイトの 非 https:// 状態が信用問題に直接結びつくことが無いので、
「住民に言われるまで対応しない」と安直に考えているとしたら、ちょっと問題ですね。
とはいえ、今日のこの時点で https:// 化しているならば、ICTスキル的には合格でしょう。


「ICTに明るい人材がいないか、役所内での執行力が弱い」という状態だったら、7月25日以降、Web サイト運営上の問題を引き起こす事になるでしょう。業者の責任ではなく、運営者の責任問題です。

1週間後に同じマップを作ってみて、どう変化するかを記録します。

〔2018/09/12 追記〕
殆ど変化が無かったので、1週間後のマップ作成は見送ったのですが、
今日(2018/09/12)現在でも、新たに確認できたのは、厚沢部町と西興部村の2つのみ。
ICTスキルの二極化が進んでいるのかもしれませんね。
業者は動機付けしかできません。この件で業者に責任を負わせることの無いように!!

2018/07/22(日)法要の準備・実施などで1週間何も出来ませんでした。

2018/07/22 14:44 未分類
行かなければならない日が三連休の最終日を重なり、こちらから見ると国民的大移動と同じ方向なため、
飛行機も新幹線も軒並み予約満席だったが、「順延」なんぞ悠長なことは許されず、辛うじて空席のあった早朝の新幹線で何とか移動出来た状態でした。

当然、札幌まで新幹線は*まだ*来て居ませんので、新函館北斗駅まで自力で移動し、東京から先は、国民的大移動と反対方向なので移動で困ることはありませんでした。
行きの道程で新函館北斗駅の立体駐車場に自分の車を置いていくことになったので、帰りも新幹線で帰ってくることに相成りました。

行きは全く余裕なかったが、帰りは前日にやっとのことでちょっと余裕ができたのと迷惑かけたので贖罪ヽ(^^; するための土産モノ選定で、観光客モードになっていました(笑)

20180722_1.JPG

知っている人はよく知っているのですが、この駅(中央本線・上諏訪駅)には1番ホームにこのような施設があり、列車に乗る用事が無くても入場券(170円?)で駅ホームに入ればこの足湯に浸かることができると思います。

2018/06/25(月)Raspberry PI Model B+ で FreeBSD11.1R を 11.1R-p10 にする

何年か前に某所から2つ預かっていて、「返せ」と来ないので事実上は当方の所持品と化しているのだが・・・
20180625.jpg


今は、Raspberry PI も 3 までバージョンアップしているものの、Raspberry PI 3 対応の FreeBSD はまだプロダクトクオリティでないとかで、手元の旧版 Raspberry PI Model B+ でサーバ構築を試みているのだが・・・

OSソースコードツリー取得に3時間余り、make buildworld を3日前から始めているものの、まだ終わりません。
4日目で llvm 絡みのコンパイルが終わり、やっと次の段階に進んだところ。
CPUの能力も低いですが、SDカードへのアクセスの遅さが主たる原因でしょうか。

今時のデスクトップ・サーバ機器ものならば、4~5時間もあれば終わってしまうのです。
これでは、この方法でメンテナンス出来ないっすね。。 

エンタープライズな方々が好みのバイナリアップデートならば即できるかもしれないが、カスタムカーネル構築は実質出来ず、その他もカスタマイズもろもろが面倒(バイナリアップデートで上書きで元に戻るし、そういうのが管理面倒)なので出来れば使いたくない。

インクリメンタル・コンパイル(更新)みたいなメンテナンスが出来れば、こちらの運用環境としてはベストなんですけどね。
そういうの必要とするユーザは殆どいないのでしょうかね。。それとも既に知られているやり方があるのでしょうか。。

〔2018/06/26 追記〕
その後、皆、クロスコンパイルで構築していることに気づき、手元の実験環境サーバで実施したら、6時間ほどで完了しました。
4日間を返せ、、、orz...

2018/06/13(水)現行 UNIX/Linux 系OSの IPv6 プロトコルスタックは日本人が主導して開発された

エンジニア歴がそこそこ長い人(概ね15年以上な方々)には、頭の片隅で知られている話ですが、
IPv6 が国際社会で本格的普及を見せている現状で IPv6 を最近知った方々には全く知らない話ですね。

Linux 系には 1997年には既に IPv6 の実装がありました。
ただ、「マトモに動作せず、メンテナンスも行き届かない」という始末だったそうです。

そのような中、先見性があったかどうかは不明なのですが、日本で BSD系Unix に IPv6 プロトコルスタック(IPv6通信を処理する中枢部)を組みこむというプロジェクトが始まりました。もう20年前の1998(平成10)年4月のこと。
#あぁ、当ブログ管理人が脱サラする直前だ。。あの頃は本当に毎日が嫌だった・・・(爆)

そのプロジェクト名は KAME と命名されました。WIDEプロジェクト傘下のプロジェクトです。
WIDEプロジェクトは、複数の民間企業がスポンサーになっている先端技術開発を行う日本国内の団体です。

最初に FreeBSD に実装され、その後で他のBSD系Unix (NetBSD,OpenBSD等) に移植されました。
当時の Linux 系のIPv6 プロトコルスタックや 1995年頃から世界各国で始まっていた IPv6 の開発中間成果物を参考に流用出来る部分は流用しつつ、根本部分から作り直したのだろうと推察されます。

これは大部分が日本人の手で行われたのです。
自慢の必要はありませんが、どこかの国のように「世界初」と嘘・ハッタリをかます事をせず、貢献の事実として記憶しておきたいですね。

ロゴはこれ ↓
kame.gif
 (KAME Project

IPv6環境で接続すると、こんな感じでカメが動くのだそうです。
プロジェクト名の由来は、ここで説明書くよりも、google 先生あたりに「WIDE KAME 由来」というキーワードで検索し、そこで上位に出てきたサイトの説明を見る方が面白いと思うので、是非そうしてみて下さい。

そのような動きが日本にて Unix系で始まったものですから、Linux 系は、KAME プロジェクトの成果をインポートする(反映させる)プロジェクトとして、USAGI と名付けられたプロジェクトが、同じく WIDE プロジェクトの傘下で始まりました。
2000(平成12)年10月のことです。
#Unix も Linux も同じようなものと思う方々は日本では実に多いのですが、厳格に「似て非なるもの」と思って頂きたいです。


↓ バナーはこれ  (トップページ右下隅に表示されます)
usabanner1.png
 (USAGI Project

このような経緯ですので、イソップ物語同様、USAGI は決して KAME に追いつけないわけです。
KAME Project は、2005年11月の完了宣言を以って、2006年3月に活動が終了しています。
一方で、USAGI Project は、明確な完了宣言などは無いですが、2008年12月に表向きは終了しているようです。

2018/05/15(火)VP9コーデック、WebMコンテナ形式で動画をエンコードする

2018/05/15 25:48 未分類
テスト確認も兼ねて、久々の自分メモ投稿。
何回か紹介しましたが、一昨年の秋から、車載動画 をYoutube にアップしております。但し、一般受けを狙ったものではありません。
5年先くらいから、記録動画としての価値がだんだん出てくると思っています。

動画アップに先立って、動画そのものを制作するわけですが、最後の段階として「エンコード」という作業があります。
筆者の場合、通常、ffmpeg というソフトウェアを使用します。
今回は Youtube で事実上の標準形式となっている VP9 WebM と呼ばれる形式です。
大抵の HTML5 対応Webブラウザではこの形式に対応しているので、試してみる価値はあると勝手に思ってやってみた次第です。

さて、本題ですが、ffmpeg のデフォルト値ではとんでもないエンコードになってしまった、という話です。
元ネタ動画は、拡張子 .avi のファイルですが、このように『エンコードすると、元ネタファイルよりも数倍でかくなってしまう』という状態になるのです:
20180516_2.png


最初は「こんなものか」と思ってはいたが、「10倍近くなるのはさすがに何か設定おかしい・・・」「エンコードにえらく時間かかる・・・」ということで、エンコードパラメータをいじってみます。

結果的には、下記のようにすることで何とかなるかな、というところです。
-c\:a libvorbis -aq 3
-c\:v libvpx-vp9 -crf 28 -b\:v 3000k -minrate 2200k -maxrate 3500k -cpu-used 1 -threads 8
制作しようとしている動画のサイズは、 1280x720p 24fps でこの場合の推奨ビットレートは、1024kbps で間に合うことになっていますが、実際に 1024kbps だと、画質が荒くなってしまって、3000k で目立たなくなるかな、といった感じ。
-crf は画質レベルの指定(値が小さいほど高画質)ですが、推奨値 32 のところを 28 にしています。

これで、こんな感じになりました:
20180516_4.png


エンコードに要する時間もまぁ我慢できるレベルになりました。
20180516_3.png


パラメータ -cpu-used を 0 にすると、エンコード自体にとんでもなく時間かかります。。。

では、何故ファイルサイズがでかくなってしまうのか。これはエンコードビットレートが関係しています:
20180516_1.png
 
20180516_5.png


左が ffmpeg のデフォルト。右はパラメータを上記に設定したときのもの。
ファイルが違っていますが、エンコードの傾向はこんな感じになります。 25Mbps とか、トンデモな値です。
VP9 形式エンコードはCPU負荷もかかる上に、適切なパラメータ設定が必須のようです。

2018/04/13(金)【予告】重い腰を上げてヾ(^^; ... このブログシステムそのものを変更します・・・

2018/04/12 25:56 コラム
もう数年来、コメントスパムとトラックバックスパムが酷い状態が継続しており、
トラックバックスパムのほうは、殆どが外国からのアクセスで接続そのものを遮断することで対処出来ている(トラックバックそのものも利用されなくなっていることが主因か...)状態ではあるものの、
コメントスパムは相変わらずです。

今まで改善案などご指摘して頂いた方も居られるのですが、構造的に大改造を施さないと実現できそうにない状態なので、「コメントスパムが溜まったら削除する」という消極的対処しか出来ない状況でした。

ですが、今度の5月連休の前半あたりに時間がとれそうなので、その時にブログシステムを入れ替えることにしました。

システム的に入れ替えるのは簡単なのですが、記事データ・コメントデータの移行処理に時間がかかり、面倒なのです。具体的には移行先のブログシステムが扱えるデータ形式で移行データを作成するという作業が必要です。しかし、既に手動でやれる分量でもありません。

現在稼働中のブログシステムは一般的なものではないため、そのようなデータを吐き出すスプリプト(プログラム)を作る必要があります。

そのため、ただでさえ更新が滞っているブログですが、4月末まで更新を停止します。
再開時はブログデザインが変わっているのですぐわかるかと思います。

2018/04/22[Sun] 追記
ブログシステムの入れ替えは完了していますが、移行チェック作業中です。
新しい記事追記した時点で作業完了と見てください。