Эвристика для использования или отклонения старой документации [закрыто]

Две опубликованные вами цитаты звучат как чье-то мнение, а не как «документация».

Стандарты - это движущиеся цели. Можно стремиться внедрить их, но каждые несколько лет они обновляются, и всегда будут расширения и случаи, когда стандарт намеренно не соблюдается. Это касается «надлежащих стандартов», а также «специальных стандартов».

Стандарты, такие как POSIX, однако, со временем меняются лишь медленно , при этом новые вещи вводятся по мере того, как они оказываются полезными, востребованными и широко распространенными, а старые вещи отбрасываются, когда они оказываются выпадающими из строя. использовать и т. д. Вот почему некоторые здесь, на U&L, стремятся указать, что некоторые оболочки (например) не совместимы с POSIX, а работают (или нет, в зависимости от обстоятельств) с определенными версиями определенных реализаций инструменты. Это способ заставить ответ жить дольше, чем конкретная реализация, предлагаемая GNU или другим поставщиком.

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

Вы можете поискать в Интернете, что делает определенный флаг для утилит sed или grep , или как использовать Getopt :: Long в Perl, но это будет руководство, установленное с фактической утилитой или библиотекой в вашей системе , то есть окончательная документация.

Историческая документация полезна для людей, использующих те же самые старые системы, ничто не отрицает этого, но часть документации обычно предназначена для системы или инструмента, как это было на момент написания. Если вы используете новую систему OpenBSD 5.9, например, и задаетесь вопросом, почему sudo не работает, потому что вы читаете веб-страницу, в которой говорится, что она должна быть в базовой системе, ну, это Было бы лучше, если бы вы прочитали руководство afterboot (8) (по запросу), в котором описывается система, которую вы только что установили . Это расскажет вам об утилите doas .

Я хочу сказать, что не имеет значения, где движется Unix или откуда он. Вы находитесь перед машиной, на которой он запущен , прямо сейчас , и именно там вы найдете самую свежую документацию.

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

Прошу прощения, если я немного пропустил отметку в своем ответе, но это то, о чем я немного думал в последнее время.

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

Вы упомянули сайты вопросов и ответов. Форумы IME Q&A часто не справляются с этим. Вы получаете несколько мнений, но не полностью аргументированные объяснения. Сторонняя «документация», обнаруженная при поиске в Интернете, например сообщения в блогах, часто имеет такое же качество. Конечно, в то время ответы полезны; они позволяют вам увидеть опыт и чтения других людей. Но аргументированное объяснение со ссылкой на первоисточники может быть полезным, даже если оно полностью устарело.

Раз уж вы спросите. Я бы сказал, что POSIX об этом. Множество поставщиков стандартизировали 1) системные вызовы и 2) служебные команды, и они останутся функциональными в будущем, чтобы сохранить совместимость с существующими приложениями.

Опять же, помните, что авторитет - это сам стандарт. Мой курс CS в одном из престижных университетов объединил стандарт потоков POSIX с первоначальной непоследовательной попыткой его реализации в Linux. Игнорирование контрпримера второй реализации (NPTL). И материалы этих курсов часто доступны в Интернете ...

Проблема в том, что после того, как они согласованы и закреплены в стандарте, они не обязательно останутся актуальными и интересными. Я думаю, что провал Linux Standard Base был бы примером этого. (Обратите внимание, что недавно сопоставимые разработки, такие как приложения xdg flatpack, построены на версионных средах выполнения. И посмотрите, как быстро меняется GTK).

Я думаю, что анализ безопасности дает убедительные примеры. Мы просто еще не придумали, как построить безопасную систему.Старые / не исправленные системы / системы, в которых не применялись меры по устранению ошибки du jour , считаются полностью неисправными. Поэтому они постоянно меняются.

Предупреждение любви к POSIX: операционные системы, используемые в реальном мире , будут каким-то образом отклоняться от стандарта. Сертификация OS X, POSIX - реализация fsync () была запрещена в соответствии с тем, что все остальные считают предполагаемым значением. Некоторые седобородые Linux утверждают, что мы должны ломать приложения, которые используют раздражающие имена файлов, например. которые включают управляющие символы. И т.д.