Ada_Ru форум

Обсуждение языка Ада

AuroraUX: Ядро OpenSolaris + UserSpace на Ada

Оставить новое сообщение

Сообщения

Alexander
AuroraUX: Ядро OpenSolaris + UserSpace на Ada
2009-03-16 19:15:02

Тут много говорили о популяризации Ады.

Вот один из примеров:

 

http://auroraux.blastwave.org/index.php/Main_Page

AuroraUX - проект по созданию операционной системы с ядром OpenSolaris, но с системными приложениями переписанными на языке Ada.

 

А вдруг есть желающие присоединиться?

Alexander wrote:

Тут много говорили о популяризации Ады.

Вот один из примеров:

 

http://auroraux.blastwave.org/index.php/Main_Page

AuroraUX - проект по созданию операционной системы с ядром OpenSolaris,

но с системными приложениями переписанными на языке Ada.

 

А вдруг есть желающие присоединиться?

 

Странная идеалогия. :) Мне больше нравится идеалогия MarteOS, где ядро на Ада, а системные приложения - на любом языке. :)

 

-- Olleg Samoylov

On Mon, 16 Mar 2009 22:15:02 +0300, you wrote:

 

Тут много говорили о популяризации Ады.

Вот один из примеров:

 

http://auroraux.blastwave.org/index.php/Main_Page

AuroraUX - проект по созданию операционной системы с ядром OpenSolaris, но с системными приложениями переписанными на языке Ada.

 

А вдруг есть желающие присоединиться?

 

Не имеет смысла развивать линейку UNIX-ов, с интерфейсами Ады или без. Кроме того, Ада не созрела для того, чтобы стать языком

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

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

Не имеет смысла развивать линейку UNIX-ов, с интерфейсами Ады или без.

Кроме того, Ада не созрела для того, чтобы стать языком

многопользовательской распределенной ОС нового поколения (а другие языки и

тем более).

 

Если обобщить, то получается смысл этой фразы, что все не имеет смысла. :)

 

А что Аде не хватает, чтобы стать языком на котором можно писать многопользовательскую распределенную ОС реального времени? Мне казалось что ассемблерные вставки дают необходимую гибкость.

 

-- Olleg Samoylov

On Tue, 17 Mar 2009 12:35:14 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

Не имеет смысла развивать линейку UNIX-ов, с интерфейсами Ады или без. Кроме того, Ада не созрела для того, чтобы стать языком

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

 

Если обобщить, то получается смысл этой фразы, что все не имеет смысла. :)

 

Не надо обобщать, соленые груздочки под водочку очень даже имеют смысл. (:-))

 

Речь о UNIX-ах шла. Ежели я о MS-DOS сказал, Вы бы тоже возразили?

А что Аде не хватает, чтобы стать языком на котором можно писать многопользовательскую распределенную ОС реального времени? Мне казалось что ассемблерные вставки дают необходимую гибкость.

 

А при чем тут ассемблер? Проблемы конкретны:

 

1. Множественное наследование где?

 

type Read_File is limited interface;

type Write_File is limited interface;

type Read_Write_File is limited interface and Read_File and Write_File;

додумайте во что это выливается.

 

2. Multiple dispatch где?

 

procedure Print (Printer : in out Device; Content : Object);

 

3. Наследование от задачных и protected типов где? Вы как интерфейс блокирующего обращения к драйверу без protected или задач собираетесь делать? Как в 1913 году, процедура с параметром Time_Out?

 

4. Некооперативный private. Как положить приватную часть чего-угодно в недоступную для несанкционированного доступа память?

 

5. Бардак с синтаксисом protected object, который выносит приватные потроха на улицу.

 

6. Где наследование интерфейсов и делегация. Вы как handle делать будете? По номерам или как в Виндозе? См. пункт 1:

 

type Handle_To_Read_File is interface and Read_File;

private

type Handle_To_Read_File is access ...;

 

Это не катит. Ну и все методы потом ручками переписывать. Я как раз этим сейчас занят. Мы делаем что-то вроде ОС. Так wrapper-ов уже сейчас больше, чем собственно кода. И это с generic-ами.

 

7. Protected action на нескольких объектах? Попробуйте ждать сразу несколько событий.

 

8. Контракты для исключений. Возможность отлова Storage_Error и т.п.

9. Результаты для точки входа. Как вернуть строку из рандеву?

 

10. Приложение Е - полностью переработать.

 

11. Платформо-независимый Stream, стары - в топку.

 

12. Вразумительный Calendar (Time_Zone там - просто чепуха).

 

13. TCP в стандарте.

 

Хватит для начала? (:-))

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

> Хватит для начала? (:-))

 

Нет. :)

 

Речь о UNIX-ах шла. Ежели я о MS-DOS сказал, Вы бы тоже возразили?

 

Там вы были как против развития юниксов так не видели смысла в развитии неюниксов независимо от используемого языка. :)

 

