BaBL
Какой еще? Плюсов в ванильном ядре нет. Ядро написано на C и с ассемблеровскими вставками, и то в основном в arch/. Конечно существуют всякие патчи, не включенные в основную ветку и даже практически не используемые в большинстве дистрибутивов. Но это личные инициативы какихто людей|компаний, которые не получили поддержки основных разработчиков ядра. Ну еще используется несколько скриптовых языков при сборке.

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

Другое дело, надо учитывать, что к моменту созревания действительно-работоспособного дистрибутива именно Национальной_ОС, очень многое изменится и в аппаратной части, и возможно даже в интерфейсной. Например привычные нам жесткие диски могут просто исчезнуть из компьютеров - будет просто память MRAM сколько-то там терабайт. Уже делаются успехи в плане построения первых нейроинтерфейсов, а эта технология обещает гораздо больший прогресс, чем переход от перфокарт к монитору, клавиатуре и мультимедийной системе. Насколько мне позволяет фантазия осознавать кардинальность этих изменений, я могу судить что независимо от того, что сейчас можно взять за основу - большая часть кода будет переработана или написана с нуля. Однако минусом этих изменений будет многократно возросшие требования к надежности конечной системы "железо + софт". Вполне может статься, что как в романе "Горячий старт", человека сможет убить его домашний компьютер (а это еще не самое страшное). Вобщем я пока вижу прообраз такой ОС в отсутствии централизации, и монолитности ядра - должно быть достаточное количество уровней изоляции, большая избыточность при резервировании функций. Например если взять человеческий мозг - прокол его подкорки, не обязательно приведет к смерти, или забыванию какой-либо информации - наша память можно сказать изрядно размазана по большим участкам подкорки. А современные ОС, в случае ошибки очень часто впадают в ступор, судорожно пытаясь завершить работу или просто убивая "приложение с ошибкой". На мой взгляд сама такая архитектура для будущего не годится...
Добавлено спустя 17 минут, 40 секунд
Кстати, что касается Си и его использования в Открытом коде. Мне этот язык своей древностью сильно ассемблер напоминает, и даже объектно-ориентированная оправа его не сильно красит. Вопрос получения машинного кода, или вм-кода всегда меня интересовал с двух сторон - качественный результат, значит без мусора, производительный и компактный, и скорость собственно компиляции. В связи с чем вспоминается, на редкость неудачный опыт компиляции GCC4 с использованием GCC3.4, под Windows и MinGW. Конечно мне тогда и опыта не хватала, но самое главное что потрясло - для компиляции каждого, самого мелкого Це-файлика (в лучшем случае десятка файликов), утилита make вызывала соответственно компилятор, каждый раз создавая новый процесс. Системные программисты меня поймут - это не та операция, что в Windows выполняется быстро. Фактически процесс компиляции растягивался на часы, при использовании Athlon XP. Меня не удивляет заявления разработчиков Microsoft, что для сборки очередного релиза с нуля будь-то Windows, или MSOffice, требуются многие часы на выделенном сервере. Сейчас надеюсь в этом плане хоть какой-то прогресс появился, во всяком случае детище Майкрософта позволяет использовать precompiled headers, и при использовании сторонней утилиты - распределять компиляцию проекта среди машин в локальной сети.
Впрочем если касаться только темы, проблемы у Си в основном только с получением легко-воспринимаемого програмного текста, ну и строгостью к программисту От этого напрямую зависит вероятное количество ошибок в исходном коде, и ресурсозатраты на их исправление. Конечно многие корифеи системного программирования, могут с закрытыми глазами писать идеальный без ошибок код, но и то недолго. При этом цена такого опыта для бизнеса в настоящее время просто не приемлима. Программисты с окладом в $10000-$15000/месяц доступны отнюдь не каждой компании.
По моим представлением идеальным языком программирования в будущем будет считаться очередная интеграция имеющихся языков. Очень хороший подход может дать сращивание XML/HTML, с Object Pascal/Oberon, меня во всяком случае очень бы обрадовала возможность использования гиперссылок и картинок в комментариях кода, а так-же повышенная интеграция с средствами проектирования и моделирования (алгоритмов, баз данных и т.д.). Уж не знаю, многие-ли Web-дизайнеры читают тему, но согласитесь, что использование конструкций <table id=T1>...</table><table id=T2 width=T1.width>...</table> гораздо удобнее, чем голый текст разметки и ява-скрипт где-то в стороне.

alpet ты, кажется, очень неравнодушен к такому популярному виндовс средству, как Delphi? Учти, это поделие в Linux не жалуют. Кстати, про HTML http://doc.trolltech.com/4.2/richtext-html-subset.html юзай на здоровье. Вообще QT великолепная штука, забудь про делфи. А про то, что нас ждет в будущем, мне больше нравится парадигма семантического программирования.

