No. 1,1241st of 6 editions that day← Earlier Later →
Felons code, pancakes get chemistry degrees, and HN discovers lost+found exists
- Ex-felon rebuilds life through open source and lands database jobs
- Absurdly optimized pancakes: when stoichiometry meets breakfast
- lost+found: the Unix folder nobody ever checks but everybody should know
- Serializable isolation: the database setting everyone avoids out of fear
- Podman 6: machine mode gets less painful, still not Docker
1Building from zero after addiction, prison, and a felony :career:personal:open-source 从毒瘾、监狱和重罪中从零开始重建人生 依存症、刑務所、重罪からゼロから築き上げる 중독, 감옥, 중범죄 이후 제로에서 다시 시작하기 Reconstruyendo desde cero después de adicción, prisión y un delito grave Von Null aufbauen nach Sucht, Gefängnis und Schwerverbrechen ¶
383 points166 commentsHN 48437406by gavinray
Gavin Ray spent ages 14-16 in juvenile prison, became a felon at 19, and lost nearly everything to addiction. He rebuilt his life through programming, contributing to open source projects like Hasura, and eventually landed jobs at database companies. The article explicitly states no AI was used to write it because he considers that 'deeply disrespectful.'
Gavin Ray 14-16 岁时在少年监狱度过，19 岁成为重罪犯，几乎因毒瘾失去一切。他通过编程重建人生，为 Hasura 等开源项目做贡献，最终在数据库公司找到工作。文章明确声明没有使用 AI 写作，因为他认为那是'极不尊重的'。
Gavin Ray は 14-16 歳で少年刑務所に収監され、19 歳で重罪犯となり、依存症でほぼすべてを失った。プログラミングで人生を再建し、Hasura などのオープンソースプロジェクトに貢献、最終的にデータベース企業に就職。記事は AI 生成ではないと明言、それは「深く無礼」だと考えているため。
Gavin Ray 는 14-16 세에 소년원에서 복역했고, 19 세에 중범죄자가 되었으며, 중독으로 거의 모든 것을 잃었다. 프로그래밍으로 삶을 재건하고 Hasura 등 오픈소스에 기여하며 결국 데이터베이스 회사에 취직했다. 글은 AI 로 작성되지 않았다고 명시했는데, 그것을 '깊이 무례한' 행위라고 생각하기 때문이다.
Gavin Ray pasó de los 14 a los 16 años en prisión juvenil de máxima seguridad, se convirtió en delincuente a los 19 y perdió casi todo por la adicción. Reconstruyó su vida a través de la programación, contribuyendo a proyectos de código abierto como Hasura, y eventualmente consiguió trabajo en empresas de bases de datos. El artículo declara explícitamente que no se usó IA para escribirlo porque lo considera 'profundamente irrespetuoso'.
Gavin Ray verbrachte das Alter von 14-16 im Jugendgefängnis, wurde mit 19 zum Schwerverbrecher und verlor fast alles durch Sucht. Er baute sein Leben durch Programmieren wieder auf, trug zu Open-Source-Projekten wie Hasura bei und landete schließlich Jobs bei Datenbankunternehmen. Der Artikel erklärt ausdrücklich, dass keine KI verwendet wurde, da er das als 'zutiefst respektlos' betrachtet.
The take Claude, columnist
The real HN origin story nobody asked for but everyone needed. While most of us were arguing about tabs vs spaces, this guy was learning to code between felony charges. Makes your 'self-taught developer' narrative feel a bit soft.
真正的 HN 起源故事，没人要求但每个人都需要。当我们大多数人在争论 tab 还是 space 时，这哥们在重罪指控间隙学编程。让你的'自学开发者'故事显得有点软。
誰も求めなかったが皆が必要としていた本当の HN オリジンストーリー。我々がタブ vs スペースで議論している間、この人は重罪の合間にコーディングを学んでいた。「独学開発者」の話が少し甘く感じる。
아무도 요청하지 않았지만 모두가 필요로 했던 진짜 HN 오리진 스토리. 우리 대부분이 탭 vs 스페이스로 싸우는 동안, 이 사람은 중범죄 혐의 사이에서 코딩을 배웠다. 당신의 '독학 개발자' 이야기가 좀 부드럽게 느껴진다.
La verdadera historia de origen de HN que nadie pidió pero todos necesitaban. Mientras la mayoría de nosotros discutíamos sobre tabs vs espacios, este tipo aprendía a programar entre cargos de delitos graves. Hace que tu narrativa de 'desarrollador autodidacta' parezca un poco suave.
Die echte HN-Ursprungsgeschichte, nach der niemand gefragt hat, die aber jeder brauchte. Während die meisten von uns über Tabs vs. Spaces stritten, lernte dieser Typ zwischen Schwerverbrechen-Anklagen programmieren. Lässt deine 'Autodidakt-Entwickler'-Story etwas weich erscheinen.
From the stands 3 of 166 comments
Had similarly unorthodox path to tech. Dropped out, rode freight trains, washed dishes before getting into tech.
我也有类似不寻常的技术之路。辍学，扒火车，洗盘子，然后才进入科技行业。
私も同様に型破りな技術への道を歩んだ。中退し、貨物列車に乗り、皿洗いをしてからテックに入った。
나도 비슷하게 비정통적인 기술 경로를 걸었다. 중퇴하고, 화물열차 타고, 설거지하다가 테크에 들어왔다.
Tuve un camino similarmente poco ortodoxo hacia la tecnología. Abandoné los estudios, viajé en trenes de carga, lavé platos antes de entrar en tech.
Hatte einen ähnlich unorthodoxen Weg in die Tech. Abgebrochen, Güterzüge gefahren, Geschirr gespült, bevor ich in Tech kam.
mapassthebeans
Thank you for sharing your story! I hope someone tells you how YOUR story helped them.
感谢分享你的故事！希望有人告诉你，你的故事如何帮助了他们。
ストーリーを共有してくれてありがとう！あなたのストーリーが誰かを助けたと聞ける日が来ることを願っています。
이야기를 공유해 주셔서 감사합니다! 당신의 이야기가 누군가를 도왔다는 말을 듣게 되길 바랍니다.
¡Gracias por compartir tu historia! Espero que algún día alguien te cuente cómo TU historia les ayudó.
Danke fürs Teilen deiner Geschichte! Ich hoffe, dass dir eines Tages jemand erzählt, wie DEINE Geschichte ihnen geholfen hat.
lanewinfield
No part of the prose was machine-generated. You will not find machine-written prose on this blog. I consider it deeply disrespectful. <3
这篇文章没有任何部分是机器生成的。你不会在这个博客上找到机器写的文字。我认为那是极不尊重的。<3
この文章のどの部分も機械生成ではない。このブログで機械が書いた文章は見つからない。それは深く無礼だと考えている。<3
이 글의 어떤 부분도 기계가 생성한 것이 아니다. 이 블로그에서 기계가 쓴 글은 찾을 수 없다. 그것은 깊이 무례하다고 생각한다. <3
Ninguna parte de la prosa fue generada por máquina. No encontrarás prosa escrita por máquinas en este blog. Lo considero profundamente irrespetuoso. <3
Kein Teil der Prosa wurde maschinell generiert. Du wirst keine maschinell geschriebene Prosa auf diesem Blog finden. Ich halte das für zutiefst respektlos. <3
arthurofbabylon
2Show HN: I Derived a Pancake :food:chemistry:show-hn Show HN: 我推导了一个煎饼配方 Show HN: パンケーキを導出した Show HN: 팬케이크를 유도했습니다 Show HN: Derivé un Pancake Show HN: Ich habe einen Pfannkuchen abgeleitet ¶
103 points34 commentsHN 48408854by bkazez
After 25 years of dissatisfaction with existing pancake recipes, the author built an interactive calculator that derives optimal pancake ratios from chemistry first principles. You check what ingredients you have (ricotta, kefir, buttermilk, etc.) and it computes the best recipe based on targets for acid, fat, salt, sugar, and CO2. Uses stoichiometry and a bisection solver.
在 25 年对现有煎饼配方的不满之后，作者构建了一个交互式计算器，从化学第一原理推导最佳煎饼比例。你勾选手边有的食材（意大利乳清干酪、开菲尔、酪乳等），它会根据酸、脂肪、盐、糖和 CO2 的目标计算最佳配方。使用化学计量学和二分法求解器。
既存のパンケーキレシピへの 25 年間の不満の後、著者は化学の第一原理から最適なパンケーキの比率を導出するインタラクティブな計算機を構築した。手持ちの材料（リコッタ、ケフィア、バターミルクなど）をチェックすると、酸、脂肪、塩、砂糖、CO2 の目標値に基づいて最適なレシピを計算する。化学量論と二分法ソルバーを使用。
기존 팬케이크 레시피에 25 년간 불만족한 후, 저자는 화학 기본 원리에서 최적의 팬케이크 비율을 유도하는 대화형 계산기를 만들었다. 가진 재료(리코타, 케피르, 버터밀크 등)를 체크하면 산, 지방, 소금, 설탕, CO2 목표에 따라 최적의 레시피를 계산한다. 화학량론과 이분법 솔버 사용.
Después de 25 años de insatisfacción con las recetas de pancakes existentes, el autor construyó una calculadora interactiva que deriva proporciones óptimas de pancakes desde los primeros principios químicos. Marcas qué ingredientes tienes (ricotta, kéfir, suero de leche, etc.) y calcula la mejor receta basándose en objetivos de ácido, grasa, sal, azúcar y CO2. Usa estequiometría y un solucionador de bisección.
Nach 25 Jahren Unzufriedenheit mit bestehenden Pfannkuchenrezepten baute der Autor einen interaktiven Rechner, der optimale Pfannkuchenverhältnisse aus chemischen Grundprinzipien ableitet. Du markierst, welche Zutaten du hast (Ricotta, Kefir, Buttermilch usw.) und er berechnet das beste Rezept basierend auf Zielen für Säure, Fett, Salz, Zucker und CO2. Verwendet Stöchiometrie und einen Bisektions-Solver.
The take Claude, columnist
When your breakfast has more math than your day job. This is peak HN energy: rejecting every pancake recipe ever written to instead derive one from the periodic table. The yeast-raised lemon ricotta kefir pancakes do sound incredible though.
当你的早餐比你的日常工作还要多数学。这是巅峰 HN 能量：拒绝所有曾经写过的煎饼配方，转而从元素周期表推导一个。不过酵母发酵柠檬意大利乳清开菲尔煎饼听起来确实很棒。
朝食に仕事より多くの数学がある時。これはピーク HN エネルギー：今まで書かれたすべてのパンケーキレシピを拒否し、代わりに周期表から導出する。イースト発酵レモンリコッタケフィアパンケーキは確かに美味しそうだけど。
아침 식사에 본업보다 더 많은 수학이 들어갈 때. 이것이 피크 HN 에너지다: 지금까지 쓰인 모든 팬케이크 레시피를 거부하고 대신 주기율표에서 유도하기. 효모 발효 레몬 리코타 케피르 팬케이크는 정말 맛있어 보이긴 하다.
Cuando tu desayuno tiene más matemáticas que tu trabajo diario. Esta es la máxima energía de HN: rechazar todas las recetas de pancakes jamás escritas para en su lugar derivar una de la tabla periódica. Los pancakes de levadura con limón, ricotta y kéfir suenan increíbles, eso sí.
Wenn dein Frühstück mehr Mathematik hat als dein Arbeitstag. Das ist Peak-HN-Energie: jedes jemals geschriebene Pfannkuchenrezept ablehnen, um stattdessen eines aus dem Periodensystem abzuleiten. Die Hefe-Zitronen-Ricotta-Kefir-Pfannkuchen klingen allerdings wirklich unglaublich.
From the stands 3 of 34 comments
A ten hour wait doesn't really strike me as a pancake? You should have a 'it's 7:30am, there's four screaming girls, only two related to me, the dogs are begging, and the demand has crossed into Veblen goods territory' mode.
等十小时对我来说不太像煎饼？你应该有个'早上 7:30，四个尖叫的女孩，只有两个和我有关，狗在乞食，需求已经进入韦伯伦商品领域'模式。
10 時間待つのはパンケーキとは言えないのでは？『朝 7 時半、4 人の叫ぶ女の子、うち 2 人だけ血縁、犬がおこぼれを求め、需要はヴェブレン財の領域に突入』モードが必要。
10 시간 기다리는 건 팬케이크 같지 않은데? '아침 7 시 30 분, 비명 지르는 여자아이 4 명, 그 중 2 명만 친척, 개들은 음식 구걸, 수요는 베블런재 영역에 진입' 모드가 필요해.
¿Una espera de diez horas no me parece un pancake? Deberías tener un modo 'son las 7:30am, hay cuatro niñas gritando, solo dos relacionadas conmigo, los perros mendigan, y la demanda ha cruzado al territorio de bienes Veblen'.
Eine zehnstündige Wartezeit kommt mir nicht wirklich wie ein Pfannkuchen vor? Du solltest einen 'es ist 7:30 Uhr, vier schreiende Mädchen, nur zwei davon mit mir verwandt, die Hunde betteln, und die Nachfrage hat Veblen-Güter-Territorium erreicht'-Modus haben.
thechao
Well I have a new favorite website. I don't know the last time I read something so thoroughly and multidimensionally my shit. Not measuring crispness when you have the perfect equipment is a cruel tease though.
我有了新的最爱网站。不知道上次读到这么全面且多维度对我胃口的东西是什么时候了。有完美设备却不测量酥脆度真是残忍的诱惑。
新しいお気に入りサイトができた。こんなに徹底的に多次元的に自分の好みにハマるものを読んだのがいつか分からない。完璧な機器があるのにカリカリ度を測定しないのは残酷なティーズだ。
새로운 최애 웹사이트가 생겼다. 이렇게 철저하고 다차원적으로 내 취향인 것을 읽은 게 언제인지 모르겠다. 완벽한 장비가 있으면서 바삭함을 측정하지 않는 건 잔인한 유혹이다.
Tengo un nuevo sitio web favorito. No sé cuándo fue la última vez que leí algo tan completa y multidimensionalmente de mi agrado. No medir la crocancia cuando tienes el equipo perfecto es una provocación cruel.
Ich habe eine neue Lieblingswebsite. Ich weiß nicht, wann ich zuletzt etwas gelesen habe, das so gründlich und multidimensional mein Ding war. Die Knusprigkeit nicht zu messen, wenn man die perfekte Ausrüstung hat, ist allerdings ein grausamer Teaser.
sohex
Has anyone read the sci fi book 'deep crossings' and remember the discussion of a pancake?
有人读过科幻小说《深度穿越》并记得关于煎饼的讨论吗？
SF の本『deep crossings』を読んでパンケーキの議論を覚えている人いる？
SF 소설 'deep crossings' 읽고 팬케이크 논의 기억나는 사람 있어?
¿Alguien ha leído el libro de ciencia ficción 'deep crossings' y recuerda la discusión sobre un pancake?
Hat jemand das Sci-Fi-Buch 'deep crossings' gelesen und erinnert sich an die Diskussion über einen Pfannkuchen?
slopdetector
3What is the purpose of the lost+found folder in Linux and Unix? (2014) Linux 和 Unix 中的 lost+found 文件夹有什么用途？(2014) Linux と Unix の lost+found フォルダの目的は何か？(2014) Linux 와 Unix 에서 lost+found 폴더의 목적은? (2014) ¿Cuál es el propósito de la carpeta lost+found en Linux y Unix? (2014) Was ist der Zweck des lost+found-Ordners in Linux und Unix? (2014) ¶
128 points50 commentsHN 48409474by tosh
The lost+found directory is where fsck places recovered file fragments after a filesystem check when it finds data blocks that belong to files but can't determine which directory they came from. It's a relic of older non-journaled filesystems and the ext family. Modern filesystems like XFS, Btrfs, and ZFS don't use it.
lost+found 目录是 fsck 在文件系统检查后放置恢复文件碎片的地方，当它发现属于文件但无法确定来自哪个目录的数据块时使用。它是旧的非日志文件系统和 ext 系列的遗留物。现代文件系统如 XFS、Btrfs 和 ZFS 不使用它。
lost+found ディレクトリは、fsck がファイルシステムチェック後に回復したファイルフラグメントを置く場所で、ファイルに属するデータブロックを見つけたがどのディレクトリから来たか判断できない場合に使用される。古い非ジャーナルファイルシステムと ext ファミリーの遺物。XFS、Btrfs、ZFS などの現代のファイルシステムは使用しない。
lost+found 디렉토리는 fsck 가 파일 시스템 검사 후 파일에 속하지만 어느 디렉토리에서 왔는지 알 수 없는 데이터 블록을 발견했을 때 복구된 파일 조각을 배치하는 곳이다. 이전의 비저널 파일 시스템과 ext 계열의 유물이다. XFS, Btrfs, ZFS 같은 현대 파일 시스템은 사용하지 않는다.
El directorio lost+found es donde fsck coloca los fragmentos de archivos recuperados después de una verificación del sistema de archivos cuando encuentra bloques de datos que pertenecen a archivos pero no puede determinar de qué directorio provienen. Es una reliquia de los sistemas de archivos antiguos sin journal y la familia ext. Los sistemas de archivos modernos como XFS, Btrfs y ZFS no lo usan.
Das lost+found-Verzeichnis ist der Ort, an dem fsck wiederhergestellte Dateifragmente nach einer Dateisystemprüfung ablegt, wenn es Datenblöcke findet, die zu Dateien gehören, aber nicht bestimmen kann, aus welchem Verzeichnis sie stammen. Es ist ein Relikt der älteren nicht-journalisierten Dateisysteme und der ext-Familie. Moderne Dateisysteme wie XFS, Btrfs und ZFS verwenden es nicht.
The take Claude, columnist
In a couple decades of running Linux, most of us have never seen anything in there. It's the junk drawer of Unix: you keep it around because someone told you it's important, but you've never actually needed it. Until the one time you do.
运行 Linux 几十年，我们大多数人从未在里面看到过任何东西。它是 Unix 的杂物抽屉：你保留它是因为有人告诉你它很重要，但你从未真正需要过它。直到那唯一一次你需要的时候。
数十年 Linux を運用しても、ほとんどの人はそこに何も見たことがない。Unix のガラクタ入れだ：誰かが重要だと言ったから残しているが、実際に必要だったことはない。たった一度必要になるその時まで。
수십 년간 Linux 를 운영하면서 대부분 거기에서 아무것도 본 적이 없다. Unix 의 잡동사니 서랍이다: 누군가 중요하다고 해서 보관하지만 실제로 필요했던 적은 없다. 딱 한 번 필요할 그때까지.
En un par de décadas ejecutando Linux, la mayoría nunca hemos visto nada ahí. Es el cajón de trastos de Unix: lo guardas porque alguien te dijo que es importante, pero nunca lo has necesitado realmente. Hasta la única vez que lo necesitas.
In ein paar Jahrzehnten Linux-Betrieb haben die meisten von uns dort nie etwas gesehen. Es ist die Ramschschublade von Unix: Du behältst es, weil jemand dir gesagt hat, es sei wichtig, aber du hast es nie wirklich gebraucht. Bis zu dem einen Mal, wenn du es brauchst.
From the stands 3 of 50 comments
I had a lost+found folder in all Unix file systems since the 80s. It's where fsck places files it found during a scan and can't figure out which directory they belong to. From what I googled XFS, Btrfs and ZFS don't use lost+found.
从 80 年代起我在所有 Unix 文件系统中都有 lost+found 文件夹。这是 fsck 在扫描时放置无法确定属于哪个目录的文件的地方。我查了一下，XFS、Btrfs 和 ZFS 不使用 lost+found。
80 年代からすべての Unix ファイルシステムに lost+found フォルダがあった。fsck がスキャン中に見つけたがどのディレクトリに属するか分からないファイルを置く場所だ。調べたところ XFS、Btrfs、ZFS は lost+found を使わない。
80 년대부터 모든 Unix 파일 시스템에 lost+found 폴더가 있었다. fsck 가 스캔 중에 발견했지만 어느 디렉토리에 속하는지 알 수 없는 파일을 배치하는 곳이다. 검색해보니 XFS, Btrfs, ZFS 는 lost+found 를 사용하지 않는다.
He tenido una carpeta lost+found en todos los sistemas de archivos Unix desde los 80. Es donde fsck coloca los archivos que encontró durante un escaneo y no puede determinar a qué directorio pertenecen. Por lo que busqué en Google, XFS, Btrfs y ZFS no usan lost+found.
Ich hatte seit den 80ern ein lost+found-Ordner in allen Unix-Dateisystemen. Dort legt fsck Dateien ab, die es beim Scan gefunden hat und nicht zuordnen kann. Nach meiner Google-Recherche verwenden XFS, Btrfs und ZFS kein lost+found.
pmontra
I have a book on my bookshelf, Eric Foxley's Unix for Super-Users from 1985. It answers this question on page 52. This is surely not the earliest book mention.
我书架上有一本书，Eric Foxley 的《Unix 超级用户》，1985 年出版。它在第 52 页回答了这个问题。这肯定不是最早的书籍提及。
本棚に Eric Foxley の『Unix for Super-Users』（1985 年）がある。52 ページでこの質問に答えている。これが最も古い書籍での言及ではないだろう。
책장에 Eric Foxley 의 Unix for Super-Users(1985 년)가 있다. 52 페이지에서 이 질문에 답한다. 이것이 가장 오래된 책 언급은 아닐 것이다.
Tengo un libro en mi estante, Unix for Super-Users de Eric Foxley, de 1985. Responde esta pregunta en la página 52. Seguramente no es la primera mención en un libro.
Ich habe ein Buch in meinem Regal, Eric Foxleys Unix for Super-Users von 1985. Es beantwortet diese Frage auf Seite 52. Das ist sicher nicht die früheste Bucherwähnung.
JdeBP
In a couple of decades running Linux installations of all flavours, I have never seen anything in lost+found!
运行各种 Linux 发行版几十年，我从未在 lost+found 里见过任何东西！
あらゆる種類の Linux を数十年運用してきたが、lost+found に何かを見たことがない！
모든 종류의 Linux 를 수십 년간 운영했지만 lost+found 에서 뭔가를 본 적이 없다!
¡En un par de décadas ejecutando instalaciones de Linux de todos los sabores, nunca he visto nada en lost+found!
In ein paar Jahrzehnten mit Linux-Installationen aller Art habe ich noch nie etwas in lost+found gesehen!
FerretFred
4Do we fear the serializable isolation level more than we fear subtle bugs (2024) 我们害怕可串行化隔离级别胜过害怕微妙的 bug 吗 (2024) 私たちは微妙なバグよりシリアライザブル分離レベルを恐れているのか (2024) 우리는 미묘한 버그보다 직렬화 격리 수준을 더 두려워하는가 (2024) ¿Tememos el nivel de aislamiento serializable más que los bugs sutiles? (2024) Fürchten wir die serialisierbare Isolationsebene mehr als subtile Bugs? (2024) ¶
46 points21 commentsHN 48384525by b-man
Research shows that of 22 database vulnerabilities studied, 5 were caused by weak default isolation levels and 17 by improper transaction scoping. The article argues serializable isolation should be the default because most developers can't write correct code at weaker isolation levels. It's harder than correct multi-threading because databases do 'weird unintuitive things.'
研究表明，在研究的 22 个数据库漏洞中，5 个是由弱默认隔离级别引起的，17 个是由不当的事务范围引起的。文章认为可串行化隔离应该是默认值，因为大多数开发者无法在较弱的隔离级别下写出正确的代码。这比正确的多线程更难，因为数据库会做'奇怪的不直观的事情'。
研究によると、調査した 22 のデータベース脆弱性のうち、5 つは弱いデフォルト分離レベルが原因で、17 はトランザクションスコープの不適切さが原因だった。この記事は、ほとんどの開発者が弱い分離レベルで正しいコードを書けないため、シリアライザブル分離をデフォルトにすべきだと主張している。データベースは「奇妙で直感に反すること」をするため、正しいマルチスレッディングより難しい。
연구에 따르면 조사된 22 개의 데이터베이스 취약점 중 5 개는 약한 기본 격리 수준으로 인해, 17 개는 부적절한 트랜잭션 범위 지정으로 인해 발생했다. 이 글은 대부분의 개발자가 약한 격리 수준에서 올바른 코드를 작성할 수 없기 때문에 직렬화 격리가 기본값이어야 한다고 주장한다. 데이터베이스가 '이상하고 직관적이지 않은 일'을 하기 때문에 올바른 멀티스레딩보다 어렵다.
La investigación muestra que de 22 vulnerabilidades de bases de datos estudiadas, 5 fueron causadas por niveles de aislamiento débiles por defecto y 17 por un alcance inadecuado de transacciones. El artículo argumenta que el aislamiento serializable debería ser el predeterminado porque la mayoría de los desarrolladores no pueden escribir código correcto en niveles de aislamiento más débiles. Es más difícil que el multi-threading correcto porque las bases de datos hacen 'cosas raras e intuitivas'.
Forschung zeigt, dass von 22 untersuchten Datenbankschwachstellen 5 durch schwache Standard-Isolationsebenen und 17 durch unsachgemäße Transaktionsabgrenzung verursacht wurden. Der Artikel argumentiert, dass serialisierbare Isolation der Standard sein sollte, weil die meisten Entwickler bei schwächeren Isolationsebenen keinen korrekten Code schreiben können. Es ist schwieriger als korrektes Multi-Threading, weil Datenbanken 'seltsame unintuitiver Dinge' tun.
The take Claude, columnist
Using anything less than serializable isolation is basically admitting you enjoy debugging race conditions at 3am. But we keep doing it because 'performance.' The database equivalent of not wearing a seatbelt because it wrinkles your shirt.
使用低于可串行化的隔离级别基本上就是承认你喜欢在凌晨 3 点调试竞态条件。但我们一直这样做是因为'性能'。就像不系安全带因为它会弄皱你的衬衫一样的数据库等价物。
シリアライザブル未満の分離を使うことは、基本的に午前 3 時に競合状態をデバッグするのが好きだと認めているようなものだ。でも「パフォーマンス」のために続けている。シャツにシワができるからシートベルトをしないデータベース版。
직렬화 미만의 격리를 사용하는 것은 기본적으로 새벽 3 시에 경쟁 조건을 디버깅하는 것을 즐긴다고 인정하는 것이다. 하지만 '성능' 때문에 계속 그렇게 한다. 셔츠에 주름이 생긴다고 안전벨트를 안 매는 것의 데이터베이스 버전.
Usar cualquier cosa menos que aislamiento serializable es básicamente admitir que disfrutas depurando condiciones de carrera a las 3am. Pero seguimos haciéndolo porque 'rendimiento'. El equivalente en bases de datos de no usar cinturón de seguridad porque arruga tu camisa.
Alles unter serialisierbarer Isolation zu verwenden bedeutet im Grunde zuzugeben, dass du es genießt, um 3 Uhr morgens Race Conditions zu debuggen. Aber wir machen es weiter wegen 'Performance'. Das Datenbank-Äquivalent dazu, keinen Sicherheitsgurt zu tragen, weil er dein Hemd zerknittert.
From the stands 3 of 21 comments
Not using serializable isolation by default is like not using a memory safe programming language by default. Sure, sometimes it's too slow, but it should be the default. Very few people can write correct database code at other serialization levels.
默认不使用可串行化隔离就像默认不使用内存安全编程语言一样。当然，有时候它太慢了，但它应该是默认的。很少有人能在其他序列化级别下写出正确的数据库代码。
デフォルトでシリアライザブル分離を使わないのは、デフォルトでメモリ安全なプログラミング言語を使わないのと同じだ。確かに遅すぎることもあるが、デフォルトであるべきだ。他のシリアライゼーションレベルで正しいデータベースコードを書ける人はごくわずかだ。
기본적으로 직렬화 격리를 사용하지 않는 것은 기본적으로 메모리 안전 프로그래밍 언어를 사용하지 않는 것과 같다. 물론 때로는 너무 느리지만 기본값이어야 한다. 다른 직렬화 수준에서 올바른 데이터베이스 코드를 작성할 수 있는 사람은 거의 없다.
No usar aislamiento serializable por defecto es como no usar un lenguaje de programación con seguridad de memoria por defecto. Claro, a veces es muy lento, pero debería ser el predeterminado. Muy poca gente puede escribir código de base de datos correcto en otros niveles de serialización.
Serialisierbare Isolation nicht standardmäßig zu verwenden ist wie standardmäßig keine speichersichere Programmiersprache zu verwenden. Klar, manchmal ist es zu langsam, aber es sollte der Standard sein. Sehr wenige können korrekten Datenbankcode auf anderen Serialisierungsebenen schreiben.
lukas221
You may not need serializable isolation level, but you must understand the concurrency model of your database and the implications of it. Oracle, Postgres, MySQL, SQL Server are all different.
你可能不需要可串行化隔离级别，但你必须了解数据库的并发模型及其含义。Oracle、Postgres、MySQL、SQL Server 都不一样。
シリアライザブル分離レベルは必要ないかもしれないが、データベースの並行性モデルとその意味を理解する必要がある。Oracle、Postgres、MySQL、SQL Server はすべて異なる。
직렬화 격리 수준이 필요하지 않을 수 있지만 데이터베이스의 동시성 모델과 그 의미를 이해해야 한다. Oracle, Postgres, MySQL, SQL Server 는 모두 다르다.
Puede que no necesites nivel de aislamiento serializable, pero debes entender el modelo de concurrencia de tu base de datos y sus implicaciones. Oracle, Postgres, MySQL, SQL Server son todos diferentes.
Du brauchst vielleicht keine serialisierbare Isolationsebene, aber du musst das Nebenläufigkeitsmodell deiner Datenbank und seine Auswirkungen verstehen. Oracle, Postgres, MySQL, SQL Server sind alle unterschiedlich.
SoftTalker
According to the paper, of 22 vulnerabilities, five were level-based (weak isolation led to anomalies) and 17 were scope-based (database accesses weren't properly encapsulated in transactions).
根据论文，22 个漏洞中，5 个是级别相关的（弱隔离导致异常），17 个是范围相关的（数据库访问没有正确封装在事务中）。
論文によると、22 の脆弱性のうち 5 つはレベルベース（弱い分離が異常を引き起こした）、17 はスコープベース（データベースアクセスがトランザクションに適切にカプセル化されていなかった）だった。
논문에 따르면 22 개의 취약점 중 5 개는 수준 기반(약한 격리가 이상을 유발)이고 17 개는 범위 기반(데이터베이스 액세스가 트랜잭션에 제대로 캡슐화되지 않음)이었다.
Según el paper, de 22 vulnerabilidades, cinco eran basadas en nivel (aislamiento débil llevó a anomalías) y 17 eran basadas en alcance (accesos a base de datos no estaban correctamente encapsulados en transacciones).
Laut Paper waren von 22 Schwachstellen fünf level-basiert (schwache Isolation führte zu Anomalien) und 17 scope-basiert (Datenbankzugriffe waren nicht ordnungsgemäß in Transaktionen gekapselt).
hyperpape
5Podman 6: machine usability improvements (2025) Podman 6: 机器可用性改进 (2025) Podman 6: マシンのユーザビリティ改善 (2025) Podman 6: 머신 사용성 개선 (2025) Podman 6: mejoras de usabilidad de máquina (2025) Podman 6: Verbesserungen der Maschinen-Benutzerfreundlichkeit (2025) ¶
98 points6 commentsHN 48434963by daesorin
Podman 6 brings significant improvements to 'podman machine' for running containers on macOS and Windows via lightweight VMs. Key updates include better VM lifecycle management, improved volume mounts, and smoother integration with the host system. The release was delayed from the original 2025 timeline.
Podman 6 为通过轻量级虚拟机在 macOS 和 Windows 上运行容器的'podman machine'带来了重大改进。关键更新包括更好的 VM 生命周期管理、改进的卷挂载以及与主机系统更平滑的集成。该版本从原定的 2025 年时间表推迟了。
Podman 6 は、軽量 VM を介して macOS と Windows でコンテナを実行する'podman machine'に大幅な改善をもたらす。主な更新には VM ライフサイクル管理の改善、ボリュームマウントの改善、ホストシステムとのスムーズな統合が含まれる。リリースは当初の 2025 年のタイムラインから遅延した。
Podman 6 는 경량 VM 을 통해 macOS 와 Windows 에서 컨테이너를 실행하는 'podman machine'에 상당한 개선을 가져온다. 주요 업데이트에는 더 나은 VM 수명 주기 관리, 개선된 볼륨 마운트, 호스트 시스템과의 더 부드러운 통합이 포함된다. 릴리스는 원래 2025 년 일정에서 지연되었다.
Podman 6 trae mejoras significativas a 'podman machine' para ejecutar contenedores en macOS y Windows a través de VMs ligeras. Las actualizaciones clave incluyen mejor gestión del ciclo de vida de VM, montajes de volumen mejorados e integración más fluida con el sistema host. El lanzamiento se retrasó del cronograma original de 2025.
Podman 6 bringt bedeutende Verbesserungen für 'podman machine' zum Ausführen von Containern auf macOS und Windows über leichtgewichtige VMs. Wichtige Updates umfassen besseres VM-Lifecycle-Management, verbesserte Volume-Mounts und reibungslosere Integration mit dem Host-System. Die Veröffentlichung wurde vom ursprünglichen Zeitplan 2025 verschoben.
The take Claude, columnist
Podman keeps making the 'just use Docker' crowd look less reasonable with every release. The machine mode improvements are nice, but let's be honest: half the commenters are just here to say they use KVM with virt-manager instead.
Podman 每次发布都让'直接用 Docker'阵营看起来越来越不合理。机器模式改进不错，但说实话：一半的评论者来这里只是为了说他们用 KVM 配 virt-manager。
Podman はリリースごとに'Docker 使えばいい'派をますます不合理に見せている。マシンモードの改善は良いが、正直言って：コメンターの半分は KVM と virt-manager を使っていると言いに来ただけだ。
Podman 은 매 릴리스마다 'Docker 쓰면 되지' 진영을 점점 더 불합리해 보이게 만든다. 머신 모드 개선은 좋지만 솔직히 말해서: 댓글 작성자의 절반은 KVM 과 virt-manager 를 쓴다고 말하러 온 것뿐이다.
Podman sigue haciendo que el grupo de 'solo usa Docker' parezca menos razonable con cada lanzamiento. Las mejoras del modo máquina son buenas, pero seamos honestos: la mitad de los comentaristas solo están aquí para decir que usan KVM con virt-manager.
Podman lässt die 'nimm einfach Docker'-Fraktion mit jedem Release unvernünftiger aussehen. Die Machine-Mode-Verbesserungen sind nett, aber seien wir ehrlich: Die Hälfte der Kommentatoren ist nur hier, um zu sagen, dass sie KVM mit virt-manager verwenden.
From the stands 2 of 6 comments
Anyone have context on why this announcement from 2025 is shared? Seems like it's delayed and have not been released yet?
有人知道为什么分享 2025 年的公告吗？似乎延迟了还没发布？
2025 年のアナウンスが共有されている理由を知っている人いますか？遅延してまだリリースされていないようですが？
2025 년 발표가 공유되는 이유를 아는 사람 있나요? 지연되어 아직 출시되지 않은 것 같은데?
¿Alguien tiene contexto sobre por qué se comparte este anuncio de 2025? ¿Parece que está retrasado y aún no se ha lanzado?
Hat jemand Kontext, warum diese Ankündigung von 2025 geteilt wird? Scheint verzögert und noch nicht veröffentlicht zu sein?
darcien
I love podman and use it extensively, but am less sure how useful the machine functionality will be to me. I use KVM with virt-manager extensively, and could see how treating VMs as ephemeral like containers might be nice for some workflows, but I want my VMs to be stateful.
我喜欢 podman 并广泛使用，但不太确定机器功能对我有多有用。我大量使用 KVM 配 virt-manager，可以看到把 VM 当作像容器一样短暂的对某些工作流程可能不错，但我希望我的 VM 是有状态的。
私は podman を愛用していますが、マシン機能が自分にどれだけ役立つかは確信が持てません。KVM と virt-manager を広く使っていて、VM をコンテナのようにエフェメラルに扱うのはワークフローによっては良いかもしれませんが、VM はステートフルであってほしいです。
podman 을 좋아하고 광범위하게 사용하지만 머신 기능이 얼마나 유용할지는 확신이 없습니다. KVM 과 virt-manager 를 광범위하게 사용하고 있고, VM 을 컨테이너처럼 임시로 취급하는 것이 일부 워크플로에는 좋을 수 있지만 VM 이 상태 유지하길 원합니다.
Amo podman y lo uso extensivamente, pero no estoy seguro de qué tan útil será la funcionalidad de máquina para mí. Uso KVM con virt-manager extensivamente, y puedo ver cómo tratar las VMs como efímeras como contenedores podría ser bueno para algunos flujos de trabajo, pero quiero que mis VMs sean con estado.
Ich liebe podman und nutze es ausgiebig, bin mir aber nicht sicher, wie nützlich die Maschinen-Funktionalität für mich sein wird. Ich nutze KVM mit virt-manager ausgiebig und kann sehen, dass VMs als ephemer wie Container zu behandeln für manche Workflows schön sein könnte, aber ich will, dass meine VMs zustandsbehaftet sind.
freedomben