Запускал (LiveCD и с дискет):
ReactOS, AROS, MenuetOS, KolibriOS, RusOS, Syllable.
ИМХО, всё это в настоящее время УЖОСНАХ, хотя KolibriOS понравилась - летает.
После запуска реактоси я понял, что зря винду за нестабильность ругают - у меня МЕ стабильней была...
У реактос идея хорошая, конечно, но вон майкрософт обещают следующую винду без реестра выпустить (хотя, они и висту обещали выпустить без реестра и с новой файловой системой). Когда в реактоси глюки отловят - она уже будет настолько устаревшей, что придётся переписывать...

OCTAGRAM
Во-первых, когда Симула стала вдруг считаться ОО-языком? Ну уж не в момент своего выхода. Потому как на то время всё произрастало из Алгола, его удобств и покрытия недостатков.

Во-вторых в плане этой цитаты хочется услышать про безопасность Ады что-то конкретное кроме общих фраз что она лучше. Причём этого что-то не должно быть в С/С++. Жду с нетерпением. Спецификацию 2005 года не читал (как бы за ненадобностью).

Ну ты сравнил - альфа-версию реактОС с зарелизенной МЕ. Когда МС выпустит еще одну версию и перестанет поддерживать ХР, реактОС останется единственной поддерживаемой win-32 совместимой системой. У МС один шанс - пойти по стопам Яббл и навесить свой интерфейс на юникс (имхо).

Да зачинщик вопроса про языки всё никак не соберётся объяснить преимущества написания ОС на Аде. А так получается что да — оффтопик.

Квизац_Хадерач
Я думаю нет. На мой взгляд можно назвать три основных ветки: Win, *nix, MacOS. А вот все остальное - альтернативное...

Квизац_Хадерач
Сначал был UNIX (если ничего не путаю, то прямо так это и называлось). Потом Э.Таненбаум написал учебную ОС MINIX, взяв за основу UNIX. И только потом Линус, наш, Торвальдс, взяв за основу MINIX, написал ядро Linux. И понеслась...
А BSD - это вроде одна из модификаций UNIX.
PS могу в чем-то и ошибаться, т.к. пишу, что знаю, а проверять себя по другим источникам пока лень...

Отредактировано DrLabRus (20-10-2007 19:07:40)

Квизац_Хадерач
Очевидно, проблема возникла из-за моей неправильной терминологии - когда я писал *nix, я подразумевал UNIX и всех ему подобных: MINIX, Linux, BSD ..... (также, как Win обозначает Win3.11, Win98 ...)
Что же на самом деле подразумевается под *nix ?

Отредактировано DrLabRus (20-10-2007 19:22:12)

Мне кажется, граждане, что вы погрязли в словоблудии.
Для меня есть три "основных" ветки ОС: Windows, MacOS и Linux вместе с *BSD. Всё остальное я воспринимаю как экзотику. Это восприятие основано исключительно на личных впечатлениях.

Что, то не верится, что-нибудь вроде "на стандарте posix", скорее ?

К сожалению тему мою про Syllable прикрыли, сказав что и тут можно поговорить. Поэтому очень кратко опишу саму систему.

Syllable не является "еще одним клоном unix". Основной задачей разработчики ставят создание быстрой и надежной операционной системы для дома. Свои корни Syllable берет от проекта под названием AtheOS, первая публичная версия которого вышла в 1997 году, но к сожалению был заброшен своим автором. Так же проект никогда не был связан с BeOS и не является его клоном. Имеются далекие отголоски AmigaOS и некоторых других мало известных у нас систем.

Syllable имеет модульное ядро, это позволяет достичь высокой скорости работы, а так же позволяет подключать драйвера именно как модули, без необходимости пересборки ядра как в Linux. Конечно некоторые драйвера и часть приложений приходится портировать с nix, но тем не менее Syllable имеет ряд нативных приложенийи свою собственную файловую систему AFS. Так же поддерживается posix, что позволяет компилировать ряд консольных приложений для системы без их серьезной модификации.

Так же существует Syllable Server, использующая ядро Linux, но она не является приоритетной веткой в развитии. Ядро Linux было выбрано так как оно обеспечивает функционирование всех необходимых сетевых сервисов и его относительно легко можно пересобрать под свои нужды.
Можно сказать так: разработчики решили сделать сетевую версию системы, но при этом решили отделаться малой кровью, так получилась Syllable Server на ядре Linux.

www.syllable.org
www.syllable.org.ru

Не знаю, когда она там официально вышла, но Simula 67 — это то, с чего пошло ООП, и это как бы общеизвестно. Недолго гуглив, получаем INTRODUCTION TO OOP IN SIMULA:

Поправка: 2007 года. В 2005м году появился только первый черновик. Так бы её и назвали Ada 2007, но с лёгкой руки AdaCore, в темпе реализовывавшей новые фичи, название Ada 2005 укрепилось в исходниках и документации, и менять его не стали.