alpet
Хм, ты предлагаешь что бы все компилил один процесс? Вообще время требуемое на создание процесса ничтожно мало по сравнению с остальным процессом компиляции. Более того это позволяет достаточно просто распаралелить процесс компиляции, просто раскидывая процессы по разным ядрам, так же distcc может достаточно просто раскидывать их по разным компам (незнаю как дела с этим у nmake от MS, но GNU make умеет это делать без проблем).
precompiled headers это немного из другой области, для .h отдельный процесс и так не создается, но компилятор выполняет фактически одну и туже работу несколько раз, а тут часть работы выполняется один раз.

И это после заявлений о долгой компиляции C...

Хм, тебе при написании кода будет удобно смотреть на всякие картинки? Есть разные систему документирования кода, которые позволяют генерировать описание функций/классов и т.п. из комментариев, там как правило можно вставлять и ссылки и т.п. На выходе получается например HTML с ссылками, картинками и т.п., который достаточно удобно просматривать. Но что бы все это находилось в коде, т.е. по среди текста картинка, надеюсь я этого не увижу

Не средству - языку Delphi. Во всяком случае для меня важно, что через много лет в своих исходниках я смогу разобраться так-же быстро как и сейчас, в следствии высокой читаемости кода. Что-же касается библиотеки VCL, я ее использую довольно редко.

Опять пустопорожний спор. Пора и мне отметится.
Уважаемые, главная мысль (и BaBL пытается ее вам вколотить!!!), не нужно ничего осваивать, с мукой рожать некие решения и т.д. и т.п. Есть огромный мир OpenSource приложений, в котором уже все что надо написано, русифицированно, отлажено и поддерживается. Вопрос больше в плоскости гос. политики (на 90%) и доработке OpenSource приложений для нужд российских пользователей (10% из которых 9% это руссификация при необходимости и подготовка русскоязычных методических пособий для пользователей и образовательных учреждений), т.е. реальная дорогостоящая работа по доработке программного кода - около 1%. С проповедниками Windows я даже не обсуждать ничего не хочу, в государственных учреждениях ДОЛЖЕН стоять opensource соответствующим образом оттестированный и сертифицированный на предмет уязвимостей и безопасности.
В масштабах страны экономия на софте и армии бестолковых windows администраторов (учитывая общую надежность opensource решений) составит сумму, сопоставимую с бюджетом страны, которую можно направить на пенсии, улучшение здравоохранения и автодороги в сибири, а не на откаты распальцованным администраторам, IT отделам и чиновникам разного звена.

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


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


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

Что это такое?



Зачем??



В африке, пожалуйста.


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

http://www.linuxfromscratch.org/


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

это всего лишь две проблемы:
а) уродливость винды в части работы с процессами
б) лишние прослойки м/у самими вызовами ядра и сишными (если взять тот же cygwin взять, то он работает далеко не быстро)

паскалю, который суть и есть основа Дельфей, лет примерно столько же, сколько и Сям... И язык, кстати, тот не очень удобный - Си гораздо практичнее...

это чьи проблемы? Приложений? Языка? А может все-таки компилятора? Хотя можно провести тест - написать пару приложений и погонять с разными ключиками на разных компиляторах...

а может вообще уйти от кода как текста? Есть возможность создать среду, в которой можно будет, просто перетаскивая с панели инструментов блоки на рабочее поле и организуя между ними связи, создавать программы. Но традиционный путь, при котором код в виде текста, а документация (с графиками, таблицами и пр. опциональными радостями) лежат отдельно, эффективнее.

зря ты так... вот ява еще быстрее, а уж как оно потом работать будет - это вопрос другой.

а что тут непонятного? читать мануал по gas и as86

ну, правильно. Где-то выигрываем, где-то теряем. Но у меня ни разу дельфи не были быстрее Сишных нормальных компилеров ))))
Добавлено спустя 2 минуты, 19 секунд

как раз ошибка там сишный компилер тот же GCC и в ассемблер он может переводить, но при необходимости.

alpet
Я говорил про XML, его разбор достаточно ресурсоемок. На счет времени компиляции, во-первых паскаль более строгий и четкий чем C, по тому компилятору немного проще. Во-вторых многое зависит от квалификации разработчика, я признаю, что для того, что бы писать хороший код на C нужно несколько больше опыта, чем для паскаля, т.к. там достаточно много подводных камней и тонкостей в том числе и связанных с компиляцией. Как пример могу привести множество открытых проектов на C++ (на C тоже, но ИМХО масштабы чуть по меньше), у большинства если посмотреть на include становится видно, что часто в .h включают то, что там совершенно не нужно и хватило бы простого описание, что это класс или структура, т.к. в этом заголовке объявлен только указатель. Вроде мелочь, но в итоге один заголовок тянет другой, тот еще один и т.п., в итоге компилятору приходится перелопатить горы фактически не нужные для компиляции данного участка программы кода. Это конечно можно отнести на сторону недостатков C и C++, хотя если человек будет думать над тем, что пишет, то таких проблем не возникнет.

