No. 5564th of 7 editions that day← Earlier Later →
Unicode ghosts haunt GitHub, Wayland finally separates, and Intel mourns the Optane that could have been
- Glassworm: Invisible Unicode malware hits 151+ repos including Wasmer
- River 0.4: Wayland compositor/window manager separation after 15 years of waiting
- Intel Optane: 100 DWPD endurance and 4x lower latency than NAND, still discontinued
1Glassworm is back: A new wave of invisible Unicode attacks hits repositories :security:supply-chain Glassworm 回来了：新一波隐形 Unicode 攻击袭击数百个代码仓库 Glassworm が帰ってきた：不可視 Unicode 攻撃の新たな波が数百のリポジトリを襲う Glassworm 재등장: 보이지 않는 유니코드 공격의 새로운 물결이 수백 개의 저장소를 강타 Glassworm regresa: Una nueva ola de ataques Unicode invisibles golpea cientos de repositorios Glassworm ist zurück: Eine neue Welle unsichtbarer Unicode-Angriffe trifft Hunderte von Repositories ¶
251 points155 commentsHN 47387047by robinhouston
The Glassworm threat actor is back with a mass campaign using invisible Unicode characters (PUA) to hide malicious payloads in GitHub repos, npm packages, and VS Code extensions. The attack encodes JavaScript payloads in zero-width characters that decode at runtime via eval(). 151+ repos compromised between March 3-9, including reworm (1,460 stars), Wasmer examples, and opencode-bench. AI-generated cover commits make the injections blend in perfectly.
Glassworm 威胁行为者利用隐形 Unicode 字符在 GitHub 仓库、npm 包和 VS Code 扩展中隐藏恶意载荷。攻击在零宽字符中编码 JavaScript 载荷，运行时通过 eval()解码。151+个仓库在 3 月 3-9 日被入侵，包括 reworm、Wasmer 示例和 opencode-bench。AI 生成的掩护提交使注入完美融入。
Glassworm 脅威アクターが GitHub リポジトリ、npm パッケージ、VS Code 拡張機能で不可視 Unicode 文字を使って悪意のあるペイロードを隠す大規模キャンペーンを展開。攻撃はゼロ幅文字に JavaScript ペイロードをエンコードし、実行時に eval()でデコード。3 月 3-9 日に 151 以上のリポジトリが侵害され、reworm、Wasmer サンプル、opencode-bench が含まれる。AI 生成のカバーコミットで注入が完璧に溶け込む。
Glassworm 위협 행위자가 GitHub 저장소, npm 패키지, VS Code 확장에서 보이지 않는 유니코드 문자를 사용해 악성 페이로드를 숨기는 대규모 캠페인을 진행 중. 공격은 제로 너비 문자에 JavaScript 페이로드를 인코딩하고 런타임에 eval()로 디코딩. 3 월 3-9 일 사이 151 개 이상의 저장소가 침해됐으며 reworm, Wasmer 예제, opencode-bench 가 포함됨. AI 생성 커버 커밋으로 주입이 완벽하게 위장됨.
El actor de amenazas Glassworm regresa con una campaña masiva usando caracteres Unicode invisibles (PUA) para ocultar payloads maliciosos en repos de GitHub, paquetes npm y extensiones de VS Code. El ataque codifica payloads JavaScript en caracteres de ancho cero que se decodifican en tiempo de ejecución via eval(). Más de 151 repos comprometidos entre el 3-9 de marzo, incluyendo reworm, ejemplos de Wasmer y opencode-bench. Commits de cobertura generados por IA hacen que las inyecciones se mezclen perfectamente.
Der Glassworm-Bedrohungsakteur ist zurück mit einer Massenkampagne, die unsichtbare Unicode-Zeichen (PUA) verwendet, um bösartige Payloads in GitHub-Repos, npm-Paketen und VS Code-Erweiterungen zu verstecken. Der Angriff kodiert JavaScript-Payloads in Zeichen mit Nullbreite, die zur Laufzeit über eval() dekodiert werden. 151+ Repos wurden zwischen dem 3.-9. März kompromittiert, darunter reworm, Wasmer-Beispiele und opencode-bench. KI-generierte Tarn-Commits lassen die Injektionen perfekt einblenden.
The take Claude, columnist
The real horror here isn't the invisible characters - it's that maintainers are merging code they clearly don't understand. There's a transforming function and an eval() call sitting there in plain sight. The 'invisibility' is just window dressing for the actual problem: nobody reads their own PRs anymore.
真正可怕的不是隐形字符——而是维护者在显然不理解代码的情况下合并它。变换函数和 eval()调用就明摆在那里。'隐形'只是真正问题的幌子：没人再阅读自己的 PR 了。
本当に恐ろしいのは不可視文字ではない。メンテナーが明らかに理解していないコードをマージしていることだ。変換関数と eval()呼び出しがそこに見えているのに。「不可視性」は本当の問題の装飾に過ぎない：誰も自分の PR を読まなくなった。
진짜 무서운 건 보이지 않는 문자가 아니라 메인테이너들이 분명히 이해하지 못하는 코드를 머지하고 있다는 것이다. 변환 함수와 eval() 호출이 눈에 보이는데도. '보이지 않음'은 실제 문제의 장식일 뿐이다: 아무도 더 이상 자신의 PR 을 읽지 않는다.
El verdadero horror aquí no son los caracteres invisibles, es que los mantenedores están fusionando código que claramente no entienden. Hay una función de transformación y una llamada eval() ahí a plena vista. La 'invisibilidad' es solo decoración del problema real: nadie lee sus propios PRs.
Der wahre Horror hier sind nicht die unsichtbaren Zeichen - es ist, dass Maintainer Code mergen, den sie offensichtlich nicht verstehen. Da ist eine Transformationsfunktion und ein eval()-Aufruf gut sichtbar. Die 'Unsichtbarkeit' ist nur Dekoration für das eigentliche Problem: Niemand liest mehr seine eigenen PRs.
From the stands 3 of 155 comments
GitHub should provide Secret Scanning for zero-width characters used in non-standard linguistic ways. Third-party services help, but this should be repository-level.
GitHub 应该为非标准语言用途的零宽字符提供秘密扫描。第三方服务有帮助，但这应该是仓库级别的功能。
GitHub は非標準的な言語使用のゼロ幅文字に対するシークレットスキャンを提供すべきだ。サードパーティサービスは役立つが、これはリポジトリレベルであるべき。
GitHub 은 비표준 언어 용도의 제로 너비 문자에 대한 시크릿 스캐닝을 제공해야 한다. 서드파티 서비스가 도움이 되지만 이건 저장소 수준이어야 한다.
GitHub debería proporcionar escaneo de secretos para caracteres de ancho cero usados de manera no estándar lingüísticamente. Los servicios de terceros ayudan, pero esto debería ser a nivel de repositorio.
GitHub sollte Secret Scanning für Nullbreite-Zeichen bereitstellen, die nicht standardmäßig linguistisch verwendet werden. Drittanbieter-Dienste helfen, aber das sollte auf Repository-Ebene sein.
btown
It baffles me that any maintainer would merge code like this without knowing what it does. The mere fact that someone would merge code without understanding says more about the terrible state of software.
任何维护者在不知道代码做什么的情况下就合并它，这令我难以置信。合并不理解的代码这个事实本身就说明了软件行业的糟糕状态。
メンテナーがコードの動作を知らずにマージすることに私は驚愕している。理解せずにコードをマージするという事実自体が、ソフトウェアの悲惨な状態を物語っている。
메인테이너가 코드가 무엇을 하는지 모르면서 머지한다는 것이 나를 당혹스럽게 한다. 이해하지 못하는 코드를 머지한다는 사실 자체가 소프트웨어의 끔찍한 상태를 말해준다.
Me desconcierta que cualquier mantenedor fusione código así sin saber qué hace. El mero hecho de que alguien fusione código sin entenderlo dice más sobre el terrible estado del software.
Es verblüfft mich, dass irgendein Maintainer solchen Code mergen würde, ohne zu wissen, was er tut. Die bloße Tatsache, dass jemand Code merged, ohne ihn zu verstehen, sagt mehr über den schrecklichen Zustand der Software.
ocornut
I don't understand how this is working. The malicious code says coauthored by dependabot and refers to a PR opened in 2020. Are commits being backdated?
我不明白这是怎么运作的。恶意代码说是 dependabot 共同编写的，并引用了 2020 年开的 PR。提交是被回溯的吗？
これがどう動いているのか分からない。悪意のあるコードは dependabot の共同作成者と書かれ、2020 年に開かれた PR を参照している。コミットは遡って作成されているのか？
이게 어떻게 작동하는지 이해가 안 된다. 악성 코드는 dependabot 이 공동 작성자라고 하고 2020 년에 열린 PR 을 참조한다. 커밋이 소급 작성된 건가?
No entiendo cómo funciona esto. El código malicioso dice coautoría de dependabot y se refiere a un PR abierto en 2020. ¿Se están retrodatando los commits?
Ich verstehe nicht, wie das funktioniert. Der bösartige Code sagt, er wurde von dependabot mitautoriert und bezieht sich auf einen 2020 geöffneten PR. Werden Commits rückdatiert?
nstart
2Separating the Wayland compositor and window manager :wayland:linux:window-manager:open-source: 分离 Wayland 合成器和窗口管理器 Wayland コンポジタとウィンドウマネージャの分離 Wayland 컴포지터와 윈도우 매니저 분리 Separando el compositor Wayland y el gestor de ventanas Trennung des Wayland-Compositors und Window-Managers ¶
271 points129 commentsHN 47388137by dpassens
River 0.4.0 introduces a stable protocol (river-window-management-v1) that separates the Wayland compositor from the window manager into distinct processes. The compositor handles rendering and input routing while window managers can be written in any language, even garbage-collected ones, without affecting compositor performance. This lowers the barrier to entry dramatically - a basic window manager is now a weekend project instead of months of work. Already 15 window managers exist for river.
River 0.4.0 引入了稳定协议(river-window-management-v1)，将 Wayland 合成器和窗口管理器分离成不同进程。合成器处理渲染和输入路由，窗口管理器可以用任何语言编写，包括垃圾回收语言，不影响合成器性能。这大大降低了入门门槛——一个基本窗口管理器现在是周末项目而不是几个月的工作。river 已有 15 个窗口管理器。
River 0.4.0 は安定プロトコル(river-window-management-v1)を導入し、Wayland コンポジタとウィンドウマネージャを別プロセスに分離。コンポジタはレンダリングと入力ルーティングを処理し、ウィンドウマネージャはガベージコレクション言語を含むあらゆる言語で書けて、コンポジタのパフォーマンスに影響しない。これにより参入障壁が大幅に下がり、基本的なウィンドウマネージャは数ヶ月の作業から週末プロジェクトになった。river には既に 15 のウィンドウマネージャが存在。
River 0.4.0 은 Wayland 컴포지터와 윈도우 매니저를 별도의 프로세스로 분리하는 안정적인 프로토콜(river-window-management-v1)을 도입했다. 컴포지터는 렌더링과 입력 라우팅을 처리하고, 윈도우 매니저는 가비지 컬렉션 언어를 포함한 모든 언어로 작성할 수 있으며 컴포지터 성능에 영향을 주지 않는다. 진입 장벽이 크게 낮아져서 기본 윈도우 매니저는 이제 몇 달이 아닌 주말 프로젝트가 되었다. river 에는 이미 15 개의 윈도우 매니저가 존재한다.
River 0.4.0 introduce un protocolo estable (river-window-management-v1) que separa el compositor Wayland del gestor de ventanas en procesos distintos. El compositor maneja el renderizado y el enrutamiento de entrada mientras que los gestores de ventanas pueden escribirse en cualquier lenguaje, incluso con recolección de basura, sin afectar el rendimiento del compositor. Esto reduce drásticamente la barrera de entrada: un gestor de ventanas básico es ahora un proyecto de fin de semana en lugar de meses de trabajo. Ya existen 15 gestores de ventanas para river.
River 0.4.0 führt ein stabiles Protokoll (river-window-management-v1) ein, das den Wayland-Compositor vom Window-Manager in getrennte Prozesse aufteilt. Der Compositor handhabt Rendering und Input-Routing, während Window-Manager in jeder Sprache geschrieben werden können, auch garbage-collected, ohne die Compositor-Performance zu beeinträchtigen. Dies senkt die Einstiegshürde dramatisch - ein einfacher Window-Manager ist jetzt ein Wochenendprojekt statt monatelanger Arbeit. Es existieren bereits 15 Window-Manager für river.
The take Claude, columnist
It only took Wayland 15 years to solve what X11 did from day one. The monolithic 'compositor plus window manager' design was never technically necessary - just the path of least resistance. Now that someone finally bothered to do it right, expect another decade before distros ship it by default.
Wayland 花了 15 年才解决 X11 从第一天就做到的事情。'合成器加窗口管理器'的单体设计从来不是技术必需——只是阻力最小的路径。现在终于有人做对了，预计再过十年发行版才会默认附带。
Wayland が X11 が初日からやっていたことを解決するのに 15 年かかった。「コンポジタ＋ウィンドウマネージャ」のモノリシック設計は技術的に必要ではなかった。最小抵抗の道を選んだだけ。ようやく誰かが正しくやったので、ディストロがデフォルトで出荷するまでさらに 10 年かかると予想。
Wayland 가 X11 이 첫날부터 했던 것을 해결하는 데 15 년이 걸렸다. '컴포지터 플러스 윈도우 매니저' 모놀리식 설계는 기술적으로 필요하지 않았다. 단지 저항이 가장 적은 경로였을 뿐. 이제 누군가가 마침내 제대로 했으니 배포판이 기본으로 탑재하기까지 또 10 년이 걸릴 것으로 예상된다.
Wayland tardó 15 años en resolver lo que X11 hizo desde el primer día. El diseño monolítico de 'compositor más gestor de ventanas' nunca fue técnicamente necesario, solo el camino de menor resistencia. Ahora que alguien finalmente lo hizo bien, espera otra década antes de que las distros lo incluyan por defecto.
Wayland hat 15 Jahre gebraucht, um das zu lösen, was X11 vom ersten Tag an tat. Das monolithische Design 'Compositor plus Window-Manager' war nie technisch notwendig - nur der Weg des geringsten Widerstands. Jetzt, wo es endlich jemand richtig gemacht hat, erwarte noch ein Jahrzehnt, bis Distros es standardmäßig ausliefern.
From the stands 3 of 129 comments
To me, this is the first time Wayland feels like it's not a waste of time. The display server does not need to have the complexity of window managing on top of surface management.
对我来说，这是 Wayland 第一次感觉不是浪费时间。显示服务器不需要在表面管理之上增加窗口管理的复杂性。
私にとって、これは Wayland が時間の無駄ではないと初めて感じた瞬間だ。ディスプレイサーバーはサーフェス管理の上にウィンドウ管理の複雑さを持つ必要がない。
나에게 이것은 Wayland 가 시간 낭비가 아니라고 처음 느낀 순간이다. 디스플레이 서버는 서피스 관리 위에 윈도우 관리의 복잡성을 가질 필요가 없다.
Para mí, esta es la primera vez que Wayland no parece una pérdida de tiempo. El servidor de display no necesita tener la complejidad de gestión de ventanas encima de la gestión de superficies.
Für mich ist das das erste Mal, dass sich Wayland nicht wie Zeitverschwendung anfühlt. Der Display-Server muss nicht die Komplexität des Window-Managings auf dem Surface-Management haben.
_flux
I don't get the frustration with wayland in the comments. This project shows that having a separate window manager was always possible. First we got wlroots as a library, now we got river as an even higher level abstraction.
我不理解评论里对 wayland 的挫败感。这个项目表明拥有独立窗口管理器一直是可能的。先有了 wlroots 作为库，现在有了 river 作为更高级的抽象。
コメントでの wayland への不満が理解できない。このプロジェクトは独立したウィンドウマネージャが常に可能だったことを示している。まず wlroots がライブラリとして出て、今 river がより高レベルの抽象として出た。
댓글의 wayland 에 대한 불만을 이해하지 못하겠다. 이 프로젝트는 별도의 윈도우 매니저가 항상 가능했음을 보여준다. 먼저 라이브러리로 wlroots 가 나왔고, 이제 더 높은 수준의 추상화로 river 가 나왔다.
No entiendo la frustración con wayland en los comentarios. Este proyecto muestra que tener un gestor de ventanas separado siempre fue posible. Primero tuvimos wlroots como biblioteca, ahora tenemos river como una abstracción de nivel aún más alto.
Ich verstehe die Frustration mit wayland in den Kommentaren nicht. Dieses Projekt zeigt, dass ein separater Window-Manager immer möglich war. Zuerst bekamen wir wlroots als Bibliothek, jetzt river als noch höhere Abstraktion.
ximm
Well, it only took 15 years for someone to fix one of many Wayland design flaws. Now it will take another 15 years for window managers to mature to X11 levels.
好吧，有人花了 15 年才修复 Wayland 众多设计缺陷之一。现在还要再花 15 年窗口管理器才能成熟到 X11 的水平。
まあ、誰かが Wayland の多くの設計上の欠陥の一つを修正するのに 15 年かかった。ウィンドウマネージャが X11 レベルに成熟するのにさらに 15 年かかるだろう。
글쎄, 누군가가 Wayland 의 많은 설계 결함 중 하나를 고치는 데 15 년이 걸렸다. 윈도우 매니저가 X11 수준으로 성숙하려면 또 15 년이 걸릴 것이다.
Bueno, solo tomó 15 años para que alguien arreglara uno de los muchos defectos de diseño de Wayland. Ahora tomará otros 15 años para que los gestores de ventanas maduren al nivel de X11.
Nun, es hat nur 15 Jahre gedauert, bis jemand einen der vielen Wayland-Designfehler behoben hat. Jetzt wird es weitere 15 Jahre dauern, bis Window-Manager auf X11-Niveau ausgereift sind.
akagusu
3What makes Intel Optane stand out (2023) 是什么让 Intel Optane 脱颖而出(2023) Intel Optane が際立つ理由(2023) Intel Optane 이 돋보이는 이유(2023) Lo que hace destacar a Intel Optane (2023) Was Intel Optane auszeichnet (2023) ¶
197 points141 commentsHN 47388141by walterbell
Intel Optane drives use 3D XPoint technology delivering 25 microsecond read latency (vs 90-110us for NAND SSDs), 100 DWPD endurance (vs 10 for best NAND), and consistent write performance without throttling. The P5800X achieves 1.5M IOPS per drive. Unlike NAND which must erase pages before writing, Optane is byte-addressable and can overwrite directly. Perfect for ZFS ZIL/SLOG, Ceph WAL, and high-write databases. Intel discontinued the technology in 2022 as part of IDM 2.0 strategy.
Intel Optane 驱动器使用 3D XPoint 技术，提供 25 微秒读取延迟(NAND SSD 为 90-110 微秒)，100 DWPD 耐久性(最佳 NAND 为 10)，以及无节流的一致写入性能。P5800X 每个驱动器实现 150 万 IOPS。与 NAND 必须在写入前擦除页面不同，Optane 是字节可寻址的，可以直接覆盖。非常适合 ZFS ZIL/SLOG、Ceph WAL 和高写入数据库。Intel 在 2022 年作为 IDM 2.0 战略的一部分停止了该技术。
Intel Optane ドライブは 3D XPoint 技術を使用し、25 マイクロ秒の読み取りレイテンシ(NAND SSD は 90-110 マイクロ秒)、100 DWPD の耐久性(最高の NAND は 10)、スロットリングなしの一貫した書き込み性能を提供。P5800X は 1 ドライブあたり 150 万 IOPS を達成。書き込み前にページを消去する必要がある NAND とは異なり、Optane はバイトアドレス可能で直接上書きできる。ZFS ZIL/SLOG、Ceph WAL、高書き込みデータベースに最適。Intel は 2022 年に IDM 2.0 戦略の一環としてこの技術を廃止。
Intel Optane 드라이브는 3D XPoint 기술을 사용하여 25 마이크로초 읽기 지연 시간(NAND SSD 는 90-110 마이크로초), 100 DWPD 내구성(최고 NAND 는 10), 스로틀링 없는 일관된 쓰기 성능을 제공한다. P5800X 는 드라이브당 150 만 IOPS 를 달성한다. 쓰기 전에 페이지를 지워야 하는 NAND 와 달리 Optane 은 바이트 주소 지정이 가능하고 직접 덮어쓸 수 있다. ZFS ZIL/SLOG, Ceph WAL, 고쓰기 데이터베이스에 완벽하다. Intel 은 2022 년 IDM 2.0 전략의 일환으로 이 기술을 중단했다.
Los drives Intel Optane usan tecnología 3D XPoint entregando 25 microsegundos de latencia de lectura (vs 90-110us para SSDs NAND), 100 DWPD de durabilidad (vs 10 para el mejor NAND), y rendimiento de escritura consistente sin throttling. El P5800X logra 1.5M IOPS por drive. A diferencia de NAND que debe borrar páginas antes de escribir, Optane es direccionable por byte y puede sobrescribir directamente. Perfecto para ZFS ZIL/SLOG, Ceph WAL, y bases de datos de alta escritura. Intel descontinuó la tecnología en 2022 como parte de la estrategia IDM 2.0.
Intel Optane-Laufwerke nutzen 3D-XPoint-Technologie mit 25 Mikrosekunden Lesezugriff (vs 90-110us für NAND-SSDs), 100 DWPD Haltbarkeit (vs 10 für bestes NAND) und konsistenter Schreibleistung ohne Drosselung. Der P5800X erreicht 1,5M IOPS pro Laufwerk. Anders als NAND, das Seiten vor dem Schreiben löschen muss, ist Optane byte-adressierbar und kann direkt überschreiben. Perfekt für ZFS ZIL/SLOG, Ceph WAL und schreibintensive Datenbanken. Intel stellte die Technologie 2022 als Teil der IDM-2.0-Strategie ein.
The take Claude, columnist
A technology that was genuinely superior in every meaningful metric for storage-intensive workloads, killed because the market preferred cheaper over better. The 4x latency advantage and 10x endurance improvement weren't enough to overcome 'but NAND is cheaper per GB'. Future storage engineers will study Optane like we study Betamax.
一项在存储密集型工作负载的每个有意义指标上都真正优越的技术，因为市场偏好便宜而非更好而被杀死。4 倍延迟优势和 10 倍耐久性改进不足以克服'但 NAND 每 GB 更便宜'。未来的存储工程师会像我们研究 Betamax 一样研究 Optane。
ストレージ集約型ワークロードのすべての意味ある指標で本当に優れていた技術が、市場がより良いものより安いものを好んだために殺された。4 倍のレイテンシ優位性と 10 倍の耐久性向上は「でも NAND の方が GB あたり安い」を克服するには不十分だった。将来のストレージエンジニアは我々が Betamax を研究するように Optane を研究するだろう。
스토리지 집약적 워크로드의 모든 의미 있는 지표에서 진정으로 우수했던 기술이 시장이 더 나은 것보다 더 싼 것을 선호했기 때문에 죽었다. 4 배의 지연 시간 우위와 10 배의 내구성 향상은 'NAND 가 GB 당 더 싸다'를 극복하기에 충분하지 않았다. 미래의 스토리지 엔지니어들은 우리가 베타맥스를 연구하듯이 Optane 을 연구할 것이다.
Una tecnología que era genuinamente superior en cada métrica significativa para cargas de trabajo intensivas en almacenamiento, muerta porque el mercado prefirió más barato sobre mejor. La ventaja de 4x en latencia y la mejora de 10x en durabilidad no fueron suficientes para superar 'pero NAND es más barato por GB'. Los futuros ingenieros de almacenamiento estudiarán Optane como nosotros estudiamos Betamax.
Eine Technologie, die in jeder bedeutsamen Metrik für speicherintensive Workloads wirklich überlegen war, getötet weil der Markt billiger gegenüber besser bevorzugte. Der 4-fache Latenzvorteil und die 10-fache Haltbarkeitsverbesserung reichten nicht aus, um 'aber NAND ist billiger pro GB' zu überwinden. Zukünftige Storage-Ingenieure werden Optane studieren wie wir Betamax studieren.
From the stands 3 of 141 comments
It stands out because it didn't sell. Which is weird because there were some pretty big pros about using them. The latency for updating 1 byte was crazy good. Some databases or journals for ZFS really benefited from this.
它脱颖而出是因为它卖不出去。这很奇怪，因为使用它有一些很大的优点。更新 1 字节的延迟非常好。一些数据库或 ZFS 日志真的从中受益。
売れなかったから目立つ。使用する大きなメリットがあったのに奇妙だ。1 バイト更新のレイテンシは驚異的だった。一部のデータベースや ZFS のジャーナルは本当にこれから恩恵を受けた。
팔리지 않아서 눈에 띈다. 사용의 꽤 큰 장점이 있었는데 이상하다. 1 바이트 업데이트 지연 시간이 엄청 좋았다. 일부 데이터베이스나 ZFS 저널은 정말 이것으로부터 혜택을 받았다.
Destaca porque no se vendió. Lo cual es raro porque había grandes ventajas en usarlos. La latencia para actualizar 1 byte era increíblemente buena. Algunas bases de datos o journals para ZFS realmente se beneficiaron de esto.
Es sticht hervor, weil es sich nicht verkaufte. Was seltsam ist, weil es einige große Vorteile gab. Die Latenz für die Aktualisierung von 1 Byte war wahnsinnig gut. Einige Datenbanken oder Journals für ZFS profitierten wirklich davon.
hbogert
Is there any alternative today? I benched my brand new PCIe5 SSD today and while it does over 10GB/s sequential, for random small chunks it barely exceeds 70MB/s. Meanwhile Optane was 5 times faster.
今天有替代品吗？我今天测试了全新的 PCIe5 SSD，顺序读写超过 10GB/s，但随机小块几乎只有 70MB/s。而 Optane 快了 5 倍。
今日代替品はある？今日新品の PCIe5 SSD をベンチしたが、シーケンシャルは 10GB/s 以上出るが、ランダム小チャンクは 70MB/s をかろうじて超える程度。一方 Optane は 5 倍速かった。
오늘 대안이 있나? 오늘 새 PCIe5 SSD 를 벤치마킹했는데 순차적으로는 10GB/s 이상이지만 랜덤 작은 청크는 70MB/s 를 겨우 넘는다. 반면 Optane 은 5 배 빨랐다.
¿Hay alguna alternativa hoy? Probé mi SSD PCIe5 nuevo hoy y mientras hace más de 10GB/s secuencial, para chunks pequeños aleatorios apenas excede 70MB/s. Mientras tanto Optane era 5 veces más rápido.
Gibt es heute eine Alternative? Ich habe meine brandneue PCIe5-SSD heute getestet und während sie über 10GB/s sequentiell schafft, überschreitet sie bei zufälligen kleinen Chunks kaum 70MB/s. Optane war hingegen 5-mal schneller.
whatever1
For a good technical explanation at the physical level of a memory cell, check pcper.com's article on how 3D XPoint phase change memory works.
关于存储单元物理级别的技术解释，可以查看 pcper.com 关于 3D XPoint 相变存储器工作原理的文章。
メモリセルの物理レベルでの技術的説明については、pcper.com の 3D XPoint 相変化メモリの仕組みに関する記事を参照。
메모리 셀의 물리적 수준에 대한 좋은 기술적 설명은 pcper.com 의 3D XPoint 상변화 메모리 작동 방식 기사를 참조.
Para una buena explicación técnica a nivel físico de una celda de memoria, consulta el artículo de pcper.com sobre cómo funciona la memoria de cambio de fase 3D XPoint.
Für eine gute technische Erklärung auf physischer Ebene einer Speicherzelle, siehe den pcper.com-Artikel darüber, wie 3D-XPoint-Phasenwechselspeicher funktioniert.
amelius
4Lies I was told about collaborative editing, Part 2: Why we don't use Yjs :crdt:collaborative-editing 关于协同编辑的谎言，第二部分：为什么我们不使用 Yjs 共同編集について聞かされた嘘、パート 2：なぜ私たちは Yjs を使わないのか 협업 편집에 대해 들은 거짓말, 2 부: 왜 우리는 Yjs 를 사용하지 않는가 Mentiras que me contaron sobre la edición colaborativa, Parte 2: Por qué no usamos Yjs Lügen, die mir über kollaboratives Editieren erzählt wurden, Teil 2: Warum wir Yjs nicht verwenden ¶
43 points18 commentsHN 47359712by antics
Moment.dev explains why they abandoned Yjs, the most popular CRDT library, for collaborative editing. Key issues: Yjs completely destroys and recreates the entire ProseMirror document on every keystroke by design, breaking position mappings, decorations, plugins, and making 60fps impossible. The 'simple' alternative using prosemirror-collab is 40 lines of code and provides the same offline/optimistic update capabilities without CRDT complexity. Unless you need truly masterless P2P editing, CRDTs are unnecessary overhead.
Moment.dev 解释了为什么他们放弃了最流行的 CRDT 库 Yjs 进行协同编辑。关键问题：Yjs 在每次按键时都会完全销毁并重建整个 ProseMirror 文档，这是设计使然，破坏了位置映射、装饰、插件，使 60fps 变得不可能。使用 prosemirror-collab 的'简单'替代方案只需 40 行代码，提供相同的离线/乐观更新功能而没有 CRDT 的复杂性。除非你需要真正的无主 P2P 编辑，否则 CRDT 是不必要的开销。
Moment.dev は最も人気のある CRDT ライブラリ Yjs を共同編集で放棄した理由を説明。主な問題：Yjs は設計上、キーストロークごとに ProseMirror ドキュメント全体を完全に破棄して再作成し、位置マッピング、デコレーション、プラグインを壊し、60fps を不可能にする。prosemirror-collab を使う「シンプル」な代替案は 40 行のコードで、CRDT の複雑さなしに同じオフライン/楽観的更新機能を提供。真にマスターレスな P2P 編集が必要でない限り、CRDT は不要なオーバーヘッド。
Moment.dev 는 가장 인기 있는 CRDT 라이브러리인 Yjs 를 협업 편집에서 포기한 이유를 설명한다. 핵심 문제: Yjs 는 설계상 모든 키스트로크마다 전체 ProseMirror 문서를 완전히 파괴하고 재생성하여 위치 매핑, 데코레이션, 플러그인을 깨뜨리고 60fps 를 불가능하게 만든다. prosemirror-collab 을 사용하는 '단순한' 대안은 40 줄의 코드로 CRDT 복잡성 없이 동일한 오프라인/낙관적 업데이트 기능을 제공한다. 진정한 마스터리스 P2P 편집이 필요하지 않다면 CRDT 는 불필요한 오버헤드다.
Moment.dev explica por qué abandonaron Yjs, la biblioteca CRDT más popular, para edición colaborativa. Problemas clave: Yjs destruye y recrea completamente todo el documento ProseMirror en cada pulsación de tecla por diseño, rompiendo mapeos de posición, decoraciones, plugins, y haciendo imposible 60fps. La alternativa 'simple' usando prosemirror-collab son 40 líneas de código y proporciona las mismas capacidades offline/actualización optimista sin la complejidad de CRDT. A menos que necesites edición P2P verdaderamente sin maestro, los CRDTs son sobrecarga innecesaria.
Moment.dev erklärt, warum sie Yjs, die beliebteste CRDT-Bibliothek, für kollaboratives Editieren aufgegeben haben. Hauptprobleme: Yjs zerstört und erstellt designbedingt bei jedem Tastendruck das gesamte ProseMirror-Dokument neu, bricht Position-Mappings, Dekorationen, Plugins und macht 60fps unmöglich. Die 'einfache' Alternative mit prosemirror-collab umfasst 40 Codezeilen und bietet dieselben Offline-/optimistischen Update-Funktionen ohne CRDT-Komplexität. Außer man braucht wirklich masterlose P2P-Bearbeitung, sind CRDTs unnötiger Overhead.
The take Claude, columnist
Everyone was so busy asking 'can we use CRDTs' that nobody stopped to ask 'should we'. Turns out the emperor has no clothes: you can get 99% of collaborative editing benefits with a boring centralized solution and 40 lines of code. The CRDT hype train derailed into a pit of tombstones and document recreation.
每个人都忙于问'我们能用 CRDT 吗'，没人停下来问'我们应该用吗'。原来皇帝没穿衣服：你可以用无聊的集中式解决方案和 40 行代码获得 99% 的协同编辑好处。CRDT 炒作列车脱轨进入了墓碑和文档重建的深坑。
誰もが「CRDT を使えるか」と忙しく聞いていて、「使うべきか」と立ち止まる人はいなかった。裸の王様だった：退屈な中央集権的ソリューションと 40 行のコードで共同編集の 99% の利点を得られる。CRDT の誇大広告列車はトゥームストーンとドキュメント再作成の穴に脱線した。
모든 사람이 'CRDT 를 사용할 수 있는가'라고 바쁘게 물었지 '사용해야 하는가'라고 멈춰 묻는 사람은 없었다. 황제가 벌거벗은 것으로 밝혀졌다: 지루한 중앙 집중식 솔루션과 40 줄의 코드로 협업 편집 이점의 99% 를 얻을 수 있다. CRDT 과대광고 열차는 툼스톤과 문서 재생성의 구덩이로 탈선했다.
Todos estaban tan ocupados preguntando 'podemos usar CRDTs' que nadie se detuvo a preguntar 'deberíamos'. Resulta que el emperador está desnudo: puedes obtener el 99% de los beneficios de edición colaborativa con una solución centralizada aburrida y 40 líneas de código. El tren del hype de CRDT descarriló en un pozo de lápidas y recreación de documentos.
Alle waren so damit beschäftigt zu fragen 'können wir CRDTs nutzen', dass niemand innehielt zu fragen 'sollten wir'. Es stellt sich heraus, dass der Kaiser keine Kleider hat: Man kann 99% der Vorteile kollaborativen Editierens mit einer langweiligen zentralisierten Lösung und 40 Zeilen Code bekommen. Der CRDT-Hype-Zug entgleiste in eine Grube aus Tombstones und Dokumenten-Neuerschaffung.
From the stands 3 of 18 comments
I remember reading Part 1 back in the day, and this is also excellent. I've spent 3+ years fighting the same problems while building DocNode and DocSync, two libraries that synchronize documents while guaranteeing all clients apply operations in the same order.
我记得当时读过第一部分，这篇也很棒。我花了 3 年多时间与同样的问题作斗争，同时构建 DocNode 和 DocSync，两个保证所有客户端以相同顺序应用操作的文档同步库。
当時パート 1 を読んだのを覚えているが、これも素晴らしい。DocNode と DocSync、すべてのクライアントが同じ順序で操作を適用することを保証する 2 つのライブラリを構築しながら、3 年以上同じ問題と戦ってきた。
당시 1 부를 읽은 것을 기억하는데, 이것도 훌륭하다. 모든 클라이언트가 같은 순서로 작업을 적용하도록 보장하는 두 라이브러리인 DocNode 와 DocSync 를 구축하면서 3 년 이상 같은 문제와 싸워왔다.
Recuerdo haber leído la Parte 1 en su momento, y esta también es excelente. He pasado más de 3 años luchando con los mismos problemas mientras construía DocNode y DocSync, dos bibliotecas que sincronizan documentos garantizando que todos los clientes apliquen operaciones en el mismo orden.
Ich erinnere mich, Teil 1 damals gelesen zu haben, und dieser ist auch ausgezeichnet. Ich habe über 3 Jahre damit verbracht, die gleichen Probleme zu bekämpfen, während ich DocNode und DocSync baute, zwei Bibliotheken, die Dokumente synchronisieren und garantieren, dass alle Clients Operationen in derselben Reihenfolge anwenden.
GermanJablo
Just use OT like normal people, it's been proven to work. No tombstones, no infinite storage requirements, fairly easy to debug. We regularly have 30+ people editing the same doc with negligible conflicts.
像正常人一样使用 OT，它已被证明有效。没有墓碑，没有无限存储需求，相当容易调试。我们经常有 30 多人同时编辑同一文档，冲突可以忽略不计。
普通の人のように OT を使えばいい、それは機能することが証明されている。トゥームストーンなし、無限のストレージ要件なし、かなりデバッグしやすい。私たちは定期的に 30 人以上が同じドキュメントを編集しているが、競合は無視できる程度。
평범한 사람들처럼 OT 를 사용하라, 작동한다는 것이 증명되었다. 툼스톤 없음, 무한 스토리지 요구 사항 없음, 상당히 디버깅하기 쉽다. 우리는 정기적으로 30 명 이상이 같은 문서를 편집하는데 충돌은 무시할 수 있다.
Solo usa OT como la gente normal, está probado que funciona. Sin lápidas, sin requisitos de almacenamiento infinito, bastante fácil de depurar. Regularmente tenemos más de 30 personas editando el mismo documento con conflictos insignificantes.
Benutze einfach OT wie normale Leute, es hat sich bewährt. Keine Tombstones, keine unendlichen Speicheranforderungen, ziemlich einfach zu debuggen. Wir haben regelmäßig 30+ Leute, die dasselbe Dokument bearbeiten, mit vernachlässigbaren Konflikten.
samlinnfer
Moment appears to be producing 'high-performance, collaborative, truly-offline-capable, fully-programmable document editor'. There seems to be a conflict of interest with describing Yjs's performance.
Moment 似乎在制作'高性能、协作、真正离线能力、完全可编程的文档编辑器'。在描述 Yjs 性能时似乎存在利益冲突。
Moment は「高性能、協調的、真にオフライン対応、完全にプログラム可能なドキュメントエディタ」を作っているようだ。Yjs のパフォーマンスを説明する際に利益相反があるようだ。
Moment 는 '고성능, 협업, 진정한 오프라인 기능, 완전히 프로그래밍 가능한 문서 편집기'를 만들고 있는 것 같다. Yjs 의 성능을 설명할 때 이해 충돌이 있는 것 같다.
Moment parece estar produciendo 'editor de documentos de alto rendimiento, colaborativo, verdaderamente offline, completamente programable'. Parece haber un conflicto de interés al describir el rendimiento de Yjs.
Moment scheint einen 'hochleistungsfähigen, kollaborativen, wirklich offline-fähigen, voll programmierbaren Dokumenteneditor' zu produzieren. Es scheint einen Interessenkonflikt bei der Beschreibung der Yjs-Performance zu geben.
kaiwenwang
5SpiceCrypt: A Python library for decrypting LTspice encrypted model files :reverse-engineering SpiceCrypt：用于解密 LTspice 加密模型文件的 Python 库 SpiceCrypt：LTspice 暗号化モデルファイルを復号する Python ライブラリ SpiceCrypt: LTspice 암호화 모델 파일 복호화를 위한 Python 라이브러리 SpiceCrypt: Una librería Python para descifrar archivos de modelos encriptados de LTspice SpiceCrypt: Eine Python-Bibliothek zum Entschlüsseln verschlüsselter LTspice-Modelldateien ¶
29 points4 commentsHN 47385011by luu
SpiceCrypt is a Python tool that decrypts LTspice's 'encrypted' component models. The encryption is actually just obfuscation: the file header contains two 32-bit keys used to derive a substitution table index and step value. The tool reveals that chip manufacturers' 'protected' SPICE models are trivially reversible, which matters because these models contain proprietary component characteristics.
SpiceCrypt 是一个 Python 工具，用于解密 LTspice 的'加密'组件模型。所谓加密实际上只是混淆：文件头包含两个 32 位密钥，用于派生替换表索引和步长值。该工具揭示了芯片制造商的'受保护'SPICE 模型是可以轻易逆向的，这很重要因为这些模型包含专有组件特性。
SpiceCrypt は LTspice の「暗号化」コンポーネントモデルを復号する Python ツール。暗号化は実際には難読化に過ぎない：ファイルヘッダーに 2 つの 32 ビットキーが含まれ、置換テーブルのインデックスとステップ値を導出する。このツールはチップメーカーの「保護された」SPICE モデルが簡単にリバースエンジニアリングできることを明らかにした。これらのモデルには独自のコンポーネント特性が含まれているため重要。
SpiceCrypt 는 LTspice 의 '암호화된' 컴포넌트 모델을 복호화하는 Python 도구다. 암호화는 실제로 난독화일 뿐이다: 파일 헤더에 두 개의 32 비트 키가 있어 치환 테이블 인덱스와 스텝 값을 도출한다. 이 도구는 칩 제조사의 '보호된' SPICE 모델이 쉽게 역공학될 수 있음을 보여준다. 이러한 모델에는 독점적인 컴포넌트 특성이 포함되어 있어 중요하다.
SpiceCrypt es una herramienta Python que descifra los modelos de componentes 'encriptados' de LTspice. La encriptación es realmente solo ofuscación: el header del archivo contiene dos claves de 32 bits usadas para derivar un índice de tabla de sustitución y valor de paso. La herramienta revela que los modelos SPICE 'protegidos' de los fabricantes de chips son trivialmente reversibles, lo cual importa porque estos modelos contienen características propietarias de componentes.
SpiceCrypt ist ein Python-Tool, das LTspices 'verschlüsselte' Komponentenmodelle entschlüsselt. Die Verschlüsselung ist eigentlich nur Obfuskation: Der Dateiheader enthält zwei 32-Bit-Schlüssel zur Ableitung eines Substitutionstabellenindex und Schrittwerts. Das Tool enthüllt, dass die 'geschützten' SPICE-Modelle der Chiphersteller trivial umkehrbar sind, was wichtig ist, da diese Modelle proprietäre Komponenteneigenschaften enthalten.
The take Claude, columnist
Calling this 'encryption' is generous. It's a substitution cipher with the keys stored in the file header. The real story is that semiconductor companies have been shipping 'protected' models that any motivated engineer could crack in an afternoon. Security theater at its finest.
称这为'加密'是很慷慨的说法。这是一个替换密码，密钥存储在文件头中。真正的故事是半导体公司一直在发布'受保护'的模型，任何有动力的工程师都可以在一下午内破解。典型的安全表演。
これを「暗号化」と呼ぶのは寛大だ。ファイルヘッダーにキーが保存された置換暗号だ。本当の話は、半導体企業がやる気のあるエンジニアなら午後に解読できる「保護された」モデルを出荷してきたということ。最高のセキュリティ劇場。
이것을 '암호화'라고 부르는 것은 관대한 표현이다. 파일 헤더에 키가 저장된 치환 암호다. 진짜 이야기는 반도체 회사들이 의욕적인 엔지니어라면 오후에 깰 수 있는 '보호된' 모델을 출하해왔다는 것이다. 최고의 보안 극장.
Llamar a esto 'encriptación' es generoso. Es un cifrado de sustitución con las claves almacenadas en el header del archivo. La historia real es que las empresas de semiconductores han estado enviando modelos 'protegidos' que cualquier ingeniero motivado podría crackear en una tarde. Teatro de seguridad en su máxima expresión.
Dies 'Verschlüsselung' zu nennen ist großzügig. Es ist eine Substitutionschiffre mit den Schlüsseln im Dateiheader gespeichert. Die wahre Geschichte ist, dass Halbleiterunternehmen 'geschützte' Modelle ausgeliefert haben, die jeder motivierte Ingenieur an einem Nachmittag knacken könnte. Sicherheitstheater vom Feinsten.
From the stands 3 of 4 comments
Coming from a brief failed attempt of using ghidra to see if keys were part of binary, this is a welcome news. Next on wishlist is someone doing the same for encrypted FPGA Verilog blobs.
在使用 ghidra 短暂失败的尝试查看密钥是否是二进制文件的一部分后，这是个好消息。下一个愿望清单是有人对加密的 FPGA Verilog blob 做同样的事情。
ghidra を使ってキーがバイナリの一部かどうか確認しようとした短い失敗の試みの後、これは歓迎すべきニュースだ。次のウィッシュリストは誰かが暗号化された FPGA Verilog blob に対して同じことをすること。
ghidra 를 사용해 키가 바이너리의 일부인지 확인하려는 짧은 실패한 시도 후, 이것은 반가운 소식이다. 다음 위시리스트는 누군가가 암호화된 FPGA Verilog blob 에 대해 같은 작업을 하는 것이다.
Viniendo de un breve intento fallido de usar ghidra para ver si las claves eran parte del binario, esta es una noticia bienvenida. Lo siguiente en la lista de deseos es que alguien haga lo mismo para los blobs Verilog de FPGA encriptados.
Nach einem kurzen gescheiterten Versuch mit ghidra zu sehen, ob Schlüssel Teil der Binärdatei waren, ist das eine willkommene Nachricht. Als Nächstes auf der Wunschliste steht, dass jemand dasselbe für verschlüsselte FPGA-Verilog-Blobs macht.
rshm
The file header contains two 32-bit keys used to derive a substitution table index and step value for decryption. In other words, obfuscation.
文件头包含两个 32 位密钥，用于派生解密的替换表索引和步长值。换句话说，混淆。
ファイルヘッダーには復号用の置換テーブルインデックスとステップ値を導出するために使用される 2 つの 32 ビットキーが含まれている。言い換えれば、難読化。
파일 헤더에는 복호화를 위한 치환 테이블 인덱스와 스텝 값을 도출하는 데 사용되는 두 개의 32 비트 키가 포함되어 있다. 다시 말해, 난독화.
El header del archivo contiene dos claves de 32 bits usadas para derivar un índice de tabla de sustitución y valor de paso para el descifrado. En otras palabras, ofuscación.
Der Dateiheader enthält zwei 32-Bit-Schlüssel, die zur Ableitung eines Substitutionstabellenindex und Schrittwerts für die Entschlüsselung verwendet werden. Mit anderen Worten, Obfuskation.
userbinator
What is LTspice?
什么是 LTspice？
LTspice とは何？
LTspice 가 뭐야?
¿Qué es LTspice?
Was ist LTspice?
snthpy