Выкладываю обещанный обзор существующих распределённых систем. Приступаю к описанию целей проекта.

Присоединённый файл ( Кол-во скачиваний: 25 )
 _____________________________________________________________________.pdf.zip 117,86 Kb

Неужели никому не интересна моя тематика? 

Что поделаешь, такова судьба пишущих ядра . Линус Товальдс тоже в одиночку начинал и надо отдать ему должное, в демагогию не ударялся, а просто представил общественности почти готовое ядро. Правда ему было легче, т.к. для получения полноценной ОС ему достаточно было лишь откомпилить самые необходимые приложение (вроде bash или vi), которые распространялись в виде исходников. И операционка готова! Вам же будет сложнее, так как никакого мат. обеспечения под Вашу ОС пока ещё нет...
Вам бы было легче, если бы вы реализовывали не полноценную ось, а какое-нибудь объектно-ориентированное расширение для одной из существующих осей. Тогда если оно действительно было такое удачное, то можно было бы существующие проекты постепенно переносить на него. А так вы один...
Все вышеперечисленное - мое субъективное ИМХО. Спорить не буду.

P.S. Извиняюсь, если вдруг допустил какие ошибки в именах собственных. Не линуксоид я. Просто хотел разжевать чужой опыт.

чем-то напоминает
http://rus-os.narod.ru/
 

Улыбнуло, гугл умрет от зависти   

Линус Торвальдс писал реализацию Unix на 386-том процессоре. В его распоряжении был готовый каркас архитектуры и системные вызовы. А начинал он с улучшения Minix. Я же не хочу писать очередной клон Unix, а пытаюсь понять современные нужды и выработать основные черты НОВОЙ архитектуры (ни в коей мере не пытаюсь себя сравнивать с Торвальдцом - мне до него в области системного программирования и знания архитектуры x86 далеко). Короче, я к тому клоню, что прежде чем что-то кодировать нужно знать, что именно… а вот с этим пока и проблема. Сейчас я пока занят статьёй, в которой формулирую требования к будущей системе с учётом всего того, что есть и что нужно (на мой субъективный взгляд). 

Почему нельзя для распределенных вычислений использовать существующие операционные системы?

Добавлено через 56 секунд
Прежде чем дергаться такое писать, нужно хотя-бы одну распределенную программу написать, ну хотя-бы многопоточную))

концептуальнык конфликт. осьминог (т.е. окотпус) является централизованной системой.
в центре - мозг. ноги идут радиально.

Это название возможно отражает некоторые нестыковки, которые пойдут далее.


рекомендую изучить существующие решения, которые вы не затронули.
вы разделили на т.н. middleware не то, что является концептуально middleware.
напр. т.к. IPC существует и штатное, к IPC нельзя относиться как к механизму отдельному от OS.
кроме того вы не затронули вообще существующие системы распределенных вычислений, как то анализ 

• 1. High Performance Computing
• 2. High Throughput Computing + Voluntary Computing
• 4. Group Communication/Process migration

Вы также не определились какую из этих задач вы пытаетесь решать/решить.
Заметьте, что решение распределенной ос не имеет смысла для решения пунктa 2.

могу вам сказать так: все проекты ОС, которые вы перечислили являются чисто академическими.
и анализ их способностей в индустрии не совсем известен. Их разрабатывают research labs. и пока практического применения этому по нет, ровно как и базы.

Еще, сама сфера распараллеливания вычислений не совсем понятна с т.з. соотношений 
выгоды/вклада ведь:

• не каждая вычислительно сложная задача параллелизуема .. как бы сказать can be parallelized.
• не каждая параллелизированная задача масштабируема
• не каждое масштабируемое решение масштабируется до бесконечности.

т.е. можно сделать расчет, что начиная с масштаба М есть выгода, а до масштаба М дойти нельзя.

И еще о выгоде: сегодня ВСЕ серьезные проекты open-source находятся под крылом фондов индустрии. Фирмы как IBM, Microsoft, Sun, HP, SGI и т.д. вкладывают человек-месяцы в разработки таких вещей как:

• ядро линукс
• драйвера
• разработки больших приложений и библиотек.

т.е. нужны "фонды" и работники на полную ставку.
Если вы хотите привести пример линукс, как пример "коллоборативной работы добровольцев", то поинтересуйтесь поглубже, что такое kernel janitors, и т.д.
Я хочу сказать, что парадигма открытого ПО больше помогает корпорациям в создании базы тестировщиков, чем увеличивает темп разработки. И еще, заметьте что самые продуктивные программисты будут работать за деньги, как это и происходит с линуксом.


У вас есть такие фонды ?
Скажем так: в России только ГазПрому под силу такой проект ;-)


В заключение, я не могу не согласиться с Lazin-ым: 
вам пока не хватает, ИМХО, базовых и практических знаний в этой сфере.


Почитайте и поковыряйтесь, или докажите что мы ошибаемся.

Удачи.

Добавлено через 9 минут и 48 секунд
хотя бы это:

да, только это решается именно в сфере HTC, a не на уровне ОС.
и уже довольно не плохо решается.

можете пояснить это предложение ? 
слишком "много букв"....
то ли мне кажется что доступ к данным не представляет собой ... никакой проблемы посредством существующих средств, то ли непонятно где эти данные, и почему подкачать автоматом библиотеку поддержки этого формата не решит проблемы.
т.е. если они у пользователя на компутере, то ... куда мы их распределять будем ? а они конфиденциальны ?
прямо напрашивается нехорошее слово.

или вот пример:

и:

не стыкуется, возможно т.е. я не понимаю что именно вы видите главным в простоте и красоте юниксов.
Я напр. как раз вижу в файловой абстракции + базовых операциях ( read/write/exec/fork/ioctl и т.д. )

ИМХО: простота и красота в файловой абстракции , которая и является недостатком вследствии ее ограниченности.

Можно, но не очень удобно. Хотелось бы проще это делать. Но я бы поставил упор на удобстве использования ресурсов других компьютеров, а также на поиске информации.



Распределённую программу я писал только одну, многопоточных – много. Но вы правы, у меня недостаточно опыта в области распределённого программирования. Но можно я хотя бы попробую?   



Я с вами согласен – старое название не совсем подходит – оно подвернулось мне, когда я не уделял должного внимания распределению и децентрализации. 

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



Полностью с вами согласен.



Да, файловая парадигма очень красива, мощна и вместе с тем ограничена (например, в сравнении с ОО парадигмой). 

Ну что тут скажешь... удачи, может что-то из этого и получиться, библиотека какая-нибудь, или программа...
PS
Кстати, чем плох для этих целей erlang?

Я не знаю, что это такое - сейчас открою, почитаю.

кхм... хотел бы услышать пример ограниченности парадигмы "всё есмь файл" в контексте нашей дискуссии, т.е. в контексте оперативной системы... распределенной оперативной системы.

Ярким примером того является Plan 9 – в этой системе почти всё есть файл, включая даже процессы. Системные вызовы, соответственно, в основном сводятся к открытию, чтению, записи и закрытию файла. В системе Plan 9, как ни в какой другой и проявляется слабость файлового представления сущностей. Эту слабость иллюстрирует существование в ней системных вызовов, отличных от вышеперечисленных, семантически не вписывающихся в файловую парадигму (например, вызовы управления разделяемой памятью). Кроме того, по сути, устройствами управляют при помощи текстовых команд, читая и записывая в соответствующие им файлы текстовые строки. Другими словами команды read и write в данном случае служат только шлюзом, направляющим сложные команды управление в ту либо иную сущность, а вся логика управления прячется в тексте команды.