Hacker News Digest

В середине XX века власти США начали массово запрещать доступное жильё для бедных — комнаты с общими кухнями и санузлами, известные как SRO (single-room occupancies). К 1950-м годам они составляли до 10% арендного фонда крупных городов и стоили эквивалент $100–300 в месяц по сегодняшним меркам. Однако под давлением общественности и политиков города приняли жёсткие zoning-нормы: ограничили число неродственников в одном доме, потребовали отдельные ванные комнаты и парковочные места, что сделало совместное проживание практически незаконным.

Исчезновение SRO совпало с резким ростом бездомности — с конца 1970-х проблема стала массовой. Сегодня штаты вроде Айовы, Орегона и Колорадо начали отменять эти ограничения, разрешая сдачу свободных комнат. Простейшее решение жилищного кризиса — позволить людям делить жильё наравне с родственниками, используя миллионы пустующих спален.

• Обсуждение касается законов, ограничивающих совместное проживание неродственных людей в одном жилом помещении (т.н. "brothel laws" или законы против SRO), которые существуют во многих юрисдикциях США и Европы.
• Участники отмечают, что подобные нормы часто приводят к дефициту доступного жилья, росту цен на аренду и усугублению проблемы бездомности, исключая такие форматы, как доходные дома и совместные съемные квартиры.
• Поднимается вопрос о различии между совместной арендой на одну семью (несколько человек в одном договоре) и индивидуальной арендой комнат (отдельные договоры), где последняя часто попадает под запрет или строгое регулирование.
• Высказываются мнения, что эти законы исторически создавались для предотвращения трущоб и обеспечения безопасности, но сейчас часто используются для сохранения высоких цен на недвижимость и социальной сегрегации.
• Участники из разных стран (Великобритания, Германия) приводят в пример регулируемые форматы совместного проживания (HMO), которые, по их мнению, доказывают возможность безопасного и легального существования такого жилья.

Zig предлагает более простой подход к созданию CLI-инструментов по сравнению с Rust, особенно когда речь идёт о работе с памятью. В Rust строгий borrow checker предотвращает ошибки на этапе компиляции, но часто вынуждает переписывать код под его требования, усложняя разработку. Например, при попытке добавить новую запись в список, одновременно удерживая ссылки на существующие, компилятор Rust блокирует действие из-за конфликта владения и заимствования.

В Zig же разработчик напрямую управляет памятью через аллокаторы, используя указатели и мутацию без сложных правил времён жизни. Это требует дисциплины, но даёт больше гибкости и скорости написания кода. Для CLI-инструментов, где производительность и простота часто важнее абсолютной безопасности памяти, Zig оказывается практичнее. Безопасность — это не только отсутствие ошибок памяти, но и читаемость, скорость разработки и соответствие задаче.

• Обсуждение затрагивает проблемы безопасности в C, связанные с ручным управлением памятью, и ироничные комментарии по этому поводу.
• Пользователи делятся мнениями о современных языках (Nim, Odin, V, D, Zig), отмечая их преимущества, такие как интероперабельность с C и гибкость в управлении памятью.
• Уточняется функциональность Zig: он не компилируется в C, но имеет инструмент для трансляции C-кода в Zig, при этом компилируясь напрямую в машинный код.
• В обсуждении присутствует юмористический тон относительно утверждения, что разработчики не являются идиотами.

HTMX предлагает декларативный подход к веб-разработке через HTML-атрибуты, что могло бы сократить потребность в JavaScript, если бы браузеры поддерживали такие семантики изначально. Однако автор отмечает, что HTMX не предоставляет чёткой структуры, подобной SPA-фреймворкам, что ведёт к риску создания спагетти-кода, как в случае с jQuery.

В ответ на это был создан MESH — фреймворк, сочетающий модульный SSR с гидрацией, где каждый компонент соответствует одному эндпоинту. Это позволяет писать бэкенд с фокусом на HTML, сохраняя ощущение работы с SPA. Для демонстрации использовались Go, Templ и Declarative Shadow DOM, с небольшим хаком для обхода ограничений HTMX внутри теневых DOM. Ключевая идея — обеспечить единственно верный способ структурирования кода, избегая хаоса.

