SII
Здесь у каждого - своя узкоспециализированная задача, плохо вписывающаяся в рамки существующих "универсальных" операционных систем. Я тоже когда-то начинал на ЕС-1022 и СМ-4, и со многими разными ОСями попарился за 25 лет. Пока не понял, что мои программы на моем компутере - важнее чужих программ, и операционная система лишь должна обеспечить им минимальную системную поддержку, но не мешать!

Вы уже второй месяц доказываете нам - фермионам достоинства статистики Бозе-Эйнштейна.

Вы - бозон? Ну и летите к бозонам, они Вас заждались.

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

art_zh wrote:SII
Здесь у каждого - своя узкоспециализированная задача, плохо вписывающаяся в рамки существующих "универсальных" операционных систем. Я тоже когда-то начинал на ЕС-1022 и СМ-4, и со многими разными ОСями попарился за 25 лет. Пока не понял, что мои программы на моем компутере - важнее чужих программ, и операционная система лишь должна обеспечить им минимальную системную поддержку, но не мешать!

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

Вы уже второй месяц доказываете нам - фермионам достоинства статистики Бозе-Эйнштейна.

Вы - бозон? Ну и летите к бозонам, они Вас заждались.

Но что-то мне подсказывает, что Вы всё-таки фермион. Тогда - пора браться за дело: попробуйте сделать систему лучше, логичней, надежней.

И сразу вопрос: _какую_ систему? КОС? Её в нынешнем виде я считаю абсолютно непригодной ни для какой реальной задачи вообще, причём непригодной безнадёжно -- из-за отсутствия предварительного детального проектирования. Т.е. я считаю, что систему надо делать с нуля, но вряд ли основная масса здешнего сообщества с этим будет согласна -- ведь получается, что вся проделанная работа летит коту под хвост (ну, не считая приобретённых знаний и опыта, конечно).

Второй вопрос -- время для всего этого. Тянуть одновременно много серьёзных проектов лично я не в состоянии, ну а мне по моей основной работе предостоит делать недоось на АРМе, о чём я уже говорил (поскольку использование коммерческой ОСРВ исключается по финансовым причинам, а заниматься сексом с Линухом у меня никакого желания нет -- чем разбираться в миллионах строк чужого кода "на все случаи жизни", проще написать несколько десятков тысяч своих, нужных для конкретной задачи на конкретной платформе). Кроме этой недооси, есть и другие вещи по работе -- достаточно мелкие, но в совокупности создающие весьма приличную нагрузку. Так что встревать в чужой проект с заявлениями типа "ребята, я ща всё вам сделаю, как надо" -- по меньшей мере безответственно, ведь я не смогу уделять этому значительное время.

Наконец, третий вопрос: а какая должна получиться система на выходе? Вот Вам подавай максимальную свободу творить всё, что вздумается (эдакая многозадачная MS DOS), ну а меня подход во многом прямо противоположный: система должна гарантировать, что никакая задача не сотворит ничего, ей не разрешённого, как бы она ни старалась. Т.е. нам с Вами нужны чуть ли не прямо противоположные системы, а значит, вряд ли мы сможем работать вместе. Наверняка подобные "конфликты интересов" будут иметь место и с другими "местными жителями". Так надо ли мне плотно встревать в это дело? Одно дело пофлудить на форуме, высказать свою кочку зрения на тот или иной вопрос (учтут её другие или проигнорируют -- уже другое дело, но хуже от ознакомления с чужой позицией точно никому не будет), и совсем другое -- реально что-то разрабатывать.

Плюс остаются более мелкие вопросы (типа того же языка), но они больше технического плана, чем принципиального, поэтому на них концентрироваться смысла нет.

Кстати Intel уже давненько намекает на Larrabee - GPU x86 архитектуры, способный выполнять и рядовые задачи CPU(не все конечно).

Larrabee несет в себе легкость программирования архитектуры x86 и существенно расширяет ее возможности в плане параллельных вычислений. Гибкие возможности для программирования, возможность использования существующих активов разработчиков, наличие программного обеспечения и инструментов обеспечивают свободу в реализации преимуществ программируемого рендеринга, внедрения растеризации и объемного рендеринга. Первое решение на основе Larrabee должно появиться в 2010 г.

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

