Джеф Арнольд (Jeff Arnold) анонсировал (http://groups.google.com/group/fa.linux.kernel/msg/196eb4edf...) в списке рассылки разработчиков Linux ядра систему Ksplice (http://web.mit.edu/ksplice/), предназначенную для обновления частей Linux ядра без перезагрузки. В первую очередь проект ориентирован на установку критических обновлений, связанных с безопасностью, в автоматическом режиме, без остановки работы.
Следует заметить, что Ksplice невозможно использовать, когда изменения затрагивают структуры данных, но подавляющие большинство исправлений ошибок безопасности не производят подобные модификации. При оценке уязвимостей исправленных с мая 2005 по декабрь 2007 года, 87% всех исправлений были пригодными для исправления без остановки работы.
Кроме того, Ksplice универсален и не требует какой-либо модификации работающего Linux ядра, требуется (http://web.mit.edu/ksplice/printk.html) лишь подгрузить два модуля ядра для внесения pre- и post-изменений, и специальным образом офо...URL: http://groups.google.com/group/fa.linux.kernel/msg/196eb4edf...
Новость: http://www.opennet.me/opennews/art.shtml?num=15522
прочитал название новости - обрадовался, саму новость - не очень! =)
посмотрин на дальнейшее развитие событий...
но не обошлось и без капли дегтя - подобная технология обновления на лету оказалась запатентованной фирмой Microsoft в 2002 году, но оптимизм вызывает то, что метод был известен задолго до публикации патента.
а суть в том, что они же сами (американцы) недавно и отклонили проект (его,
кстати, поддержавала и млакосотт), который предлагал изменить текущую схему
патентования. И у них до сих пор (в отличие от всех стран Мира) признается право
за тем, кто впервые использовал, а не подал заявку (как мракосо в данном случае).Так что, все ок :) У нас их софт-патенты не действуют, а они сами пользуются схемой,
которая позволит отозвать у мракосо их патент.
>но не обошлось и без капли дегтя - подобная технология обновления на
>лету оказалась запатентованной фирмой Microsoft в 2002 году, но оптимизм вызывает
>то, что метод был известен задолго до публикации патента.да тот-же недавний vmsplice многие подлечили через systemtap
>...подобная технология обновления на лету оказалась
>запатентованной фирмой Microsoft в 2002 годуНу и где мы это видем?! Может быть в Висте?! Не знаю, не пробовал, но вот XP по каждому "чиху" перегружаться просится.
А линуксоиды конечно молодцы! Какую штуку отчебучили! Вот она - передовая IT-технологий.
В глобальном смысле - это ни разу не передовая. Солярка это уже лет десять умеет.
Но молодцы что таки сделали.
Можно ссылку на документацию, каким боком солярка это умеет?
> Можно ссылку на документацию, каким боком солярка это умеет?http://opensolaris.org/os/community/fm/
Оченно помогает пройтись по сцылкам на вышеуказанной странице и прочитать их.
http://www.opensolaris.org/jive/thread.jspa?messageID=149032...
немного странно тогда получается - солярка умеет давно, а патент у мс. И, главное, тишина...
У МС есть патент на даблклик. Тож молчат. И такого много.
>У МС есть патент на даблклик. Тож молчат. И такого много.Представляю себе, если они попытаются заявить об этом :-) Их если и не съедет заживо, то как минимум будут пальцем показывать: "Эй смотрите, вон чувак из Микрософта пошёл" :-D
>В глобальном смысле - это ни разу не передовая. Солярка это уже
>лет десять умеет.Бедем считать, что передовая, но для простых смертных :-) Солярка-то недавно к нам с небес спустилась, недоступна была однако :-(
Не Sun Solaris, не OpenSolaris, не имеет этого функцанала, в треде есть ссылка на пост в форуме на opensolaris.org...:)
Простите, но уж больно глаз режет. Вы хотели сказать "ни Sun Solaris, ни OpenSolaris".
In one implementation the present invention uses core API's which exist within the operating system e.g. Windows NET server 2003 and enable the successful installation of a hotpatch and coldpatch in support of a security or other fix This technique does not induce downtime data loss or temporary interruption of services for the customer http://www.google.com/patents?id=cVyWAAAAEBAJ&zoom=4&dq=hotp...,1175,423,130&source=bookclip
Мелкософт запатентовала боян, или что-то другое. Подобный механизм использовался в начале 90-х в novell netware начиная с 3 версии.
А реально сделать так полное обновление ядра? Т.е. прямо на лету обновить 2.6.24 до 2.6.25 без перезагрузки?
>А реально сделать так полное обновление ядра? Т.е. прямо на лету обновить
>2.6.24 до 2.6.25 без перезагрузки?наруш традицию
поди почитай по сцылке
нет, не реально - изменение структуры данных (введение или удаление поля) и всё, приплыли, порча памяти. В частном случае сделать можно (например переход 2.6.24 -> 2.6.25), но геморрой изрядный, так как для каждой измененной структуры данных нужна будет своя процедура копирования и все будут только и делать, что писать и отлаживать "копировалки". По большому счету это нафиг не надо. А вот "алгоритмический" патчинг (багфиксы, секурити-фиксы) очень нужны. Крутится на сервере три десятка виртуалок, а одна подвисает из-за бага. Надо ядро патчить -> перезагрузка, но остальные виртуалки останавливать ой как неохота...
Есть же Live-migration в xen и openvz, что-то подобное можно для обновления ядра придумать, замораживание как при hibernate образа системы, загрузки нового ядра и размораживание.
>Есть же Live-migration в xen и openvz, что-то подобное можно для обновления
>ядра придумать, замораживание как при hibernate образа системы, загрузки нового ядра
>и размораживание.Ну, в теории наверное можно.При неизменности интерфейсов.А что делать если структуры данных поменялись?Программы то не в курсе :)
Это все костыли
>Это все костылиа что не костыли?
> >Это все костыли
>а что не костыли?Ultimate Linux Kernel - последняя версия ядра без багов и со всем фичами... его один раз надо загрузить и всё :)
>> >Это все костыли
>>а что не костыли?
>
>Ultimate Linux Kernel - последняя версия ядра без багов и со всем
>фичами... его один раз надо загрузить и всё :)улыбнул :)
А что делать, когда в нем баги найдут?
> Это все костылиПрограммы, почтенный, делятся на две категории: на те, которые устарели, и на те, которые не работают.
Вот меня лично интересуют только вторые. :) И чтобы с их помощью решать реальные задачи, такие вот "костыли" оченно необходимы. :)
Ну на Десктопе такое понижение производительности и рисс нестабильности не нужно. Надеюсь, по умолчанию в ядро не впихнут :)
>Ну на Десктопе такое понижение производительности и рисс нестабильности не нужно. Надеюсь,
>по умолчанию в ядро не впихнут :)никаких предварительных модификаций ядра не требуется. Чего ты боишся интеграции этой системы сборки в дистрибутив ядра?
>никаких предварительных модификаций ядра не требуется.
>Чего ты боишся интеграции этой системы сборки в дистрибутив ядра?Это как? Предварительных модификация не требуется, но интеграция в дистрибутив ядра нужна?
Я боюсь вот этого:
>требуется лишь подгрузить два модуля ядра для внесения pre- и post-изменений, и >специальным образом оформить файл изменений, который будет спроецирован на работающее >ядро.Что-то мне подсказывает, что "специальным образом оформленный файл изменений, спроецированный на работающее ядро", будет существенно тормозить само ядро и будет весьма нестабильной штукой. Технология, честно говоря, не ахти какая.
>>никаких предварительных модификаций ядра не требуется.
>>Чего ты боишся интеграции этой системы сборки в дистрибутив ядра?
>Это как? Предварительных модификация не требуется, но интеграция в дистрибутив ядра нужна?Не нужна :) Бери пользуй так. Но ее могут включить в дистр ядра.
А человек этого боиццо. Че - непонятно....
>Я боюсь вот этого:
>>требуется лишь подгрузить два модуля ядра для внесения pre- и post-изменений, и >специальным образом оформить файл изменений, который будет спроецирован на работающее >ядро.
>Что-то мне подсказывает, что "специальным образом оформленный файл изменений, спроецированный на работающее
>ядро", будет существенно тормозить само ядро и будет весьма нестабильной штукой.
>Технология, честно говоря, не ахти какая.ясно. Вы вообще не в теме. Ну тогда не страшно. Бойтесь :) Не стану разубеждать.
>ясно. Вы вообще не в теме. Ну тогда не страшно. Бойтесь :) Не стану разубеждать.То-есть вы утверждаете, что такими костылями невозможно понизить производительность и стабильность?
>>ясно. Вы вообще не в теме. Ну тогда не страшно. Бойтесь :) Не стану разубеждать.
>То-есть вы утверждаете, что такими костылями невозможно понизить производительность и стабильность?Смотря ЧЕМ запатчить ядро.
Если тридцатью вложенными пустыми неоптимизированными цыклами - вопрос о производительности не заставит себя ждать.
Если же такими патчами, которые реально были в истории критических патчей (одна-две строки заменяются) - то НЕТ, производительность не упадет.Стабильность можно нарушить если работающее ядро и новые функции будут собраны разными компиляторами или же с разными опциями. И не иначе. Но кто так будет делать - сам себе буратино :)
Ну представь, что есть функция, в которой обнаружили уязвимость. Пишут аналог этой функции без уязвимости, оформляют в виде модуля, загружают модуль и меняют в коде ядра вызов старой функции на вызов новой. Вот и все. Снижения скорости не будет (если, конечно, новая функция не будет содержать тормозов).
Так бы я делал. Думаю, они сделали похоже.