| Версия для печати темы
Нажмите сюда для просмотра этой темы в оригинальном формате |
| Форум программистов > Клуб юнуксоидов > Разработка новой ОС |
| Автор: Абабо 2.3.2009, 17:04 |
Модератор: Сообщение скрыто. |
| Автор: MAKCim 2.3.2009, 17:30 |
| без концептуальной "изюминки" (хотя бы пока теоретической) смысла в разработке такой ОС нет (если не брать в расчет обучение и повышение скилов в системном программировании) у тебя есть такая "изюминка"? |
| Автор: UniBomb 2.3.2009, 17:37 |
| Зачем темы дублировать ? http://forum.vingrad.ru/forum/topic-249684/kw-operating-system-операционная-система.html |
| Автор: rebex 2.3.2009, 20:49 |
| А смысл разработки новой ОС ? =) |
| Автор: powerfox 2.3.2009, 22:35 | ||
|
| Автор: Абабо 3.3.2009, 15:38 |
| Есть там изюминка. Кое-что изюмистого уже выложено (см. статью "Рефлексивный интернет"). будут и ещё изюминки... Я только открыл и наполняю форум... потому пустой (но уже кое-что есть, будет рости) |
| Автор: MAKCim 3.3.2009, 17:10 |
| Абабо, что мешает реализовать свои идеи в уже существующем linux? в статье кстати про это и написано |
| Автор: Абабо 6.3.2009, 18:28 | ||
| Внятное и простое введение в мои архитектурные концепты в следующих тезисах: 1. Хост – всё, что имеет микропроцессор и выход в Интернет. 2. Система – множество всех хостов. 3. Хосты содержат объекты (одиночное наследование классов, множественное наследование интерфейсов). 4. Типы это объекты, описывающие классы. 5. Объекты могут взаимодействовать друг с другом только посредством синхронного вызова метода. 6. Компоненты – объекты, методы которых могут быть вызваны объектом на другом хосте. 7. Компоненты есть долгоживущие объекты (сохраняются на энергонезависимых устройствах хранения). 8. Типы являются компонентами. 9. Каждому компоненту соответствует глобально уникальный идентификатор (GUID). 10. При копировании компонента новая копия получает новый GUID, а при перемещении GUID сохраняется. 11. Некоторые компоненты являются реплицируемыми и обладают уникальным идентификатором реплики (RUID). 12. При копировании и перемещении реплицируемого компонента его RUID сохраняется. 13. Типы константны и являются реплицируемыми компонентами. 14. Система поддерживает глобальный поиск GUID компонентов по Prolog-подобным запросам, оперирующим отношением наследования, RUID и другой информацией. 15. Интерфейс – компонент, описывающий набор методов. 16. Интерфейсы константны и являются реплицируемыми компонентами. 17. Существуют только интерфейсные ссылки, объектных ссылок не бывает. 18. Интерфейсная ссылка на компонент может быть получена только через системный вызов, берущий в качестве аргумента GUID требуемого компонента и ссылку на требуемый интерфейс. 19. Систему пронизывает множество потоков. 20. Объект, у которого внутри нестатического метода выполняется какой-то поток, считается запертым. 21. Внутри нестатического метода объекта может находиться не более одного потока. 22. Поток может вызывать нестатический метод с ожиданием и без. 23. При вызове с ожиданием в случае запертого объекта вызывающий поток будет блокирован, ожидая отпирания. 24. При вызове без ожидания в случае запертого объекта вызывающий поток сгенерирует соответствующее исключение. 25. Ссылка на компонент может быть получена только при наличии достаточных полномочий, в противном случае будет сгенерировано исключение. 26. В системе существуют учётные записи – компоненты, описывающие пользователей системы (люди или программы). 27. Право есть возможность получения ссылки заданного интерфейса на заданный компонент. 28. Каждый компонент ассоциирован с учётной записью – его хозяином. 29. Компонент имеет все права на компонент с тем же хозяином. 30. Назначение права есть триада: [GUID компонента, RUID интерфейса, флаг доступа (разрешён/запрещён)]. 31. На хосте существуют группы – объекты, описывающие набор назначений прав на компоненты данного хоста. 32. Учётная запись входит в одну или несколько групп, определяющих набор её прав (при отсутствии назначения или при наличии хотя бы одного запрещающего назначения – право отсутствует). 33. Компонент имеет права своего хозяина. Кого заинтересует зову на форум: http://ababos.ipb.su/
|
| Автор: nerezus 9.3.2009, 12:08 | ||
Мне почему-то вспомнился луч поноса сразу =) |
| Автор: Severyanin 14.3.2009, 05:06 | ||||
А потоки тоже между собой будут взаимодействовать только синхронно? Тогда вряд-ли получится сделать нормальную многозадачность. Надеюсь, Вы не собираетесь ваять очередной клон MenuetOS, которая годится только на поиграться. А HAL свой писать собираетесь?))))) |
| Автор: Абабо 18.3.2009, 15:33 | ||
Почему? |
| Автор: Lazin 28.3.2009, 18:30 |
| посмотрел код, с такими темпами развития, можно даже обсуждать нечего Добавлено через 37 секунд в общем, все это только слова и ничего более, чего-то похожего даже отдаленно на разработку ПО там не происходит... |
| Автор: Абабо 28.3.2009, 20:26 |
| К сожалению, скорость написания кода на самом деле достаточно низкая. В своё оправдание могу лишь посетовать на временный недостаток в досуге. |
| Автор: bilbobagginz 28.3.2009, 23:35 | ||
угадай почему так мало реально различных ОС в мире |
| Автор: Абабо 29.3.2009, 00:31 |
| Жаль только, что никто ни в чём толком не заинтересован. Ведь гораздо приятнее праздно покритиковать, а то и позубоскалить, а вот разобраться в предлагаемых идеях, внести коррективы и усовершенствования, принять участие в работе никому не надо... |
| Автор: MAKCim 29.3.2009, 09:47 |
| Абабо, извини, но сначала продемонстрируй что-нибудь рабочее...как Линус например это раз во-вторых, у меня есть большие сомнения насчет твоего профессионализма в третьих, я не вижу "изюминки", зато я знаю кучу уже существующих распределенных систем типа http://ru.wikipedia.org/wiki/%D0%9E%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D1%8B%D0%B5_%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D1%8B итого много шума из ничего отмазки типа нет времени не принимаются: на форуме у тебя же есть время писАть а когда начинается пиар того, чего еще нет даже на уровне самой примитивной архитектуры, это отталкивает |
| Автор: bilbobagginz 29.3.2009, 10:10 | ||
| Абабо, не буду тут кружить в культурных "вы". Жизнь слишком коротка для этого здесь. Это уже второй заход, я уже писал такой пост, когда идея AbabOS была опубликована у нас в "поиске участников в проектах". для желающих, http://forum.vingrad.ru/forum/topic-166490/unread-1/kw-%D0%BE%D0%BF%D0%B5%D1%80%D0%B0%D1%86%D0%B8%D0%BE%D0%BD%D0%BD%D0%B0%D1%8F-%D1%81%D0%B8%D1%81%D1%82%D0%B5%D0%BC%D0%B0-%D0%BE%D1%81%D1%8C-%D0%BE%D1%81%D0%B8.html Прошу обратить внимание на даты. Изначально опубликовано всё летом 2006 года (сессия кончилась, сидя на даче под чашечку чая на ноуте) потом немного более умными словами всё было сформулировано летом 2007 года. т.е. ... сессия кончилась, пройдены предметы ООП, компиляции... третья попытка - летом 2008 года. и сейчас. и т.д.: заходы видимо в каникулы, по праздникам. Смотрю, ты ворчишь, но продолжаешь пытаться - это хорошо. Результатов грубо говоря - 0. это ПЛОХО. У каждого "кандидата" присоединиться и писАть (интересно для кого ;-) ) эту ОС может возникнуть вполне закономерный вопрос:
Свистеть в интернете большого ума не нужно, написать "концепции" - тоже. полупустые файлы повесить - даже первая степень по информатике не нужна. Сколько ОС были написаны "не в фирме"? не больше пяти. Если присмотреться к примеру ядра LiNUX - Л. Торвалдс взял
Он априори ничего не нового не говорил, и практически молча (по-фински) сделал ОС "под UNIX". Заметим, что первые версии были выпущены в сеть уже в относительно рабочем состоянии. И выпущены они были не из 10 файлов с полупустыми кишками, где уже макро говорят многое об опыте разработки. Но это не важно, допустим: действительно есть серьёзные намерения реализовать эту АбабОС. Понимаешь, что одной только идеи недостаточно ? Ты знаешь сколько намного более "революционных" чем эта идей идут в помойку из-за того, что у изобретателя не было достаточных ресурсов ? тысячи в год. Если серьёзно намереваешься что либо реализовывать - закрой форум, садись за код. Сделай что-то рабочее. А потом - и поговорим. Можно оговориться и сказать, мол - писать - любой идиот может начать, главное - подумать. НЕТ. главное - не подумать, и не писать. Главное - РЕЗУЛЬТАТ. Результат на полу не валяется и ничем не пахнет, его надо реализовывать. А думать в понятиях "если наберётся достаточно добровольной раб. силы" - это изначально искать себе отмазки, а не сосредотачиваться на реализации и ресурсах, которые уже ЕСТЬ. Пока результат - тысячи часов писанины в форумах и максимум 50 часов работы над кодом (судя по его количеству и свойствам) И вообще, без обид, но у меня лично создаётся ощущение что автор - любитель публичного внимания. Без соответствующего кода написанного твоим мозгом и ручками, Абабо, это называется просто: мегаломания. Кстати, ничего не имею против заслуженной славы, чес слово. Добавлено через 4 минуты и 13 секунд MAKCim, oпередил, и полаконичнее ;-) |
| Автор: Абабо 29.3.2009, 10:21 | ||||||
Тут не имеет смысла спорить, каждый останется при своём.
А тезисы читал? Понял? Можешь обоснованно показать что в них плохого?
Тезисы читай, те что выше. Пойми о чём я, уверен, что или не читал, или не уразумел - там есть несколько новых идей. А будешь действительно заинтересован к сотрудничеству (а не к критике моего профессионализма), не поймёшь (понять сразу наврядли получится), спросишь - я тебе объясню, ты ПОДУМАЕШЬ, станешь противоречить, я попробую тебя убедить, а может и внесёшь ценные коррективы... вот тогда я буду уверенным в твоей заинтересованности, доброжелательности и компетентности. А если тебе не интересно этим заниматься - не критикуй ради того, чтобы покритиковать "с высоты хакерского линуксоидного полёта", пройди мимо. Добавлено @ 10:32 bilbobagginz - как ты не можешь понять, всё что я хочу от таких так ты, точнее, не от таких, а от более заинтересованных - это не собачиться на форуме, а обсудить идеи!! Я хочу понять, что из того, что я придумал есть хорошо, а что есть плохо. В универе преподы на защите магистерской меня не выслушали, поставили 5ку автоматом (никому не надо), тут я пытаюсь пропихнуть идеи. Тоже самое. Нету у меня наполеоновских амбиций (даже если б были, какая разница?). Просто мне это интересно и я хочу найти людей, которым это также интересно как мне. Хочу с тобой, bilbobagginz, поговорить о тезисах, хочу рассказать и объяснить, что я в них вкладываю, хочу твоей реакции, контраргументов, в чём-то согласия, в чём-то - нет. Чтобы ты, bilbobagginz, понял ВСЁ что я хочу сказать. Может ты и прав в том, что я ничего не разрабатываю, а только языком треплю. Давай потрепимся по делу, без личностей, потрепимся о системной архитектуре с чистого листа! |
| Автор: MAKCim 29.3.2009, 10:58 | ||||
мне эта тема близка (ОС'и, реализация, низкоуровневое программирование) и интересна а любая здоровая критика в первую очередь направлена не на подавление инициативы, а на пробуждение инстинктов доказать всем критикам их неправоту без критики невозможно развивтие в принципе я как-то на 3-м курсе в качестве курсового выбрал разработку основных компонентов ОС цель была - разобраться и повысить скил я реально писАл код, а не занимался пустой болтовней вот могу даже сорсы выложить как доказательства рабочего там мало, но по крайней мере база есть, _написанная мной_ вот и ты должен написать базу, чтобы заинтересовать людей, либо платить им деньги, чтобы они работали, однако, как тут уже сказал bilbobagginz, навряд ли ты потянешь это Добавлено через 11 минут и 47 секунд
не вопрос как будет реализован IPI в рамках разных хостов одной системы IPI (Inter-Processor Interrupt) иными словами как будешь реализовывать распределенное межпроцессорное взаимодействие? |
| Автор: MAKCim 29.3.2009, 11:28 | ||
еще вопросы
если предусматривается масштабируемость системы, то значит потенциальное количество распределенных хостов может быть огромным как ты собираешься реализовать _эффективную_ проверку того, что данный GUID не используется каким-то компонентом на одном из хостов? |
| Автор: Абабо 29.3.2009, 12:32 | ||
Выделением GUID (я их подразделяю на 2, CUID (component uid) и RUID (replica uid)) будет заниматься только сама система. Т.е. ты не можешь ей дать указание: я назначаю CUID этому компоненту. А сам алгоритм UUID гарантирует (практически, в теории есть ничтожная вероятность коллизии) что два одинаковых не будет. Кроме того, во время всего жизненного цикла компонентов, работа с их идентификаторами ведётся системой эксклюзивно. Можно копнуть глубже и спросить: а что если мы будем имитировать систему, отвечая на языке её протокола левыми CUIDами, или вообще ломанём её. Тут я могу ответить следующее. Протокол должен поддерживать (я не о рабочих прототипах, а о реальной системе) шифрование с открытым ключём. Т.е. получая от пользователя инфу идентификаторах, которыми он располагает (или вообще любую другую инфу) ты сможешь сам решить по его открытому ключу, доверять ему или нет. А чисто технически это можно реализовать (по принципу массовой рассылки + кэширование). Я не очень углублялся в алгоритм, поскольку ещё не дошло до его реализации, но знаю, что это можно эффективно имплементировать (гугли CHORD - это проект по разработке p2p протокола, там файлам назначаются идентификаторы - они проводили тесты с многими тысячами хостов). |
| Автор: MAKCim 29.3.2009, 12:48 | ||
что есть система? и где она располагается? |
| Автор: Абабо 29.3.2009, 12:55 | ||
Это распределённая ОС, поддерживающая гостевой режим (то есть, и нативно на железе, и как система промеж. слоя). Располагается по экземпляру на хост. |
| Автор: gcc 29.3.2009, 14:05 |
| Абабо, на perl может? возможно? |
| Автор: bilbobagginz 29.3.2009, 19:17 | ||
| Абабо, во-первых, постарайся абстрагироваться от тона, и сосредоточиться на вопросах. это будет не просто, но постарайся. чисто практический вопрос (Есть ТУЕВА ХУЧА) напр. рас|шифровка UUID-ов. оставим проблемы "многопроцессорности", оставим проблемы "распределённости". допустим у нас 1 проц. любая [рас]шифровка требует CPU времени. кешировать расшифровку небезопасно (дабы не дать коллеге-процессу считать старые значения кешей, и поиметь какие-то запретные ключи) значит надо будет эти кеши стирать. всё это - время-деньги. сегодня в unix системах бежит от нескольки сот до десятков тысяч потоков. в эффективности ОС есть разные параметры "пенальти" каждого действия - создания процесса, записи в память, в файл, чтения, смены "контекста процесса" и т.д. в линукс, напр. старались эти параметры получить наиболее выгодными для пользователя, т.е. чтобы смена процесса, его рождение, убиение и т.д. были подешевее, не теряя атомности действий, контекстов, стэков, таблиц дескрипторофф и .т.д., работали над этим механизмом долго и дошли до какого-то удовлетворяющего компромисса. Если я правильно понял взаимодействие "примитивок", поток - одна из примитив. Кроме того, каждый поток - асоциируется с другой примитивой приложения. а в каждом приложении есть вызовы других объектов (функций и т.д.), каждая из к-рых - тоже твоя примитивина. получаем DDOS вычислений этих идентификаторов: возможно подразумевается иерархия вызов->поток->процесс->приложение->хост. неважно тут это 2 или 3 или 4 уровня, всё равно это слишком ветвистое древо как дорого будет стоить в "А-бабусе" создание каждого объекта вкл. верификации этих самых GUID, CUID , RID и т.д. ? как ты себе представляешь взаимодействие системы, где на каждую запущенную функцию(!!!) будет высчитываться какая-то рас|шифровка, т.е. получаем O(numprocs*numthreads*numcalls) расшифровок на данном хосте локально. "А бабусь" система будет обычно заниматься только вычислением хэшей, а на "саму работу" ей просто будет постоянно не хватать времени. возьми самую простую "легкую"/дешевую расшифровку совместимую с UUID-шками, и помножь то-на-то. т.е. предположительное быстродействие - как у бабуси с Альцгеймером. Жду ответа.
не понял это бравада или сетование.... или их комбинация ? |
| Автор: Абабо 29.3.2009, 20:16 | ||||||
Во-первых, не для каждого объекта (это было бы бредом), а для больших объектов (я их называю компонентами), которые распознаёт система. Большие компоненты запускают кучу маленьких объектов (вообще, это могут быть не объекты, а что-то другое - системе мало до этого дела). А для компонентов... Ты хочешь формулу сложности для алгоритма в несуществующей системе?
Т.е. компоненты это подмножество объектов. Читай внимательно тезисы.
Сетование. Нынче в вузах 5ки по защите получают все, включая полных дебилов (у меня в группе было так). P.S. Неприятно вести беседу в таком грубом и язвительном тоне. Ты что нормально общаться не умеешь? |
| Автор: bilbobagginz 30.3.2009, 07:38 | ||
SMYC, Абабо, SMYC. Мир Всем. |
| Автор: MAKCim 30.3.2009, 10:44 |
| Абабо, начни с себя ps. что-то мне подсказывает, что все можно реализовать, если взять за основу linux и концепцию nfs ;) |
| Автор: bilbobagginz 30.3.2009, 11:19 |
я надеюсь ты не имел network file system от sun microsystems. это чисто централизованная система. она совсем не распределенная. я думаю чел теоритизирует на тему ОС с встроенной поддержкой unified distributed shared memory. Абабо, второй вопрос: что такое "Поток" в твоей системе ? компонент ? несколько компонентов ? что в себя количественно или качественно включает поток ? |
| Автор: MAKCim 30.3.2009, 14:05 | ||
именно network file system и за снову я предлагаю взять концепцию (RPC и XDR), а не реализацию |
| Автор: Абабо 30.3.2009, 21:53 | ||
Поток у меня один из основных примитивов. Причём, поток не локален, а глобален (может перебегать с хоста на хост). Качественно он состоит из набора стеков в соотв. адресных пространствах, соотв. регистровых контекстов + своих спец. переменных - т.е. как и обычный поток, только в нескольких местах. На счёт соответствия ему некоторого компонента (обёртки) я не уверен (нужно продумать все следствия этого). Скорее, о потоках можно будет получить инфу, обращаясь к некому системному менеджеру (компоненту). Но можно ассоциировать с потоком некоторый служебный компонент, но с некоторыми ограничениями (короче, этот аспект недостаточно хорошо продуман, к тому же может сильно зависить от особенностей реализации). А по поводу идеи мигрирующих потоков можно прочесть http://ababos.ipb.su/index.php?showtopic=15. |
| Автор: Lazin 31.3.2009, 16:53 | ||
считай что тебе невероятно повезло |
| Автор: gcc 31.3.2009, 21:14 |
| было написано что perl работает быстрее чем Си если уметь пользоватся (и смотря что обрабатывать), может быть OS на perl быстрее будет работать...? писать очень много надо будет... |
| Автор: powerfox 31.3.2009, 22:37 |
Без асма всё равно не обойтись. Если честно, не слышал, чтобы можно было писать гибридные perl-asm функции. Да и perl, если не изменяет память, интерпретируемый язык, который не может быть быстрее компилируемого (правильнее сказать транслируемого). Ну, если только его инструкции не выполняются железом ) |
| Автор: gcc 2.4.2009, 00:25 |
| Доказательством удачного дизайна Perl можно считать то, что в некоторых случаях он применяется для выполнения задач, на которые он никогда не был ориентирован, и прекрасно справляется с ними. Когда компания Clearcase проектировала автомобильную систему заднего обозрения, драйвера для нее были написаны как на Си, так и на Perl. К удивлению создателей Perl-версия не только работала, но и в 10 раз превосходила Си-вариант по скорости выполнения. http://www.opennet.ru/opennews/art.shtml?num=19366 |
| Автор: Абабо 2.4.2009, 10:46 |
| Я всегда считал, что перл - это не красивый концептуальный язык, а нагромождение разнородных удобных вещей. Справедливости ради скажу, что моё знакомство с перлом ограничилось двумя десятками страниц конспекта и тройкой лабораторных работ, так что, может, такое мнение скорее от незнания... |
| Автор: ZeeLax 2.4.2009, 11:46 | ||
|
| Автор: Абабо 2.4.2009, 13:48 | ||
Если хочешь разговоры по делу, иди на мой форум. |
| Автор: powerfox 2.4.2009, 14:26 | ||
|