Что является источником менталитета «компилируй сам» в Linux [закрыто]
Акт использования nohup просто изменяет PPID порожденного процесса на 1 (init), так что когда оболочка выходит, она больше не является дочерним процессом этой оболочки и, следовательно, не получает HUP.
EDIT: Иногда я должен больше думать, прежде чем писать. Оставляю это здесь, чтобы напомнить о своем позоре :-(
Очень просто, на протяжении большей части истории *nix не было другого выбора. Программы распространялись в виде tar-архивов с исходным кодом, и единственным способом их использования была компиляция из исходного кода. Так что это не столько менталитет, сколько необходимое зло.
Тем не менее, есть очень веские причины компилировать материал самостоятельно, поскольку затем он будет скомпилирован специально для вашего оборудования, вы можете выбрать, какие параметры включить или нет, и поэтому вы можете получить точно настроенный исполняемый файл Вам нравится это. Однако это, очевидно, имеет смысл только для опытных пользователей, а не для людей, которые просто хотят, чтобы работающая машина читала их электронные письма.
Теперь, в мире Linux, все основные дистрибутивы отошли от этого много лет назад. В наши дни вам очень, очень редко нужно что-либо компилировать самостоятельно, если только вы не используете дистрибутив, специально разработанный для людей, которые любят это делать, таких как Gentoo. Однако для подавляющего большинства дистрибутивов среднестатистическому пользователю никогда не потребуется ничего компилировать, поскольку почти все, что им когда-либо понадобится, присутствует и скомпилировано в репозиториях их дистрибутива.
Таким образом, этот менталитет CIY, как вы его называете, по существу исчез. Возможно, он все еще жив и здоров в мире UNIX, у меня нет в этом опыта, но в Linux, если вы используете популярный дистрибутив с приличным репозиторием, вам почти никогда не придется ничего компилировать самостоятельно.
Как говорит @terdon, в настоящее время потребность в компиляции довольно незначительна, особенно для домашних пользователей.
В прошлом, в мире Unix, я сильно зависел от компиляции исходных кодов, например, когда я управлял системами Solaris, AIX, Ultrix, Digital Ultrix и HP/UX, которые иногда больше не обслуживались поставщиком, или какие реализации общих служб сильно отставали от того, что обычно использовалось в других Unix, включая Linux.
В настоящее время по-прежнему существует реальная потребность в компиляции вещей, либо для получения еще какой-то малоизвестной или устаревшей части программного обеспечения, которой нет в репозиториях, либо для использования более новой версии пакета, для которого у вас нет совместимых двоичных файлов. , или когда вы хотите добавить дополнительную функциональность или редко, если вы можете написать для нее патч или модуль.
Мне также приходилось компилировать программное обеспечение вручную при реинжиниринге систем для переноса на Debian и/или новые версии Debian, структура которых больше не поддерживалась ОС.
Например, в прошлом мне приходилось вручную компилировать демоны DHCP для поддержки (на тот момент недавних) изменений Windows в протоколе или для поддержки определенных исправлений для обеспечения в мире телекоммуникаций.
Я до сих пор храню в своем локальном репозитории deb-файлы для версий FreeRadius, скомпилированные мной из репозитория dev git, поскольку в Debian есть ряд стабильных версий с (серьезными) ошибками, и обычно соответствующие .deb-файлы для Debian/Ubuntu. не соответствовали нашим потребностям.
И само собой разумеется, что иногда нам также приходится запускать/или компилировать материал, написанный нами.
Установка зависимостей в настоящее время не так сложна, как в прошлом, и некоторые программы даже имеют настраиваемые файлы правил для некоторых распространенных дистрибутивов Linux, которые называют зависимости для компиляции и выполняют тяжелую работу по созданию файла пакета со списком зависимостей. встроенный. Установка такого пакета из локального репозитория мало чем отличается от установки такого же пакета из официальных репозиториев.
Есть несколько причин для такого менталитета, от конечных пользователей, сопровождающих дистрибутивов и поставщиков кода/разработчиков/проектных групп, и каждая из них совершенно верна.
Аспект открытого исходного кода
Есть люди, которым нравится знать, что они используют свободное программное обеспечение, и подтверждают это, выбирая компиляцию из исходного кода. Вот тут-то и появляются такие вещи, как проект/руководство/книга Linux From Scratch.
Аспект оптимизации и опций
Хотите скомпилировать материал с определенной оптимизацией для вашей конкретной архитектуры ЦП? Возможно, есть опция времени компиляции (или патч для ее создания), чтобы включить или отключить определенную функцию, которая вам нужна. Примерами этого может быть исправление постфикса, чтобы иметь возможность управлять квотами, или использование дистрибутива, такого как Gentoo, где вы можете отказаться от использования systemd, или вы специально выбираете поддержку ogg/theora/vorbis/независимо, а НЕ mp3 из-за проблем с лицензированием. или что-то еще.
Аспект архитектуры ЦП
Используются ли на вашем рабочем месте высокопроизводительные машины, отличные от x86/amd64? Пакет, который вам нужен/нужен, может быть недоступен в предварительно скомпилированном виде для архитектуры вашего процессора, а тем более для любого дистрибутива, который вы используете. Конечно, большинство мест, где работает такое оборудование, также получают поддержку от IBM и т. Д. И не занимаются установкой / компиляцией волей-неволей.Но что, если вы возьмете один из распродажи, выкопаете старый iMac с процессором PPC и т. Д.?
Аспект дистрибутива
«Семейства» дистрибутивов — например, Debian с Ubuntu, Mint и др., RedHat с CentOS, Whitebox, Fedora и др. — все используют разные форматы пакетов. И каждая версия поставляется с разными версиями библиотек и т. д. Даже для простого сценария оболочки с одним файлом настройка правильного файла Debian .deb требует времени и усилий. Если вы написали какое-то программное обеспечение, чтобы избавиться от зуда, и хотите сделать его бесплатным и разместить его на gitlab, на своем собственном веб-сервере, что угодно, вы бы предпочли просто опубликовать общий файл исходного кода .tar.gz с инструкциями по сборке, или вы бы предпочли упаковать версии для 2 версий Debian (стабильная и тестируемая, возможно старая стабильная), несколько версий Redhat и Fedora в виде RPM, TGZ для Slackware, профиль ebuild для Gentoo и т. д. и т. д. и т. д.