гм-гмммм... привет всем кто меня знает и может быть даже помнит...
Поднял перископ, осмотрелся и дале тряхнул лень и перечитал всю ветку, блин.
Ну и намутили... впрочем тута и не такого раньше было, помнится.
Новые лица, для которых Embedded не просто слово - приятно слышать!
1) вот уже скоро 6 лет назад я НЕ учавствую в... по причине АРХИТЕКТУРЫ ЯДРА и перспектив проекта(ов) с этим связанных. Печально, но 6 лет назад были люди говорившие, что перво наперво нужно открыть глаза и хотябы попытаться ПЕРЕделать ядро на новые рельсы, тем более, что вилле тогда многих наших обижал... Ну ладно время как вода утекло...
2. дабы не производить ВСЕ полезное начинания в разные холивары, включая архитектурные прения есть ряд методов ОРГАНИЗАЦИОННО-СИСТЕМАТИЗИРУЮЩЕГО плана, а именно анкетирование (Марат, ты хотел бизнеспланирование:), очерчивание перечня вопросов, голосование и ряд итераций дабы оптимизнуть, вычистить флуд, спустить пар, кристаллизовать ЦЕЛЕВОЙ вопросник КОМАНДЫ
3. да, между прочим исхожу и опираюсь из FREE концепции челов-девелопов
4. так вот данный вопросник (с легкой руки) должен дать полное представление о том:
4.1 люди как специ в области ....... желательно в % владения вопроса(ов), языков, архитектур.....
4.2 возможности по времени уделения проекту макс, мин, ночь, день.... в любое время
4.3 приоритет и интерес поличностный в..... в силу которых могу принять участие, испытываю интерес, тяготею к..... перечитайте все ветку и посмотрите на семя состороны и на других вы увидите всеь спектр ОСНОВНЫХ цементирующих людей
............
и т.п.
вот Марат наверное помнит на нашем УМЕРШЕМ сайте atomos.org.ru (не помню какой версии от Protopopiusa), был так называемый "Наш Отдел Кадров", где при регистрации пердполагалось, что помимо контактов, ников и пр. чел укажет о себе ключевые вещи, соответственно команда лидеров может пригласитьна собеседование по мылу, асье, что мы по минимуму и необходимости делали в свое время.....
Ребята, поверьте, Вам нужен анализ самих себя и тех кто ЖЕ с Вами!???
А уж потом планы, ядра, а уж где то там потом, потом - пробы, образы...
Да, главное, и что ОООООчень не хочется делать - ДОКУМЕНТАЦИЯ!
По себе знаю, тянет лепить, ваять.... Это нужно перебарывать приблизительно равно как бросить курить!
Но поверьте отрезвляет, заставляет быть мудрым, а не изливать на форумах потоки..., хотя прорывает иногда, но поделиться белее... от нетерплячки
Команда, это "не хочу видеть в проекте", "мне надо", а могу работать в команде, т.е. в некоторой степени выполнять задание ТЕБЕ СВОЙСТВЕННОЕ(!) и доверять тем спецам, кто тебе ее дает, т.е. он для тебя не босс и не начальник, а АВТОРИТЕТНЫЙ СПЕЦ и он несет бремя ответственности и может быть сброшен с бочки и забросан помидорами )))) за...
Напоминаю, Ваш вектор (по сабжу если) это начать очерчивать список вопросов, который в полной мере очерчивает круг интересующих вопросов (анкета)!!!
Начни каждый это сделать, затем соедините или делигируйтие это кому либо из группы связи с общественностью и массами Поверьте, это нормальный деловой бизнес подход или его начало. Да и потом в % от общего видно ведь кто (поличностно обязательно) куда "тянет" и по знаниям и по хотелкам и по возможностям, это ведь здорово, это цивры, это факты, а не брызги эмоций. Они заставляют думать каждого что поставить за (... %) число напротив строчки с хитрой формулирвкой или предложить новую если вопрос не характерен, не выражает ничего конкртетного, водянистый.
А вот потом нужен нещадный чёс этого пречня, ну опять таки голосуете в % список и "ура!" программа №1 по созданию команды выполнена.
Если ничего не выйдет, вывод один команды не будет и может еще и 6 и 10 лет пройти в таком же ключе, так таки оно Вам надо???
Исхожу из того, что большинство хочет то по-взрослому и "кое что плавали"
Ладно посмотрим тута в сторонке... ), извините отплываю...
Искренне дарю "бисер" ребята, УСПЕХОВ!

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

