2018年10月6日土曜日

Howto eject usb media like "Safely Remove Drive" from CLI

gio mount --eject /media/nekomatu/$(drive-name)

I use Ubuntu 18.04(Bionic).
Ubuntu is doing mount automatically when USB removal media is connected PC.It's convinient. and un-mount is easy. only one-click eject button from filer. so I want to eject like filer from CLI.



2018年10月4日木曜日

OSSの長期利用とメンテナンス に参加した

本ブログは個人のものであり、所属する団体の意見等では一切ございません。
というか、参加自体も仕事じゃなくて個人ですし。私はプラント系の人ではないので推測が多分に含まれています。
間違っていたりしたらこっそり教えてください。いつもにまして脳内ダンプ・ポエム感。

OSSの長期利用とメンテナンス







最初のきっかけは、とある人のCIPに対するツイートを見てうーん、CIPの人がそんな事を考えていないはずがないけどどうなってるんだろー?と気になったからでした。それだったら会場提供するよ的な話になって20人近く参加するイベントになっていました。
ガチ勢の方が多くびっくりしました。

CIPというのはLinuxFoundation配下のプロジェクトで、 Civil Infrastructure Platformのことです。社会インフラ向けのLinux・OSSの利用についてやっていこう的なプロジェクトです。プラント系なのでサポートがミニマム10年とからしいです。
https://www.cip-project.org/

CIPの活動の中でLinuxカーネルのSLTS(SuperLongTermSupport)というのがあるのですが、長期に渡ってバージョンを固定化してFixPatchを当て続けるのはどうなのか?みたいなのが最初の問題提起的なものでした。

Civil Infrastructure Platform Announces First Super Long Term Support Kernel at Embedded Linux Conference Europe
Linux4.4を10年はサポートしていくというブログ

理屈上は十分なテストケースとバリデーションを通せれば、カーネルのバージョンをBump-upしても問題ないのではないかという前提があります。古いカーネルにパッチを当て続けることは容易では無いため、これらの工数やお金をテスト等に回すほうが健全ではないのかという発想です。
これに対しては、やはりバリデーションの難しさ・過去のアセット利用等が背景としてあることが述べられました。

例えば、最終的な受け入れテストなどはプラントに入れてから行ったりします。機能安全については第三者機関に出すことなどもあります。このような体制は比較的昔からあるものだという理解が必要です。こういった時、セキュリティパッチだけを当てて影響範囲はこれだけですというレポートの提出で済むか、テストケースが全部通っているのでバージョンのBump-upしますが通じるかというシチュエーションが容易に想像できます。

過去のアセットとは、ソフトウェア資産を想定した私が最近好んで使うタームです。(ルー大柴みたいな表現になっているのは許してほしいです)
つまり、プラントのような規模が大きいシステムを毎回1から作るのは非合理的ですし、機能安全規格をPASSしたモジュールなどがあれば使いまわしたいと考えるのが一般的です。つまり、枯れたコンポーネントを積極的に使う動機があります。しかしながら、弱点もあって設計そのものがモダンではない、テストが不十分であるといった時代的な課題も抱えていることが想定されます。そうすると、バージョニングの固定が現実的な最適解になルノではないかと思われます。
これはプラントに限らずあるある話なような気がしています。

バージョニングの固定が最適解になりがちというのを過去のアセットという観点で述べてみました。もう一点、これを正当化(Justification)している根拠としてはプラント系はEOLがおおよそ定まっているという要素があるのではないかと私は推測しました。端的に言えば設計寿命であり、一度入れたものをノーメンテナンスで壊れるまで使い続けるということはあまり考えにくいです。ですから、メンテナンスサポートも含めて収益でありビジネスになっているのであれば、バージョニングの固定はシンプルな発想です。

ところで、製品寿命は存外自明ではありません。
皆様は「長期使用製品安全表示制度」というのをご存知でしょうか。最近、扇風機などを買うと「設計上の標準使用期間 : 10年」とか書かれているシールが貼られていたりします。どうゆうことかというと、扇風機とかうっかりすると30年ぐらい使い続けたりします。すると、コードやモーターの劣化に起因して火災が発生したりとか出てきたりしたんですよね。これを防ぐために注意喚起情報を付与することが今では行われています。
他にも「補修用性能部品の保有期間」といって、修理に必要なパーツを何年保持しますと表示しているメーカーもあります。(この辺りは法的なものかは未確認)

