swift-bridge makes it easy to pass and share high-level types between Rust and Swift, such as String, Option<T>, Result<T, E>, struct, class and more. It also helps you bridge higher level language features, such as async functions and generics. Using swift-bridge should be safer, more performant and more ergonomic than managing Rust and Swift FFI by hand.
Как ни странно, одним из препятствий на пути к внедрению был... Баг процессора, который проявлялся в том, что одна редкоиспользуемая инструкция могла исполняться некорректно. Ловили долго.
Разработчик под ником 1996fanrui заметил, что его SSD изнашивается подозрительно быстро, и докопался до причины: виноват Codex CLI — консольный инструмент OpenAI для агентного программирования. Оказалось, что Codex непрерывно пишет диагностические логи в локальную базу SQLite по пути ~/.codex/logs_2.sqlite. За 21 день работы машины на накопитель ушло около 37 ТБ — и это при том, что сам файл базы весит чуть больше гигабайта.
В пересчете на год это примерно 640 ТБ записи. Для сравнения: типичный потребительский SSD на 1 ТБ рассчитан в среднем на 600 TBW, то есть на 600 терабайт записи за весь срок службы. Иными словами, один забытый лог способен исчерпать гарантийный ресурс накопителя меньше чем за год. Реальная нагрузка даже выше, чем кажется по размеру файла: из-за эффекта write amplification база живет в режиме постоянной вставки и удаления — за один 15-секундный замер автор насчитал около 36 тысяч новых строк при неизменном числе хранимых. Проблема тянется как минимум с апреля: тогда фиксировали запись до 5-16 МБ/с прямо во время ответа модели.
Причина — в настройке, которую вряд ли собирались показывать конечным пользователям. SQLite-сток логов по умолчанию работает на глобальном уровне TRACE, самом шумном из возможных. В базу попадает буквально все: сырые данные WebSocket, зеркалированная телеметрия и даже рутинные обращения к системным файлам вроде passwd и ld.so.cache. Хуже того, сток игнорирует стандартную переменную RUST_LOG, так что приглушить его очевидным способом не получается. По оценке автора, около 71% записанного — бесполезный для рядового пользователя мусор.
История с распухающими логами Codex обсуждается на десятке связанных issues не первый месяц, а сам тикет про 640 ТБ висит без официального ответа OpenAI уже неделю. В недавних обновлениях компания чинила стабильность SQLite (включая баг с повреждением WAL), но именно объем записи не тронула. Получается парадокс: OpenAI продает Codex как инструмент, который сам пишет код и проводит ревью, но не закрывает баг, который этот же инструмент по идее должен был отловить, — и который тихо изнашивает железо тысяч пользователей.
Где-то (не помню уже, где) видел лайфхак: если нужен перевод какого-то относительно специфического термина с русского на английский, найдите по этому статью в Википедии, а потом переключите язык на английский. В обратную сторону, конечно, тоже работает, но не всегда, потому что в английской Википедии банально больше статей и потому что для некоторых терминов устоявшихся переводов на русский язык нет
