Google Reader: Googleがほとんどメンテナンスいらないものを潰したのは、ずっと恨んでる。10年間そのままでいても全然気にしなかったのに、RSSリーダーは2015年と同じ使い方してたからね。

Chromecast Audioはまだ使えるよ！ただ、もう売ってないけど。私は毎日使ってるし、誰かが売ってるのをずっと探してる…。

Google Search: まだ正式には死んでないけど…。

Googleマップがもう私の位置情報を追跡してくれないのがまだ残念だな。どれくらいの頻度で、どこに行ったかを振り返るのがすごく便利だったのに。ローカルで保存できる別のアプリってないかな？

Googleノートブックを廃止して、数年後にほぼ同じ機能を持つGoogle Keepを作ったことに、今でも笑っちゃう。

Google Play Music: そこに何千ものMP3ファイルをアップロードしてたんだけど、サービス終了しちゃったんだよね。もう二度とアップロードする時間を無駄にしたくない。GPMと同じくらい良いかどうかは議論の余地があるけど、GoogleがYouTube Musicに移行したからって、アップロードした音楽が消えたってのは間違いだよ。俺は移行したけど、音楽は新しくアップロードすることなく全部移ったからね。

今でもPICASA使ってるけど、全然問題ないよ。ただ、GoogleがGdriveと写真のリンクを切ったせいで、写真が自動でPCにダウンロードされなくなったんだ。これが俺にとってのGoogleの終わりだった。

