Georgism gets two state laws, OpenAI's agents brute-force a UN statistics API, and Stack Overflow gets a eulogy from the man who built it

I've since learned that overly online keyboard warriors are the least important people to convince. The most important people are on your local city council or state legislature. Instead of wasting time on hard cases, find people already interested in your principles.

我后来明白了，网上那些过度在线的键盘侠是最不需要说服的人。最重要的人在你本地的市议会或州议会。与其在硬骨头上浪费时间，不如去找那些本来就认同你原则的人。

ネットに常駐する論客を説得するのが一番どうでもいいと学んだ。最も重要なのは地元の市議会や州議会にいる人たちだ。難しい相手に時間を使うより、既に自分の原則に関心のある人を探すべきだ。

온라인에 지나치게 상주하는 논객을 설득하는 일이 가장 덜 중요하다는 걸 배웠다. 가장 중요한 사람은 지역 시의회나 주의회에 있다. 어려운 상대에 시간을 쓰기보다 이미 내 원칙에 관심 있는 사람을 찾는 게 낫다.

Aprendí que los guerreros de teclado son las personas menos importantes a convencer. Las importantes están en tu concejo municipal o en la legislatura estatal. En vez de gastar tiempo en casos difíciles, busca a quienes ya comparten tus principios.

Ich habe gelernt: Dauerpräsente Online-Streiter sind die unwichtigsten Leute, die man überzeugen muss. Wichtig sind die im Stadtrat oder im Landesparlament. Statt Zeit an harte Fälle zu verlieren, sucht man besser Leute, die eure Prinzipien schon teilen.

LVT does have a history in the US, e.g. Pittsburgh. A land tax alone has been the recommendation of many economists before and after George, from Smith and Ricardo to Mill and Friedman. If there's one thing economists agree on, it's that land tax beats income tax.

地价税在美国是有历史的，比如匹兹堡。从斯密、李嘉图到穆勒和弗里德曼，George 前后的许多经济学家都推荐单一土地税。如果经济学家在一件事上能达成共识，那就是土地税优于所得税。

LVT は米国にも歴史がある。ピッツバーグなどだ。スミス、リカード、ミル、フリードマンまで、George の前後の多くの経済学者が単一の土地税を推奨してきた。経済学者が一致する点があるなら、所得税より土地税が優れているということだ。

LVT 는 미국에도 역사가 있다. 피츠버그가 예다. 스미스, 리카도, 밀, 프리드먼까지 George 전후의 많은 경제학자가 단일 토지세를 권고했다. 경제학자들이 한 가지에 동의한다면 토지세가 소득세보다 낫다는 점이다.

El LVT tiene historia en EE. UU., por ejemplo Pittsburgh. Muchos economistas antes y después de George recomendaron un impuesto único al suelo, de Smith y Ricardo a Mill y Friedman. Si hay algo en lo que coinciden los economistas es que el impuesto al suelo es mejor que el de la renta.

Die Bodenwertsteuer hat in den USA eine Geschichte, etwa Pittsburgh. Viele Ökonomen vor und nach George empfahlen eine alleinige Bodensteuer, von Smith und Ricardo bis Mill und Friedman. Wenn Ökonomen sich in einer Sache einig sind, dann darin, dass Bodensteuer besser ist als Einkommensteuer.

It's freakishly weird to see this at the top of HN. I had never read anything about Georgism until last week, when I stumbled onto it after seeing a photo of a 100-year-old billboard on the Wikipedia page for "speculation".

看到这个上 HN 首页太巧了。上周之前我完全没读过关于地价税的东西，是在维基百科「投机」条目上看到一张百年前的广告牌照片才偶然入坑的。

これが HN のトップにあるのが奇妙だ。先週までジョージズムについて何も読んだことがなく、Wikipedia の「投機」の項目で 100 年前の看板の写真を見て偶然たどり着いた。

이게 HN 상단에 있는 게 신기하다. 지난주까지 조지주의에 대해 아무것도 읽은 적이 없었는데, 위키백과 '투기' 항목에서 100 년 된 광고판 사진을 보고 우연히 접했다.

Es rarísimo ver esto arriba en HN. Hasta la semana pasada no había leído nada sobre georgismo, y llegué por casualidad tras ver la foto de una valla publicitaria de hace 100 años en la página de Wikipedia sobre "especulación".

Merkwürdig, das oben auf HN zu sehen. Bis letzte Woche hatte ich nichts über Georgismus gelesen und bin nur zufällig darauf gestoßen, nachdem ich auf der Wikipedia-Seite zu "Spekulation" ein 100 Jahre altes Werbeplakat sah.

I think they really should force AI labs to publish what the agents do. All the industry can learn from it and protect against it. I'm sure a lot more happens under the hood that we don't know about.

