Hacker News Digest

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

После обращения за поддержкой доходы Libera Chat на Liberapay выросли примерно в 4 раза, а также поступили крупные разовые пожертвования и оборудование. Юридическая фирма предоставила заключение, что Libera Chat может аргументировать отсутствие достаточных связей с Великобританией для применения Закона о безопасности в интернете (OSA), и риск попыток принудительного исполнения даже при ином раскладе минимален. Организация не планирует вводить требования ID-проверки в обозримом будущем.

Libera Chat, базирующаяся в Швеции со шведским банком и несколькими серверами в UK, стремится избежать блокировки доступа для британских пользователей, как это сделали некоторые другие сообщества. OSA применяется к провайдерам услуг с "значительным числом пользователей в UK" или UK как целевым рынком. Интересно, что наличие сотрудников в UK не автоматически создает связи с UK для целей OSA, если они не взаимодействуют с сервисом как пользователи.

• Libera.chat и другие IRC-сети утверждают, что не подпадают под действие закона, потому что у них недостаточно «значительной» доли пользователей в Великобритании, и что они могут продолжать обслуживать пользователей в Великобритании без соблюдения требований к идентификации.
• Однако, в обсуждении поднимается вопрос, что «значительность» может быть интерпретирована регулятором иначе, и что даже если IRC-сеть может избежать ответственности сейчас, в будущем она может быть поставлена под угрозу.
• Также обсуждается, что даже если IRC-сеть может избежать ответственности, то это не обязательно будет иметь значение для других сервисов, которые могут быть затронуты.
• Некоторые комментаторы поднимают вопрос, что если вы не можете быть уверены, что вы не подпадаете под действие закона, то вы должны быть осторожны в отношении Великобритании.
• Наконец, обсуждается, что если вы не можете быть уверены, что вы не подпадаете под действие закона, то вы должны быть осторожны в отношении Великобритании.

Обработка камней в барабанном шлифовальнике позволяет превратить необработанные камни в красивые полированные камни, принося чувство удовлетворения. Процесс прост, если следовать определенной процедуре и правилам. Наилучшие результаты достигаются с материалами твердостью по Моусу 6-7 и размером от 3/8" до 1 1/2". К наиболее часто обрабатываемым материалам относятся халцедон (агат, яшма, сердолик), кварц (аметист, цитрин, розовый кварц) и различные горные породы (гранит, базальт, кварцит).

Существуют три "золотых правила" обработки камней: "Мусор на входе - мусор на выходе" (начинайте с качественного сырья, отбрасывая пористые или треснувшие камни), "Избегайте загрязнения" (используйте разные абразивы для каждого этапа, чтобы избежать царапин) и "Отличные результаты требуют времени". Качественный исходный материал экономит время и дает лучший результат, а покупка у активных энтузиастов обработки камней гарантирует более точное описание и лучшие образцы.

• Разные люди делятся опытом: кто-то вспоминает, как в детстве мать привозила домой гальку с моря; кто-то рассказывает, что тумблер действительно шумный, но можно использовать керамический наполнитель и стеклянную крошку вместо «правильных» камней, чтобы сократить шум и ускорить процесс.
• Обсуждается, что делать с камнями после полировки: кто-то продаёт их на Etsy, кто-то дарит друзьям, кто-то использует как декоративные элементы в аквариуме.
• Участники обмениваются советами, как сделать процесс менее шумным и быстрее: использовать керамический наполнитель в барабане, чтобы сократить шум и ускорить процесс.
• Некоторые участники делятся личными историями: кто-то вспоминает, как в детстве хотел купить морскую стекляшку, но вместо этого получил обычную книгу с замком; кто-то вспоминает, как хотел купить набор для выращивания морских обитателей, но вместо этого получил пакетик сухого брюхов.

Hmm, considering this is on mac rumours, the title does make sense. But it sounds like the more accurate title would be "Windows 10 Deadline Expedites Fleet Renewels". The +17% in lenovo shipments, along with increases for HP and Asus, will all come with Windows 11 installation c

Synadia и TigerBeetle совместно выделили $512,000 на поддержку Zig Software Foundation в течение двух лет. Synadia, создатель NATS.io, помогает крупным предприятиям проектировать и масштабировать архитектуры в облаке и на периферии, обслуживая клиентов в финансовой сфере, электронной коммерции, гейминге и промышленном IoT. TigerBeetle, финансовая база данных, разработанная на Zig с философией "TigerStyle", подчеркивает правильность, ясность и надежность.

