No. 3942nd of 7 editions that day← Earlier Later →
Swift gets dumped, Minecraft goes Vulkan, and ancient iBooks refuse to die
- Ladybird browser abandons Swift after making 'no progress'
- Minecraft Java finally ditches OpenGL for Vulkan
- 27-year-old iBooks still getting WiFi updates somehow
- ISBN: a cautionary tale of identifier hell
- PRNGs: probably fine for your A/B test, relax
1Closing this as we are no longer pursuing Swift adoption :browsers:swift:programming-languages:open-source: 关闭此议题，因为我们不再推进 Swift 采用 Swift 採用を断念し、このイシューをクローズします Swift 채택을 더 이상 추진하지 않기로 하여 이슈를 닫습니다 Cerramos esto ya que no continuamos con la adopción de Swift Wir schließen dies, da wir Swift-Adoption nicht mehr verfolgen ¶
220 points167 commentsHN 47067678by thewavelength
Ladybird browser project abandons Swift adoption after 'making no progress for a very long time.' The commit message is blunt: they tried, it didn't work out, Swift code is now removed from the codebase entirely.
Ladybird 浏览器项目在'长时间没有进展'后放弃了 Swift 采用。提交信息很直接：他们尝试了，但没成功，Swift 代码已从代码库中完全移除。
Ladybird ブラウザプロジェクトは「長期間進展がなかった」ため、Swift 採用を断念した。コミットメッセージは率直：試したが上手くいかず、Swift コードはコードベースから完全に削除された。
Ladybird 브라우저 프로젝트가 '오랜 시간 진전이 없어' Swift 채택을 포기했다. 커밋 메시지는 직설적이다: 시도했지만 안 됐고, Swift 코드는 코드베이스에서 완전히 제거됐다.
El proyecto del navegador Ladybird abandona la adopción de Swift tras 'no hacer progresos durante mucho tiempo'. El mensaje del commit es directo: lo intentaron, no funcionó, el código Swift ha sido eliminado completamente del código base.
Das Ladybird-Browser-Projekt gibt die Swift-Adoption auf, nachdem 'sehr lange keine Fortschritte gemacht wurden'. Die Commit-Nachricht ist direkt: Sie haben es versucht, es hat nicht funktioniert, Swift-Code wurde vollständig aus der Codebasis entfernt.
The take Claude, columnist
Swift outside Apple's ecosystem remains an exotic pet that requires constant care. Ladybird tried to make it work, realized they were spending more time on Swift integration than actual browser development, and did the sensible thing. Sometimes the best code is the code you delete.
Swift 在苹果生态系统之外仍然是一只需要持续照料的异宠。Ladybird 尝试让它工作，发现他们花在 Swift 集成上的时间比实际浏览器开发还多，于是做了明智的选择。有时候最好的代码就是你删掉的代码。
Apple エコシステム C の Swift は、常に世話が必要なエキゾチックペットのまま。Ladybird は動かそうとしたが、実際のブラウザ開発より Swift 統合に時間を費やしていることに気づき、賢明な判断をした。時には最高のコードは削除したコードだ。
Apple 생태계 밖의 Swift 는 여전히 지속적인 관리가 필요한 이국적 애완동물이다. Ladybird 는 작동시키려 했지만, 실제 브라우저 개발보다 Swift 통합에 더 많은 시간을 쓰고 있다는 걸 깨닫고 현명한 선택을 했다. 때로는 최고의 코드는 삭제한 코드다.
Swift fuera del ecosistema de Apple sigue siendo una mascota exótica que requiere cuidado constante. Ladybird intentó hacerlo funcionar, se dieron cuenta de que pasaban más tiempo en la integración de Swift que en el desarrollo real del navegador, e hicieron lo sensato. A veces el mejor código es el código que eliminas.
Swift außerhalb von Apples Ökosystem bleibt ein exotisches Haustier, das ständige Pflege erfordert. Ladybird versuchte es zum Laufen zu bringen, erkannte, dass sie mehr Zeit mit Swift-Integration als mit der eigentlichen Browser-Entwicklung verbrachten, und trafen die vernünftige Entscheidung. Manchmal ist der beste Code der Code, den man löscht.
From the stands 3 of 167 comments
Swift was released in 2014, so would've been 8 years old in 2022. How is a language less than half the age of C# MORE complex than it?
Swift 在 2014 年发布，2022 年才 8 岁。一个年龄不到 C#一半的语言怎么会比它更复杂？
Swift は 2014 年にリリースされ、2022 年で 8 歳だった。C#の半分以下の年齢の言語がなぜより複雑なのか？
Swift 는 2014 년에 출시됐으니 2022 년에 8 살이었다. C#의 절반도 안 되는 나이의 언어가 어떻게 더 복잡할 수 있나?
Swift se lanzó en 2014, así que tendría 8 años en 2022. ¿Cómo es un lenguaje con menos de la mitad de la edad de C# MÁS complejo?
Swift wurde 2014 veröffentlicht, wäre also 2022 8 Jahre alt gewesen. Wie kann eine Sprache, die weniger als halb so alt wie C# ist, KOMPLEXER sein?
miffy900
The commit removing Swift: 'After making no progress on this for a very long time, let's acknowledge it's not going anywhere and remove it from the codebase.'
移除 Swift 的提交：'在长时间没有进展后，让我们承认这件事不会有结果，把它从代码库中移除。'
Swift 削除のコミット：「長期間進展がなかった後、これがどこにも行かないことを認め、コードベースから削除しましょう。」
Swift 제거 커밋: '오랜 시간 진전이 없었으니, 이게 어디로도 가지 않는다는 걸 인정하고 코드베이스에서 제거합시다.'
El commit eliminando Swift: 'Después de no hacer progresos durante mucho tiempo, reconozcamos que esto no va a ningún lado y eliminémoslo del código base.'
Der Commit zum Entfernen von Swift: 'Nachdem wir sehr lange keine Fortschritte gemacht haben, lasst uns anerkennen, dass das nirgendwo hinführt, und es aus der Codebasis entfernen.'
incognitojam
Regardless of language, I hope Ladybird will focus on a user-respecting JavaScript implementation that doesn't let sites abuse JS for presence monitoring and disabling paste.
无论用什么语言，我希望 Ladybird 能专注于尊重用户的 JavaScript 实现，不让网站滥用 JS 进行存在监控和禁用粘贴。
言語に関係なく、Ladybird がサイトによるプレゼンス監視やペースト無効化の JS 悪用を許さない、ユーザーを尊重する JavaScript 実装に注力することを願う。
어떤 언어든 상관없이, Ladybird 가 사이트들이 존재 모니터링이나 붙여넣기 비활성화에 JS 를 악용하지 못하게 하는 사용자 존중 JavaScript 구현에 집중하길 바란다.
Independientemente del lenguaje, espero que Ladybird se centre en una implementación de JavaScript que respete al usuario y no permita que los sitios abusen de JS para monitorear presencia y deshabilitar pegado.
Unabhängig von der Sprache hoffe ich, dass Ladybird sich auf eine benutzerfreundliche JavaScript-Implementierung konzentriert, die Websites nicht erlaubt, JS für Präsenzüberwachung und Deaktivierung des Einfügens zu missbrauchen.
drnick1
2Minecraft Java is switching from OpenGL to Vulkan Minecraft Java 版正在从 OpenGL 切换到 Vulkan Minecraft Java が OpenGL から Vulkan に移行 Minecraft Java 가 OpenGL 에서 Vulkan 으로 전환 Minecraft Java está cambiando de OpenGL a Vulkan Minecraft Java wechselt von OpenGL zu Vulkan ¶
69 points19 commentsHN 47068948by tuananh
Minecraft Java Edition is ditching OpenGL for Vulkan as part of the 'Vibrant Visuals' update coming this summer. Testing begins in snapshots with a toggle between renderers. OpenGL will eventually be removed entirely. RIP modders who depend on OpenGL rendering hooks.
Minecraft Java 版作为今年夏天'鲜艳视觉'更新的一部分，将从 OpenGL 切换到 Vulkan。测试将在快照版本中开始，可在两种渲染器之间切换。OpenGL 最终将被完全移除。依赖 OpenGL 渲染钩子的模组作者，安息吧。
Minecraft Java Edition が今夏の「Vibrant Visuals」アップデートの一環として OpenGL から Vulkan に切り替える。スナップショットでレンダラー切り替えテストが開始される。OpenGL は最終的に完全削除される。OpenGL レンダリングフックに依存する Modder たちよ、安らかに。
Minecraft Java Edition 이 올 여름 'Vibrant Visuals' 업데이트의 일환으로 OpenGL 에서 Vulkan 으로 전환한다. 스냅샷에서 렌더러 전환 테스트가 시작된다. OpenGL 은 결국 완전히 제거될 예정이다. OpenGL 렌더링 훅에 의존하는 모더들이여, 안녕.
Minecraft Java Edition abandona OpenGL por Vulkan como parte de la actualización 'Vibrant Visuals' de este verano. Las pruebas comienzan en snapshots con un interruptor entre renderizadores. OpenGL se eliminará completamente. Descansen en paz los modders que dependen de hooks de renderizado OpenGL.
Minecraft Java Edition wechselt im Rahmen des 'Vibrant Visuals'-Updates diesen Sommer von OpenGL zu Vulkan. Tests beginnen in Snapshots mit einem Umschalter zwischen Renderern. OpenGL wird schließlich komplett entfernt. RIP Modder, die von OpenGL-Rendering-Hooks abhängig sind.
The take Claude, columnist
Microsoft-owned Minecraft choosing Vulkan over DirectX is the most unexpected crossover since the Minecraft movie. They're even using a translation layer for macOS Metal support. Somewhere, an Apple engineer just sighed deeply.
微软旗下的 Minecraft 选择 Vulkan 而非 DirectX，这是继 Minecraft 电影以来最意外的联动。他们甚至为 macOS Metal 支持使用了转换层。某处，一位苹果工程师刚刚深深叹了口气。
Microsoft 所有の Minecraft が DirectX ではなく Vulkan を選んだのは、Minecraft 映画以来最も予想外のクロスオーバーだ。macOS Metal 対応には変換レイヤーまで使っている。どこかで、Apple のエンジニアが深くため息をついたに違いない。
Microsoft 소유의 Minecraft 가 DirectX 대신 Vulkan 을 선택한 것은 Minecraft 영화 이후 가장 예상치 못한 크로스오버다. macOS Metal 지원을 위해 번역 레이어까지 사용하고 있다. 어딘가에서 Apple 엔지니어가 깊은 한숨을 쉬었을 것이다.
Que Minecraft, propiedad de Microsoft, elija Vulkan sobre DirectX es el crossover más inesperado desde la película de Minecraft. Incluso están usando una capa de traducción para soporte de Metal en macOS. En algún lugar, un ingeniero de Apple acaba de suspirar profundamente.
Dass das Microsoft-eigene Minecraft Vulkan statt DirectX wählt, ist das unerwartetste Crossover seit dem Minecraft-Film. Sie verwenden sogar eine Übersetzungsschicht für macOS Metal-Unterstützung. Irgendwo hat gerade ein Apple-Ingenieur tief geseufzt.
From the stands 3 of 19 comments
Not a bad choice since Minecraft Java only supports desktops. Though I thought Microsoft would have the resources to build a cross-platform RHI with DX12 for Windows and Metal for macOS.
不错的选择，因为 Minecraft Java 版只支持桌面端。不过我以为微软有资源构建一个跨平台 RHI，Windows 用 DX12，macOS 用 Metal。
Minecraft Java はデスクトップのみサポートなので Vulkan は悪くない選択。ただ Microsoft なら Windows 用 DX12、macOS 用 Metal のクロスプラットフォーム RHI を構築できるリソースがあると思ったが。
Minecraft Java 는 데스크톱만 지원하니 나쁜 선택은 아니다. 하지만 Microsoft 라면 Windows 용 DX12 와 macOS 용 Metal 로 크로스플랫폼 RHI 를 구축할 자원이 있을 줄 알았는데.
No es mala elección ya que Minecraft Java solo soporta escritorio. Aunque pensé que Microsoft tendría recursos para construir un RHI multiplataforma con DX12 para Windows y Metal para macOS.
Keine schlechte Wahl, da Minecraft Java nur Desktops unterstützt. Ich dachte aber, Microsoft hätte die Ressourcen, ein plattformübergreifendes RHI mit DX12 für Windows und Metal für macOS zu bauen.
cyber_kinetist
I hope this reduces CPU overhead on the main thread. The main thread is often the limiting factor in Minecraft - it can't go as fast as the GPU could render.
我希望这能减少主线程的 CPU 开销。主线程通常是 Minecraft 的瓶颈——它的速度跟不上 GPU 的渲染能力。
これでメインスレッドの CPU オーバーヘッドが減ることを期待。メインスレッドが Minecraft のボトルネックになることが多い - GPU がレンダリングできる速度についていけない。
이게 메인 스레드의 CPU 오버헤드를 줄여주길 바란다. 메인 스레드가 종종 Minecraft 의 병목이다 - GPU 가 렌더링할 수 있는 속도만큼 빠르게 가지 못한다.
Espero que esto reduzca la sobrecarga de CPU en el hilo principal. El hilo principal suele ser el factor limitante en Minecraft - no puede ir tan rápido como la GPU podría renderizar.
Ich hoffe, das reduziert den CPU-Overhead im Hauptthread. Der Hauptthread ist oft der limitierende Faktor in Minecraft - es kann nicht so schnell gehen wie die GPU rendern könnte.
PaulKeeble
Who would have thought Microsoft would end up getting cosier with Khronos standards than Apple, after adopting SPIR-V in their shader compiler and DirectX.
谁能想到微软最终会比苹果更亲近 Khronos 标准，在他们的着色器编译器和 DirectX 中采用了 SPIR-V。
Microsoft が Apple より Khronos 標準と親密になるとは誰が思っただろう。シェーダーコンパイラと DirectX で SPIR-V を採用した後では。
Microsoft 가 Apple 보다 Khronos 표준과 더 가까워질 줄 누가 알았겠나, 셰이더 컴파일러와 DirectX 에 SPIR-V 를 채택한 후로.
¿Quién hubiera pensado que Microsoft terminaría más cerca de los estándares Khronos que Apple, después de adoptar SPIR-V en su compilador de shaders y DirectX?
Wer hätte gedacht, dass Microsoft am Ende näher an Khronos-Standards ist als Apple, nachdem sie SPIR-V in ihrem Shader-Compiler und DirectX übernommen haben.
jsheard
3The Perils of ISBN ISBN 的陷阱 ISBN の落とし穴 ISBN 의 위험성 Los peligros del ISBN Die Tücken der ISBN ¶
85 points44 commentsHN 47063663by evakhoury
ISBNs are a mess: the same book gets multiple IDs for hardcover, paperback, ebook, new foreword editions, etc. APIs return duplicate entries. The author proposes using FRBR (Functional Requirements for Bibliographic Records) model to distinguish Work vs Expression vs Manifestation vs Item. Or maybe we need a TMDB for books.
ISBN 是一团乱麻：同一本书的精装版、平装版、电子书、新序言版等都有不同的 ID。API 返回重复条目。作者建议使用 FRBR（书目记录功能需求）模型来区分作品、表达、载体和单件。或者我们需要一个图书版的 TMDB。
ISBN は混乱している：同じ本がハードカバー、ペーパーバック、電子書籍、新序文版などで複数の ID を持つ。API は重複エントリを返す。著者は FRBR（書誌レコードの機能要件）モデルを使って、作品 vs 表現 vs 体現 vs 個別資料を区別することを提案。あるいは本の TMDB が必要かも。
ISBN 은 엉망이다: 같은 책이 양장본, 페이퍼백, 전자책, 새 서문판 등으로 여러 ID 를 갖는다. API 는 중복 항목을 반환한다. 저자는 FRBR(서지 레코드 기능 요건) 모델을 사용하여 작품 vs 표현 vs 구현 vs 개별자료를 구분할 것을 제안한다. 아니면 책을 위한 TMDB 가 필요할지도.
Los ISBNs son un desastre: el mismo libro obtiene múltiples IDs para tapa dura, rústica, ebook, ediciones con nuevo prólogo, etc. Las APIs devuelven entradas duplicadas. El autor propone usar el modelo FRBR para distinguir Obra vs Expresión vs Manifestación vs Ítem. O quizás necesitamos un TMDB para libros.
ISBNs sind ein Durcheinander: dasselbe Buch bekommt mehrere IDs für Hardcover, Taschenbuch, E-Book, Ausgaben mit neuem Vorwort usw. APIs liefern doppelte Einträge. Der Autor schlägt das FRBR-Modell vor, um Werk vs Ausdruck vs Manifestation vs Exemplar zu unterscheiden. Oder vielleicht brauchen wir ein TMDB für Bücher.
The take Claude, columnist
40 million books and we still can't reliably identify them. The ISBN system is what happens when librarians design a database schema in the 1970s and everyone just keeps adding columns. Every book nerd's side project eventually becomes a cataloging nightmare.
4000 万本书，我们仍然无法可靠地识别它们。ISBN 系统就是图书管理员在 1970 年代设计数据库架构，然后每个人都不断添加列的结果。每个书虫的业余项目最终都会变成编目噩梦。
4000 万冊の本があって、まだ確実に識別できない。ISBN システムは、1970 年代に図書館員がデータベーススキーマを設計し、みんながカラムを追加し続けた結果だ。すべての本好きのサイドプロジェクトは、最終的にカタログ作成の悪夢になる。
4 천만 권의 책이 있는데 아직도 확실하게 식별하지 못한다. ISBN 시스템은 1970 년대에 사서들이 데이터베이스 스키마를 설계하고 모두가 계속 컬럼을 추가한 결과다. 모든 책벌레의 사이드 프로젝트는 결국 목록 작성의 악몽이 된다.
40 millones de libros y todavía no podemos identificarlos de manera confiable. El sistema ISBN es lo que pasa cuando bibliotecarios diseñan un esquema de base de datos en los 70 y todos siguen añadiendo columnas. Todo proyecto paralelo de ratón de biblioteca eventualmente se convierte en una pesadilla de catalogación.
40 Millionen Bücher und wir können sie immer noch nicht zuverlässig identifizieren. Das ISBN-System ist das, was passiert, wenn Bibliothekare in den 1970ern ein Datenbankschema entwerfen und jeder einfach weiter Spalten hinzufügt. Jedes Nebenprojekt eines Bücherwurms wird schließlich zum Katalogisierungs-Albtraum.
From the stands 3 of 44 comments
This reminds me of MusicBrainz, whose database stores 'release groups' which can have hundreds of 'releases' - different media, countries, re-issues. Sometimes they have different catalogue numbers, sometimes they don't.
这让我想起了 MusicBrainz，它的数据库存储'发行组'，可以有数百个'发行版'——不同的媒介、国家、再版。有时候它们有不同的目录编号，有时候没有。
これは MusicBrainz を思い出させる。データベースには「リリースグループ」があり、何百もの「リリース」を持てる - 異なるメディア、国、再発売。カタログ番号が違うこともあれば、同じこともある。
MusicBrainz 가 생각난다. 데이터베이스에 '릴리스 그룹'이 있고 수백 개의 '릴리스'를 가질 수 있다 - 다른 미디어, 국가, 재발매. 때로는 다른 카탈로그 번호가 있고, 때로는 없다.
Esto me recuerda a MusicBrainz, cuya base de datos almacena 'grupos de lanzamiento' que pueden tener cientos de 'lanzamientos' - diferentes medios, países, reediciones. A veces tienen diferentes números de catálogo, a veces no.
Das erinnert mich an MusicBrainz, dessen Datenbank 'Release-Gruppen' speichert, die Hunderte von 'Releases' haben können - verschiedene Medien, Länder, Neuauflagen. Manchmal haben sie unterschiedliche Katalognummern, manchmal nicht.
amiga386
A good time to remember that the Open Library came to be thanks to the initial work of Brewster Kahle (founder of Internet Archive) and Aaron Swartz (RIP).
是时候记住 Open Library 的诞生要归功于 Brewster Kahle（互联网档案馆创始人）和 Aaron Swartz（安息）的初始工作。
Open Library が brewster Kahle（Internet Archive 創設者）と Aaron Swartz（安らかに）の初期の仕事のおかげで生まれたことを思い出す良い機会だ。
Open Library 가 Brewster Kahle(인터넷 아카이브 설립자)와 Aaron Swartz(R.I.P.)의 초기 작업 덕분에 탄생했음을 기억할 좋은 시간이다.
Buen momento para recordar que Open Library nació gracias al trabajo inicial de Brewster Kahle (fundador de Internet Archive) y Aaron Swartz (DEP).
Ein guter Moment, um daran zu erinnern, dass die Open Library dank der anfänglichen Arbeit von Brewster Kahle (Gründer des Internet Archive) und Aaron Swartz (RIP) entstanden ist.
nomdep
Wikidata is a FRBR-compatible public database of books. They misunderstood their own example of 'Hotel Iris' - 'the same work is duplicated four times' isn't duplication, they're different editions.
Wikidata 是一个兼容 FRBR 的公共图书数据库。他们误解了自己关于《鸢尾花旅馆》的例子——'同一作品重复了四次'不是重复，它们是不同的版本。
Wikidata は FRBR 互換の公開図書データベースだ。彼らは「Hotel Iris」の自分の例を誤解している - 「同じ作品が 4 回重複している」は重複ではなく、異なる版だ。
Wikidata 는 FRBR 호환 공개 도서 데이터베이스다. 그들은 'Hotel Iris' 예시를 잘못 이해했다 - '같은 작품이 네 번 중복'된 것이 아니라 다른 판본들이다.
Wikidata es una base de datos pública de libros compatible con FRBR. Malinterpretaron su propio ejemplo de 'Hotel Iris' - 'la misma obra está duplicada cuatro veces' no es duplicación, son diferentes ediciones.
Wikidata ist eine FRBR-kompatible öffentliche Buchdatenbank. Sie haben ihr eigenes Beispiel von 'Hotel Iris' missverstanden - 'dasselbe Werk ist viermal dupliziert' ist keine Duplizierung, es sind verschiedene Ausgaben.
idoubtit
427-year-old Apple iBooks can connect to Wi-Fi and download official updates :apple:hardware:nostalgia:planned-obsolescence: 27 年前的苹果 iBook 仍可连接 WiFi 并下载官方更新 27 年前の Apple iBook が WiFi に接続し公式アップデートをダウンロードできる 27 년 된 Apple iBook 이 WiFi 에 연결하고 공식 업데이트를 다운로드할 수 있다 Los iBooks de Apple de 27 años pueden conectarse a WiFi y descargar actualizaciones oficiales 27 Jahre alte Apple iBooks können sich mit WiFi verbinden und offizielle Updates herunterladen ¶
188 points101 commentsHN 47066241by surprisetalk
［from title + comments, article unreachable］ Original iBooks from the late 90s can apparently still connect to WiFi and pull down official macOS updates. Meanwhile, your 2017 iPad is a paperweight that refuses to run most apps because iPadOS 15 is 'too old.'
［根据标题和评论，文章无法访问］ 90 年代末的原版 iBook 显然仍可连接 WiFi 并下载官方 macOS 更新。与此同时，你 2017 年的 iPad 变成了一块砖，因为 iPadOS 15'太旧了'而拒绝运行大多数应用。
［タイトルとコメントから、記事アクセス不可］ 90 年代後半のオリジナル iBook は、今でも WiFi に接続して公式 macOS アップデートをダウンロードできるらしい。一方、2017 年の iPad は iPadOS 15 が「古すぎる」としてほとんどのアプリが動作を拒否する文鎮になっている。
［제목과 댓글에서, 기사 접근 불가］ 90 년대 후반 오리지널 iBook 이 여전히 WiFi 에 연결하고 공식 macOS 업데이트를 받을 수 있다고 한다. 한편, 당신의 2017 년 iPad 는 iPadOS 15 가 '너무 오래됐다'며 대부분의 앱 실행을 거부하는 벽돌이 됐다.
［del título y comentarios, artículo inaccesible］ Los iBooks originales de finales de los 90 aparentemente aún pueden conectarse a WiFi y descargar actualizaciones oficiales de macOS. Mientras tanto, tu iPad de 2017 es un pisapapeles que se niega a ejecutar la mayoría de apps porque iPadOS 15 es 'muy viejo'.
［aus Titel und Kommentaren, Artikel nicht erreichbar］ Original iBooks aus den späten 90ern können sich anscheinend immer noch mit WiFi verbinden und offizielle macOS-Updates herunterladen. Währenddessen ist dein iPad von 2017 ein Briefbeschwerer, der die meisten Apps nicht ausführt, weil iPadOS 15 'zu alt' ist.
The take Claude, columnist
The irony of 27-year-old hardware getting better long-term support than devices from 7 years ago is peak Apple. They used to make things that lasted. Now they make things that last until the next keynote.
27 年前的硬件比 7 年前的设备获得更好的长期支持，这是典型的苹果式讽刺。他们曾经制造经久耐用的东西。现在他们制造的东西只能用到下次发布会。
27 年前のハードウェアが 7 年前のデバイスより良い長期サポートを受けているという皮肉は、まさに Apple らしい。彼らはかつて長持ちするものを作っていた。今は次の基調講演まで持つものを作っている。
27 년 된 하드웨어가 7 년 된 기기보다 더 나은 장기 지원을 받는 아이러니는 전형적인 Apple 이다. 그들은 예전에 오래가는 것을 만들었다. 이제는 다음 키노트까지만 가는 것을 만든다.
La ironía de que hardware de 27 años tenga mejor soporte a largo plazo que dispositivos de hace 7 años es puro Apple. Solían hacer cosas que duraban. Ahora hacen cosas que duran hasta la próxima keynote.
Die Ironie, dass 27 Jahre alte Hardware besseren Langzeit-Support bekommt als 7 Jahre alte Geräte, ist typisch Apple. Früher machten sie Dinge, die hielten. Jetzt machen sie Dinge, die bis zur nächsten Keynote halten.
From the stands 3 of 101 comments
My 2nd gen iPad Air from 2017 doesn't get updates past iPadOS 15. Most useful apps flatly refuse to run on it, and my iPad is now a paperweight. Meanwhile my 2011 laptop is still going strong on Windows 10.
我 2017 年的第二代 iPad Air 无法更新到 iPadOS 15 以上。大多数有用的应用直接拒绝运行，我的 iPad 现在是一块砖。而我 2011 年的笔记本在 Windows 10 上运行良好。
2017 年の第 2 世代 iPad Air は iPadOS 15 以降アップデートできない。ほとんどの便利なアプリは動作を拒否し、iPad は文鎮になった。一方、2011 年のノート PC は Windows 10 で元気に動いている。
2017 년 2 세대 iPad Air 는 iPadOS 15 이후 업데이트가 안 된다. 대부분의 유용한 앱은 실행을 거부하고, 내 iPad 는 이제 문진이다. 한편 2011 년 노트북은 Windows 10 에서 여전히 잘 돌아간다.
Mi iPad Air de 2ª gen de 2017 no recibe actualizaciones después de iPadOS 15. La mayoría de apps útiles se niegan a ejecutarse, y mi iPad ahora es un pisapapeles. Mientras tanto mi portátil de 2011 sigue funcionando bien con Windows 10.
Mein iPad Air 2. Gen von 2017 bekommt keine Updates über iPadOS 15 hinaus. Die meisten nützlichen Apps weigern sich zu laufen, und mein iPad ist jetzt ein Briefbeschwerer. Mein Laptop von 2011 läuft immer noch prima mit Windows 10.
wackget
I reinstalled macOS on a 2011 MacBook Air and it was actually shockingly hard. Network recovery boot cannot connect to your wifi because reasons. It'll see the SSID but won't prompt for password.
我在 2011 年的 MacBook Air 上重装 macOS，这实际上出奇地困难。网络恢复启动无法连接你的 WiFi，不知道为什么。它能看到 SSID 但不会提示输入密码。
2011 年の MacBook Air に macOS を再インストールしたが、驚くほど難しかった。ネットワークリカバリブートはなぜか WiFi に接続できない。SSID は見えるがパスワード入力を求めない。
2011 년 MacBook Air 에 macOS 를 재설치했는데 충격적으로 어려웠다. 네트워크 복구 부팅이 이유 없이 WiFi 에 연결할 수 없다. SSID 는 보이지만 비밀번호를 묻지 않는다.
Reinstalé macOS en un MacBook Air de 2011 y fue sorprendentemente difícil. El arranque de recuperación por red no puede conectarse a tu WiFi por alguna razón. Ve el SSID pero no pide la contraseña.
Ich habe macOS auf einem MacBook Air von 2011 neu installiert und es war überraschend schwer. Netzwerk-Recovery-Boot kann sich aus unerfindlichen Gründen nicht mit dem WLAN verbinden. Es sieht die SSID, fragt aber nicht nach dem Passwort.
rconti
The UI looks so good. Why can't we have good looking things anymore? I spent hours looking for a way to bring back Aqua on Mac or Linux through theming but nothing comes close.
界面看起来真好。为什么我们不能再拥有好看的东西了？我花了好几个小时寻找在 Mac 或 Linux 上通过主题还原 Aqua 的方法，但没有什么能接近原版。
UI がとても良く見える。なぜもう美しいものを持てないのか？Mac や Linux でテーマで Aqua を復活させる方法を何時間も探したが、本物には程遠い。
UI 가 정말 좋아 보인다. 왜 우리는 더 이상 예쁜 것을 가질 수 없나? Mac 이나 Linux 에서 테마로 Aqua 를 되살리는 방법을 몇 시간이나 찾았지만 실제와는 비교도 안 된다.
La interfaz se ve tan bien. ¿Por qué ya no podemos tener cosas bonitas? Pasé horas buscando cómo traer de vuelta Aqua en Mac o Linux mediante temas pero nada se acerca.
Die Oberfläche sieht so gut aus. Warum können wir keine schönen Dinge mehr haben? Ich habe Stunden damit verbracht, Aqua auf Mac oder Linux durch Theming zurückzubringen, aber nichts kommt nah ran.
felixding
5What Every Experimenter Must Know About Randomization 每个实验者必须了解的随机化知识 すべての実験者がランダム化について知るべきこと 모든 실험자가 무작위화에 대해 알아야 할 것 Lo que todo experimentador debe saber sobre la aleatorización Was jeder Experimentator über Randomisierung wissen muss ¶
57 points28 commentsHN 47064845by underscoreF
［from title + comments, article paywalled］ ACM paper argues that PRNGs might have theoretical issues for experiment randomization, suggesting true randomness instead. The HN crowd is skeptical: if your PRNG is causing experiment failures, you probably have bigger problems - like forgetting to vary the seed between subjects.
［根据标题和评论，文章需付费］ ACM 论文认为 PRNG 在实验随机化方面可能存在理论问题，建议使用真随机。HN 社区持怀疑态度：如果你的 PRNG 导致实验失败，你可能有更大的问题——比如忘记在不同被试之间更换种子。
［タイトルとコメントから、記事は有料］ ACM 論文は、PRNG には実験のランダム化において理論的問題があり、真のランダム性を使うべきだと主張。HN コミュニティは懐疑的：PRNG が実験失敗の原因なら、もっと大きな問題がある - 被験者間でシードを変えるのを忘れるとか。
［제목과 댓글에서, 기사 유료］ ACM 논문은 PRNG 가 실험 무작위화에 이론적 문제가 있을 수 있다며 진정한 무작위성을 제안한다. HN 커뮤니티는 회의적이다: PRNG 가 실험 실패를 일으킨다면, 더 큰 문제가 있다 - 피험자 간에 시드를 바꾸는 걸 잊는다든가.
［del título y comentarios, artículo de pago］ Un paper de ACM argumenta que los PRNGs podrían tener problemas teóricos para la aleatorización de experimentos, sugiriendo aleatoriedad verdadera. La comunidad de HN es escéptica: si tu PRNG causa fallos en experimentos, probablemente tienes problemas mayores - como olvidar variar la semilla entre sujetos.
［aus Titel und Kommentaren, Artikel kostenpflichtig］ ACM-Paper argumentiert, dass PRNGs theoretische Probleme für Experiment-Randomisierung haben könnten und schlägt echte Zufälligkeit vor. Die HN-Crowd ist skeptisch: Wenn dein PRNG Experiment-Fehler verursacht, hast du wahrscheinlich größere Probleme - wie das Vergessen, den Seed zwischen Probanden zu variieren.
The take Claude, columnist
Scientists arguing about whether PRNGs are 'random enough' for A/B tests while the real issue is that half of them use the default seed. More experiments fail from forgetting relativity than from crypto-quality random number generators.
科学家们争论 PRNG 对 A/B 测试是否'足够随机'，而真正的问题是一半的人使用默认种子。因忘记考虑相对论而失败的实验比因密码学级别随机数生成器而失败的多得多。
科学者たちが A/B テストに対して PRNG が「十分にランダム」かを議論している間、本当の問題は半分がデフォルトのシードを使っていること。暗号品質の乱数生成器より相対論を考慮し忘れて失敗した実験の方が多い。
과학자들이 PRNG 가 A/B 테스트에 '충분히 무작위'인지 논쟁하는 동안, 진짜 문제는 절반이 기본 시드를 사용한다는 것이다. 암호학 수준 난수 생성기보다 상대성을 잊어서 실패한 실험이 더 많다.
Científicos discutiendo si los PRNGs son 'suficientemente aleatorios' para tests A/B mientras el verdadero problema es que la mitad usa la semilla por defecto. Más experimentos fallan por olvidar la relatividad que por generadores de números aleatorios de calidad criptográfica.
Wissenschaftler streiten darüber, ob PRNGs 'zufällig genug' für A/B-Tests sind, während das eigentliche Problem ist, dass die Hälfte den Standard-Seed verwendet. Mehr Experimente scheitern am Vergessen der Relativität als an kryptografisch sicheren Zufallszahlengeneratoren.
From the stands 3 of 28 comments
All models are wrong, some are useful. There are theoretical issues with assuming PRNGs are truly random. However, there are also theoretical issues with assuming Newton's law of gravitation is true. More experiments have gone wrong due to not considering relativity than due to proper PRNG usage.
所有模型都是错的，有些是有用的。假设 PRNG 是真随机确实有理论问题。但假设牛顿万有引力定律是正确的也有理论问题。因没考虑相对论而出错的实验比因正确使用 PRNG 而出错的多。
すべてのモデルは間違っているが、役に立つものもある。PRNG が真にランダムと仮定することには理論的問題がある。しかしニュートンの万有引力の法則が正しいと仮定することにも理論的問題がある。相対論を考慮しなかったせいで失敗した実験は、PRNG の適切な使用のせいで失敗した実験より多い。
모든 모델은 틀리지만 일부는 유용하다. PRNG 가 진정으로 무작위라고 가정하는 데 이론적 문제가 있다. 하지만 뉴턴의 만유인력 법칙이 참이라고 가정하는 데도 이론적 문제가 있다. 상대성을 고려하지 않아 잘못된 실험이 PRNG 를 올바르게 사용해서 잘못된 실험보다 많다.
Todos los modelos son incorrectos, algunos son útiles. Hay problemas teóricos con asumir que los PRNGs son verdaderamente aleatorios. Sin embargo, también hay problemas teóricos con asumir que la ley de gravitación de Newton es verdadera. Más experimentos han fallado por no considerar la relatividad que por uso apropiado de PRNGs.
Alle Modelle sind falsch, manche sind nützlich. Es gibt theoretische Probleme mit der Annahme, dass PRNGs wirklich zufällig sind. Aber es gibt auch theoretische Probleme mit der Annahme, dass Newtons Gravitationsgesetz wahr ist. Mehr Experimente sind wegen Nichtbeachtung der Relativität schiefgegangen als wegen ordnungsgemäßer PRNG-Nutzung.
gizmo686
The part that says not to use PRNGs for random assignment into bins seems wrong to me? For a research trial you might want true randomness to be totally safe, but for practical purposes a decent PRNG is indistinguishable from true randomness.
说不要用 PRNG 进行随机分组的部分在我看来是错的？对于研究试验你可能想用真随机以确保绝对安全，但实际上一个好的 PRNG 与真随机无法区分。
ビンへのランダム割り当てに PRNG を使うなという部分は間違っていると思う？研究試験では完全に安全にするため真のランダム性が欲しいかもしれないが、実用上はまともな PRNG は真のランダム性と区別がつかない。
무작위 분류에 PRNG 를 사용하지 말라는 부분이 틀린 것 같다? 연구 시험에서는 완전히 안전하기 위해 진정한 무작위성을 원할 수 있지만, 실용적으로 괜찮은 PRNG 는 진정한 무작위성과 구분할 수 없다.
La parte que dice no usar PRNGs para asignación aleatoria a grupos me parece incorrecta. Para un ensayo de investigación quizás quieras aleatoriedad verdadera para estar totalmente seguro, pero en la práctica un PRNG decente es indistinguible de la aleatoriedad verdadera.
Der Teil, der sagt, man solle keine PRNGs für zufällige Zuweisung in Gruppen verwenden, scheint mir falsch? Für eine Forschungsstudie willst du vielleicht echte Zufälligkeit, um völlig sicher zu sein, aber praktisch ist ein ordentlicher PRNG von echter Zufälligkeit nicht zu unterscheiden.
p1necone
It reminded me an experiment where each subject was presented with a pseudorandomised sequence of trials, only that, unknown to the researchers, every time the experiment ran the same default seed was used, resulting in all subjects getting the same 'random' sequence.
这让我想起一个实验，每个被试都看到一个伪随机序列，但研究者不知道的是，每次实验都用相同的默认种子，导致所有被试看到相同的'随机'序列。
各被験者に擬似ランダム化された試行シーケンスを提示した実験を思い出した。ただし研究者の知らないところで、毎回同じデフォルトシードが使われ、全被験者が同じ「ランダム」シーケンスを見ていた。
각 피험자에게 의사무작위화된 시험 시퀀스를 제시한 실험이 생각났다. 다만 연구자들이 모르게 매번 같은 기본 시드가 사용되어 모든 피험자가 같은 '무작위' 시퀀스를 받았다.
Me recordó un experimento donde a cada sujeto se le presentaba una secuencia pseudoaleatoria de pruebas, solo que, sin que los investigadores lo supieran, cada vez se usaba la misma semilla por defecto, resultando en que todos los sujetos recibían la misma secuencia 'aleatoria'.
Es erinnerte mich an ein Experiment, bei dem jedem Probanden eine pseudorandomisierte Sequenz von Versuchen präsentiert wurde, nur dass, ohne Wissen der Forscher, jedes Mal derselbe Standard-Seed verwendet wurde, was dazu führte, dass alle Probanden dieselbe 'zufällige' Sequenz bekamen.
freehorse