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

https://tass.ru/obschestvo/7083637

Есть такая технология, называется OAuth2. Она используется, когда вы нажимаете на кнопочку "зайти через Google/Github/Facebook — аккаунт" в браузере. Идея в том, чтобы дать третьей стороне немного поковыряться в данных вашего аккаунта, но при этом сохранить полный контроль и при необходимости отозвать это разрешение. Очевидно, что нельзя кому-попало давать свои логин и пароль.

Идея хорошая, но есть нюанс. Вот хочу я допустим задать вопрос на StackExchange из консоли. Программу я напишу сам, вопрос доверия не возникает. Однако интерфейс, позволяющие работать с сайтом не через браузере, а програмно (StackExchange API), завязан на этот самый OAuth, и никак иначе.

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

Ну окей, я то справлюсь. Проведу необходимые магические ритуалы, создам бессмертный токен, сохраню его в менеджере паролей и через пару недель забуду, откуда он у меня вообще есть. Но есть я хочу поделиться полезной программой с кем-то ещё, то как я смогу объяснить, что нет, логина и пароля для счастья недостаточно, нужно больше странных ритуалов?

Стоп, я знаю универсальное объяснение. This world is ugly.

Иногда в списках обсуждений Debian всплывает наркоманская мысль: а давайте сделаем альтернативную реализацию .service файлов.

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

Плохой, он же sysvinit style, это скрипт и double-fork. Радости в духе pid-файлов и start-stop-daemon прилагаются.

Хороший, он же daemontools style, это логи в stdout и отсутствие привязки к reparenting.

Вечно актуальный комикс: https://xkcd.com/927/

Да, кстати. Хороший способ делается совместимым с плохим посредством daemon(1), обратно, очевидно никак.

Когда была последняя новость про 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 системе вызовет примерно такую же реакцию.