さてソフトウェアという観点ではどうでしょうか。スマホはプライバシーの塊とも言えるかと思いますが、ソフトウェアのセキュリティ的な安全性は何時までどのように担保されているか考えている人はどれくらいいるでしょうか。
IoTマルウェアのMiraiや監視カメラの初期パスワードアタックなどはかなり有名ですが、どこまでどのようにサポートされるべきなのでしょうか。
ソフトウェアも製品に組み込まれている部品の1つですが、これがクリアリーになっているケースはそこまで多くありません。
スマホの例だと、Googleが出しているブランドのNexus・Pixcelシリーズはセキュリティアップデートの日付を明示しています。一方で、これを認知しているユーザーの割合や、サポート期間を超えて使い続けた場合についてはまだまだ社会的なコンセンサスや認識が無い状況だと認識しています。

目指していきたい方向性

ここから脳内ダンプ。ポエムがさらに深刻になってきます…。とほほ。

主にWeb系でマイクロサービスアーキテクチャという話がありますが、これは組込みとかにも言えるんじゃないかなーと思っています。
コンポーネントを疎結合にというのもあるのですが、もう少しトータルデザインとして。APIやインターフェースを界面として個々の品質や実装については担保されていて入れ換えの自由が効くように。

転換期のつらみ

私の考え方としては、今は転換期のつらみと捉えています。
コンピューターテクノロジーの進化はどの産業よりも変化が早く急速に社会を変化させていきました。ここに、コネクティビティ(ネットワーク)が加わったことにより物理的な制約条件をしばしば突破する強烈なインパクトをもたらしています。現代のソフトウェアは一人では見きれないほどの複雑で非常に高度なものになっていて、しばしばセキュリティ的な問題が含まれ時に狙われるという状況になっています。

高度なソフトウェアを新規でほいほい書けるかというとまだ世の中はそうはなっていないようです。そのために、過去のアセットを使わざる得ない状況があります。ベンチャー企業とか新規参入者はこの辺りが付け入る隙になっていると思います。逆の観点から言うと新規参入障壁とかそういった言葉が出てくる気がしています。

Amazonは元々本の流通をやっていたわけですが、電子書籍を始めちゃうように自分自身で破壊的なイノベーションをしていけるのは相当強いし、やっていかなければいずれか新規参入勢にやられちゃったりするんじゃないかなーと思っています。

終わり。

2018年10月1日月曜日

Yahoo!ジオシティーズ、お世話になりました。






このサービスはわりかし原点かもしれません。年齢がバレる。
ここからHTMLを学びパーミッションや文字化けの洗練を受けたのです。
当時のアップローダはなぜか全部EUCに変換しちゃうとかだったような。もう何も覚えていません。
FFFTPでバイナリモード?アスキーモード?よくわかんないけど、手元のメモ帳で書いたHTMLをアップロードしてはWebブラウザを更新したのです。
ちょっと動いてすごいなってなって、とほほのWWW入門のコードをベースにできることを増やしていったような記憶があります。
当時はフレーム(iframe)とか結構当たり前で、上手に設定してないとどんどん左のメニューが入れ子になっちゃうとか合ったような気がします。
レスポンシブデザインとかなくて、決め打ちなのでレイアウトとかどうなってたんでしょうか。それでも、手元でいい感じに分割されるのが楽しかったです。
わけもわからずキラキラするJavaScriptをコピペしてキャッキャしてたのも懐かしいです。
そこからCGIなるものをがあるとしって、Infoseekに行ってみたり、カウンターなるものを設置してみたり。

そういえば、一緒に初めた友人のページばっかりカウンター回ってジェラシー感じたりもしましたっけ。

小学生だった自分の家にはまだパソコンとかインターネットはなくて、児童館で貸し出してくれるWindows95seとかを触ってたような気がします。
申請書を書けば誰でも使えるのですが、使っているのは自分たちぐらいでした。
そういえば、PCがガリガリガリとHDDの音を立てて起動するのに5分ぐらい待つ。というのも遠い昔の話ですね…。

