Каков источник менталитета «собери сам» в linux [закрыто]

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

Тем не менее, я не могу сказать, что действительно понимаю менталитет [CIY] самостоятельно [CIY], который существует в * nix кругах. Я знаю, что это уходит, но все еще слышу это время от времени. Как разработчик, я знаю, что настройка компиляторов и необходимых зависимостей является проблемой, поэтому я чувствую, что рабочие процессы CIY помогли сделать * nix намного менее доступным.

Какие социальные или технические факторы привели к росту менталитета CIY?

Очень просто, для большей части истории * nix другого выбора не было. Программы распространялись как исходные архивы, и единственный способ использовать их состоял в том, чтобы компилировать их из исходного кода. Так что это не столько менталитет, сколько необходимое зло.

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

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

Так что этот менталитет CIY, как вы его называете, по существу исчез. Вполне возможно, что он все еще жив и работает в мире UNIX, у меня там нет опыта, но в Linux, если вы используете популярный дистрибутив с приличным хранилищем, вам почти никогда не придется ничего компилировать самостоятельно.

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

Открытый исходный код

Есть те, кому нравится знать, что они используют Свободное программное обеспечение, и подтверждают это, выбирая компиляцию из исходного кода. Именно здесь появляются такие вещи, как проект Linux From Scratch / howto / guide / book.

Оптимизация и настройки параметров

Хотите скомпилировать материал с определенной оптимизацией для вашей конкретной архитектуры процессора? Возможно, есть опция времени компиляции (или патч для ее создания), чтобы включить или отключить определенную нужную вам функцию. Примерами этого могут быть исправление postfix, чтобы иметь возможность управлять квотами, или использование дистрибутива, такого как Gentoo, где вы можете отказаться от использования systemd, или вы решили специально поддерживать ogg / theora / vorbis / whats и НЕ mp3 из-за проблем с лицензированием или что угодно.

Архитектура процессора

Использует ли ваше рабочее место машины высшего класса, отличные от x86 / amd64? Пакет, который вам нужен / нужен, может быть недоступен предварительно скомпилированным для вашей архитектуры ЦП, тем более независимо от того, какой дистрибутив вы используете. Конечно, в большинстве мест, где работает аппаратное обеспечение такого типа, также есть поддержка IBM и т. Д., И они не занимаются установкой / компиляцией чего-либо. Но что, если вы возьмете его с распродажи, откопаете старый iMac с процессором PPC и т. Д.?

Распределение

«Семейства» дистрибутивов - то есть Debian с Ubuntu, Mint и др. И RedHat с CentOS, Whitebox, Fedora и др. - все используют разные форматы пакетов. Каждая версия поставляется с разными версиями библиотеки и т. Д. Даже для простого сценария оболочки для одного файла настройка правильного файла .deb Debian требует времени и усилий. Если вы написали какое-то программное обеспечение, чтобы избавиться от зуда, и хотели сделать его бесплатным и опубликовать его на gitlab, вашем собственном веб-сервере, что угодно, вы бы просто опубликовали общий файл исходного кода .tar.gz с инструкциями по сборке, или вы бы предпочли Пакетные версии для двух версий Debian (стабильная и тестируемая, возможно, старая), нескольких версий Redhat и Fedora в качестве RPM, TGZ для Slackware, профиля ebuild для Gentoo и т. д. и т. д. и т. д. и т. д. и т. д.

Как говорит @terdon, в настоящее время необходимость компилировать вещи очень мала, особенно для домашних пользователей.

В прошлом, в мире Unix, я сильно зависел от компиляции источников, например, так как я управлял системами Solaris, AIX, Ultrix, Digital Ultrix и HP / UX, которые иногда больше не поддерживались поставщиком, или какими реализациями из общих служб были далеко позади того, что обычно использовалось другими Unixes, включая Linux.

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

Я также должен был скомпилировать программное обеспечение вручную, когда проводил реинжиниринг систем для переноса на Debian и / или новые версии Debian, которые имели каркас, который больше не поддерживался ОС.

Например, в прошлом мне приходилось вручную скомпилировать DHCP-демоны для поддержки (к тому времени недавних) изменений Windows в протоколе или для поддержки определенных исправлений для обеспечения в мире телекоммуникаций.

Я до сих пор храню в своем локальном хранилище дабы для версий FreeRadius, скомпилированных мной из репозитория dev git, поскольку в Debian была строка стабильных версий, в которых были (серьезные) ошибки, и обычно соответствующих .debs для Debian / Ubuntu не было. адекватно нашим потребностям.

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

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

Какие социальные или технические факторы привели к росту менталитета CIY?

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

Пока дистрибутивы Linux не начали упаковывать большинство вещей, которые захотят использовать обычные люди, единственным вариантом было получить исходный код и скомпилировать его для своей собственной системы. Коммерческие поставщики Unix, как правило, не включают в себя вещи, которые нужны почти всем (например, хорошую оболочку, такую ​​как GNU bashили аналогичную), просто их собственную реализацию shи / или csh, поэтому вам нужно было создавать вещи самостоятельно, если вы (как системный администратор) хотели обеспечить приятную среду Unix для ваших пользователей для интерактивного использования.