Вот уж точно. Будучи пессимистом, я тоже думаю, так и будет. Я бы даже ожидал приведения в действие следующего эмпирического закона:
How come Ada isn't more popular?

Rohanx
Но попробовать стоит.
Мысли

Есть в C++ некоторые "удобства", за которые я платить отказываюсь. В первую очередь, это совместимость с C на уровне исходных текстов. Это преподносится как нечто очень полезное, как нужное и важное свойство. На деле же кара за рекламную ложь ощутима. Во–первых, простота смешивать вот так вот просто языки, как предложено, это преувеличение. В C исключений не было, так что писать исходный текст на нём следует в пессимистичном стиле. А в C++ — есть, и там нужен оптимистичный стиль. Нужно конвертировать коды ошибок C в исключения C++ и делать некоторую другую работу. Но если, как ни крути, на стыках возникают impedance mismatch, то зачем вообще вся эта совместимость на уровне исходных текстов? В Аде языковое смешение было предусмотрено. По стандарту с C, Fortran и COBOL. А в компиляторах GNAT ещё и C++. Но не на уровне исходных текстов. А так, что понятно, вот здесь legacy C, а здесь Ада.

Далее, в C можно было менять входные параметры. Собственно, C лишь был кроссплатформенным ассемблером, и эта возможность просто отражала возможности процессора. Но наш доблестный C++ ведь очень хотел быть совместимым с C! И, поэтому, даже если мы пишем в C++ методе входным параметром сам объект, а не ссылку на него, объект скопируется. Для нашего же удобства. Вдруг мы его копию изменить захотим. Принято считать, что в C++ за те удобства, которые не используем, мы и не платим, но есть кое–что, что имеет более высокий приоритет. Совместимость с C. Причём, в C–то это проблемой не было, C же не претендовал на язык с шаблонами (будь в C++ инты изменяемы, а более сложные — нет, это привело бы к противоречиям в языке; как вариант, сделать read-only входной параметр типа–параметра, даже если этот тип–параметр может быть параметризован как int, но это что–то нездоровое, тем более, что struct в C уже копировались, опять противоречие). И то, что в C структура вот так же просто копировалась, не было чем–то странным. Это проблема именно C++. Да, там есть ссылки, и их приходится использовать. Тем временем в Аде входные параметры по умолчанию доступны только на чтение, соответственно, разговоров об избежании копирования даже не начинается. Компилятор сам разберётся, как ему там эти параметры переслать. (Замечание: C.6 Shared Variable Control: If an actual parameter is atomic or volatile, and the corresponding formal parameter is not, then the parameter is passed by copy. Так что и тут всё гладко)

Возврат результата тоже сделан грамотно. Если результат достаточно мал, он передаётся по значению. Если больше, но известного (на этапе компиляции) размера, под него отводится место на стеке, и на это место функции передаётся указатель. Если неизвестного размера, то функция размещает объект на втором стеке и возвращает указатель на него. Все эти вопросы прекрасно может разруливать компилятор. Это особенно важно при программировании дженериков. Мало ли, как его параметризовать могут. Будет там что известно на этапе компиляции или нет...

Одним "необходимым" (да–да, в кавычках) для программирования знанием меньше. Все эти const & и последующие за ними специализации шаблонов для int и т. д., в Аде не нужны. В Аде писать дженерики проще. Причём, заметьте, эта не та рекламная "простота", за которую нужно чем–то платить, как в Яве или C#. Нет, это одна из сложностей, которых можно избежать при грамотном проектировании языка.

Я не говорил про замену Адой всего, я упомянул лишь C(++). Да, было бы неплохо видеть побольше программ на спайке Ада+Лисп (также, как в Mozilla C++ + JavaScript). Хотя можно и не Лисп, но Ада уж точно. Эти части (статика/динамика) таковы, что выбирать их можно независимо. А коль уж топик про операционные системы, нас должно интересовать системное программирование. Тем более, что сами динамические языки так или иначе тоже надо на чём–то реализовывать.

То, что в десктопном варианте их нет. Lovelace OS, призванная это исправить, делается 4мя людьми. Для сравнения, Psi делается семерыми. Но это не значит, что не стоит пытаться. Был бы остов, а добровольцы ещё могут найтись. На выборы ведь тоже можно не ходить, но если все так будут думать, и никто не пойдёт...

Существующие операционки — да, а язык — нет. Embedded — это основное поле деятельности для Ады, но сама Ада — язык универсальный.

Если в реале всё хреново, почему в виртуале должно быть лучше? Люди–то те же самые.

Мысли: Об алгоритмах и программах

Тем не менее, микроскопическими шагами, но вперёд двигаемся. Раньше вот была FAT, и ничего, что она к сбоям неустойчива. Сейчас у большинства HFS+, NTFS или другие, от сбоев защищённые. И это не вызывает насмешек типа да зачем нам эти журналы–транзакции. То же самое и с Ada vs. C(++). Глядишь, тоже дойдёт когда–нибудь.

Поконкретнее было по ссылке :
Слайды : Programming in the Small: C/C++/Java Pitfalls & Ada Benefits

