Hacker News Digest

Разработчики создали IRC-клиент Halloy в Rust. Проект примечателен тем, что это не просто кроссплатформенный инструмент для чата, но и open-source проект, доступный на GitHub. Вместо стандартного подхода, Halloy предлагает современный интерфейс и функционал, вроде поддержки расширений и тем оформления, что редкость для IRC-клиентов, которые часто застревают в прошлом.

Основная идея — сделать IRC доступным и удобным для современных разработчиков, интегрируя его с современными инструментами. Например, Halloy поддерживает встраивание медиа и интеграцию с сервисами вроде GitHub. Проект набирает популярность, так как сочетает ностальгический протокол IRC с современными практиками разработки.

• Halloy — современный IRC-клиент, написанный на Rust и использующий iced.
• Пользователи отмечают высокую скорость, стабильность и удобство настройки через TOML-файл.
• Поддержка нескольких серверов и каналов, но пока нет вкладок; вместо этого используется буфер-менеджер.
• Проект открытого кода, активно развивается и принимает PR.
• Некоторые пользователи отмечают, что Halloy всё ещё не поддерживает некоторые функции, такие как вкладки, минимизация в трей и полная поддержка экранных читателей.

#3.1 #1.1 #1.1 #1.1

• Программа «выборочных художников» в Ирландии вызывает споры: она не универсальна, исключает тех, кто не может позволить себе быть художником, и не соответствует концепции UBI.
• Критика включает: отсутствие прозрачности в отборе, несправедливые критерии, и то, что это не является универсальным базовым доходом (UBI), как это подразумевается.
• Дебаты также охватывают более широкие вопросы, такие как универсальный базовый доход (UBI), налоговые льготы для технологических компаний, и как общество должно поддерживать художников и других творческих профессионалов.
• Некоторые комментаторы поднимают вопрос о том, что это может быть попыткой использовать художников в качестве оправдания для налоговых льгот.
• Другие указывают на то, что вместо того, чтобы предоставлять базовый доход всем, правительство выбрало только «выбранных» художников, что противоречит идее UBI.
• Некоторые также выражают обеспокоенность о том, что эта программа может быть использована для оправдания налоговых льгот для технологических компаний, которые не предоставляют рабочие места или достойную оплату.
• Наконец, некоторые комментаторы поднимают вопрос о том, что правительство должно предоставлять базовый доход всем гражданам, а не только «выбранным» художникам, и что это может быть лучшим способом поддержки художников и других творческих профессионалов.

• Обсуждение показало, что serverless не всегда подходит для высоконагруженных API, особенно если требуется низкая латентность и стабильность.
• Участники отметили, что serverless может быть полезен для MVP или спайков, но не для высоконагруженных сервисов.
• Некоторые участники подчеркнули, что serverless может быть дороже и сложнее в управлении, чем традиционные серверы.
• Было отмечено, что serverless может быть полезен для специфических задач, таких как обработка фото или видео, но не для высоконагруженных API.
• Участники также обсудили, что выбор между serverless и традиционными серверами должен основываться на конкретных потребностях и ограничениях проекта.

Этот проект под названием DataCops разрабатывает инструменты для анализа рекламных трат и обнаружения поддельного трафика.

Вот основной вывод: до 73% посетителей интернет-магазинов могут быть фейковыми, что искажает маркетинговую аналитику.

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

Особенно опасны боты, симулирующие "холодных" пользователей — тех, кто лишь просматривает сайт. Они составляют до 68% трафика в некоторых случаях.

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

Реальная ценность — в защите малого бизнеса. Представьте: вы платите $1,000 за рекламу, рассчитывая на 10,000 посетителей, но 7,300 из них — боты. Это не просто потеря денег, это крах оптимизации и аналитики.

Компании вроде DataCops строят защиту, перенося аналитику на сервер первого

