[obsidian] vault backup: 2026-01-12 09:11:36[

content/Python.md

@@ -0,0 +1,4 @@
+---
+date: 2026-01-12 08:24
+---
+#stub

content/Zooko Triangle.md

@@ -0,0 +1,14 @@
+---
+date: 2026-01-12 08:53
+---
+#notion 
+
+[[パッケージマネージャー]]を分散型設計にするときに問題になること。
+
+> - **Human-meaningful**: short, memorable names like `express` or `rails`
+> - **Decentralized**: no central authority controls who gets what name
+> - **Secure**: when you ask for `express`, you get the real one, not a malicious package that happens to share the name
+
+これら3つを全て同時に達成することは不可能であるというジレンマ。
+
+[Federated Package Management and the Zooko Triangle | Andrew Nesbitt](https://nesbitt.io/2025/12/21/federated-package-management.html)

content/uv.md

@@ -1,5 +1,5 @@
 
 [[Rust]]で書かれた[[Python]]向けパッケージマネージャ
 
-[Fetching Title#f11c](https://astral.sh/blog/uv-unified-python-packaging)
+[uv: Unified Python packaging](https://astral.sh/blog/uv-unified-python-packaging)
 

content/パッケージマネージャー.md

@@ -7,12 +7,15 @@ date: 2025-07-09 19:14
 
 バージョンの依存性解決なども機能のうちに含む。
 
+[[パッケージマネージャーはコミュニケーションツールである]]
+
+
+---
 
 [[Suwa Takashi]]さんの記事がパッケージマネージャとは何かをよく解説してくれている
 
 [パッケージマネージャを自作するときに考えること - gfnweb](https://gfngfn.github.io/ja/posts/2023-02-15-on-creating-package-managers/)
 
-
 ---
 
 [[Andrew Nesbitt]]がたくさん解説している
@@ -23,18 +26,13 @@ date: 2025-07-09 19:14
 
 [Package Manager Design Tradeoffs | Andrew Nesbitt](https://nesbitt.io/2025/12/05/package-manager-tradeoffs.html)
 
-[Federated Package Management and the Zooko Triangle | Andrew Nesbitt](https://nesbitt.io/2025/12/21/federated-package-management.html)
+[[Zooko Triangle]]
+
+[[Go]]のパッケージ管理システムを作った[[Sam Boyer]]による記事
 
 [So you want to write a package manager | by sam boyer | Medium](https://medium.com/@sdboyer/so-you-want-to-write-a-package-manager-4ae9c17d9527)
 
 [[開発者のためのハームリダクション]]
 
-
-[The Cutting Edge of Versioning (LambdaConf 2024) — Sympolymathesy, by Chris Krycho](https://v5.chriskrycho.com/elsewhere/cutting-edge-of-versioning/)
-
-
 [[uv]]
 
-> **バージョン管理はコミュニケーションツールである**
-
-> **バージョン管理は*社会技術的契約*である：**

content/パッケージマネージャーはコミュニケーションツールである.md

@@ -0,0 +1,28 @@
+---
+date: 2026-01-12 08:48
+---
+#thoughts 
+
+[The Cutting Edge of Versioning (LambdaConf 2024) — Sympolymathesy, by Chris Krycho](https://v5.chriskrycho.com/elsewhere/cutting-edge-of-versioning/)
+
+> **バージョン管理はコミュニケーションツールである**
+
+> **バージョン管理は*社会技術的契約*である：**
+
+パッケージマネージャが導入されることで初めてプログラミング言語はインターネットで繋がれたツールになる。
+
+パッケージマネージャは自動で問題を解決してくれるわけではない。なぜなら問題を管理する人間が不完全だからである。
+
+バージョン管理は通常[[Semantic Versioning]]で管理されるが、メジャーバージョンは互換性とは別にマーケティング的都合で動かされることもままある。作者がパッチバージョンとマイナーバージョンを間違えてタグづけることもある。Gitで操作した履歴とパッケージマニフェストのバージョン番号が不整合なこともある。
+
+どっちかというとこれらの不整合の責任を分離するツールとも言えるかもしれない。
+
+例えば[[Homebrew]]は技術的にはあまり良くできたパッケージマネージャではない。どれが依存パッケージかの区別がないので管理が面倒だし、ロックファイルもない(Pythonツールのresourcesのやり方は少しロックファイルっぽいが）。なので基本的にどのツールも複数バージョンの共有を許さないため、依存ツール間でバージョンの不整合が起きると死ぬことがある。だがなんだかんだ割とよく使われてて成立している。それがなぜかというと、Pull Requestベースのレビューでリポジトリが中央集権管理されていて、また管理がよく行き届いていてユーザーが多いから、というややトートロジー的な理由である。
+
+不整合は起きるかもしれないが、起きたら起きたでユーザーからの報告がすぐ届いて、対応も早い。運用でうまいことツールの不出来さをカバーしている。そのぐらいの複雑度だから多くの人が運用に参加できているとも言える。
+
+
+
+
+
+

content/開発者のためのハームリダクション.md

@@ -1,3 +1,5 @@
 
 [Harm reduction for developers](https://jvns.ca/blog/2014/11/18/harm-reduction-for-developers/)
 
+> switching out YOU’RE WRONG TO DO THAT JUST DON’T DO THAT for _doing something to help people be safer_
+