2011/02/25(金)FreeBSD 8.2R/7.4R リリース

2017/10/12 04:23 サーバ運営・管理
今朝、 AM 5:00 過ぎにアナウンスが入りました。

○ FreeBSD 8.2R リリースノート(勝手な和訳)

- [amd64] FreeBSD/amd64は、物理的な記憶容量より等しいか大きいサイズの KVAスペースの確保をします。 この変更は、ZFSを使用するときしばしば起こる“kmem_map too small”パニックを防ぐのを助けるでしょ う。

- FreeBSD GENERICカーネルは現在、KDBとKDB_TRACEオプションでコンパイルされます。 8.2-RELEASEから、カーネルは、ddb(8)のようにデバッガバックエンドなしで stack(9) を使用することにより、panic時のスタックトレースを表示するのをサポートします。このことが panic時におけるGENERICカーネルのデフォルトの振舞いを変えないことに注意してください。

- FreeBSD の crypto(4) フレームワーク(opencrypto)は、XTS-AES(XEX-TCB-CTS、またはCipherText StealingがあるXEXベースのTweaked Code Bookモード)をサポートしました。(XTS-AESはIEEE Std. 1619-2007 で定義されます)。

- [amd64] FreeBSD/amd64カーネルにおけるXen HVMサポートが改良されました。 その他の詳細に関しては、xen(4)マニュアルページを参照してください。

- FreeBSDは、GPT(GUID Partition Table)を完全にサポートしました。 プライマリヘッダーとプライマリパーティション・テーブルのチェックサムは現在、適切に確かめられます。

- [amd64,i386] aesni(4)ドライバーが新設されました。 これは、インテルCPU上に、AESアクセラレータがあると、crypto(4)のためにAES操作を加速します。

- [amd64,i386] aibs(4)ドライバーが新設されました。 これは、ASUSマザーボードにてハードウェアセンサをサポートし、acpi_aiboost(4)ドライバーの置き換えになります。

- tpm(4)ドライバーに、信頼されるモジュール(トラステッドプラットフォームモジュール) 判定サポートが加えられました。

- xhci(4)ドライバーに、Extensible Host Controller Interface (xHCI) と USB3.0サポートが加えられました。

- FreeBSD Linuxエミュレーションは、video4linux APIをサポートしました。これは multimedia/pwcbsdと、multimedia/webcamdによって提供されたもの等の Linuxネイティブな video4linux ハードウェア・ドライバーを必要とします。

- miibus(4)は、一般的なIEEE802.3 annex 31B full duplexフロー制御サポートのために書き直されました。これに伴い、alc(4)、bge(4)、bce(4)、cas(4)、fxp(4)、gem(4)、jme(4)、msk(4)、nfe(4)、re(4)、stge(4)、およびxl(4) に伴うドライバー atphy(4)、bmtphy(4)、brgphy(4)、e1000phy(4)、gentbi(4)、inphy(4)、ip1000phy(4)、jmphy(4)、nsgphy(4)、nsphyter(4)、およびrgephy(4) をアップデートしました。

- 新しい netgraph(4) に node_ng_patch(4)が新設されます。 これは通り抜けるパケットのデータ変更を実行します。 変更は8、16、32の符号のない整数か64ビットのサイズでC言語操作の部分集合に制限されます。

- FreeBSD TCP reassembly は改良されました。 SMPシステムに影響する長年のバグが解消され、net.inet.tcp.reass.maxqlen sysctl(8)変数が、動的に変わるソケットバッファサイズを示します。 FreeBSDの パケット受信は、現在、接続スループットを向上させる以前より、かなり良好にパケット損失回復(特に待ち行列オーバーフローで引き起こされた損失)を扱います。

- siftr(4)、Statistical情報 For TCP Research(SIFTR)カーネルモジュールは新設されました。 これは、活発なTCP接続におけるさまざまな統計をログファイルに登録する機能です。 それはシステム管理者、開発者、および研究者を対象にした、非常に高度なTCP接続状態の測定をする能力を提供します。

- geli(8) GEOM クラスは、現在、デフォルトでXTS-AESモードを使用します。
- ディスクフォーマットのときに、ZFSを Version 15へアップデートしました。そして、OpenSolaris から ZFSに様々な性能改良を導入しました。

- Userlandサポート dtrace(1) が新設されました。これはuserlandソフトウェア自体の試験とカーネルとの相関関係を許容します。その結果、場面の後ろで先へ進んでいる状況の表示ができます。 dtruss(1)ユーティリティを加えました。そして、この機能をサポートするためにlibprocをアップデートしました。

- gpart(8)ユーティリティは、GPTパーティション・テーブルを回復できるようになりました。

- part(8)ユーティリティは、現在、GPTでGPT_ENT_ATTR_BOOTME、GPT_ENT_ATTR_BOOTONCE、およびGPT_ENT_ATTR_BOOTFAILEDに属性をサポートします。 コマンドラインの属性キーワードは、bootme、bootonceであり、それぞれbootfailedされました。

- libarchiveライブラリと tar(1) ユーティリティは、LZMA(Lempel-Zivマルコフ連鎖アルゴリズム)圧縮形式をサポートしました。

- newsyslog(8)ユーティリティは、デフォルトsyslogd(8) PIDファイルに優越するために -S pidfileオプションをサポートしました。

- newsyslog(8)ユーティリティは、新たに処理ファイル包含のために、特別なログファイル名をサポートします。 ファイル Globbingで、名前検出がサポートされます。 その他の詳細に関しては、newsyslog.conf(5)マニュアルページを参照してください。

- pmcstat(8)ユーティリティは、現在、トップソースとしてファイルとネットワークソケットをサポートします。 これはシステムの上で例えば、ローカルのシンボルなしでTCPの上のトップモニターを許します。

- tftp(1)とtftpd(8)ユーティリティは、より良い相互運用性のために改良されました。そして、それらは、現在、RFC1350、2347、2348、2349、および3617をサポートします。

- periodic スクリプトに zfs関連が加えられました。 その他の詳細に関しては、periodic.conf(5)マニュアルページを参照してください。

- periodic スクリプトに、ミスマッチしているチェックサムでインストールされたポートのファイルを見つけるスクリプトが加えられました。 その他の詳細に関しては、periodic.conf(5)マニュアルページを参照してください。

- sysinstall(8)ユーティリティは、デフォルトと最小のパーティションサイズに、以下の値を使用するようになります: /のための1GB、/varのための4GB、および/tmpのための1GB。

- ACPI-CAを20101013にアップデートしました。
- ee(1) をバージョン1.5.2にアップデートしました。
- ISC BINDをバージョン9.6-ESV-R3にアップデートしました。
- netcatをバージョン4.8にアップデートしました。
- OpenSSLをバージョン0.9.8qにアップデートしました。
- タイムゾーンデータベースをtzdata2010oリリースにアップデートしました。
- xzを2010年4月12日スナップショットから5.0.0リリースにアップデートしました。
- GNOMEデスクトップ環境(x11/gnome2)をバージョン2.32.1にアップデートしました。
- KDEデスクトップ環境(x11/kde4)をバージョン4.5.5にアップデートしました。

○ FreeBSD 7.4R リリースノート(勝手な和訳)

- GNOMEデスクトップ環境(x11/gnome2)をバージョン2.32.1にアップデートしました。
- KDEデスクトップ環境(x11/kde4)をバージョン4.5.5にアップデートしました。
- [sparc64] FreeBSD/sparc64が新たにサポートされました。
- [sparc64] FreeBSD/sparc64は、UltraSPARC IV, IV+, and SPARC64 V CPUをサポートします。
- alc(4)ドライバーは、Atheros AR8151/AR8152 PCIe Gigabit/ファースト・イーサネットコントローラを新たにサポートしました。
- bge(4)ドライバーは、BCM5718 PCI Express x2 デュアルポートギガビットイーサネットコントローラを新たにサポートします。 このファミリーは、BCM5714/BCM5715家の後継であり、IPv4/IPv6チェックサムのVLANハードウェア動作、TSO、タグ付け、ジャンボフレーム、MSI/MSIX、IOV、RSS、およびTSSが機能します。 ドライバーの最新版はIOVとRSS/TSS以外のすべてのハードウェア機能をサポートします。

- fxp(4)ドライバーは、i82550とi82551コントローラのVLAN上でTSOをサポートしました。

- re(4)ドライバーは、RTL810xE/RTL8168/RTL8111 PCIeのために64ビットDMAをサポートしました。

- rl(4)ドライバーは、現在、RTL8139Bか、より新しいコントローラ上でWoLをサポートしました(Wakeup on LAN)。

※詳細は、それぞれのリリースノート参照下さい。
FreeBSD 8.2R 〔英文〕
FreeBSD 7.4R 〔英文〕

2011/01/28(金)iso-2022-jp コード問題の対応まだ

2017/10/12 04:20 はんかくさい
2010/12/20 の記事 にて、iso-2022-jp いわゆる、JIS コードでエンコードされた Webサイトを IE8 で閲覧すると、文字化けするようになったという記事を掲載しました。

当方では、その後の反応はサッパリだが、今日、メンテナンスで IE8 にて動作チェックをしたら、(この間の自動 Windows update は3回くらいあった)文字化けは治らない状況で、やはり別の Web ブラウザ(Firefox とか Chrome あたり)を使ってもらうしかない、という状況。

一応、状況報告が挙がっている模様:
MS10-090 導入後の不具合につきまして〔Internet Explorer ブログ (日本語版)〕
↑ 作りこんだ問題解決をやる気があるんだか、無いんだか、、
「(コンピュータ)ウィルスと同じ」という厳しい意見もあるが、この点はそう言える。

制作者によっては、 iso-2022-jp (JISコード) なんて、使ったこと無いという層もいるようですが、そういう制作者は、ここ数年の新参者が多いでしょうね。
個人的には、結果的に技術教育できていないのねぇ、、なんて思ってしまった。。

昔は、日本語のサイト=iso-2022-jp と決まっていたようなもので、ベテラン層はそれを忠実に守ってきただけの話です。

コンテンツの文字コードを変えるという作業は、一般ユーザには単純な話に思うのでしょうが、想像以上にはるかに煩雑です。
そのコスト払ってくれないと、、です。

2011/01/26(水)今まで見た中では最高記録

2017/10/12 04:19 はんかくさい
 **:**AM  up 971 days,  7:08, 1 user, load averages: 0.00, 0.00, 0.00
 USER TTY FROM LOGIN@ IDLE WHAT
 ******** p0 example.com **:**AM - w

うーむ、、はんかくさいと言うより、「良く連続動作してるなぁ」という感想。
決してσ(^^) が管理しているサーバではありません。
稼動OSが恐ろしく古く、対応出来ないソフトウェアもあるレベル。

*ぱっと見て解らない方へ*
最上行左側は、連続稼動の期間。971 days と7時間8分。

2011/01/17(月)CGI に使う言語

いわゆる、ここではプログラム言語に何を使うか? という話。

日本では、
PHP , Java というのがもてはやされている模様。
ですが、これはちょっとガラパゴス化している可能性が最近出てきた感ありです。
元々当方は、メンテナンスの点で PHP は否定的、 Java は無駄に高性能なハードウェアを要求する点で否定的。

当方的に推奨できるのは Perl です。あと、ruby。C言語や C++,C# もありです。
こう書くと、嘲笑の対象なんですな、、しかしです。嘲笑するような奴らは、はっきり言ってITゼネコンに洗脳されています。

Java は、ITゼネコンのひとつである、富士通が主に推進し、ごり押ししました。
それが実体。資金力に任せてAPIを提供してきたので、そこそこ使えるのでしょう。
しかし、無駄にハードウェアを高性能化することを要求されるため、ハードウェアの売り上げに繋がる、という商業的な理由があります。
だから、当方はそういうのは承服できないのです。

PHP は、バージョンアップの度に、過去の互換性検証を強要されます。
これだけでもうメンテナンス性がダメダメです。
作りっぱなしなら問題ないけれど、ここでも「互換性検証」という名目で売り上げ増や維持に繋がる、という商業的理由があります。
PHP もITゼネコンが半ばごり押しした言語。

一方で、Perl は10年前に作成したものであっても、セキュリティ問題等さえなければ、何の問題もなく、さくっと動作するのです。こういうのを「後方互換性が優れている」と評価します。Windows で言えば、 Windows 95 の時代に作ったアプリケーションが、Windows 7 や Windows XP でも何の問題もなく、さくっと動作するという感じです。

ruby 、C++、C# なんかも、そんな傾向です。
perl であれば、商業的なことで、無駄なことしなくて済むのです。
だから、米国やインドなどの日本以外の国では、Perl や ruby が見直されてきています。

だが、商業的には都合が悪いかもしれません。
日本のITゼネコン達は Perl や ruby を使うことは否定的です。

若干話題から脱線しますが、「フレームワーク」というプログラム制作上の枠組みを設けることが、均質で質のよいプログラムを作る礎と思い込んでいる勘違いマネージャーもおり、ますます日本のソフトウェア産業 の未来は懐疑的です。

無駄削減を従業員に強要する企業が、顧客に無駄を強要しているのです。
システム開発は、ウチのような中小の方がいい仕事できます。
ただ、ITゼネコンの下請け会社のようなところは避けましょう。

弊社は、ITゼネコンの下請けはしていません。下請けになれば、技術者は育たない。それが体感として判っているからです。
だから、最初からプロジェクトを任された場合に限るのですが、ある程度の能力的自信はあります。

2011/01/06(木)HTML5対応状況

2017/10/12 04:15 雑多なトピック
毎年の事だが、虚礼廃止(虚礼省略というべきか・・)ということで、、

これまた毎回の事で散々他サイトで既出だが、自分メモということで。
まだ正式に仕様確定したという話しを聞いておらず、実装先行状態だが、、

http://findmebyip.com/litmus/

数ある HTML5 対応状況紹介サイトの中では、最も客観的なので、多くの紹介がある模様。
やはり目立つのは、IEの対応の低さ。

IE7 まで「俺様ブラウザ」路線で結果的に当方を含め、制作者が駆逐したいブラウザに異口同音に必ず挙がるのが今の Internet Explorer であり、、

数年後、HTML5 でまた悩むのかな。既に HTML5 への移行が制作サイドで起きており、このままの流れだと、IE専用に HTML4 で制作しなければならない時代が来る可能性がやや高い。

2010/12/20(月)原因は M$社なのに、、、

12/16 頃から IE7/IE8 で文字化けするとの連絡が、、
当初、原因判らず、挙句の果てには、当方が同時期に提供したシステム更新のせいでは?

との話しもあったが、原因は、Windows Update によって、IEでiso-2022-jp (JISコード) な文字コードが判別出来なくなったもの。
参考資料→ [MS10-090] Internet Explorer 用の累積的なセキュリティ更新プログラム

なので、 12/15 以降公開の Windows Update を行い、IE にて iso-2022-jp なサイトを閲覧しようとしたときのみ文字化けが発生するわけです。
弊社サイトは、この条件で見事に文字化けするようになりました、、
Firefox や Chrome では、この問題は起きません。

本来、サーバサイドにて対応すべき問題ではありません。
しかし、IE ユーザ層は自力解決困難なユーザ層が大半なので、完全に無視するわけにもいきません。