• Большая часть трафика в интернете — это боты, и это не новость: в 2024 году 73 % трафика на 200+ сайтов оказалось ботами.
• Рекламная индустрия страдает от фрода с самого начала, но вместо решения проблемы, она использует это как повод для взвинчивания цен на рекламу.
• Сайты, которые продают собственные продукты, не должны быть зависимы от рекламы, но вместо этого они встраивают трекинг и продают эти данные третьим лицам.
• Платформа, такие как Google и Meta, обвиняются в том, что они не могут отличить ботов от людей, но вместо этого они продолжают продавать рекламу, зная, что она не будет эффективной.
• В конце концов, вся эта система построена на лжи и фальшивых метриках, и это не только неэффективно, но и вредит всем участникам рынка.

• Ветряные фермы в Шотландии производят электричество, которое не может быть использовано из-за отсутствия линий передачи, что приводит к потере 1.5 миллионов фунтов в день. Это подчеркивает необходимость инвестиций в инфраструктуру передачи электричества и поднимает вопрос о том, как эффективно используется возобновляемая энергия.
• Проблема нехватки линий передачи влияет на стоимость электричества для потребителей, так как цена формируется на основе самого дорогого источника энергии. Это подчеркивает необходимость инвестиций в инфраструктуру передачи электричества и поднимает вопрос о том, как эффективно используется возобновляемая энергия.
• Проблема нехватки линий передачи влияет на стоимость электричества для потребителей, так как цена формируется на основе самого дорогого источника энергии. Это подчеркивает необходимость инвестиций в инфраструктуру передачи электричества и поднимает вопрос о том, как эффективно используется возобновляемая энергия.
• Проблема нехватки линий передачи влияет на стоимость электричества для потребителей, так как цена формируется на основе самого дорогого источника энергии. Это подчеркивает необходимость инвестиций в инфраструктуру передачи электричества и поднимает вопрос о том, как эффективно используется возобновляемая энергия.

Разработчик приложения Inkdrop получил пугающее письмо от пользователя, сообщавшего о проблеме с cookie consent, блокирующим доступ к сайту. Странно было то, что сайт приложения вообще не использует cookie consent — отслеживание и реклама отсутствуют. В ответ на запрос автора уточнить детали, пользователь прислал ссылку на "скриншот", которая вела на страницу с капчей и требованием выполнить вредоносную команду в терминале.

Команда, скопированная в буфер обмена, скачивала и выполняла удалённый shell-скрипт. Хотя Gmail пометил второй ответ как спам, первый выглядел вполне нормально. Такие фишинговые атаки становятся всё более изощрёнными, часто имитирующие реальные запросы поддержки. Даже на форумах автора появляются подозрительные посты, написанные, вероятно, ИИ, которые выглядят естественно, но содержат скрытые угрозы.

• Сообщения в треде подчеркивают, что фишинг становится всё более изощрённым: злоумышленники маскируют вредоносные ссылки под видом Google Sites, Cloudflare, Dropbox и т.д., а также используют фейковые сервисы поддержки, чтобы выманить у пользователей конфиденциальные данные.
• Участники обсуждения отмечают, что даже технически подкованные пользователи могут быть обмануты, если злоумышленник использует правдоподобные, но поддельные домены и визуально неотличимые от легитимных сервисов ссылки.
• Обсуждение также поднимает вопрос о том, что даже если пользователь не ведётся на кликбейт, то вредоносное ПО может быть скачено и запущено в фоновом режиме, если пользователь просто открыл вредонусную страницу в браузере.
• Участники также обсуждают, что в условиях, когда всё большее и большее количество людей полагаются на ИИ-ассистенты вроде ChatGPT, фишинг может стать ещё более изощрённым и трудным для обнаружения.
• Наконец, участники обсуждения подчеркивают, что важно помнить, что никакие легитимные сервисы не будут просить вас запустить что-то в терминале и что всегда стоит проверять URL-адреса, особенно если они ведут на сайты, которые вы не ожидаете увидеть.

