Или его со временем полностью вытеснит верифицируемый промежуточный код?
Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
Да.
C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Да.
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Да.
Но не скоро.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства? WH>Да.
Скорее всего нет. Ибо виртуализация.
Но для разработки ОС такой механизм применяться не будет.
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
Нет.
C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Нет.
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Нет.
З.Ы. Теперь согласные/несогласные могут ставить плюсики либо мне, либо WolfHound-у
P.P.S. На самом деле, осталось еще 6 вариантов ответа...
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
Зависи от ОС.
C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Зависи от ОС.
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Зависи от ОС.
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
Осталось выяснить разновидность этого самого промежуточного кода. Минимум два непримиримых кандидата на престол у нас уже есть — CLR и JVM. Так что, ИМХО, если кто-то кого-то и вытеснит, то точно не в ближайшее время.
C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Скорее нет, чем да.
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Нет, не утратит. ИМХО, по одной простой причине — в виртуальных адресных пространствах, в принципе, можно запустить хоть вагон управляемых ОС (каждой по сегменту и пусть никто не уйдёт огорчённым). Хотя, конечно, эти подходы можно и смешивать до определённой степени — т.е., управляемая ОС сможет запускать много чего Native.
Я знаю только две бесконечные вещи — Вселенную и человеческую глупость, и я не совсем уверен насчёт Вселенной. (c) А. Эйнштейн
P.S.: Винодельческие провинции — это есть рулез!
Здравствуйте, Chrome, Вы писали:
C>Или его со временем полностью вытеснит верифицируемый промежуточный код?
Нет.
C>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
Нет.
C>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
Не знаю. Совместное адресное пространство было уже (Win16), ничего хорошего из этого не вышло. Однако даже отвергнутые идеи имеют иногда способность возвращаться . В ближайшем будущем все же нет.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, jazzer, Вы писали:
J>>P.P.S. На самом деле, осталось еще 6 вариантов ответа...
PD>Больше. Я на один из вопросов ответил "Не знаю"
Здравствуйте, Sorantis, Вы писали:
S>Здравствуйте, Chrome, Вы писали:
C>>Или его со временем полностью вытеснит верифицируемый промежуточный код? S>Зависи от ОС.
C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы? S>Зависи от ОС.
C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства? S>Зависи от ОС.
А что именно зависит от ОС?
Вроде современные распространенные ОС по перечисленным аспектам похожи как капли воды
— выполняют native code
— используют виртуальные адресные пространства для изоляции процессов
— имеют ядро и соответственно переключения в режим ядра
Здравствуйте, thesz, Вы писали:
T>Здравствуйте, Chrome, Вы писали:
C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?
T>Нет.
C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
T>Нет.
C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
T>Нет.
Интереснее было бы услышать аргументы, а не авторитетное мнение.
Здравствуйте, Pavel Dvorkin, Вы писали:
PD>Здравствуйте, Chrome, Вы писали:
C>>Или его со временем полностью вытеснит верифицируемый промежуточный код?
PD>Нет.
Даже в случае проектируемой с нуля какой нибудь будущей ОС?
C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы?
PD>Нет.
А зачем оно будет нужно?
C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства?
PD>Не знаю. Совместное адресное пространство было уже (Win16), ничего хорошего из этого не вышло. Однако даже отвергнутые идеи имеют иногда способность возвращаться . В ближайшем будущем все же нет.
Верифицируемый код не позволяет портить чужие данные. Что еще нужно?
Здравствуйте, Геннадий Васильев, Вы писали:
ГВ>Осталось выяснить разновидность этого самого промежуточного кода. Минимум два непримиримых кандидата на престол у нас уже есть — CLR и JVM. Так что, ИМХО, если кто-то кого-то и вытеснит, то точно не в ближайшее время.
Ни тот и ни другой.
У них система типов мягко говоря слабовата.
В ядре ОС без зависимых типов делать нечего.
C>>Уйдет ли в прошлое "работа потока в режиме ядра и в пользовательском режиме" и связанные с этим накладные расходы? ГВ>Скорее нет, чем да.
А нафига оно надо если будет программная изоляция?
C>>Утратит ли смысл изоляция приложений с помощью отдельного виртуального адресного пространства? ГВ>Нет, не утратит. ИМХО, по одной простой причине — в виртуальных адресных пространствах, в принципе, можно запустить хоть вагон управляемых ОС (каждой по сегменту и пусть никто не уйдёт огорчённым). Хотя, конечно, эти подходы можно и смешивать до определённой степени — т.е., управляемая ОС сможет запускать много чего Native.
Оно будет нужно только для того чтобы во всяких вмварях легаси запускать.
А для чего еще?
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, Serginio1, Вы писали:
S>А есть уже практическое применение Singularity, хотя бы как Оберон систем
Не думаю ибо эта ОС изначально задумывалась исключительно как эксперимент.
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, blackhearted, Вы писали:
C>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно? B>Осталось его весь верифицировать
Не позволить портить чужие данные это вообще примитив. С этим даже жаба и .НЕТ справляются.
А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...
Пусть это будет просто:
просто, как только можно,
но не проще.
(C) А. Эйнштейн
Здравствуйте, WolfHound, Вы писали:
WH>Здравствуйте, blackhearted, Вы писали:
C>>>Верифицируемый код не позволяет портить чужие данные. Что еще нужно? B>>Осталось его весь верифицировать WH>Не позволить портить чужие данные это вообще примитив. С этим даже жаба и .НЕТ справляются. WH>А если прикрутить http://en.wikipedia.org/wiki/Dependent_type то ВМ сможет столько всего проверить...
Зависимые типы они круты, безусловно, но вот, а какие ещё проблемы может дать "нехороший" код, которые зависимые типы должны по идее разрешить, кроме порчи памяти? В голову пока приходит только захват ресурсов (в т.ч. памяти), который будет мешать другим процессам (и ядерным возможно).
