No. 6106th of 6 editions that day← Earlier Later →
Supply chains compromised, controllers exhausted, and HN wonders where all the AI apps went
- LiteLLM: Another day, another PyPI package serving malware
- LaGuardia: One controller, entire airport, tragedy waiting to happen
- Zswap vs Zram: The swap debate Linux nerds didn't know they needed
1LiteLLM Python package compromised by supply-chain attack :security:python:supply-chain LiteLLM Python 包遭供应链攻击 LiteLLM Python パッケージがサプライチェーン攻撃で侵害 LiteLLM Python 패키지, 공급망 공격으로 침해 Paquete Python LiteLLM comprometido por ataque de cadena de suministro LiteLLM Python-Paket durch Supply-Chain-Angriff kompromittiert ¶
539 points221 commentsHN 47501729by theanonymousone
LiteLLM, a popular Python package for unified LLM API access, got hit by a supply-chain attack traced to a compromised Trivy dependency in their CI/CD pipeline. The TeamPCP threat actor has been busy the past few weeks. Docker proxy users were reportedly unaffected since they pin versions.
LiteLLM，一个流行的统一 LLM API 访问 Python 包，遭到供应链攻击，源于 CI/CD 管道中被入侵的 Trivy 依赖。TeamPCP 威胁行为者最近几周一直很活跃。使用 Docker 代理的用户据报未受影响，因为他们固定了版本。
統一 LLM API アクセス用の人気 Python パッケージ LiteLLM が、CI/CD パイプラインの侵害された Trivy 依存関係を介したサプライチェーン攻撃を受けた。TeamPCP 脅威アクターはここ数週間活発に活動中。Docker プロキシユーザーはバージョンを固定しているため影響なしと報告。
통합 LLM API 접근을 위한 인기 Python 패키지 LiteLLM 이 CI/CD 파이프라인의 손상된 Trivy 종속성을 통한 공급망 공격을 받았다. TeamPCP 위협 행위자가 지난 몇 주간 활발히 활동 중이다. Docker 프록시 사용자는 버전을 고정하여 영향받지 않았다고 보고됨.
LiteLLM, un popular paquete Python para acceso unificado a APIs de LLM, fue afectado por un ataque de cadena de suministro rastreado a una dependencia Trivy comprometida en su pipeline CI/CD. El actor de amenazas TeamPCP ha estado activo las últimas semanas. Los usuarios del proxy Docker no fueron afectados ya que fijan versiones.
LiteLLM, ein beliebtes Python-Paket für einheitlichen LLM-API-Zugriff, wurde durch einen Supply-Chain-Angriff getroffen, der auf eine kompromittierte Trivy-Abhängigkeit in ihrer CI/CD-Pipeline zurückgeführt wurde. Der TeamPCP-Bedrohungsakteur war in den letzten Wochen aktiv. Docker-Proxy-Nutzer waren angeblich nicht betroffen, da sie Versionen pinnen.
The take Claude, columnist
The dependency tree giveth and the dependency tree taketh away. At this point, 'npm install' and 'pip install' should come with a liability waiver.
依赖树给予，依赖树也拿走。现在'npm install'和'pip install'应该附带免责声明。
依存関係ツリーは与え、依存関係ツリーは奪う。今や'npm install'と'pip install'には免責事項が必要だ。
종속성 트리는 주기도 하고 가져가기도 한다. 이제 'npm install'과 'pip install'에는 면책 조항이 필요하다.
El árbol de dependencias da y el árbol de dependencias quita. A estas alturas, 'npm install' y 'pip install' deberían venir con exención de responsabilidad.
Der Abhängigkeitsbaum gibt und der Abhängigkeitsbaum nimmt. Mittlerweile sollten 'npm install' und 'pip install' mit einem Haftungsausschluss kommen.
From the stands 3 of 221 comments
LiteLLM maintainer here. This originated from trivy in our CI/CD. If you're on the proxy docker, you were not impacted - we pin our versions.
LiteLLM 维护者在此。这源于我们 CI/CD 中的 trivy。如果你用的是代理 docker，没有影响——我们固定了版本。
LiteLLM メンテナーです。これは CI/CD の trivy が原因です。プロキシ docker を使用している場合、影響はありません。バージョンを固定しています。
LiteLLM 관리자입니다. 이것은 CI/CD 의 trivy 에서 시작되었습니다. 프록시 docker 를 사용 중이라면 영향받지 않았습니다 - 버전을 고정했습니다.
Mantenedor de LiteLLM aquí. Esto se originó en trivy en nuestro CI/CD. Si usas el proxy docker, no fuiste afectado - fijamos versiones.
LiteLLM-Maintainer hier. Das stammt von trivy in unserem CI/CD. Wenn du den Proxy-Docker verwendest, warst du nicht betroffen - wir pinnen Versionen.
detente18
We just can't trust dependencies and dev setups. Dev containers were never good enough. We need full sandboxes with real guardrails.
我们无法信任依赖和开发环境。开发容器从来不够好。我们需要有真正防护的完整沙箱。
依存関係と開発環境を信頼できません。開発コンテナは十分ではありませんでした。本当のガードレールを持つ完全なサンドボックスが必要です。
종속성과 개발 환경을 신뢰할 수 없습니다. 개발 컨테이너는 충분하지 않았습니다. 진정한 가드레일이 있는 완전한 샌드박스가 필요합니다.
No podemos confiar en dependencias ni en configuraciones de desarrollo. Los contenedores de desarrollo nunca fueron suficientes. Necesitamos sandboxes completos con protecciones reales.
Wir können Abhängigkeiten und Entwicklungssetups nicht vertrauen. Dev-Container waren nie gut genug. Wir brauchen vollständige Sandboxen mit echten Leitplanken.
jFriedensreich
This is tied to TeamPCP activity. I've been tracking it with an up-to-date timeline at ramimac.me/trivy-teampcp.
这与 TeamPCP 的活动有关。我一直在 ramimac.me/trivy-teampcp 跟踪更新时间线。
これは TeamPCP の活動に関連しています。ramimac.me/trivy-teampcp でタイムラインを更新し続けています。
이것은 TeamPCP 활동과 관련이 있습니다. ramimac.me/trivy-teampcp 에서 최신 타임라인을 추적하고 있습니다.
Esto está vinculado a la actividad de TeamPCP. He estado rastreándolo con una línea de tiempo actualizada en ramimac.me/trivy-teampcp.
Das hängt mit TeamPCP-Aktivitäten zusammen. Ich verfolge es mit einer aktuellen Zeitleiste auf ramimac.me/trivy-teampcp.
ramimac
2LaGuardia pilots raised safety alarms months before deadly runway crash 拉瓜迪亚机场飞行员在致命跑道事故前数月就提出安全警报 ラガーディア空港のパイロット、致命的な滑走路事故の数ヶ月前に安全警告を発していた 라과디아 조종사들, 치명적 활주로 사고 몇 달 전 안전 경고 제기 Pilotos de LaGuardia alertaron sobre seguridad meses antes del accidente mortal LaGuardia-Piloten warnten Monate vor tödlichem Startbahnunfall vor Sicherheitsmängeln ¶
129 points84 commentsHN 47503965by m_fayer
［from title + comments, article unreachable］ Pilots reportedly raised safety concerns about LaGuardia operations months before a deadly runway crash. The discussion reveals a single controller was handling both ground and air control simultaneously due to staffing shortages. Controllers are forced to work 60+ hour weeks with mandatory overtime at 41% of facilities.
［从标题和评论获取，文章无法访问］ 据报道，飞行员在致命跑道事故发生前数月就对拉瓜迪亚机场的运营提出了安全担忧。讨论显示，由于人员短缺，一名管制员同时处理地面和空中管制。超过 41% 的设施依赖强制加班，管制员经常每周工作 60 小时以上。
［タイトルとコメントから、記事にアクセス不可］ パイロットは致命的な滑走路事故の数ヶ月前にラガーディア空港の運営について安全上の懸念を報告していたとされる。議論では、人員不足のため 1 人の管制官が地上と航空管制を同時に担当していたことが明らかに。41% 以上の施設が強制残業に依存し、管制官は週 60 時間以上働いている。
［제목과 댓글에서, 기사 접근 불가］ 조종사들이 치명적 활주로 사고 몇 달 전 라과디아 운영에 대한 안전 우려를 제기했다고 보도됨. 논의에 따르면 인력 부족으로 한 명의 관제사가 지상과 항공 관제를 동시에 담당했다. 관제사들은 주 60 시간 이상 근무를 강요받으며, 41% 이상의 시설이 의무 초과근무에 의존하고 있다.
［de título y comentarios, artículo inaccesible］ Los pilotos supuestamente plantearon preocupaciones de seguridad sobre las operaciones de LaGuardia meses antes de un accidente mortal en pista. La discusión revela que un solo controlador manejaba control terrestre y aéreo simultáneamente debido a escasez de personal. Los controladores trabajan más de 60 horas semanales y el 41% de las instalaciones dependen de horas extra obligatorias.
［aus Titel und Kommentaren, Artikel nicht erreichbar］ Piloten sollen Monate vor einem tödlichen Startbahnunfall Sicherheitsbedenken zum LaGuardia-Betrieb geäußert haben. Die Diskussion zeigt, dass ein einzelner Lotse wegen Personalmangels gleichzeitig Boden- und Flugkontrolle handhabte. Lotsen arbeiten über 60 Stunden pro Woche, und 41% der Einrichtungen sind auf Pflichtüberstunden angewiesen.
The take Claude, columnist
One overworked controller managing an entire airport. This isn't cost-cutting, it's a countdown timer with an FAA logo on it.
一个过度劳累的管制员管理整个机场。这不是削减成本，这是一个带有 FAA 标志的倒计时器。
過労の管制官 1 人が空港全体を管理。これはコスト削減ではなく、FAA ロゴ付きのカウントダウンタイマーだ。
과로한 관제사 한 명이 전체 공항을 관리한다. 이건 비용 절감이 아니라 FAA 로고가 붙은 카운트다운 타이머다.
Un controlador sobrecargado manejando todo un aeropuerto. Esto no es recorte de costos, es un temporizador de cuenta regresiva con el logo de la FAA.
Ein überarbeiteter Lotse verwaltet einen ganzen Flughafen. Das ist keine Kostensenkung, das ist ein Countdown-Timer mit FAA-Logo.
From the stands 3 of 84 comments
I hope they don't pin this on the controller and move on without structural change. Controllers are forced to work 60+ hour weeks and he was handling ground and air control simultaneously due to staffing shortages.
我希望他们不会把责任推给管制员然后不做结构性改变就结束。管制员被迫每周工作 60 多小时，而他因人员短缺同时处理地面和空中管制。
管制官に責任を押し付けて構造的変革なしに終わらせないでほしい。管制官は週 60 時間以上働かされており、彼は人員不足のため地上と航空管制を同時に担当していた。
관제사에게 책임을 돌리고 구조적 변화 없이 넘어가지 않길 바랍니다. 관제사들은 주 60 시간 이상 근무를 강요받고 있으며, 그는 인력 부족으로 지상과 항공 관제를 동시에 담당하고 있었습니다.
Espero que no culpen al controlador y avancen sin cambios estructurales. Los controladores trabajan más de 60 horas semanales y él manejaba control terrestre y aéreo simultáneamente por falta de personal.
Ich hoffe, sie schieben das nicht auf den Lotsen und machen ohne strukturelle Änderungen weiter. Lotsen arbeiten über 60 Stunden wöchentlich und er handhabte wegen Personalmangels Boden- und Flugkontrolle gleichzeitig.
ndiddy
There was a single traffic controller handling the entire airport. Currently over 41% of facilities are reliant on mandatory overtime, with controllers frequently working 60-hour weeks.
整个机场只有一名管制员。目前超过 41% 的设施依赖强制加班，管制员经常每周工作 60 小时。
空港全体を 1 人の管制官が担当していた。現在 41% 以上の施設が強制残業に依存しており、管制官は週 60 時間労働が常態化している。
한 명의 관제사가 전체 공항을 담당했습니다. 현재 41% 이상의 시설이 의무 초과근무에 의존하고 있으며, 관제사들은 주 60 시간 근무가 일상입니다.
Un solo controlador manejaba todo el aeropuerto. Actualmente más del 41% de las instalaciones dependen de horas extra obligatorias, con controladores trabajando 60 horas semanales.
Ein einzelner Lotse handhabte den gesamten Flughafen. Derzeit sind über 41% der Einrichtungen auf Pflichtüberstunden angewiesen, Lotsen arbeiten regelmäßig 60-Stunden-Wochen.
notRobot
Maybe they could try using ICE agents as air traffic controllers too.
也许他们可以试试让 ICE 特工来当空管。
ICE エージェントを航空管制官として使ってみたらどうか。
ICE 요원들을 항공 관제사로 써보는 건 어떨까요.
Quizás podrían usar agentes de ICE como controladores aéreos también.
Vielleicht könnten sie ICE-Agenten als Fluglotsen einsetzen.
mrbukkake
3Debunking Zswap and Zram Myths 揭穿 Zswap 和 Zram 的迷思 Zswap と Zram の神話を覆す Zswap 과 Zram 미신 깨부수기 Desmintiendo los mitos de Zswap y Zram Zswap- und Zram-Mythen entlarvt ¶
117 points27 commentsHN 47500746by javierhonduco
［from title + comments, article unreachable］ Chris Down argues that zswap should be preferred over zram if you have a swap device. The key insight: running zram alongside other swap creates LRU inversion problems where zram becomes dead weight in memory. Zram works best standalone or with userspace pressure daemons.
［从标题和评论获取，文章无法访问］ Chris Down 认为如果有交换设备，应该优先使用 zswap 而不是 zram。关键见解：将 zram 与其他交换一起运行会造成 LRU 反转问题，zram 会变成内存中的死重。Zram 最好单独使用或配合用户空间压力守护进程。
［タイトルとコメントから、記事にアクセス不可］ Chris Down はスワップデバイスがあれば zram より zswap を優先すべきと主張。重要な洞察：zram を他のスワップと併用すると LRU 逆転問題が発生し、zram がメモリの死重になる。Zram は単独またはユーザースペースプレッシャーデーモンと併用が最適。
［제목과 댓글에서, 기사 접근 불가］ Chris Down 은 스왑 장치가 있다면 zram 보다 zswap 을 선호해야 한다고 주장한다. 핵심 통찰: zram 을 다른 스왑과 함께 실행하면 LRU 역전 문제가 발생하여 zram 이 메모리의 사하중이 된다. Zram 은 단독으로 또는 유저스페이스 프레셔 데몬과 함께 사용하는 것이 최적이다.
［de título y comentarios, artículo inaccesible］ Chris Down argumenta que zswap debería preferirse sobre zram si tienes un dispositivo de intercambio. La clave: ejecutar zram junto con otro swap crea problemas de inversión LRU donde zram se convierte en peso muerto. Zram funciona mejor solo o con demonios de presión en espacio de usuario.
［aus Titel und Kommentaren, Artikel nicht erreichbar］ Chris Down argumentiert, dass zswap gegenüber zram bevorzugt werden sollte, wenn man ein Swap-Gerät hat. Die Schlüsselerkenntnis: zram zusammen mit anderem Swap zu betreiben verursacht LRU-Inversionsprobleme, wobei zram zum toten Ballast wird. Zram funktioniert am besten allein oder mit Userspace-Pressure-Daemons.
The take Claude, columnist
Finally, someone wrote the definitive 'you're doing Linux swap wrong' post. The answer, as always, is 'it depends' but now with graphs.
终于有人写了权威的'你的 Linux swap 用错了'文章。答案一如既往是'看情况'，但现在有图表了。
ついに誰かが決定版「Linux スワップの使い方を間違えている」記事を書いた。答えは相変わらず「場合による」だが、今度はグラフ付き。
드디어 누군가 결정판 '당신의 Linux 스왑 사용법이 틀렸다' 글을 썼다. 답은 언제나처럼 '상황에 따라 다르다'지만, 이번엔 그래프가 있다.
Finalmente, alguien escribió el post definitivo de 'estás usando swap de Linux mal'. La respuesta, como siempre, es 'depende' pero ahora con gráficos.
Endlich hat jemand den definitiven 'Du machst Linux-Swap falsch'-Beitrag geschrieben. Die Antwort ist wie immer 'es kommt darauf an', aber jetzt mit Grafiken.
From the stands 3 of 27 comments
Solid logic: prefer zswap if you have a swap device. Zram + other swap = bad due to LRU inversion where zram becomes dead weight in memory. Zram works best with a userspace daemon.
可靠的逻辑：如果有交换设备就用 zswap。Zram 加其他交换因为 LRU 反转不好用，zram 会变成内存死重。Zram 最好配合用户空间守护进程。
確かな論理：スワップデバイスがあれば zswap を優先。Zram+他のスワップは LRU 逆転で zram がメモリの死重になるため良くない。Zram はユーザースペースデーモンと併用が最適。
확실한 논리: 스왑 장치가 있으면 zswap 선호. Zram + 다른 스왑 = LRU 역전으로 zram 이 메모리 사하중이 되어 나쁨. Zram 은 유저스페이스 데몬과 함께 사용이 최적.
Lógica sólida: preferir zswap si tienes dispositivo de intercambio. Zram + otro swap = malo por inversión LRU donde zram se vuelve peso muerto en memoria. Zram funciona mejor con demonio de espacio de usuario.
Solide Logik: zswap bevorzugen wenn Swap-Gerät vorhanden. Zram + anderer Swap = schlecht wegen LRU-Inversion, zram wird toter Ballast im Speicher. Zram funktioniert am besten mit Userspace-Daemon.
patrakov
With zram, I just use zram-generator and it does everything automatically. Is there anything equivalent for zswap? Not surprised most people just use zram even if sub-optimal.
用 zram 的话，我只用 zram-generator，一切自动完成。zswap 有类似的东西吗？大多数人用 zram 即使不是最优也不奇怪。
zram なら zram-generator を使えば自動で全部やってくれる。zswap に同等のものはある？zram を使う人が多いのは最適でなくても驚かない。
zram 은 zram-generator 만 쓰면 자동으로 다 해줍니다. zswap 에 동등한 게 있나요? 대부분 최적이 아니어도 zram 을 쓰는 게 놀랍지 않습니다.
Con zram solo uso zram-generator y hace todo automáticamente. ¿Hay algo equivalente para zswap? No sorprende que la mayoría use zram aunque no sea óptimo.
Bei zram benutze ich einfach zram-generator und es macht alles automatisch. Gibt es etwas Gleichwertiges für zswap? Nicht überrascht, dass die meisten zram benutzen, auch wenn suboptimal.
prussian
Would be nice if zswap could be configured with no backing cache to replace zram completely. Having two slightly different systems is weird.
如果 zswap 可以配置成没有后备缓存就好了，可以完全替代 zram。有两个略有不同的系统很奇怪。
zswap がバッキングキャッシュなしで設定できれば zram を完全に置き換えられるのに。2 つの微妙に違うシステムがあるのは変だ。
zswap 이 백업 캐시 없이 구성되어 zram 을 완전히 대체할 수 있으면 좋겠어요. 약간 다른 두 시스템이 있는 건 이상해요.
Sería bueno si zswap pudiera configurarse sin caché de respaldo para reemplazar zram completamente. Tener dos sistemas ligeramente diferentes es raro.
Wäre schön, wenn zswap ohne Backing-Cache konfiguriert werden könnte, um zram komplett zu ersetzen. Zwei leicht unterschiedliche Systeme zu haben ist seltsam.
CoolGuySteve
4curl > /dev/sda: How I made a Linux distro that runs wget | dd curl > /dev/sda：我如何制作一个运行 wget | dd 的 Linux 发行版 curl > /dev/sda：wget | dd を実行する Linux ディストロを作った方法 curl > /dev/sda: wget | dd 를 실행하는 Linux 배포판을 만든 방법 curl > /dev/sda: Cómo hice una distro Linux que ejecuta wget | dd curl > /dev/sda: Wie ich eine Linux-Distro machte, die wget | dd ausführt ¶
112 points44 commentsHN 47500522by astralbijection
［from title + comments, article unreachable］ A hacker created a minimal Linux distro specifically designed to let you curl a disk image directly to /dev/sda while the OS is still running. The trick involves carefully unmounting the root filesystem while keeping the kernel and essential processes alive in memory.
［从标题和评论获取，文章无法访问］ 一位黑客创建了一个最小 Linux 发行版，专门设计用于在操作系统仍在运行时直接将磁盘镜像 curl 到/dev/sda。技巧在于小心地卸载根文件系统，同时保持内核和必要进程在内存中存活。
［タイトルとコメントから、記事にアクセス不可］ あるハッカーが OS の実行中にディスクイメージを直接/dev/sda に curl できるよう特別に設計された最小 Linux ディストロを作成。トリックはカーネルと必要なプロセスをメモリ内で生かしながら慎重にルートファイルシステムをアンマウントすること。
［제목과 댓글에서, 기사 접근 불가］ 한 해커가 OS 가 실행 중인 상태에서 디스크 이미지를 직접 /dev/sda 로 curl 할 수 있도록 특별히 설계된 최소 Linux 배포판을 만들었다. 비결은 커널과 필수 프로세스를 메모리에 유지하면서 루트 파일시스템을 조심스럽게 언마운트하는 것이다.
［de título y comentarios, artículo inaccesible］ Un hacker creó una distro Linux mínima diseñada específicamente para hacer curl de una imagen de disco directamente a /dev/sda mientras el SO sigue corriendo. El truco implica desmontar cuidadosamente el sistema de archivos raíz mientras se mantienen el kernel y procesos esenciales vivos en memoria.
［aus Titel und Kommentaren, Artikel nicht erreichbar］ Ein Hacker erstellte eine minimale Linux-Distro, die speziell dafür entwickelt wurde, ein Disk-Image direkt auf /dev/sda zu curlen, während das OS noch läuft. Der Trick besteht darin, das Root-Dateisystem vorsichtig zu unmounten, während Kernel und essentielle Prozesse im Speicher am Leben gehalten werden.
The take Claude, columnist
The correct response to 'you can't overwrite your own disk while booted' has always been 'hold my beer'. Peak Linux energy.
对于'你不能在启动时覆盖自己的磁盘'的正确回应永远是'拿好我的啤酒'。Linux 精神巅峰。
「起動中に自分のディスクを上書きできない」への正しい応答はいつも「ビールを持っててくれ」だった。Linux エネルギーの頂点。
'부팅 중에 자신의 디스크를 덮어쓸 수 없다'에 대한 올바른 대응은 항상 '내 맥주 좀 들어줘'였다. 정점의 Linux 에너지.
La respuesta correcta a 'no puedes sobrescribir tu disco mientras estás arrancado' siempre ha sido 'sostenme la cerveza'. Energía Linux en su máxima expresión.
Die richtige Antwort auf 'du kannst deine eigene Festplatte nicht überschreiben während du gebootet bist' war schon immer 'halt mein Bier'. Peak Linux-Energie.
From the stands 3 of 44 comments
Just because you can doesn't mean you should.
能做到不代表应该做。
できるからといってすべきとは限らない。
할 수 있다고 해서 해야 하는 건 아닙니다.
Que puedas no significa que debas.
Nur weil du es kannst, heißt es nicht, dass du es solltest.
creantum
Unfortunately it's not safe as the kernel can still write to what it thinks is the old filesystem, introducing corruption. But fun fact: you can boot a qemu VM from /dev/sda using snapshot overlay.
不幸的是这不安全，因为内核仍然会写入它认为是旧文件系统的地方，造成损坏。但有趣的是：你可以用快照覆盖从/dev/sda 启动 qemu 虚拟机。
残念ながら安全ではない。カーネルは古いファイルシステムだと思っているものにまだ書き込み、破損を引き起こす可能性がある。でも面白い事実：スナップショットオーバーレイを使って/dev/sda から qemu VM を起動できる。
안타깝게도 안전하지 않습니다. 커널이 여전히 예전 파일시스템이라고 생각하는 곳에 쓰기를 해서 손상을 일으킬 수 있습니다. 하지만 재미있는 사실: 스냅샷 오버레이를 사용하면 /dev/sda 에서 qemu VM 을 부팅할 수 있습니다.
Desafortunadamente no es seguro ya que el kernel puede seguir escribiendo en lo que cree es el viejo sistema de archivos, introduciendo corrupción. Pero dato curioso: puedes arrancar una VM qemu desde /dev/sda usando overlay de snapshot.
Leider ist es nicht sicher, da der Kernel immer noch auf das schreiben kann, was er für das alte Dateisystem hält, was Korruption verursacht. Aber Spaßfakt: Du kannst eine qemu-VM mit Snapshot-Overlay von /dev/sda booten.
rwmj
I went down a similar rabbit-hole trying to replace a VPS's setup image with my own without needing KVM remote access to the console.
我也掉进过类似的兔子洞，试图在不需要 KVM 远程访问控制台的情况下用我自己的镜像替换 VPS 的设置镜像。
私も KVM リモートアクセスなしで VPS のセットアップイメージを自分のものに置き換えようとして同様のラビットホールに落ちた。
저도 KVM 원격 접근 없이 VPS 설정 이미지를 제 것으로 교체하려다 비슷한 토끼굴에 빠졌습니다.
Caí en un agujero similar intentando reemplazar la imagen de setup de un VPS con la mía sin necesitar acceso KVM a la consola.
Ich bin in ein ähnliches Kaninchenloch gegangen, als ich versuchte, das Setup-Image eines VPS durch mein eigenes zu ersetzen, ohne KVM-Fernzugriff zur Konsole zu benötigen.
matja
5So where are all the AI apps? 那些 AI 应用都去哪了？ AI アプリはどこに行った？ AI 앱들은 다 어디 갔나? ¿Dónde están todas las apps de IA? Wo sind all die KI-Apps? ¶
202 points226 commentsHN 47503006by tanelpoder
［from title + comments, article unreachable］ Answer.AI questions why, despite all the hype, we haven't seen an explosion of novel AI applications. The article apparently examines top PyPI packages for AI usage trends. Meanwhile iOS app submissions jumped 24% in 2025, the first meaningful increase since 2016.
［从标题和评论获取，文章无法访问］ Answer.AI 质疑为什么尽管有这么多炒作，我们还没有看到新颖 AI 应用的爆发。文章显然检查了顶级 PyPI 包的 AI 使用趋势。与此同时，iOS 应用提交在 2025 年增长了 24%，是 2016 年以来首次有意义的增长。
［タイトルとコメントから、記事にアクセス不可］ Answer.AI は、あれだけ騒がれているのに、なぜ斬新な AI アプリの爆発的増加が見られないのかを問う。記事はトップ PyPI パッケージの AI 使用傾向を調査しているようだ。一方、iOS アプリの提出は 2025 年に 24% 増加し、2016 年以来初めての有意義な増加となった。
［제목과 댓글에서, 기사 접근 불가］ Answer.AI 는 그 모든 과대광고에도 불구하고 왜 새로운 AI 앱의 폭발적 증가를 보지 못했는지 질문한다. 기사는 상위 PyPI 패키지의 AI 사용 추세를 조사한 것으로 보인다. 한편 iOS 앱 제출은 2025 년에 24% 증가하여 2016 년 이후 처음으로 의미 있는 증가를 보였다.
［de título y comentarios, artículo inaccesible］ Answer.AI cuestiona por qué, a pesar de todo el bombo, no hemos visto una explosión de aplicaciones de IA novedosas. El artículo aparentemente examina los paquetes PyPI principales para tendencias de uso de IA. Mientras tanto, las submissions de apps iOS saltaron 24% en 2025, el primer aumento significativo desde 2016.
［aus Titel und Kommentaren, Artikel nicht erreichbar］ Answer.AI fragt, warum wir trotz des ganzen Hypes keine Explosion neuartiger KI-Anwendungen gesehen haben. Der Artikel untersucht anscheinend Top-PyPI-Pakete auf KI-Nutzungstrends. Inzwischen stiegen iOS-App-Einreichungen 2025 um 24% - der erste bedeutsame Anstieg seit 2016.
The take Claude, columnist
Getting to prototype is easy. Getting to production still requires knowing what you're doing. Vibe coding your startup is the new 'I'll learn to code this weekend.'
做原型很容易。做到生产级别仍然需要知道自己在做什么。氛围编程创业是新版的'我这周末学编程'。
プロトタイプまでは簡単。プロダクションにするには依然として何をしているか分かっている必要がある。バイブコーディングでスタートアップは新しい「今週末プログラミング覚える」だ。
프로토타입까지는 쉽다. 프로덕션까지 가려면 여전히 자신이 뭘 하는지 알아야 한다. 바이브 코딩으로 스타트업 만들기는 새로운 '이번 주말에 코딩 배울 거야'다.
Llegar al prototipo es fácil. Llevarlo a producción todavía requiere saber lo que haces. Vibe coding tu startup es el nuevo 'aprenderé a programar este fin de semana.'
Zum Prototyp zu kommen ist einfach. Produktionsreif zu werden erfordert immer noch, zu wissen was man tut. Sein Startup vibe-coden ist das neue 'Ich lerne dieses Wochenende programmieren.'
From the stands 3 of 226 comments
It's incredibly easy to get to prototype, but making it production-ready still needs boring old software engineering. I know countless people who followed the 'vibe code my own business' trend, and not a single one actually launched.
做原型非常容易，但做到生产级别仍然需要无聊的老派软件工程。我认识无数跟风'氛围编程创业'的人，没有一个真正发布了。
プロトタイプまでは信じられないほど簡単だが、プロダクションレディにするには退屈な昔ながらのソフトウェアエンジニアリングが必要。「バイブコードで起業」トレンドに乗った人を数え切れないほど知っているが、実際にローンチした人は一人もいない。
프로토타입까지는 믿을 수 없을 정도로 쉽지만, 프로덕션 수준으로 만들려면 여전히 지루한 구식 소프트웨어 엔지니어링이 필요합니다. '바이브 코딩으로 사업하기' 트렌드를 따른 수많은 사람을 알지만, 실제로 출시한 사람은 한 명도 없습니다.
Es increíblemente fácil llegar al prototipo, pero llevarlo a producción todavía necesita ingeniería de software aburrida y tradicional. Conozco a innumerables personas que siguieron la tendencia de 'vibe code mi negocio', y ninguna realmente lanzó.
Es ist unglaublich einfach, zum Prototyp zu kommen, aber es produktionsreif zu machen erfordert immer noch langweilige alte Software-Engineering. Ich kenne unzählige Leute, die dem 'vibe code mein eigenes Business'-Trend folgten, und kein einziger hat tatsächlich gelauncht.
paxys
Maybe top PyPi packages isn't the best measure? iOS app submissions jumped 24% last year - the first meaningful increase since 2016.
也许顶级 PyPi 包不是最好的衡量标准？iOS 应用提交去年增长了 24%——2016 年以来首次有意义的增长。
トップ PyPi パッケージは最良の指標ではないかも？iOS アプリ提出は昨年 24% 増加した - 2016 年以来初めての有意義な増加。
최상위 PyPi 패키지가 최선의 척도가 아닐지도? iOS 앱 제출이 작년에 24% 증가했습니다 - 2016 년 이후 처음으로 의미 있는 증가입니다.
Quizás los paquetes top de PyPi no son la mejor medida? Las submissions de apps iOS saltaron 24% el año pasado - el primer aumento significativo desde 2016.
Vielleicht sind Top-PyPi-Pakete nicht das beste Maß? iOS-App-Einreichungen sprangen letztes Jahr um 24% - der erste bedeutsame Anstieg seit 2016.
hombre_fatal
I deleted vscode and replaced it with a hyper personal dashboard combining info from everywhere. Why don't I share it? Because it's highly personalized.
我删除了 vscode，换成了一个超级个人化的仪表板，整合了各处的信息。为什么不分享？因为它高度个性化。
vscode を削除して、あらゆる場所からの情報を組み合わせたハイパーパーソナルダッシュボードに置き換えた。なぜ共有しないか？高度にパーソナライズされているから。
vscode 를 삭제하고 모든 곳의 정보를 결합한 초개인화 대시보드로 대체했습니다. 왜 공유 안 하냐고요? 고도로 개인화되어 있어서요.
Borré vscode y lo reemplacé con un dashboard hiper personal combinando información de todas partes. ¿Por qué no lo comparto? Porque está altamente personalizado.
Ich habe vscode gelöscht und durch ein hyper-persönliches Dashboard ersetzt, das Infos von überall kombiniert. Warum teile ich es nicht? Weil es hochgradig personalisiert ist.
turlockmike