Благодарен за дальнейшую аргументацию. Приверы со стандартной библиотекой можно пока проигнорить, т.к. при написании ядра она врядли будет использоваться как есть. А вот многочисленные упреки самого языка... Вы же давно этой проблемой занимаетесь, если у вас есть обоснованные претензии, почему вы не попробуете поискать что-то более идеальное? Или Ада по прежднему лучше всех не смотря на все названные вами недостатки?

 

Это не катит. Ну и все методы потом ручками переписывать. Я как раз этим

сейчас занят. Мы делаем что-то вроде ОС. Так wrapper-ов уже сейчас больше,

чем собственно кода. И это с generic-ами.

 

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

 

Допустим это нечто должно быть модульным и расширяемым. Чтобы основа работала как на маленьких ARM устройствах так и управляла суперкомпьютерами, дополнительная функциональность бы добавлялась по потребностям и по возможностям. Чтобы она была годна для работы для самых требовательных к надежности и стабильности устройств: робототехники, бортовых ЭВМ и т.д. Но и при этом легко могла быть расширина до OS персональных компьютеров, например до поддержики POSIX и libc. Всего это может быть много. Но, интересуют минимальные требования.

 

Какими минимальными качествами и функциональностью должно было бы обладать основное ядро такой ОС? Ведь наверняка вы можете также перечислить.

 

-- Olleg Samoylov

On Tue, 17 Mar 2009 15:00:58 +0300, you wrote:

 

Dmitry A. Kazakov wrote:

 

Речь о UNIX-ах шла. Ежели я о MS-DOS сказал, Вы бы тоже возразили?

 

Там вы были как против развития юниксов так не видели смысла в развитии неюниксов независимо от используемого языка. :)

 

А в чем отличие UNIX-ах от MS-DOS? Двое из ларца, одинаковых с лица... (:-)) Если делать ОС, то такую, чья идеология была бы чуток поближе к нам, чем середина 70-х. Я, конечно, фан Deep Purple и прочих, но то в музыке, а не в операционных системах...

 

почему вы не попробуете поискать что-то более идеальное?

 

Не встречал.

 

Или Ада по прежднему лучше всех не смотря на все названные

вами недостатки?

 

Да, по-прежнему. Проблема в том, что в этом классе языков (strong, statically, manifestedly typed, universal purpose) ничего нет и близко.

Это не катит. Ну и все методы потом ручками переписывать. Я как раз этим сейчас занят. Мы делаем что-то вроде ОС. Так wrapper-ов уже сейчас больше, чем собственно кода. И это с generic-ами.

 

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

 

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

 

Допустим это нечто должно быть модульным и расширяемым. Чтобы основа работала как на маленьких ARM устройствах так и управляла

суперкомпьютерами, дополнительная функциональность бы добавлялась по потребностям и по возможностям.

 

Scalability, modularity да

 

Чтобы она была годна для работы для

самых требовательных к надежности и стабильности устройств:

робототехники, бортовых ЭВМ и т.д.

 

Safety. Да, но это отдельная и очень сложная тема. Некоторые уровни SIL, и то, как оно все сертифицируется исключают разумные технические решения. Я говорил с разными людьми из "сертификаторов." Мое впечатление, таково, что нет научного понимания того, что такое программная ошибка. Есть разные попытки перенести физические модели ошибок на софт и/или контролировать процесс разработки и людей в нем участвующих. Слабость и того, и другого в том, что к, собственно, софту, и его свойствам прямого отношения все это не имеет. Логика типа, ну они плохого не сделают, если там V-модель, и процесс, и кофе бесплатно, ну и т.п.

 

Но и при этом легко могла быть

расширина до OS персональных компьютеров, например до поддержики POSIX и libc.

 

(Например POSIX должен быть уголовно наказуемым, а людей его

разрабатывавших следовало бы послать на рисовые поля... (:-))

 

Нет ничего такого в персональных компьютерах, от чего они должны были бы иметь кривые интерфейсы.

 

Всего это может быть много. Но, интересуют минимальные требования.

Какими минимальными качествами и функциональностью должно было бы обладать основное ядро такой ОС? Ведь наверняка вы можете также перечислить.

 

Вопрос конечно интересный. Но поскольку, с моей точки зрения, ОС нового поколения должна быть строго ОО, мы скорее всего не сговоримся на деталях. Вот Вы спросите, какие файловые системы поддерживать, а я скажу - никаких и никогда. Файлов-то нет. Возможно, не знаю, но ядро голых объектов могло бы быть очень маленьким по нынешним критериям. Но все это - вопрос для серьезных исследований. А я так, в плане базара... (:-))

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Dmitry A. Kazakov wrote:

 

А что Аде не хватает, чтобы стать языком на котором можно писать многопользовательскую распределенную ОС реального времени? Мне казалось что ассемблерные вставки дают необходимую гибкость.

 

А при чем тут ассемблер? Проблемы конкретны:

 

1. Множественное наследование где?

2. Multiple dispatch где?

 

Я в аналогичной теме на cla отписывался по поводу этой фичи.

 

http://groups.google.com/groups?selm=gpbtkc%24qgr%241%40octagram.motzarella.org

 

Не понятно, как должен быть устроен multiple dispatch применительно к Аде.

Что должно происходить, если объявлены действия для (A_Anc, B) и (A, B_Anc), а вызывается (A_Anc, B_Anc)?

 

3. Наследование от задачных и protected типов где?

А вот тут проблема, как я понял, в невозможности реализации. Ну или возможно, но нетривиально. И без того компиляторов нехватка.

 

Как в 1913 году, процедура с параметром Time_Out?

 

:))))

 

 

4. Некооперативный private. Как положить приватную часть чего-угодно в

недоступную для несанкционированного доступа память?

 

Дважды отнаследовать, один раз with private, второй раз with record.

 

Или я не понял?

 

-- If you want to get to the top, you have to start at the bottom

On Tue, 17 Mar 2009 21:36:28 +0600, you wrote:

 

Dmitry A. Kazakov wrote:

 

А что Аде не хватает, чтобы стать языком на котором можно писать многопользовательскую распределенную ОС реального времени? Мне казалось что ассемблерные вставки дают необходимую гибкость.

 

А при чем тут ассемблер? Проблемы конкретны:

 

1. Множественное наследование где?

2. Multiple dispatch где?

 

Я в аналогичной теме на cla отписывался по поводу этой фичи.

 

http://groups.google.com/groups?selm=gpbtkc%24qgr%241%40octagram.motzarella.org

 

Не понятно, как должен быть устроен multiple dispatch применительно к Аде. Что должно происходить, если объявлены действия для (A_Anc, B) и (A, B_Anc), а вызывается (A_Anc, B_Anc)?

 

Ошибка компиляции. Требование к реализации - все комбинации неабстрактных типов определены. В данном случае Вы должны будете переписать (A_Anc, B_Anc).

 

Настоящая проблема не с этим, а с раздельной компиляцией. Ну, и с отсутствием делегации для борьбы с wrapper-ами для геометрически плодящихся комбинаций.

 

Вообще, до тех пор, пока проблема не ставится, а уважаемые люди занимаются очевидной ерундой типа оператора return, решений и не будет...

 

3. Наследование от задачных и protected типов где?

 

А вот тут проблема, как я понял, в невозможности реализации. Ну или возможно, но нетривиально.

 

А никто и не говорил, что тривиально. См. выше.

 

И без того компиляторов нехватка.

 

Ага! Машин не хватает, получите коньки!

 

Это да, крыть нечем. Любимый аргумент членов ARG...

 

4. Некооперативный private. Как положить приватную часть чего-угодно в недоступную для несанкционированного доступа память?

 

Дважды отнаследовать, один раз with private, второй раз with record.

Или я не понял?

 

Да. Речь идет о том, что для ОС требуется, чтобы приватная операция или компонента была бы физически недоступна. Т.е. если не виден, то никаким способом, включая Unchecked_Conversion, или там липовый Storage_Pool, нельзя преобразовать адрес в объект.

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Am Dienstag, den 17.03.2009, 14:50 +0100 schrieb Dmitry A. Kazakov:

Но поскольку, с моей точки зрения, ОС нового

поколения должна быть строго ОО, мы скорее всего не сговоримся на деталях.

 

Эээ, OC нового поколения должна быть модульной, но не OO, OO как

известно приводит, к "ожирению" и наследованию багов :)

On Sun, 22 Mar 2009 16:20:08 +0100, you wrote:

 

Am Dienstag, den 17.03.2009, 14:50 +0100 schrieb Dmitry A. Kazakov:

Но поскольку, с моей точки зрения, ОС нового

поколения должна быть строго ОО, мы скорее всего не сговоримся на деталях.

 

Эээ, OC нового поколения должна быть модульной, но не OO, OO как известно приводит, к "ожирению" и наследованию багов :)

 

Не знаю как добиться модульности без ОО. Модульность требует развитой системы описания, проверки и принуждения конформности интерфейсов модулей. Ничего лучшего ОО и рядом не стояло. Жуткие API "современных" ОС основаны на процедурной декомпозиции с использованием только примитивных типов типа char *, int, size_t и т.п. На счет ожирения, есть "блестящий" пример Linux. Было время, он запускался с X11 на четырех метрах, кои тогда считались колоссальным объемом памяти. Я, например, помню четырех пользователей VMS в интерактивных отладчиках на двух метрах. Ну и как Linux теперь, здорово исхудал? Или может gdb меньшим д***мом стал?

 

--

Regards,

Dmitry A. Kazakov

http://www.dmitry-kazakov.de

Новое сообщение:
Страницы: 1

Чтобы оставить новое сообщение необходимо Зарегистрироваться и Войти