Компания Microsoft выпустила (http://www.codeplex.com/singularity/Release/ProjectReleases....) второй релиз исследовательского проекта Singularity (http://research.microsoft.com/os/singularity/), в рамках которого разрабатывается прототип сверхнадежной операционной системы будущего, не базирующейся на текущем коде Windows. Исходные тексты доступны в виде Singularity RDK (http://www.codeplex.com/singularity) (Research Development Kit), распространяем под специальной MSR-LA (shared source (http://www.codeplex.com/singularity/license)) лицензией. В комплект включены исходные тексты ОС, утилиты для сборки и тестирования, документация по устройству системы. Кроме того для загрузки доступен установочный iso-образ со сборкой Singularity для x86 архитектуры.Особенностью Singularity, является то, что большая часть кода написана на одном из диалектов языка C#, включая код драйверов и системы ввода-вывода. На производительность это сильно не влияет, так как весь код опера...
URL: http://www.codeplex.com/singularity/Release/ProjectReleases....
Новость: http://www.opennet.me/opennews/art.shtml?num=18959
Решили сэкономить на разработчиках?
>Решили сэкономить на разработчиках?Если посмотреть на историю то всей индустрией ПО движет желание сэкономить на разработчиках. Иначе сидело бы пять тысяч программистов делая System 360 и писали бы по 20 отлаженных строчек в год.
>>Решили сэкономить на разработчиках?
>
>Если посмотреть на историю то всей индустрией ПО движет желание сэкономить на
>разработчиках. Иначе сидело бы пять тысяч программистов делая System 360 и
>писали бы по 20 отлаженных строчек в год.А мне почему-то кажется, что всей индустрией ПО в настоящее время движет желание создавать каких-то страшных и сложных монстров. Дабы вытряхивать бабло из кармана заказчика. Раньше ИТ служил для сокращения издержек, сейчас большая часть ИТ вообще непонятно зачем нужна.
Виртуальные и выдуманные потребности правят миром ИТ.
точно. тем не менее, этот пузырь уже почти лопнул, больше такого не будет.
>Решили сэкономить на разработчиках?...а потом как всегда - будут навариваться в 1 харю?
>Решили сэкономить на разработчиках?Не на разработчиках, а на тестерах. Танцы с бубном, как у qnx.
а что благородный дон понимает в данном случае под "танцы с бубном" ? Когда периодически выкладывают релизы на "поиграться"?
>а что благородный дон понимает в данном случае под "танцы с бубном"
>? Когда периодически выкладывают релизы на "поиграться"?Ну типа вам дается кульное право - забесплатно попахать на %s...
Непонятно, на кой понадобилось отказываться от проверенных и надежных аппаратных механизмоы изоляции и полагаться на "Software Isolated Processes"? %-(
В тех.докладе по первому релизу было вроде заявлено так, м.б. ко второму что-то изменилось? Надо почитать...
>Непонятно, на кой понадобилось отказываться от проверенных и надежных аппаратных механизмоы изоляции
>и полагаться на "Software Isolated Processes"? %-(Это Language-based protection?
>Непонятно, на кой понадобилось отказываться от проверенных и надежных аппаратных механизмоы изоляции
>и полагаться на "Software Isolated Processes"? %-(Да очень просто. Не надо переключать контекст system\user level, не надо переключать кеш TLB. Надежные и проверенные не значит эффективные.
Зачем отказываться от надежных и проверенных гужевых повозок в пользу этих новомодных автомобилей? :)
>Да очень просто. Не надо переключать контекст system\user level, не надо переключать
>кеш TLB. Надежные и проверенные не значит эффективные.Да, послушать вас - так софтварные решения надежнее и быстрее аппаратных.Очень убедительно звучит, ага.
>>Да очень просто. Не надо переключать контекст system\user level, не надо переключать
>>кеш TLB. Надежные и проверенные не значит эффективные.
>
>Да, послушать вас - так софтварные решения надежнее и быстрее аппаратных.Очень убедительно
>звучит, ага.По крайней мере ошибку в софтварной реализации исправить проще. Так что нужно искать баланс - вот разработчики Бесконечности его и ищут... бесконечно. :)
>Да, послушать вас - так софтварные решения надежнее и быстрее аппаратных.Очень убедительно
>звучит, ага.верим в непогрешимость софта для железняк? нуну
Этот "новомодный" автомобиль, в котором контекст system\user level не переключался, кажется, мы уже видели раньше, и назывался он DOS ;))
DRM в ней уже реализовали?
Это не надо, есть Plan 9
>Это не надо, есть Plan 9Не, не так. "Есть эмулятор Plan 9" :)
даже не сомневался, что m$ будет делать нечто отличное от innovation in the areas of systems, languages, and tools. они только этим и занимались.кто-то надоумил их перестать патентовать мышиные клики и вложиться в исследования. но, все равно, получается как обычно, в m$-style.
Chinese, ты тут п$$$шь а они дело делают
> весь код операционной системы компилируется в машинные кодыНе понял. То, вроде, писали, что вся эта шняга компилируется в байт-код и поэтому-то она якобы такая жутко безопасная и портабельная. Теперь пишут, что - в машинный код. Чем же она тогда лучше той же венды? Тем, что написана на каком-то китайском диалекте?
>> весь код операционной системы компилируется в машинные коды
>
>Не понял. То, вроде, писали, что вся эта шняга компилируется в байт-код
>и поэтому-то она якобы такая жутко безопасная и портабельная. Теперь пишут,
>что - в машинный код. Чем же она тогда лучше той
>же венды? Тем, что написана на каком-то китайском диалекте?+1 хотел сказать примерно тоже, но не нашел правильных слов.
лучше тем, что машинный код получается компиляцией из такого языка, где в принципе невозможны многие проблемы, связанные с произвольными манипуляциями указателями, т.е. выходы за пределы массивов, запись в уже освобожденную память, разыменование неинициализированного указателя, утечки памяти и т.д. Естественно, такие возможности сказываются на производительности.
Все эти проблемы невозможны в C#, покуда байт-код выполняется в .NET-песочнице. Машинный код с, например, дотнетовским сборщиком мусора -- это уже не совсем обычный машинный код.
Если я не ошибаюсь, то в С# байт-код перед выполнением компилится в машинный код, который затем кэшируется на будущее и выполняется. Процессор ведь умеет работать только с машинным кодом. А значит на чем бы вы не писали свои творения (хоть на asm, хоть на С, хоть на Java или Бейсике) в конечном счете все это тем или иным образом преобразуется в машинный код и исполняется.
Здесь, насколько я понял из новости, после написания эта ОС сразу компилится в машинный код, минуя стадию байт-кода (ну или не минуя). Для самой ОС это не критично, ИМХО.
Какая-то ява-генту получается :)
>Если я не ошибаюсь, то в С# байт-код перед выполнением компилится в
>машинный код, который затем кэшируется на будущее и выполняется. Процессор ведь
>умеет работать только с машинным кодом. А значит на чем бы
>вы не писали свои творения (хоть на asm, хоть на С,
>хоть на Java или Бейсике) в конечном счете все это тем
>или иным образом преобразуется в машинный код и исполняется.
>Здесь, насколько я понял из новости, после написания эта ОС сразу компилится
>в машинный код, минуя стадию байт-кода (ну или не минуя). Для
>самой ОС это не критично, ИМХО.Это ускоряет работу.
И притом значительно.
За счёт устранения издержек на функционирование виртуальной машины в т.ч. компиляцию кода JIT-компилятором.
С одной стороны.
А с другой - как только у нас вместо байт-кода оказался "честный" машинный код - скажем велкам переполнениям стека и прочим уязвимостям, порождённым ошибками програмирования.
А если писать ОС, которая будет выполняться в виртуальной машине.... То такая ОС, без сомнения, тормознёт любой PC :-)
>как только у нас вместо байт-кода оказался "честный"
>машинный код - скажем велкам переполнениям стека
>и прочим уязвимостям, порождённым ошибками програмирования.Ну что за бред? Язык не позволит писать небезопасные выражения, компилятор их не пропустит.
Потеря производительности компенсируется за счет того, что не нужно переключаться между kernel/user.
> Потеря производительности компенсируется за счет того, что не нужно переключаться между kernel/user.Это неимоверный бред, потому что вычисления (на которых теряется производительность) и ввод-вывод (для которогу нужны переключения контекста) - совсем разные вещь. Кроме того, нормальные люди пишут так, чтобы лишних переключений контекста было.
упс... и куда же денется на вычислениях производительность?
>упс... и куда же денется на вычислениях производительность?пойдет на проверку, что очередная запись в массив будет производиться в его пределах... на проверку, что указатель инициализирован... на сборку мусора...
Прошу прощения, но разве перечисленные Вами действия не производятся в любой нормально написанной программе? (ну разве что сборка мусора, но и ей можно управлять)
Или же ради производительности в компиляторе надо поотключать всякие проверки?
даже в "нормально написанной" с виду программе далеко не всегда и не везде есть эти проверки. Отчасти из-за забывчивости, отчасти из-за того, что производительность падает, отчасти из-за невозможности ошибки в силу самой логики программы. На последнее часто уповают программисты и эти проверки пропускают там, где они должны быть. Вот и имеем то, что имеем. В языках типа C#, Java, Sing# и прочих обращение к массиву в принципе не может быть выполнено вне его границ, потому что код обращения к элементу массива генерируется компилятором так, что всегда включает в себя проверку на вхождение в границы. Указатель в принципе не может указывать на освобожденный участок памяти, потому что объект освобождается только по обнулению последнего указателя на него. Если же указатель содержит null, то после обращения по такому указателю немедленно вылетает исключение, ибо проверка на null осуществляется всегда при его разыменовании, и программист на это повлиять не может.
>> весь код операционной системы компилируется в машинные коды
>
>Не понял. То, вроде, писали, что вся эта шняга компилируется в байт-код
>и поэтому-то она якобы такая жутко безопасная и портабельная. Теперь пишут,
>что - в машинный код. Чем же она тогда лучше той
>же венды? Тем, что написана на каком-то китайском диалекте?Тем, что используется "language-protected" подход (см. http://en.wikipedia.org/wiki/Language-based_system).
Такой подхот можно воплотить, используя байт-коды и JIT, но не обязательно.
>>> весь код операционной системы компилируется в машинные коды
>>
>>Не понял. То, вроде, писали, что вся эта шняга компилируется в байт-код
>>и поэтому-то она якобы такая жутко безопасная и портабельная. Теперь пишут,
>>что - в машинный код. Чем же она тогда лучше той
>>же венды? Тем, что написана на каком-то китайском диалекте?
>
>Тем, что используется "language-protected" подход (см. http://en.wikipedia.org/wiki/Language-based_system).
>Такой подхот можно воплотить, используя байт-коды и JIT, но не обязательно.Проще говоря - ничем не лучше. В сухом остатке, так сказать.
И есть немалая вероятность, что вместе с водой выплеснут ребёнка.
Просто если при аппаратном переключении контекста код "запирается" в отведённом ему месте усилиями процессора (а механизм этот существует ещё с 80286 и весьма неплохо отлажен к текущему моменту) то нам теперь предлагают взвалить всё это дело на плечи компилятора, аргументируя это тем, что программную ошибку-де легче поправить, чем аппаратную....
Так-то оно так, то:
1) Программную ошибку ещё надо найти. А некоторые уязвимости висели в стека TCP ВинНТ ужо лет 10. За это время успело смениться не одно семейство процов. А потом надо ещё её исправить так, чтобы это не поставило, извиняюсь, раком пользовательские приложения.
2) Аппаратная ошибка всё равно останется, будь твой язык хоть трижды доверенным. И будет влиять, падла такая.
3) Что-то я не помню о аппаратных ошибках, связанных с переключением контента, с ранних 20286.... ;-) А вот баги в виртуальных машинах находят (и правят) регулярно.....По-хорошему, господам из M$ над бы не метаться за стадом зайцев, а довести до ума хотя бы что-то одно.
А то какой продукт не возьми - везде имеем особенности национального индусского программирования.
То официально выложенный русский пакет совместимости для 2003 офиса криво сохраняет файлы в формате 2007-го (английский конвентер такого бага, слава богам, лишен), то актив-синх выдает 1/3 лога в UTF-8, а оставшиеся 2/3 в WIN 1251, то в логах у нас сообщения "Ошибка: Код 0. Сервис запущен успешно", то в Шаре-Поинте приходится танцевать с бубуном, чтобы он не сбрасывал текущие позиции в списках (писать вещи вроде a.selected=a.selected, LOL), то Ексель по сети большие файлы (~17Мб) сначала сохранить не может, потому как операция сохранения не может по его мнению длиться более 5 сек, а после патча на сей баг - начинает эти самые файлы уродовать иногда, то кластеры бродкаст-шторм устраивают.
>[оверквотинг удален]
>Просто если при аппаратном переключении контекста код "запирается" в отведённом ему месте
>усилиями процессора (а механизм этот существует ещё с 80286 и весьма
>неплохо отлажен к текущему моменту) то нам теперь предлагают взвалить всё
>это дело на плечи компилятора, аргументируя это тем, что программную ошибку-де
>легче поправить, чем аппаратную....
>Так-то оно так, то:
>1) Программную ошибку ещё надо найти. А некоторые уязвимости висели в стека
>TCP ВинНТ ужо лет 10. За это время успело смениться не
>одно семейство процов. А потом надо ещё её исправить так, чтобы
>это не поставило, извиняюсь, раком пользовательские приложения.Если это именно ошибка (то есть несоответствие спецификации), то её исправление раком никого не поставит. Кроме админов, канеш.
>2) Аппаратная ошибка всё равно останется, будь твой язык хоть трижды доверенным.
>И будет влиять, падла такая.Угу. Поэтому речь о том, чтобы ЦП (именно ЦП, а не вспомогательные юниты) был максимально простым; тупым, если хотите. Тогда аппаратных ошибок будет немного...
>3) Что-то я не помню о аппаратных ошибках, связанных с переключением контента,
>с ранних 20286.... ;-)http://download.intel.com/design/processor/specupdt/318733.pdf , раздел "Errata". На всякий случай уточню, что реальную критичность проблем надо додумывать самому, красивых надписей "Critical" на красном фоне ждать не стоит. :)
> А вот баги в виртуальных машинах находят
>(и правят) регулярно.....Виртуальные машины и компиляторы - вещи немного разные:). У компилятора свободы больше на порядок. Но ошибок и в компиляторах хватает, канеш.
Я не знаю, какие аспекты работы 80286 Вы имеете в виду, но хочу напомнить, что главной фичей в 80286 была сегментная адресация, заставлявшая программиста переключать сегменты. Этот механизм порождает кучу сложностей при программировании на ассемблере и при написании компилятора, и даже при предельно эффективном программировании сильно тормозит вычисления. (Я не стал упираться в 16-битное ограничение размера сегмента - это можно исправить; я говорю именно о принципе сегментирования.) В 80386 добавили ещё два сегментных регистра, но программисты предпочти использовать Flat-модель, когда используется один сегмент (точнее, все четыре сегмента (CS, DS, ES и SS) совпадают и покрывают всё адресное пространство), а защита памяти производится гораздо менее гибким механизмом страниц (снижение гибкости обусловлено фиксированным размером страницы).И вообще, аппаратура никогда не сможет эффективно отслеживать ошибки - это надо возлагать на компилятор и на runtime проверки (если стандарты языка не предусматривают свободы программиста делать опасные и неотслеживаемые компилятором вещи). Аппаратная поддержка таких проверок сразу породит проблемы совместимости, когда на одних моделях процессоров что-то будет работать, а на других будет сбоить.
не смог найти, откуда качать исходники и забил
Не работает:BL: Unrecognized kill action 0xFFFFFFFF!
BL: Halt! blsingularity.cpp(720)
А где скриншоты? :)))
Уверен, сейчас народ кинется прикручивать дрова NVIDIA к этому чуду техники. ЛОЛ!> В Singularity RDK 2.0 реализована поддержка архитектуры AMD64, представлен новый загрузчик, улучшена поддержка ACPI, разработан SMB-клиент.
Еще лет 5 и она научится читать NTFS а так же ext3
ЛОЛ
>
>Еще лет 5 и она научится читать NTFS а так же ext3
>Уже умеет. http://www.opennet.me/opennews/art.shtml?num=17065
> сверхнадежной операционной системы будущего, не базирующейся на текущем коде WindowsЛОЛ
> На производительность это сильно не влияет
влияет на оптимальность исполняемого кода
> наиболее критические низкоуровневые компоненты написаны на языке ассемблер и Си.
значит таки влияет? напрасно они на асме лабают, прямо в исполняемом коде круче. скоросшивателем перфокарту продырявил - и пофиксил баг.
> Singularity не является микроядерной ОС, весь код выполняется в режиме ядра в рамках одного процесса.
интересно, как же реализована сверхнадёжность? разработчики мамой клянутся, что в их коде нет багов?
выполнять код в режиме супервизора на процессоре, имеющем MMU - это вообще онанизм. гораздо надёжнее выделить драйверу адресное пространство порта ВВ - и не париться.сколько бабок выбрасывают, фтопку
>интересно, как же реализована сверхнадёжность? разработчики мамой клянутся, что в их коде
>нет багов?)))
>сколько бабок выбрасывают, фтопкуэто отвлечение внимания студентов от юникс систем, чтобы они не дай Бог, не просекли что есть что.
Почитайте где-нибудь про организацию ОС с приложениями в управляемом коде и не задавайте глупых вопросов.
Прочитайте, сколько раз уже обходили эту защиту. К тому же, кроме програмных бывают и апаратные баги.И вообще, большинство програмистов думает статически - они думают что в момент выполнения их кода вся вселенная стоит и ждёт пока он закончится, что в системах защиты в корне не правильно. Для систем защиты вообще отдельный, параноидальны язык надо использовать, который ни на что не надеется и всё проверяет и перепроверяет (например как "perl -T" поступает с входными данными) и не допускает, например, выполнять операции уровня ядра с даными, которые подконтрольны userspace.
Managed-code - это громадный шаг вперёд по сравнению с Си, но он всё ещё допускает операции которые могут привести к пробитию защиты. Расчитывать только на managed-code и security-manager пока ещё глупо. Ещё один слой защиты - апаратный, не помешает.
>Managed-code - это громадный шаг вперёд по сравнению с Си...Сильно. Это все равно, что сказать: автомобиль - это громадный шаг вперёд по сравнению с двигателем внутреннего сгорания...
>Прочитайте, сколько раз уже обходили эту защиту. К тому же, кроме програмных
>бывают и апаратные баги.
>
>И вообще, большинство програмистов думает статически - они думают что в момент
>выполнения их кода вся вселенная стоит и ждёт пока он закончится,
>что в системах защиты в корне не правильно. Для систем защиты
>вообще отдельный, параноидальны язык надо использовать, который ни на что не
>надеется и всё проверяет и перепроверяет (например как "perl -T" поступает
>с входными данными) и не допускает, например, выполнять операции уровня ядра
>с даными, которые подконтрольны userspace.Ага. А как тогда файл открыть, если ядро прочесть строку с именем файла не сможет? :) Не так уж всё просто.
>Managed-code - это громадный шаг вперёд по сравнению с Си, но он
>всё ещё допускает операции которые могут привести к пробитию защиты. Расчитывать
>только на managed-code и security-manager пока ещё глупо. Ещё один слой
>защиты - апаратный, не помешает.Если в нём не будет ошибок, которые нельзя обойти, то не помешает. Почитайте errata от производителей самых распространённых в мире процессоров на досуге. Внимательно почитайте.
от логических ошибок и описок оно тоже защищает ? :)
Беда в том, что MS со своим мощным маркетингом опять может сделать всех на реализации чужой хорошей идеи, даже если реализация эта будет далеко не лучшей.А хорошие проекты, вроде JNode и Inferno рискуют остаться на втором плане из-за того, что комьюнити недооценивает перспективу ОС с управляемым кодом.
Поверьте, в MS знают, что делают.
да ладно проект в любом случае интересен ...
>да ладно проект в любом случае интересен ...плохо что его майкрософт делает
>>да ладно проект в любом случае интересен ...
>
>плохо что его майкрософт делаетЕсть и аналогичные свободные проекты. Как минимум, это JNode и Inferno. А все внимание к Singularity - маркетоиды работают.
Потому что через 10 лет Singularity будет на моей машине, а JNode с Inferno где-то далеко-далеко.P.S. ЛОР в дауне, судя по количеству странных каментов
Товарищи! Смотрю описание JNode и вижу: некрософт опять стырили чужую идею! Но JNode это опенсорсный проект, а Singularity - УГ.
>Товарищи! Смотрю описание JNode и вижу: некрософт опять стырили чужую идею! Но
>JNode это опенсорсный проект, а Singularity - УГ.Эта идея ещё постарше будет.
>Товарищи! Смотрю описание JNode и вижу: некрософт опять стырили чужую идею! Но
>JNode это опенсорсный проект, а Singularity - УГ.Давным-давно в далёкой галактике жил-был Никлаус Вирт.
И вот придумал он однажды Oberon.
А его ученики на базе Oberon сделали Bluebottle.Хорошая ОС, которая давно существует.
Некоторые из авторов трудятся на MS.http://dir.osrc.info/Bluebottle
Ссылочки там есть.
>BluebottleЭто они в честь Бредбери назвали?
Неумолимо надвигается эпоха электронного концлагеря. Придётся скоро собирать рюкзаки и валить в лес.
По поводу исходников - это пилюля для очередных судебных разборок. Потом будут пальцы гнуть что у них чо-то там опять заимствовали незаконно. Некрософтом управляют одни аферисты и я даже нюхать не буду их перхотявые исходники. Их "гениальность решений" подчёркнута уже реализованными продуктами, и поэтому я уж лучше "Крокодил" полистаю ради смеха, чем их требуху.
>Неумолимо надвигается эпоха электронного концлагеря. Придётся скоро собирать рюкзаки и валить в
>лес.А коллайдер таки уже запустили?
А всё-таки почему про plan9, inferno, jnode ничего не слышно? Все только плюются жаль что идею майкрософт реализует или вот опять наворовали и ничего с этим не делает
>А всё-таки почему про plan9, inferno, jnode ничего не слышно? Все только
>плюются жаль что идею майкрософт реализует или вот опять наворовали и
>ничего с этим не делаетне слышно тем, кто не слушает. микрософт умеет пеарить и продавать, а делать что-то хорошо не умеет
MS делает свои продукты ровно настолько качественно, насколько необходимо, чтобы извлечь максимальную прибыль.
>А всё-таки почему про plan9, inferno, jnode ничего не слышно? Все только
>плюются жаль что идею майкрософт реализует или вот опять наворовали и
>ничего с этим не делаетapt-cache search plan9
Хочу выразить глубокую признательность (или неприязнь, сам ещё не решил), тому товарищу который сообщил об OS Inferno.
2-й день , в перерывах между работой, читаю об этой удивительной ОС и о языке Лимбо.
Сцуко (простите за новомодное ругательство), такая штука классная ...
Но:
1. там tk - смерть простым пользователям;
2. там нет поддержки 64-бит процессоров - смерть маинстриму.
3. Вроде для embedded должно хорошо подойти, дык она на всякое старьё портирована. Которого уже минимум как 5 лет в продаже нет. Ну это за исключением умирающего 386.Потому и не решил, то-ли благодарность в приказе объявить, то-ли строгоча влепить, тому товарищу, что реплику подал о данном чуде.
инферно клон plan9 читай про неё и про протокол 9p
можно ещё про minix3 почитать и про dragonflybsd
Ага, и plan9 заработает на моём железе, прямо сейчас. А Inferno как гостевая ОС и среда разработки выглядит очень интересно. Да-да, пингвин, жаба, php, solaris, oraсle и прочие питоны - идеальная кормушка. Но и о будущем забывать не стоит. А про plan9 можно забыть как про несбывшийся сон. Пока линукс маркетируется наравне с "ентерпрайз", другим ОС хода не будет. А среды разработки дорогу себе всегда пробивают. Вон, - питоноговнище, какой популярный ! Всякие скалы никому ненужные, и прочие лиспообразные изнатрахатье и то находят себе пользователей. А лимбо красив и натурален для параллельного программирования, тем и интересен. Так, что скорее благодарность надо выносить. На том и постановим !Приказ Barmaglota, N°1:
Товарищ "F on 18-Ноя-08, 14:38" !
Вам, выносится огромная благодарность, с занесением в трудовую книжку !
Затаив сердце читал ваш пост 19/11. Что же меня ждет?
Все-таки благодарность, ура! Спасибо.