Информация о Microsoft Midori OS
18001
Мэри Джо Фоли (Mary Jo Foley) опубликовала продолжение своего эксклюзива о Midori OS от Microsoft. В дополнение к материалу Джо Фоли представляем подтверждение о существовании Midori из одной презентации, с сайта Microsoft Research.
Эта презентация была представлена Шазом Кадиром (Shaz Qadeer) из Microsoft Research Software Reliability Research в Принстонском университете еще в декабре 2007 года. Во время одного из слайдов презентации Шаз обсуждает CHESS, которая является такой же технологией, которая обсуждалась в предыдущей презентации Шаза, которая была впервые замечена на сайте . В новейшей презентации нет ничего особенного, если, конечно, вы не поймете эту статью с технической точки зрения, с которой она и написана. Поэтому, подсказка: в 38 слайде есть упоминание о Midori OS.
Итак, о секретной ОС, разрабатываемой в недрах Microsoft, известной под кодовым именем Midori. К сожалению, некоторые люди воспринимают известные на данный момент факты, которых и так немного, искаженно, и это вынуждает нас развеять некоторые слухи и мифы.
Великое недоразумение: Кодовое имя Midori - это имя Windows 8, и абсолютно новая база кода для каждой последующей версии Windows.
Факты: на данный момент кодовое имя Midori не имеет ничего общего с Windows. А именно с Windows 8 и Windows 9, которым народная молва уже присвоила кодовые имена Orient и Mystic.
Midori OS тесно связана с Singularity - ОС, написанной на управляемом коде.
Вопрос: Где Microsoft упоминает о данной предполагаемой ОС, на основе чего автор делает такие выводы?
Ответ: Вы можете загрузить презентацию с сайта Microsoft, и найти слово Midori в документе.
Итак, вся эта шумиха вокруг Midori началась после того, как Мэри Джо Фоли написала, что Midori вероятно заменит Windows, и в своем роде, находится в инкубационном состоянии, имея в виду, что проект находится в более готовом для рынка состоянии, чем обычно бывают проекты Microsoft Research. Несмотря на внутренние планы относительно Midori сейчас, история показывает, что планы имеют свойство меняться, причем иногда радикально. Фактически, предположение о том, что на данный момент Midori имеет какое-либо отношение к какой-либо версии Windows абсолютно бессмысленно. Поэтому не вносите сумятицу, создавая теории.
Midori может очень успешно в будущем заменить Windows, но давайте не говорить об этом сейчас.
Итог: Midori имеет отношение к Windows 8? В данный момент нет. К будущим версиям Windows? Возможно.
Источник:
Перевод: Zloy Kak Pё$
Комментарии
сингулярная ось эт конечно хорошо.. скомпилил, запустил, посмотрел, выключил)) да, на шарпе она написана..
В прошлый раз я спросил у администрации сайта "какое отношение к www.the_ V___I__ S__ T__ A .ru имеет Windows 7 ?" Мне ответили, что сайту интересна не только тема Vista но Windows 7. Тепреь еще и Midori присоеденилась ..Может переименовать сайт в www.NEXTGEN OSes from Microsoft.ru ?
Plantus, а какое отношение имеет сайт www.microsoft.ru к тяжелому софту? Какая разница как называется сайт, у сайта есть политика и направление развития, вот именно ей он и следует.
Между прочим если не заострять внимание на том, что сайт называется так-же как и ось от мелкософта, то очень даже нормальное название (разве что "The" можно убрать, но имя www.vista.ru к сожалению уже занято). Vista переводится как Перспектива. То есть сайт обсуждает перспективы в развитии программного обеспечения, в частности производства Microsoft.
Интересно, какое название будет у финальной версии? Midori как-то не очень звучит.
Заметьте, что только МС дает каждой оси новое громкое имя. Но чем громче оно разгавкано, тем сложнее потом тулить следубющее.
И тут приходит на помощь верный друг - код с ошибкамим, которые сознательно не исправляются в сервис паках и заплатках, где сейчас такие хорошие удобные и лицомкпользователю обращенные вин98 и Хр?? Даже виста уже не кажется такой хорошей!
Можно ли продолжать завоевывать рынок таким образом.
midori будет на тему анимэ и с драйвером видеокарты написанном на C#
Plantusпрочитай внимательно что написано у тебя на окне браузера
TheVista.Ru - Опережая время - Продукты семейства Windows и Office
Продукты семейства Windows и Office
теперь понял?
да наплевать как сайт завётся может ты и на порно сайтах пишишь а почему увас сайт завётся не порно.ру а камила+18.ком?
меньше драчи приятель и невозникай по пустакам:;)
А вообще любопытно посмотреть. Если вся ОС написана на управляемом языке, сделанном на основе шарпа, то интересно - как они решили проблему адских тормозов при работе сборщика мусора? В момент, когда работает сборщик мусора, ничего больше выполняться не может, по идее.
В момент, когда работает сборщик мусора, ничего больше выполняться не может, по идее.
В мультипроцессорной (многоядерной) системе должно быть всё ок.
Vermillion_returned, не нужно все воспринимать в лоб, буквально. Вполне очевидно, что никто не будет использовать для работы оси тот .Net Framework, которыя сейчас имеется. Под эту ось делают специальную версию дотнета, в частности, сборщик мусора там будт работать по другим алгоритмам. Рекмендую читануть пдф-нички из раздела про Singularity на сайте МС.
Кстати, сборщик мусора прекрасно справляется со своей работой в большинстве случаев, не особо подтормаживая систему. Какие-то заметные тормозо я лично наблюдал очень редко. К тому же, есть определенные рекомендации, как писат ьприложения так, чтобы они не нагружали сборщик. Аналогичные ограничения имеются и в рантаймах где нет сборщика. Например, в сишном рантайме есть проблема фрагментации памяти и скорости ее выделения изза поиска по списку. Идеальных решений не существует, так что нельзя сказать, что что-то одно - говно, а другое однозначно рулит.
Ну вообще то раньше это сайт назывался TheLonghorn сейчас TheVista, туда дальше будет какой нибудь TheSeven или TheMidori 
главное суть сайта не поменялась, и это радует 
Vermillion_returned
Во-первых, тормозить будет только тот процесс, в котором в данный момент собирается мусор, т.к. сбощик мусора в каждом процессе свой. Так по крайней мере было в Singularity
Во-вторых, при правильном подходе можно сделать так, чтобы он вообще не вызывался, например, если процесс - это драйвер чего-то там, то возможно удастся его спроектировать так, чтобы он использовал фиксированные буферы памяти, запрошенные один раз при старте и не выделял память в динамике вообще, спроектировать свой пул памяти ну или что-то типа того.
Vermillion_returned, не нужно все воспринимать в лоб, буквально. Вполне очевидно, что никто не будет использовать для работы оси тот .Net Framework, которыя сейчас имеется. Под эту ось делают специальную версию дотнета, в частности, сборщик мусора там будт работать по другим алгоритмам. Рекмендую читануть пдф-нички из раздела про Singularity на сайте МС.
Кстати, сборщик мусора прекрасно справляется со своей работой в большинстве случаев, не особо подтормаживая систему. Какие-то заметные тормозо я лично наблюдал очень редко. К тому же, есть определенные рекомендации, как писат ьприложения так, чтобы они не нагружали сборщик. Аналогичные ограничения имеются и в рантаймах где нет сборщика. Например, в сишном рантайме есть проблема фрагментации памяти и скорости ее выделения изза поиска по списку. Идеальных решений не существует, так что нельзя сказать, что что-то одно - говно, а другое однозначно рулит.
Ну проблема сборки мусора существует, тем не менее. Со временем ее, возможно, как-то решат, но в языках типа С++ таких проблем нет. Сборщики, конечно, сильно упрощают работу программиста, но для плюсов тоже есть рекомендации типа использования стл-хранилищ с дальнейшим их переопределением вместо юзания непосредственно указателей, что позволяет избежать утечек памяти.
Vermillion_returned
Во-первых, тормозить будет только тот процесс, в котором в данный момент собирается мусор, т.к. сбощик мусора в каждом процессе свой. Так по крайней мере было в Singularity
Во-вторых, при правильном подходе можно сделать так, чтобы он вообще не вызывался, например, если процесс - это драйвер чего-то там, то возможно удастся его спроектировать так, чтобы он использовал фиксированные буферы памяти, запрошенные один раз при старте и не выделял память в динамике вообще, спроектировать свой пул памяти ну или что-то типа того.
При правильном подходе можно все сделать и на плюсах. Правильный подход - он вообще везде рулит. Написать всю ОС на управляемом языке - это похвально и в принципе правильно, но мы посмотрим, что из этого выйдет. Тут уже где-то слышал про ОС, написанную целиком на JAVA - , а тут на диалекте шарпа. Может веяние времени, может не веяние, но даже сейчас от асма полностью не отказались. Самые быстрые куски пишутся не на управляемых языках опять же. Пока что, по крайней мере. Плюс, тут многие ссылаются на закон Мура - мол, рано или поздно все равно процессор сможет выполниь все что угодно и с какой угодно скоростью. Но: 1) предел тактовой частоты уже практически достигнут в нынешней технологии; 2)Два процессора по 2 ГГц - это всегда медленнее, чем 1 процессор, который работает в 2 раза быстрее. 3)Как следствие п.2, скорость растет не пропорционально числу ядер, а скорее пропорционально корню из этой величины. Поэтому, если МС могли полагаться на закон Мура в 90-х годах, то теперь прийдется сильно попотеть над увеличением быстродействия, т.к. сделать программу более "параллельной" - это очень серьезная дополнительная работа, которую создатели процов переложили на него, вместо того, чтобы создать 40ГГц камни. К тому же, есть такие задачи, которые не распараллеливаются в принципе.
Кстати, Билл Гейтс еще до своего ухода дал понять, что в МС знают об этой проблеме:
Да, действительно происходит революция. В течение двадцати последних лет тактовая частота процессоров повышалась пропорционально росту числа транзисторов на подложке. А в ближайшие годы, хотя число транзисторов будет увеличиваться, тактовые частоты будут расти очень медленно, может быть, на 5% в год и достигнут 5-8 гигагерц, в самом лучшем случае, 10 гигагерц. Встречаясь с представителями компаний, производящих процессоры, я всегда прошу дать мне процессоры с частотой 20, 40 гигагерц, но они не знают, как это сделать.
Отсюда взято:
На сорока гигагерцах виста бы просто летала как птица. Еще раз повторю, что тот подход, который был у МС раньше - "железо рано или поздно догонит требования софта" - он себя изживает на текущий момент, имхо. Нужно придумывать что-то новое либо создателям железа, либо программистам. На текущий момент все выглядит так, что ужаться в требованиях прийдтся программистам. Та операционная система, коей посвящен сайт, как раз наглядно демонстрирует все эти проблемы.
да, господа, Vermillion_returned прав! такая многоядерность как в висте никому не нужна. Что нового - многоя дер и 16 гиг памяти поддерживал еще 2000 сервер (анвансед), так он работал на п100, чтов нем было не так, интерфейс не такой красивый, а может тормозов и глюков все-таки меньше?
Так ведь они же не меняют его все в один день. Кто-то только недавно купил, а кто-то - уже давно. Поэтому кому-то новая ОС ещё не нужна, а кому-то - уже пора.
Ну у кого 40-ггц проц есть, то тем конечно же можно на висту переходить. Или сразу же на vin7, причем без заметной потери в производительности.
Обычный АМДшный процессор на 3 гигагерца и 4 гигабайта памяти хватает ЗА ГЛАЗА, чтобы летала Виста БЕЗ свап-файла!!! И ЛЮБАЯ современная игра загружалась с максимальными установками БЕЗ ТОРМОЗОВ. Частота кадров в игре - это отдельная тема, это уже и от видухи и от драйверов зависит.
Но я это к тому, что даже такая посредственная конфигурация - уже больше чем достаточно для висты. Для 7й версии, уверен, будет также за глаза.
Vermillion_returned, я говорил, что в сях существуют аналогичные проблемы. понятно, что не со сборщиком мусора. аналогия в том, что сборщику мусора нужно пробежать по всему дереву сссылок чтобы отсеять неиспользуемые объекты, а сишному рантайму нужно пробежать по списку свободных блоков памяти чтобы найти подходящий при выделении. дотнетовому рантайму это делать не нужно, память выделяется последовательно и практически мгновенно.
Не совсем понял, что вы имеете ввиду под СТЛ хранилищами, но если вы про такие вещи как вектор говорите, то никаких преимуществ при выделении памяти он не дает, он просто делает работу с массивами данных более безопасной и удобной за счет того, что указатели спрятаны. Однако он периодически растет, и периодически выделяет память и копирует элементы (что собсно просиходит и в большинстве коллекций с изменяемым размером в других языках). Конечно, тот факт, что он выделяет память с запасом, позволяет делать поиск памяти реже, но это опять же оптимизация на уровне пользовательского кода, а не подсистемы памяти, и она, как я уже сказал, примерно одинакова у большинства языков.
Если правильно подходить к вопросу, то никакой фрагментации памяти не будет. Опять-таки, размер фрагментов значит очень много. Подробностей о работе виндовского дефрагментатора рассказывать не буду, отчасти потому, что глубоко не копал данную тему, но замечу, что жрет ресурсов он значительно меньше, чем сборщик мусора. Тем более, что памяти сейчас настолько много, что указанные проблемы имеют место быть все меньше и меньше. А чтобы вообще устранить влияние дефрагментации, рекомендую использовать связанные списки где возможно, а не векторы - тогда память использует все свободные дырки, а не ищет непрерывный блок. Насчет переопределения, приведу такой простой пример:
class CMyList : public list<CMyObject*>
{
CMyList() {};
~CMyList()
{
for(list<CMyObjects>::iterator it = begin(); it != end(); it++)
if(*it) delete (*it);
}
}
теперь, в коде программы мы можем писать:
CMyList list1;
for(int i = 0; i < 100; i++)
list1.push_front(new CMyObject());
И при любых обстоятельствах - при выходе из области видимости, например - список будет удален их памяти. при этом мне не надо явно где-то удалять все динамически созданные объекты. Ну чем не автоматическая уборка мусора? А память не фрагментируется, потому что используется связанный список. Даже если использовался бы вектор, то большого непрерывного куска памяти использовать не нужно было бы, т.к. хранятся-то только указатели, а не сами объекты. Не нужно заморачиваться с созданием конструктора копий опять же. Плюс, если дополнительно переопределить в векторе оператор [], то можно сделать так, чтобы возвращался не указатель, а именно сам объект, что позволит использовать оператор-точка, а не стрелку, что намного красивее и удобнее.
*точнее не сам объект, а ссылка (именно ссылка &, а не указатель *), что и позволяет использовать оператор "точка".
В связных списках есть 2 существенный недостатока:
1. Нет произвольного доступа к элементам (по индексу)
2. Операции клонирования, копирования и пр. на порядок медленнее, чем при использовании непрерывных блоков памяти при реализации оных
3. Даже последовательные итерации медленнее, хотя и не намного.
Именно эти причины в основном и являются определяющими при выборе паттерна реализации.
В связных списках есть 2 существенный недостатока:
1. Нет произвольного доступа к элементам (по индексу)
2. Операции клонирования, копирования и пр. на порядок медленнее, чем при использовании непрерывных блоков памяти при реализации оных
3. Даже последовательные итерации медленнее, хотя и не намного.
Именно эти причины в основном и являются определяющими при выборе паттерна реализации.
Вы невнимательно читали.
1)можно свободно то же самое сделать для вектора с указателями, а найти непрерывнокусок памяти для массива указателей гораздо проще, чем для массива объектов. Я использовал именно такие реализации на практике. Об этом я сказал в последнем абзаце.
2)я специально привел пример с указателями, которые не надо копировать/клонировать для занесения в вектор/лист. Еще раз поворю, можно возвращать не указатель объекта, а ссылку. А именно:
const_reference operator[](size_type _Pos); - это описание STL-вектора в MSDN.
значит, я могу сделать так:
CMyObject& CMyVector::operator[](size_type _Pos) { return (*(at(_Pos))); }
После чего к элементу можно будет обращаться не
myvect->SomeFunction()
а обычно, через точку:
myvect.SomeFunction()
Заметьте, никакого копирования/клонирования и иже с ним. А значит, и никаких проблем с производительностью.
Блин, вроде закрыл тег.
Вот реальный кусок кода, например. Никаких копирующих конструкторов.
class CMyObject
{
public:
CMyObject() {};
~CMyObject() {};
void Func1() {};
};
class CMyVector : public vector<CMyObject*>
{
public:
CMyVector() {};
~CMyVector()
{
for(size_t i = 0; i < size(); i++)
if(at(i))
{
delete at(i);
at(i) = NULL;
}
};
CMyObject& operator[](size_t pos)
{
return *at(pos);
};
};
//......
void Function001()
{
CMyVector vect;
vect.push_back(new CMyObject());
vect.push_back(new CMyObject());
vect.push_back(new CMyObject());
vect[0].Func1();
vect[1].Func1();
vect[2].Func1();
};
кстати, насчет фрагментации. Одно из решений - т.н. Куча с Пониженной Фрагментацией, уже реализован во многих компиляторах С++. Вот например :. Тут дефрагментация памяти не требуется в принципе, а значит и потерь производительности нет никаких.
Массивы указателей хороши, если объект сильно больше чем 4 байта (или 8 в x64). Вот в таких случаях на практике указатели в основном и используют (ну или управляемые ссылки в .NET), ну а если объект 4 - 8 - 16 байтов, то толку с такой оптимизации никакого. Фрагментация памяти гораздо больше за счёт того, что под каждый отдельный объект будет выделяться память и плюс под массив указателей.
насчет фрагментации памяти я уже сказал - это несуществующая проблема на текущий момент. Нынешние компиляторы делают управление кучи таким, что дефграментация памяти практически не нужна в принципе и вся вычислительная нагрузка равномерно распределяется по оси времени при выполнении программы. Разумеется, указанный кусок кода реален в том смысле, что он компилируется и демострирует определенные вещи. На практике объекты занимают, естественно, более нескольких байт, и , помимо прочего, содержат указатели на другие объекты. Во-вторых - тупо засирать память остатками от старых, но еще не удаленных объектов, до тех пор, пока их не удалит GC - это по моему мнению не есть рационально. Ведь многие программисты спокойно себе юзают тот же стандартный класс String, не задумываясь о том, сколько лишнего простанства поедается из-за активных манипуляций со строками. Плюс, больше работы достается тому же многострадальному GC.
Ну на счёт работы GC - всё зависит от типа приложения. Если это клиентский офисный софт или web-приложение. То здесь редкие разовые задержки несущественны и незаметно, ну а остальные случаи нужно рассматривать конкретно
Дело не только в "редких разовых задержках". Дело во всей концепции разработки софта, которая базируется на том, что программист соверешенно не приучен хоть как-то думать о быстродействии - пусть процессор думает, у него гигагерцов много и ядер уже часто более одного к тому же.
Насчет того, что офис не должен быть быстрым: для ручного набора - да, пожалуй, а если у вас программа использует MS Office в качестве сервера приложений для автоматического формирования xls- и doc-отчетов -- как тогда быть? Тут уже есть разница, 2 часа или двое суток будет выполняться работа.
А задержки не разовые и не редкие. Вот посмотрите , например. Отставание в разы - это уже как бы не разовая задержка. Самый быстрый из указанных продуктов, кстати, написан на С++, который сейчас активно предают анафеме в MS.
Начнём с того, что IE 7 и IE 8 не содержит managed-кода вообще.
Ну а про задержки на сутки вместо 2-х часов приведите пожалуйста пример
И без управляемого когда хватает криворукости, выходит. Насчет 2-х часов и 2-х суток - это я утрирую. Но если вы сходили по ссылке (а вы сходили), то вы заметили, что утрирую я не так уж и сильно.
В принципе в системе под какой-то стандартный язык, толи ява, тои шарп, востребованность есть. Никто не будет использовать ява и дотнет проекты, если есть аналоги, использующие апи данной ос. что такое ос вообще, по определению, это какой то документрованный набор высокоуровневых (относительно) функций, для реализации работы с железом. Во всяком случае для программиста это так. Это печально известный MFC для С++ с которым, как в той песне, столько пройдено. Но никто из моим знакомых, работавших с мфц не хвалил его ), скорее наоборот. Очевидно нужен удобный язык - шарп, ява.. Но в тоцй же хр илди висте вирт машина явы или фраймворк дотнета (и то и то по сути фраймворк) выступают между исходным кодом и апи ос. Фактически функции фраймворка пишутся на апи конкретной ос, и, естественно, что приложения непосредственно на апи получаются быстрее. Вот именно поэтому идея ОС, предоставляющая фраймворк в качестве апи мне кажется интересной. Но не надо ставить все с ног на голову, слохраняя апи, зачем то писать драйвера на фраймворке. Вот например зачем ати написала свой уе__щный (извините, можете банить, но других слов у меня нет) контрол центр на дотнете??? это же реально неудобно. конечный пользователь сталкивается в итоге с проблемой, которую он сам решить не может.. какой остается осадок от такого софта??
Это в вебе неважно, фраймворк это (ява, дотнет) или модуль (пхп) или сжи (перл, пхп опять же, питон, даже делфи )) ), там рез-т работы - хтмл текст и никакого железа. А в ос все по другому, поэтому очень важен корректный быстрый и удобный апи. Посмотрите на хромого (гугле хроме) он легко обощел все браузеры, будучи написанным с нуля, во всяком случае в смысле скорости яваскриптов и в плане соответсьвия стандартам.
вот такая философия, все в руках мс - если она реализует описанное, то будет заслуженно получать доход и рынок, если схалтурит, железо такого гне простит, закон мура давно неверен....
Vermillion_returned
Т.е. GC уже не ругаем, а ругаем разрабов IE?
Что вы - нет конечно. Мы хвалим разрабов ИЕ - они разработали такой невероятно быстрый и соблюдающий все международные стандарты браузер. Осталось только пожелать, чтобы они написали его на шарпе, после чего он станет работать еще быстрее.
По теме
- Microsoft запатентовала технологию воссоздания умерших людей в виде чат-ботов
- Microsoft представила свой сервис облачного гейминга Project xCloud
- Компания Microsoft погрузила на морское дно дата-центр
- Искусственный интеллект Microsoft обошел человека и конкурента от Alibaba в тесте на понимание полученной информации
- Microsoft патентует сканер отпечатков пальцев, встроенный в дисплей
- Microsoft представила платформу обучения ИИ Project Brainwave
- Microsoft достигла 5.1% ошибок в распознавании речи
- Бот Zo сказал, что Linux лучше Windows
- Чат бот Zo от Microsoft заговорил на запрещенные темы
- Microsoft Research создает гарнитуру дополненной реальности в виде обычных очков