かなり前のことなので記憶が曖昧ですが、
「#! とパスの間にはスペースを空けるべき！」
みたいな主張を読んで（実際に著名な方がそういう scripts を書いていたということもあり）、そのように習慣づけていたのですが...

The #! magic - details about the shebang mechanism (下線は引用者による)

Blank after #! required?
There is a rumor, that a very few and very special, earlier Unix versions (particularly 4.2BSD derivatives) require you to separate the "#!" from the following path with a blank.
You may also read, that (allegedly) such a kernel parses "#! /" as a 32-bit (long) magic. But it turns out that it is virtually impossible to find a Unix which actually required this.
...
There is a manpage in a "4.1.snap" snapshot of 4.1BSD on the CSRG CDs, /usr/man/man2/exec.2 (4/1/81), where a space/tab after the #! is mentioned as mandatory. However, this is not true: the source itself remained unchanged.

Blank forbidden?
I found no evidence yet, that there's an implementation which forbids a blank after #!

ということで、根拠の無い噂だったみたい。でも、これによって動かない実装系は無いようなので、まぁいいかという感じです。これから新しく書くモノでは気をつけよう。

Here is a list of some tools that Apple employees are using for their work:

AppleConnect - Single Sign-on and VPN Management
Espresso - Source Code Management
Sonar - Request and Issue Tracking System
Radar - Bug Tracking System
NFA - Apple's New File System

Interestingly, they're all AppleScript compatible :-)

2010-03-03 23:13 JST から 2010-03-04 4:00 JST (推定) までの間、サーバのハードウェア障害により www.kenichimaehashi.com, anison.kenichimaehashi.com, lyrics.kenichimaehashi.com, blog.kenichimaehashi.com 上の全 Web サービスが断続的に停止しておりましたが、現在は復旧しております。ご迷惑をお掛けしました。なお、この期間にお送りいただいたメールには影響ありません。

参考: 障害情報（www.s83.xrea.com）

　＊

障害発生時間は公式発表では 23:30 となっていますが、死活監視システムのログを見ると上記の時間には既にアクセスできない状態だったようです。その後は断続的に up / down を繰り返し、4:00 頃には解消されたと推定されます。サーバの復旧後、全データの保全を行いましたが、特に問題はないようです。近いうちに時間を見つけて、「さくらのレンタルサーバ」への移行をしたいと思います。（これ、1 年くらい前から言っていますが...）

REAL Software: The Compiler: Better, Stronger, Faster

REAL Studio のコンパイラバックエンドが LLVM インフラストラクチャを使用するようになるとのこと。利点として、「ARM を含む数多くのプロセッサに対応できること」「最適化コンパイル・不使用コードの削除によってパフォーマンスの向上が可能になること（最大 10 倍程度）」「オープンソースによる継続的な性能向上に期待できること」などが挙げられています。フロントエンドは変更されないため、移行に伴う作業はほぼ不要で、「コンパイルし直せば、アプリケーションのサイズが小さく、動作が速くなっていることに気づくだろう」と述べられています。なお、メインのアプリケーションコンパイラへ採用される前に、RBScript コントロールが LLVM を使用するように再実装されるようです。

不使用コードの削減とか、やってなかったのか！という感じですが、ARM サポートによって iPhone への道が開けるのは大きいですね。またよく分からない bug が追加されないといいなぁ。

brctl で addif しても、encap:Point-to-Point Protocol なインタフェースは追加できない。
理屈は分かる（Ethernet じゃない）けど、なんだかどうも納得いかない...。

で、解決策としては、ブリッジしたい先のネットワーク範囲をルーティングテーブルに登録（PPP の対向 IP アドレスが next hop）し、そのサブネット全部を Proxy ARP してしまう、というもの。
そこで、昨日書いた Linux の IPv4 Forwarding でサブネット全体に対する Proxy ARP を有効にするというのが必要になってくる。