• Критика системы правосудия США как несвободной и репрессивной.
• Утверждение о неизбежности судебного преследования даже при оправдательном приговоре ("поездка" хуже "обвинения").
• Пример нарушения закона CFAA при несанкционированном доступе к аккаунту (например, Netflix родственника).
• Тезис о совершении нескольких уголовных преступлений ежедневно без осознания этого.
• Рекомендация обратиться в Фонд электронных рубежей (EFF) за помощью.
• Характеристика ситуации как обыденности для полицейского государства.
• Ссылка на решение Верховного суда по делу Van Buren v. United States, уточняющее трактовку "превышения авторизованного доступа" по CFAA.

• Пользователи рекомендуют фильм "Подставленные" (Sneakers) как очень занимательный и стоящий просмотра.
• Участники обсуждения выражают соболезнования в связи со смертью Роберта Редфорда, вспоминая его как "Сандэнс Кид".
• Предоставлена ссылка на архивную статью, посвященную памяти актера.
• Редфорд отмечен как выдающийся человек и вне съемочной площадки, использовавший свою славу и ресурсы для значимых целей.
• Его биография упомянута как достойная прочтения.
• Перечислены знаковые фильмы с его участием: "Афера", "Вся президентская рать", "Великий Уолдо Пеппер", "Джеремайя Джонсон".
• Упомянута его редкая роль в сериале "Сумеречная зона" в образе Смерти.
• Процитирована известная фраза "Мой голос - мой паспорт. Верифицируйте меня" из фильма "Подставленные".

Компрометация пакетов ctrl/tinycolor и 40+ других в NPM

Популярный пакет @ctrl/tinycolor с более чем 2 млн загрузок в неделю был скомпрометирован вместе с 40+ другими пакетами в результате сложной атаки на цепочку поставок. Вредоносное ПО самораспространяется по пакетам maintainer'ов, собирает учетные данные AWS/GCP/Azure с помощью TruffleHog и создает бэкдоры через GitHub Actions.

Технический анализ

Атака реализуется через многоступенчатую цепочку, использующую Node.js process.env для доступа к учетным данным. Основной элемент — файл bundle.js (~3.6 МБ), который выполняется асинхронно во время npm install.

Механизм самораспространения
Вредоносное ПО через функцию NpmModule.updatePackage запрашивает API реестра NPM для получения до 20 пакетов maintainer'а и принудительно публикует обновления, создавая каскадный эффект компрометации.

Сбор учетных данных
Используются инструменты вроде TruffleHog для сканирования файловой системы на наличие секретов. Целевые учетные данные включают:

• Токены доступа GitHub
• Ключи доступа AWS
• Учетные данные Google Cloud Platform

• Пользователи выражают обеспокоенность невозможностью аудита всех зависимостей и их уязвимостью к атакам в npm.
• Критикуется архитектура npm, в частности выполнение postinstall-скриптов по умолчанию, в отличие от других менеджеров пакетов.
• Предлагаются решения: игнорирование скриптов в настройках, песочница (bubblewrap), использование подписей кода и каррированных пакетов.
• Указывается на системную проблему экосистемы JS: огромное количество мелких зависимостей и отсутствие сильной стандартной библиотеки.
• Обсуждается масштаб атаки (180+ пакетов) и её возможная связь с государственными акторами.
• Поднимается вопрос уязвимости других экосистем (PyPI) и необходимости обязательной 2FA и подписи артефактов.
• Высказываются радикальные предложения по замене npm или созданию безопасного форка/дистрибутива пакетов.

