Когда была последняя новость про busybox? Sysvinit? Procmail? Daemontools? Coreutils?

Правильно. Про них новости не нужны, они просто работают. Ну а про systemd новости есть всегда. Вот недавняя уязвимость, например.

В блоге какого-то хмыря я видел девиз "если двигаясь вперед вы ничего не ломаете, вы двигаетесь слишком медленно".

Как мы допустили, чтобы такие выбрались за пределы "херак-херак и сайт на Wordpress"?!

Как известно, linux console не поддерживает больше 16 цветов. Мейнтейнеры Linux отказываются принимать патчи, которые бы это исправляли.

Как человек, которому нравится работать в tty, без X, мне бы хотелось 256 цветов. Но также я понимаю, что мейнтейнеры правы. Не надо тащить опциональные функции в принципиальные компоненты системы.

Это к тому, что я способен понять что такое хорошо, а что такое "мне было бы удобно прикрутить костыль по-диагонали нормальной архитектуры".

В викпедии есть принцип конфликта интересов. Это значит, что человек не должен писать про себя, свою рок-группу или своего работадателя.

В Debian такого нет. У нас есть Debian Developer, работающий в Red Hat. Последствия известны.

Несколько недель назад некий программист пытался спасти мою душу.

Основной тезис его проповеди заключался в том, он, программист, пишет душеспасительное письмо через web-интерфейс mail[.]ru, ибо ему лень настроить нормальный почтовик, который не склеивает абзацы в одну длинную строчку, и из этого следует, что принципы Unix-way несостоятелены, а программы, написанные в соответствии с ними, не нужны.

Впрочем, после обмена парой реплик, программист признал, что моей душе уже нет спасения.

Да, это так. Да, я отказываюсь обожествлять лень, некомпетентность и посредствнность. Да, я считаю, что интересы некомпетентных -- ничто перед интересами компетентных.

Гореть мне в хипстерском аду!

Существует мнение, что Apple убивает web-технологии в лице Electron.

Противоречивые чувства. С одной стороны, Apple снова душит чью-то свободу, а с другой -- а вдруг Electron, это отродье "современного веба", и правда сдохнет?

Недавно я задумался над ещё одним противоречивым моментом:

С одной стороны, портирование программ на проблемные платформы, как то Windows, чудовищно усложняет код и идейно неверно. С другой -- переносимость на платфомы отличные от GNU/Linux служит оберегом от systemd.

Кстати, переносимость на MacOS тоже служит оберегом, но не так усложняет код как в случае с Windows. Я должен поблагодарить Apple за то, что она где-то далеко от меня, но существует?!

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

Сил уже никаких нет.

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

Мы против того, чтобы люди подвергались репрессиям за свои убеждения, и мы хотим помочь политзаключённым. Если вы с нами согласны, то наверняка уже думали о том, как можете помочь оказавшимся в беде.

В России осталось не так много легальных способов участвовать в жизни общества, поэтому мы призываем вас принять участие в первом онлайн-хакатоне в поддержку политических заключённых!

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

Должен признать, проект freedesktop.org таки сделал что-то хорошее. XDG_CONFIG_DIR это хорошо.

Упаковать программу вместе с конфигурацией, если она использует эту переменную окружения, гораздо проще.

Даже если не xdg, пожалуйста, не прибивайте гвоздями конфигурационные файлы к $HOME.

Debian в одном шаге от бездны. Кто может спасать -- голосуйте и надейтесь, кто не может -- просто надейтесь. Момент X назначен на 27 декабря.

http://www.chiark.greenend.org.uk/pipermail/debian-init-diversity/2019-December/002876.html

В СИЗО я много наслушался историй о том, что происходит когда бизнес попадает на радары больших шишек, но на этот раз бьют совсем-совсем наших. Я не хочу обратно на Apache!

https://m.habr.com/ru/company/itsumma/blog/479942/

Помню одного погромиста, от которого требовалась изменить две строчки в репозитории, с которым он обычно не работал. Потом смотрю -- коммит на триста строк. Вася, какого хрена? "А мне IDEA IDE переформатировала, а потом в этой IDE я нажал кнопку commit." И глазами хлопает. Я после этого gitolite внедрил.

Другая история. Таксист привозит в точку A, которая не совпадает с точкой назначения B. Вася, какого хрена? "А мне GPS так показывает." И глазами хлопает.

Господа, IDE, GPS и прочие восхитительные вещи -- это лишь инструменты, которые не снимают с вас обязанности понимать, что именно вы делаете этими инструментами.

Uber дал нам толпы таксистов, не знающих города, GitHub/GitLab -- толпы программистов, не умеющих пользоваться git, gmail -- толпы людей, не умеющих пользоваться электронной почтой (rfc1855). Понижение баррьера входа, да.

Такое положение дел приносит кучу денег бизнесу, который смог пустить идиотов массы туда, где их раньше не было.