• Обсуждается применимость HTMX для различных типов приложений: отличное решение для многостраничных приложений, но может быть неоптимальным для сложных SPA-подобных интерфейсов с интенсивным взаимодействием (например, drag-and-drop).
• Представлены альтернативные подходы и фреймворки: MESH (один эндпоинт на компонент), Data-Star (обновление по SSE), Blazor, Leptos, а также использование чистого JS или Web Components.
• Поднимаются технические нюансы HTMX: поведение по умолчанию при замене контента (innerHTML), обработка ошибок, ограничения парсера DOM при работе с Shadow DOM.
• Критикуется тенденция добавления абстракций поверх HTMX, что, по мнению части участников, противорит его философии простоты и возврата к истокам.
• Отмечается ценность HTMX и подобных инструментов как реакция на сложность современных JS-фреймворков и возможность быстрой разработки без сборки.

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

• Добавлена поддержка Valgrind в Go для тестирования криптографического кода на постоянное время выполнения и отслеживания инициализации памяти.
• Обсуждаются преимущества Valgrind для обнаружения утечек памяти и тонких ошибок, несмотря на наличие других инструментов, таких как ASan/MSan.
• Подчёркивается важность аннотаций для корректного анализа неинициализированной памяти, особенно при использовании unsafe-кода или CGO.
• Высказываются опасения, что эффективность зависит от повсеместного использования инструмента всеми пакетами, чтобы избежать большого количества ложных предупреждений.
• Некоторые пользователи выражают скептицизм, считая необходимость в Valgrind признаком недостатков языка, в то время другие видят в этом мощное дополнение к инструментарию.

YAML позиционируется как удобный для человека формат данных, но на деле оказывается чрезвычайно сложным и полным скрытых ловушек. Его спецификация занимает 10 глав с многоуровневой структурой, в отличие от лаконичного JSON, чья спецификация умещается в шести диаграммах и почти не менялась два десятилетия. YAML активно развивается: версия 1.2 существенно отличается от 1.1, что приводит к разному parsing одних и тех же документов в разных реализациях.

Пример документа с настройками сервера демонстрирует проблемы YAML: числа вида 22:22 могут интерпретироваться как sexagesimal (1342) в версии 1.1, но как строка в 1.2. Якоря (&) и алиасы (*) усложняют чтение, а теги (!) создают угрозу выполнения произвольного кода при загрузке ненадёжных данных. Известная «проблема Норвегии» (неожиданная интерпретация сокращений стран) подчёркивает, что попытки быть «дружелюбным» формат делают его непредсказуемым и опасным.

• Критика YAML за его сложность, неоднозначность и множество подводных камней, таких как проблемы с автоматическим определением типов (например, "no" интерпретируется как false).
• Предложения использовать альтернативы: JSONC, TOML, HCL, Dhall, Jsonnet, CUE или всегда заключать строки в кавычки в YAML для избежания ошибок.
• Обсуждение отдельных проблемных особенностей YAML, таких как якоря/алиасы, сексегесимальные числа и необходимость в линтерах.
• Отмечается, что, несмотря на недостатки, YAML остается популярным из-за удобочитаемости и широкой распространенности.
• Упоминание, что спецификация YAML 1.2 (2009 г.) исправила некоторые проблемы, но многие issues остаются актуальными.

Иранский разработчик делится опытом блокировок из-за санкций против страны. Microsoft удалила его приложение EyesGuard из магазина без объяснений, стерев аккаунт и отзывы пользователей. Notion полностью очистил его данные, ответив в поддержке, что услуги недоступны для резидентов Ирана из-за ограничений.

Эти случаи показывают, как санкции ударяют по обычным пользователям, лишая их доступа к инструментам и стирая цифровую историю. Разработчик иронично сравнивает это с SQL-запросом на удаление пользователей по географическому признаку.

• Участники обсуждают негативное влияние санкций на обычных граждан Ирана, блокировку сервисов и цифровую изоляцию, отмечая, что санкции вредят населению, а не правящим elites.
• Поднимается тема двойных стандартов: пользователи критикуют тенденцию обвинять народы "стран-изгоев" в действиях их правительств, в то время как действия западных правительств часто отделяются от ответственности их граждан.
• Высказываются опасения по поводу централизации цифровой инфраструктуры в руках США, что дает им возможность в одностороннем порядке определять, кто может пользоваться услугами, и риски такой модели для пользователей из недружественных стран.
• Обсуждается эффективность санкций: многие участники сомневаются, что санкции достигают заявленных целей по изменению политики правительств, а вместо этого лишь укрепляют режимы и усугубляют положение населения.
• Отмечается сложность ситуации для владельцев бизнесов, которые вынуждены блокировать пользователей из-под санкций из-за юридических рисков и штрафов, даже если они не согласны с такой политикой.

