Hacker News Digest

Статья объясняет, как Linux выполняет ELF-бинарные файлы — основной формат программ в современных Linux-системах. Поддержка ELF реализована в файле fs/binfmt_elf.c, где основная функция load_elf_binary() занимает более 400 строк кода — вчетверо больше, чем поддержка старого формата a.out. ELF-файл содержит заголовок ELF и таблицу заголовков программы, из которой ядро извлекает три ключевых типа записей: PT_LOAD (описывающие области памяти программы), PT_INTERP (определяющий компоновщик) и PT_GNU_STACK (указывающий, должен ли стек быть исполняемым).

Процесс загрузки начинается с проверки формата файла и чтения его заголовков. Затем функция вызывает flush_old_exec(), которая очищает состояние ядра, унаследованное от предыдущей программы, убивает другие потоки процесса и очищает обработку сигналов. Это обеспечивает чистый запуск новой программы с одним потоком. Интересно, что BSS-секция (для неинициализированных данных) в ELF-файле хранится только как размер, так как ядро заполняет её нулями при загрузке.

• Пользователи обсуждают, что в детстве изучение формата ELF привело к интересу к Linux и программированию.
• Обсуждается, что обработка исполняемых файлов теперь происходит в пространстве пользователя, что, как предполагается, может уменьшить риск крашей ядра из-за ошибок в формате.
• Участники вспоминают, что когда-то процесс загрузки ELF-файлов назывался "image activation", и что эта терминология исчезла после dot-com краха и появления LLM.
• Несколько человек спорят о том, как именно загружаются статические бинарники: часть считает, что ядро все еще обрабатывает их, другие утверждают, что это не так.

• Обсуждение охватывает вопросы динамического связывания, загрузки ELF-файлов и влияния различных библиотек на размер бинарника, а также затрагивает тему встроенных файлов в бинарнике и использования shebang-ов в Unix-подобных системах.
• Участники обмениваются ссылками на статьи и инструменты, включая https://cpu.land и https://blog.foletta.net/post/2021-04-19-what-the-
• Обсуждение также касается вопросов, связанных с тем, как стек растет вниз, а не вверх, как это обычно изображается в учебниках, и как это влияет на обучение студентов.
• Участники также обсуждают, что влияет на размер бинарника, и какие еще факторы могут влиять на него, включая использование статической линковки, встроенных файлов и других аспектов.

Тактильность — это не просто физическое ощущение, а сложный феномен, влияющий на восприятие, эмоции и взаимодействие с миром. Она играет ключевую роль в пользовательском опыте: от сенсорных экранов до дизайна продуктов, где текстура и вес создают ощущение качества. Исследования показывают, что тактильные сигналы могут усиливать доверие и запоминаемость, например, в розничной торговле или цифровых интерфейсах.

Виртуальная реальность и хаптические технологии активно развиваются, имитируя прикосновения для более immersive-опыта. Интересно, что тактильная обратная свядь иногда перевешивает визуальную — люди чаще доверяют тому, что могут «пощупать». Это подчёркивает её фундаментальное значение в эпоху доминирования цифровых взаимодействий.

• Обсуждение возможностей и ограничений ESP32-устройств, включая поддержку загружаемых нативных приложений (ELF apps) в проекте Tactility.
• Рассмотрение альтернативных языков и сред для ESP32, таких как Toit, Nim, BASIC (Picomite) и Java, а также поддержка RISC-V архитектуры.
• Исследование практических применений: от IoT до портативных менеджеров паролей, клиентов для мессенджеров (IRC) и устройств с сотовой связью.
• Критика и скептицизм относительно ограниченных ресурсов ESP32 (памяти) для выполнения сложных задач, таких как динамическая линковка.
• Сравнение Tactility с другими проектами (Flipper, Zephyr) и обсуждение его статуса как операционной системы.

jacobly0 предлагает полностью переписать линкер Zig с нуля, создав Elf2 вместо текущей реализации. Основная цель — повысить производительность, уменьшить потребление памяти и улучшить поддержку различных форматов объектных файлов. Новая архитектура позволит эффективнее обрабатывать символы, секции и релокации, избегая проблем существующего кода.

Ключевые улучшения включают параллельную обработку, лучшую диагностику ошибок и оптимизацию для больших проектов. Это может значительно ускорить сборку в экосистеме Zig и упростить дальнейшее расширение. Практический вывод: переписывание устаревших компонентов иногда необходимо для долгосрочной масштабируемости.

• Участники высоко оценивают Zig как компилятор для C/C++ и инструмент кросс-компиляции за его простоту и самодостаточность.
• Отмечается мощная вертикально интегрированная система сборки Zig, включающая линкер и бэкенды генерации кода, что открывает возможности для оптимизаций.
• Обсуждаются ограничения использования линкера Zig (elf2) и самого компилятора вне экосистемы Zig, а также отсутствие неструктурированного goto.
• Некоторые пользователи выражают смешанные чувства: язык делает многое правильно, но отдельные изменения и особенности вызывают сомнения.
• Упоминается книга "Linkers and Loaders" и общее оживление в области разработки линкеров (ренессанс).