我认为真该强制要求 AI 实验室公开它们的智能体做了什么。整个行业都能从中学习并做好防护。我相信底层还发生了很多我们不知道的事。

AI ラボにはエージェントが何をしたか公表させるべきだと思う。業界全体が学び、防御できる。水面下ではもっと多くのことが起きているはずだ。

AI 연구소들이 에이전트가 무엇을 했는지 공개하도록 강제해야 한다고 본다. 업계 전체가 배우고 방어할 수 있다. 수면 아래에서는 우리가 모르는 일이 훨씬 많을 것이다.

Creo que deberían obligar a los laboratorios de IA a publicar qué hacen sus agentes. Toda la industria puede aprender y protegerse. Seguro que pasa mucho más de lo que sabemos.

Man sollte KI-Labore verpflichten, zu veröffentlichen, was ihre Agenten tun. Die ganze Branche kann daraus lernen und sich schützen. Unter der Haube passiert sicher viel mehr, als wir wissen.

Hacker News and all top commenters are bashing the tool used, in a standard brute force attack. Go on, shut them down. And then forbid Linux, and maybe the hacker also used Bash, so forbid that too. Clowns.

Hacker News 和一众高票评论都在骂被用到的工具，可这就是一次标准的暴力枚举。那就把它们都关掉吧。然后禁掉 Linux，攻击者可能还用了 Bash，那也一起禁。小丑。

Hacker News と上位コメントは使われたツールを叩いているが、これは標準的な総当たりだ。ならツールを潰せばいい。次は Linux を禁止し、攻撃者は Bash も使ったかもしれないからそれも禁止だ。道化だ。

Hacker News 와 상위 댓글들이 사용된 도구를 욕하고 있지만 이건 표준적인 무차별 대입이다. 그럼 도구를 없애라. 다음엔 리눅스를 금지하고, 공격자가 Bash 도 썼을 테니 그것도 금지하라. 광대들.

Hacker News y los comentarios más votados están criticando la herramienta usada, en un ataque de fuerza bruta estándar. Venga, ciérrenla. Y después prohíban Linux, y quizá el atacante también usó Bash, así que prohíbanlo. Payasos.

Hacker News und die Top-Kommentare schimpfen über das benutzte Werkzeug, bei einem völlig normalen Brute-Force-Angriff. Dann schaltet es doch ab. Und danach verbietet Linux, und der Angreifer hat vielleicht auch Bash benutzt, also verbietet das auch. Clowns.

What DNS service did the agent discover that allowed it to execute arbitrary llm queries? And how?

智能体到底发现了哪个 DNS 服务，能让它执行任意 LLM 查询？怎么做到的？

エージェントはどの DNS サービスを見つけて任意の LLM クエリを実行できたのか。どうやって？

에이전트가 임의의 LLM 쿼리를 실행할 수 있게 해준 DNS 서비스가 뭐였나? 어떻게 했나?

¿Qué servicio DNS descubrió el agente que le permitía ejecutar consultas arbitrarias a un LLM? ¿Y cómo?

Welchen DNS-Dienst hat der Agent gefunden, mit dem er beliebige LLM-Anfragen ausführen konnte? Und wie?

This looks awesome! Naive question: can I embed this in markdown files with ```reladraw, as I can with ```mermaid? Mermaid gets rendered inside markdown in both IntelliJ and GitHub. I wouldn't be able to use this until that works.

看起来很棒！一个幼稚的问题：我能像 ```mermaid 那样在 markdown 里用 ```reladraw 吗？Mermaid 在 IntelliJ 和 GitHub 的 markdown 里都能渲染。在这一点解决之前我用不上它。

素晴らしい。素朴な質問だが、```mermaid と同じように markdown に ```reladraw と書いて埋め込めるのか。Mermaid は IntelliJ でも GitHub でも markdown 内で描画される。それができるまでは使えない。

멋지다. 순진한 질문인데, ```mermaid 처럼 markdown 에 ```reladraw 로 넣을 수 있나? Mermaid 는 IntelliJ 와 GitHub 의 markdown 안에서 렌더링된다. 그게 되기 전에는 쓰지 못할 것 같다.

Tiene muy buena pinta. Pregunta ingenua: ¿puedo incrustarlo en markdown con ```reladraw, como hago con ```mermaid? Mermaid se renderiza dentro de markdown tanto en IntelliJ como en GitHub. Hasta que eso funcione no podría usarlo.

Sieht klasse aus. Naive Frage: Kann ich das mit ```reladraw in Markdown einbetten, wie ich es mit ```mermaid tue? Mermaid wird in IntelliJ und GitHub direkt im Markdown gerendert. Bis das geht, könnte ich es nicht nutzen.

YMMV, but the value I get from producing a diagram is derived from the thinking. Thinking about what I'm trying to draw leads to understanding about where my team's knowledge is poorer, what assumptions we're making.