Picasaはすごかったよ。他のほとんどのものよりもずっと前に顔認識機能があったし、オフラインで使えるパッケージも良かった。残念ながら、最後の公開バージョンには顔タグがランダムに入れ替わるバグがあって、間違った人の顔でトレーニングしちゃうから、家族の写真が何千枚もあっても認識がほとんど役に立たなくなっちゃった。8( Digikamは代替品としては微妙で、なんとか仕事をこなす程度だね。

Google G Suiteは、最初は終了すると言ってたのに、無料オプションを提供したよ。今、Workspaceアカウントにログインしたところだよ： https://ibb.co/99jBLJnD まだたくさんのドメインがあって、全部Gmail使ってる。

Google Chromecast: え、Chromecastが終わったの？これを書くまで知らなかったよ…今はGoogle TV Streamerっていうのがあるから、個人的には製品を本当に終わらせたというより、リブランドしたって感じだね。

Waveはマジで最高だった。バグもあったけど、素晴らしかった。

Discordは機能的には今一番だね…。

デモを見たときは衝撃的だったけど、考えたら悪夢に思えてきた。スラックの問題、つまり手動でチャンネルをチェックしなきゃいけないのが100倍になった感じ。ああ、スラックがその時はなかったのは分かってるけど、ネストされた常に更新される階層スレッドについていくのは無理そうだった。スラックのチャンネルを追うのも大変なのに、もしウェーブが成功してたらもっとひどかっただろうね。

Nextcloud（Nextcloud Talkも含む）は、十分な代替手段じゃない？ 確かに、Discordみたいな中央集権的でクローズドソースなものは違うけど。

これを真っ先に思い出した。ウェーブの薄めたバージョンでも、私のホストスタートアップで使ってたし、実質的にはプロジェクト管理ツールだった。それは素晴らしかったよ。今の選択肢と比べるとどうだったかは分からないけど、当時はそれが終了したのは大きな損失だった。

このバージョンのWaveの動画とかある？

Google Waveは素晴らしい技術基盤の上に作られてたのに、ユーザーインターフェースが完全にダメだったよね。みんなが同時に編集できる一つのドキュメントとして扱うんじゃなくて、別々のアイテムのセットとして扱うことにしたから、台無しになった。余計に複雑に見えちゃって、良いところが全部消えちゃった。

Google Waveは時代を先取りしすぎてた。

Google Waveは素晴らしい技術を持ってたけど、デモを振り返ると、あんまり良い製品じゃなかったって分かる。オールインワンの製品を作ろうとしたけど、それはうまくいかなかったんだよね。ある意味、Waveはまだ存在してるけど、いくつかの製品に分かれたから「死んだ」とは言えないかな。その技術は今でもGoogleの人気製品に使われてるし、目的ごとに別々のインターフェースを持つ方が、オールインワンよりもユーザーフレンドリーだってことが分かったんだ。

友達と一緒に旅行を計画してたんだけど、それがドキュメントやリンクを含むアドホックなディスカッションにはすごく良かったんだ。これが未来だと思ってたし、プログラミング始めたばかりの頃には、サーバー管理用の超セキュリティが甘いプラグインを作ったこともあるよ。https://github.com/shano/Wave-ServerAdmin もう16年経ったんだね。そろそろアーカイブしないと。

使ったことはないけど、Yahoo Pipesについて話してるのを聞くと、すごく良かったんだろうなって思う。Yahoo Pipesが死んだのか、オープンプロトコルとスタンダードに基づく主流のインターネットが死んだのかは分からないけど。

Yahoo Pipesは、インターネットがあるべき姿だった。コンピュータの歴史が数十年経っても、その種のツール間リンクはユニックスのパイプにしかほとんど匹敵してない。

誰か時間とお金、リソースがある人がYahoo! Pipesのアイデアを復活させたいなら、Node-REDを良いスタートポイントとして使うことを勧めるよ。オープンソースで、定義された安定したAPIとしっかりしたバックエンドがあるのが利点だし、視覚的にフローベースのプログラミングを実装するための学びが10年以上あるからね。Node-REDのフロントエンドを使ってBrowser-Redを作ったんだけど、これはサーバーなしでブラウザ内だけで動くNode-REDなんだ。Node-REDの全機能をサポートしているわけじゃないけど、Node-REDとフローベースのプログラミングを使う感覚は掴めるよ。もう一つのプロジェクトはErlang-Redで、Erlangバックエンドを持つNode-REDなんだ。ErlangはNodeJSよりもフローベースのプログラミングに向いているから、この試みを示そうとしてるんだ！Node-REDはYahoo! Pipesとは少し違う前提を持っていて、入力ポートが最大の違いだね。Node-REDのノードは入力ワイヤーが0か1しかないけど、Yahoo! Pipesのノードは複数の入力ワイヤーがあった。jQueryの良い知識が必要だけど、それがフロントエンドコードに入るのを簡単にすると思うよ ;) Node-REDに関する質問があれば、メールはプロフィールに書いてあるから気軽にどうぞ。

Pipesが大好きだった。コンテンツを共有していたサイトからのRSSフィードを集めて、Pipesで一つのRSSフィードにフォーマットしてPHPブログに取り込んでたんだ。でも、投稿していたサイトが一つずつRSSをサポートしなくなって、最終的にPipesも終了しちゃった。しばらくは、Pipesと同じことを視覚エディタなしでやるPythonライブラリのrikoを使ってた。これのおかげでPHPからPythonに移行できたんだ。 https://github.com/nerevu/riko

Yahoo Pipesがすごく懐かしくて、最近自分用に似たようなものを作ったんだ :) 代わりになるものはいくつかあるけど、自分の欲求を満たしたくてね。 https://www.mashups.io

同じようなデータ統合パイプラインやエージェントワークフローにはApache Camel（https://camel.apache.org）をおすすめするよ。今ではCamel用のビジュアルエディタもあって、パイプラインをすごく簡単に素早く作れると思う。Apache Karavan: https://karavan.space/ Kaoto（Red Hat）: https://kaoto.io どちらもvscode内でエンドツーエンドで使えるよ。

Pipesの歴史については、https://retool.com/pipesを読むことを絶対におすすめするよ。そこに関わった人たちの意見がたくさん載ってるから（特にモバイルでは分かりにくいけど、サイトを見たら下にスクロールして内容を見てみて）。