Европа пытается усилить контроль над приватными сообщениями, требуя сканирования даже зашифрованного контента, но это подрывает саму идею цифрового суверенитета. Германия недавно заблокировала голосование по так называемому "Chat Control", что даёт отсрочку до декабря.

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

Компании вроде Proton и Element выступают против, указывая, что безопасность — это не опция, а фундамент. Без шифрования нет доверия к цифровым сервисам, а значит, и суверенитета.

Дебаты в ЕС сейчас — это не только о приватности, но и о стратегической автономии. Зависимость от неевропейских tech-гигантов усугубляется, если местные компании вынуждены встраивать уязвимости в свои продукты.

Декабрь покажет, сможет ли Европа выбрать гармонию между безопасностью и свободой.

• Продолжающийся конфликт между технологическим суверенитетом и правом на приватность в ЕС; вопрос в том, что ЕС не стремится к технологическому суверенитету и вместо этого продолжает полагаться на американские технологические компании.
• Дискуссия о том, что ЕС не имеет собственной технологической индустрии, и что это может быть связано с тем, что ЕС не защищает свои рынки от американских технологических компаний.
• Обсуждение о том, что ЕС не имеет собственной технологической индустрии, и что это может быть связано с тем, что ЕС не защищает свои рынки от американских технологических компаний.
• Обсуждение о том, что ЕС не имеет собственной технологической индустрии, и что это может быть связано с тем, что ЕС не защищает свои рынки от американских технологических компаний.

Остановка потоков Linux требует аккуратного подхода, особенно при работе с низкоуровневыми потоками, созданными через pthread_create или std::thread. В отличие от запуска, корректное завершение потоков позволяет выполнить очистку ресурсов — освобождение памяти, блокировок, сброс логов. Идеального универсального решения не существует, но есть несколько подходов.

Простой метод — организация квази-активного ожидания в каждом потоке с проверкой флага остановки. Когда нужно завершить поток, флаг устанавливается в true, после чего вызывается pthread_join. Цикл не должен быть полностью неблокирующим, но должен завершаться за разумное время. Для потоков, блокирующихся на системных вызовах, используются сигналы для прерывания выполнения. Важно, что даже с этим подходом нужно учитывать обработку сигналов для корректной работы с буферизированным выводом.

• Проблема заключается в том, что POSIX не предоставляет безопасного механизма для остановки потока, и это приводит к тому, что разработчики вынуждены полагаться на pthread_cancel, который небезопасен и может привести к утечкам ресурсов или повреждению состояния.
• Попытки использовать SIGUSR1 и signalfd для обработки сигналов в пространстве пользователя не решают проблему, потому что большинство библиотек не ожидают, что их вызовы будут прерваны, и это может привести к повреждению состояния.
• Вместо этого, вместо попыток остановить поток, который может быть в любой точке, лучше структурировать код так, чтобы он мог реагировать на сигнал остановки, или использовать модель, где потоки не блокируются на системных вызовах, а вместо этого используют асинхронные вызовы и ожидают на poll/select/epoll/io_uring.
• Некоторые комментаторы отмечают, что в Linux существует io_uring, который позволяет прервать системный вызов, и что это может быть использовано для реализации остановки потока, но это не решает проблему, что не все вызовы могут быть прерваны таким образом.
• В конечном счёте, вместо попыток убить поток, который может быть в любой точке, лучше писать код так, чтобы он был отзывчив к сигналу остановки, и использовать модели, где потоки не блокируются на системных вызовах, а вместо этого используют асинхронные вызовы и ожидают на poll/select/epoll/io_uring.

В GitHub создан новый инструмент для управления задачами «Firm», который предназначен для разработчиков и технических специалистов. Он использует текстовый интерфейс для управления проектами, задачами и багами, интегрируясь с Git. Основная идея в том, чтобы обеспечить прозрачность и избежать навязывания конкретных инструментов, сохраняя при этом простоту и эффективность.

