«Плохо понимаю зачем в iPhone эта древняя и невнятная технология при полноценном браузере и почтовом клиенте.»
Вы будете удивлены — но сама электронная почта гораздо более древняя и невнятная, чем MMS. При этом электронная почта требует наличие как минимум двух почтовых ящиков (у отправителя и у адресата), настроенных почтовых клиентов, знания адреса получателя, и дополнительного оповещения «проверь почту, я тебе фоку прислал».
Зря вы XP приводите — МС очень четко подходит к выпуску ОС с обновленной архитектурой (большими системными требованиями, несовместимостью и т.п.).
Сначала выпускается версия A — с унылым интерфейсом, со всеми детскими болезнями, и небольшой кучкой новых фич (НФ). Естественно, А тут же обзывается «провальной ОС», продвижение идет слабо. Однако, НФ известны, и все только и говорят про то, что лучше бы вышел сервис-пак к старой ОС, в которой все это было бы.
Через год-полтора выпускается версия B — с точно такой же архитектурой, что и A. Естественно, что количество драйверов уже вполне приличное, железо стало более мощным, весь более-менее популярный софт обзавелся поддержкой ОС версии A. Основные отличия — красивый интерфейс, отсутствие детских болезней, и еще немного фич, которые по странному стечению обстоятельств не попали в A.
Усе :) После выхода B называется «самой стабильной, правильной и красивой» ОС, ее начинают сравнивать с «ужасной A, которая тормозит и глючит», и т.д.
Зачем комментировать? Это реальность — если в телефоне есть возможность моментально отправить картинку с камеры любому человеку, то такой возможностью пользуешься.
Если же возможности нет — ты гемороишься с почтой (настроил клиент, потом вспомнил Васино мыло, отправил письмо, послал СМС «проверь почту»).
«О какой сохранности может идти речь когда мой компьютер перезагружается каждые несколько дней? „
А какое отношение имеет плановая перезагрузка к сохранности данных? Правильно, никакого
«Uptime того компьютера, с которого я это пишу — 72 дн»
Вы таки определитесь, что для вас важнее — аптайм, или сохранность вашей (возможоно мгономесячной) работы?
«Извините, а как в этом случае поможет перезагрузка?»
Речь идет о том, что в памяти одновременно живут старая и новая библиотеки. Их реализация может отличаться, равно как могут отличаться внутренние форматы данных, наборы вспомогательных компонентов и т.п.
Как следствие — разного рода конфликты, ошибки при доступе к общим ресурсам, и т.п.
«всё будет работать и без перезагрузки, тихой подменой библиотеки, в то время как уже запущенные программы продолжают использовать старую версию.»
Библиотека существует не в вакууме. Она обращается к ОС, создает объекты ядра, выделяет память, что-то пишет в нее и т.п. И чем сложнее библиотека, тем больше вероятность коллизий.
Простейший пример (если вы немножко в теме) — базовый адрес загрузки библиотеки в винде. Для многих нужд внутри исполняемого модуля требуются не просто относительные адреса (типа «прыгнуть отсюда вперед на 35 байт»), а полноценные логические адреса (для x86 — 32-х битные) — по которым расположен определенный код, либо данные. Поэтому при компиляции исполняемого модуля необходимо указывать его базовый адрес, скажем 0x40000000, по которому модуль будет загружен в память. В этом случае данные, расположенные по смещению 0x200 относительно начала файла, будут иметь виртуальный адрес 0x40000200.
Все будет идеально работать до тех пор, пока ОС может загрузить модуль по этому адресу. Но что делать, если по нему уже загружен другой модуль? Ведь если наша библиотека получит базовый адрес 0x50000000, то сгенерированный компилятором адрес 0x40000200 будет мягко скажем навалидным…
Для решения этой проблемы исполняемый файл МОЖЕТ иметь специальную секцию, содержимое которой после загрузки по другому базовому адресу позволит ОС «подкрутить» адреса внутри модуля, дабы избежать проблем.
Однако если библиотеку делал недобросовстный программист, решивший сэкономить место с помощью купирования «ненужной» секции, или в ней пропишет себя вирус, то мы получаем бомбу с часовым механизмом. Когда произойдет «бум» — сказать сложно.
При этом лично у вас все может быть ок, я и сам (каюсь, грешен) часто делал библиотеки без секции .reloc — ну удобнее мне так, удобнее (я просто ставил хитрый базовый адрес, но не об этом речь). Но на машинах пользователей все может жахнуть в любой момент.
«То есть вы обеспечиваете совместимость ABI, но не совместимость с порождаемыми данными?»
Вы путаете внешний интерфейс библиотеки, и ее реализацию.
Внешний интерфейс очевидно не изменяется, обеспечивая обратную совместимость. Но вот реализация библиотеки может (и наверняка будет — мы же что-то обновили) иной.
И когда в системе взаимодействуют несколько разных реализаций одной и той же библиотеки (причем в роизвольных комбинациях) — жди беды.
«посмотрите на количество версий msvcrt в последних версиях Windows или на количество версий libdb в *nix»
Вы уходите в сторону — если библиотеки имеют разные имена, то никаких проблем с ФС нет в принципе. Не надо путать описанный мной сценарий с DLL-hell
«Но возможность сделать это «на ходу» позволяет (и очень часто позволяет) уменьшить downtime.»
Вы не поверите — возможность обновить библиотеку «на ходу» есть и в винде. Речь идет лишь о том, что это крайний случай, и подобные трюки необходимо использовать с большой осторожностью.
«Вы знаете, я много лет работаю на линуксе и описаное вами происходило от силы раза два»
Типа если у вас нет СПИД'а то предохраняться не нужно? Согласитесь, странная логика.
«В конце-концов, можно и перезагрузиться, если очень надо»
Вы готовы заниматься анализом исходных кодов обновления, дабы точно установить — нужна перезагрузка, или нет?
«установка какого-нибудь банального драйвера принтера»
Установка принтера в винде уже давно-давно не требует перезагрузок. Не знаете — не пишите.
«Ну, ей богу, всё уже сто лет как есть и всё уже давно и прекрасно работает»
И винде все прекрасно работает. Но речь про ФС.
«Все остальные прекрасно обходятся просто подменой библиотек и, если уж край как нужно, перезапуском отдельных сервисов»
Вы видимо не в курсе — народ массово перезапускает иксы (вместе со ВСЕМИ приложениями) после обновлений, и т.п.
Особенно умиляет показательно-небрежное отношение к своему времени — мол, если жахнет, то и фиг с ним.
«Это может быть важно в продакшене. Где минутный простой на перезагрузку означает огромные убытки. „
А теперь подумайте, сколько может стоить получасовое загаживание базы мусором вместо данных из-за подмены библиотеки, и вытекающих отсюда проблем.
Мне повезло — на нашем движке работает mtv.com и иже с ним. Поэтому последствия “простой подмены» и дикий вой после развала продакшена мне хорошо знаком.
«писать модули так, чтобы версия 1.0 и версия 1.5 были совместимы. Если же этого нет, то кто гарантирует что ваше ненаглядное приложение A вообще сможет стартовать после замены библиотеки 1.0 на библиотеку 1.5?»
Речь не о взаимодействии приложения с модулями версии 1.0 и 1.5. Речь о взаимодействии ОДНОВРЕМЕННО ЗАГРУЖЕННЫХ модулей версии 1.0 и 1.5 с системой и друг с другом.
«расскажите мне, идиоту, как перезагрузка сможет вдруг сделать библиотеку 1.5 совместимой с 1.0 если без перезагрузки она с ней несовместима»
Вы неправильно поняли условия задачи. 1.5 совместима с 1.0 (иначе это не обновление, а хз что) — только вот приложение, в которое загружена 1.5, будет портить данные, передаваемые из приложения с модулем 1.0.
Именно поэтому нельзя обновлять систему постепенно, не закрывая работающие приложения. Обновить вы обновите — но стабильность под вопросом.
«представьте себе, он вызовет ту же самую функцию. Ибо у него открыта старая версия dll-ки и ни о каких новых фичах он ничего не узнает до того, как его перезапустят.»
Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Как следствие — вылет приложения и потеря данных.
Странно, такое впечатление что подавляющее кол-во оставляющих комменты либо никогда не занимались программированием, либо никогда не работали с большими проектами, где за трюки в стиле «да я же одну библиотеку изменил, и все» бьют по рукам. Очень, очень больно.
«Таким образом новозапущеные программы будут использовать новый файл, а те который уже работают — будут работать со старым. „
Можно ли гарантировать стабильную работу системы в этом случае? Очевидный ответ — “нет», т.к. при тестировании обновлений невозможно проверить все возможные сочетания версий загруженных одновременно разными приложениями.
«Естественно, если в старом файле была какая-то ошибка связанная с безопасностью — то лучше перезагрузить систему, что бы все программы использовали новый файл»
Постарайтесь понять — что наличие в памяти двух (трех, десяти — в зависимости от количества запущенных установщиков) версий одной библиотеки в памяти это ОГРОМНАЯ проблема. Не столько с безопасностью, сколько со стабильностью.
«Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё? „
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.
Поэтому при любых изменениях в коде любой проект всегда полностью пересобирается, и на нем заново прогоняются тесты.
«В вашем гипотетическом случае дело ограничется (возможно, а возможно и так пройдёт) рестартом этих двух приложений»
Не двух — а всех, так или иначе использующих библиотеку. В т.ч. системных сервисов — что по-сути и есть рестарт все системы.
«При более чем двух последовательных инсталяциях в венде есть неслабый шанс получить вообще неработоспособную систему „
Только эта проблема к ФС никакого отношения не имеет.
“Бага там не только и не столько в необходимости перезагрузки на ровном месте, а именно этом. „
Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей, а не тихая подмена исполняемых модулей без ведома приложених, их использующих
Я прекрасно все понял — автор считает, что принципы работы с ФС в одной ОС являются «багом».
Все претензии в итоге сводятся к тому, что нельзя подменить эксклюзивно открытый файл. Однако само по себе «можно» или «нельзя» это не плюс или минус конкретной ОС, это особенности ее реализации.
К примеру, замена эксклюзивно открытой библиотеки может привести к непредсказуемым сбоям. Приложение A имеет в памяти версию 1.0, а приложение B, запущенное позднее — версию 1.5. Что произойдет, если приложения взаимодействуют друг с другом? Правильно — НЛО его знает что…
Единственный способ корректно провести замену библиотеки во всех приложениях, это перезагрузка всех приложений. То есть — перезагрузка ОС.
Автор забыл сказать, что перезагрузка нужна в общем-то не для затирания файла (что можно сделать в любой ФС), а для того что бы все заинтересованные приложения получили обновленные версии файлов.
И никакой ошибки в работе с ФС нет — есть отдельные криворукие программисты, пишущие прикладной софт.
Верно — беда лишь в том, что американские законы о ТМ и прочей «интеллектуальной собвственности» отличаются редкостным маразмом, плюс прецендентное право.
И «если что» — то все в итоге будет решать американский суд.
Вы будете удивлены — но сама электронная почта гораздо более древняя и невнятная, чем MMS. При этом электронная почта требует наличие как минимум двух почтовых ящиков (у отправителя и у адресата), настроенных почтовых клиентов, знания адреса получателя, и дополнительного оповещения «проверь почту, я тебе фоку прислал».
Сначала выпускается версия A — с унылым интерфейсом, со всеми детскими болезнями, и небольшой кучкой новых фич (НФ). Естественно, А тут же обзывается «провальной ОС», продвижение идет слабо. Однако, НФ известны, и все только и говорят про то, что лучше бы вышел сервис-пак к старой ОС, в которой все это было бы.
Через год-полтора выпускается версия B — с точно такой же архитектурой, что и A. Естественно, что количество драйверов уже вполне приличное, железо стало более мощным, весь более-менее популярный софт обзавелся поддержкой ОС версии A. Основные отличия — красивый интерфейс, отсутствие детских болезней, и еще немного фич, которые по странному стечению обстоятельств не попали в A.
Усе :) После выхода B называется «самой стабильной, правильной и красивой» ОС, ее начинают сравнивать с «ужасной A, которая тормозит и глючит», и т.д.
Если же возможности нет — ты гемороишься с почтой (настроил клиент, потом вспомнил Васино мыло, отправил письмо, послал СМС «проверь почту»).
А какое отношение имеет плановая перезагрузка к сохранности данных? Правильно, никакого
Вы таки определитесь, что для вас важнее — аптайм, или сохранность вашей (возможоно мгономесячной) работы?
Речь идет о том, что в памяти одновременно живут старая и новая библиотеки. Их реализация может отличаться, равно как могут отличаться внутренние форматы данных, наборы вспомогательных компонентов и т.п.
Как следствие — разного рода конфликты, ошибки при доступе к общим ресурсам, и т.п.
«всё будет работать и без перезагрузки, тихой подменой библиотеки, в то время как уже запущенные программы продолжают использовать старую версию.»
Библиотека существует не в вакууме. Она обращается к ОС, создает объекты ядра, выделяет память, что-то пишет в нее и т.п. И чем сложнее библиотека, тем больше вероятность коллизий.
Простейший пример (если вы немножко в теме) — базовый адрес загрузки библиотеки в винде. Для многих нужд внутри исполняемого модуля требуются не просто относительные адреса (типа «прыгнуть отсюда вперед на 35 байт»), а полноценные логические адреса (для x86 — 32-х битные) — по которым расположен определенный код, либо данные. Поэтому при компиляции исполняемого модуля необходимо указывать его базовый адрес, скажем 0x40000000, по которому модуль будет загружен в память. В этом случае данные, расположенные по смещению 0x200 относительно начала файла, будут иметь виртуальный адрес 0x40000200.
Все будет идеально работать до тех пор, пока ОС может загрузить модуль по этому адресу. Но что делать, если по нему уже загружен другой модуль? Ведь если наша библиотека получит базовый адрес 0x50000000, то сгенерированный компилятором адрес 0x40000200 будет мягко скажем навалидным…
Для решения этой проблемы исполняемый файл МОЖЕТ иметь специальную секцию, содержимое которой после загрузки по другому базовому адресу позволит ОС «подкрутить» адреса внутри модуля, дабы избежать проблем.
Однако если библиотеку делал недобросовстный программист, решивший сэкономить место с помощью купирования «ненужной» секции, или в ней пропишет себя вирус, то мы получаем бомбу с часовым механизмом. Когда произойдет «бум» — сказать сложно.
При этом лично у вас все может быть ок, я и сам (каюсь, грешен) часто делал библиотеки без секции .reloc — ну удобнее мне так, удобнее (я просто ставил хитрый базовый адрес, но не об этом речь). Но на машинах пользователей все может жахнуть в любой момент.
Вы путаете внешний интерфейс библиотеки, и ее реализацию.
Внешний интерфейс очевидно не изменяется, обеспечивая обратную совместимость. Но вот реализация библиотеки может (и наверняка будет — мы же что-то обновили) иной.
И когда в системе взаимодействуют несколько разных реализаций одной и той же библиотеки (причем в роизвольных комбинациях) — жди беды.
«посмотрите на количество версий msvcrt в последних версиях Windows или на количество версий libdb в *nix»
Вы уходите в сторону — если библиотеки имеют разные имена, то никаких проблем с ФС нет в принципе. Не надо путать описанный мной сценарий с DLL-hell
«Но возможность сделать это «на ходу» позволяет (и очень часто позволяет) уменьшить downtime.»
Вы не поверите — возможность обновить библиотеку «на ходу» есть и в винде. Речь идет лишь о том, что это крайний случай, и подобные трюки необходимо использовать с большой осторожностью.
Типа если у вас нет СПИД'а то предохраняться не нужно? Согласитесь, странная логика.
«В конце-концов, можно и перезагрузиться, если очень надо»
Вы готовы заниматься анализом исходных кодов обновления, дабы точно установить — нужна перезагрузка, или нет?
«установка какого-нибудь банального драйвера принтера»
Установка принтера в винде уже давно-давно не требует перезагрузок. Не знаете — не пишите.
«Ну, ей богу, всё уже сто лет как есть и всё уже давно и прекрасно работает»
И винде все прекрасно работает. Но речь про ФС.
«Все остальные прекрасно обходятся просто подменой библиотек и, если уж край как нужно, перезапуском отдельных сервисов»
Вы видимо не в курсе — народ массово перезапускает иксы (вместе со ВСЕМИ приложениями) после обновлений, и т.п.
Особенно умиляет показательно-небрежное отношение к своему времени — мол, если жахнет, то и фиг с ним.
«Это может быть важно в продакшене. Где минутный простой на перезагрузку означает огромные убытки. „
А теперь подумайте, сколько может стоить получасовое загаживание базы мусором вместо данных из-за подмены библиотеки, и вытекающих отсюда проблем.
Мне повезло — на нашем движке работает mtv.com и иже с ним. Поэтому последствия “простой подмены» и дикий вой после развала продакшена мне хорошо знаком.
Речь не о взаимодействии приложения с модулями версии 1.0 и 1.5. Речь о взаимодействии ОДНОВРЕМЕННО ЗАГРУЖЕННЫХ модулей версии 1.0 и 1.5 с системой и друг с другом.
«расскажите мне, идиоту, как перезагрузка сможет вдруг сделать библиотеку 1.5 совместимой с 1.0 если без перезагрузки она с ней несовместима»
Вы неправильно поняли условия задачи. 1.5 совместима с 1.0 (иначе это не обновление, а хз что) — только вот приложение, в которое загружена 1.5, будет портить данные, передаваемые из приложения с модулем 1.0.
Именно поэтому нельзя обновлять систему постепенно, не закрывая работающие приложения. Обновить вы обновите — но стабильность под вопросом.
Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Как следствие — вылет приложения и потеря данных.
Странно, такое впечатление что подавляющее кол-во оставляющих комменты либо никогда не занимались программированием, либо никогда не работали с большими проектами, где за трюки в стиле «да я же одну библиотеку изменил, и все» бьют по рукам. Очень, очень больно.
Можно ли гарантировать стабильную работу системы в этом случае? Очевидный ответ — “нет», т.к. при тестировании обновлений невозможно проверить все возможные сочетания версий загруженных одновременно разными приложениями.
«Естественно, если в старом файле была какая-то ошибка связанная с безопасностью — то лучше перезагрузить систему, что бы все программы использовали новый файл»
Постарайтесь понять — что наличие в памяти двух (трех, десяти — в зависимости от количества запущенных установщиков) версий одной библиотеки в памяти это ОГРОМНАЯ проблема. Не столько с безопасностью, сколько со стабильностью.
«Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё? „
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.
Поэтому при любых изменениях в коде любой проект всегда полностью пересобирается, и на нем заново прогоняются тесты.
Не двух — а всех, так или иначе использующих библиотеку. В т.ч. системных сервисов — что по-сути и есть рестарт все системы.
«При более чем двух последовательных инсталяциях в венде есть неслабый шанс получить вообще неработоспособную систему „
Только эта проблема к ФС никакого отношения не имеет.
“Бага там не только и не столько в необходимости перезагрузки на ровном месте, а именно этом. „
Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей, а не тихая подмена исполняемых модулей без ведома приложених, их использующих
У вас есть другое решение? Поделитесь пожалуйста.
Все претензии в итоге сводятся к тому, что нельзя подменить эксклюзивно открытый файл. Однако само по себе «можно» или «нельзя» это не плюс или минус конкретной ОС, это особенности ее реализации.
К примеру, замена эксклюзивно открытой библиотеки может привести к непредсказуемым сбоям. Приложение A имеет в памяти версию 1.0, а приложение B, запущенное позднее — версию 1.5. Что произойдет, если приложения взаимодействуют друг с другом? Правильно — НЛО его знает что…
Единственный способ корректно провести замену библиотеки во всех приложениях, это перезагрузка всех приложений. То есть — перезагрузка ОС.
Если у вас есть другое решение — предложите.
И никакой ошибки в работе с ФС нет — есть отдельные криворукие программисты, пишущие прикладной софт.
И «если что» — то все в итоге будет решать американский суд.
Ну и касательно «других регистраторов» — они напрямую зависят от ICANN. Так что…
Правительство США посредством ICANN.