Здравствуйте, koandrew, Вы писали:
C>>Выделить программу в контейнер и затормозить весь контейнер. K>Хм... А сервак, с которым прога работает, ты тоже заморозишь?
Весь-то зачем?
K>Вместе с сетевым стеком?
Можно. К примеру, для миграции на другой хост и последующей "разморозки". Если уложиться в таймауты TCP, то даже соединения можно мигрировать.
Погугли по "single image cluster".
K>И как насчёт деревьев процессов, которые так любят и которыми так гордятся линуксоиды?
Без проблем тоже. Что положишь в контейнер, то и "замёрзнет" при остановке. Всё что не будет заморожено — для остановленных процессов будет выглядеть как умершие процессы.
Здравствуйте, LaPerouse, Вы писали:
LP>От этого и гибернация всея системы не поможет. Чудес не бывает.
Ну просто обычно эпплофилы утверждают, что стивжопс либо делает фичу хорошо, либо не делает совсем. Тут невозможность сделать её хорошо очевидна, но тем не менее её сделали
Здравствуйте, Mamut, Вы писали:
M>Ну, на десктопе, имхо, вполне четко различимы эти границы.
Вордовский документ, в который вставлен аутпроцессовский OLE-объект -- это сколько приложений?
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Mamut, Вы писали:
C>>Linux. Причём есть чудо, и приложениям не нужно использовать новый API. C>>Так что как всегда: "Стив Джобс изобрёл миграцию процессов". M>Угу. Только что-то этого чуда в линуксах не видно, иначе бы использовалось повсеместно.
Ну а зачем оно нужно? Сейчас основной пользователь для этого — балансировка нагрузки для легковесной виртуализации.
LP>>2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр. E>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...
Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.
Здравствуйте, koandrew, Вы писали:
LP>>От этого и гибернация всея системы не поможет. Чудес не бывает. K>Ну просто обычно эпплофилы утверждают, что стивжопс либо делает фичу хорошо, либо не делает совсем. Тут невозможность сделать её хорошо очевидна, но тем не менее её сделали
Только она уже была много лет как реализована в Linux'е.
В общем: "Стив Джобс придумал миграцию процессов".
Здравствуйте, LaPerouse, Вы писали:
E>>Что касается драйверов, то не всё там так просто.
LP>Не понял, при чем здесь драйвера. Установка некоторых драйверов требует перезагрузки — это печальный факт.
Драйвера тут при том, что они имеют дело с железом, для которого хибернайт нифига не прозрачен...
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Cyberax, Вы писали:
C>Весь-то зачем?
Хм — состояние сервака является частью состояния приложения => надо "замораживать".
C>Можно. К примеру, для миграции на другой хост и последующей "разморозки". Если уложиться в таймауты TCP, то даже соединения можно мигрировать.
C>Погугли по "single image cluster".
Я в курсе и про live migration, и про все эти дела. Но тут речь не об этом. Тут нужно заморозить состояние приложения на неопределённый срок (а не на таймаут TCP)
C>Без проблем тоже. Что положишь в контейнер, то и "замёрзнет" при остановке. Всё что не будет заморожено — для остановленных процессов будет выглядеть как умершие процессы.
C>Причём контейнер автоматически отслеживает иерархию процессов, что классно используется в http://0pointer.de/blog/projects/systemd.html
Не-не, раз сказали, что сохраняем всё состояние приложения, значит так и делаем. Состоянием приложения может быть:
Состояние гуи
Открытые файлы
Разделяемая память (в случае многопросессного приложения)
Состояние некого внешнего по отношению к нашему приложения, с которым общается наше приложение (например через DDE/OLE Automation/Inplace activation в случае винды)
Статус сетевых соединений и приложений "на том конце провода"
Здравствуйте, Mamut, Вы писали:
M>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.
Для этого тебе придётся потрясти разработчиков ворда, чтобы они это сделали. То же самое тебе нужно будет сделать и в случае использования этого "нового" API. В чём разница-то?
Здравствуйте, Mamut, Вы писали:
LP>>>2. Можно отправить в гибернацию отдельное приложение или группу приложений. Реализовать этот юзкейс прозрачно для приложения (то есть без поддержки со стороны приложения), вероятно, непросто (что например делать с открытыми ресурсами, изменившимся окружением?), поэтому придумали вот такое вот решение через API — программер сам все сделает, учтя все вышеозначенные проблемы с ресурсами и пр. E>>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...
M>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.
И, что существенно, с несохраненным документом, если он оставался несохраненным в момент стопа приложения. Сохранение данных и состояния приложения — разные вещи. С сохранением данных так шутить нельзя.
Социализм — это власть трудящихся и централизованная плановая экономика.
Здравствуйте, Mamut, Вы писали:
M>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.
Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...
E>>Ну так всё же уже украдено до нас. Нормальные приложения уже умеют так делать, ненормальные и не научатся никогда...
M>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.
Дык это в MS должны же сделать? А при чём тут Джобс со своим API
Все эмоциональные формулировки не соотвествуют действительному положению вещей и приведены мной исключительно "ради красного словца". За корректными формулировками и неискажённым изложением идей, следует обращаться к их автором или воспользоваться поиском
Здравствуйте, Erop, Вы писали:
E>Здравствуйте, LaPerouse, Вы писали:
E>>>Что касается драйверов, то не всё там так просто. LP>>Не понял, при чем здесь драйвера. Установка некоторых драйверов требует перезагрузки — это печальный факт. E>Драйвера тут при том, что они имеют дело с железом, для которого хибернайт нифига не прозрачен...
Реализация гибернайта в винде вроде бы требует PnP от устройств. Но при чем тут вообще драйвера? Ты к чему о них заговорил?
Социализм — это власть трудящихся и централизованная плановая экономика.
M>>Причем тут FF? E>При том, что они вполне обошлись без спец. API...
Правильно, изобретя собственный велосипед. МакОСь предложит единый API
M>>То, что некотрые приложения реализуют собственные велосипеды, это известно. Тут интересно, что это будет общесистемный API, доступный всем. E>А что именно сейчас недоступно?
M>>Ну, на десктопе, имхо, вполне четко различимы эти границы.
E>Вордовский документ, в который вставлен аутпроцессовский OLE-объект -- это сколько приложений?
Здравствуйте, koandrew, Вы писали:
M>>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений. K>Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...
Hint: они работают через драйверы, которые есть часть ОС.
C>>>Linux. Причём есть чудо, и приложениям не нужно использовать новый API. C>>>Так что как всегда: "Стив Джобс изобрёл миграцию процессов". M>>Угу. Только что-то этого чуда в линуксах не видно, иначе бы использовалось повсеместно. C>Ну а зачем оно нужно? Сейчас основной пользователь для этого — балансировка нагрузки для легковесной виртуализации.
Непрерывность работы. Я хочу, чтобы система, как минимум, запускалась с файлами, открытыми в тех местах, где я их оствил.
Или даже не запускалась вся система, а закрытое мной приложение.
M>>Не умеют они. Я хочу, чтобы при запуске ворда сразу открывались все редактируемые мной документы, с сохраненным выделением, положениями курсора и т.п.
K>Для этого тебе придётся потрясти разработчиков ворда, чтобы они это сделали. То же самое тебе нужно будет сделать и в случае использования этого "нового" API. В чём разница-то?
В том, что мне придется отдельно трясти разработчиков ворда, чтобы они изобрели свой велосипед, разработчиов еще какой-то программы, чтоби они изобрели свой велосипед и т.д. Тут (в теории, во всяком случае) не требуется изобретать свой велосипед,а дается готовый API
M>>Прикол в том, что можно прозрачно реализовать stop/resume для (практически) любого приложения, не заморачиваясь вопросами типа "вы действительно хотите выйти?", "сохранить?" и минутными сплешами при стартапе приложений.
K>Нельзя. Хинт — некоторые приложения работают с железом, которому ОС не указ...
Если мы говороим, про десктоп, то для подавляющего большинсва можно.
Здравствуйте, koandrew, Вы писали:
C>>Весь-то зачем? K>Хм — состояние сервака является частью состояния приложения => надо "замораживать".
Какого сервака?
C>>Без проблем тоже. Что положишь в контейнер, то и "замёрзнет" при остановке. Всё что не будет заморожено — для остановленных процессов будет выглядеть как умершие процессы. C>>Причём контейнер автоматически отслеживает иерархию процессов, что классно используется в http://0pointer.de/blog/projects/systemd.html K>Не-не, раз сказали, что сохраняем всё состояние приложения, значит так и делаем. Состоянием приложения может быть: K>
K> Состояние гуи K>
Есть.
K>
K> Открытые файлы K>
Есть.
K>
K> Разделяемая память (в случае многопросессного приложения) K>
Снимок состояния будет.
K>
K> Состояние некого внешнего по отношению к нашему приложения, с которым общается наше приложение (например через DDE/OLE Automation/Inplace activation в случае винды) K>
Нет, понятное дело.
K>
K> Статус сетевых соединений и приложений "на том конце провода" K>
Один фиг, по таймауту отвалятся.
K>Ну и как всё это сохранять?
С весёлой песней.