• Обсуждаются строгие правила CRAN для R-пакетов, требующие обратной совместимости и тестирования всех зависимых пакетов при обновлении, что сравнивают с монорепозиторием.
• Поднимаются проблемы других экосистем (Python, npm), где распространены ломающие изменения и конфликты зависимостей, и отмечается стабильность R.
• Участники спорят о практичности подхода CRAN: одни видят в нём бремя для разработчиков, другие — выгоду для научной воспроизводимости и пользователей.
• Предлагаются альтернативы и обходные пути, такие как полное форкирование, версионирование API или контейнеризация.
• Отмечается уникальная философия R-сообщества, ориентированная на статистиков, а не на разработчиков, что объясняет такие жёсткие требования.

Ведущие юридические эксперты ООН пришли к выводу, что Израиль виновен в геноциде в Газе. Это наиболее авторитетный доклад ООН по данному вопросу, который может повлиять на решение Международного суда.

72-страничный отчёт комиссии ООН устанавливает, что Израиль совершил четыре из пяти запрещённых Конвенцией о геноциде действий, а израильские лидеры имели намерение уничтожить палестинцев в Газе как группу.

Председатель комиссии Нави Пиллэй подчеркнула, что все государства обязаны предотвращать геноцид в Газе, не дожидаясь судебного решения. Она призвала правительство Великобритании пересмотреть свою позицию.

Член комиссии Крис Сидоти заявил, что у стран больше нет оправданий для бездействия. Доклад имеет особую доказательную ценность и может использоваться международными судами.

• Обсуждение касается отчета ООН о геноциде в Газе и реакции на него, включая критику его предвзятости и обоснованности.
• Поднимаются вопросы о влиянии лоббистских групп, таких как AIPAC, на политику США и призывы к санкциям против Израиля.
• Участники обсуждают роль США и других западных стран в поддержке Израиля, несмотря на действия его правительства.
• Высказываются опасения о свободе слова и возможных репрессиях за критические высказывания, связанные с конфликтом.
• Многие комментаторы выражают личную позицию, превращаясь в «одновопросных избирателей» из-за событий в Газе.
• Часть пользователей считает, что подобные политические обсуждения не соответствуют тематике Hacker News, и многие комментарии были удалены или заблокированы.
• Отмечается недостаточное освещение отчета в основных СМИ и обсуждается, какую благотворительную помощь можно оказать жителям Газы.

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

Использование готовых библиотек компонентов, таких как HeroUI, помогает сохранять единообразие. Важно применять их "как есть", без кастомизации, и ограничивать набор стилей, чтобы избежать беспорядка. Такой подход экономит усилия и делает интерфейс целостным, даже если отдельные элементы не идеальны.

• Подчёркивается важность фундаментальных принципов дизайна (таких как гештальт), которые не зависят от технологий, в отличие от фреймворков и паттернов.
• Критикуется подход, ставящий эстетику выше функциональности и удобства использования; акцент делается на юзабилити, логику и чёткую структуру интерфейса.
• Обсуждается ценность глобальной консистентности и использования готовых библиотек компонентов против кастомных, но часто неудачных решений.
• Отмечается, что хороший дизайн начинается с глубокого понимания пользователя, а не просто со следования набору правил или созданию "красивого" интерфейса.
• Упоминаются конкретные ресурсы для обучения (книги вроде "The Design of Everyday Things", "Refactoring UI") и критика их дороговизны или поверхностного применения.

Метод public static void main(String[] args) больше не нужен для первой программы на Java. Теперь достаточно:

void main() {
    var name = IO.readln("Как тебя зовут? ");
    IO.println("Привет, " + name);
}

Наконец-то избавились от этого ужасного кода. Помню, как в школе спрашивал старшеклассника о значении этого метода — он не знал. Позже он бросил колледж и стал ютубером по Minecraft. Какая жизнь.

Выскажитесь в комментариях — дайте волю эмоциям.