В Аде более строгие правила работы со указателями. Вот просто так не возьмёшь и не присвоишь указатель на локальный объект переменной типа указатель на глобальный объект. В Аде есть проверка на выход за границу массива (а не только вектора). В C++ нетривиально сделать проверку для массивов, созданных new []. В C++ нельзя объявить указатель not null. В Аде RAII действует не только на объекты–переменные, но и на те, что были созданы new. Они будут финализированы не позже выхода из области видимости типа указателя.

Это только те фичи, которые непосредственно усиливают безопасность и безошибочность. C++ славится своими патогенными особенностями (об этом на слайдах линк выше, а также на FQA Lite линк ниже).

Все методы безопасности в Аде можно подавлять и обходить. Но при этом те места, где это было сделано, локализуемы. Я бы предпочёл отвечать за то, что я снял проверку в известном месте, чем за то, что я её где–то не поставил.

Ada helps churn out less-buggy code

Video System Reduces Test and Debug Time with Ada

No call for it

Technical Features
Business Benefits
Advocacy
Choose Ada : The Most Trusted Name in Software™

В C++ очень многое решается костылями. Размер массива должен быть известен на этапе компиляции. А пофиг, пусть vector юзают, если нужен с заранее неизвестными границами. Псевдомодульность обеспечивает препроцессор. А пофиг, работает же и ладно. (повторюсь) параметры без ссылок будут копироваться. А пофиг, программисты всё стерпят, от них не убудет пару лишних специализаций написать.

C++ FQA Lite — здесь много, чего описано. Я сам к этому материалу неоднозначно отношусь в свете того, что знаю, как некоторые проблемы всё–таки можно решить в рамках языка системного программирования. Например:

В Аде для этого есть extended return statement (return-do-end return), конструирующий объект прямо на нужном месте и позволяющий с ним ещё что–нибудь сделать. Как видите, можно обойтись и без сборки мусора. Хотя... Ада может работать и в средах со сборкой мусора, стандарту это не противоречит.

Про совместимость с C

C++ — это куча костылей. А где костыли, там и грабли.

Помимо тех фич Ады, которые на самом деле недоработки C++, есть в стандарте Ады секции стандарта, относящиеся именно к низкоуровневому программированию. А низкоуровневые фичи Ады как раз могли бы найти применение в OS.
Далее информация касается более C, т. к. низкоуровневые фичи в C++ остались без особых изменений.

Например, битовые поля в C ограничены размером целого числа.

источник

А в Аде — нет. В Аде можно сначала объявить запись, а потом задокументировать, с каких битов начинаются какие поля. А можно просто поставить Pragma Pack и все поля по возможности будут упакованы до битов. А работать с этой записью можно будет как ни в чём не бывало. Понятно, что программист должен представлять, с чем имеет дело, и, тем не менее, одной проблемой меньше. Кстати, битовый массив в Аде — это всего лишь array of Boolean с pragma Pack : Pragma Pack for Arrays

Change of Representation

Философия C — то, что можно сделать эффективно, нужно делать эффективно (а не так, что 20Mb на Hello, World! в Java). Философия Ады — не только не мешать программисту делать эффективно то, что можно сделать эффективно, но и не мешать делать неэффективно то, что эффективно сделать не получится.

В C мы были бы вынуждены (если, конечно, нам повезло, и битовое поле влезло в целое число) вручную присвоить каждое поле. Да, это неэффективно — взять и перетасовать зараз кучу битов. Но ведь конечная цель не описывать всё подряд на низком уровне, а достичь поставленной цели.

Что касается C++, там можно прикрутить какой–нибудь libbit, но это будет не то же самое. Change of representation столь же гладко не получится.

Добавлено Sun Oct 28 09:44:48 2007 :
В Аде очень хорошо сделано управление стеком. Стек — это великая вещь. С него можно быстро брать память. И быстро отдавать. Быстрее, чем это происходит с кучей. Мы ведь всё ещё про OS говорим, верно? Там это всё полезно. Адская строка представляет из себя не что иное, как массив символов с недоопределёнными границами. И, если ничто этому не мешает, живёт эта строка на стеке. В Аде, как и в C99, границы (и вообще размеры) могут быть неизвестны на этапе компиляции. Но эта фича C99 "не досталась" C++. В C++ можно разве что использовать всякие alloca, но их переносимость ограничена. И, опять же, это костыль, а в Аде динамическая работа со стеком поддерживается и обеспечивается компилятором.

Вот агрегатов ещё в C++ нету (зато есть в C99). Конструкторы есть, но их в таком случае ещё написать надо. Для каждой Plain Ol' Data структуры, в то время как в C99 это не нужно.

Как же хорошо, что есть Ада, и что можно не волноваться, кому там что не досталось (кстати, вот список), а просто иметь лучшие фичи и от того, и от другого.

Конечно, есть в Аде и традиционные строки, Bounded_String и Unbounded_String.

Ковырял тут одно расширение — оказалось в Java тоже есть исключения: конструкция try|catch|finally.