Ситуация, когда большинство людей являются единственным администратором и единственным пользователем компьютера, сидящего на рабочем столе, сильно отличается от традиционной модели Unix. Системный администратор поддерживал программное обеспечение в центральной системе и на рабочем столе каждого. (Часто, когда рабочие станции просто монтируются по NFS /optи /usr/local/с центрального сервера, и устанавливаются там).

До таких вещей, как .NET и Java, настоящая двоичная переносимость между различными архитектурами ЦП была невозможна. По этой причине культура Unix развивалась с переносимостью исходного кода по умолчанию, при этом не требовалось больших усилий, чтобы даже попытаться включить переносимость двоичных файлов до недавних усилий Linux, таких как LSB. Например, POSIX ( основной стандарт Unix) только пытается стандартизировать исходную портативность, даже в последних версии.

Связанный культурный фактор: ранняя коммерческая версия AT & T Unix шла с исходным кодом (на лентах). Вам не нужно было собирать систему из исходного кода, это было просто на случай, если вы захотите увидеть, как что-то действительно работает, когда документов недостаточно.

Википедия говорит :

«Политика Unix в отношении обширной онлайновой документации и (в течение многих лет) легкого доступа ко всему исходному коду системы повысила ожидания программистов и способствовала началу движения за свободное программное обеспечение в 1983 году».

Я не уверен, что послужило причиной этого решения, так как предоставление клиентам доступа к исходному коду коммерческого программного обеспечения в наши дни неслыханно. Очевидно, в этом направлении есть некоторые ранние культурные предрассудки, но, возможно, они возникли из корней Unix как портативной ОС, написанной в основном на C (не на ассемблере), которая может быть скомпилирована для другого оборудования. Я думаю, что многие более ранние ОС имели больше кода, написанного в asm для конкретного процессора, поэтому переносимость на уровне исходного кода была одной из сильных сторон раннего Unix. (Возможно, я ошибаюсь; я не эксперт по ранним версиям Unix, но Unix и C связаны между собой.)

Распространение программного обеспечения в исходной форме - безусловно, самый простой способ позволить людям адаптировать его к любой системе, на которой он хочет работать. (Либо конечные пользователи, либо люди, которые упаковывают его для дистрибутива Linux). Если программное обеспечение уже было упаковано для / для распространения, конечные пользователи могут просто использовать это.

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

Получение программного обеспечения для запуска в системе, отличной от той, которую использовал автор, может даже потребовать некоторых небольших изменений, которые легко сделать с источником . Небольшая одноразовая программа, которую кто-то написал, чтобы избавиться от собственного зуда, вероятно, никогда не тестировалась на большинстве непонятных систем. Наличие источника позволяет сделать такие изменения. Первоначальный автор мог что-то упустить или намеренно написал менее переносимый код, потому что это сэкономило много времени. Даже у крупных пакетов, таких как Info-ZIP , не было тестеров на каждой платформе сразу, и требовалось, чтобы люди отправляли свои исправления переносимости при обнаружении проблем.

(Существуют и другие виды проблем с переносимостью исходного уровня , которые только происходят из - за различий в сборки окр, и которые на самом деле не относятся к проблеме здесь. С Java-стиль двоичная портативности, автоинструмент ( autoconf/ auto-make) и тому подобные вещи , как cmakeWouldn в этом нет необходимости. И у нас не было бы таких вещей, как некоторые системы, требующие включения <netinet/in.h>вместо<arpa/inet.h> forntohl(3) . (И, может быть, у нас не было бы ntohl()или чего-то другого в порядке следования байтов!)

Я регулярно работаю на языках .NET, поэтому я не компьютерный неграмотный.

Однократная компиляция, запуск в любом месте - одна из основных целей .NET, а также Java, поэтому справедливо сказать, что для решения этой проблемы были изобретены целые языки , и ваш опыт разработки связан с одной из них. С .NET ваш двоичный файл работает в переносимой среде выполнения (CLR) . Java называет среду выполнения виртуальной машиной Java . Вам нужно только распространить один двоичный файл, который будет работать в любой системе (по крайней мере, в любой системе, где кто-то уже внедрил JVM или CLR). Вы можете все еще есть проблемы с переносимостью , как, /против \разделителей пути, или , как печатать, или GUI макет детали, конечно.

Много программного обеспечения написано на языках, которые полностью скомпилированы в нативный код . Нет никакого .netбайт-кода или java, просто собственный машинный код для процессора, на котором он будет работать, хранящийся в непереносимом формате исполняемых файлов. C и C ++ являются основными примерами этого, особенно в мире Unix. Очевидно, это означает, что двоичный файл должен быть скомпилирован для конкретной архитектуры процессора.

Версии библиотеки - еще одна проблема . Библиотеки могут и часто поддерживают стабильность API уровня источника при изменении ABI двоичного уровня. (См. Раздел « Различие между API и ABI» .) Например, добавление другого элемента в opaque по- structпрежнему меняет его размер и требует перекомпиляции с заголовками для новой версии библиотеки для любого кода, который выделяет пространство для такой структуры, будь то динамическая (malloc) ), статический (глобальный) или автоматический (локальный в стеке).

