Почему обновление рабочей системы Linux не проблематично?

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

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

Предположим, что "B" был заменен в файловой системе, также. Теперь "A" должен считать "B" снова по некоторым причинам. Вопрос: действительно ли возможно, что "A" мог найти несовместимую версию "B" и отказать или неправильно функционировать некоторым другим способом?

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

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

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

Почему никто не обновляет их системы путем перезагрузки с живым CD или некоторой подобной процедурой?

Закрытие и перезагрузка от другой версии привели бы к приостановке обслуживания. Для серверов это не обычно желаемо. В любом случае диспетчер пакетов в рабочей системе знает о программном обеспечении и версиях, которые это установило. Живые CD имеют там собственный список установленного программного обеспечения, возможно с различными версиями. Это мешает надежно обновлять рабочую систему с живого CD.

Живые CD иногда используются, когда новый выпуск O/S устанавливается. В этом случае чистая установка O/S обычно делается. Это может ограничить сумму неиспользованных файлов от предыдущей сохраняемой версии. Это может быть больше усилия, чем обновление живой системы. Однако, если различные корневые разделы используются, это может ограничить риск застревания с незагрузочной частично обновленной системой.

Существуют некоторые случаи, где это - проблема:

• Обновление JDK, в то время как java-VM работает: Я спросил myselv тот же вопрос, который Вы получили - у меня был рабочий кот, который использует Java. Теперь после обновления патча JDK это все еще работало без проблем - таким образом, это казалось.

Теперь объяснение является кэш-памятью. Хорошо - я запустил программу пожирателя ресурсов памяти для израсходования всей доступной RAM - и затем разрушенный кот (после того, как я получил доступ к приложению, работающему там).

• Обновление ядра в системах SuSE: На SuSE старое ядро и его модули становятся удаленными прямо после обновления патча ядра. Если Вы затем захотите использовать что-то новое, которое требует модуля ядра, который не был загружен вплоть до сих пор, то сервис перестанет работать.