オプテインドライブにカーネル入れてるから、即ブートだよ！

3D XPointには賛成！この技術が成熟するのに数十年かかったけど、ビジネスの人たちはその革命的な技術が世の中に追いつくのを待つ忍耐がなかったんだよね。

Optaneは技術的にはすごかったね。RAMとディスクメモリの分断をなくして、両方を一つのスティックで使えるようになるところだったんだ！

値段だけの問題じゃないよ。'エコシステム'のインフラが整ってなかったし、広がりも足りなかった。'マインドシェア'や、どうやってやるかの考え方も同様。これは初期のLispやSmalltalkのような（ライブ）'イメージベース'の作業環境に近いね。今の彼らの状況を見てみて… それについてもう少し考えがあるんだけど、実際にそのファームウェアでシステムレベルのサポートがあった最後のシステムを持ってるし、そういう用途向けに設計された初期の低容量オプターヌもあるからね。遊ぶのは面白いけど、容量が少なくて、古いOSに縛られてる。十分なRAMがあれば、RAMへのサスペンドとレジュームができるからエミュレートできるよ。もう一つの選択肢は、ますます速くて大容量のSSD。実際には、いくつかのモデルではほとんど違いがなくなってきてるし、ランダムアクセスの時間がすごく速くて、転送速度も異常だからね。もしかしたら、総TBWや日々のTBWは気になるかも。これらは組み合わせることもできるよ。

システムはストレージのモデルが古いままで、RAMでもディスクでもないものに対応できてなかったんだ。でも、Optaneはしばらくの間、いくつかの研究プロジェクトにインスピレーションを与えたよ。特にサーバー分野ではいくつかのアプリケーションが登場したね。

• XHTML。HTML5のパースルールを読んだことある？悪いHTMLのセマンティクスが正式化されてるんだ。ブラウザは最初のエラーで投げ出して、エラーメッセージを表示して、残りのページをTimes Romanでレンダリングすべきだよ。タグをちゃんと閉じるのがそんなに難しいか？アーメン。ポステルの法則は間違ってた。https://datatracker.ietf.org/doc/html/rfc9413 ほとんどの他のフォーマットでは、問題の兆候が見えたらすぐにやめるのに、HTMLには緩いパースが必要ない。これが多くのセキュリティ脆弱性を引き起こして、ほとんどの人にとってさらに難しくなってる。HTML5のパースに対する態度は、インターネットエクスプローラーよりも良いことをしようとする人たちが頭の中で雲の中にいるという変な逆張りから生まれたように思えるし、標準の役割はバグをすべて書き留めることだけだった。

いいリストだね。いくつかの考えを： - NeXTに移行しなかったら、たとえジョブズがAppleに戻ってきても、iPhoneにはたどり着けなかったと思う。iOSは、UnixライクなOSで、Unixライクな哲学を使っていて、その哲学が当時のモバイルOS技術の最前線と比べて、ゲームチェンジングなものを作るのを可能にしたと思う。Androidもそれに続いてるし。コマンドラインがないし、インストールも問題ないから、君の論理はあまり強くないかも。ただ、君が指摘してるかもしれないことは、見逃されてるポイントだと思う：今日のmacOSは、iOSやiPadOSがやらざるを得ないことから少し学んで、設定を一箇所に集中させるべきだと思う。 - トランザクション処理オペレーティングシステムは、今日では「サーバーレス」として再発明されたと思う。君が説明したロード/実行/終了のサイクルは、AWS LambdaやGCP Cloud Run Functions、Azure Functionsを構築する方法だよ。 - 君の他のアイデアのほとんど（例外もあるけど、下で見てね）は、クールな技術を作るのではなくお金を掴もうとした人たちのせいで死んでしまったし、自由市場が足で投票したと言えるかも。次にハードウェアアーキテクチャに大きな変化があるのはいつだろうね。今は「x86」と「ARM」だけで、それが次世代の全てって感じがする。 - XHTMLは、人々が物事を進めるのが難しすぎたから死んだ。HTML仕様の寛容な性質は機能であってバグじゃない。ウェブに公開するために人々が仕様を読む専門家であることを期待すべきじゃないし、ウェブをゲートキープする特別なソフトウェアも必要ない。技術は人々に役立つものであるべきで、私たちは人々が技術に仕えることを望んでないんだ。