Основатель Synadia Дерек Коллисон отметил, что Zig переопределяет возможности современного системного программирования благодаря своему подходу к контролю, производительности и простоте. Основатель TigerBeetle Йоран Дирк Гриф выразил уверенность, что Zig сыграет основополагающую роль в следующем поколении надежных распределенных систем. Обе компании разделяют видение предсказуемого, простого и заслуживающего доверия программного обеспечения, поддерживая Эндрю Келли и весь Zig-сообщество.

• Оценивали Rust, Zig и Ada/SPARK для критически важного ПО; Rust имеет поддержку корпорации и сообщества, но не применяется в кибер-физических системах.
• TigerBeetle получил $512k в течение 2 лет от Synadia и TigerBeetle, что вызвало вопросы о стратегии финансирования и приоритете языков.
• Обсуждение вылилось в обмен любезностями и техническими деталями, включая предположения о переходе на Zig и оставлении Rust без должной поддержки.

В статье рассматривается создание микро-Linux дистрибутива с нуля, включая сборку ядра Linux и разработку ПО для упаковки. Пример реализован для архитектуры RISC-V (QEMU riscv64 virt), но подход применим и к x86. Автор предупреждает, что это упрощенное представление Linux-дистрибутива, предназначенное для начинающих, и некоторые детали могут быть неточны на 0.1%.

Ядро операционной системы выполняет несколько ключевых функций: обеспечивает одновременное выполнение программ даже на одноядерных устройствах, абстрагирует низкоуровневые операции с оборудованием, предоставляя разработчикам простые высокоуровневые интерфейсы. Вместо того чтобы знать физические адреса устройств, приложения просто сообщают ядру о своих потребностях (например, "вывести сообщение на стандартный вывод"). Также ядро предоставляет файловые системы как интерфейсы для взаимодействия с данными, которые могут храниться не только на дисках, и создает программную модель, позволяющую приложениям работать независимо, не зная друг о друге.

• Обсуждение вращается вокруг создания минимальной Linux-системы: от идеи до практических нюансов (UEFI, cloud-init, PXE, initramfs, cpio, u-root, kexec, Gentoo vs LFS vs Buildroot).
• Участники делятся опытом, что «маленькая» сборка может быть полезна как для обучения, так и для практического применения (например, как образ для облачных инстансов).
• Обсуждаются различные инструменты и подходы: от полностью статически слинкованных бинарников до полноценных дистрибутивов, а также варианты с использованием u-root, kexec, initramfs, cpio, PXE и т.д.
• Участники также обсуждают, что такие мини-дистрибутивы могут быть полезны для обучения, отладки и даже как основа для специализированных образов (например, для RPi или как образ для облачных провайдеров).

Автор отмечает, что хотя ИИ хорошо справляется с рутинными задачами, он все еще уступает в организации кода. Качественный код требует четкой структуры, которую автор предлагает делить на три уровня: интерфейсный (контроллеры, работа с БД, HTTP-клиенты), сервисный (изолированная бизнес-логика) и шаблонный (логирование, авторизация). Основная проблема — при связывании этих компонентов приходится постоянно обрабатывать исключения и нулевые значения, что приводит к громоздкому коду с множеством проверок.

Решением автор предлагает паттерн Result — "обертку", которая инкапсулирует обработку ошибок и нулевых значений. В примере показано, как традиционный imperative-стиль с многочисленными if-try-catch блоками заменяется на более элегантное решение с использованием Result. Такой подход позволяет писать более чистый, тестируемый и поддерживаемый код, где основная логика не теряется в море проверок на null и обработке исключений.

• Обсуждение показало, что вопросы вокруг Result/Either в разных языках и экосистемах (Kotlin, Java, TypeScript, Rust, Scala) вызывают много споров: отсутствие стандартного Result в Java, влияние на производительность, сигнатуры типов и то, как библиотеки влияют на эргономику кода.

• Участники поделились опытом с такими библиотеками как Vavr, Effect-TS, neverthrow и другими, а также обсудили, как языки вроде Rust и Kotlin встроенные типы Result делают эти вопросы менее болезненными.

• Были затронуты темы производительности, где обсуждались традиционные исключения против возвращаемых значений-оберток вроде Result/Either, и как это влияет на написание кода и его читаемость.

• Также обсуждались такие темы, как то, что встроенные типы вроде Try в Scala или Result в Kotlin могут быть использованы для упрощения кода клиентов API и как это влияет на дизайн библиотек и фреймворков.

• В конце обсуждение сошлось на то, что в конечном счете, выбор между исключениями и возвращаемыми значениями-обертками часто сводится к тому, что контекст важнее: внутренние библиотеки языка, экосистема и то, как сообщество будет использовать API.