zoxide — это умная замена команды cd, которая запоминает часто посещаемые каталоги и позволяет быстро переходить по ним с помощью частичного совпадения имён. Она поддерживает все основные оболочки, включая bash, zsh и fish, и использует алгоритм ранжирования для предложения наиболее релевантных путей.

Инструмент работает быстрее аналогов вроде autojump, так как написан на Rust, и интегрируется с fzf для интерактивного выбора. Практический бонус — экономия времени при навигации в сложных проектных структурах.

• Критика zoxide за нечёткость работы и потенциальные ошибки при навигации, а также предпочтение встроенного поиска по истории ZSH или комбинации с fzf.
• Положительные отзывы о значительном ускорении навигации и интеграции zoxide в рабочий процесс, особенно в сочетании с другими инструментами (fzf, bat, starship).
• Обсуждение альтернатив и схожих инструментов (autojump, z, navita, CDPATH в bash/zsh), их сравнение с zoxide.
• Варианты настройки и использования zoxide, включая алиасы для cd, флаг basedir и интерактивный режим zi.
• Замечания о том, что для многих пользователей нативные возможности оболочки или другие инструменты покрывают большинство потребностей.

Прожив девяносто лет, автор осознаёт, что многие ошибки можно было избежать, усвоив несколько ключевых принципов раньше. Главный из них — необходимость самоопределения: быть цельной личностью с чёткими моральными ориентирами, основанными на добродетелях, а не на импульсах. Без этого человек рискует стать «кучей побуждений», а не хозяином своей жизни. Моральная основа — не абстракция, а практический компас: страдание — плохо, радость — хорошо, честность и доброта предпочтительнее зависти и жестокости.

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

• Обсуждается значительная роль удачи и внешних обстоятельств (родители, генетика, география) в успехе или неудаче, что призывает к смирению.
• Критикуется идея счастья как постоянного состояния; подчёркивается важность баланса боли и удовольствия для саморефлексии и поиска смысла.
• Отмечается, что статья содержит много цитат других авторов, что может затруднять восприятие собственных мыслей автора.
• Поднимается вопрос о практическом применении советов о serenity и composure в повседневной жизни, запрашиваются более конкретные руководства.
• Упоминается важность самопознания и честности с собой для избежания самообмана и принятия верных решений.

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

Один из участников заработал более $10,000, что демонстрирует практическую пользу инициативы. Такие результаты побуждают другие штаты рассматривать аналогичные модели, видя в них эффективный инструмент ресоциализации и сокращения затрат на содержание заключённых.

• Обсуждается возможность реабилитации заключенных через удаленную работу и обучение новым навыкам (например, программированию), что может снизить рецидивизм.
• Критикуется система частных тюрем в США и perverse incentives (например, коррупция в виде "kids for cash"), ведущие к высокому уровню incarceration.
• Поднимается вопрос о принудительном труде заключенных и его сравнении с современными формами рабства из-за исключения в 13-й поправке.
• Высказываются опасения, что использование заключенных на удаленной работе может снижать рыночные ставки зарплат и отнимать jobs у других.
• Отмечается, что дегуманизация заключенных и отсутствие focus на реабилитацию — общая проблема многих стран, включая США и Бразилию.

Массовое внедрение генеративного ИИ привело к парадоксу: компании активно внедряют ИИ-процессы, но 95% организаций не видят измеримой отдачи от инвестиций. Количество полностью автоматизированных процессов удвоилось за год, использование ИИ на работе также выросло вдвое с 2023 года, однако реальная продуктивность не увеличивается.

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

• Руководство предписывает обязательное использование ИИ в работе и требует отчётов о повышении продуктивности, не учитывая возможное негативное влияние.
• Участники критикуют слепую веру руководства в возможности ИИ, сравнивая это с маркетинговой шумихой и отмечая отсутствие у менеджеров технических знаний.
• Генерируемый ИИ контент (тексты, код) часто описывается как низкокачественный, многословный и неточный, что увеличивает нагрузку на сотрудников, вынужденных его проверять и исправлять.
• Обсуждается парадокс: внедрение ИИ, призванное повысить эффективность, может привести к её снижению из-за роста бюрократии и производства бесполезного контента.
• Некоторые предлагают саботировать требование отчётов, используя для их генерации тот же ИИ или просто выдумывая результаты.