хм, что из себя должна представлять БД модулей? Фактически ничего нового там не будет, те же объекты, они же файлы, только с доп. свойствами, так версиями можно вполне эффективно рулить с помощью svn и множества других систем. Только это получается еще и более гибкий способ, можно просто скомпилировать один файл, а можно сделать большой проект.
Конечно можно сделать, что функция это объект и т.п., но упростит ли это разработку? ИМХО только заставит разработчика лишний раз тыкать мышкой по кнопкам.

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

Я согласен, с тем, что смотря на картинке можно быстрее понять например как взаимодействуют модули, но зачем это пихать в код? Мне удобнее было бы, если бы в комментарии было указано, где находится картинка. Но если в самом комментарии будет картинка, то придется каждый раз что бы на нее посмотреть, возможно прокручивать несколько сот строк кода... Да и потом, эти идеи достаточно просто реализовать, но я до сих пор не видел ничего подобного. М.б. тебе стоит этим заняться, будешь зарабатывать деньги на новых инструментах разработки софта?

Раскраска кода не отвлекает, а помогает, так же использую группировку кода. Но это не картинки на пол экрана, которые мне проще открыть в отдельном окне, или вообще напечатать.
Добавлено спустя 10 минут, 37 секунд
Root
Вот на счет этого не уверен. Я как то ковырял binutils и gcc по поводу поддержки архитектор процессоров, насколько я понял, gcc вообще не генерирует объектные файлы, а этим занимается gas. Хотя могу ошибаться.

gas- одно из агрегатных состояний вещества, типа намёк на любимый линукс фанатами метан и биореактор? Или это gnu asm и ассемблер x86? Если уж сам к манам послал, то может подкинешь что-нибудь стоящие по ассемблеру на линукс, желательно где уделено внимание одновременной работе с несколькими ядрами cpu. Я только одного не понял, как ассемблерный код x86 может запуститься под другой архитектурой, или кросс-платформенность уже нечто другое, или ассемблерный код к архитектуре не привязан?



Да ладно? У меня всё, что пробовал из жабы, отнюдь не летало и память жрало нехило. Походу те, кто считает яву и качественное п.о. несовместимыми, правы.

STXTSS
GNU Assembler.

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

А это скорее у кого-то все перемешалось в голове в данном контексте AT&T это синтаксис x86 ассемблера. А GCC использует внутри еще одно промежуточное состояние Такова цена кросс-платформенности...

Swappp

http://en.wikibooks.org/wiki/X86_Assembly/GAS_Syntax
По ссылке пишут, что можно gcc генерить сразу объектники, а можно получать ассемблерный листинг и потом из него уже с помощью gas'а объектник... Так вот - при таком раскладе получается, что gas не является необходимым компонентом для работы gcc, а следовательно gcc не преобразует в явном виде сишный код в ассемблерный (внутреннее представление компилятора в счет не берем, т.к. оно характерно для любого компилера).
Добавлено спустя 10 минут, 39 секунд
STXTSS

об этом и речь. Что в яве компиляции быстрая, а исполнение - нет.

не смешно

ага.

никак. Регистры разные минимум, команды тоже. Другое дело, что gas знает несколько платформ, т.е. умеет под них генерить машинный код Но при этом входной source код для них будет разный.

Что никак, даже я, не программист, про это читал. Просто как-то странно слышать от программистов про кросплатформенный ассемблер. Поддержка нескольких архитектур ещё далеко не кросплатформенность.


Ага. Скоро начнёте РусОС обсуждать и язык д( душевный), для снятия стрессов, а в итоге на налоги граждан везде будет "лучшая и самая лицензионная" ос "Windows Vista".
P.S. Надеюсь холивар будет, а то как-то скучно форум читать стало, ничего интересного даже по теме форума.

Не будет. Тему про очередной мсовский отчет про безопасность прикрыли в самом начале холивара. Здесь будет тоже самое.

Ага-ага. Только в этом случае о государственной безопасности можно забыть, т.к. хотя бы одного из этих 960 человек я думаю можно подкупить и он вставит пару дополнительных строк кода, которые будут при необходимости активизироваться командой из вне...
Вы, конечно, можете сказать, что т.к. это opencource, то исходники есть и всё можно проверить. Интересно, каково это протестировать несколько сотен тысяч строк кода, с учётом того, что далеко не все из них имеют комментарии...
ИМХО Линукс как систему можно взять, но писать её надо самим и с "нуля". Только в этом случае мы будем гарантированны от того, что произошло в Ираке с Windows...

Зачем подкупать? Сам можешь присоединиться к разработке и вставить. Линукс - самая небезопасная ОС, ее имеют все кто хотят. Вот стоит у меня ща сервер, думаешь я чувствую себя в безопасности? Да нет же! Мне сегодня угрожали по аське, сказали взломают, вот завтра будет обновление системы, специально мне руткиты встраивают.

terran, для начала посмотри КАК разрабатывается ядро, а потом чушь неси.

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