タグをちゃんと閉じるのがそんなに難しいことなのかな？多分、そんなことはないけど、ページが表示されないことが増えるメリットって何だろう？もしxhtmlがxhtmlモードでしか動かないクールな機能と組み合わされていたら、成功したかもしれないけど、単体ではあまり価値がないよね。

タグをちゃんと閉じるのがそんなに難しいことなのかな？多分、そんなことはないけど、ページが表示されないことが増えるメリットって何だろう？もしxhtmlがxhtmlモードでしか動かないクールな機能と組み合わされていたら、成功したかもしれないけど、単体ではあまり価値がないよね。

Modula。Modula 2と3は結構良い言語だったけど、Oberonは失敗だったね。DECはModulaに注力してたけど、ModulaはDECと共に消えた。Modulaのデザインが好きなら、Nimを見てみて。[1] https://nim-lang.org [2] https://en.wikipedia.org/wiki/Modula-3

• XHTML. [...] タグをちゃんと閉じるのがそんなに難しいのかな？XHTMLは、物事には厳格に正しいやり方があるべきだという直感に訴えるけど、広く共有されるウェブドキュメントにはその厳しいフレームワークは使えないよ。「現実の世界」には2種類のファイル形式がある：(1) 消費者が著者に連絡できない/制御できない/罰することができないファイルタイプ（オープンループ）：HTML、pdf、zip、csvなど。共通のテーマは、データ自体がファイル形式よりも重要だってこと。だからAdobe ReaderはバグのあるPDFライブラリが書いた不正なPDFファイルも読めるんだ。7-ZipやWinrarも壊れたヘッダーの不正なzipファイルを読めるし（古いバグのあるJavaライブラリが悪いzipファイルを書いたから）、MS Excelも不正なcsvファイルをインポートできる。例えば、シティバンクのcsvエクスポートは不正なファイルを書いたけど、ドルの生データがcsvファイルの間違ったカンマより重要だから、MS Excelがそれをインポートするのが望ましかったんだ。で、シティのプログラマーに連絡して、バグのあるコードを直してもらう方法もないしね。(2) 消費者が著者を制御できるファイルタイプ（クローズドループ）：.cや.javaのようなプログラミング言語のソースコードや、EDIのようなビジネスインターチェンジドキュメント。".c"ソースコードを解析するために「寛容なgcc/clangコンパイラ」が必要ないのは、消費者と著者が同じ人だから。つまり、開発者はコンパイラが構文エラーで止まるのを見て、修正して再コンパイルを試みる。EDIのようなビジネスインターチェンジフォーマットでは、ウォルマートのような会社がベンダーに壊れたEDIファイルを直すように言える。XHTMLはグループ(2)に入りたいけど、ウェブサーフィンする人たちは.htmlの著者を全員制御できないから、HTMLの「寛容な解析」が勝ってしまう。XHTMLは、会社が社員向けの内部文書を書くような「クローズドループ」環境でうまく機能するだろうね。例えば、社員ハンドブックは厳密なXHTMLで書ける。なぜなら、消費者と著者が同じ会社で働いているから。例えば、XHTMLの構文が間違っているから休暇ポリシーが見れない？！Slackチャンネルに入って、プログラマーかコンテンツ著者に直してもらうように言えばいい。

