Хабр Курсы для всех
РЕКЛАМА
Практикум, Хекслет, SkyPro, авторские курсы — собрали всех и попросили скидки. Осталось выбрать!
Хабр доступен 24/7 благодаря поддержке друзей
Комментарии 302
Что, помешал автор фапать на образ непорочного БГ?
Это фанатизм или попытка самоутвердиться?
Факты есть факты. Спорить из-за этого или оскорблять кого-то — только себе хуже. Костыли у МС прикручиваются постоянно. Я не говорю, что их нет в ПО других производителей, но не дальнозоркость обычно и приводил к появлению таких вещей, как .net, 10 версий IE и т.д.
ведь не просто так ту-же прозрачность окошек без .net не прикрутить в win98(ну это просто для примера)
Факты есть факты. Спорить из-за этого или оскорблять кого-то — только себе хуже. Костыли у МС прикручиваются постоянно. Я не говорю, что их нет в ПО других производителей, но не дальнозоркость обычно и приводил к появлению таких вещей, как .net, 10 версий IE и т.д.
ведь не просто так ту-же прозрачность окошек без .net не прикрутить в win98(ну это просто для примера)
Это фанатизм или попытка самоутвердиться?
Скорее попытка суицида.
Doppelganger
Вообще святой человек. Давайте за него помолимся, ведь все его 88 комментов — это оказывается не попытка самоутвердиться и компенсировать свои умственные недостатки путём поливания всех грязью, это что то другое…
Вообще все обиженные сидят на упячке и т.п. недалёких сайтах, поэтому свободен, тут твоё убогое мнение никому не интересно, деградируй в другом месте.
Вообще святой человек. Давайте за него помолимся, ведь все его 88 комментов — это оказывается не попытка самоутвердиться и компенсировать свои умственные недостатки путём поливания всех грязью, это что то другое…
Вообще все обиженные сидят на упячке и т.п. недалёких сайтах, поэтому свободен, тут твоё убогое мнение никому не интересно, деградируй в другом месте.
10 версий IE? Их всего 8. У мозилы их сотни, хотя основные 3.
Жаль у меня не хватает заряда, чтобы тебя заминусовать…
ты знаешь а мне что-то тебя немного жаль )
но минус таки ты заслужил
но минус таки ты заслужил
Какой толстенный тролль ))
зачем кидаться зря словами? это ведь просто мнение автора =) а вот мне Вас искренне жаль, зато Вы первый в рейтинге… с конца… какой смысл идти на осознанное понижение собственной кармы?
жирный троль?
что-то я не понял причем тут дизайн… ошибка вроде как не в дизайне… или я чего-то не понял?
дизайн архитектуры приложения, системы…
аа… не въехал сходу )
А есть же слово «проектирование».
Да и gramota.ru говорит, что «дизайн» относится больше к внешнему облику.
Да и gramota.ru говорит, что «дизайн» относится больше к внешнему облику.
design patterns широко используемый термин.
Это заблуждение. К примеру, гейм-дизайнер не имеет прямого отношения к внешнему виду игры.
Согласен.
Но я почему-то больше привык слышать «проектирование системы», чем «дизайн».
Для меня «проектирование» — это внутреннее устройство, а «дизайн» так или иначе связан с пользователем (потому за играбельность отвечает дизайнер, а за внутреннее устройство архитектор), но это моё мнение, я его никому не навязываю. Да и грань в моём случае тоже достаточно тонкая, так что за правило не сгодится.
Но я почему-то больше привык слышать «проектирование системы», чем «дизайн».
Для меня «проектирование» — это внутреннее устройство, а «дизайн» так или иначе связан с пользователем (потому за играбельность отвечает дизайнер, а за внутреннее устройство архитектор), но это моё мнение, я его никому не навязываю. Да и грань в моём случае тоже достаточно тонкая, так что за правило не сгодится.
а клининг-менеджер — это вам не уборщица! Речь идет не о заимствованном названии профессии, а о том, что «проектирование» в русском звучит не только понятней, но и лучше отражает суть, чем смешанное «дизайн».
игровой проектировщик — звучит как то не очень
В английском языке слово «design» используется и как существительное, и как глагол.
В форме глагола, «дизайн» следует понимать, как процесс проектирования и разработки чего-либо.
В форме глагола, «дизайн» следует понимать, как процесс проектирования и разработки чего-либо.
дизайн — это не только внешний вид.
«Дизайн» — обширное понятие, это совсем необязательно рисование веб-страницы в фотошопе (или где там их рисуют) :)
сейчас в универе(техническом) учим англ, в основном Итшную терминологию, так что могу по свежему опыту сказать — design в IT сфере это даже скорее разработка, чем непосредственно дизайн
Буквально вчера перешел на четвертые кеды не выходя из третьих (причем удалив половину оных по пути). Все работало.
тут говорилось не про linux, а про unix подобные, что в windows сделано лучше чем в *nix системах(*bsd, linux, macosx, etc) системах? кажется, только костыли…
Если брать все виды *nix'ов, то, пожалуй, ничего, а если какой-нибудь конкретный — то, например, видеоподсистема в Linux ужасна. То, что всё управление видеокартой вынесено в отдельный процесс во-первых противоречит основной идее (ядро является посредником между программами и железом), а во-вторых имеет важные практические последствия (supend/hibernate становятся «русской рулеткой»). Опять-таки dnotify имеет кучу проблем (следить за сменными носителями нельзя — а на них, как раз, это полезнее всего).
Другое дело что в *nix принято ошибки исправлять (inotify сменил dnotify и работа над полноценными ядрёными драйверами сейчас весьма активно ведётся), а не искать к ним оправдание и пристраивать костыли к костылям как в Windows…
Другое дело что в *nix принято ошибки исправлять (inotify сменил dnotify и работа над полноценными ядрёными драйверами сейчас весьма активно ведётся), а не искать к ним оправдание и пристраивать костыли к костылям как в Windows…
из статьи непонятно про чьи «миллионные убытки» идет речь, автор поясните плиз
Пользователей, которые были вынуждены перезагружать компьютеры. Компаний, которые вынуждены платить за восстановление работоспособности программ. Разработчиков (в том числе в самой Microsoft), которые вынуждены изобретать кучу костылей, а затем — заплаток к этим костылям.
Миллионы — это консервативная оценка.
Миллионы — это консервативная оценка.
Необходимость перезагрузки сервера может многого стоить. ИМХО. А если он потом ещё и не заведётся (из-за описанной выше проблемы), будет совсем кисло. Ну это скорее теория, чем практика.
Насколько я помню, существуют техники, которые позволяют без перезагрузки даже обновлять ядро линукса (работающее в данный момент!). Хотя это уже немного иная тема.
Насколько я помню, существуют техники, которые позволяют без перезагрузки даже обновлять ядро линукса (работающее в данный момент!). Хотя это уже немного иная тема.
А если он потом ещё и не заведётся (из-за описанной выше проблемы), будет совсем кисло. Ну это скорее теория, чем практика.В моём случае это практика. Оправлять человека в другой город плюс время простоя — это недёшево. Правда это было лет 10 назад — сейчас этим занимается техподдержка хостинг-провайдера, что не значит что она от этого дела в восторге.
ага, тот же kexec.
сам он никогда не перезагрузится
да ладно
у меня никогда такого не было, но когда работала на ноуте парня — каждые 5 минут вылезало это окошко, которое отсчитывало сколько-то там секунд(минута, чтоли) и ребутает систему, если не отменить.
И бывало такое, что подходишь минут через 10, а винда ребутнулась. Опять же, у меня такого никогда не было. Мб какие-то параметры отключены. Не знаю
И бывало такое, что подходишь минут через 10, а винда ребутнулась. Опять же, у меня такого никогда не было. Мб какие-то параметры отключены. Не знаю
Это был Вирусяка ;)
Очень забавная штука. В универе не было прав поставить заплатку, так за то время, пока тикал таймер запускал консоль и выполнял shutdown -a (отмену). Правда преподаватель как-то странно после этого на меня смотрел :(
Очень забавная штука. В универе не было прав поставить заплатку, так за то время, пока тикал таймер запускал консоль и выполнял shutdown -a (отмену). Правда преподаватель как-то странно после этого на меня смотрел :(
успел раньше меня ))
Ребята! ну вы даете… Да, был вирус такой который систему ребутил, но сейчас насколько я знаю любой уважающий себя антивирус его отловит и накажет. А тут человек говорит про автоматическую перезагрузку после апдейта. Там окошко вылезает и говорит что через только-то перезагрузит систему. можно нажать отмена. но если не успел то система перезагрузится и эту «фичу» можно отключить в сервисах.
Другое дело что у некоторых товарищей автоматические апдейты вообще выключены и про такую штуку он вообще не знают
Другое дело что у некоторых товарищей автоматические апдейты вообще выключены и про такую штуку он вообще не знают
Не думаю, у меня когда я сидел на корпоративной винде такое было заботливо добавлено IT, чтобы особо хитрые пользователи не забивали на security updates.
Мне кажется это вирус :)
Только после падения svchost появляется окошко с одной минутой и комп ребутается :)
Только после падения svchost появляется окошко с одной минутой и комп ребутается :)
Нет, не вирус. Если обновление автоматическое, то и перезагрузка тоже, если не успеешь отменить.
Пришлось во всем офисе перенастроить на автоматическое скачивание обновлений, но ручную их установку.
Это в настройках автообновления делается.
Пришлось во всем офисе перенастроить на автоматическое скачивание обновлений, но ручную их установку.
Это в настройках автообновления делается.
хммм… может давно не сидел за XP… но не помню чтобы автоматическая служба сама ребутала комп
Более того оно точно так же работает и в 2003 Server. Я как раз пару дней назад с этим столкнулся, прихожу утром, а мне сервак так весело, дескать, тут апдейт был и я перегрузился. Хорошо ночью. Первый раз поставил автоматическую установку обновлений, до этого всегда было автоматическое скачивание и ручная установка.
Windows Update на ручной режим и не будет требовать.
перезагрузится, когда обновления скачает, тоже один раз попал так, будильник на компе завел, а то перегрузился ночью, утром проспал, смотрю на комп, а так радостная надпись что обновление установлено
Перезагрузится, если приехали важные заплатки. Ну и конечно если Update не отключен.
у меня комп как-то сам включался через несколько минут после включения, а вы говорите, он перезагрузиться сам не может :)
Хм… компьютер сам перегружался только когда что — то падало, системная ошибка! Других вариантов пока не наблюдал.
Чтобы не просил настырно перезагрузиться: www.online-tech-tips.com/computer-tips/disable-restart-now/
Чтобы не перезагружался сам: www.askstudent.com/techtips/disable-automatic-reboot-after-windows-update/
Чтобы не перезагружался сам: www.askstudent.com/techtips/disable-automatic-reboot-after-windows-update/
Все не так просто. FAT намного проще чем любая UNIX-система. Более того, если всё так, как написано, то почему не случилось чуда при использовании NTFS? Там метаинформация отделена от данных.
FAT проще, возможно… Но не совершенна… Посмотреть только на количество ограничений, в мир нанотехнологий некоторые из них просто недопустимы.
support.microsoft.com/kb/314463/ru
support.microsoft.com/kb/314463/ru
Дык никто про соврешенство и не говорит, но на тот момент это была весьма современная ОС. В 128 КБ ОЗУ и такое затолкать сумать нужно. Не слудет забывать, что юникс на тот момент был уделом больших ЭВМ.
Только ушли от FAT они не так уж и давно.
На тот момент Unix производства Microsoft работал на PC. Так что всё у них было.
уникс разрабатывался на пидипи-7 с непонятно сколько памятью, а потом был перенесён на пидипи-11 с… гм… гм… возможно, с 64-мя килобайтами? и сам занимал 12кб :).
А в фате метаинформация от файла тоже отделена, это ошибка именно в днк, а не в файловой системе.
А в фате метаинформация от файла тоже отделена, это ошибка именно в днк, а не в файловой системе.
А в фате метаинформация от файла тоже отделена, это ошибка именно в днк, а не в файловой системе.Это не совсем так. Длина файла записана именно в каталоге. В FAT нет понятия inode, которое бы хранило эту важную информацию о файле, а файлы длиной 10 байт и 100 байт — всё-таки разные файлы.
Юниксзародился на мейнфрейме GE-600. А на PDP-7 долго влачил жалкое существование — группа разрабочиков очень хотела перейти на более мощную машину, т.к. ресурсов PDP-7 не хватало. Второе дыхание проект получил перейда на PDP-11/20, а это уже весьма мощный компьютер. Там же он обрёл соврtменные черты. Уже в конце 80х ядро линукса (только ядро!) превышало 40КБ — по тем временам очень много! Предшественник DOS — CP/M, в котором и родился FAT, занимал лишь несколько килобайт.
Тьфу, в конце 70х, конечно же. А именно — в 1979 году. Это было одно из первых ядер обладающие основными характерыми особенностями *nix.
>Уже в конце 80х ядро линукса (только ядро!) превышало 40КБ — по тем временам очень много! Предшественник DOS — CP/M, в котором и родился FAT, занимал лишь несколько килобайт.
Ну наверное всё-таки Юникса, а не Линукса, а во-вторых: что умел тот ДОС — и что умел Юникс? ;)
Ну наверное всё-таки Юникса, а не Линукса, а во-вторых: что умел тот ДОС — и что умел Юникс? ;)
метаинформация в файловой системе и в FAT отделена :) но вот внутри самой операционной системы… в linux FAT к примеру тоже поддерживается, но внутри ядра линуха это все теже inode's+dirnode's
а разве драйверы файловых систем не реализуют стандартные операции вроде create/open/read/open/write/delete?
что значит внутри ядра всё теже inode? внутри драйвера ext2? тогда внутри драйвера fat — своя специфика
что значит внутри ядра всё теже inode? внутри драйвера ext2? тогда внутри драйвера fat — своя специфика
Это прекрасно. Ноу Linux нет COM. А у Windows она есть давным давно. Что прикажете с ней делать? Объясняю на пальцах.
У вас есть некий DLL являющийся контейнером объекта COM. Этот объект загружен и используется. И тут вы волшебным образом подменяете файл используя волшебную силу inodes. Внимание вопрос — если ещё одно приложение попробует создать этот объект — какая версия будет создана?
Вторая проблема — ресурсы. Ресурсы в Windows загружаются не в момент загрузки приграммы, а по мере использования или по запросу.
Третья проблемма — DLL. У вас есть некая системная DLL, которую использует множетсво приложений. И тут вы её находу заменяете. А потом запускается новое приложение и пытается вручную загрузить ещё один экземпляр этотй DLL. Но это уже другая DLL! А теперь учтите, что у DLL есть методы, вызываемые при первоначальной загрузке, а тут первоначальных загрухок получается две.
Не нужно считать других глупее себя. Просто пример — запустите в Windows любой исполняемый файл. А теперь переименуйте его. Фокус-покус! Файл перименовался! Причём фал не просто продолжает работать, но и может использовать ресурсы. Хотя, следуя логиrе автора быть такого ну, никак не может. Inodes в данном случае заменяет module instance handle. И не важно какая файловая система.
Не нужно считать других глупее себя. Microsoft сознательно отказалась от идеи виртуальной файловой системы ядра, так, как развязывало ей руки в применении множества других перспективных технологий.
У вас есть некий DLL являющийся контейнером объекта COM. Этот объект загружен и используется. И тут вы волшебным образом подменяете файл используя волшебную силу inodes. Внимание вопрос — если ещё одно приложение попробует создать этот объект — какая версия будет создана?
Вторая проблема — ресурсы. Ресурсы в Windows загружаются не в момент загрузки приграммы, а по мере использования или по запросу.
Третья проблемма — DLL. У вас есть некая системная DLL, которую использует множетсво приложений. И тут вы её находу заменяете. А потом запускается новое приложение и пытается вручную загрузить ещё один экземпляр этотй DLL. Но это уже другая DLL! А теперь учтите, что у DLL есть методы, вызываемые при первоначальной загрузке, а тут первоначальных загрухок получается две.
Не нужно считать других глупее себя. Просто пример — запустите в Windows любой исполняемый файл. А теперь переименуйте его. Фокус-покус! Файл перименовался! Причём фал не просто продолжает работать, но и может использовать ресурсы. Хотя, следуя логиrе автора быть такого ну, никак не может. Inodes в данном случае заменяет module instance handle. И не важно какая файловая система.
Не нужно считать других глупее себя. Microsoft сознательно отказалась от идеи виртуальной файловой системы ядра, так, как развязывало ей руки в применении множества других перспективных технологий.
вообщето CORBA есть и в линухе…
а COM, загибает и сама мелкософт
а COM, загибает и сама мелкософт
прекоммент: да кстати, ваш комментарий, ну совсем не в тему.
1) корба есть (про dll ниже)
2) ресурсы в линухе тоже загружаются по мере необходимости, даже от экзешника в памяти будет лежать только то что исполняется
3) нет никакой проблемы, заменяйте наздоровье, в линухе совместимость dll (.so) обеспечивается версионированием. Если версия одинакова, то для приложений dll'ка абсолютно заменяемая. Запустили одно приложение со старой dll, во время работы обновили dll, новое приложение запустится с новой версией, старая будет работать со старой версией.
3) В линухе можно переименовать запущенный файл, и даже переместить его и даже, о боже, удалить! И тоже он будет использовать все ресурсы которые ему нужны были для запуска. Файл в линухе удаляется с диска только после того как его освободили все приложения.
microsoft не отказалась от виртуальной файловой системы ядра, и это никак не сковывало ей руки в новых технологиях
1) корба есть (про dll ниже)
2) ресурсы в линухе тоже загружаются по мере необходимости, даже от экзешника в памяти будет лежать только то что исполняется
3) нет никакой проблемы, заменяйте наздоровье, в линухе совместимость dll (.so) обеспечивается версионированием. Если версия одинакова, то для приложений dll'ка абсолютно заменяемая. Запустили одно приложение со старой dll, во время работы обновили dll, новое приложение запустится с новой версией, старая будет работать со старой версией.
3) В линухе можно переименовать запущенный файл, и даже переместить его и даже, о боже, удалить! И тоже он будет использовать все ресурсы которые ему нужны были для запуска. Файл в линухе удаляется с диска только после того как его освободили все приложения.
microsoft не отказалась от виртуальной файловой системы ядра, и это никак не сковывало ей руки в новых технологиях
1. Корба и COM — вещи сильно разные. COM (а имено — маршалинг) поддерживается на уровне OS. Замена DLL содержащей объект COM приведёт к краху. Поясняю — COM объект исполняющий код может быть один. А вот пользовательских объектов которые с ним работают может быть много. и хранится всё это в одном файле. Если у вас имеется созданый объект COM, а потом вы пытетесь к нему обратится из объекта другйо версии — это приведёт к краху или загадочным глюкам.
2. Именно, но кривые руки периодически пытаются обратится к ресурсам «вручную» — через повтроное открытие файла. Как правило этого можно избежать, но решение не всегда тривиальное.
3. DLL при загрузке её приложением может выполнять некие действия. Есть функции DLL которые автоматически Вызываются системой при её загрузке приложением. Причём эти функции различны для первой загрузки ипоследующих — очень, кстати, удобно.Если вы заменили DLL, то при последующей загрузке она опять попытается произвести некоторую инициализацию — а такого быть не должно! Да, и кроме этого там много интересных эффектов возникает.
4. Это прекрасно. Как вы думаете если Windows позволяет переименовать используемый файл, сложно ли было добавить возможность его удаления?
2. Именно, но кривые руки периодически пытаются обратится к ресурсам «вручную» — через повтроное открытие файла. Как правило этого можно избежать, но решение не всегда тривиальное.
3. DLL при загрузке её приложением может выполнять некие действия. Есть функции DLL которые автоматически Вызываются системой при её загрузке приложением. Причём эти функции различны для первой загрузки ипоследующих — очень, кстати, удобно.Если вы заменили DLL, то при последующей загрузке она опять попытается произвести некоторую инициализацию — а такого быть не должно! Да, и кроме этого там много интересных эффектов возникает.
4. Это прекрасно. Как вы думаете если Windows позволяет переименовать используемый файл, сложно ли было добавить возможность его удаления?
1. в данном примере проблемы реализации COM пытаются привестись как приемущества?
2. что значит кривые руки? в винде тоже можно обратиться «вручную», в чем проблема?
3. опять же — проблемы реализации пытаются привести как приемущество?
4. у вас в руках черный ящик, вы обнаружили что черный ящик может выполнять действие A только при некоторых условиях, с чего вы решили что этот черный ящик очень прост для переделки выполнения А при всех условиях?
2. что значит кривые руки? в винде тоже можно обратиться «вручную», в чем проблема?
3. опять же — проблемы реализации пытаются привести как приемущество?
4. у вас в руках черный ящик, вы обнаружили что черный ящик может выполнять действие A только при некоторых условиях, с чего вы решили что этот черный ящик очень прост для переделки выполнения А при всех условиях?
Как-то ваш ответ сам себе противоречит. Вы прочитайте что вы написали:
Просто пример — запустите в Windows любой исполняемый файл. А теперь переименуйте его. Фокус-покус! Файл перименовался! Причём файл не просто продолжает работать, но и может использовать ресурсы.А теперь
вы волшебным образом подменяете файл используя волшебную силупереименования файлов — что дальше произойдёт? А вот все возможные ваши беды и произойдут.
Microsoft сознательно отказалась от идеи виртуальной файловой системы ядра, так, как развязывало ей руки в применении множества других перспективных технологий.Каких именно? Какая именно технология существенным образом опирается на невозможность «удаления» открытого файла? И почему это не мешает им работать в WINE? Или может речь идёт о каких-то суперсекретных технологиях, которые WINE никак может скопировать из-за того, что Linux не использует гениального подхода Microsoft?
На тот момент времени возможность удаления файлов на лету, во-первых, сильно усложняло систему, во-вторых создавало дополнительные трудность с COM, которую делала ставку MS. На данный момент это пердставляет никаких бролем, но очень дорго из-за проблем с соместимостью. MS — коммерческая котора и руководствуется прежде всего экономической целесообразность. ЗАчем делать то, что не выгодно? На тот момент это было не выгодно. Выгодно ли это сейчас — только микрософт знает
Чувак, glibc обновляется БЕЗ перезагрузки.
xpcom
Если автор программы считает, что переименование dll вызовет крах системы, он может использовать flock.
Чуда не случилось потому что нужно было поддерживать совместимость. В Linux и FAT и NTSC ведут себя как любая обычная файловая система…
Просто когда в файловой системе у одного файла может быть только одно имя то идея что «блокировка файла == блокировка имени» не кажется странной.
Просто когда в файловой системе у одного файла может быть только одно имя то идея что «блокировка файла == блокировка имени» не кажется странной.
>Главное: если программа открыла файл и даже если она сделала это в эксклюзивном режиме — на права доступа к записи в каталоге это не распространяется.
Мне непонятно — вот программа открыла файл в эксклюзивном режиме, мы его удалили или перезаписали, после чего эта программа, у которой он всё еще открыт в эксклюзивном режиме, пытается из него что-то прочитать, или в него что-то записать. Что произойдёт? Данные пойдут в inode, которое больше не ассоциируется с этим именем файла и будет при первой возможности стёрто? Программа должна проверять какие-то флаги файла перед записью, типа что он не удалён?
Мне непонятно — вот программа открыла файл в эксклюзивном режиме, мы его удалили или перезаписали, после чего эта программа, у которой он всё еще открыт в эксклюзивном режиме, пытается из него что-то прочитать, или в него что-то записать. Что произойдёт? Данные пойдут в inode, которое больше не ассоциируется с этим именем файла и будет при первой возможности стёрто? Программа должна проверять какие-то флаги файла перед записью, типа что он не удалён?
программа сможет свободно писать и читать из него. inode останется в живых, пока программа не закроет файл.
Т.е. запись в каталоге про этот файл удалится сразу. А вот сам файл — только тогда, когда программа его закроет.
Может кого-то путает терминология. Так что поясню на всякий случай — каталог (или «папка» в терминологии Microsoft) — это на самом деле просто специальный файл, который хранит список файлов «содержащихся в» этом каталоге.
При удалении файла отдельно удаляется запись в каталоге и отдельно сам файл (т.е. данные, которые в нем содержаться). По крайней мере так происходит в *nix
Т.е. запись в каталоге про этот файл удалится сразу. А вот сам файл — только тогда, когда программа его закроет.
Может кого-то путает терминология. Так что поясню на всякий случай — каталог (или «папка» в терминологии Microsoft) — это на самом деле просто специальный файл, который хранит список файлов «содержащихся в» этом каталоге.
При удалении файла отдельно удаляется запись в каталоге и отдельно сам файл (т.е. данные, которые в нем содержаться). По крайней мере так происходит в *nix
А такой метод не имеет собственных проблем, отличных от тех, что есть в Windows?
Потенциально прога удалившая файл не сможет его занового создать в случае если место на диске кончилось. Но это клиника, забивать диск под завязку плохо по множеству причин (к примеру с точки зрения фрагментации диска).
Конечно имеет! Например что будет если программа на вашем компьютере открыла файл на машине соседа… и повисла… вместе с вашим компом! Имя же файла было удалено — что тут делать? Когда файл-то удалять? Собственно потому SHARE.EXE и делает то, что он делает: если программа с машины соседа заблокировала файл и умерла вместе с машиной соседа — то вам достаточно перезагрузиться и всё будет Ok. Потерянного места не будет. Но за 10 лет эксплуатации Unix (а теперь уже за 40 лет) было выяснено что эти недостатки не перевешивают достоинств…
>вот программа открыла файл в эксклюзивном режиме
открыта inode этого файла
>мы его удалили или перезаписали
удалили или перезаписали метку в таблице размещения файлов
>после чего эта программа, у которой он всё еще открыт в эксклюзивном режиме, пытается из него что-то прочитать…
и прочитает inode
>… или в него что-то записать [skipped] Данные пойдут в inode, которое больше не ассоциируется с этим именем файла и будет при первой возможности стёрто?
если файловая запись была удалена — она будет создана заново. если имела место замена на другой файл — сабжевый будет сохранен под именем file~
открыта inode этого файла
>мы его удалили или перезаписали
удалили или перезаписали метку в таблице размещения файлов
>после чего эта программа, у которой он всё еще открыт в эксклюзивном режиме, пытается из него что-то прочитать…
и прочитает inode
>… или в него что-то записать [skipped] Данные пойдут в inode, которое больше не ассоциируется с этим именем файла и будет при первой возможности стёрто?
если файловая запись была удалена — она будет создана заново. если имела место замена на другой файл — сабжевый будет сохранен под именем file~
А я просто скажу Спасибо автору за интересную статью: Р
ну, 1-е — вообще — то, первая DOS, которую MS впарили IBM разрабатывалась совсем не Гейтсом! Поэтому что там и как было изначально теперь не разобрать чьи просчёты как программистов, не с точки зрения маркетинга!
2 — думаете сама MS не пересматривала свой взгляд на такие вещи как перестрой архитектуры? Мне кажется что в Майкрософте и рады бы внести изменения, но они не могут!!! Потому что это означает конец обратной совместимости, палка в колесо как разработчикам софта так и, в большей степени, — конечным пользователям! Они ведут разработку другой ОС, не связанной с Windows — Microsoft Singularity, как вы, наверное уже знаете, где таких проблем, в принципе, не должно быть.
3 — пользуюсь на работе Windows Vista, дома — Windows 7, требования перезагрузки встречаю ооочень редко, только после обновления в основном, а большинство программ даже требуя перезагрузки запускаются и без оной (как пример сегодня ставил на рабочую станцию .Net 3.5 SP1, потребовала перезагрузки, но приложения использующие её запустились без таковой!).
2 — думаете сама MS не пересматривала свой взгляд на такие вещи как перестрой архитектуры? Мне кажется что в Майкрософте и рады бы внести изменения, но они не могут!!! Потому что это означает конец обратной совместимости, палка в колесо как разработчикам софта так и, в большей степени, — конечным пользователям! Они ведут разработку другой ОС, не связанной с Windows — Microsoft Singularity, как вы, наверное уже знаете, где таких проблем, в принципе, не должно быть.
3 — пользуюсь на работе Windows Vista, дома — Windows 7, требования перезагрузки встречаю ооочень редко, только после обновления в основном, а большинство программ даже требуя перезагрузки запускаются и без оной (как пример сегодня ставил на рабочую станцию .Net 3.5 SP1, потребовала перезагрузки, но приложения использующие её запустились без таковой!).
Вполне верно, DOS была продуктом Сиэттл Компьютерс, а у Майкрософта повидимому не было времени очень дорабатывать систему.
Вся история Майкрософта состоит из жестких дедлайнов. А это не полезно любой системе.
Вспомните, в какой спешке они создавали Windows, что бы успеть к выходу Макинтоша, как все последующие версии создавались в спешке. Из за спешки и глупостей поломали висту.
Вся история Майкрософта состоит из жестких дедлайнов. А это не полезно любой системе.
Вспомните, в какой спешке они создавали Windows, что бы успеть к выходу Макинтоша, как все последующие версии создавались в спешке. Из за спешки и глупостей поломали висту.
Требует перезагрузки только апдейты либо безопастности, либо quicktime, ну и ядра. Остальное разве требует?
не все. толко системные и секьюрити апдейты.
Так вот откуда растут ноги у «перезагружабельности» Windows! Познавательно, спасибо!
С учетом того, что решение имеет 20ти летнюю историю — рефакторинг производить немного поздновато?
С учетом того, что решение имеет 20ти летнюю историю — рефакторинг производить немного поздновато?
а почему mac os x часто тоже ребута после апдейтов просит?
Меня больше интересует связана ли «ошибка в ДНК» системы с «ошибкой в ДНК» людей, которые пишут под нее приложения и всячески способствуют ее распространению…
Money, money, money… Вы думаете, работники ВАЗа задумываются над тем, что они делают…
Есть работа, а есть религия.
Есть работа, а есть религия.
Т.е. самая популярная ОС совершивашая революцию в использовании персональных компьютеров написана людьми с «ошибкой в ДНК». Не ошибаются только те, кто ничего не делают :) А распространение она получила сугубо благода магии Вуду и жертвоприношениям младенцев? Видимо, нужно было сидеть в консоли, плясать с бубном вокруг каждой программы, а софт писать сугубо на кошерном C.
Не они совершили эту революцию…
Но зато они хорошо на ней заработали! Собственно чего у Microsoft не отнять — так это умения доводить до ума чужие идеи и получать на них прибыль. А что реализация получается хуже чем у оригинала — так это путём грамотного маркетинга несложно компенсировать…
Сравните Microsoft Word и Wordperfect, сравните MacOS и Windows, сравните что угодно — и увидите что всё что делает Microsoft хуже чем то, что делают другие, но оно появляется на рынке чуть раньше, стоит чуть дешевле, выглядит чуток покрасивше или просто лучше работает с другими технологиями, разработанными Microsoft — за счёт чего и завоёвывает популярность. Причём зачастую определяющим фактором является последний.
Почему с дизайном файловых систем что-либо должно быть по-другому?
Сравните Microsoft Word и Wordperfect, сравните MacOS и Windows, сравните что угодно — и увидите что всё что делает Microsoft хуже чем то, что делают другие, но оно появляется на рынке чуть раньше, стоит чуть дешевле, выглядит чуток покрасивше или просто лучше работает с другими технологиями, разработанными Microsoft — за счёт чего и завоёвывает популярность. Причём зачастую определяющим фактором является последний.
Почему с дизайном файловых систем что-либо должно быть по-другому?
если коротко, то да :-)
может я ошибаюсь, но мне казалось, что основная проблема необходимости перезагрузки после установки ПО кроется не в свойствах файловой системы и системе разделения доступа к файлам, а в механизме dll (so в unix). Или я не прав?
А изменения в реестре? Нормально написанный софт вообще не волнует проблема dll.
я не большой знаток нутра Windows, но все таки куча софта делает изменения в реестре, и при этом не заставляет перезагружаться. Часто виста перегружается, когда ставит критические обновления, и обновляет она системные dll… в этом случае, если идет замена системных dll, разве есть другой способ обновления, без перезагрузки?
Я, наверное, неправильно выразился. Под софом имелся в виду прикладной, а не сама ОС.
>в этом случае, если идет замена системных dll, разве есть другой способ обновления, без перезагрузки?
Ну, в принципе, софт, запущенный после апдейта, может начинать пользоваться новой версией библиотеки. Запущенный до — жить со старой, загруженной в память. Зачем ребут? На всякий случай?
>в этом случае, если идет замена системных dll, разве есть другой способ обновления, без перезагрузки?
Ну, в принципе, софт, запущенный после апдейта, может начинать пользоваться новой версией библиотеки. Запущенный до — жить со старой, загруженной в память. Зачем ребут? На всякий случай?
а если он сам обновил системную библиотеку? :) например, msvcrt*.dll? такого софта мало, но он все таки есть… кстати, мсофис, по-моему, не требует перезагрузки
Не требует.
>>а если он сам обновил системную библиотеку? :) например, msvcrt*.dll?
а зачем он это делает? если она ему нужна для работы — кладите в папочку с собой и пользуйтесь. или ностальгия по dll-hell? :)
>>а если он сам обновил системную библиотеку? :) например, msvcrt*.dll?
а зачем он это делает? если она ему нужна для работы — кладите в папочку с собой и пользуйтесь. или ностальгия по dll-hell? :)
Какая разница кто и что обновил? Принцип тот же: что было запущено пока старая версия была «жива» — использует старую версию библиотеки, что после — уже новую. Могут пострадать только программы, которые постоянно загружают и выгружают библиотеки — но их не так много.
за прошедший год не было ни единого разрыва, ни единого ребута, ни единой перезагрузки приложений… было установлено 10 новых версий системной библиотеки… только вот память стала подводить — её всё меньше и меньше… ибо запущенные 20 приложений юзают 10 её версий одновременно и они, каким-то чудесным и непостижимым образом, друг с другом совершенно не конфликтуют…
10 версий системной библиотеки — это порядка 10MB памяти (если считать только «горячий» код, загруженный в память). Вы реально верите что вы почувствуете потерю такого количества памяти на компьютере где её объёмы меряются гигабайтами? И да — ничто ни с чем не конфликтует. И ничего непостижимого тут нет. Эти 10 версий отличаются друг от друга минимально: там функция исправлена, тут функция добавлена. Вам не нужно ждать пока изменений накопится дофига и больше или собирать ежемесячные сборники обновлений, чтобы обновлять системные библиотеки: если обнаружена ошибка, исправь, не жди!
нет, не так. 10 версий системной библиотеки — это в 10 раз увеличившееся потребление памяти. а библиотека в системе не одна — их много. и если не думать о мегабайтах — гигабайтов начинает быстро нехватать.
новые версии — это далеко не только латание дыр.
новые версии — это далеко не только латание дыр.
а библиотека в системе не одна — их многоЭто уменьшает проблему, а не увеличивает.
10 версий системной библиотеки — это в 10 раз увеличившееся потребление памятиС чего вдруг? Если в вашей системе код занимает большую часть памяти, то вы что-то делаете не так. В большинстве современных систем код занимает не так много, основная часть — это данные. Плюс большинство библиотек после 10 upgrade'ов будут иметь в памяти 2-3 версии, а не 10. Ибо чтобы у вас получилось 10 версий библиотеки вам нужно как минимум 10 программ, которые перезапускаются в разное время. Что это за программы и откуда у вас в системе образовался такой бардак? Обычно речь идёт в /sbin/init и тому подобных демонах (которые запускаются один раз и работают до перезагрузки системы), обычных демонах (типа MySQL и Apache), которые перезапускаются скопом после обновления библиотек и программах, которые запускаются из скриптов. Итого — 2-3 версии библиотеки и то если вам сильно не повезёт.
и если не думать о мегабайтах — гигабайтов начинает быстро нехватать.Насколько быстро? Вы проводили измерения? Некоторые библиотеки обновляются часто (10-20 раз в год), но среднее количество обновлений — весьма мало (пресловутый закон Паретто), так что ваша проблема — высосана из пальца.
новые версии — это далеко не только латание дыр.Та же самая история. 80-90% «новых» версий — это именно латание дыр. А в тех редких случаях когда версия кардинально отличается — можно и систему перезагрузить. Цель ведь состоит не в том, чтобы избежать перезагрузок любой ценой, а чтобы снизить потери от них! Каждая перезагрузка — это потеря времени, сил и денег, но если для отказа от перезагрузки требуется «горы свернуть» — то можно систему и перезагрузить, криминала тут нет. Простое решение используемое в *nix-системах позволяет отказаться от 90% перезагрузок легко и до 99% — если в вашем случае перезагрузки — действительно большая проблема, но отказ от 100% перезагрузок на повестке дня не стоит.
Странно, у меня наоборот ощущение, что суси линукс требует перезагрузку намного чаще, чем просила бы виста. А в висте перезагрузка нужна только на апдейты, которые ставятся автоматом и несрочно, соотвественно ненапряжно.
На что сузя просит ребута? Я серьезно спрашиваю, ибо последний раз видел ее во времена 8.0
Ну, на апдейты из SLED10 репозитория вообще часто требует ребута. Например пытался тут вебкамеру подключить, тоже ребут потребовался. С русификацией когда игрался, тоже ребут часто требовался, абсолютно для меня в удивительных местах. Еще какие-то мелочи, которые сейчас не вспомню. Например, изменение разрешения экрана внешнего монитора, тоже часто криво проходит, только ребут спасает.
Какието такие базовые вещи, которые в винде в жисть не подумаешь, что ребута потребовать могут.
Какието такие базовые вещи, которые в винде в жисть не подумаешь, что ребута потребовать могут.
жесть какая. энтерпрайзненько — ребутаться ради modprobe.
Ну вот сегодняшний практический пример, ставлю я алсу.
www.linlap.com/wiki/Configuring+the+audio+and+updating+ALSA+for+SuSE-OpenSuSE+10.3#configuring+the+audio+and+updating+alsa+for+suse-opensuse+10.3
Вот мне как пользователю удивительно, что тут необходим рестарт.
www.linlap.com/wiki/Configuring+the+audio+and+updating+ALSA+for+SuSE-OpenSuSE+10.3#configuring+the+audio+and+updating+alsa+for+suse-opensuse+10.3
Вот мне как пользователю удивительно, что тут необходим рестарт.
Если кто-то написал, что рестарт нужен — это ещё не говорит о том, что он действительно нужен.
Тут на Хабре тоже кто-то советовал после сборки модуля на wifi перезапускать иксы — но это же не говорит о том, что этот рестарт необходим ;)
Я уже молчу про make install в пакетном дистрибутиве, что лично меня заставляет усомниться в квалификации автора статьи по приведённой Вами ссылке.
Тут на Хабре тоже кто-то советовал после сборки модуля на wifi перезапускать иксы — но это же не говорит о том, что этот рестарт необходим ;)
Я уже молчу про make install в пакетном дистрибутиве, что лично меня заставляет усомниться в квалификации автора статьи по приведённой Вами ссылке.
При обновлении ядра убунта говорит: «ну, как бы эта… Можно и перезагрузиться» :) А можно и не перезагрузиться :) Можешь работать на прежнем ядре сколько влезет.
Я обычно когда приходит обновление ядра просто его ставлю, а загружаюсь в него уже только на следующий день.
Я обычно когда приходит обновление ядра просто его ставлю, а загружаюсь в него уже только на следующий день.
Помнится, на рабочем сервере переразбивал(изменял размеры, добавлял новые разделы) несколько разделов.
Перезагрузку не пришлось делать.
Так что не вижу причин перезагрузки linux, кроме как смена ядра.
Перезагрузку не пришлось делать.
Так что не вижу причин перезагрузки linux, кроме как смена ядра.
Есть технологии, позволяющие и сменить ядро на ходу.
Ресайзить смонтированную файлуху иногда опасно.
а и не получится )
ресайзил, предварительно отмонтировав
ресайзил, предварительно отмонтировав
Online resizer есть только для некоторых файловых систем. Btrfs обещает решить эту проблему, но когда она ещё выйдет…
А на AIX это всё работало уже 10 лет (а может и 20 — я не помню сколько тел было железяке в которой мы «на ходу» меняли винт) назад…
А на AIX это всё работало уже 10 лет (а может и 20 — я не помню сколько тел было железяке в которой мы «на ходу» меняли винт) назад…
XFS _надо_ ресайзить смонтированой! The filesystem must be mounted to be grown.
Да чего тут разграгольствовать?! Автору спасибо за статью, под утреннюю чашку кофе хорошо легла. В программерской деятельности не сталкивался с необхожимостью ребута, но, конечно наблюдал этот эффект…
P.S. Так было, есть и будет Microsoft — позади планеты всей. Только и умеют, что совать нос в прибыльные отрасли, каждый раз поража какой-то недоработкой. Я не то, чтобы критикую их. В конце-концов есть же альтернативы… Но нехорошо, лидер индустрии и каждый раз тапком в г****. Вот если бы Google так делала, вот бы шороху было… :)
P.S. Так было, есть и будет Microsoft — позади планеты всей. Только и умеют, что совать нос в прибыльные отрасли, каждый раз поража какой-то недоработкой. Я не то, чтобы критикую их. В конце-концов есть же альтернативы… Но нехорошо, лидер индустрии и каждый раз тапком в г****. Вот если бы Google так делала, вот бы шороху было… :)
тсссс. На хабре микрософт сообщество сильное (ну или как минимум активное), надо молчать и сидеть в подполье. :) Улыбайтесь!
Слышали слово «Singularity»? Это оно. Переписано с нуля. Только весь софт не совместим и нужно переписывать заново. Предложишь такое пользователям — все разбегутся. Скажут хотим чтобы работали наши старые программы.
Наверное самый поучительный пример.
отличный холиварный топик. так и хочется у каждого спросить, под каой ОС он тролит.
и про «миллионные убытки» совсем непонятно.
и про «миллионные убытки» совсем непонятно.
КГАМ, не читал.
Думаю, что Майкрософт поступит правильно, резко оторвав задницу от разработки того самого Windows, за который тянется хвост из Доса. Apple поступила очень резко по мнению многих, похоронив девятку, а вскоре и ее эмуляцию. Как выяснилось, это оказалось к лучшему. Черт знает, во что выльется Сингулярити, но думаю, что категорически отказавшись от «хвоста», а возможно и от совместимости, у них получится отличный продукт.
«не будет адалён»
опечатка
На тему холивара:
На компе стоит Mandriva, иногда после апдейтов просит перезагрузить иксы, ничего страшного в этом нет
На ноуте стоит виста, иногда требует ребута, но ничего, мне не жалко)
опечатка
На тему холивара:
На компе стоит Mandriva, иногда после апдейтов просит перезагрузить иксы, ничего страшного в этом нет
На ноуте стоит виста, иногда требует ребута, но ничего, мне не жалко)
Автор забыл сказать, что перезагрузка нужна в общем-то не для затирания файла (что можно сделать в любой ФС), а для того что бы все заинтересованные приложения получили обновленные версии файлов.
И никакой ошибки в работе с ФС нет — есть отдельные криворукие программисты, пишущие прикладной софт.
И никакой ошибки в работе с ФС нет — есть отдельные криворукие программисты, пишущие прикладной софт.
>Автор забыл сказать,
Нет, вы просто не поняли что он хотел сказать :)
>не для затирания файла (что можно сделать в любой ФС)
В том-то и дело, что нельзя. Эксклюзивно открытый файл нельзя затереть в любой нормальной системе, но в венде его ещё и нельзя подменить, поскольку у них файл == имя файла.
>а для того что бы все заинтересованные приложения получили обновленные версии файлов
Ага. И для этого достаточно создать новый файл с тем же именем (а старое имя удалить) — то есть подменить файл. Но венда этого делать не позволяет, поэтому приходится перегружаться.
Нет, вы просто не поняли что он хотел сказать :)
>не для затирания файла (что можно сделать в любой ФС)
В том-то и дело, что нельзя. Эксклюзивно открытый файл нельзя затереть в любой нормальной системе, но в венде его ещё и нельзя подменить, поскольку у них файл == имя файла.
>а для того что бы все заинтересованные приложения получили обновленные версии файлов
Ага. И для этого достаточно создать новый файл с тем же именем (а старое имя удалить) — то есть подменить файл. Но венда этого делать не позволяет, поэтому приходится перегружаться.
Я прекрасно все понял — автор считает, что принципы работы с ФС в одной ОС являются «багом».
Все претензии в итоге сводятся к тому, что нельзя подменить эксклюзивно открытый файл. Однако само по себе «можно» или «нельзя» это не плюс или минус конкретной ОС, это особенности ее реализации.
К примеру, замена эксклюзивно открытой библиотеки может привести к непредсказуемым сбоям. Приложение A имеет в памяти версию 1.0, а приложение B, запущенное позднее — версию 1.5. Что произойдет, если приложения взаимодействуют друг с другом? Правильно — НЛО его знает что…
Единственный способ корректно провести замену библиотеки во всех приложениях, это перезагрузка всех приложений. То есть — перезагрузка ОС.
Если у вас есть другое решение — предложите.
Все претензии в итоге сводятся к тому, что нельзя подменить эксклюзивно открытый файл. Однако само по себе «можно» или «нельзя» это не плюс или минус конкретной ОС, это особенности ее реализации.
К примеру, замена эксклюзивно открытой библиотеки может привести к непредсказуемым сбоям. Приложение A имеет в памяти версию 1.0, а приложение B, запущенное позднее — версию 1.5. Что произойдет, если приложения взаимодействуют друг с другом? Правильно — НЛО его знает что…
Единственный способ корректно провести замену библиотеки во всех приложениях, это перезагрузка всех приложений. То есть — перезагрузка ОС.
Если у вас есть другое решение — предложите.
Про то почему это не «особенность», а минус — в статье тоже описано. В вашем гипотетическом случае дело ограничется (возможно, а возможно и так пройдёт) рестартом этих двух приложений. При более чем двух последовательных инсталяциях в венде есть неслабый шанс получить вообще неработоспособную систему (перекроятся файлы из «очередей»). Бага там не только и не столько в необходимости перезагрузки на ровном месте, а именно этом.
«В вашем гипотетическом случае дело ограничется (возможно, а возможно и так пройдёт) рестартом этих двух приложений»
Не двух — а всех, так или иначе использующих библиотеку. В т.ч. системных сервисов — что по-сути и есть рестарт все системы.
«При более чем двух последовательных инсталяциях в венде есть неслабый шанс получить вообще неработоспособную систему „
Только эта проблема к ФС никакого отношения не имеет.
“Бага там не только и не столько в необходимости перезагрузки на ровном месте, а именно этом. „
Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей, а не тихая подмена исполняемых модулей без ведома приложених, их использующих
У вас есть другое решение? Поделитесь пожалуйста.
Не двух — а всех, так или иначе использующих библиотеку. В т.ч. системных сервисов — что по-сути и есть рестарт все системы.
«При более чем двух последовательных инсталяциях в венде есть неслабый шанс получить вообще неработоспособную систему „
Только эта проблема к ФС никакого отношения не имеет.
“Бага там не только и не столько в необходимости перезагрузки на ровном месте, а именно этом. „
Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей, а не тихая подмена исполняемых модулей без ведома приложених, их использующих
У вас есть другое решение? Поделитесь пожалуйста.
Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей, а не тихая подмена исполняемых модулей без ведома приложених, их использующих.Не пишите чепухи. Единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы — это писать модули так, чтобы версия 1.0 и версия 1.5 были совместимы. Если же этого нет, то кто гарантирует что ваше ненаглядное приложение A вообще сможет стартовать после замены библиотеки 1.0 на библиотеку 1.5?
У вас есть другое решение? Поделитесь пожалуйста.От вас жду того же — расскажите мне, идиоту, как перезагрузка сможет вдруг сделать библиотеку 1.5 совместимой с 1.0 если без перезагрузки она с ней несовместима. И как часто такое случается на практике.
«писать модули так, чтобы версия 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.
Именно поэтому нельзя обновлять систему постепенно, не закрывая работающие приложения. Обновить вы обновите — но стабильность под вопросом.
Речь не о взаимодействии приложения с модулями версии 1.0 и 1.5. Речь о взаимодействии ОДНОВРЕМЕННО ЗАГРУЖЕННЫХ модулей версии 1.0 и 1.5 с системой и друг с другом.
«расскажите мне, идиоту, как перезагрузка сможет вдруг сделать библиотеку 1.5 совместимой с 1.0 если без перезагрузки она с ней несовместима»
Вы неправильно поняли условия задачи. 1.5 совместима с 1.0 (иначе это не обновление, а хз что) — только вот приложение, в которое загружена 1.5, будет портить данные, передаваемые из приложения с модулем 1.0.
Именно поэтому нельзя обновлять систему постепенно, не закрывая работающие приложения. Обновить вы обновите — но стабильность под вопросом.
Вы неправильно поняли условия задачи. 1.5 совместима с 1.0 (иначе это не обновление, а хз что) — только вот приложение, в которое загружена 1.5, будет портить данные, передаваемые из приложения с модулем 1.0.То есть вы обеспечиваете совместимость ABI, но не совместимость с порождаемыми данными? Бред какой-то. В 90% (если не в 99%) случаев бывает наоборот. Ибо иметь 2, 3, да даже 10 библиотек в системе — не проблема (посмотрите на количество версий msvcrt в последних версиях Windows или на количество версий libdb в *nix), а вот данные — часто собираются годами.
Именно поэтому нельзя обновлять систему постепенно, не закрывая работающие приложения. Обновить вы обновите — но стабильность под вопросом.Когда вы обновляете библиотеки — стабильность всегда под вопросом. Но возможность сделать это «на ходу» позволяет (и очень часто позволяет) уменьшить downtime.
«То есть вы обеспечиваете совместимость ABI, но не совместимость с порождаемыми данными?»
Вы путаете внешний интерфейс библиотеки, и ее реализацию.
Внешний интерфейс очевидно не изменяется, обеспечивая обратную совместимость. Но вот реализация библиотеки может (и наверняка будет — мы же что-то обновили) иной.
И когда в системе взаимодействуют несколько разных реализаций одной и той же библиотеки (причем в роизвольных комбинациях) — жди беды.
«посмотрите на количество версий msvcrt в последних версиях Windows или на количество версий libdb в *nix»
Вы уходите в сторону — если библиотеки имеют разные имена, то никаких проблем с ФС нет в принципе. Не надо путать описанный мной сценарий с DLL-hell
«Но возможность сделать это «на ходу» позволяет (и очень часто позволяет) уменьшить downtime.»
Вы не поверите — возможность обновить библиотеку «на ходу» есть и в винде. Речь идет лишь о том, что это крайний случай, и подобные трюки необходимо использовать с большой осторожностью.
Вы путаете внешний интерфейс библиотеки, и ее реализацию.
Внешний интерфейс очевидно не изменяется, обеспечивая обратную совместимость. Но вот реализация библиотеки может (и наверняка будет — мы же что-то обновили) иной.
И когда в системе взаимодействуют несколько разных реализаций одной и той же библиотеки (причем в роизвольных комбинациях) — жди беды.
«посмотрите на количество версий msvcrt в последних версиях Windows или на количество версий libdb в *nix»
Вы уходите в сторону — если библиотеки имеют разные имена, то никаких проблем с ФС нет в принципе. Не надо путать описанный мной сценарий с DLL-hell
«Но возможность сделать это «на ходу» позволяет (и очень часто позволяет) уменьшить downtime.»
Вы не поверите — возможность обновить библиотеку «на ходу» есть и в винде. Речь идет лишь о том, что это крайний случай, и подобные трюки необходимо использовать с большой осторожностью.
Речь идет лишь о том, что это крайний случай, и подобные трюки необходимо использовать с большой осторожностью.Если это — крайний случай, то его никто не будет тестировать и отлаживать, а обновления будут копиться ибо нельзя же перезагружать комп каждый час! Так и до несовместимости можно дойти. Если же это штатный способ, который применяют миллионы — то об этом разработчики должны додуматься и сделать всё «как надо». Что вовсе не так сложно, как вам кажется.
Внешний интерфейс очевидно не изменяется, обеспечивая обратную совместимость. Но вот реализация библиотеки может (и наверняка будет — мы же что-то обновили) иной.С чего вдруг? Внутри процесса всегда работает одна версия библиотеки (загрузчик просто не будет загружать уже загруженную библиотеку), там конфликтов не будет, а если ваша библиотека имеет другой интерфейс с вшеним миром, то с какого перепугу она имеет тот же номер?
И когда в системе взаимодействуют несколько разных реализаций одной и той же библиотеки (причем в роизвольных комбинациях) — жди беды.
«Не двух — а всех, так или иначе использующих библиотеку. В т.ч. системных сервисов — что по-сути и есть рестарт все системы.»
Вы знаете, я много лет работаю на линуксе и описаное вами происходило от силы раза два, если происходило вообще. В конце-концов, можно и перезагрузиться, если очень надо, но для этого должны быть действительно веские причины, а не установка какого-нибудь банального драйвера принтера. Сейчас в линуксах даже ядро можно патчить без перезагрузок. Ну, ей богу, всё уже сто лет как есть и всё уже давно и прекрасно работает. Там выше кто-то писал, что перелез с кде3 на кде4 не выходя из кде. Вот это могучий человек! :)
«Только эта проблема к ФС никакого отношения не имеет. „
Верно. К ФС не имеет. Имеет отношение к баге в ДНК :).
“Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей»
Угу. А мужики-то и не знают. Это единственный способ гарантированно обеспечить стабильность венды, — это верно. Из-за бага. Все остальные прекрасно обходятся просто подменой библиотек и, если уж край как нужно, перезапуском отдельных сервисов.
«У вас есть другое решение? Поделитесь пожалуйста.»
Да, вроде бы, всё в статье и описано. Повторюсь — сейчас сделана даже возможность патчить ядро линукса без перезагрузки. Это может быть важно в продакшене. Где минутный простой на перезагрузку означает огромные убытки. Я вообще-то с трудом могу представить ситуацию когда это было бы необходимо, но раз сделали, значит это кому-то нужно. Можно просто работать, а можно бесконечно вздыхать о мнимой невозможности этого. Ради чего? Ради веры в сомнительную непогрешимость микросовта? :)
Вы знаете, я много лет работаю на линуксе и описаное вами происходило от силы раза два, если происходило вообще. В конце-концов, можно и перезагрузиться, если очень надо, но для этого должны быть действительно веские причины, а не установка какого-нибудь банального драйвера принтера. Сейчас в линуксах даже ядро можно патчить без перезагрузок. Ну, ей богу, всё уже сто лет как есть и всё уже давно и прекрасно работает. Там выше кто-то писал, что перелез с кде3 на кде4 не выходя из кде. Вот это могучий человек! :)
«Только эта проблема к ФС никакого отношения не имеет. „
Верно. К ФС не имеет. Имеет отношение к баге в ДНК :).
“Баги нет — потому что единственный способ ГАРАНТИРОВАННО обеспечить стабильность системы это как раз перезагрузка после обновления отдельных системных модулей»
Угу. А мужики-то и не знают. Это единственный способ гарантированно обеспечить стабильность венды, — это верно. Из-за бага. Все остальные прекрасно обходятся просто подменой библиотек и, если уж край как нужно, перезапуском отдельных сервисов.
«У вас есть другое решение? Поделитесь пожалуйста.»
Да, вроде бы, всё в статье и описано. Повторюсь — сейчас сделана даже возможность патчить ядро линукса без перезагрузки. Это может быть важно в продакшене. Где минутный простой на перезагрузку означает огромные убытки. Я вообще-то с трудом могу представить ситуацию когда это было бы необходимо, но раз сделали, значит это кому-то нужно. Можно просто работать, а можно бесконечно вздыхать о мнимой невозможности этого. Ради чего? Ради веры в сомнительную непогрешимость микросовта? :)
«Вы знаете, я много лет работаю на линуксе и описаное вами происходило от силы раза два»
Типа если у вас нет СПИД'а то предохраняться не нужно? Согласитесь, странная логика.
«В конце-концов, можно и перезагрузиться, если очень надо»
Вы готовы заниматься анализом исходных кодов обновления, дабы точно установить — нужна перезагрузка, или нет?
«установка какого-нибудь банального драйвера принтера»
Установка принтера в винде уже давно-давно не требует перезагрузок. Не знаете — не пишите.
«Ну, ей богу, всё уже сто лет как есть и всё уже давно и прекрасно работает»
И винде все прекрасно работает. Но речь про ФС.
«Все остальные прекрасно обходятся просто подменой библиотек и, если уж край как нужно, перезапуском отдельных сервисов»
Вы видимо не в курсе — народ массово перезапускает иксы (вместе со ВСЕМИ приложениями) после обновлений, и т.п.
Особенно умиляет показательно-небрежное отношение к своему времени — мол, если жахнет, то и фиг с ним.
«Это может быть важно в продакшене. Где минутный простой на перезагрузку означает огромные убытки. „
А теперь подумайте, сколько может стоить получасовое загаживание базы мусором вместо данных из-за подмены библиотеки, и вытекающих отсюда проблем.
Мне повезло — на нашем движке работает mtv.com и иже с ним. Поэтому последствия “простой подмены» и дикий вой после развала продакшена мне хорошо знаком.
Типа если у вас нет СПИД'а то предохраняться не нужно? Согласитесь, странная логика.
«В конце-концов, можно и перезагрузиться, если очень надо»
Вы готовы заниматься анализом исходных кодов обновления, дабы точно установить — нужна перезагрузка, или нет?
«установка какого-нибудь банального драйвера принтера»
Установка принтера в винде уже давно-давно не требует перезагрузок. Не знаете — не пишите.
«Ну, ей богу, всё уже сто лет как есть и всё уже давно и прекрасно работает»
И винде все прекрасно работает. Но речь про ФС.
«Все остальные прекрасно обходятся просто подменой библиотек и, если уж край как нужно, перезапуском отдельных сервисов»
Вы видимо не в курсе — народ массово перезапускает иксы (вместе со ВСЕМИ приложениями) после обновлений, и т.п.
Особенно умиляет показательно-небрежное отношение к своему времени — мол, если жахнет, то и фиг с ним.
«Это может быть важно в продакшене. Где минутный простой на перезагрузку означает огромные убытки. „
А теперь подумайте, сколько может стоить получасовое загаживание базы мусором вместо данных из-за подмены библиотеки, и вытекающих отсюда проблем.
Мне повезло — на нашем движке работает mtv.com и иже с ним. Поэтому последствия “простой подмены» и дикий вой после развала продакшена мне хорошо знаком.
>Типа если у вас нет СПИД'а то предохраняться не нужно? Согласитесь, странная логика.
Странная логика — надевать презерватив на огурец, как в том анекдоте.
>Вы готовы заниматься анализом исходных кодов обновления, дабы точно установить — нужна перезагрузка, или нет?
Ага. Вероятно, я что-то делаю не так. Всё работает, но я что-то делаю не так. Аминь.
>Установка принтера в винде уже давно-давно не требует перезагрузок. Не знаете — не пишите.
Вы попросту врёте. Позавчера ставил дома на венду драйвер принтера — перезагрузка :(. Потом обнаружил, что забыл поставить драйвер сканера — ещё раз :(. Кучу времени на это барахло бездарно убил :( :(
>Вы видимо не в курсе — народ массово перезапускает иксы (вместе со ВСЕМИ приложениями) после обновлений, и т.п.
Я реально не в курсе. И опять что-то делаю не так :). Кстати, при перезапуске иксов далеко не все приложения перезапускаются. Я бы даже сказал, что только очень некоторые из запущенных у меня.
>Особенно умиляет показательно-небрежное отношение к своему времени — мол, если жахнет, то и фиг с ним.
Особо умиляет показательно-небрежное отношение к своему времени — перезагружаться после каждого драйвера принтера :(. Мои перезагрузки на работе — от ядра до ядра. Тратить время на всякий бред мне просто жалко.
>А теперь подумайте, сколько может стоить получасовое загаживание базы мусором вместо данных из-за подмены библиотеки, и вытекающих отсюда проблем.
Сломать палец можно даже ковыряя в носу. Если очень постараться. Но… зачем???
>Поэтому последствия “простой подмены» и дикий вой после развала продакшена мне хорошо знаком.
Наверное, это один из показателей качества вашей системы. :) А вы… это… перезагружаете сервера, после того, как обновляете гифчики на сервере? Это же ЕДИНСТВЕННЫЙ гарантированый способ убедиться, что ваш новый гифчик совместим со всеми приложениями, его использующими.
Странная логика — надевать презерватив на огурец, как в том анекдоте.
>Вы готовы заниматься анализом исходных кодов обновления, дабы точно установить — нужна перезагрузка, или нет?
Ага. Вероятно, я что-то делаю не так. Всё работает, но я что-то делаю не так. Аминь.
>Установка принтера в винде уже давно-давно не требует перезагрузок. Не знаете — не пишите.
Вы попросту врёте. Позавчера ставил дома на венду драйвер принтера — перезагрузка :(. Потом обнаружил, что забыл поставить драйвер сканера — ещё раз :(. Кучу времени на это барахло бездарно убил :( :(
>Вы видимо не в курсе — народ массово перезапускает иксы (вместе со ВСЕМИ приложениями) после обновлений, и т.п.
Я реально не в курсе. И опять что-то делаю не так :). Кстати, при перезапуске иксов далеко не все приложения перезапускаются. Я бы даже сказал, что только очень некоторые из запущенных у меня.
>Особенно умиляет показательно-небрежное отношение к своему времени — мол, если жахнет, то и фиг с ним.
Особо умиляет показательно-небрежное отношение к своему времени — перезагружаться после каждого драйвера принтера :(. Мои перезагрузки на работе — от ядра до ядра. Тратить время на всякий бред мне просто жалко.
>А теперь подумайте, сколько может стоить получасовое загаживание базы мусором вместо данных из-за подмены библиотеки, и вытекающих отсюда проблем.
Сломать палец можно даже ковыряя в носу. Если очень постараться. Но… зачем???
>Поэтому последствия “простой подмены» и дикий вой после развала продакшена мне хорошо знаком.
Наверное, это один из показателей качества вашей системы. :) А вы… это… перезагружаете сервера, после того, как обновляете гифчики на сервере? Это же ЕДИНСТВЕННЫЙ гарантированый способ убедиться, что ваш новый гифчик совместим со всеми приложениями, его использующими.
Да? Если я хочу обновить к примеру user32.dll, который подгружен большинством процессов — мне это не удастся. Потому что он подгружен большинством процессов :)
А вот если бы было так как в Linux, то: мы удаляем старый user32.dll, но он остается открыт уже запущенными программами. А потом вместо него записываем новый.
Таким образом новозапущеные программы будут использовать новый файл, а те который уже работают — будут работать со старым.
Естественно, если в старом файле была какая-то ошибка связанная с безопасностью — то лучше перезагрузить систему, что бы все программы использовали новый файл.
Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё?
А вот если бы было так как в Linux, то: мы удаляем старый user32.dll, но он остается открыт уже запущенными программами. А потом вместо него записываем новый.
Таким образом новозапущеные программы будут использовать новый файл, а те который уже работают — будут работать со старым.
Естественно, если в старом файле была какая-то ошибка связанная с безопасностью — то лучше перезагрузить систему, что бы все программы использовали новый файл.
Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё?
«Таким образом новозапущеные программы будут использовать новый файл, а те который уже работают — будут работать со старым. „
Можно ли гарантировать стабильную работу системы в этом случае? Очевидный ответ — “нет», т.к. при тестировании обновлений невозможно проверить все возможные сочетания версий загруженных одновременно разными приложениями.
«Естественно, если в старом файле была какая-то ошибка связанная с безопасностью — то лучше перезагрузить систему, что бы все программы использовали новый файл»
Постарайтесь понять — что наличие в памяти двух (трех, десяти — в зависимости от количества запущенных установщиков) версий одной библиотеки в памяти это ОГРОМНАЯ проблема. Не столько с безопасностью, сколько со стабильностью.
«Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё? „
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.
Поэтому при любых изменениях в коде любой проект всегда полностью пересобирается, и на нем заново прогоняются тесты.
Можно ли гарантировать стабильную работу системы в этом случае? Очевидный ответ — “нет», т.к. при тестировании обновлений невозможно проверить все возможные сочетания версий загруженных одновременно разными приложениями.
«Естественно, если в старом файле была какая-то ошибка связанная с безопасностью — то лучше перезагрузить систему, что бы все программы использовали новый файл»
Постарайтесь понять — что наличие в памяти двух (трех, десяти — в зависимости от количества запущенных установщиков) версий одной библиотеки в памяти это ОГРОМНАЯ проблема. Не столько с безопасностью, сколько со стабильностью.
«Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё? „
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.
Поэтому при любых изменениях в коде любой проект всегда полностью пересобирается, и на нем заново прогоняются тесты.
Очевидный ответ — “нет», т.к. при тестировании обновлений невозможно проверить все возможные сочетания версий загруженных одновременно разными приложениямиЕсли исходить из этого критерия то стабильную работу системы вообще никогда нельзя гарантировать.
Постарайтесь понять — что наличие в памяти двух (трех, десяти — в зависимости от количества запущенных установщиков) версий одной библиотеки в памяти это ОГРОМНАЯ проблема.Почему вдруг?
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.В этом случае менять старый модуль на новый вообще нельзя и вся обсуждаемая проблема не стоит выеденного яйца.
Поэтому при любых изменениях в коде любой проект всегда полностью пересобирается, и на нем заново прогоняются тесты.Тесты заново прогнать — это завсегда полезно, но пересобирать-то зачем? Это ни в какие ворота не лезет — так только Microsoft делает и то только для Windows. При изменении системной библиотеки в Windows MS Office и MS Visual Studio никто заново не пересобирает.
>«Но если мы его обновляем просто из-за каких-то новых функций — то зачем перезапускать всё?»
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.
Извините, а как в этом случае поможет перезагрузка? Если СТАРЫЕ функции перестали работать по-старому, то при перезагрузке (и, соответственно, задействовании новой версии с поломанными старыми функциями) всё как раз гарантированно сломается :)
А вот если старые функции работают как и прежде, то всё будет работать и без перезагрузки, тихой подменой библиотеки, в то время как уже запущенные программы продолжают использовать старую версию.
Потому что у вас нет гарантии, что СТАРЫЕ функции в данном модуле продолжают работать так же, как и раньше.
Извините, а как в этом случае поможет перезагрузка? Если СТАРЫЕ функции перестали работать по-старому, то при перезагрузке (и, соответственно, задействовании новой версии с поломанными старыми функциями) всё как раз гарантированно сломается :)
А вот если старые функции работают как и прежде, то всё будет работать и без перезагрузки, тихой подменой библиотеки, в то время как уже запущенные программы продолжают использовать старую версию.
«Извините, а как в этом случае поможет перезагрузка?»
Речь идет о том, что в памяти одновременно живут старая и новая библиотеки. Их реализация может отличаться, равно как могут отличаться внутренние форматы данных, наборы вспомогательных компонентов и т.п.
Как следствие — разного рода конфликты, ошибки при доступе к общим ресурсам, и т.п.
«всё будет работать и без перезагрузки, тихой подменой библиотеки, в то время как уже запущенные программы продолжают использовать старую версию.»
Библиотека существует не в вакууме. Она обращается к ОС, создает объекты ядра, выделяет память, что-то пишет в нее и т.п. И чем сложнее библиотека, тем больше вероятность коллизий.
Простейший пример (если вы немножко в теме) — базовый адрес загрузки библиотеки в винде. Для многих нужд внутри исполняемого модуля требуются не просто относительные адреса (типа «прыгнуть отсюда вперед на 35 байт»), а полноценные логические адреса (для x86 — 32-х битные) — по которым расположен определенный код, либо данные. Поэтому при компиляции исполняемого модуля необходимо указывать его базовый адрес, скажем 0x40000000, по которому модуль будет загружен в память. В этом случае данные, расположенные по смещению 0x200 относительно начала файла, будут иметь виртуальный адрес 0x40000200.
Все будет идеально работать до тех пор, пока ОС может загрузить модуль по этому адресу. Но что делать, если по нему уже загружен другой модуль? Ведь если наша библиотека получит базовый адрес 0x50000000, то сгенерированный компилятором адрес 0x40000200 будет мягко скажем навалидным…
Для решения этой проблемы исполняемый файл МОЖЕТ иметь специальную секцию, содержимое которой после загрузки по другому базовому адресу позволит ОС «подкрутить» адреса внутри модуля, дабы избежать проблем.
Однако если библиотеку делал недобросовстный программист, решивший сэкономить место с помощью купирования «ненужной» секции, или в ней пропишет себя вирус, то мы получаем бомбу с часовым механизмом. Когда произойдет «бум» — сказать сложно.
При этом лично у вас все может быть ок, я и сам (каюсь, грешен) часто делал библиотеки без секции .reloc — ну удобнее мне так, удобнее (я просто ставил хитрый базовый адрес, но не об этом речь). Но на машинах пользователей все может жахнуть в любой момент.
Речь идет о том, что в памяти одновременно живут старая и новая библиотеки. Их реализация может отличаться, равно как могут отличаться внутренние форматы данных, наборы вспомогательных компонентов и т.п.
Как следствие — разного рода конфликты, ошибки при доступе к общим ресурсам, и т.п.
«всё будет работать и без перезагрузки, тихой подменой библиотеки, в то время как уже запущенные программы продолжают использовать старую версию.»
Библиотека существует не в вакууме. Она обращается к ОС, создает объекты ядра, выделяет память, что-то пишет в нее и т.п. И чем сложнее библиотека, тем больше вероятность коллизий.
Простейший пример (если вы немножко в теме) — базовый адрес загрузки библиотеки в винде. Для многих нужд внутри исполняемого модуля требуются не просто относительные адреса (типа «прыгнуть отсюда вперед на 35 байт»), а полноценные логические адреса (для x86 — 32-х битные) — по которым расположен определенный код, либо данные. Поэтому при компиляции исполняемого модуля необходимо указывать его базовый адрес, скажем 0x40000000, по которому модуль будет загружен в память. В этом случае данные, расположенные по смещению 0x200 относительно начала файла, будут иметь виртуальный адрес 0x40000200.
Все будет идеально работать до тех пор, пока ОС может загрузить модуль по этому адресу. Но что делать, если по нему уже загружен другой модуль? Ведь если наша библиотека получит базовый адрес 0x50000000, то сгенерированный компилятором адрес 0x40000200 будет мягко скажем навалидным…
Для решения этой проблемы исполняемый файл МОЖЕТ иметь специальную секцию, содержимое которой после загрузки по другому базовому адресу позволит ОС «подкрутить» адреса внутри модуля, дабы избежать проблем.
Однако если библиотеку делал недобросовстный программист, решивший сэкономить место с помощью купирования «ненужной» секции, или в ней пропишет себя вирус, то мы получаем бомбу с часовым механизмом. Когда произойдет «бум» — сказать сложно.
При этом лично у вас все может быть ок, я и сам (каюсь, грешен) часто делал библиотеки без секции .reloc — ну удобнее мне так, удобнее (я просто ставил хитрый базовый адрес, но не об этом речь). Но на машинах пользователей все может жахнуть в любой момент.
Речь идет о том, что в памяти одновременно живут старая и новая библиотеки.Нет двух библиотек в памяти «одновременно». Вернее есть — но в памяти разных процессов. Один процесс работает со старой библиотекой и только с ней, другой — с новой и только с ней. Откуда конфликты?
Однако если библиотеку делал недобросовстный программист, решивший сэкономить место с помощью купирования «ненужной» секции, или в ней пропишет себя вирус, то мы получаем бомбу с часовым механизмом. Когда произойдет «бум» — сказать сложно.Если у вас вирусы в системе, то вам уже ничего не поможет. Что будет если обновление поместит по адресу 0x40000000 user.dll? И вашу библиотеку придётся перемещать несмотря на перезагрузку?
При этом лично у вас все может быть ок, я и сам (каюсь, грешен) часто делал библиотеки без секции .reloc — ну удобнее мне так, удобнее (я просто ставил хитрый базовый адрес, но не об этом речь). Но на машинах пользователей все может жахнуть в любой момент.Ну если вы хотите ездить на машине без тормозов и руля, то это не повод заявлять что все дороги должны быть только прямыми — и шоб никаких перекрёстков! Во-первых я не понял причём тут проблемы с базовыми адресами (две библиотеки в память одного процесса никогда не попадают), а во-вторых от использования базовых адресов в Unix мире все уже давно отказались (Linux — 1996й год, FreeBSD — 1998й год, NetBSD — 2000й год)…
1. запускаем программу А работающему с свн 1.4 и натравливаем на рабочую копию.
2. обновляем свн до 1.5.
3. запускаем программу Б, которая заюзает свн 1.5 и конвертнёт рабочую копию в новый формат.
4.…
5. фейл.
2. обновляем свн до 1.5.
3. запускаем программу Б, которая заюзает свн 1.5 и конвертнёт рабочую копию в новый формат.
4.…
5. фейл.
И не смотря на ошибку в ДНК, это привело не к миллионым убыткам, а к миллиардным доходам. Ведь главное — маркетинг :)
Столько пафоса, что в заголовке, что в статье. У вас есть какие-то цифры об этих мистических миллионых убытках?
Представьте себе, что вы пишите диплом в ворде и написали уже более 9000 страниц, но до сих пор не сохраняли сохраняли документ и вот какая-то сторонняя программа или виндовс апдейт хочет обновить системную dll-ку, которую изпользует в данных момент ворд (например какую-нибудь функцию из неё импортирует) и опа — дллка заменена, но ворд ничего об этом не знает и пытается вызвать ту же самую функцию, а эта функция возможно тоже изменена и возвращает несколько иной результат или принимает другое количество параметров в итоге имеем креш ворда вместе с документом.
Это простой пример того, что поведение системы может стать непредсказуемым если всем подряд дать заменять используемые в данный момент файлы.
Другое дело, что можно было бы дать пользователю решать — заменять ли дллки например с помощью мессадж бокса «Заменить файл, который используется в данный момент?», но видимо до этого ещё не скоро дойдет.
Представьте себе, что вы пишите диплом в ворде и написали уже более 9000 страниц, но до сих пор не сохраняли сохраняли документ и вот какая-то сторонняя программа или виндовс апдейт хочет обновить системную dll-ку, которую изпользует в данных момент ворд (например какую-нибудь функцию из неё импортирует) и опа — дллка заменена, но ворд ничего об этом не знает и пытается вызвать ту же самую функцию, а эта функция возможно тоже изменена и возвращает несколько иной результат или принимает другое количество параметров в итоге имеем креш ворда вместе с документом.
Это простой пример того, что поведение системы может стать непредсказуемым если всем подряд дать заменять используемые в данный момент файлы.
Другое дело, что можно было бы дать пользователю решать — заменять ли дллки например с помощью мессадж бокса «Заменить файл, который используется в данный момент?», но видимо до этого ещё не скоро дойдет.
но ворд ничего об этом не знает и пытается вызвать ту же самую функциюи, представьте себе, он вызовет ту же самую функцию. Ибо у него открыта старая версия dll-ки и ни о каких новых фичах он ничего не узнает до того, как его перезапустят. Или вы о том, что он может закрыть dll'ку, потом открыть её и вот тут как раз получить облом? Ну так это и в Windows возможно: если программа dll'ку закрыла — то её и подменить можно в любой OS, даже в Windows.
Это простой пример того, что поведение системы может стать непредсказуемым если всем подряд дать заменять используемые в данный момент файлы.Это простой пример показывает что бывает если статьи читать не вчитываясь и не думая.
«представьте себе, он вызовет ту же самую функцию. Ибо у него открыта старая версия dll-ки и ни о каких новых фичах он ничего не узнает до того, как его перезапустят.»
Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Как следствие — вылет приложения и потеря данных.
Странно, такое впечатление что подавляющее кол-во оставляющих комменты либо никогда не занимались программированием, либо никогда не работали с большими проектами, где за трюки в стиле «да я же одну библиотеку изменил, и все» бьют по рукам. Очень, очень больно.
Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Как следствие — вылет приложения и потеря данных.
Странно, такое впечатление что подавляющее кол-во оставляющих комменты либо никогда не занимались программированием, либо никогда не работали с большими проектами, где за трюки в стиле «да я же одну библиотеку изменил, и все» бьют по рукам. Очень, очень больно.
>Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Ерунда какая-то. Если старая версия библиотеки ещё загружена, то она и будет использовать ещё свой старый компонент. Или это такое хитрое приложение, которое только тем и занимается, что загружает-выгружает библиотеки? Тогда да, против лома нет приёма. :)
>Как следствие — вылет приложения и потеря данных.
А если бы он вёз патроны? А если одно обновление произошло, а второе — нет? Вы ведь говорите о двух обновлениях?
>Странно, такое впечатление что подавляющее кол-во оставляющих комменты
Странно, такое впечатление, что вы только в досе работали. Причём с какими-то безумными проектами, у которых библиотеки новых версий абсолютно несовместимы со старыми и нет отслеживания зависимостей. Это баг, батенька. В днк ваших проектировщиков. Они вас больно бьют по рукам, вероятно, потому, что их больно били по голове и что-то там сдвинули. :)
Ерунда какая-то. Если старая версия библиотеки ещё загружена, то она и будет использовать ещё свой старый компонент. Или это такое хитрое приложение, которое только тем и занимается, что загружает-выгружает библиотеки? Тогда да, против лома нет приёма. :)
>Как следствие — вылет приложения и потеря данных.
А если бы он вёз патроны? А если одно обновление произошло, а второе — нет? Вы ведь говорите о двух обновлениях?
>Странно, такое впечатление что подавляющее кол-во оставляющих комменты
Странно, такое впечатление, что вы только в досе работали. Причём с какими-то безумными проектами, у которых библиотеки новых версий абсолютно несовместимы со старыми и нет отслеживания зависимостей. Это баг, батенька. В днк ваших проектировщиков. Они вас больно бьют по рукам, вероятно, потому, что их больно били по голове и что-то там сдвинули. :)
>никогда не работали с большими проектами, где за трюки в стиле «да я же одну библиотеку изменил, и все» бьют по рукам. Очень, очень больно.
Между проектом в разработке и выпущенным продуктом ОГРОМНАЯ разница. А если ваш продукт выдает такие трюки в виде несовместимости со старой версией, но при этом затирает эту старую версию, то конечно нужно бить по рукам таких разработчиков… и вообще их разработками не пользоваться
Неужели не понятно, при проблемах несовместимости возможно свой файл на 9000 и еще 500 страниц вы сохраните(хотя механизм *nix тоже даст возможность это сделать), но после перезагрузки тоже нифига не будет работать
> Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Вот чтоб такого не было в *nix существует механизм контроля зависимостей. Да и вообще эта ситуёвина создаст проблемы не зависимо от перезагружаемости
Между проектом в разработке и выпущенным продуктом ОГРОМНАЯ разница. А если ваш продукт выдает такие трюки в виде несовместимости со старой версией, но при этом затирает эту старую версию, то конечно нужно бить по рукам таких разработчиков… и вообще их разработками не пользоваться
Неужели не понятно, при проблемах несовместимости возможно свой файл на 9000 и еще 500 страниц вы сохраните(хотя механизм *nix тоже даст возможность это сделать), но после перезагрузки тоже нифига не будет работать
> Вот только беда — обновилась еще один компонент в системе, который вообще не тестировался на совместимость со старой версией библиотеки.
Вот чтоб такого не было в *nix существует механизм контроля зависимостей. Да и вообще эта ситуёвина создаст проблемы не зависимо от перезагружаемости
Странно, такое впечатление что подавляющее кол-во оставляющих комменты либо никогда не занимались программированием, либо никогда не работали с большими проектами, где за трюки в стиле «да я же одну библиотеку изменил, и все» бьют по рукам. Очень, очень больно.Всё верно — такие вещи нужно проверять на тестовых системах, а потом уже ставить то же обновление на 10'000 компьютеров. Но перезагружаться-то зачем?
Ещё раз: установка новой версии компонента достаточно часто приводит к проблемам — и в Windows и в Linux. Но вот такого, чтобы проблемы после этого в Linux лечились перезагрузкой — практически никогда не бывает. Не нужно бороться с ветряными мельницами. Ваша проблема — надуманна, на практике её не существует.
> Это простой пример показывает что бывает если статьи читать не вчитываясь и не думая.
Это да. Я пропустил абзац из своих размышлений, поэтому получилась каша. Итак:
Вы пишите, что в винде используемый в данный момент файл заменить невозможно, т.к. «ошибки в ДНК» и т.д. — строго говоря это не совсем верно, потому что можно найти приложение использующее этот файл — «засуспендить» его и удалить хендл на файл, который необходимо заменить. Именно так работает утилитка Unlocker и после этого то же самое приложение «разсуспендить» и оно подхватит уже новую библиотечку без перезапуска. И в принципе в МС могли такую штуку реализовать вместо всем известного PendingFileRenameOperations.
А теперь можно вставлять содержимое моего комментария выше.
Такие дела.
Это да. Я пропустил абзац из своих размышлений, поэтому получилась каша. Итак:
Вы пишите, что в винде используемый в данный момент файл заменить невозможно, т.к. «ошибки в ДНК» и т.д. — строго говоря это не совсем верно, потому что можно найти приложение использующее этот файл — «засуспендить» его и удалить хендл на файл, который необходимо заменить. Именно так работает утилитка Unlocker и после этого то же самое приложение «разсуспендить» и оно подхватит уже новую библиотечку без перезапуска. И в принципе в МС могли такую штуку реализовать вместо всем известного PendingFileRenameOperations.
А теперь можно вставлять содержимое моего комментария выше.
Такие дела.
Эм… вы видимо не совсем поняли. Если вы открыли dll, то она для вас останется старой, той которую вы открыли, ее замена в файловой системе вас никак не каснется. Так в *nix.
>> вы пишите диплом в ворде и написали уже более 9000 страниц, но до сих пор не сохраняли сохраняли документ
Я не могу себе такого представить. Это верх ламерства я считаю. У нас на работе 80% пользователей — в компьютерах полные нули, на даже они хоршо знают, что документ надо периодически сохранять(обычно это тривиальная настройка автосохранения) во избежание неприятных эмоций и напрасно потерянного времени. Даже если 1-2 страницы, а 9000…
Ну и вы конечно не стали читать топик и то, что в нем написано, а просто пробежались по диагонали
Я не могу себе такого представить. Это верх ламерства я считаю. У нас на работе 80% пользователей — в компьютерах полные нули, на даже они хоршо знают, что документ надо периодически сохранять(обычно это тривиальная настройка автосохранения) во избежание неприятных эмоций и напрасно потерянного времени. Даже если 1-2 страницы, а 9000…
Ну и вы конечно не стали читать топик и то, что в нем написано, а просто пробежались по диагонали
Это простой пример того, как человек не владеющей темой может написать совершенно непредсказуемую чушь :).
Ничего там такого не случится, старозапущеный ворд будет использовать старую длл-ку, а вновьзапущеные приложения — новую. Ну, то есть в системах, где это поддерживается — оно так.
Ничего там такого не случится, старозапущеный ворд будет использовать старую длл-ку, а вновьзапущеные приложения — новую. Ну, то есть в системах, где это поддерживается — оно так.
Вообще довольно странная (и забавная) позиция. Некая ОС требует иногда перегружаться при установке софта. Ну казалось бы, что за чепуха — нажал ребут, а сам пошёл чаю налить. Пока налил, уже и ребутнулось.
Нет, надо из этой ерунды развивать слонообразную тему — о том как, оказывается, всё плохо. Да господи, перезагрузил — забыл, не велика беда.
По поводу dll hell (обновили прогу, а она не пашет) — согласен, но это совсем другая проблема. Пытались сэкономить на размере, винчестеры были дорогими. Теперь уже не пытаются — любое .net приложение, например, устанавливает свою dll совместно с предыдущими версиями (не обновляя систему). Так что по идее, про эту проблему можно потихоньку начать забывать.
Нет, надо из этой ерунды развивать слонообразную тему — о том как, оказывается, всё плохо. Да господи, перезагрузил — забыл, не велика беда.
По поводу dll hell (обновили прогу, а она не пашет) — согласен, но это совсем другая проблема. Пытались сэкономить на размере, винчестеры были дорогими. Теперь уже не пытаются — любое .net приложение, например, устанавливает свою dll совместно с предыдущими версиями (не обновляя систему). Так что по идее, про эту проблему можно потихоньку начать забывать.
Ну казалось бы, что за чепуха — нажал ребут, а сам пошёл чаю налить. Пока налил, уже и ребутнулось.Ну действительно. А если этих компьютеров у вас в организации — 10'000? И на них нужно обновление установить? И на них люди работают? Или, наоборот, люди не работают, но эти компьютеры — это сервера и если они все сразу перезагрузятся, то ваша фирма убытков поимеет до… и больше?
Это просто так кажется что лишняя перезагрузка — это фигня. Пока ты «сам себе режиссёр» и компьютер у тебя один.
Теперь уже не пытаются — любое .net приложение, например, устанавливает свою dll совместно с предыдущими версиями (не обновляя систему). Так что по идее, про эту проблему можно потихоньку начать забывать.Погодите — а если в библиотеке или программе ошибка — тогда как? Нифига это не решение, так, заплатка на заплатке.
Нормальный админ не делает это посреди рабочего дня. Всегда можно найти время — в конце концов, ставить автоматом ночные обновления. Ну и другие способы есть. В конце концов, Гугл тоже когда-то свои сервера ребутит, но мы этого не замечаем.
А по поводу dll ещё раз: я не совсем понял вопрос. Если речь о том, что надо обновить библиотеку принудительно, то это это другая задача.
Предположим, есть софт А и софт Б. Они юзают библиотеку Д разных версий.
Если с софтом Б выходит более новая библиотека Д, только Б её и использует. А софт А продолжает использовать свою версию.
Если в библиотеке Д нашли ошибку, то нужен отдельный патч для А и отдельный патч для Б — по крайней мере, мне кажется, что это так работает.
А по поводу dll ещё раз: я не совсем понял вопрос. Если речь о том, что надо обновить библиотеку принудительно, то это это другая задача.
Предположим, есть софт А и софт Б. Они юзают библиотеку Д разных версий.
Если с софтом Б выходит более новая библиотека Д, только Б её и использует. А софт А продолжает использовать свою версию.
Если в библиотеке Д нашли ошибку, то нужен отдельный патч для А и отдельный патч для Б — по крайней мере, мне кажется, что это так работает.
Нормальный админ не делает это посреди рабочего дня. Всегда можно найти время — в конце концов, ставить автоматом ночные обновления. Ну и другие способы есть.А какая разница? Uptime того компьютера, с которого я это пишу — 72 дня. А программы я запустил и аккуратно их окошки расположил месяц назад. Какая разница — когда вы компьютер перезапустите — в любом случае мне все программы заново нужно будет запускать…
В конце концов, Гугл тоже когда-то свои сервера ребутит, но мы этого не замечаем.По иронии судьбы я знаком с одним из людей, которые это делают. Так вот: upgrade ядра (а это единственная операция, требующая перезагрузки, так как Windows они не используют) — на порядок более стрессовая ситуация, чем простая замена любой библиотеки. Даже glibc (хотя это тоже непросто ибо всякие казусы могут быть).
Предположим, есть софт А и софт Б. Они юзают библиотеку Д разных версий.А этот подход тот же Гугл использует для libstdc++… И да, нужно патчить отдельно все библиотеки, так что шибко широкое распространение этого метода создаёт свои проблемы… Представьте что ошибку нашли в zlib, которая используется в сотне программ у вас в системе…
Если с софтом Б выходит более новая библиотека Д, только Б её и использует. А софт А продолжает использовать свою версию.
Если в библиотеке Д нашли ошибку, то нужен отдельный патч для А и отдельный патч для Б — по крайней мере, мне кажется, что это так работает.
«Uptime того компьютера, с которого я это пишу — 72 дн»
Вы таки определитесь, что для вас важнее — аптайм, или сохранность вашей (возможоно мгономесячной) работы?
Вы таки определитесь, что для вас важнее — аптайм, или сохранность вашей (возможоно мгономесячной) работы?
О какой сохранности может идти речь когда мой компьютер перезагружается каждые несколько дней?
«О какой сохранности может идти речь когда мой компьютер перезагружается каждые несколько дней? „
А какое отношение имеет плановая перезагрузка к сохранности данных? Правильно, никакого
А какое отношение имеет плановая перезагрузка к сохранности данных? Правильно, никакого
Плановую перезагрузку планирует админ, а данные — они в документах у секретаря, однако. Кроме всего прочего после перезагрузки компьютер ведь может и не подняться — и не надо говорить о том, что так бывает редко. Так бывает — этого достаточно.
Любая перезагрузка — это угроза данным. Другое дело что иногда отказ от неё — большая угроза и из двух зол выбирается меньшее, но говорить
Любая перезагрузка — это угроза данным. Другое дело что иногда отказ от неё — большая угроза и из двух зол выбирается меньшее, но говорить
А какое отношение имеет плановая перезагрузка к сохранности данных? Правильно, никакогоможет только человек никогда не работавший админом…
так вот почему линуксоиды так боятся перезагрузки! =D
Я вас разочарую: перезагрузок боятся все админы, не только линуксоиды. Когда Microsoft выкатывает очередное обновление, требующее перезагрузки всегда очень долго оценивается выигрыш от него и потенциальный риск от неприменения. Конечно то же самое делается с любым обновлением, но если обновление требует перезагрузки — то это всегда становится большой проблемой: нужно оповещать всех в списке рассылки о том, что компьютер будет перезагружен, etc. В частности поэтому в корпорациях патчи, выложенные в Windows Update могут не применяться месяцами.
просто форсируют оную перезагруЖку. В общем — много
Отклонюсь от темы, но вдруг кому-нить пригодится :) Несмотря на такую ошибку в «ДНК», у меня из программ обновляет сама себя следующим образом: переименовывает себя, кладёт новую версию на прежнее место, запускает её и закрывается. Новая версия при запуске подчищает хвосты.
Только не надо писать что в линуксе всё можно сделать проще. Просто один из способов бороться с данной проблемой (не такой уж и тяжелый), возможно кому-нить пригодится, если будут делать апдейты.
Только не надо писать что в линуксе всё можно сделать проще. Просто один из способов бороться с данной проблемой (не такой уж и тяжелый), возможно кому-нить пригодится, если будут делать апдейты.
Тоже вариант. И тоже возникают проблемы с каскадными апдейтами и/или использованием одного ресурса из нескольких процессов. Гугловые программы (тот же Chrome) часто так делают.
Как я сказал: была изобретена масса способов как-то обойти эту ошибку в разных случаях. И будет изобретено ещё больше. Но окончательно решить её можно только на уровне OS.
Как я сказал: была изобретена масса способов как-то обойти эту ошибку в разных случаях. И будет изобретено ещё больше. Но окончательно решить её можно только на уровне OS.
Ололо! Автор поста, видимо, тролль.
Инсталляторы просят перегружать систему вовсе не потому, что файло в винде лочится. Иди читай книжки, школьник!
P.S. Я не спорю, что авторы инсталляторов криворуки, но статья полный ололо и автор тоже.
Инсталляторы просят перегружать систему вовсе не потому, что файло в винде лочится. Иди читай книжки, школьник!
P.S. Я не спорю, что авторы инсталляторов криворуки, но статья полный ололо и автор тоже.
Надо переобозвать пост с:
— «Ошибки в ДНК» или как неправильный дизайн может приводить к миллионным убыткам
на:
— «Ошибки в ДНК» или как поддержка ПО может приносить миллиардные прибыли :)
— «Ошибки в ДНК» или как неправильный дизайн может приводить к миллионным убыткам
на:
— «Ошибки в ДНК» или как поддержка ПО может приносить миллиардные прибыли :)
Миллиардные прибыли Microsoft получила на благодаря, а вопреки этой ошибке. Поддержке эта «фича» принесла не прибыли, а кучу головной боли, так что вариант тоже не прокатывает… Потом Microsoft делает не только ошибки в своей системе: скажем inotify в Linux появился в 2005м году, а в Windows аналогичная функция — на несколько лет раньше.
а вот такой философский вопрос: как вы думаете сколько они сэкономили времени на том что в свое время не сделали этого? я думаю что много. А значит шаг хоть и был проигрышным в перспективе не был проигрышным здесь и сейчас. Очень сложно побороть искушение сделать хорошо вместо того чтоб сделать быстро, но майкрософт регулярно это делает и они успешны на рынке — может это тоже кое чему должно нас научить?
Хотя статья мне ОЧЕНЬ понравилась — огромное вам спосибо
Хотя статья мне ОЧЕНЬ понравилась — огромное вам спосибо
я хотел сказать что добавлю в избранное и когда у меня кончатся аргументы перед начальством почему нада делать хорошо, а не быстро — я покажу статью
Вопрос действительно интересен: что лучше — «сделать хорошо» или «заработать бабла»? Microsoft доказывает что второе часто вступает в противоречие с первым и что стремление к совершенству обычно заканчивается ничем (ещё лучше это доказывает hurd), конечно. Но удивительно не то, что они совершили эту ошибку, а что они позже не попытались исправить проблему! Ну пусть не в Windows 9X, но почему и в Windows NT (которая писалась с нуля) — та же самая беда?
ИМХО, не такая уж это и проблематичная фича.
Ага. А куча решений от Microsoft, пытающихся её обойти и десятки, если не сотни, от третьих фирм — это мелочи?
Согласен, я говорил это к тому, что реализация отделения inode от дерева файловой системы не такая уж проблемная функция, как это подаёт developer.
Вы будете смеяться: все ещё хуже. Физически (на уровне файловой системы) NTFS эту фичу уже имеет (и имела всегда — ещё тогда, когда она называлась HPFS в OS/2). А вот логически (на уровне WinAPI) её нет. Сделать это — вообще раз плюнуть. Но… видимо это никому не нужно — или люди боятся что возможность удалять открытые файлы приведёт к проблемам с совместимостью. Последнее — наиболее вероятно.
Честно говоря, я не очень понял о каких убытках идёт речь?
Компания макрософт — крупнейшая IT корпорация в мире. И выходит, что Гейтс принял совершенно правильное бизнес-решение. С точки зрения разработчиков да — оно было не самым лучшим. Но на ~80% ПК установлена ОС Windows, а значит Билл был прав. И пользователя видимо не так сильно отталкивают частые перезагрузки, как привлекают какие-то другие вещи.
P.S. Мне в операционной системе Windows больше всего не нравится то, что за неё надо платить. Поэтому я пользуюсь Linux Debian.
Компания макрософт — крупнейшая IT корпорация в мире. И выходит, что Гейтс принял совершенно правильное бизнес-решение. С точки зрения разработчиков да — оно было не самым лучшим. Но на ~80% ПК установлена ОС Windows, а значит Билл был прав. И пользователя видимо не так сильно отталкивают частые перезагрузки, как привлекают какие-то другие вещи.
P.S. Мне в операционной системе Windows больше всего не нравится то, что за неё надо платить. Поэтому я пользуюсь Linux Debian.
А я скажу: «спасибо, познавательно» :) и поделюсь позитивом
я бы не хотел, чтобы после удаления мною файла он бы *не особождал* занимаемого места.
Но, о ужас, так это и в Windows и в Linux. Достаточно дать файлу второе имя (прочитайте про hardlinks). Современное «решение от Microsoft» в точности реализует все мыслимые недостатки других решений одновременно.
а как с этим в маке?
собственно вопрос: Вы можете назвать 5 программ которые просят перезагрузки, причем которые не используют драйвера/сервисы системы? не так все глупо на правах завязано…
есть примета: если от выключения одного сервера ваша компания терпит многомиллионные убытки, то пора искать нового админа.
Есть примета: если админ ставить security update только на один сервер из тысяч чтобы те не перезагружались, то его нужно просто уволить. Уж лучше студент, чем такой «спецалист».
Одна перезагрузка — стоит копейки. А вот если их десятки за год… а если компьютеров тысячи и миллионы… В сумме набегает неплохо…
Одна перезагрузка — стоит копейки. А вот если их десятки за год… а если компьютеров тысячи и миллионы… В сумме набегает неплохо…
одна перезагрузка ничего не стоит. если, конечно, админом не является тот студент, которому не хватает мозгов сообразить как перезагрузить каждый сервер не уронив продакшен.
Вы как тот Чебурашка, который просил наколупать изюма из булочек. Рабочее время админа всегда чего-то стоит на на перезагрузку его требуется больше, чем на замену библиотеки — вот эта разница уже чего-то стоит. Далее, если у вас сервер не поднимется — к нему придётся ехать. Даже если вероятность этого мала — матожидание нулю не равно и, стало быть, в цену перезагрузки добавляется ещё копеечка. И т.д. и т.п. Цена перезагрузки редко когда оказывается меньше $1, если посчитать все возможные затраты и вспомнить статистику.
любое изменение на сервере может с ненулевой вероятностью привести к чему угодно. именно поэтому никакие апдейты нельзя проводить на живую — машинка выводится из кластера, обновляется, прогоняется через тесты и только если тесты прошли успешно возвращается в строй.
Тут вы правы, но тут такая история: перезагрузка на сервере добавляет свои немалые риски, а перезагрузка на клиенте — вообще караул. Как вы будете «выводить машину из кластера» если она у человека на столе стоит?
ну, он же не круглосуточно за ней сидит? =)
Нет, но как об этом узнать админу? Я, например, иногда засиживаюсь на работе до 22, а иногда, наоборот, прихожу очень рано. А программы у меня вообще никогда не закрываются: перед уходом я лочу экран — и всё. Спланировать подходящее время для перезагрузки, а потом ответить на вопросы разъярнных пользователей, у которых возникли проблемы — отдельная история. И делать это ради обновления какого-нибудь Outlook Express'а, которым пользуется дай бог один человек из 10 ой как не хочется…
(отвечаю не совсем туда, но потерял коммент)
Грубо говоря:
Библиотеки .so загружаются в shared память и там висят, до тех пор, пока их кто-нибудь использует.
Загрузчик запоминает куда и какая библиотека загружена (по полным путям библиотек в файловой системе).
Замена файла библиотеки заключается в:
— создании нового файла (на новом месте)
— переписывание ссылки в каталоге на этот файл.
На библиотеку, уже загруженную в память манипуляции в файловой системе никоим образом не влияют.
Новый процесс, использующий библиотеку под темже полным именем будет слинкован с уже загруженной версией библиотеки.
Загрузка новой версии библиотеки произойдёт только после того, как завершатся все процессы её использующие. (И запустится новый, использующий эту же библиотеку).
Теоретически, возможна ситуация (её можно попробовать сделать намеренно), когда часть взаимоиспользующихся библиотек уже перегружена, а часть ещё осталась в памяти. Если обновлённые версии библиотек были несовместимые с предыдущими — будет конфликтец.
Загрузчик различает библиотеки по полному файловому имени.
Именно поэтому имена файлов библиотек включают в себя полную версию, и на каждую библиотеку нагораживается огород с симлинками:
libfoo-1.2.3.so -> libfoo-1.2.so -> libfoo-1.so -> libfoo.so
Поскольку /sbin/init использует libc.so и собственно ld.so,
при обновлении этих библиотек требуется таки перезагрузка, либо очень интересный, но неизвестный мне танец с бубном.
Ну и разумеется, перезагрузка нужна для смены версии ядра.
Это может быть критично при апгрейде каких-нибудь утилит, завязанных на ядро.
Во всех остальных случаях, как я понимаю, апгрейдить систему можно без перезагрузки.
Спокойно обновить в фоне все свои иксы/кеды/гнома, потом перезайти в сессию (можно даже не закрывая запущенных программ), чтобы они естественным образом перегрузили библиотеки, и вуаля! — всё встало раком :))
Ну тоесть всё должно сразу заработать по-новому, либо я что-то важное в своих выкладках пропустил.
Грубо говоря:
Библиотеки .so загружаются в shared память и там висят, до тех пор, пока их кто-нибудь использует.
Загрузчик запоминает куда и какая библиотека загружена (по полным путям библиотек в файловой системе).
Замена файла библиотеки заключается в:
— создании нового файла (на новом месте)
— переписывание ссылки в каталоге на этот файл.
На библиотеку, уже загруженную в память манипуляции в файловой системе никоим образом не влияют.
Новый процесс, использующий библиотеку под темже полным именем будет слинкован с уже загруженной версией библиотеки.
Загрузка новой версии библиотеки произойдёт только после того, как завершатся все процессы её использующие. (И запустится новый, использующий эту же библиотеку).
Теоретически, возможна ситуация (её можно попробовать сделать намеренно), когда часть взаимоиспользующихся библиотек уже перегружена, а часть ещё осталась в памяти. Если обновлённые версии библиотек были несовместимые с предыдущими — будет конфликтец.
Загрузчик различает библиотеки по полному файловому имени.
Именно поэтому имена файлов библиотек включают в себя полную версию, и на каждую библиотеку нагораживается огород с симлинками:
libfoo-1.2.3.so -> libfoo-1.2.so -> libfoo-1.so -> libfoo.so
Поскольку /sbin/init использует libc.so и собственно ld.so,
при обновлении этих библиотек требуется таки перезагрузка, либо очень интересный, но неизвестный мне танец с бубном.
Ну и разумеется, перезагрузка нужна для смены версии ядра.
Это может быть критично при апгрейде каких-нибудь утилит, завязанных на ядро.
Во всех остальных случаях, как я понимаю, апгрейдить систему можно без перезагрузки.
Спокойно обновить в фоне все свои иксы/кеды/гнома, потом перезайти в сессию (можно даже не закрывая запущенных программ), чтобы они естественным образом перегрузили библиотеки, и вуаля! — всё встало раком :))
Ну тоесть всё должно сразу заработать по-новому, либо я что-то важное в своих выкладках пропустил.
Поскольку /sbin/init использует libc.so и собственно ld.so,Не нужно никакого танца с бубнами. Пусть себе /sbin/init использует столетнюю версию glibc. Он настолько мало из неё использует и та часть, которую он использует настолько вылизана, что я не думаю что в ней за много лет будет найдена хоть одна ошибка…
при обновлении этих библиотек требуется таки перезагрузка, либо очень интересный, но неизвестный мне танец с бубном.
Стоит переформулировать
«Права доступа к inode и права доступа к файлу никак, вообще говоря, не связаны между собой»
Как раз права доступа к _файлу_ задаются в inode, а к _имени_ _файла_ в каталоге.
«Права доступа к inode и права доступа к файлу никак, вообще говоря, не связаны между собой»
Как раз права доступа к _файлу_ задаются в inode, а к _имени_ _файла_ в каталоге.
Однозначно статья месяца!
Интересная статья. Вот оказывается где собака порылась…
Опечатка «Многие файлы в Windows вообще не могут быть моДИфицированы во всемя её работы»
Опечатка «Многие файлы в Windows вообще не могут быть моДИфицированы во всемя её работы»
Зарегистрируйтесь на Хабре, чтобы оставить комментарий
«Ошибки в ДНК» или как неправильный дизайн может приводить к миллионным убыткам