Saturday, December 27, 2008

Singularity?

Удалось запустить Singularity под эмулятором - она запустилась только под виртуальной машиной Microsoft(Microsoft Virtual PC/). Где то месяц назад пытался запустить под bochs и VMWare но в обоих эмуляторах она не запустилась - точную причину ошибки не помню, под Virtual PC она тоже не сразу запустилась - в стандартном примере настроек было указано 512 метров памяти - при запуске вывалилась ошибка, что столько памяти виртуальная машина выделить не может, оказалось для запуска нужно около 400 метров памяти в виртуальной машине(стандартных 128 мало), если памяти мало запуск(загрузка самой ОС) выдает что не может выделить достаточно памяти. После запуска появляется командная строка - с очень маленьким количеством команд. В общем не впечатлило - как демонстрация концепции в общем не плохо - но документация года три назад меня больше понравилась - а пока видно основной недостаток для демонстрации требование в пол гигабайта мне кажется много. Я думал что за три года они достигли больших успехов. По сравнению с Minix(концепция близка) и даже другими миниос - демонстрация не очень.

Ну а идея в общем то не плоха использовать для всех компонентов управляемый код(только загрузчик на C), но идея не уникальна ОС на java тоже существует, например JNode и требования по описанию ниже(сам не пробовал).
Идея:
  1. ограничить коммуникацию между приложениями и ядром только сообщениями;
  2. описание в заголовке приложения всей требующихся ему ресурсов и возможностей(нужен ли доступ к сети, возможности и потребность в памяти);
  3. возможность перезапуска приложения при сбое;
  4. отсутствие требования к смене контекста и блокирования доступа к чужим страницам, так как доступ к памяти полностью управляется средствами языка(Не очень критичное улучшение, так как все эти операции часто контролируются аппаратно, например x86).
- уже реализовано в других операционных системах и как следствие имеет общие с ними проблемы:
  1. накладные расходы по передаче сообщений между элементами(MINIX - обычно это ограничение указывается для него);
  2. реализация части функция вне ядра в виде сервисов добавляет дополнительные затраты(опять таки MINIX), хотя в принципе при хорошо продуманном интерфейсе это не столь существенно и так работает графика в Vista и Linux(Xсы).
Ограничение возможностей для приложений, в распостраненных ос, очень часто расширяют для особенных приложений, из-за ошибок в этих приложениях эта защита преодолевается. И как следствие, эта система не всегда работает особенно при увеличении популярности ос.

И решением этой проблемы на мой взгляд есть:
  • проверка кода и требование от него максимальной прогнозируемости(на стадии разработки обычно при более менее коде, без разнообразных ухищрений, что приводит к снижению эффективности на первый вгляд но дает прогнозируемую эффективность, что гораздо важнее), и
  • максимальному продумыванию интерфейсов связи, с блокировкой на этапе проектирования всех возможных дыр(простота залог качества), так как верить в то что компилятор отследит все ошибки сомнительное решение - его пишут тоже люди, лучше продумать и дать все нужные интерфейсы чем потом добавлять изощерения для получения дополнительных возможностей.

Достаточно интересным примером я считаю минимальное количество функций доступных приложению в Linux(как и Unix) и простота и универсальность этих функций и предоставляемых абстракций. Абстракции в Inferno(расширение концепций Unix) мне показались немного излишними, но возможно если их более точно понять, что под ними скрывается они окажутся даже более удобными и универсальными - пока я по описанию не очень точно понял смысл понятий на которых они основываются(отличие от концепций Unix). Но они достаточно эффективны, так как позволяют выполнять действия такие как копирование контента между 2 узлами управляемое с 3 достаточно эффективным через передачу управления непосредственно на первых 2 узла с передачей на 3 только статистики(очень похоже на самостоятельное управление передачей устройствами SCSI), вопрос безопасности и получения доверия между этими узлами в принципе решаем и при важности скрытия источника и приемника информации(непосредственно узлы не должны иметь полных данных) вполне решаем.

No comments: