「樹の根本近くに新しい小さな枝を見つけた気がします」くらいで

こんな感じかな

RGB = ★○●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●

★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●
★★○○●● ★★○○●●

RGBW = ★○●□
★★★○○○ ●●●□□□
★★★○○○ ●●●□□□
★★★○○○ ●●●□□□
★★★○○○ ●●●□□□
★★★○○○ ●●●□□□
★★★○○○ ●●●□□□

●●●□□□ ★★★○○○
●●●□□□ ★★★○○○
●●●□□□ ★★★○○○
●●●□□□ ★★★○○○
●●●□□□ ★★★○○○
●●●□□□ ★★★○○○

両者を比べると
・白黒解像度に影響する G,W の画素数は同じピッチなので 300 dpi ある
・色解像度に影響する R,B の画素数は半分しかないので 150 dpi しかない

人間の目の白黒の解像度と色彩の解像度は元々異っていて、白黒の解像度は高いけど、
色の解像度はかなり低いので実用上問題無しかな。

ここは発想を変えましょう。

どうせ普通の人は地方時(localtime）などという適当なもので生活しているので、その辺をいじるのが良さそうです。UTCとTAIの間はズラさずに、地方ごとの時差をずらすんです。例えば日本標準時だと UTC+9時間 から、UTC+32401秒とかにするとか。
これで閏秒無しでも、生活時間とのズレは最小で済みます。

# 閏秒の挿入の手間に比べれば地方時の変更の手間は少ない...と思う。

# 何千年もたつと日付け変更線を移動させる必要が出てくる可能性がありますが :-)

> POP3ですと、USER, PASS, STAT, LIST, RETR, DELEの順番にリクエストしていくわけですが、
> RETRを送った後にOK+Octets数のステータスを受信するまでに次のRETRを発行しても問題なく
> 動作するものなのでしょうか?

昔 POP3 server の実装やりました。

これは POP3 server と client の実装によります。
規格的に言うと POP3 server と POP3 client の両方が PIPELINING capability を実装している場合には上記動作が可能になります。(cf. RFC2449)
ということで規格の方はずっと昔に既に拡張済み。

# それよりも(世の中にあふれている?)行バッファリングでパケットを送る駄目 POP3 server の方が本当の問題だと思う

- GFDL の対象は著作物なので一体として配布された図形その他にも GFDL が適用される
- GFDL で改変不可を指定できるのはあくまで追補部分(appendix or a front-matter section)だけなので本文中の図案に改変不可を指定することはできない
- 原著作者はデュアルライセンスで配布することができるので、一方で独占的な配布をしながら、他方で GFDL で配布するこができる。(もちろん GFDL で配布したものに関しては配布や改変を制限することはできない)
- もちろん他人の独占的な著作物を無断で GFDL の文書に混ぜるのはそれ以前の問題

という風に理解しているのだが、今回の件に関してはどうでしょうね。

この手の問題で考えなければならないのは、
    1. (将来有償化する予定を明示せずに)無償でソフトウェアやサービスを配布する
    2. 広く使われ、利用者が慣れるのを待つ
    3. 突然有料にする
    4. 乗り換えにコストがかかることを嫌う人たちからお金を集める
というビジネスモデルが許されるかどうかでしょうね。

個人的には許されても良いか(騙されるやつが悪い)とも思うけど、
消費者保護とか社会的なコストを考えると好ましくないかもしれない。

プロトコルを調べてもらうと気付くかもしれないけど、CRAM-MD5 とかはサーバ側に
生パスワードを保存しなくても良い設計になっています。一方で古い設計の APOPと
か CHAPとかがサーバ側に生パスーワドを要求するので難しいのですが...

細かい点だけど 3.f) は普通は
3.f) link("~/.kde/foo/bar/baz", "~/.kde/foo/bar/baz~") --- this is optional
とするのが常識じゃないかな？ 3.f) と 3.g) の間に割込まれる可能性も考慮しないと！

どこか別の場所で事前にロックとって排他しているのでない場合には、3.b) の
O_TRUNC とかも論外な気がする。NFS まで考えると気休めけど O_EXCL くらいは
つけときたい所。

C/C++ 言語に constant 修飾子と同様に nonnull 修飾子があると便利だと前から思ってたんだけど、どうだろ？

nonnull ポインタ変数は初期化必須で、NULL やnonull修飾子無しのポインタからの代入できないくらいで。

個人間の同意があれば今でも別に UTF-8 を使っても問題ないですよ。そうでなければ単なる迷惑メールですね。

現状で既存の ISO-2022-JP と Unicode/UTF-8 との間の変換表が OSごと(MS-Windows,Macintosh,Linux)でばらばらな状態で UTF-8 のメールを許すというのは有りえないでしょう。

メールのセキュリティ(サインとか、スパム対策)を考えると正常に使っていても文字化けするような状況を導入するのは欠点のほうが多過ぎですよね。

本気で UTF-8 メールを主流にするなら、UTF-8 と ISO-2022-JP との一意な変換表を RFC か何かで規定することから始める必要があるのではないでしょうか。