Операционные системы также важны . Другой вкус Unix для тех же архитектур процессора может иметь различные бинарные форматы файлы, различный ABI для создания системных вызовов, а также различных числовых значений констант , таких как fopen(3)«с O_RDONLY, O_APPEND,O_TRUNC .

Обратите внимание, что даже у динамически связанного двоичного файла все еще есть некоторый специфичный для ОС код запуска, который выполняется раньше main(). На Windows это есть crt0. Unix и Linux имеют одно и то же, где некоторый код запуска C-Runtime статически связан с каждым двоичным файлом. Я предполагаю, что теоретически вы могли бы спроектировать систему, в которой этот код был бы динамически связан, и часть libc или самого динамического компоновщика, но это не то, как все работает на практике на любой ОС, о которой я знаю. Это решило бы только проблему системного вызова ABI, а не проблему числовых значений констант для функций стандартной библиотеки. (Обычно системные вызовы выполняются через функции-оболочки libc: обычный бинарный Linux-файл x86-64 для исходного кода, mmap()который не содержит syscallинструкции, простоcall инструкция к функции-оболочке libc с тем же именем.

Это одна из причин, по которой вы не можете просто запускать двоичные файлы i386-FreeBSD в i386-Linux. (Некоторое время ядро ​​Linux имело уровень совместимости системных вызовов. Я думаю, что по крайней мере одна из BSD может запускать двоичные файлы Linux с аналогичным уровнем совместимости, но вам, конечно, нужны библиотеки Linux.)

Если вы хотите распространять двоичные файлы, вам нужно будет создать отдельный для каждой комбинации CPU / OS-flavor + version / instal-library-version .

Еще в 80–90-х годах было много разных типов ЦП, широко используемых для систем Unix (MIPS, SPARC, POWER, PA-RISC, m68k и т. Д.), А также множество различных разновидностей Unix (IRIX, SunOS, Solaris, AIX, HP-UX, BSD и т. Д.).
И это только системы Unix . Многие исходные пакеты также будут компилироваться и работать на других системах, таких как VAX / VMS, MacOS (m68k и PPC), Amiga, PC / MS-DOS, Atari ST и т. Д.

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

Таким образом, комбинаций CPU / OS уже больше, чем вы можете потрясти, даже прежде, чем вы начнете думать о зависимостях от сторонних библиотек, которые могут быть в разных версиях на разных системах. (Все, что не упаковано поставщиком ОС, должно быть установлено вручную.)

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

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

Даже сделать двоичные файлы просто так i386-linux-gnuи amd64-linux-gnuсложно. Много времени и усилий было потрачено на такие вещи, как Linux Standard Base, чтобы сделать возможным переносимые двоичные файлы . Даже статически связанные двоичные файлы не решают все проблемы. (например, как программа печати текста должна печатать в системе RedHat по сравнению с системой Debian? Как при установке следует добавить пользователя или группу для демона и организовать запуск сценария запуска после каждой перезагрузки?) Это не очень хорошо примеры, потому что перекомпиляция из источника не решает их.

Помимо всего этого, в те времена память была более драгоценной, чем сейчас. Отсутствие дополнительных функций во время компиляции может создать меньшие двоичные файлы (меньший размер кода), которые также используют меньше памяти для своих структур данных. Если для функции требуется дополнительный элемент в каждом конкретном случае classили structдля отслеживания чего-либо, отключение этой функции приведет к уменьшению объекта на 4 байта (например), что хорошо, если это объект, для которого программа выделяет 100 КБ.

Дополнительные функции времени компиляции в наши дни чаще всего используются, чтобы сделать дополнительные библиотеки необязательными. Например , вы можете скомпилировать ffmpegс или без libx264, libx265, libvorbisи многими другими библиотеками для конкретного видео / аудио кодеров, обработки субтитров и т.д. и т.п. Чаще всего , много вещей , которые могут быть собран с или без libreadline: если он доступен при запуске ./configure, то Полученный двоичный файл будет зависеть от библиотеки и обеспечит необычное редактирование строк при чтении из терминала. Если это не так, то программа будет использовать некоторую запасную поддержку, чтобы просто читать строки из stdin с помощью fgets()чего-либо.)

В некоторых проектах все еще используются дополнительные функции для исключения ненужного кода по соображениям производительности. Например, само ядро ​​Linux может быть собрано без поддержки SMP (например, для встроенной системы или старого рабочего стола), и в этом случае большая часть блокировки проще. Или со многими другими дополнительными функциями, которые влияют на некоторый основной код, а не просто пропуская драйверы или другие аппаратные функции. (Хотя специфичные для arch и аппаратные параметры конфигурации составляют большую часть общего исходного кода. См. Почему ядро ​​Linux содержит более 15 миллионов строк кода? )