結局、兼ねてから予定していた弊社サイトの UTF-8 化を前倒しでやってしまいました。
損害賠償をM$社からもらえるわけではありません。
しかし、損害を被っています。

尖閣諸島近海で、中国籍の漁船が海上保安庁の巡視船に意図的体当たりして明らかな「公務執行妨害」なのに無罪放免され、その様子を撮影した動画を政府の意図に反して公開した公務員が罪に問われるということに 似ています。

ユーザサイドに立てばかなり大きな問題ですが、殆ど騒がれませんでした。
ここからして、思考回路の何かが変だ。

権力か覇権あれば、何やっても許されるんですか。おかしな社会だ。

2010/11/27(土)真冬並み寒気流入



この時期に0℃前後まで気温が下がるのは、珍しくなく、むしろごく普通の状態だったりしますが、今までが平年よりかなり高めで推移してきたので、ちょっと堪えます。

また、この時期の北海道は空から降ってくるものが、雨になったり、雪になったりで、冬支度のタイミングに悩むのが常。
当方は 11/25 に自動車のタイヤ交換して、冬支度を始めました。

2010/11/25(木)javascript なクロスフェード表示

表示が切り替わるときに、新旧の内容が交差するような感じでゆっくりと切り替わるようなものを「クロスフェード表示」といいます。
音楽でも曲が入れ替わる時に使う常套手法です。

散々既出ですが、メモ代わりということで、、
提供時期は少し古いですが、最新のIE8,Firefox 3.6,Chrome で動作確認しました。

先ず、クロスフェード Javascript をダウンロード し、Webサーバにアップロード。

次に、対象がある HTML ファイルに以下の一文を <head> - </head> の間に追記。
<script type="text/javascript" src="bsn.Crossfader.js"></script>


次に、実際にクロスフェードさせたい内容を記述。
<span id="disp1">文字列1</span>
<span id="disp2">文字列2</span>
<span id="disp3">文字列3</span>

<div> 要素を使う説明が多いらしいですが、id 属性が付与できる要素であれば、何でもいいようです。
最後に、上記記述を行った直後の位置に、以下のような記述を行います。
<script type="text/javascript">
var cf = new Crossfader( new Array('disp1' , 'disp2' , 'disp3'), 1800, 4500 );
</script>


外部ファイルにしても良いです。
最後の2つの数値はフェードエフェクトの時間と、要素の表示時間の設定です。
この例だと、
* フェードエフェクトの時間 : 1800ms
* 各要素の表示時間 : 4500ms

のようになります。
まぁ、特定の要素だけ長く表示するようなことは、スクリプト改造でもしないと出来ません。あとはお好みで。

2010/11/13(土)ハングル文字(韓国語)の入力方法

2017/10/12 04:11 雑多なトピック
技術調査の過程で必要になったので、ちょっとだけ調査を。

提起の件、WindowsXP SP3 であれば、韓国語 IME を追加インストールするだけで可能です。
ただ、日本で広く普及しているローマ字入力はできません。

日本でいうところの、カナ入力に類似した入力が主流の模様。
母音と子音でキーが割り付けられており、その組み合わせで文字を確定するようです。

それはそれでいいのですが、驚いたことに、どうも統一された規格というものが無いらしい。
韓国ですら3つの規格らしきものがあり、北朝鮮と中国の朝鮮族が使っている規格とあわせて、異なる規格が5つ。

日本人から見ると、ローマ字入力できるのが一番とっつきやすい。
だが、韓国ではローマ字入力はどちらかというと、マイナーな入力方法らしい。

個人的には韓国語IMEなんぞ殆ど使う機会無いので、とりあえず差し迫った課題では無いですが :-)

当方の知人に韓国語のローマ字入力ツール(?)を試験的に作った人がいるので、ご入用の方は当方に問い合わせてください。