LAMP on Fedora30

仮想PCでのCentOSはとりあえず一段落。で、もともとFedora上で動かしてみたらどうなるのかということで環境構築。

いろいろとパーミッションの関係で引っかかたので対策をメモしておく。

cgiの起動許可はSelinuxをDisableにしてさらに、/var/run/httpdのオーナーを変更してクリア。
php系のcgi-handlerの起動失敗の方は/etc/php-fpm.d/www.confのユーザーとオーナー部を書き換え。これだけでは駄目だったので、/var/run/php-fpmのユーザーとオーナーを書き換えてクリア。
さらに/var/lib/phpのopcache/とsession/とwsdlcahce/のユーザーを書き換え。

しかし、CentOSを設定した時にこんな面倒は無かったのに不思議だ。こんなことなら、素直にユーザーapacheを作成しておいた方が早かったかな。

仮想PCその2

VirtualBoxのインストールは無事終了です。こちらもカーネルバージョンに依存するモジュールがあるのですが、第三者のパッチを当てて処理なんてことはないので、今後のカーネルアップデートでも多少楽できるかな。

問題は、画面の広さと違和感の残るマウスやキーボード入力。今時SVGA(1024×768)しか広げられないのってどうなんでしょう。マウスにしても仮想PC内外の識別がいまいちでなんかちょっと…

まぁ、HOST環境がLinuxなのだから、こちらでLAMP app(Apache,MariaDB,PHP)を動くようにするのが一番手っ取り早いのはわかってますけど、それだと進歩がない気がしてね。

XenとKVMにも挑戦してみますか。

仮想PC

職場サーバーの環境整備として、自分のPCに仮想マシンをインストールして、そこであれこれ作業しています。いきなり本番機でやるとトラブルの時の始末が大変だからで、まぁ当たり前と言えば当たり前のことではあります。

で、自宅のLinux(Fedora)上でも仮想PCが動くのかと思い作業。いろいろとトラブルはあったのですが、VMware Playerは無事に起動。職場の仮想PCもそのまま持っていくこともできて一安心。のつもりでしたが、2日後にKernelアップデートが有ってあっさりと動かなくなりました。

もともとカーネル系でトラブルが起きるので専用のパッチがあったのですが、そいつが最新カーネルには対応しきれず、対応モジュールが作成できません。

いろいろ見てみると、Fedoraに限らず、Ubuntuでもカーネルのアップデートで動かくなったという相談が多数。これだと頻繁にカーネルが更新されるFedoraのような環境では安心して使用できないのでVMwareは使用断念しました。

となると次の仮想PCですが、Linux界隈ではXenが有名ですが、私のやりたい方向とは違っている雰囲気。なので次善の策としてOrcaleのVirtual BOXを選択。ホストOSのカーネルに敏感でなければいいなと思う次第。

とりあえず、なぜかVMwareに付属しているツールでVMware上の仮想PCをOrcaleでも読み込める形に変換してトライ開始。
さてはてどうなるかな。

MDB2 to PDOその3

5つのシステムのうち4つまでは完了。PDO対応を進めつつ、以前は理解力不足で機能させられなかったJavascriptによる事前チェック機能などを整備してだいぶ使いい勝手も良くなりました。

最後の一つは一番新しい奴なんだけど、変な色気を出してフレーム構造にした結果、処理制御が難解になっています。
何周遅れてんだよと嘲笑が聞こえてきそうですが、PHPのsession管理を利用すれば、今はformのPOST機能で利用している長いパラメーター文字列の何文字目が□だったらこの処理、△だったらこっちの処理なんて複雑な事をする必要がなくなることが判明。
この機構を利用してやる予定だけど、中身が大幅に変わるので、少し時間がかかりそうだな。

Javascriptを利用した場合、手っ取り早くブラウザのWeb開発モードを利用してデバッグするのだけど、反応が悪くてとてもしんどい。画面が狭いもの悩みの種。専従じゃないので、わざわざ別ディスプレイを用意してっても大げさだし、なにより現在VM Player上のCentOSで作業しているので、VM環境のLinuxがマルチディスプレイに対応するかどうかも怪しいしね。

MDB2 to PDOその2

仕事の合間に片手間でやっていたMDB2からPDOへの移行。第一弾がようやく完了です。

やり方によって、処理結果がObjectだったり単純変数だったりといろいろなので、面食らいながらもなんとか書き換え終了です。
PDOの目玉であるpreparedステートメントを利用すると、DBに届く実際のクエリが確認できず、一点だけ問題が解決できないままとなってしまいました。この実際に投げているクエリが確認できると、とても良いんだけどな。

今回改良した処理システムは2006年からチマチマとイジりながら運用していたもので、現時点でソースを読み返すと、SQL文を工夫すればクエリの結果からデーターを選別しなくても良いのにという点が多々有りました。その辺は改良したので、少しは全体的に早くなったかな。

