OSDev

Фантом ОС ищет единомышленников.

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

Где: http://code.google.com/p/phantomuserland/

Лицензия: LGPL.

Совместимость: для родных приложений планируется (и частично сделана) совместимость с Java bytecode (и, следовательно, всеми совместимыми ЯП), позже - с CLR. Кроме того есть (пока ещё неперсистентный) POSIX-box (работает, хотя и реализован очень вчерне).

Переносимость: Основная разработка идёт на x86/32, в работе порт на Arm (грузится, переходит в графику, надо отлаживать), mips32 (только ожил, в самом начале пути). Дальше в планах mips64 и amd64.

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

Кто нам нужен:

- драйверописатели - как всегда, драйверов не хватает, и не все те что есть - отлажены.

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

- специалисты по виртуальным машинам - основная виртуальная машина всё ещё интерпретатор. хотя совершенно понятно, как подключать libjit, это надо сделать. кроме того, есть задачи по приведению в порядок refcount gc и написанию большого офлайн GC (marksweep on disk - вообще он почти написан)

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

- документатор! хотя какая-то документация есть ( http://code.google.com/p/phantomuserland/w/list ) - её мало и она не вполне актуальна

- организатор тестирования на живом железе - частично это уже делается, но нужно поставить на регулярную основу.

- фанаты ARM/MIPS/name it - отлаживать и тестировать соответствующие порты ОС

Проект уже довольно большой - 150 000 строк кода только ядра - и очень интересный.

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

а что насчет скорости? Java очень медленная штука.. JavaOS тому доказательство..
какие планы вообще и планы относительно компилятора фантом-байткода?

qeos, Java не медленная. Да есть у неё недостатки в скорости.
Но вот тебе для затравки.
Как пишет dz он собирается использовать jit. jit - даёт скорость такую же, как если бы это был Native компилятор.
В частности dz пишет что хочет использовать LibJIT. Вот тут какое не какое сравнение в скорости. http://habrahabr.ru/blogs/personal/102533/

Задам пожалуй вопрос.
Вот, допустим программа работала работала, а потом испортилась, зависла. Ну как испортилась мы не знаем. Но вполне возможен случай, что испортились некоторые данные. Кто будет определять какие данные испорчены, а какие нет? А главное как будут отличать испорченные данные от неиспорченных?

А зачем системе что-то определять? Если программа зависла, то всё как обычно - кнопку "Закрыть" ни кто не отменял. Впрочем, мне кажется сомнительным достоинством системы сохранять рабочее пространство. На сохранение контекста будет постоянно тратиться время и ресурсы. Сплошной trade-off между сохранением и восстановлением.

Эта легенда про "Java очень медленная штука" надоела уже до печёнок.

Сравнение 1: http://www.stefankrause.net/wp/?p=4
Сравнение 2: http://scribblethink.org/Computer/javaCbenchmark.html

1. Разница в скорости между Java и C сравнима с разницей в скорости между разными компиляторами си.
2. Эта разница бывает В ПОЛЬЗУ Java - то есть Java бывает БЫСТРЕЕ, чем си. На вычислительных задачах - очень нередко.
3. Ну скачайте уже Java frontend для gcc (он входит в комплект gcc несколько лет), и объясните, с чего бы один и тот же компилятор сам себе уступал.

Итого: Си, Ява и Си шарп являют собой тройку самых производительных ЯП в мире. Разница между ними несущественна.

4. "Кроме того есть (пока ещё неперсистентный) POSIX-box." Это если очень нужен си.

5. Производительность зависит не только от языка и платформы. В реальности - больше от скорости ввода-вывода.

Вот писал я документ в ворде. Три месяца писал. И вдруг - он не открывается. (Реальный случай.) Кто будет определять какие данные испорчены, а какие нет?

Ответ - никто, в общем-то, не будет - поругаются на ворд, и пойдут искать в почте предыдущую версию файла, которую вчера посылали Васе Пупкину. Или достанут из машины времени, если работают на маке и эту машину прикупили.

Впрочем, есть исследование - только не надо смеяться :) - британских учёных, - которые утверждают, что небольшой процент битых объектов для современных Java-программ не критичен - то есть - не приводит к смерти программы или полной потере документа.

(В реальности - проблемы в другом месте, и более серьёзные. Но тоже исправимые.)

Постоянно?

Если вы ничего не делали, то и сохранять нечего. А если что-то делали - то всяко придётся сохранить, нет?

Сохранить документ - это всего несколько килобайт. Сохранить рабочий контекст приложения - это уже мегабайты.

Так сохранять только разницу, для обычных приложений это хватит. Вот для профессиональных такое не годится. В том же фотошопе документ 3 мегабайта, а в секунду контексте может меняться под 100 мегабайт.