MacOS 8。Linuxのやつじゃなくて、Copelandのこと。これはオリジナルのMacOSを現代化したもので、コマンドラインなしの伝統を引き継いでた。コマンドラインがないと、みんながインストールや設定をどうするか真剣に考えなきゃいけなくなる。たぶん、モバイルへの移行も楽になっただろう。実際に開発者に出荷されたバージョンもあったけど、AppleがSteve Jobsを迎えるためにNextを救済する理由を正当化するために隠さなきゃいけなかった。君は逆に考えてる。Coplandプロジェクトはひどく管理がずさんだった。Appleの新技術を考えた人は、機能の肥大化や安定性を無視してCoplandに組み込まれてしまった。プロジェクトがキャンセルされる直前に流出したビルドがあって、それは非常に不安定で、基本的なデスクトップ機能を使うだけでもハングやクラッシュが起きた。1996年の中頃から後半にかけて、Coplandは決して出荷されないことが明らかになり、Appleは外部OSのライセンスを取得するのが最善の策だと判断した。SolarisやWindows NT、BeOSなどの選択肢を考えたけど、結局NeXTを買うことになった。CoplandはNeXTを買うために殺されたわけじゃなくて、Coplandが出荷できないからNeXTを買ったんだ。

昔はXHTMLに夢中だったけど、広告やアプリの他の部分で閉じてないタグがあると、ページ全体が崩れちゃうことに気づいてからは冷めちゃった。ユーザーは巨大なエラーメッセージしか見えないし、残りのページをTimes New Romanで表示するなんて選択肢もないしね。HTMLのセマンティクスを維持しようとする？それともただのプレーンテキストで表示するだけ？プレーンテキストなら意味がないよ。セマンティクスを持った何かを表示するなら、解析方法を知っておく必要がある。結局、最初の状態に戻っちゃうんだよね。確かに、自分のコードが有効なXHTMLであることは確認できるけど、私は超几帳面な自閉症の変わり者だから、他の人はそうじゃないし。XHTMLが「理にかなっている」とは言っても、現実では全然使えなかった。ほとんどの人がズボラだからね。時には、悪い方が良いこともある。

• XHTML。HTML 5の解析ルールを読んだことある？悪いHTMLのセマンティクスが正式に定義されてるんだ。ブラウザは最初のエラーで投げ出して、エラーメッセージを表示して、残りのページをTimes Romanで表示すればいいと思う。タグをちゃんと閉じるのがそんなに難しい？個人的には、XHTMLは生成された出力フォーマットとしては必要だと思うけど、HTML自体は書きやすくて軽量なマークアップフォーマットであるべきだと思う。特にタグの省略に関しては、テキストを書いてるときにやがいっぱい見えるのは嫌なんだよね。視覚的にうるさいし、軽量なマークアップが欲しい。

IBM MicroChannel。初期のミニコンピュータやマイクロコンピュータの設計者たちは、「バス」を考えていて、周辺機器がメモリと通信できて、周辺機器がCPUにとってメモリのように見えるというものだった。でもメインフレームは「チャネル」を持っていて、周辺機器をCPUに接続するシンプルなプロセッサーだった。今日学んだこと：マイクロチャネルの「マイクロ」と「チャネル」の意味。OSに依存しないデバイスクラスドライバーもあったし、新しいCPUをカードに詰め込んでそのまま差し込むこともできた。286+2MBから486dx2+32MBにアップグレードしたんだ。

あのツールは素晴らしかったけど、フォーマットとしてはパフォーマンスが悪くてセキュリティホールも多かったから最悪だったね。Macromedia Fireworksがまだ恋しいよ。

そうだね。自分はFlashを使ったことはないけど、みんなが作った小さなゲームが大好きだった。非開発者たちがいろんな小さなゲームを作ってたシーンがあったけど、それがもうなくなっちゃったね。

もしAdobeがちゃんと対策してセキュリティホールを直してたとしても、Appleは結局潰してたと思う。人気のデザインツールとして常に脅威だったからね。それに、数十年後、HTMLキャンバスのブームが去った今でも、Adobe Flashができたことの代わりはまだないよ。どんなデザイナーでも、月額サブスクリプションなしで、どのウェブサイトにも埋め込める素晴らしいインタラクティブデザインを作れたのに。

