Некоторое время назад заметил, что при вводе пароля sudo в Ubuntu начали отображаться звездочки. Раньше никакой индикации не было. Это изменение связано с sudo-rs, который заменил обычный sudo в Ubuntu 25.10. В версии, которая идет с Ubuntu 26.04, просто изменили значение по умолчанию для флага pwfeedback.

Но почему изначально ничего не отображалось? На это есть две причины. Во-первых, кто-то может узнать длину пароля. Можно подумать “ужасная уязвимость!11”, но дырка там все-таки нашлась, только не про длину. Во-вторых, исторически терминалы (точнее, телетайпы) печатали весь вывод на бумаге, и там это не имело смысла. А менять такую важную настройку по умолчанию страшно:)

Хорошая визуализация картинки XKCD, которую часто вспоминаешь при громких уязвимостях или узких точках отказа (как с недавней четверкой, например): конкретные личности, цифры, статистика и т.п. (без претензии на полноту, разумеется).

Полезная фича, которая поможет проходить корпоративное обучение и подобную шляпу.

В хроме это можно сделать с помощью DevTools, а для Firefox можно только баг-репорт почитать. Но есть и расширения, например, Always Active Window.

Пара моих ранних вкладов в опенсорс была мелкими фиксами, связанными с кодом завершения программы при ошибке (1, 2): чтобы это был не 0, а 1.

Еще тогда (9 лет назад) мне казалось, что это решенная проблема, и вообще best practice — второй пункт в базовых вещах. Все-таки, это один из простых способов интеграции с другими программами или с баш-скриптами. Сегодня агенты это активно используют, следуя философии Unix. Так вот, к сожалению, недавно пришлось зарепортить баг про код возврата для одной из внутренних утилит.

Есть и альтернативные способы коммуникации консольной программы с оболочкой — например, через управляющие последовательности, которые, по сути, просто спецсимволы для стандартного вывода, с помощью которых, кроме управления терминалом, можно передавать команды через терминал для ОС: послать уведомление, показать прогресс (типа такого), использовать буфер обмена, вывести гиперссылку. И тут прогресс не стоит на месте — например, недавно автор Ghostty предложил спецификацию для еще одной управляющей последовательности: статус задачи. Однако стоит отметить, что единого стандарта нет, и поддержка у терминальных приложений фрагментирована.

Часть корпоративной культуры — «ценности», которые выдают мудрые C-level мужи устами HR. Идея-то в целом неплохая: когда есть высокий уровень неопределенности и/или требуется принять стратегическое решение, ценности могут скорректировать направление, и их озвучивание поможет в спорах «как правильно» или «кто не прав». На практике они красиво где-то там записаны на портале, и в лучшем случае работяги о них вспоминают, только когда на перформанс-ревью спрашивают про их вклад в аспекте этих ценностей, и еще иногда можно услышать их упоминание в презентации особо воодушевленного и верующего менеджера. Вообще, сходство с религией довольно интересное: есть какие-то заветы, «как надо», можно ими махать у лица, некоторые фанатеют, но реальность полна разочарований. А служители вокруг них пытаются оправдать свою значимость. Простой народ может либо отказаться от этой шелухи, либо следовать формально — чтобы отстали или чтобы помочь коллеге, играя по правилам. Попытка привить ценности будет тщетна, если они не соблюдаются. При здоровой организационной и инженерной культуре прописывать ценности имеет смысл разве что для онбординга: остальные и так следуют им, а культура насаждается личным примером коллег и впитывается из окружения.

Хороший проект, где на одной карте показываются не только исторические границы государств, но и примечательные (выборочные) исторические события и личности.

Я абсолютно точно знаю, что несколько человек используют нейронку, чтобы сгенерить ни к чему не обязывающий отзыв на коллегу, особенно когда заполнить надо, а сказать нечего.

А что если попробовать сгенерировать ревью на себя? Это же по идее тупо обработка текста, нейронки должны же делать это хорошо? Просто скормим все исходные данные из кучи источников: гитхаб, доски/проекты, слак, гугл-доки, а также корпоративные гайды и попросим выдать хорошее ревью.

Написала ли нейронка хорошее ревью? Нет. Сделала ли она фокус на важном? Опять нет. Может быть, ее вариант хотя бы был вдохновляющим, или там были вдохновляющие идеи? Тоже нет. Ладно, ну хотя бы она смогла все данные собрать, откуда я указал? Да, вы угадали, еще одно “нет”. Окей, ну хотя бы она сжато смогла пересказать результаты и разбить их на категории, это же основная работа ЛЛМ-ки? Да, опять “нет”:)

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

С группировкой нейронка справилась плохо — читала только заголовки, хотя у нее были и подробные описания, и в итоге несколько раз в кучу смешались кони, люди и залпы тысячи орудий (совершенно не связанные друг с другом).

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

Разумеется, со структурой была шляпа, а ЛЛМ-измы были load-bearing.

В целом конечно польза была, особенно относительно сбора данных и поиска “улик” (хотя заметки все еще писать проще). Еще неплохо работает как резиновая утка и как редактор. Ну и еще как ревьюер, чтобы галочки закрыть. В общем, если не очень важно что там написано, то можно оставить и первый вариант…

Я думал, что основное отличие RISC от CISC — это меньшее количество команд и их простота, и даже писал когда-то про это. Однако смешнявка заставила разобраться в вопросе, и мне объяснили, что ARM активно эволюционирует, и под RISC стоит понимать “короткие инструкции, кодируемые одинаковым количеством байт” (хотя и это не точно, потому что есть расширение для RISC-V с переменной длиной команд). Иными словами, RISC — это скорее про простоту декодера команд внутри процессора.

Просто хорошая техническая статья про оптимизацию структур данных для хранения DNS-кэша: сначала померили, потом определили паттерн и характер данных, выкинули ненужное, подобрали правильные структуры и поигрались с указателями. В итоге — 50% меньше памяти и скорость на 43% выше.

И да, разумеется, эти оптимизации окупаются только на больших масштабах — в типичном приложении (пока) еще читаемость и простота будут важнее.

Одна из немногих книг по программированию, которая произвела на меня в свое время впечатление — The Art of Unix Programming. Примерно в 2007 году, когда я ее читал в бумажном варианте, это еще был свежак (книга 2003 года), но автор стоит на плечах гигантов и, в целом, там написаны довольно базовые принципы.

Не уверен, что она на 100% актуальна сегодня, потому что часть глав — история, а часть могла морально устареть. Однако если почитать принципы Unix из первой главы, то вроде все по делу. Вспоминается давний спор с одним из коллег, где я указывал на превосходство текстового формата над бинарным по умолчанию, в том числе опираясь на тезисы из книжки. А на прошлой неделе вместо паручасового пыхтения с ручным вводом данных в экзотическом редакторе, я сделал за минуту пример, сохранил в текстовый файл, показал агенту исходник и пример, и все было готово за 5 минут.

И кстати, а какие программы агенты используют? Да это же продвинутые пользователи всех базовых консольных утилит. Современная агентская разработка вряд ли была возможна без этого неказистого вороха программ с текстовыми интерфейсами, которые как раз следуют философии Unix…