Такое положение дел создает рабочие места, что одобряется как государством, так и многими общественными организациями.

Увы, я не вижу достаточно могущественной силы, которая могла бы этому что-то противопоставить.

Сегодня утром новая версия мессенджера Signal (обсуждение практики автообновления оставим на другой раз) порадовала девизом "Зачем использовать слова, если можно использовать стикеры."

Затем чтобы выражать идеи, сложнее чем у кроманьонца. Затем, что мысли и речь неразрывно связаны.

Дружественный канал @parisburns задаётся вопросом про мессенжер сигнал:

Зачем использовать номер телефона если можно использовать имэйл?

Я бы пошёл дальше и спросил бы, почему бы просто не генерировать GUID при первом подключении.

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

Но ведь когда-то эти самые люди учились пользоваться мышкой и Microsoft Office. Через слёзы и "не хочу", но они справилась. Да, мир был другим.

Последнее время я активно использую Nix для того, чтобы раскатывать WSGI-приложения. Прелесть в том, что в одну производную (derivation) можно запихать собственно код, библиотеки по зависимостям, скрипты инициализации (supervision scripts), сервер приложений, веб-сервер, статичесеские файлы и вообще почти всё что угодно, и всё это без излишней дупликации. По сравнению с cdist/Ansible/..., а уж тем более ручным оркестрированием — райские кущи.

Единственное но — всю эту радость кто-то должен запускать. Для этого я из-под рута в init-скрипте запускаю runit, примерно так: chpst -u deploy runsvdir ~deploy/.nix-profile/sv. Единственная внешняя зависимость. Всё круто, но ~deploy/.nix-profile/sv/<foo>/supervise должен быть символической ссылкой на директорию, которую юзер deploy либо может создать, либо уже существует и в ней можно писать. Параметризовать derivation путём до домашней директории пользователя можно, но довольно уродливо. Как и вываливать в /dev/shm, который a+rwx.

После некоторых размышлений, рассматривая даже такую тяжёлую артиллерию как unshare(2), я нашёл довольно симпатичное решение. На чтение можно открыть не только обычный (regular) файл, но и директорию. Т.е можно сделать exec 64</tmp и теперь /proc/$$/fd/64 является символической ссылкой на /tmp. Работает только при kernel=linux.

Собственно, это и ответ: надо runsvdir запускать так, чтобы он унаследовал домашнюю директорию, открытую на дескрипторе 64, а производную собирать так, чтобы все файлы и директории лежали в /proc/self/fd/64. Если кто знает POSIX решение, я весь внимание.

PS. Если быть совсем точным, supervise может быть директорией, но Nix хранилище (store) только для чтения, так это не вариант сразу.

Question interfaces! Нет ничего важнее. Если не сомневаться в основах и не задумываться над тем, что именно мы хотим сделать, то будет вечное "хотели как лучше, получилось как всегда". Расскажу историю.

Традиционно, аутентификация пользователя в Unix системах производилась в соответствии с файлом /etc/passwd, где хранились логины и хеши от паролей пользователей, а стандартная библиотека предоставляла функцию проверки, что-то в духе:

bool check_credentials(const char *username, const char *password)

На самом деле интерфейс более неуклюжий, но это не важно. Важно то, что со временем появилась необходимость хранить данные о пользователях способами, отличным от формата /etc/passwd — в базе данных или на удалённом сервере. И что-бы удовлетворить эту потребность, стали появляться библиотеки, которые предоставляли примерно такой-же интерфейс, но проверяли логин и пароль, используя данные из альтернативных источником. Вершиной такой эволюции стала библиотека PAM (Pluggable Authentication Modules), которая предоставляет универсальный интерфейс к огромному количеству способов проверки логина и пароля, большинством из которых вы никогда не воспользуетесь.

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

Можно ли было сделать лучше? Нет, если держаться за интерфейс стандартной библиотеки. Но нужно ли?

Если сделать шаг назад и пересмотреть что именно мы хотим сделать, то мы увидим, что программа состоит из трёх частей: часть, которая выполняется до проверки логина/пароля, собственно проверка и часть, которая выполняется после. Если разделить программу на три меньшие программы, то только вторая будет содержать код, связанный с проверкой логина/пароля. Да, это давно известная вещь.

При таком подходе программа для проверки пароля ровно настолько сложная, насколько это необходимо, а не насколько сложной она может быть теоретически. Более того, даже если в программе проверки пароле есть баг, он не сможен испортить память, которую будет использовать третья часть.

Конечно, всё не так прямолинейно. Как за простыми формулами школьной физике, так и за простыми решениями в IT стоит титан мысли, гениальность которого нам сложно оценить, когда ответ уже перед нами.

Question interfaces, и возможно жизнь станет немного проще.

Что за фигня?! 307 проголосовавших из 1116? Судьбоносный референдум с явкой около одной трети?!

