Hacker News Digest

Это сообщение об ошибке появляется, когда на сайте требуется JavaScript, но он отключен в браузере пользователя. Сайт не может загрузить необходимый компонент без включенного JavaScript, что блокирует доступ к функционалу.

Проблема может возникать из-за нескольких причин: использование браузерных расширений (блокировщиков рекламы), сетевые неполадки или настройки самого браузера. Для решения рекомендуется проверить интернет-соединение, временно отключить расширения, особенно блокировщики рекламы, или попробовать использовать другой браузер. Включение JavaScript позволит сайту корректно загрузить все необходимые элементы и обеспечить полноценную работу.

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

Пользователи Hacker News обсуждают, что делать, если твой проект на GitHub внезапно взлетел: за 12 часов он собрал 1000 звёзд, попал на главную страницу и начал приносить деньги. Кто-то предлагает «не вздумай трогать репозиторий», другие советуют «сделать его ещё лучше и не трогать». Тем не менее, большинство сходится на том, что важно не потерять моментум и продолжать фокусироваться на продукте и сообществе.

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

Автор, известный как «парень из Bundler», рассказывает о 15-летней истории проекта, который он помогал развивать с 2010 года. Изначально созданный Yehuda и Carl, Bundler быстро стал стандартом управления зависимостями в Ruby, сохранив свою структуру до версии 2.7.2. После ухода основателей автор взял на себя ведущую роль в поддержке, сотрудничая с Terence Lee и позже основав Ruby Together для финансирования разработки.

Сейчас Ruby Central заявляет права на владение названием Bundler, что противоречит духу сообщества. В ответ автор зарегистрировал товарный знак, чтобы защитить репутацию проекта и его maintainers, подчеркивая, что код остаётся под MIT-лицензией, а название принадлежит сообществу. Ключевая цель — обеспечить, чтобы решения по проекту принимались самими пользователями и разработчиками, а не одной организацией.

• Финансирование Ruby Central от спонсоров вроде Shopify было условием захвата контроля над Bundler и RubyGems, что привело к корпоративному захвату инфраструктуры.
• В ответ на это был зарегистрирован товарный знак Bundler, чтобы предотвратить захват и передать его под управление нового, действительно сообщественного органа.
• Ключевой риск — потеря давних мейнтейнеров, раскол сообщества и форк ключевой инфраструктуры, что создаст хаос.
• Сообщество ожидает ответа от Ruby Central, включая возобновление запланированного Zoom-звонка, но пока ситуация в подвешенном состоянии.
• Под вопросом юридическая сила товарного знака, так как его долгое отсутствие enforcement может означать отказ от прав или генерализацию.

Главное: «нет» — не вред, а забота.
Сохранять душу проекта важнее, чем расти функциями. Чёткая философия (зачем проект живёт) притягивает единомышленников и отпугивает «почти-полезное».

LLM-эра всё усложнила: код теперь дешёв, дискуссия исчезла. PR без issue — почти спам. FastMCP требует issue, но люди открывают односложные заглушки.

Как защищаться:

• Документируй «почему» в README.
• Перекладывай доказательную нагрузку на автора PR.
• Используй contrib/: полезный, но чуждый духу код живёт там без гарантий.

Личный вывод: раньше отвечал за 15 минут, теперь игнорю стену LLM-текста без MRE. Ручная работа и сообщество всё ещё делают проекты великими, а не «вайб-код».

• Мейнтейнеры устают от «приезжих» PR: люди присылают код, который не вписывается в философию проекта, не покрыт тестами или создан LLM-ом «на коленке».
• Популярный выход — чаще говорить «нет» и требовать предварительного issue; иначе проект превращается в вечный багажник чужих хотелок.
• Контрибьюторы возмущаются: «почему полезная фича отклонена?» Ответ: scope creep, лишняя сложность, поддержка ложится на одного человека, а время — конечный ресурс.
• Сторонники форков: хотите свою фичу — форкните, опубликуйте, сами и поддерживайте; мейнтейнер никому ничего не должен.
• LLM удешевили код, но не уменьшили расходы внимания мейнтейнера; дешёвые PR стали массовыми, обсуждение исчезает, поэтому «no» теперь дефолт.

Wikipedia живёт, потому что скучна
Пока весь интернет рушится, «вики» стоит. Её секрет — не в деньгах, а в правилах: нейтральный тон, проверяемые источники, консенсус редакторов.

Салют Маска как тест прочности
20 января 2025 года Илон Маск показал жест, похожий на нацистское приветствие. Первый редактор добавил фразу в статью, второй — удалил: биографии живых людей защищены строже. Началась многочасовая дискуссия: это был нацистский салют, неловкий жест или провокация? Вместо войны правок редакторы перешли к голосованию и источникам.

Почему это работает

• Правила > эмоций: каждое утверждение требует двух независимых публикаций.
• Скорость через процесс: новость появляется, когда её подтвердят, а не когда взорвётся твиттер.
• Скука как щит: отсутствие лайков и алгоритмов не даёт вирусному гневу захватить платформу.

Итог: Wikipedia остаётся последним островком фактов в океане контента, который ломается каждый день.

• Участники спорят, действительно ли Wikipedia «последний добрый остров» интернета: одни хвалят, другие критикуют за политическую ангажированность и «захваченность» тематическими кланами.
• Подчёркивают, что английская версия ещё держится, а вот неанглоязычные часто превращаются в пропаганду и исторические фальсификации.
• Отмечают рост давления со стороны властей (пример – запросы конгрессменов раскрыть имена редакторов) и опасность массовых доносов/доксинга внутри сообщества.
• Многие советуют читать не только статью, но и страницу обсуждения, а также историю правок, чтобы видеть, какие точки зрения вырезали и почему.
• Часть комментаторов считает, что выживание Wikipedia возможно именно благодаря медленному, «не-стартаповому» принципу и отсутствию прибыли, но ресурс уже «подсел» на пожертвования и всё чаще поддаётся внешнему влиянию.