Файловая система unix
В UNIX существует только один корневой каталог, а все остальные файлы и каталоги вложены в него. Чтобы получить доступ к файлам и каталогам на каком-нибудь диске, необходимо смонтировать этот диск командой mount. Например, чтобы открыть файлы на CD, нужно, говоря простым языком, сказать операционной системе: «возьми файловую систему на этом компакт-диске и покажи её в каталоге /mnt/cdrom». Все файлы и каталоги, находящиеся на CD, появятся в этом каталоге /mnt/cdrom, который называется точкой монтирования (англ. mount point).[2] В большинстве UNIX-подобных систем съёмные диски (дискеты и CD), флеш-накопители и другие внешние устройства хранения данных монтируют в каталог /mnt, /mount или /media. Unix и UNIX-подобные операционные системы также позволяет автоматически монтировать диски при загрузке операционной системы.
Файловая система UNIX имеет иерархическую структуру; чаще всего она описывается в виде дерева. Вершина этого дерева - это справочник root. Он обозначается с помощью /. Все другие справочники и файлы берут свое начало из справочника root.
Один из путей из root ведет в ваш собственный справочник. Вы можете организовывать и хранить информацию в вашей собственной иерархии справочников и файлов.
Другие пути ведут к системным справочникам и доступны всем пользователям. Чтобы получить перечень всех справочников и файлов в справочнике root, введите командную строку:
ls -l /<CR>
Чтобы перемещаться по файловой структуре, вы можете использовать имена путей. Например, вы можете переместиться в справочник /usr/bin, если введете следующую командную строку:
cd /usr/bin<CR>
В операционной системе UNIX файл является хранилищем двоичных и символьных данных, хранимых как поток байтов. В UNIX символьные данные кодируются с помощью кода ASCII, хотя на таких системах, как мэйнфрейм IBM 390, используется кодировка EBCDIC. Коды ASCII и EBSDIC отличаются друг от друга, т.е. один и тот же код в них соответствует разным символам, а один и тот же символ закодирован в них разными кодами. В разных операционных системах данные хранятся по-разному. Данное обстоятельство может вызвать проблемы при попытке в одной операционной системе обработать данные, созданные в другой операционной системе. Необходимы специальные программы для конвертирования данных из файлов, созданных в одной операционной системе в файлы другой операционной системы так, чтобы они были пригодны для обработки.
Файлы содержат разные типы информации. Например, файл может содержать исходный код программы на С, COBOL или C++, он может быть текстовым документом с письмом от друга или исполняемым модулем программы. В UNIX существует несколько "родных" форматов файлов, которые можно просматривать или копировать, используя команды системы. Однако некоторые файлы нельзя обработать внутренними командами UNIX. Например, файлы базы данных для СУБД независимых разработчиков, таких как Oracle, требуют для обработки специальных программ.
Файл может располагаться на разных носителях. Файлы бывают постоянными, т.е. записанными на диске или временными - в памяти; данные из файла могут выводиться на терминал, или файл может принимать данные с терминал\а. Если файл постоянный, то его можно просмотреть, а если файл временный, то вы можете даже не знать о его существовании.
DLL-hell
DLL hell (DLL-кошмар, буквально: DLL-ад) — тупиковая ситуация, связанная с управлением динамическими библиотеками DLL в операционной системе Microsoft Windows.
Сущность проблемы заключается в конфликте версий DLL, призванных поддерживать определённые функции. DLL hell — пример плохой концепции программирования, которая, подобно скрытой мине, приводит к резкому возрастанию трудностей при усложнении и совершенствовании системы.
По исходному замыслу, DLL должны быть совместимыми от версии к версии и взаимозаменяемыми в обе стороны.
Реализация механизма DLL такова, что несовместимость и невзаимозаменяемость становится скорее правилом, чем исключением, что приводит к большому количеству проблем.
Отсутствие стандартов на имена, версии и положение DLL в файловой структуре приводит к тому, что несовместимые DLL легко замещают или отключают друг друга
Отсутствие стандарта на процедуру установки приводит к тому, что установка новых программ приводит к замещению работающих DLL на несовместимые версии
Отсутствие поддержки DLL со стороны компоновщиков и механизмов защиты приводит к тому, что несовместимые DLL могут иметь одинаковые имя и версию
Отсутствуют стандартные инструменты идентификации и управления системой DLL пользователями и администраторами Использование отдельных DLL для обеспечения связи между задачами приводит к нестабильности сложных приложений
Для избежания конфликтов обычно используют множество избыточных копий DLL для каждого приложения, что сводит нанет исходную идею получения преимущества от DLL как стандартных модулей, хранящихся один раз в памяти и разделяемых многими задачами. Кроме того, при таком опыте после исправления ошибок в DLL или восстановления системы из архива количество различных DLL, носящих одно и то же имя и выполняющих те же функции, возрастает, а автоматическое обновление версии или исправление ошибок становится невозможным.
История проблемы
Эта проблема возникла в ранних версиях Microsoft Windows.С подобными же проблемами сталкивались ранние версии Mac OS X, но с использованием других технологий. Не избегают подобных проблем дистрибуторы библиотек Open Source.Поэтому, когда речь идёт о не-майкрософтовской среде, эту ситуацию называют dependency hell (кошмар зависимостей). Проблема постоянно повторяется, когда программу пытаются запустить не с той DLL, c которой она тестировалась, что показывает изначальную порочность общей концепции, позволяющей произвольную замену версий модулей.
Меры против DLL hell
Данные меры рекомендуют предпринимать одновременно для получения наилучшего результата: подсчитать контрольную сумму кода функции вызываемой из DLL - сравнить с контрольной суммой функции используемой при написании программы.
Операционная система должна поставляться совместно с менеджером пакетов, чтобы иметь возможность прослеживать все взаимозависимости DLL, при этом использование менеджера пакетов должно поощряться, а индивидуальная инсталляция DLL — по возможности отвергаться.
Централизованное распространение библиотек
Допустить возможность параллельного использования нескольких версий одной и той же DLL [1].
При модификации программного обеспечения для частного использования поставлять также модифицированные версии DLL.
Во время проектирования DLL должна тщательно продумываться концепция функций и версий. DLL не должны использоваться без необходимости, а библиотеки, связанные только с одним приложением, должны подключаться статически (в EXE-файл).