社内イントラネットで動くフロントエンドをたまに手直しすることがあるのですが、役員の方々が見るダッシュボードに ☰ ⋮ ⋯ + みたいなアイコンを入れたら怒られたことがあります。どこそこ機能はどこへ行ったんだと聞かれて、このボタンを押せばいいですと言うと、見えない、普通にテキストで書けと言われて……。結局また元々使っていた2000年代風のインターフェースに戻したことがあります。何でもそうですが、フロントエンドは難しいですね。

タイトルが kills に… ｗｗｗｗ

テスラもリビアンも、結局はどちらも自社チップを作る方向に進むことになるんですね。もちろんこの発表の後、株価は10%も下落しましたが。
リビアンは試乗はできず、ただ座っただけでしたが、作りの良さは本当に感じました。
韓国国内でも2021年にすでに商標と特許の登録はしていたのに、発売の知らせは聞こえてきませんね

ご理解いただきありがとうございます。

黄金の卵を産むガチョウがいると主張する人がいるなら、その卵が本当に黄金なのか、そのガチョウが産んだものなのか、そして黄金の卵の対価として何を受け取るのかを検証できるべきではないかと思います。
私は、ストールマンの「信頼できるコンピューティングのためにはソースにアクセスできなければならない」という主張を、そのようなニュアンスで読んでいます。

最近、中国の組み込みプラットフォームメーカーであるsipeedが発売したnanokvmという製品で、マイクが見つかった事例がありました。
中国製の組み込み製品はセキュリティ的に脆弱だったり、ひいては政府のセキュリティ工作に利用されているのではないかという不安感があるものと理解しています。
そのため、そうした先入観が反映されたのか、最近この製品についてこのような記事も出ていました。 중국산 NanoKVM에서 숨겨진 마이크를 발견한 과정
しかし、sipeedはそのハードウェアからソフトウェア開発までをオープンソースで進めていたため、ちょっとした騒動として誤解を解くことができたのだと思います: https://x.com/lexifdev/status/1999340940805439775

ストールマンの時代には、このような言説において中国政府の代わりに、その位置にいたのはマッカーシズムの影響が残っていた頃の米国政府とNSAだったと理解しています。
陰謀論かと思われていたものの、実在すると判明したNSAのバックドア事例もありますし、printer tracking dots (https://en.wikipedia.org/wiki/Printer_tracking_dots) のようなものもありました。
最近は、政府が関与した陰謀論よりも、広告を主な収益源とする企業がターゲティング広告のためにスマートフォンのマイクを盗聴しているという話のほうが話題ですが。

そしてソフトウェア技術企業では、ソースコードがもちろん大きな役割を果たしますが、全体的な利便性、サービス運用能力、そして信頼のほうがより大きな役割を果たすと思います。
OpenAIのソースコードをすべて手に入れたからといって、後発組が簡単に多数のユーザーを支えられるインフラを安定して確保・運用し、ブランドの信頼に追いつけるわけではないでしょう。
主要プロダクトをオープンソースで運営し、多数のフォークがありながらも主導権を失っていない事例はかなりあります。
すぐに思い浮かぶものだけでも、ChromeやVS Codeのような例があります。
もちろん、主導権を失った例としてElasticやRedisで、AWSが原因でオープンソースライセンスをめぐる事件がありましたが、同様に私は、両社が相対的にAWSの利便性、サービス運用能力、信頼において後れを取っていたために起きたことだと思います。

まあ、こういう話も見方によっては政治的・思想的な話ではあります。なので、個人的な話を付け加えてみます。
本業でソフトウェア開発をし、趣味で組み込みハードウェアをいじる立場からすると、ソースコードや回路図のようなものがないブラックボックス相手では本当に……開発も保守も本当に大変なんですよね。
何らかのソフトウェアライブラリやハードウェアを使って開発しようとするとき、ソースコードや設計図を入手できる、あるいは少なくとも仕様書がきちんと整理されていれば開発は本当に楽ですが、そうでないと本当に頭が痛いです。
最近、海外で「修理する権利」の話がかなりありましたが、その中で印象的だったのは、昔は電子機器のふたを開けると、修理の参考にするため配線図が描かれていたという話です。 （最近はAppleが修理業者に回路図を提供しているとは聞きます）
こうした経験が、その製品群の信頼性の形成に大きく影響するんですよね。最近は、どの技術を選ぶか、どの製品を買うかを考えるとき、これが壊れたり問題が起きたりしたときに、自分が簡単に理解して修理して使えるか、あるいは回避策を講じて使えるかをまず検討します。

その通りです
ストールマンはSaaSも使わないよう主張しています
https://www.gnu.org/philosophy/who-does-that-server-really-serve.html

セラミックっぽい雰囲気ですね。

私の年俸の上昇グラフは、5年間ずっと0%です。

一般化するのは簡単ではないでしょうが、ひとまず経営陣を説得するには最も良いツールであることは確かですね。

他人のサーバーで計算を実行する方式は、ユーザーのコンピューティングの自由を損なうという点で、利用を拒否すべきだということです。

これはLLMだけでなく、すべてのクラウドサービスや外部サービスも拒否しようという主張ではないですか……？ 翻訳が間違っているのでしょうか？

これはかなり前に読んだことがある記事のようですが……改めて自分にとって励みになる文章でしたね。アップロードしてくださってありがとうございます。

言語モデルでコーディングしながら、機械に近い表現を勝手に魔法のように作ってくれると信じるなんて、虫がよすぎますね
制約があるほど、その制約の中でうまく仕事をします

最近は、発表そのものに意味を持たせるにはAIを扱うコツ中心になる気がしますが、発表の本質がだんだん安易になって色あせていく感じがして残念ですね。

仕事を委任することが、どれほど難しいかを改めて実感しました。

そうは言っても、メンテナーが何人も離脱したのではないですか？

ハングル関連の書籍がちょうど1冊出ているのですが、残念ながらLinuxカーネルでのRustの使い方が何度も破壊的変更を経験したせいで、最近のカーネルとは完全には互換性がないようです。GitHubなどを通じて補完されると本当に良いのですが。

AIがコードを書くとしても、サービスに対する責任は開発者が負うべきでしょう。自分で理解できないコードに責任を持てるのか、疑問です。

それでもなお、有意義な測定基準はあると思います。特に、相反する2つの指標の両方に責任を持つ誰かがいるほうが、より効果的だと思います。SREの観点で障害件数を減らせたと喜んでも、その分だけ石橋を叩いて渡るように慎重になってデプロイが遅れ、機能開発が鈍ることもあり得ますし、Devの観点で機能開発をたくさんできたと喜んでも、その分だけ障害発生件数も増えるかもしれないからです。

p99 latency、応答成功率、リクエストあたりのコスト、MTTR、障害発生件数のような指標も、悪用しにくい良い指標だと思います。（もちろん悪用される可能性はあるでしょうが、追跡して管理することのほうが、失うものより得るもののほうが多そうです……）

それなら、そのグラフはおそらく汚染される可能性が高いでしょう。

グッドハートの法則: "測定基準が目標になった瞬間、その測定基準はもはや良い測定基準ではなくなる"

普段から、パーセンテージで成果をアピールするのは無意味だと思っていましたが、この記事がその考えを完成させてくれる気がします。

売上を5パーセント向上させることに貢献、ではなく、どの期間にどれだけ伸ばし、それが自分の貢献前と比べてどれだけ急になったのかを語るべきだと思います

:+1: