読者です 読者をやめる 読者になる 読者になる

解き放たれしソフトウェア

GNU/LinuxなどFLOSSについて書いてみるつもり

『Software Design』のUbuntuの連載に書かれている機械翻訳疑惑騒動の記事について

技評『Software Design』6月号の「Ubuntu Monthly Report 【86】Ubuntuの方針転換とWeb翻訳混入事件」の記事を見てエグいと思いましたので。 なぜならば、個人名は挙げていないとはいえ、公刊されている雑誌の記事に一方的に書いて晒しものにしているからで。公刊出版物に投稿する事実上の権力をもっている社会的強者が、一介の一般人である相手の出てこられないところで一方的に書く。それは、事情がどうあれ、物凄いイジメだと思いましたので。 記事自体では、相手の個人名を記載していないため特定不能なので名誉棄損等にはならないという考えでしょうが、それはウェブで検索すれば容易に判明してしまいます。たとえ犯罪ではなくとも、相手には一般人レベルの反論手段しかないがゆえに、物凄くアンフェアで、一言でいえばイジメですから。

前提

Ubuntuの翻訳もオープンソースソフトウェアの御多分に漏れず公募しているわけですが、Ubuntuでは翻訳成果物のライセンスがBSD-2だそうです。他方で、巷のウェブサービス機械翻訳でアウトプットされる成果物はこれと互換性のない異なるライセンスであることが多く、ライセンスにヴァイオレイトするものを採用するわけにはいかないわけです。

疑惑

Ubuntuの日本語翻訳チームのところに翻訳案をコミットし続けていた某氏が、採用されないコミットが多いことに業を煮やして、日本のではなくグローバルなメーリングリストの方に陳情をしたそうです。 これに対して日本語翻訳チームの側が反論して云々っていう流れです。 参考: Ubuntu英日翻訳にGoogle翻訳の成果物を突っ込む人物が現れライセンスがなんじゃもんじゃでつらい - Togetterまとめ

で、要は、Google翻訳の成果物をコミットしていたという疑義が発生したわけで。

Software Design』の当該記事の問題点

周知させたいのは、「ライセンス違反になるような『Web翻訳』の成果物をコミットしないでください」ということであるはずです。しかし、当該記事はそこから論点が概ね外れていて、どちらかというと、騒動の具体的な説明と、実名は挙げていないとは言え当該人物に対する非難。

個人的所感

Ubuntu の Japanese コミュニティ自体もどうかしていると私は思っていますよ、個人的感想。 例年のミーティングの際に大量の唐揚げを出して悪ふざけするところとかにしても。 (日経の雑誌の影響もあるでしょうが、)ユーザの人数が多いのに、権限や事実上の影響力をもっている人が少なく、入れ替わりも少なく、それなのになんか、主観や先入観をもった言動を、ウェブ上であれ、さらには雑誌上であれ、公開して憚りませんよね。

率直に言って、問題の根底には、フリーソフトウェアやライセンスのことが理解されておらず、多くの人は無関心でいる(ナイーブだ)ということです。 GNU/Linuxに関する雑誌は現在は(少なくとも、書店で並んでいる雑誌では)せいぜい『Software Design』と『日経Linux』くらいしかないわけですが、その日経が意図的に「フリーソフトウェア」を隠蔽して「フリーソフト」と書いています。 多くの人が「無料で、オープンソース」ということにしか意識をもっていません。 フリーソフトウェア思想とか、ライセンスのこととかは、関心をもつ以前にそもそも、知らないわけです。

Ubuntuフリーソフトウェアの「意識低い系」の典型みたいなもので、プロプライエタリ・ソフトウェアのリポジトリを提供していますし、フリーソフトウェアということの周知や啓発について非積極的な方です。

で、OSSとか言うんですが、そこで意図的にフリーソフトウェアを混ぜてFLOSSと言うことすらしない人々の意図はなんなのか。 そうしたことで寄ってくるユーザやコントリビュータはどういう人々なのでしょうか。 例えば、結果さえよければかまわなくって、慈善でこんなにコントリビュートしているんだから偉いのに、なんで評価されないのかってなる。