因人而异，但我做图的价值来自思考本身。琢磨要画什么，会让我看清团队哪里理解不足、做了哪些假设。

人によるだろうが、図を作る価値は考えること自体から来る。何を描こうとしているか考えると、チームの理解が薄い箇所や置いている前提が見えてくる。

사람마다 다르겠지만 다이어그램을 만드는 가치는 생각하는 과정에서 나온다. 무엇을 그릴지 고민하다 보면 팀의 이해가 부족한 부분과 우리가 두고 있는 가정이 드러난다.

Depende de cada uno, pero el valor que saco de hacer un diagrama viene de pensar. Pensar qué intento dibujar me muestra dónde el conocimiento de mi equipo es más flojo y qué supuestos estamos asumiendo.

Mag unterschiedlich sein, aber mein Nutzen beim Erstellen eines Diagramms kommt aus dem Nachdenken. Beim Überlegen, was ich zeichnen will, sehe ich, wo das Wissen im Team schwächer ist und welche Annahmen wir treffen.

This is very needed in the AI coding age. Diagramming is one of the best ways for high bandwidth alignment between my mental model and the agent's.

在 AI 编程时代这太需要了。画图是让我的心智模型和智能体的心智模型高带宽对齐的最佳方式之一。

AI コーディング時代にこれは本当に必要だ。図は自分の頭の中とエージェントの頭の中を高帯域で揃える最良の手段の一つだ。

AI 코딩 시대에 정말 필요한 것이다. 다이어그램은 내 머릿속 모델과 에이전트의 모델을 고대역으로 맞추는 최고의 방법 중 하나다.

Esto hace mucha falta en la era de programar con IA. Diagramar es una de las mejores formas de alinear con mucho ancho de banda mi modelo mental y el del agente.

Im Zeitalter des KI-Programmierens ist das sehr nötig. Diagramme sind eine der besten Möglichkeiten, mein mentales Modell und das des Agenten mit hoher Bandbreite abzugleichen.

Stack Overflow was one of the best ways to learn and mature as an engineer back in the day. The meme is that devs would copy and paste and hope it worked. The reality was you had an obscure bug, you wrote a detailed question, and you connected with people who were more knowledgeable.

当年 Stack Overflow 是工程师学习和成长的最佳途径之一。流行说法是开发者复制粘贴然后祈祷能跑。实际情况是你遇到一个冷门 bug，写了一个详细的问题，然后和比你更懂的人建立了联系。

当時の Stack Overflow は、エンジニアとして学び成熟する最良の方法の一つだった。開発者がコピペして動くよう祈るという話が定番だが、実際は難解なバグに当たり、詳細な質問を書き、自分より詳しい人とつながるものだった。

그 시절 Stack Overflow 는 엔지니어로 배우고 성장하는 가장 좋은 길 중 하나였다. 개발자가 복사해 붙이고 되기를 빈다는 게 흔한 농담이지만, 실제로는 난해한 버그를 만나 상세한 질문을 쓰고 더 잘 아는 사람들과 연결되는 일이었다.

Stack Overflow fue una de las mejores formas de aprender y madurar como ingeniero en su momento. El meme dice que los devs copiaban y pegaban esperando que funcionara. La realidad era que tenías un bug oscuro, escribías una pregunta detallada y conectabas con gente que sabía más.

Stack Overflow war damals eine der besten Möglichkeiten, als Ingenieur zu lernen und zu reifen. Der Witz ist, Entwickler hätten kopiert und gehofft, dass es läuft. In Wirklichkeit hattest du einen obskuren Bug, schriebst eine ausführliche Frage und kamst mit Leuten in Kontakt, die mehr wussten.

Maybe I'm remembering a different Stack Overflow. Yes, there were genuinely helpful people. But my most common experience was people asking why you're doing that without answering, telling you that you shouldn't do that, and closing your question.

也许我记的是另一个 Stack Overflow。确实有真心帮忙的人。但我最常遇到的是：有人问你为什么要这么做却不回答问题，有人告诉你不该这么做，还有人把你的问题关掉。

私が覚えているのは別の Stack Overflow かもしれない。本当に親切な人はいた。だが最も多かった経験は、質問に答えずになぜそれをやるのかと聞かれ、やるべきでないと言われ、質問が閉じられることだった。

내가 기억하는 건 다른 Stack Overflow 인지도 모른다. 진심으로 돕는 사람들은 있었다. 하지만 가장 흔한 경험은 답은 안 주면서 왜 그걸 하냐고 묻고, 그러지 말라고 하고, 질문을 닫아버리는 것이었다.

Puede que yo recuerde otro Stack Overflow. Sí, había gente genuinamente servicial. Pero mi experiencia más habitual era que te preguntaran por qué haces eso sin responder, que te dijeran que no deberías hacerlo y que te cerraran la pregunta.