Максим ты вот сколько раз еще будешь писать, писать, писать? Если такой умный выкладывай готовый проект - люди посмотрят. А так все твои заявления воспринимают как бесполезный треп - не более того. Можешь обижаться.
Вот как то так.

Осознают все. Делать никто не будет.

Serge wrote:Осознают все. Делать никто не будет.

Вот потому и делаю всё сам, а не примыкаю к командам. Ибо начинаю всегда как раз с проектирования и написания документации, а основной массе хочется поскорей кодировать, чтобы увидеть конечный результат (ну а в оси при правильном, "системном" подходе _зримый_ результат появляется ну очень поздно -- на одну доку уйдёт уйма времени, если проектировать достаточно подробно, ну а в серьёзной системе по-иному попросту нельзя). Конечно, в процессе программирования в документацию приходится вносить изменения и т.д. и т.п., но, тем не менее, описание того, что должно быть сделано, появляется раньше собственно реализации, что очень облегчает жизнь.

SII
Знал бы ты как это дело разрабатывается в бизнес проектах крупных. Сначала пишут код, а потом его документируют. Да и конечно постоянно вылезают не стыковки являющиеся головной болью остальных разработчиков. В противном случае невозможно соблюсти никаких сроков сдачи проектов. Конечно какая-то часть документации есть - например Руководство пользователя (User Guide), но до руководства программиста доходит вообще исключительно редко, а уж тем более наличие предварительной проектной документации - это вообще фантастика. Обычно в лучшем случае хорошо документированные исходники. И как не печально - это общепринятая практика, даже в крупных фирмах. Чего уж говорить о средних и мелких фирмах.

Mario
Да знаю, самому участвовать приходилось во время оно. Это сейчас я сам себе полный хозяин. Но если в коммерческих разработках подобные гонки оправдываются сроками и т.п. (хотя лично я считаю, что это ужасно; вот если бы разработчики ПО несли реальную отвественность за его качество, сроки резко увеличились бы, доходы упали, но вот качество стало бы нормальным), то в любительских -- и в КОС в том числе -- этот аргумент уже не работает. Так что думаю, что здесь прежде всего психологический аспект: хочется ж кодить, а не плодить мегабайты описаний. Хотя лично у меня интересы как раз другие: мне интересней проектировать, чем реализовывать, разрабатывать спецификации и т.п. вещи "верхнего" уровня, а не кодировать их реализацию. Ну, думаю, понятно, о чём говорю

Ещё один, и тоже психологический, аспект -- наличие, а точнее, отсутствие "босса". В любительских проектах "правильной" организации труда практически не встречается: каждый занимается тем, чем интересно лично ему, и не очень-то склонен согласовывать свои действия с другими, не говоря уже о том, чтобы реализовывать чужие задумки. Даже наличие некоего "харизматического" лидера не слишком меняет ситуацию, поскольку в крупном проекте без нормального разделения обязанностей не обойтись: должны быть архитекторы, должны быть кодеры, должны быть координаторы и т.п. Ну а если этого нет, получается не проект, а задница...

SII
Если проект не коммерческий в принципе и вообще даже хобби -то о каких требованиях может речь идти вообще? Иначе теряется интерес. Да и потом, когда человек работает за деньги он обучается тому, что от него требуют, получит ли он от своей работы моральное удовлетворение это дело десятое. В хобби проекте именно самовыражение и получение морального удовлетворения, от того что "Я так могу!", а нужно ли кому-нибудь это еще и принесет ли это выгоду дело десятое.

Лично мне участие в разработке Колибри принесло профит, пусть не прямой, а исключительно косвенный, но я бы не работал сейчас программистом и не попал бы в программистскую фирму. У меня нет образования по профилю, но по сути это оказалось абсолютно не важным. Главное навыки программиста сформировались - способность разбираться в чужом коде, править его и писать новый на основе уже существующего. А теперь поработав более двух лет я внедряю некоторые вещи в Колибри. Вот такое вот взаимное использование опыта.

Может я и ошибаюсь, но разработка документации проекта в одиночку не столь продуктивно как коллективное. Вот как-то так.

