52 Year old data tape could contain Unix history
52-летняя магнитная лента, обнаруженная в архивах, может содержать утерянные ранние версии Unix, включая код, предшествовавший официальному релизу в 1971 году. Найденная в коллекции Bell Labs, лента хранит копию версии Unix 0, которая считается "святым Граалем" для историков вычислительной техники. Успешное восстановление данных с этого артефакта позволит проследить эволюцию ключевых компонентов ОС, таких как файловая система и ядро, и заполнить пробелы в истории Unix, повлиявшей на современные операционные системы.
Специалисты из Computer History Museum и Unix Heritage Society ведут сложный процесс восстановления данных с деградированной ленты, используя специализированное оборудование. По словам одного из экспертов, "эта лента — как цифровая Декларация независимости для Unix". Если восстановление пройдет успешно, это станет первым случаем извлечения работающего кода из столь ранней версии Unix, предоставив уникальную возможность изучить "первобытный код", сформировавший основу для Linux, macOS и других систем.
Комментарии (61)
- Обсуждение вращается вокруг архивных лент 1972 года, найденных в лаборатории IBM, и возможности их восстановления.
- Участники обсуждают, что это может означать для сохранения наследия Unix и ранних систем, и какие технические и этические вопросы это поднимает.
- Поднимается вопрос о том, что в будущем может быть трудно оценить значение таких находок, и что это может означать для сохранения истории компьютерной эпохи.
- Обсуждается, какие усилия предпринимаются для сохранения таких артефактов, и какие могут быть последствия для общественного доступа к ним.
Unix philosophy and filesystem access makes Claude Code amazing 🔥 Горячее 💬 Длинная дискуссия
Claude Code превратился из инструмента для помощи в программировании в полноценную операционную систему с агентным подходом, интегрирующуюся с Obsidian через доступ к файловой системе. Ключевое преимущество — нативная поддержка Unix-команд, идеально подходящих для LLM благодаря их простоте, документированности и философии «делай одно дело хорошо». Это позволяет моделям эффективно передавать данные между инструментами, избегая сложностей.
Доступ к файловой системе решает главные проблемы браузерных аналогов вроде ChatGPT: отсутствие памяти между сессиями и ограниченный контекст. Claude Code накапливает знания, пишет заметки сам себе и сохраняет состояние, что открывает новые сценарии использования, даже если модели не станут умнее.
Комментарии (197)
- Пользователи восхищаются способностью Claude Code и подобных инструментов взаимодействовать с системой через CLI, используя стандартные утилиты (adb/logcat, AWS CLI, tmux) для отладки, автоматизации и решения сложных задач в реальном времени.
- Подчёркивается преимущество Unix-философии и текстовых интерфейсов для интеграции с ИИ: простота, композируемость инструментов, использование stdout/stdin и файловой системы как универсального API, что делает их идеальными для агентов.
- Высказываются опасения по поводу конфиденциальности данных при использовании облачных ИИ-сервисов, а также желание полностью локальной работы с открытым ПО (Obsidian, локальные LLM).
- Отмечается, что ИИ эффективно использует существующие инструменты (линтеры, браузеры через кастомные скрипты, man-страницы) лучше, чем пытается решать задачи самостоятельно, что повышает качество результата.
- Наблюдается полярность мнений: одни видят в CLI-инструментах революцию и возрождение, другие считают их переоцененными или отмечают, что аналогичные возможности уже есть у других продуктов (Gemini CLI, Warp, Cursor, Copilot).
Sandboxing AI agents at the kernel level
Агенты ИИ, работающие с файловой системой, представляют угрозу безопасности, особенно в облачных средах. Злоумышленник может обойти защиту на уровне приложения и заставить агента раскрыть конфиденциальные файлы через системные вызовы. Решение — изоляция на уровне ядра, где сам Linux блокирует доступ к нежелательным ресурсам.
Анализ системного вызова open в ядре Linux показывает три точки отказа: do_open (поздний отказ), link_path_walk (средний) и path_init (ранний). Контейнеризация использует эти механизмы, создавая виртуальную файловую систему и пространства имён, чтобы скрыть реальные файлы от процесса. Это надёжнее, чем полагаться на фильтрацию ввода-вывода в приложении.
Комментарии (21)
- Обсуждение методов изоляции и безопасности для AI-агентов, включая контейнеризацию (runc, podman), Landlock и WebAssembly как потенциальные решения.
- Критика предложенного подхода к песочнице как избыточной или неубедительной для экспертов по безопасности, с акцентом на использование существующих проверенных библиотек и методов.
- Уточнение требований к агенту для код-ревью: доступ только к кодовой базе, истории репозитория, диффам, CI/CD логам и системам отслеживания ошибок.
- Обсуждение практических сложностей реализации, таких как неподдерживаемые системные вызовы в gVisor и необходимость баланса между производительностью и безопасностью.
- Скептицизм относительно новизны и точности объяснения автора, с замечаниями, что описанные методы (chroot) не являются полноценной песочницей или контейнеризацией.
In-Memory Filesystems in Rust
Разрабатывая CLI-утилиту, я хотел избежать тормозов при тестах из-за fstat, как это было в Bundler. Решил попробовать in-memory FS, как в Go-библиотеке Afero.
В Rust аналогов нет: спросишь — получишь лекцию «в Rust это не нужно». Нашёл два кандидата:
- vfs — поддерживает swap-бэкендов, но без симлинков и прав, а главное — нельзя создавать исполняемые файлы.
- rsfs — старый, почти заброшенный; требует параметризовать весь код типом
rsfs::FS, превращая сигнатуры в кашу.
Провёл бенчмарк: vfs, rsfs, ramdisk и обычный SSD — всё показывает ~45 мс. Современные SSD + кеш ОС настолько быстры, что экономия на syscalls незаметна.
Вывод: тестируй прямо на файловой системе — проще и не медленнее.
Комментарии (45)
- Позикс-семантика сложна, поэтому самописная in-memory реализация почти всегда хуже по качеству, чем готовые tmpfs/ramfs.
- Для быстрых тестов достаточно /tmp (часто tmpfs) или /dev/shm — это дёшево и использует проверенный ядром код.
- SSD и кэши ОС настолько быстры, что даже обычное файловое I/O редко становится узким местом; CPU и syscalls чаще ограничивают.
- Несколько участников пожелали стандартным traits для файловой системы, как в Go (fs.FS, afero), но признают, что в std Rust это уже трудно.
- Основная цель обсуждаемого vfs-крейта — встраивать файлы в бинарь, а не мокать диск; об этом автор плохо сообщил в README.