個人的な愚痴だけど、今でもGIFを作る人間としては、Image Readyが懐かしい。AdobeがImage ReadyをPhotoshopに吸収しちゃって、シンプルなGIFを作るのがあんなに簡単だったのに、今は全然そうじゃないんだよね。

初心者でもゲームを作れるようにするのは素晴らしかったし、その結果、ゲーム業界全体が新しいアイデアの注入で恩恵を受けたと思う。新しい視点でゲームを作るインディー開発者がたくさん出てきたし、今思いつくのはZachtronicsのような例だね。一方で、フラッシュゲームが作られるたびに、約1万本のフラッシュ広告があって、基本的なナビゲーションにフラッシュを使っているウェブサイトもほぼ同じくらいあった。数年間、ウェブサイトを持つレストランはすべてフラッシュを使っていて、最良の場合でも使い物にならない結果になってた。フラッシュが支配していた間は、ブラウザに適切なビデオサポートを入れる需要が抑えられていたことも忘れないで。フラッシュベースのビデオプレーヤーはクソみたいな性能で、Linuxでの生活は本当に面倒だった。

Godotはめっちゃすごい。学ぶのも簡単だし、2Dも3Dもできるし、HTML5/webasmにエクスポートできて、主要なOSやブラウザ、モバイルでも動く。完璧ではないけど、ゲームじゃないことでも楽しんで使ってるし、ここ1、2年でかなり進化した感じ。今まさにBlenderのような瞬間が近い気がする。

Flashは90年代から2000年代初頭のHyperCardみたいなもんだった。まだ代わりは出てないね。

Flashはもっと早く死んでほしかった。ウェブの疫病だったし、ズームもできないし、テキストを選択もできないし、戻ることもできない。ただの黒い箱で、ウェブブラウザのことを無視してた。これを終わらせたのは、Jobsがやった中で一番良いことだと思う。

Ricochetモデムが大好きだったなぁ。パロアルトのカフェでApple Powerbookと第2世代のRicochetモデムを使って、56kでウェブブラウジングやsshセッションを楽しんでた頃、Wi-Fiなんて一般には知られてなかった。今でもどこかに箱に入れてあるのがあって、スター・モードにできるか試してみたい気分。

リコシェットはめっちゃクールだったよね。時代を先取りしてた。ジョエルのブログにも記事があるよね。

わあ、これ忘れてた！当時としては驚くほど良かったよね。どうやら私は彼らの4人の顧客の一人でもあったみたい！

他のUnix系システムが「すべてはファイル」という哲学を採用するのを何が妨げてるの？

Plan 9ファイルシステムプロトコルはWSL2の中で生き続けてるよ。

Plan 9が早く消えた理由は、Unixとは違って、ハードウェアメーカーが安くライセンスを取得して自分たちのハードウェアに適応できる（たくさんのUnixソフトウェアとの互換性も保証される）のに対して、ベル研究所はPlan 9を商業ソフトウェアとして350ドルで売ろうとしたからだと思う。 （過去に何度も書いたけどね: https://news.ycombinator.com/item?id=22412539>, https://news.ycombinator.com/item?id=33937087>, https://news.ycombinator.com/item?id=43641480>）

今はスマホがこれやってるんじゃない？Lytroカメラのこと、すごくワクワクしたのを覚えてる。

残念ながら、プロの写真家に必要な画質にはまだ達していなかったみたい。ずっと気になってたんだけど、異なる焦点深度でピクセルをインターリーブする仕組みだから、単一平面フォーカスのカメラでは得られない解像度のトレードオフが常にあるんだよね。でも、すごくクールなアイデアだし、センサーとマイクロレンズアレイを組み合わせるのと同じくらい製造は難しくないはず。