当時もWebチャットとかお絵かきチャットとかBBSとかFlashとか合ったような気がします。Yahooキッズが懐かしいです。
そういったコミュニケーション系には自分は特にはまらずこの辺りには思い出がないです。

ニフティサーブとかパソコン通信とかは分かりません。
でも、この世界においてはおじさんに一歩足をかけてるんだなとやっぱり実感するのです。

2018年9月21日金曜日

LinuxカーネルにCode of Contactがコミットされた

Subject Linux 4.19-rc4 released, an apology, and a maintainership note
https://lkml.org/lkml/2018/9/16/167
> The one change that stands out and merits mention is the code of conduct addition...

https://git.kernel.org/pub/scm/linux/kernel/git/stable/linux.git/commit/?id=8a104f8b5867c682d994ffa7a74093c54469c11f

Code of Conduct: Let's revamp it.
The Code of Conflict is not achieving its implicit goal of fostering
civility and the spirit of 'be excellent to each other'. Explicit
guidelines have demonstrated success in other projects and other areas
of the kernel.

Here is a Code of Conduct statement for the wider kernel. It is based
on the Contributor Covenant as described at www.contributor-covenant.org

From this point forward, we should abide by these rules in order to help
make the kernel community a welcoming environment to participate in.



自分にとってはCoCはちょっぴり思い出がありまして、それはUbuntuを使い始めたきっかけの1つです。
私にとってCoCとは、どんなコミュニティでありたいかということを意識付けるものであると思っています。

2018年8月26日日曜日

[ポエム]仕事しながらLinuxカーネルのメインライン化が大変な件。(途中で書くの挫折)

タイトル長すぎて検索でヒットしない予感。ポエムだし、このブログは自分のための備忘録ということになっているので許してください。(言い訳ここまで)

昨日、[ポエム]Linuxカーネルに関する独自コードをメンテナンスに関してという物を書きました。
本記事では、メインライン化の大変さを述べます。次にフォークコスト高すぎ問題について述べます。
先の記事については3行で書くと…
  • Linux(カーネル)といえども、特別なことはなくソフトウェアなので変更をしたくなることがある。機能の追加やバグ修正といったもので一般的なオープンソースソフトウェアと同じである。
  • 作ったソースコード(パッチ)をメインライン化(コミュニティに取り込んでもらってマージしてもらうこと)を基本とするべきであることを経験的に知っている。
  • しかしながら、諸般の事情でメインライン化できないこともあるだろう。大事なことはメインライン化したときのメリット・デメリットは検討することではないだろうか。

みたいな感じです。(雑)
2018年にセルフツッコミを書きたくなってしまう人です。ポエムっぽい。

メインライン化は簡単ではないとは?

まず、メインライン化とは何かという点をクリアにしておきます。
ここでは自分が作ったパッチをコミュニティに送って最終的には取り込んでもらうことを指すことにします。
メインライン化の頓挫と表現した場合は、パッチが取り込んでもらえなかった状況を想像していただければと思います。

話を分かりやすくするため、シナリオ形式で書いてみたいと思います。

シチュエーション

・・・
ここに会社に雇われているプログラマーがいます。名前は勇者といいます。
この会社では現在とある製品の後継機種を設計しており、ハードウェアエンジニアはコスト削減のために部品の一部を変更することにしました。
変更された部品はソフトウェアから制御する必要があるものであるため、ソフトウェアの変更が必要か確認されました。
確認の結果、新しく採用された部品(デバイス)を動作させるために必要なデバイスドライバーが残念ながらLinuxでは提供されていないことが分かりました。
あなたはハードウェアと仕様書を渡され、Linuxで動くようにしてほしいと仕事を依頼されました。
無事にやり遂げ、開発完了したソースコードは1000行程度の簡単なもので収まり、社内の品質テストにも合格しています。

git diff -urn とすることでパッチ形式で出力できる状態です。
・・・

シナリオ1 メインライン化に理解がない。社内的な仕組み・ルールがない。