Несмотря на 15 лет развития фронтенда, сравнение React и Backbone показывает удивительно мало прогресса в снижении сложности. Код для одинаковой функциональности в обеих фреймворках примерно одинаков по длине, что ставит под сомнение все усилия сообщества. React выглядит чище, но это достигается за счет скрытой сложности абстракций, в то время как Backbone предлагает явное, хоть и многословное, описание происходящего.

"Вы торгуете явной простотой за сложность абстракций" — ключевая мысль статьи. React скрывает множество деталей: неожиданное очищение инпутов из-за смены ключей компонентов, бесконечные циклы в useEffect из-за нестабильных зависимостей, "устаревшие" замыкания в обработчиках событий. Эти не крайние случаи, а обычные проблемы, требующие понимания алгоритмов согласования, фаз рендеринга и планировщика React.

Для 99% приложений, не имеющих тысячи компонентов на странице, такая сложность может быть избыточна. Фундаментальная задача "событие + состояние = UI" остается простой, но современные фреймворки создают ненужные абстракции, мешающие пониманию и отладке. Возможно, сообществу стоит искать более прозрачные и "взламываемые" решения, подобные Backbone и jQuery.

• Обсуждение показало, что споры между сторонниками React и Backbone часто сводятся к сравнению простых примеров, что не отражает реальную сложность больших приложений и может вводить в заблуждение.
• Участники подчеркнули, что React и Backbone решают разные задачи: первый предлагает сложную, но мощную систему управления состоянием, тогда как второй предоставляет прямой и прозрачный контроль над DOM.
• Несколько человек отметили, что выбор между инструментами должен зависеть от характера проекта и команды, а не от сравнения "Hello World" примеров.
• Обсуждение также затронуло вопрос о том, что разработчики могут переоценивать или недооценивать сложность, связанную с управлением состоянием, и как это влияет на выбор инструмента.
• Наконец, было высказано мнение, что выбор между React и Backbone должен быть основан на факторах, таких как размер команды, сложность проекта и долгосрочная поддерживаемость, а не на сравнение простых примеров кода.

OpenAI представила браузер Atlas, который автор называет "анти-веб" браузером, поскольку он активно борется с принципами открытого интернета. По умолчанию Atlas не ведет пользователей на реальные веб-страницы, а подменяет их контентом, сгенерированным ИИ. Когда автор искал "Taylor Swift showgirl", получил результат, похожий на веб-страницу, но без единой ссылки на официальный сайт певицы. Это создает "внутренний сад" из ИИ-контента, где пользователь заперт, не имея доступа к реальной информации.

Интерфейс браузера требует от пользователей угадывать команды вместо использования интуитивных кликабельных ссылок, что автор сравнивает с устаревшими текстовыми интерфейсами 1980-х годов. "Atlas - это браузер, но не веб-браузер. Это анти-веб браузер", - подчеркивает автор. Хотя при запуске есть предупреждение о возможной неточности информации, оно не отражает того факта, что браузер может полностью fabrircate контент, выдавая его за реальные веб-результаты.

• Обсуждение вращается вокруг того, что OpenAI и другие компании стремятся не просто создать браузер, а встроить себя в поток данных, что вызывает опасения по поводу приватности и безопасности.
• Участники обсуждают, что браузер Atlas, как и другие подобные продукты, не предоставляет ссылки на первоисточники, что подрывает саму идею веба как такового.
• Обсуждается, что вместо того, чтобы предоставлять пользователю прямой доступ к информации, эти продукты вместо этого изолируют его внутри их собственной экосистемы, что вызывает опасения по поводу монополизации и контроля над информацией.
• Участники также обсуждают, что такие продукты могут быть использованы для сбора персональных данных, что может быть использовано для таргетированой рекламы или других целей.
• В конце концов, обсуждение приходит к выводу, что вместо того, чтобы позволить технологическим компаниям встроить себя в поток данных, следует развивать открытые и прозрачные технологии, которые бы позволили пользователям иметь контроль над их собственными данными и приватностью.

• Пользователи обсуждают, что OpenAI требует верификацию личности для доступа к GPT-5, что вызывает обеспокоенность конфиденциальностью и возможной дискриминацией.
• Некоторые участники упоминают альтернативные модели, такие как GLM-4 и Kimi, которые не требуют верификации и могут быть более доступны.
• Обсуждается, что OpenAI может использовать верификацию для сбора персональных данных и что это может быть связано с мировым проектом Worldcoin.
• Участники также обсуждают, что OpenAI может быть использует верификацию для ограничения доступа к моделям и создания барьеров для конкурентов.
• Некоторые участники выражают обеспокоенность по поводу того, что OpenAI может быть использует верификацию для сбора персональных данных и что это может быть связано с мировым проектом Worldcoin.