Если у вас есть возможность физически дотянуться до Debian Developer'а, который не проголосовал, напомните ему о его гражданском долге.

https://vote.debian.org/~secretary/gr_initsystems/

https://db.debian.org/search.cgi

Пару дней назад я прочитал статью, озаглавленную Unix Considered Harmful, а в ней была ссылка на Unix Haters Handbook. Прочитал и задумался, а вдруг я и правда я чего-то не вижу? В конце концов, все красивые и простые решения, которые я тут нахваливаю, базируются на на примитивах Unix. Question Intefaces! и достал из кладовки маленький нетбук, обладающий свойством, что вся периферия на нём отлично работает с kernel=linux-libre.

Окей, что у нас есть? Пробуем HaikuOS. Написана на С++. Хм. Установочный образ почти гигабайт. Неудивительно. Окей, графическая оболочка, напоминающая Windows98. Терминал. В терминале нет vim. Хм. Окей, браузер. Проводной интерфейс с dhcp нашёлся сам, хорошо. В браузере похоже Javascript есть. И видео проигрывает. Нешустро, но я не знаю, кто виноват — браузер, немолодой нетбук или современный web. В общем, любви с первого взгляда не случилось. Если кто знает о какой-то вау-идее в Haiku — я весь внимание.

Что ещё? KolibriOS. Операционная система, полностью написанная на x86 ассемблере. Установочный образ 1.5 мегабайта. Добро. Ещё одна графическая оболочка a-la Windows98. Ок. Пятнашки есть. И текстовый редактор примитивный тоже. И браузер. Упс, а вот проводное соединение с dhcp на нашлось. Любовь опять не сложилась.

Надо признать, я был очень поверхностен, и вероятно первое знакомство с tty1 в GNU/Linux системе вызовет примерно такую же реакцию.

Сейчас очень бурное движение наблюдается в области использования графических web-браузеров как замену операционной системе. Я задамся вопросом, почему люди это делают.

Да, окружение в котором выполняется Javascript абстрагирует от работы с сетью в разных операционных системах и от построения графических интерфейсов, и это удобно. Но тоже самое предоставляют многие кроссплатформенные библиотки, например Qt, которую, кстати, можно использовать не только из С++, но и из Python. Так в чём же секрет?

Мне кажется, секрет в том, что у приложения, выполняющегося в браузере, нет версий и нет обратной совместимости. Никто не любит поддерживать обратную совместимость, все любят новые игрушни. Серебряная пуля найдена?!

Нет, конечно. Программу, которую я скачиваю откуда-то на свой компьютер я могу изучить, запустить несколько раз в разных условиях и сделать определённые выводы на её счёт. Теоретически, тоже самое можно сделать и с JS кодом, но когда я зайду на сайт в следующий раз, браузер скачает и выполнит уже другой код. Без предупреждения. В браузере нет возможности сделать chattr +i, поэтому идея LibreJS не выглядит убедительной.

Ещё один компромисс безопасности в пользу удобства. Как знать, возможно в мире, где информационная безопасность держится не на технологиях, а на уголовном кодексе, это разумно.

Всё плохо. Последний крупный бастион здравого смысла пал. Прощай, Debian.

https://kaction.cc/posts/2019-12-28_tragedy_in_debian.html

О сколько открытий чудных нам дарит https://mitmproxy.org. Это было проще, чем я ожидал. Попробуйте!

Увы, есть несколько сайтов, которые мне нужны и которые работают только в Firefox/Chromium.

И я обнаружил, что кроме бяки гуглоаналитики (и других), браузер по своей инициативе лезет куда не надо. Например, что такое http://detectportal.firefox.com/success.txt ?

Я ведь уже рекламировал этот список? Он хорош, но всё равно неполон. Мы проигрываем эту гонку вооружений, но я не вижу ничего лучше, поэтому начал свой список.

Грядут большие дебаты по поводу феминизма, и наверное это будет интересно. А у меня нет цифр и статистики, я просто расскажу историю.

Я работал в физической лаборатории при МПГУ, где вместе с коллегами обоих полов, изготавливал крошечные девайсы размером 3×4 милиметра. Расходником в технологии создание этих устройств были баллоны со сжатым азотом. 50 литров, 62 килограмма, 150 атмосфер.

Примерно раз в полторы-две недели приезжал грузовик поставщика с десятью новыми заполненными баллонами. Мы разгружали новые баллоны и отвозили на склад, а пустые баллоны привозили со склада и загружали в транспорт. Женское население в этом не учавствовало.

Также, раз в полтора-два дня нужно было привозить со склада новый баллон к машине, которая его использовала и отвозить пустой. Женщины этим также не занимались.

Другая история. Маленькая IT контора в офисе на втором этаже. Четрыре мальчика-программиста и девочка дизайнер. Бутыли для кулера (19 литров) доставляли только до первого этажа, дальше этим занимались...