一般社会では概ね封建的で、生まれや身分によって権限をもてたり、成果があっても地位が与えられなかったりすることが多いです。(ちなみに、それで日本ではなく国外で活躍しようとする人もいますが、多くの国ではJapanese、Asian、肌がYellow、Non-Christianなどということで往々にして事実上の差別を受けます。) だから、OSSコミュニティにコントリビュートして評価されようとする、承認欲求を満たそうとする人々は、当然にかなり多いでしょう。 つまり、なぜわざわざコントリビュートするかって、動機があるはずなんですよね。

地位身分階級をもたない人が承認欲求を満たすためにコントリビュートしていくときには、その人に自己客観視(自己洞察)が足りなければ、結局のところ(社会生活で不利益を受けているのにも関わらず)権威主義に陥るという矛盾した歪みが出てきてしまうことがありえます。 そうして、権威権力をもつ人(プロジェクトの創始者とかメンテナとか)を礼賛したり、取り入ったりしようとすることもあるかもしれません。 (実際、OSS界隈だけではなくって、今の日本人の社会現象自体がそうですよね。差別されている当人が差別肯定して自分よりも下層の人間をつくって差別するっていう矛盾。)

本来は、フリーソフトウェアって、コミュニズムと親和性が高いし、自治で維持管理されていくものだと思います。ところが、そういう層がコントリビュートしているようには思えません。例えば日本共産党員がフリーソフトウェア界隈で活躍しているというところが、(本当は居るのかもしれませんけれど、少なくとも、)見えません。(本当は居るのかもしれないけれども、「私、共産党員です」「私、社民党支持者です」みたいに明言したら社会の大手通りから疎外されるようなのが日本ですから、言い出せないと思います。「角を立てない」ために黙っている人が多いと思います、変な社会です。)

むしろ実際には、OSSって、商業的、資本主義的に傾いてしまっています。それにそうしないと人もカネも集まらない。 いわば「悪魔に魂売った」みたいな感じです。

フリーソフト」(「無料ソフト」の類義)に釣られる層って、簡単に言えば、拝金的なのですよね。 そうして釣られて、実際とはズレた信念をもってしまった人が、ユーザになり、ときにはコントリビュートしていくわけですから、大変です。

フリーソフトウェアってこういうものなんですよ、って周知して人を集めた方が、寄付(献金)が集まるかはともかく、来る人に対してインフォームドコンセントが成り立って健全だと思うのですが。

Let's Encrypt の TLS 証明書をウェブ以外で利用するには

Let’s Encrypt発行のTLS証明書は、FirefoxChrome などのウェブブラウザでは対応しています。 しかし、Let’s Encrypt の証明書はウェブで利用することが想定されていて、その他のインターネットサービスにはそのままでは利用不可能だったりします。

その原因は、認証局から直接に署名された証明書ではなく、中間に証明書をもう一つ挟んでいるからです。 その中間証明書がインストール済ならばそのまま利用可能なのですが、無ければ中間証明書を読み込ませる必要があります。

具体的には、 Let’s Encrypt で発行を受けたときに付いてくる chain.pem というファイルが相当しますが、 同じものが “Chain of Trust - Let's Encrypt - Free SSL/TLS Certificates” にアップロードされています。 (“Let’s Encrypt Authority X3 (IdenTrust cross-signed)”)

この中間証明書を保存して、 CA (Certificate Authority)ファイルとして読み込ませれば、ウェブ以外のネットワークサービスでも利用可能になるはずです。

lm_sensors でファンの回転数を制御する

近年の PC 用 M/B の多くは、温度やファン回転数、電圧のセンサーチップが搭載されています*1。CPU 温度と冷却ファン回転数を監視することで、ファンが壊れて即死という事態を予防しています。 そして、M/B のファームウェアによりますが、ファン回転数を制御可能な M/B が一般的になっています。

lm_sensors

さて、GNU/Linux では、 lm_sensors を用いると、こうした温度や回転数などの数値を取得可能です。 さらに、 lm_sensors を用いれば、検出した温度に合わせてファンの回転数を変えるということも可能です。

参照: ArchWiki

まず、 lm_sensors をインストールします。

sensors_detect

そして、sensors-detect を root 権限で実行して、センサーを検出します。

Gentoo の場合は