• Пользователи обсуждают нововведение в Java 21 (JEP 445), которое упрощает объявление метода main, убирая необходимость в public static void main(String[] args).
• Многие вспоминают, как изучали этот синтаксис в начале своего пути в программировании и как со временем он становился понятным.
• Есть мнение, что изменение полезно для начинающих, так как уменьшает количество "магических заклинаний", которые нужно запомнить, чтобы написать первую программу.
• Часть участников скептически относится к изменению, считая, что явное объявление метода main было визитной карточкой Java и не создавало реальных проблем.
• Некоторые сравнивают это изменение с аналогичными упрощениями в других языках, например, в C#.
• Обсуждается, является ли это изменение лишь синтаксическим сахаром или же реальным улучшением языка, упрощающим его изучение.

Safepoints — это ключевой механизм синхронизации в Fil-C и других виртуальных машинах, обеспечивающий безопасность памяти в многопоточной среде. Они позволяют потокам делать предположения о состоянии VM и сообщать о своём текущем состоянии, что критично для точного сборщика мусора, отладки и профилирования. Без safepoints не было бы возможности безопасно сканировать стеки, обрабатывать сигналы или использовать fork.

Fil-C вставляет pollchecks — проверки на необходимость остановки — на каждом обратном ребре управления в коде. Это короткая инструкция вроде testb, которая при срабатывании переходит к медленному пути обработки. Такой подход гарантирует, что GC может прервать поток только в безопасных точках, избегая проблем с регистрами или векторными инструкциями, и сохраняя корректность без invasive изменений в компиляторе.

• Fil-C использует механизм pollchecks для остановки потоков (stop-the-world), что необходимо для корректной работы fork(2), но поддержка vfork(2) пока отсутствует и требует нестандартных решений.
• Внедрение safepoint-ов в ассемблерный код рискованно и может нарушить предположения Fil-C о безопасности памяти; в долгосрочной перспективе планируется создать способ написания безопасного ассемблерного кода.
• Подход Fil-C к сборке мусора с опросом точек остановки (polling) создает нагрузку в tight loops, что решается разными оптимизациями (например, разверткой циклов), в отличие от асинхронных сигналов в Go.
• Мнения о читаемости и понятности реализации Fil-C разделились: одни участники находят ее интересной и хорошо объясненной, другие признаются, что не до конца понимают детали.
• Утверждение, что Java использует исключительно compacting GC, является упрощением, учитывая множество доступных конфигураций сборщика мусора в разных реализациях JVM.

При обращении к данным пользователя в интерфейсах часто возникает вопрос: использовать «мой» или «ваш»? Например: «Мой аккаунт» или «Ваш аккаунт»? Но часто префикс не нужен вовсе — достаточно просто «Аккаунт», «Заказы», «Дела», как это делает Amazon.

Однако если в продукте есть элементы, принадлежащие и пользователю, и другим (например, система дел, где есть «мои дела» и «все дела»), возникает сложность. Использование «мои дела» в меню навигации кажется уместным, но вне меню — в onboarding, email-уведомлениях или справке — фраза «перейдите в мои дела» звучит неестественно. Если я скажу вам «перейдите в мои дела», вы подумаете о своих, а не о моих. Поддержка может рекомендовать «перейдите в ваши дела», что конфликтует с интерфейсом, где написано «мои дела».

С «ваш» таких проблем не возникает — этот подход проверен на множестве продуктов и не вызывает затруднений у пользователей.

Но есть нюанс: если пользователь общается с системой, например, через радиокнопки, корректнее использовать «мой». Например, на вопрос «Хотите поделиться своим фото профиля?» варианты ответа должны звучать как «Да, поделиться моим фото» и «Нет, не делиться моим фото». Использование «ваш» здесь некорректно, так как звучит как инструкция для компьютера поделиться своим фото, а не фото пользователя.

Итог:

• Используйте «ваш», когда обращаетесь к пользователю.
• Используйте «мой», когда пользователь обращается к системе.

