FBSD111C-EMACSに復帰
インストール画面のスクロールばかり見ていて飽きてしまったので、mozc-emacsが動いているFBSD111C-EMACSを弄る事にする。
FBSD111C-NOX11でuim.elを試してみたい気もするが、上手く行かない事が続くと、続けるのが嫌になる。
ますます具体的な目標が曖昧になりつつあるので、本来の直近の目的に焦点を当て直す必要がある。本来の直近の目的とはEmacsを日常的に使う事。その為にまず10.3でやっていた作業を引き継ぐ事。
仮想マシンを次々とセットアップしているのは、本来その為のプラットフォーム作りをしていたのに他ならない。
後で後悔しない為という名目で、ちょっと回り道をし過ぎて、道に迷いかけている。
FBSD111DEVで走らせているperl5のmake testはまだ終わらない。
結局、Perlのmake testは終わる気配がないので強制終了させた。
FBSD111C-EMACSにemacs-noxをインストール。
素のemacsだが、uim-mozcがインストール済みなので、日本語の入力は使える。
w3mはewwで代替できる。
uim.elについて調べる。UimEl · uim/uim-doc-ja Wiki · GitHub
uim-el-emacs25_nox-1.8.6_6 をインストール。
# pkg install uim-el-emacs25_nox |& tee log
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):New packages to be INSTALLED:
uim-el-emacs25_nox: 1.8.6_6Number of packages to be installed: 1
33 KiB to be downloaded.
Proceed with this action? [y/N]: y
[1/1] Fetching uim-el-emacs25_nox-1.8.6_6.txz: ..... done
Checking integrity... done (0 conflicting)
[1/1] Installing uim-el-emacs25_nox-1.8.6_6...
[1/1] Extracting uim-el-emacs25_nox-1.8.6_6: .......... done
root@FBSD111C-EMACS:/home/muh # cat log
Updating FreeBSD repository catalogue...
FreeBSD repository is up to date.
All repositories are up to date.
The following 1 package(s) will be affected (of 0 checked):New packages to be INSTALLED:
uim-el-emacs25_nox: 1.8.6_6Number of packages to be installed: 1
33 KiB to be downloaded.
Proceed with this action? [y/N]: [1/1] Fetching uim-el-emacs25_nox-1.8.6_6.txz: ..... done
Checking integrity... done (0 conflicting)
[1/1] Installing uim-el-emacs25_nox-1.8.6_6...
[1/1] Extracting uim-el-emacs25_nox-1.8.6_6: .......... done
emacsはインストールしたばかりなので、~/.emacs.d/init.el はまだ存在していない。
;; uim.elを読み込む (require 'uim) ;; Emacs起動時に読み込んでほしくない場合は、上記をコメントアウトし、 ;; 代わりに下記の行をアンコメント ;;(autoload 'uim-mode "uim" nil t) ;; uim-modeをトグルするためのキーバインド（C-oを使う場合の例） (global-set-key "\C-o" 'uim-mode)
これでOKといえばOK。C-iでカタカナに変換できないのがちょっと不便だが、何か方法はあるはず。UTFがデフォルトになっているEmacs25では、わざわざ指定する必要はないのかもしれない。diredも問題ない。
何か問題があった時に、記述を追加する。日本語に関しては、以前より随分楽になっている。
仮想マシンが増えすぎたので、整理する必要がある。少なくとも今よりは増やさないように。HDDの空き容量が166GBになっている。
験しにPerlをインストールした
完全にやっつけ仕事。ちょっと飽きてる。
Installing perl5-5.26.1...
The /usr/bin/perl symlink has been removed starting with Perl 5.20.
For shebangs, you should either use:#!/usr/local/bin/perl
or
#!/usr/bin/env perl
The first one will only work if you have a /usr/local/bin/perl,
the second will work as long as perl is in PATH.===> SECURITY REPORT:
This port has installed the following files which may act as network
servers and may therefore pose a remote security risk to the system.
/usr/local/lib/perl5/5.26/mach/CORE/libperl.so.5.26.1If there are vulnerabilities in these programs there may be a security
risk to the system. FreeBSD makes no guarantee about the security of
ports included in the Ports Collection. Please type 'make deinstall'
to deinstall the port if this is a concern.For more information, and contact details about the security
status of this software, see the following webpage:
http://www.perl.org/
WARNING: You've never run 'make test'!!! (Installing anyway.)というメッセージがあったので、make test を走らせて見た。ただのテストでも結構時間がかかる。
make test、正直なところ意味が判らない。failがあってもソースを追跡して原因を特定するほどの力量も気力もないが、やらないよりはやった方がいいのだろうし、やっているうちに意味も判ってくるかもしれない。
時間ばかり掛かって、えらく時代遅れな事をしているような気がする。すべてをportsからインストールして実用に耐えるマシンを構成しようとしたら、いったいどれくらいの時間がかかるのだろう。
運用を目的にするのなら、パッケージでさくっといった方が良い。
完璧を目指すならばsubversionを使うべきだし、完璧を目指してもロクな事にならならいのは判っているのだが、趣味の一環だから、まぁ適当でいいか。
pkg info
dialog4ports-0.1.6 Console Interface to configure ports
perl5-5.26.1 Practical Extraction and Report Language
pkg-1.10.5 Package manager
開発用マシンのプロトタイプ
uim-mozcのポートからのインストールで懲りたので、開発用マシンのプロトタイプをセットアップしようと思う。
勿論、趣味の一環なので、楽しみながらというのを最優先する。
まずは、uim-mozcのセットアップでの、パッケージとポートのpkg infoを比較して、差分が開発用のベースだと考えてもいいだろう。
sataは意味がないようなので、IDEでのセットアップにする。
面倒臭いので、FBSD111Cのクローンを使う。
inm-mozcのmake installで時間が掛かりすぎた挙句のインストール失敗でモチベーション低下。インストール画面のスクロールを見ているのに飽きた。
動作確認で遊ぶ。
uim-mozcをポートからインストールしている現状のマシンを開発用に流用しても同じようなものだが、意図してインストールしたのか、結果的にそうなったのかでは、方法論的に異なる。
問題は本来の目的が、どんどん希薄になってしまっていく事。Emacsで日本語が使えるシステムは既にセットアップできているので、併行すれば良いだけなのだが、どちらに重点をおくべきか、バランスが難しい。
趣味のコンピュータ
仕事としてのコンピュータは、あまり楽しい仕事ではない。
ディスプレイを凝視して、とても面倒臭い作業をしている時でも、周囲にはそうは映らない。端末に向かって放心しているように見えるらしい。集中している時に後から不用意に声を掛けられて、何度椅子から飛び上がったか判らない。
開発時は上流工程にも積極的に口を出すようにしていたが、維持運用に入ると、システムへの関与は分業化され、個人の作業は局所化され、繰り返しの機械的な作業と不具合対応が日常になる。
自分はクライアント側の立場に居たので、そこそこ好き勝手はできたのだが、それでも中盤以降はマンネリ化して嫌気がさしていた。
開発ステージは、クライアント側で関わる分には面白かった。それはシステム的な面白さが３割、業者との駆け引きが７割だった。システム企画部は運用部門の要求仕様を抽出する能力は持たず、予算管理が精一杯で、責任逃れの為に、業者と運用部門に丸投げの状態。業者はクライアントの企業の運用部門なんかは舐めきっていた。
業者はクライアント側の要求を最初のうちこそ、黙って聞いているが、結局は実現可能性と予算を盾に、どんどん簡略化し、最終的には自分達が保持しているテンプレートに落とし込む戦法を取る。実現方法を詳細にクライアントに説明する事は無駄だと思っており、こちらが黙っていると、手抜きの議事録とそれに準じた仕様書を提案してくる。議事録はクライアントの言質を証拠化する為、仕様書は肝心な部分が誤魔化されていたり、意図的に抜け落ちたりしている。
結局、業者とのミーティングはアリバイと経費稼ぎに過ぎない。ミーティングも人月の計算がからんでくる。議論が白熱して二転三転するのは、業者にとっては思う壷だっただろう。ミーティングに出席するクライアント側の人間は、素人に毛が生えたよりも始末に終えなかったりする。エンドユーザーコンピューティングが叫ばれていた時代で、適当過ぎる啓蒙書が出回っていた。偉い人達がシステム化に銀の弾の夢を見ても仕方はなかったのかもしれない。
これが、たぶんITバブルの実態だ。合理的でシンプルな処理系より、営業主導で偉い人を納得させ易い処理系が優先され、処理の効率よりもアジャイルな開発手法が優先された。リッチプログラミングなんていうアセンブラ時代の技術者が卒倒しそうな概念が出てきたのもこの頃。システム的な美学よりも結果がすべて。技術者が作業者になり、IT土方なんていうコトバも生まれた。
さて、趣味のコンピュータ。
ITバブルの成果物を全て無視する事はできない。個人が普通にインターネットに接続できる環境というのはITバブルの賜物だし、PCが家庭用電化製品になったのも同様だ。コンピュータは身近な存在にはなったが、複雑で個人で把握しきるは難しい代物になってしまった。
PCのプレイヤー化は、随分前から言われていたが、今のWindowsはコンピュータというより、アプリケーションプレイヤーとして見るのが正しい。自作パソコンにWindowsをインストールするよりは、始めからインストール済みのPCを買ってきた方が安上がりだし、ソフトウェアのインストールは下手にカスタマイズするより、デフォルトの方が無難だ。コンピュータを使うというよりは、コンピュータの上で走っているアプリを使うというイメージが主流になっている。
アプリ自体も大規模で複雑になっている。これは差別化と便利さを追求した結果だから仕方がないのだが、使いこなせないほど便利になっても仕方がない。iTuneなんか、アプリがお節介過ぎて、せっかく整備したライブラリを不本意な形で再整備してくれる。アプリを使っているのか、使われているのか判らない。
趣味でコンピュータを使うのなら、少々不便でも、自分が思うように振る舞い、自分の思うような結果を得る事のできるシステムを構築したい。システム上に自分の世界を創出したい。趣味的な技術者は作業者ではなく哲学者を目指すべきだ。
今のコンピュータを取り巻く環境に言いたいことは沢山あるが、趣味としてコンピュータをいじるには良い時代になった。昔なら、CPUクロック1GHz以上、主記憶1GB以上、ストレージ容量20GBのPCなら場所をとる重いデスクトップで、購入価格も数十万円だった。今ならそれが仮想マシンで、必要なだけ複数セットアップできる。リアルマシンでもラズパイやらBBBなら１万円以内で調達できる。そのメリットを存分に活かすべきだ。
まだ終わらない make install
perl5とpython27を始めとする開発環境や汎用ライブラリは予めインストールしておくべきだった。
buildに必要なツールもインストールされるので、パッケージかのインストールよりモジュールの数は多い。依存関係のあるモジュールをインストールする為に、更にその依存モジュールをインストールするという具合に波及的に必要なモジュールが増えていくので、キリがない。
２回目以降はマシになるだろう。
ソースからビルドされるので、アセンブラまでインストールされる。開発用のマシンを立ち上げるつもりなら無駄にはならないが、Xを省いたコンパクトなコンソールマシンを立ち上げたいという目論見からすれば、見当違いも甚だしい。
x関係のモジュールを省く事は難しいし、どれだけ意味があるのかも判らない。そこまでやるなら、カーネルの再構築やクロスコンパイルによるパッケージの自作も視野に入れるべき。
実務的にはパッケージからのインストールの方が現実的。今回の仮想マシンは実験用のセットアップとして割り切る事にする。（デバッグ環境を整備した開発用の仮想マシンをじっくり作った方がいいのかもしれない。）
実用と趣味と実験は、分けて考えた方がいい。
uim-mozcをポートからインストールしている間に
全然終わらない。
ちょっと後悔しているが、これも経験。昔Kernelをビルドした事があったような気がするのだけど、それより時間がかかっているんじゃないだろうか。
uim 古いだけあって情報が多い。mozcの方は新しいだけに、間にuimが入ってくれるのは有り難いかもしれない。
とりあえず、uimの情報源を、、
Home · uim/uim-doc-ja Wiki · GitHub
FreeBSD のコンソールで漢字の読み書き：ある nakagami の日記：So-netブログ
ポートの使い方の詳細も調べておいた方がいい。これだけ時間を掛けて、結果がpkg installと何も変わらないのでは悲しすぎる。（make cleanはせずにそのままにしておく）
把握可能なシステム
何がしたいかというと、ある程度、何がどうなっているかを把握できるシステムを使いたい。
CP/MとかPC-DOSの時代なら、ある程度何がどうなっているか判った。
大昔のUNIXもシンプルな構成だった。
今のコンピュータシステムはわけが判らない。
Windowsは隠蔽されている部分があるし、それ以前に歴史的な強引さが災いして、複雑怪奇なシステムになってしまっている。
Linuxもバザール形式の開発で、マルチパラダイムの難しさがある。
FreeBSDはまだましだろうというのが、自分の浅薄な知識と経験からの判断。
それでも十分、ややっこしい。
uim-mozcでさえ、make install した後のスクロールを見ていると溜息が出てくる。
uim-mozcをインストールしたら、その時、一緒にインストールされる依存モジュール詳細までは無理にしても、おおよそ何の為のモジュールかくらいは把握しておきたい。
プログラムはC/C++に挫折して、TurboPascalからDelphiに行き、JSP絡みで、Javaをほんの少し齧った程度。Delphiは優れたプログラミング言語だったと思うが、おかげでリンカーとかの知識は完全に欠落している。
システムに適性があって、集中力のある年齢なら、なんとかなるだろうが、凡人の適性で集中力がなくなっている今の年齢で、どこまで行けるか。
今更ながら残念なのは、自分の高校時代にまだPCというものが存在しなかった事。あったとしても嵌っていたかどうかは判らないが、あの暇な時代にPCを知っていたなら、それが幸せに繋がったどうかは知らないが、別の人生があっただろう。
何度かFreeBSDをセットアップして、結局今日までモノにならなかったのは、時間がなかったから。そもそも営業職のサラリーマンがコンピュータを趣味にする事に無理があった。もっともコンピュータに興味を持っていた時期は、入社して３年目くらいで、本来的にそんな余裕はなかった。
まとまったプログラムを書くようになったのは、職種変更で事務職になってから。一般企業でOA化が急務になった頃だったので、好き勝手させてもらった。社内にPCをまともに使いこなせる人材はいなかった。
社内のイントラに関わるようになって、却って好きな事はできなくなった。趣味でPCをいじっていた頃の方が視野は広かったように思う。
それで一旦、1999年くらいに時代を戻してみようと思っている。
1999年といえば、PentiumⅢの時代。Northwoodはまだ出ておらず、CPUが物理的に熱い時代だった。
【ここだけ1999年】PCでテレビ視聴&動画編集をする時代へーーVAIOの最高峰スペック機は42万円だった | GetNavi web ゲットナビ
CPUクロック550MHz、メモリー256MB、HDD20GB、56Kbpsのアナログモデムの時代だ。このスペックのデスクトップ機で当時の実売価格が42万9千円だったそうだ。
当時、新しいPCをBTOで発注しようとメモリーを8MBにするか16MBにするかで悩んでいたのを思い出す。今はノートPCのメモリーを8GBにするか32GBにするかで悩んでいる。
さて、この当時の高級PCのスペックは、７年前に買ったノートPCの仮想環境上で現在稼動している仮想マシンのスペックにはるかに及ばない。最先端を突っ走るつもりなら、全然足りない性能だが、1999年に戻ってその時代の感性で扱うなら、理想的ともいえる環境といえる。
昔、今持っているPCに不満を覚えると数年前の雑誌のPCの広告を眺めて、このマシンに較べたら自分のマシンは夢のスペックだと自分を納得させて物欲を抑えていたのと同じようなもの。
、、、というか、今も昔も変わらないが、過去のある時期のマシンでさえ、そのスペックを満たす程のスキルを自分は持ち合わせていない。
動画処理とか3DCGとか絶対的なスペックが要求される部分は別にして、個人の日常生活をサポートする程度のシステムなら、本来ならば1999年当時のポケットPCにでも余裕でこなせてしまう。要はそれを使う側が使いこなせるかどうかの問題だ。
考えてみりゃ、最初に使ったテキストエディターはedlinだった。それしかなければ、それを便利に使っていた。少なくとも手書きで紙に書くよりは便利だった。Vzエディターを使った時はこれ以上のものは必要ないと思った。
アップルのハイパーカードには憧れた。本物のRDBMSが個人で使える時代が来るとは思わなかった。NiftyServeで月に7万の請求が来た事もあった。
世の中が進み過ぎて、便利に安くなり、逆に面白くなくなったしまった。スマホのアプリに魅力を感じない。殆どが流行物として消費されるべきもので、ツールやリソースとして蓄積できるものではない。ただの暇潰しだ。
とはいえ、今更、chrome代わりw3mを使うかといえば、それはない。Emacsに習熟するよりはMS Officeに習熟した方が、仕事には有利だ。あくまで、趣味、遊びの範囲で1999年のコンピューティングという事になる。その時代に行きていたからこそ、楽しめる遊びであり、暇潰しとしては最高である事は経験的に知っている。
今のところ、これくらいでいいか。
uim-mozcのmake install、無茶苦茶時間がかかっている。PythonとかPerlとかのバイナリが存在しない状態からのビルドだから、まぁ仕方がないが、Xサポートのチェックを外す為だけの作業としてはコストが大きい。
ポストWindowsは考えておくべきだ。
Windowsは複雑になり過ぎた。WIndowsが10以降のアップバージョンを予定していないと宣言しているのは、マイクロソフト自身が、その複雑さの限界と代償を意識しているからだろう。
Windowsマシンなんて、今後は、２～３万の使い捨てに近いノートPCでいいのかもしれない。
emacsに昔懐かしいw3mをと思っていたが、eww(Emacs 24.4 の新機能・内蔵ブラウザ eww.el を調べてみた - 雑文発散(2014-08-07) )というのがあるそうだ。知らなかった。