それと、HTML部とphpソースが混じっいて読みにくいですね。システム的にはOKになっているけど、もう少し改良しなくては。それと残り5つの処理システムがMDB2のままなので、こちらも書き換えていかなくてはいけないな。

乱数の質その2

モンテカルロ法だとよくわからなかったglibcとMelsenne Twisterの違い。ならば単純にヒストグラムを取ったらどうなるという訳でテストです。
一様乱数だと処理が面倒なので、0から9999までの乱数を発生させて、各数値の発生回数をカウントします。

全体で1010回の試行の結果は次の通り。

分散の値はMTの方が大きくなっているけど、そういうものなのかな??

実際的にはホワイトノイズ(例のシャーってノイズ)にA/Dコンを接続したものや量子力学的現象を利用するとかいろいろな方法が提案されていますが、何が一番なんだろうな。というか、乱数の質ってなんだか哲学的な話になってきたので簡単には結論は出せないんでしょうけど。

乱数の質?

乱数を使用してあれこれという場面は結構ありますが、質がどうなのかのチェックはしていなかったと思い、ちょっとテストした結果です。

比較にはLinux標準のglibcに含まれるrand()と Mersenne Twisterと呼ばれる手法によるgenrand_real1()を利用して一様乱数を発生させてどんな感じなのかを調べます。ちなみにMersenne Twisterは非常に質が良いとされている最近出てきた乱数生成手法。
ただヒストグラムを取っても面白くないので、モンテカルロ法で円周率を計算させてみます。

プログラム自体は単純なので省略。各10億(109)点(20億組)から円周率を計算することを1000回繰り返すので、1兆(1012)組の乱数を発生させることになります。
MT.hの中身を見ていないのですが、けっこう面倒なことをしているようで、rand()が360分かかったのに対して、genrand()の方は415分が所要時間。

で、結果はどうなのかというと、
円周率計算結果
と大差無しの結果が得られました。なんか肩透かしだな。というよりrand()もなかなかやるじゃないかという訳で安心して使用できそうだという結論。それともあと4桁くらい余計に生成させると差が出るんだろうか?  ただ4桁増やすと、結果出るのが4150000分後って288日もかかるんでやる気は無いけど。

追記:
もしかして、109個ってのが多すぎだったかも。3桁くらい減らしてみたら、違いが出るか?

多角形からの円周率

円周率の算出方法として内接する多角形の一辺の長さの合計から割り出す方法があります。

基本から考えると、こんな感じかな。
まず円に内接する多角形を考える。この多角形は中心を頂点とするn個の二等辺三角形に分割でき、底辺の長さの合計が円周に近似される。
さて角数をnとすると、各三角形の頂角θは

であり、各三角形の底角θ1

頂点から底辺の中央に向けて垂線を引くと、底辺の1/2の点で交わるので、円の半径をrとすれば、底辺の1/2の長さr1

となるので、n角形の辺の長さの合計Rは

と表される。
元の円の半径rを0.5とすれば、
となる。

例えば、4角形ならば4cos(90-180/4)=2.828…、5角形なら5cos(90-180/5)=2.938…
120角形ならば、120cos(90-180/120)=3.141233…
といった具合。

つまり、

とまぁ、Texを使えば数式をそれらしく書けるのが嬉しくて下らないことをだらだら書きました。

現代では三角関数が使えるので、それこそ電卓でも持ち出せば1000角形だろうが一瞬で計算OKと。それでは意味はないので、幾何的に処理することを考えないと。
幾何的に処理となると、三平方の定理を使ってやればいいのかな? ちょっと図を書いて考えてみよう。




KiCAD日本語対応その後

メインシステムであるFedoraが30になったので、そちらの対応に追われていました。
Fedora30ではKiCadが5.1.2となっています。例によって.srpmを調達してnewstroke_font.cppを入替え。無事にLinux版はビルドに成功しました。

それにしても、バージョンアップの度にこれだと面倒だな… Windows版だとWinbuilderにまた変化が有ったようなのでこちらは手強そう。

ところで、この日本語対応版KiCADのバイナリって需要があるのかな? 本家kicad.jpも活動が停まっているように見えるしな。

Fedora30

新しい版の発表が先日ありました。予定では7日とのことで、連休明けだなぁと思って居ましたが、運良く休み期間中に発表になったので早速入替え。半年に一度の煩わしい楽しい時間の始まりです。

とりあえず最小限インストールして、何時のように必要なものをインストール。
さすがに半年に一度インストールしている関係で環境構築はすっかり慣れし親しんだルーチンワークで、約2時間ほどで8割方元の環境が戻りました。あとは開発系のパッケージだけど、なにが必要化はよく掴んでないので、必要と言われるままに入れていくしか無いな。

例によって再ビルドするパッケージが山積みとなりますが、楽しくしばらく遊べそう。