• Рекомендуется использовать местоимение «your» (ваш/ваша/ваше) в интерфейсах, когда система обращается к пользователю, и «my» (мой/моя/моё), когда пользователь дает команду системе.
• Многие участники выступают против использования местоимений вообще, считая их избыточными и предлагая убирать притяжательные формы для упрощения (например, «Pictures» вместо «My Pictures»).
• Критикуется использование местоимения «we» (мы) системой, так как это создает ощущение патернализма и ложной вовлеченности пользователя в процесс («Let's add your account»).
• Подчеркивается важность контекста и согласованности в формулировках, особенно при локализации, поскольку в разных языках существуют разные нормы вежливости и формальности.
• Отмечается, что неправильное использование местоимений может приводить к путанице, особенно если продукт или функция уже содержит слово «My» в названии (например, «Your My Card»).
• Некоторые участники предпочитают, чтобы интерфейсы и системы общались более формально и машинообразно, без попыток казаться «дружелюбными» или человечными.
• Указывается на проблемы перевода и локализации, когда недостаток контекста для строк интерфейса приводит к ошибкам и неоднозначностям.
• Обсуждается, что лучшей практикой является обработка элементов интерфейса как собственных имен (использование кавычек, выделение) в инструкциях и поддержке, чтобы избежать путаницы с местоимениями.

Телефоны на Linux важнее, чем когда-либо

Android всегда был довольно открытой платформой, но в последние месяцы мы наблюдаем стремительную деградацию экосистемы:

1. Закрытие разработки всё большего числа компонентов в AOSP.
2. Samsung, Xiaomi и OnePlus убрали возможность разблокировки загрузчика. Google, вероятно, последует их примеру.
3. Внедрение Play Integrity API, которое поощряют разработчиков. Даже европейский кошелёк для верификации личности требует его использования, вопреки законам ЕС.
4. Обязательная верификация разработчиков на Android. Это затронет 99,9% устройств, и многие разработчики open-source могут просто прекратить создавать приложения для Android. SyncThing уже прекратил разработку из-за проблем с Google Play.

Google больше не конкурирует с Apple — он перенимает её методы. Android, каким мы его знаем, мёртв или скоро умрёт. Нам нужна открытая альтернатива.

Примечание: это не призыв переходить на Linux сегодня, а указание на необходимость ускорения разработки.

---

Комментарии

y0kai: Мой следующий телефон будет работать на Linux, даже если это неудобно. Как только этот телефон будет оплачен, я также уйду от Google Fi.

MasterOKhan: Я с тобой, я перевёл все свои компьютеры на Linux по похожим причинам. Недавно купил Android-телефон и установил на него Linux, хотя ещё есть над чем работать, например, со звуком и микрофоном. Жду не дождусь, когда смогу отказаться от iPhone.

• Пользователи выражают недовольство ограничениями Android, такими как блокировка скриншотов и записи звонков, несмотря на их законность в некоторых юрисдикциях.
• Обсуждаются возможные альтернативы: использование двух телефонов (один — для банковских приложений, другой — с открытой ОС) или переход на Linux-смартфоны.
• Отмечаются проблемы Linux-телефонов: короткое время работы от батареи, отсутствие поддержки популярных приложений (банки, мессенджеры) и сырой пользовательский опыт.
• Предлагаются решения: форк AOSP, создание устройств без модема (по аналогии с iPod Touch) или использование внешнего модема для разделения trusted/untrusted частей.
• Поднимается вопрос о необходимости открытой мобильной ОС из-за растущей зависимости от проприетарных платформ (Google/Apple) для доступа к госуслугам, банкингу и другим сервисам.
• Высказывается мнение, что усилия сообщества стоит направить на развитие реальных альтернатив (например, PostmarketOS), а не на кастомные прошивки Android.
• Отмечается, что ключевая проблема — не ОС, а экосистема приложений, которые зачастую требуют наличие Google Play Services и блокируются на нестандартных устройствах.
• Некоторые пользователи считают, что регулирование на уровне ЕС (например, форк Android) могло бы улучшить ситуацию с открытостью и безопасностью.