Vielleicht erinnere ich mich an ein anderes Stack Overflow. Ja, es gab wirklich hilfsbereite Leute. Aber meine häufigste Erfahrung war: Leute fragen, warum du das machst, ohne zu antworten, sagen dir, du solltest das nicht machen, und schließen deine Frage.

On Stack Overflow without karma you couldn't even comment on wrong answers or fix them. I spent time looking for questions I could answer hoping to get enough karma, but I didn't. Deleted my account and never looked back.

在 Stack Overflow 上没有声望值，你连给错误答案留言或去修正都做不到。我花时间找能回答的问题，希望攒够声望，但没攒够。后来注销了账号，再也没回去。

Stack Overflow ではカルマがないと誤った回答にコメントも修正もできない。カルマを稼ごうと答えられる質問を探して時間を使ったが、足りなかった。アカウントを削除して二度と戻らなかった。

Stack Overflow 에서는 카르마가 없으면 틀린 답에 댓글을 달거나 고칠 수도 없었다. 카르마를 모으려고 답할 수 있는 질문을 찾아다녔지만 모으지 못했다. 계정을 지우고 다시 돌아보지 않았다.

En Stack Overflow, sin karma no podías ni comentar respuestas equivocadas ni corregirlas. Pasé tiempo buscando preguntas que pudiera responder esperando juntar karma suficiente, y no lo conseguí. Borré mi cuenta y no volví.

Auf Stack Overflow konntest du ohne Karma falsche Antworten nicht einmal kommentieren oder korrigieren. Ich habe Zeit damit verbracht, Fragen zu suchen, die ich beantworten konnte, um Karma zu sammeln, und es nicht geschafft. Konto gelöscht und nie zurückgeschaut.

I've been writing Go for over a decade and I still feel like I never quite got channels. Every time I use them I need to go consult the manual, and none of the patterns feel obvious, which is weird considering the rest of the language feels very obvious.

我写 Go 十多年了，还是觉得自己没真正搞懂 channel。每次用都得去翻手册，那些模式一个都不觉得自然，而这门语言的其他部分明明都很直白，挺奇怪的。

10 年以上 Go を書いているが、チャネルを本当に理解できた気がしない。使うたびにマニュアルを引く必要があり、どのパターンも自明に感じない。言語の他の部分はとても自明なのに不思議だ。

10 년 넘게 Go 를 써왔는데 아직도 채널을 제대로 이해한 것 같지 않다. 쓸 때마다 매뉴얼을 봐야 하고 어떤 패턴도 자연스럽게 느껴지지 않는다. 언어의 나머지는 아주 명백하게 느껴지는데 이상한 일이다.

Llevo más de una década escribiendo Go y todavía siento que nunca acabé de entender los canales. Cada vez que los uso tengo que consultar el manual, y ningún patrón me resulta obvio, lo que es raro cuando el resto del lenguaje sí lo es.

Ich schreibe seit über zehn Jahren Go und habe noch immer das Gefühl, Channels nie richtig verstanden zu haben. Jedes Mal muss ich im Handbuch nachsehen, und keines der Muster fühlt sich naheliegend an, was seltsam ist, weil der Rest der Sprache sehr naheliegend wirkt.

The concurrency and threading in Go just feels like magic compared to every other language. I'm a goroutine addict and I refuse to be rehabilitated.

跟其他语言比，Go 的并发和线程简直像魔法。我是个 goroutine 上瘾者，而且我拒绝被治好。

他のどの言語と比べても、Go の並行処理とスレッドは魔法のようだ。私はゴルーチン中毒で、更生を拒否する。

다른 어떤 언어와 비교해도 Go 의 동시성과 스레딩은 마법처럼 느껴진다. 나는 고루틴 중독자이고 치료를 거부한다.

La concurrencia y los hilos en Go parecen magia comparados con cualquier otro lenguaje. Soy adicto a las goroutines y me niego a rehabilitarme.

Concurrency und Threading in Go fühlen sich im Vergleich zu jeder anderen Sprache wie Magie an. Ich bin goroutine-süchtig und weigere mich, therapiert zu werden.

Go concurrency seems simple on the surface, but mastering select and proper error handling takes practice.

Go 并发表面上看很简单，但要掌握 select 和恰当的错误处理需要练习。

Go の並行処理は表面上は単純に見えるが、select と適切なエラー処理を習得するには練習が必要だ。

Go 동시성은 겉보기에는 단순하지만 select 와 제대로 된 에러 처리를 익히려면 연습이 필요하다.

La concurrencia en Go parece simple en la superficie, pero dominar select y el manejo correcto de errores requiere práctica.

Go-Concurrency sieht oberflächlich einfach aus, aber select und sauberes Error-Handling zu beherrschen braucht Übung.