Mario wrote:SII
Если проект не коммерческий в принципе и вообще даже хобби -то о каких требованиях может речь идти вообще? Иначе теряется интерес.

Ну, собсно, о том и речь. Потому-то все понимают, что делают неправильно, но ничего не меняют -- ибо многим станет неинтересно. Хотя думаю, что даже в случае хобби возможна "правильная" разработка, но здесь уж требуются усилия со стороны разработчиков, готовность заниматься не только тем, что действительно интересно -- в общем, проявлять "сознательность". Далеко не каждый на это пойдёт.

Да и потом, когда человек работает за деньги он обучается тому, что от него требуют, получит ли он от своей работы моральное удовлетворение это дело десятое

Ну, это ещё от человека зависит. Я, например, ни за какие коврижки не пойду программистом в банк или тому подобную структуру -- неинтересно, да ещё работа от звонка до звонка, да ещё идиот-начальник, ну и т.п. (утрирую, конечно, но смысл ясен). Поэтому сижу на мизерной зарплате (25 тыс. рублей "грязными", иногда ещё премии перепадают, но они не в счёт, поскольку непредсказуемы), но зато занимаюсь даже по работе тем, что интересно, плюс имею кучу свободного времени для собственного творчества, да на работе появляюсь раз в неделю, а то и в месяц (зависит от того, нужен я там физически или нет), да ещё и шеф регулярно из дома привозит и домой отвозит

Может я и ошибаюсь, но разработка документации проекта в одиночку не столь продуктивно как коллективное

Ну, тут смотря с какой стороны посмотреть Документирование -- вещь довольно специфическая, мало кто горит желанием этим заниматься, а тем более делать это серьёзно, а не абы как. Плюс обсуждения: когда делаешь всё один, ни с кем не обсуждаешь, а значит, нет потери времени на это и т.п. (хотя, понятное дело, что мнение другого квалифицированного человека будет не лишним, даже если в конечном итоге поступишь по-своему: когда всё делаешь один, глаз "замыливается" со всеми вытекающими). Наконец, не всегда можно разделить документирование на части. Например, можно разделить написание руководства пользователя и руководства программиста, но попробуй раздели описание архитектуры ядра -- нужна ж цельность, а не отдельными кусками, плохо согласующимися между собой. Когда люди контактируют в реале (работают в одной фирме, грубо говоря), обладают близкой квалификацией и являются единомышленниками, это не создаёт больших проблем, а вот в других случаях... Ну и, наконец, в проектировании (а документирование является его результатом) всегда должен быть "главный" -- тот, кто принимает окончательное решение по тому или иному вопросу. Когда работаешь один, этой проблемы, понятное дело, нет (ну, разве что если ты шизофреник ). Голосования же здесь, ИМХО, неприемлемы: проект легко может потерять стройность и целостность (вот коллективные обсуждения или голосования в качестве "совещательного голоса" -- это другое дело: полума -- хорошо, а полтора -- лучше).

Рискну высказать своё мнение по основной теме разговора (пока схематично)

(1) Так сказать "с высоты птичьего полёта" стихийно сложившаяся архитектура KolibriOS не выглядит настолько неприемлемой, чтобы её нужно было менять. Другое дело, что (судя по предыдущим высказываниям) эта архитектура трудно обозрима ввиду
- отсутствия достаточной документации,
- стихийности её развития,
- наличия "мёртвого года" (в смысле - кода, написанного давно и о котором мало кто знает, причём который не совсем устраивает: достаточно упоминания о "ротации регистров" при системном вызове).
Отсюда у меня создалось мнение, что для KolibriOS требуется не редизайн с нуля, а именно осознание и усовершенствование уже имеющейся архитектуры.

(2) Здесь высказывались предложения довольно радикального характера. К ним бы я отнёсся по принципу: "Семь раз отмерь ...". На мой взгляд, фичами KolibryOS являются:
- операционная система, целиком написанная на ассемблере,
- рекордно малый размер, рекордно быстрая загрузка системы, рекордно малые потребляемые ресурсы (с учётом графического интерфейса, ибо экран 800x600x32 - это уже 2 Мб на одно только отображение),
- графический интерфейс со своебразным API,
...
Сделав KolibriOS "более правильной", рискуем потерять своеобразие операционной системы (а значит - снизить потенциальную её ценность).

(3) На мой взгляд, появившиеся проблемы с видоизменением, расширением, преобразованием, адаптации к изменениям архитектуры - это частные случаи проблем портируемости ассемблерного кода. Но KolibriOS не может просто перейти на ЯВУ, ибо перестанет быть KolibriOS (Это было возможно для L4, ввиду двух основных причин(на мой взгляд): L4 - это только микроядро, ассеблер в L4 имел значение "для пущего эффекта" - целью же было разработать механизмы и алгоритмы, позволяющие кардинально улучшить производительность микрядерной архитектуры).

(4) Опыт эволюционного развития архитектуры MINIX, показывает трудность и болезненность этого процесса (а ведь это и официальный исследовательский проект, и гранты имеет на его разработку, и постарше будет, и написан в основном на C). Подобный процесс для KolibryOS скорее всего будет проходить ещё сложнее. Переписать занового пожалуй проще будет, но
- одно дело, когда развиваеш ОС с нуля и радуешься упешной натройке прерываний, первому рисунку и тексту в графическом режиме,
- другое дело, когда переписываешь уже существующую и довольно хорошую ОС (а KolibriOS -это весьма хорошая операционная система).
Инными словами, сесть и начать переписывать 70 000 строк ассемблерного кода на ia-64 можно только получая за это деньги (а учитывая ассемблер - хорошие деньги).

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

"Предложить наиболее оптималную технологию перевода операционной системы, полностью написанной на ассемблере, на совершенно другую платформу (например, ia-32 -> arm), так, чтобы
- в результате снова получилась бы операционная система, целиком написанная на ассемблере,
- технология была бы пригодна для OpenSource проекта".

Моя идея сколь дикая, столь и тупая :

1-й этап: Создание KolibriOS[ia-32-generic]

Это можно сделать постепенно переводя 70 000 строк на ассемблере в 20 000 строк на ЯВУ + примерно 5000 строк на ассемблере, содержащих принципиально специфические вещи ia-32, которые просто невозможно нормально программировать на ЯВУ (и их даже бессмысленно переписывать для новой архитектуры - другая архитектура потребует принципиально другого решения).

При этом ассемблерную версию (KolibriOS[ia-32-main) отменять не планируется. Более того, при переводе могут возникнуть идеи по улучшению архитектуры, которые в рамках обратной связи целесообразно будет эволюционно внести в исходную ассемблерную версию.

2-й этап: Создание KolibriOS[x-arch-generic]

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

3-й этап: Создание KolibriOS[x-arch-main]

На данном этапе будет производится постепенная ассемблерная оптимизация - перевод всех функций ЯВУ на ассемблер новой архитектуры.

Выскажу гипотезу, что такой подход (по сравнению с лобовым переводом ассемблера (ia-32 -> xarch) ):
- позволит сократить время разработки примерно в два раза,
- заметно снизит требования к квалификации его участников,
- позволяет в каждый момент иметь работоспособную и практически полноценную промежуточную версию.

Firewall, извините, но мнение таких людей, как SII, Serge и Mario для меня гораздо ближэе и обоснованней

А конкретно продумывая чего можно достичь малыми силами за разумные сроки.

Возможно стоит отказаться от упора исключительно на ассемблер (я наступаю себе на горло - но против правды далеко не попрешь), но не ломиться по пути *nix - у системы свой, пусть тернистый, путь и некоторые вещи можно реализовать лучше. POSIX не панацея. Переносимость возможно, но не обязательно. Упор имеет смысл делать в основном на x86-64. При этом не бросая текущую систему. Кому интересно могут продолжать.

Начал перечитывать тему, наткнулся.

Ладно, давайте посмотрим с другой стороны. Пойдем методом исключения. Серверные решения на данный момент нам недоступны - там очень-очень прочно обосновались другие системы. Встроенка? Тоже крайне сомнительно: в большинстве своем там используется не IA32. Остаются только десктопы. На десктопах - Винда, Линух, Мак. Опа. Вам последнее слово ничего не говорит?

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

Иначе вижу только вариант с написанием ОС для самосовершенствования, как программиста.

P.S. Откуда появилась дурацкая привычка выделять ники и термины жирным???