Инструмент позволяет создавать и отслеживать задачи прямо из командной строки, что ускоряет workflow. Он также поддерживает интеграцию с другими инструментами, такими как GitHub Issues, делая его мощным дополнением для разработчиков, уже использующих Git.

Ключевая особенность — минималистичный дизайн, который не мешает основной работе, и возможность настройки под конкретные нужды команды. Это пример того, как open-source инструменты могут улучшить продуктивность без добавления излишней сложности.

• Пользователи обсуждают CLI-ориентированные инструменты для управления бизнесом, но признают, что для широкого распространения нужен GUI.
• Обсуждается, что текстовые форматы (JSON, YAML) могут быть более удобны для LLM и человека, но вызывают проблемы с масштабируемостью и обработкой больших объемов данных.
• Участники отмечают, что подобные инструменты могут быть полезны для малого бизнеса и как личный инструмент разработчика, но сомневаются в их применимости для более широкого круга пользователей без GUI.
• Поднимается вопрос о том, что такие инструменты могут быть полезны для управления собственным бизнесом, но также отмечается, что для этого может быть достаточно уже существующих инструментов.
• Участники также обсуждают, что вместо изобретения нового формата данных, возможно, стоит использовать существующие форматы, такие как JSON или CSV, что может упростить интеграцию с другими инструментами.

Пользователь работает с несколькими моделями одновременно, каждая из которых выполняет атомарные коммиты. Основной стек — TypeScript и React, развернутый на Vercel.

Основная идея — использование инструмента codex (предположительно, внутренний инструмент или API) в качестве основного драйвера для разработки. Вместо того чтобы писать код вручную, пользователь использует несколько экземпляров codex (до 8 одновременно), каждый из которых работает над своей частью задачи. Каждый агент коммитит изменения самостоятельно, что позволяет поддерживать чистую историю.

Ключевые моменты:

• Контекст и координация. Несмотря на то, что агенты работают параллельно, пользователь тщательно управляет их работой, чтобы избегать конфликтов. Например, при работе над крупными изменениями он сначала запускает один агент для оценки, а затем уже основную группу.
• Инкрементальный подход. Вместо того чтобы пытаться решить все сразу, пользователь разбивает задачи на мелкие, атомарные шаги. Например, при обновлении зависимостей он не просто запускает скрипт, а сначала проверяет каждое изменение, затем тестирует, и только потом обновляет.
• Отказ от излишеств. Пользователь избегает сложных систем вроде прекоммит-хуков для валидации, так как они замедляют процесс. Вместо этого он полагается на то, что агенты достаточно умны, чтобы не допускать ошибок.
• Практичность. Инструменты выбираются по принципу "работает — не трогай". Например, codex используется вместо Claude Code, потому что последний стал слишком абстрактным (например, он может часами "думать" над простой задачей). codex же просто делает.

В целом, подход напоминает принцип "двигайся быстро и не ломай" (move fast and don't break things), но с уклоном в "двигаться быстро", даже если иногда что-то сломается. Это компенсируется скоростью: один агент может заменить целую команду, и даже если он ошибся, это быстро фиксится.

• Дискуссия разделилась на два лагеря: «AI пишет почти весь код» против «никакой AI не заменит разработчика»; при этом обе стороны сходятся в том, что важно уметь читать и ревьюить весь код, независимо от того, кто его написал.
• Участники обсуждали, что 300k строк кода, которые, как утверждается, были написаны ИИ, на самом деле могут быть просто увеличены в 10-15 раз по сравнению с тем, что написал бы человек, и что это вызывает сомнения в надёжности такого подхода.
• Поднимался вопрос о том, насколько можно доверять ИИ-написанному коду, и какие именно навыки требуются, чтобы эффективно использовать такие инструменты.
• Также обсуждалось, что важно ли вообще писать статьи о таких инструментах, если они не раскрывают, как именно они используются, и какие именно задачи они решают.