Gentoo の場合は Linux カーネルを自力でビルドするのが原則でしょうから、sensors-detect の出力内容に応じてカーネルコンフィグレーションをやり直し、カーネルの再インストールが必要になるかもしれません。 lm_sensors - Gentoo Wiki にも書いてありますが、

  • CONFIG_I2C
  • CONFIG_I2C_CHARDEV
  • CONFIG_HWMON
  • CONFIG_THERMAL_HWMON
  • (おそらくは) CONFIG_X86_CPUID
  • M/B に載っているセンサーチップ用のデバイスドライバ

以上を、ローダブルモジュール<M>でもいいですが、有効にする必要があります。

とはいえ、M/B に載っているセンサーチップが何かが判らないでしょう。 とりあえず後回しにして sensors-detect を先に実行すると判ります。

設定が完了したら、service lm_sensors start で開始し、rc-update add lm_sensors default で再起動後も始動するようにします。

sensors

設定完了後は、 sensors コマンドで、センサーの数値が表示されます。

fancontrol

lm_sensors に入っている fancontrol が、ファン回転数制御のためのプログラムです。

参考: ArchWiki

pwmcontrol

fancontrol を使えるようにするには設定が必要です( /etc/fancontrol )。 pwmconfig は、この設定のためのツールです。

Gentoo の場合は

Gentoo ではやはり、 service fancontrol start で始動し、 rc-update add fancontrol default で自動始動にします。

DCファンの構造と回転数制御

さて、PC は電源ユニットから先は直流電力(DC)ですから、冷却ファンもDCです。

DCですから、端子の一本はプラスで、一本はマイナスです。

CPU 冷却ファンなどでは、回転数を M/B に検知させるのが一般的になって久しいです。そこで、回転数を知らせるためのピンが1本あります。

よって、端子は、3ピンあるわけです。

回転数制御の手法

回転数を固定ではなく可変にすることもいまや一般的です。 そして、回転数を変えるための手法には

  1. M/B が一方的に電圧を上下させる手法(電圧制御方式)
  2. M/B がファンに信号を送って、その信号を受けたファンが回転数を変える手法(パルス幅変調制御方式 ; PWM

の2種類があります。

電圧による制御では、ファン側に特別な機能は必要ないのが利点で、挙動は M/B と ファンとの相性次第で何ら確証がないのが欠点です。電圧が足りないときのファンは、停止します。

他方の PWM 制御では、信号を送るためのピンがさらに1本必要になり、合計4本の端子になってしまいます。 PWM 制御では、挙動はファンの設計次第で決まるので確実です。

M/B の対応状況

電圧制御でも回転数の上下は可能ですから、 PWM 非対応の M/B は多いです。

lm_sensors の pwmconfig では、"PWM" という語を用いてはいますが、PWM 用の数値を M/B に送ったところで実際にどう処理されるかは M/B 次第です。

実際には PWM 非対応の M/B では、電圧を変えることでファンの回転数を制御します。

3ピン端子と4ピン(PWM対応)端子の互換性

3ピン端子と、4ピン(PWM対応)端子とは、互換性があります。 PWM 対応 M/B に 3ピン端子は挿せます。 PWM 用ファンを PWM 非対応 M/B に挿せます。ただし、他の部品による物理的干渉が無いことが前提ですが。

PWM 信号が来ないときの PWM ファンは、100% の指令が来ているものとして動作します。 ですから、電圧制御方式の M/B に挿しているときは、 PWM ではフル回転ですが、電圧不足で回転数が下げられます。

実際の回転数の設定どうしよう

ケース内には、M/B のシステムチップ、RAM モジュール、拡張ボード、HDD など、発熱する部品があるでしょう。 ですから、いくら CPU がパッシブヒートシンクだけでまかなえる状況であったとしても、ケースへの air flow はあった方がよいと思います。

ただし、電源ユニットがファンレスではない場合は、電源ユニットのファンを利用して冷却し、CPU ファンやケース(シャーシ;chasis)ファンは止めるという案もあるかもしれません。そうなると、 CPU ファンもケースファンも止める余地はあります。

*1:他方で、携帯端末などのいわゆる「組込み」などではそもそも CPU が過熱しない、ファンがないといったことから、事情は異なります