勇者はメインライン化の必要性があると感じたため、上司に少し工数がもう少し欲しいと相談しました。

No1. 上司「メインライン化って何?」-> 勇者は説明を始めた。
--> でも、上司はピンときておらず困惑している! -> もういいや。

No2. 上司個人にはメインライン化の理解はあるが、会社としての見解がない場合等
「でも、会社の成果物を勝手に出すのは法務部とかに確認が必要そうだなぁ…」 -> もういいや。
「でも、工数は開発と品質テストの分しか確保してないからできないよ。」 -> 勇者は次のプロジェクトへ…
「好きにやったら良いと思うよ、責任は取れないけど。」 -> もういいや。

社内にルールや前例がないと往々にして動けないことがあります。これは正しいことなのですが話が急に大事になってしまい頓挫する例です。
このような場合エンジニアはメンテナンスコストとメインライン化の作業についてPros/Consをとって取りまとめておき、責任者に承認を得るのがベターだと思われます。(つまり、現場レベルでは少なくとも責務を果たしているという状態にしておく)
ただし、メインライン化とはなんぞや?から始まる場合はPros/Consシートの価値を理解することができない環境ということになるのでつらいですね。解は仲間を頑張って見つけて機運を高めるように頑張ってみる、上司を説得して業務課題化する、俺が上司だ!、理解ある会社に転職してしまうなどがあります。
ちなみに、ここでは勇者がメインライン化の必要性に気付いている前提となっています。もしかすると、メインライン化という意識すらない可能性がありますがががが…(割愛)

シナリオ2 メインライン化の作業が楽ではない

皆さんは、最初のスタート地点はここだと思われたかと思います。実際にはシナリオ1で頓挫している現場も多数あるように感じています。
スタートラインに立てているならば、なんとかなるでしょう。 - fin-

さすがにそれでは雑すぎるので、作業の中で頓挫してしまう例を上げてみたいと思います。

No1.パッチをどこにどうすれば取り込んでもらえるか分からない。
-> 最初は誰しもがそうですよね。社内にナレッジがある場合は先輩に聞くことで解決できますが、ない場合は調べる他ありません。
ちなみに、ドライバーを新規作成した場合はサブシステムのMLなどに投稿するのですが、これだけで1つの記事が出来上がってしまうので割愛します。

No2.パッチの品質が悪い。
期待した動作するコードが必ずしも、優れたパッチとは限りません。
パッチをMLに投稿してから指摘されることも多いです。むしろ、一発で通すことを目指すというよりレビューを受けて仕上げていく感覚に近いです。
よくある指摘事項は、パッチをもっと分割して。パッチのdiscriptionを充実させて。このアプローチは微妙だからこうしてくれなどがあります。

このリファクタリング作業はこのようにレビューを受けたりするため、そこそこ絶対的に時間がかかることが多いです。そんなに手間かかるならやめたら?という横槍が入ることもあるでしょう。
またQAコストがペイしないと判断されて頓挫してしまうことがあります。(製品に組み込んでいる場合は大抵結合テストが必要だからです。)
本来ならば、メインライン化の作業と製品作りなどは分離して置く必要があるのですが、片手間にどうぞという形だったりする場合は、このようなことが発生することがあるようです。

まだまだあるぞ、現場のあるある。

そもそも、カーネルってバニラの最新のLTSが使えるわけではない。SoCに付随してくるLSPを使わざる得ない。
このLSP、何個前のバージョンがベースですか…。なんですか、この独自パッチにまみれたカーネルは。いや、パッチならまだいいけど、Linuxカーネルのお作法とかの概念が存在しねぇ!?おれおれヘルパー関数でサブシステム越境してやがるだと!!なぜ、そこにフック関数が…etc

この辺はx86_64はあんまりないかも知れませんが、ARM SoCだとにゃーんって感じなんですよねー。

力尽きた

書き出すとシナリオがいっぱいあることに気付き、この辺りで書くのに疲れました…。(パタリ)
アップストリーム化の作業する上で、バニラのヘッドが使える環境じゃないと大変とかなんか他にもいろいろありそうなのですが…。
この辺誰かもうまとめるような気がするのですが、意外に無いのかな。