Увидела свет (http://jarios.org/node/30) первая альфа версия микроядерной ОС Jari (http://jarios.org/), исходные тексты которой распространяются в рамках лицензий GPL и LGPL. В основе Jari OS лежит мультисервисная архитектура и микроядро μString. Система поддерживает (http://jarios.org/node/11) многозадачность, многопоточность, SMP, real-time, POSIX API. Драйверы устройств реализованы в виде изолированных системных сервисов. В качестве файловой системы используется ext2, но в будущем разработчики планируют перейти на XFS. В разработке находится реализация TCP/IP стека и GUI интерфейса (в настоящий момент доступна только консоль через framebuffer). Размер установочного iso-образа (http://jarios.org/node/14) менее 8 Мб.
URL: http://jarios.org/node/30
Новость: http://www.opennet.me/opennews/art.shtml?num=22210
Звучит красиво и интересно! Хорошо что есть такие замечательные проекты, возможно какой-то из таких станет ОСью будущего, как сейчас - Linux. Наверное программы можно будет унаследовать, а драйвера открыты - ничто не мешает развитию :)
Отлично, что возродился интерес к микроядрам
>Отлично, что возродился интерес к микроядрамон никогда не пропадал. проблема в финансировании. мажделмашу и красношляпам гнутая ось с микроядром в х. не впилась
микроядрам микрофинансирование ))
Более того - оно и просто бизнесу никуда не впилось.Просер производительности есть а преимущества - в основном теоретические, а это на хлеб не намажешь и в кошелек не положишь.А вот на более мощные сервера баблосов - надо.Ну а то что бизнес не собирается густо финансировать блажь нужную только теоретикам для их душевного спокойствия думаю все кто не на ручнике уже поняли.Ну, кроме некоторых, особо одаренных, которые грезят микроядрами но настолько оторвались от реалий что при этом забывают некоторые азбучные истины.Например что бизнесу и большинству тех кто пользуется ОС нужен вовсе не музейный экспонат который круто сделан но вот только не бегает или бегает хуже чем менее эстетичные системы.И если кто не понял - таким манером сдох например вагон архитектур процессоров, при засилье х86 уродца.Который может и фуфло, но зато - сравнительно дешев, доступен, а потому - практичен.Да настолько что даже в суперкомпьютеры идет запросто.
Не забывайте, что Mac OS X использует микроядро Mach, и все real-time системы микроядерные. Если люди сначала думают, потом делают это всегда лучше, но творчество толпы этому не способствует
А вы не опускайте нюансы, которые наверное намерянно не упомянули. Например mac os x далеко не микроядерная, гибридная - это примерно тоже самое, что часть функциональности linux kernel или freebsd перенести в юзерспейс, а часть оставить внутри ядра. Также real-time системы обычно выполняют весьма специфические функции, и пока системы типо qnx не доказали что они способны превосходно работать на мощьном железе выполняя разные функции одновременно - вкладывать в них деньги межделмаши не будут.
А что до толпы, то модель разработки свободного софта позволяет и думать и делать, и делать и потом думать, и делать как все, каждый сам выбирает.
У неё очень качественный дизайн ядра, она гибридная, микроядро отделено от системы ввода/вывода I/O Kit и от сервисов, выполняемых в пространстве ядра, но вполне обособленных. Что касается Linux, Free BSD - это не одно и то же, у них множество зависимостей внутри монолитного ядра, вы можете вынести в модули, но получите зависимости между модулями т. е. то же самое, но только outside. Чтобы выполнять сервисы в пользовательском пространстве нужен отлаженный механизм сообщений, специальные менеджеры - всё это нужно проектировать изначально.
>от сервисов, выполняемых в пространстве ядра, но вполне обособленных.Ха, где-то я это уже видел?Наверное в MSовском франкенштейне.Который тоже в теории какой-то там модульный, обособленный, бла-бла-бла.На практике - 4 мега кернельного кода в Executive, еще 2 в win32k.sys и еще вагон дров.В итоге получается бааааальшая куча костылей в ядре через некоторое время.
>пространстве нужен отлаженный механизм сообщений, специальные менеджеры - всё это нужно
>проектировать изначально.Ага, вот только линуксоиды юзают штуки типа FUSE - которые по логике вещей как раз что-то типа драйверов (ФС) в юзерспейсе.
>Не забывайте, что Mac OS X использует микроядро Mach,Вылезли маковцы.Какие они все примитивные и предсказуемые.И что самое интересное - как правило ни один понтующийся системщиком и уж тем более ядерщиком ни разу не является.
>и все real-time системы микроядерные.
Да что вы говорите?Правда чтоли?Вообще-то так, FYI, во многих случаях когда надо предельно низкое время реакции и его предсказуемость и минимальный разброс - делают однозадачную фирмвару для таракана способного быстро дергаться на события.Часто без уровней привилегий даже.И даже не ос вообще в привычном понимании зачастую.Которая целиком посвящена своей задаче.Вот оно такое - реалтаймнее некуда.Например может обмотки двигателя в реальном времени вместо механических щеток коммутировать.Или там еще что не менее жесткое по реалтайму, с реакцией в считанные такты процессора (в том числе и за счет отсутствия переключения между разными режимами CPU).Ну и вы понимаете что реальное время не ждет и никакие опоздания в таких применениях недопустимы.Как и сбои.Посему самый крутой и злобный реалтайм == простая, однозадачная, вылизанная до битика фирмвара, занимающаяся сугубо своим делом.Которая операционкой вообще не является по большому счету.
>Если люди сначала думают, потом делают это всегда лучше,
>но творчество толпы этому не способствуетНу вон Таненбаум со своей системой до сих пор "где-то есть".А реальные дизайны хоть немного набравшие популярность - гибридные как максимум.
>Более того - оно и просто бизнесу никуда не впилось.Просер производительности есть а >преимущества - в основном теоретические, а это на хлеб не намажешь и в кошелек не >положишь.А вот на более мощные сервера баблосов - надо.Поумерьте свой пыл молодой человек, ынтырпрайз не смотрит на ОС, он смотрит на другие вещи, а именно на то сколько мартышек и как можно нанять и чтобы так чтобы их подменить можно было. Тот объем денег который там крутится позволяет добавить немного мощностей, за счет стабильности, и как вы понимаете верификации. Ваш эпотаж напоминает старый добрый спор - asm vs C , что мол на ассемблере одна инструкция, а вот C компилятор делает на тоже 2-3. Поймите наконец, что для многих задач потеря на переключение контекста (на современных архитектурах это ооооочень малая величина) не имеет значения. Линукс? Верифицировать? Сомнительное занятие если его не кастировать, а если кастрировать - то зачем он такой из себя мало на что способный нужен ?
Микроядерная архитектура имеет свое предназначение, да не стоит его пихать везде и всюду (что кстати делают с монолитом), и денег на подобные вещи выделяют, выделяли и будут выделять. Не всем интерестна монолитная помойка. Да и ктому же есть системы в которых есть требование - при отказе 2/3 ОС она должна работать, монолит при отказе любой подсистемы свалится, грамотное микроядро нет.
Другое дело то что микроядерный системы в разработке на порядки сложнее и трудозатраты гораздо больше, проще пихнуть готовый или полуготовый монолит и доработать, чем серьезно подойти к вопросу, если эти ребята сделают что то стоящее, то вполне это может занять свою нишу.
>Ваш эпотаж напоминает старый добрый спор - asm vs C , что мол на ассемблере одна
>инструкция, а вот C компилятор делает на тоже 2-3.Дельно говорите, мне нравится.Но вот только си могли предложить нечто чего ассемблеру совсем не под силу - переносимость.А это значит что при смене архитектуры наработки не пойдут псу под хвост.Понятный и доходчивый аргумент, да.Экономия бабла на переписку софта - налицо(особенно если вспомнить смену x86 -> 286 -> 386 которые показали что смена архитектуры - не пустой звук).А те кто козыряет преимуществами микроядра не могут придумать не одного нормального плюса компенсирующего их медлительность.Особенно если брать микроядра в абсолютизированном виде а не гибриды типа NT у которых черт знает что в ядерной части творится с мегазами кода и покладанием на все возможные концепции.И там кстати в теории дрова хоть и в ядре через HAL должны работать а на практике на это половина дров кладет.Ради скорости, разумеется :)
>Поймите наконец, что для многих задач потеря на переключение контекста
А еще для очень многих - имеет.
>(на современных архитектурах это ооооочень малая величина)
Она малая по сравнению с чем?Эта величина как правило достаточно велика по сравнению с временем выполнения одной инструкции в хороших условиях.А потому - если надо часто переключаться, в случае когда надо много переключений, проц только и будет переключаться.Вместо того чтобы что-то полезное делать.Что и наблюдается - внос в ядро того что тормозило порой дает прирост скорости чуть ли не в разы.Что и способствует разведению гадюшника в режиме ядра :)
>не имеет значения. Линукс? Верифицировать? Сомнительное занятие
>если его не кастировать, а если кастрировать - то зачем он
>такой из себя мало на что способный нужен ?Затем что под конкретную задачу конкретная железка свое дело будет делать.С минимальными усилиями на разработку и неплохой скоростью.Получается дешево, просто и практично.И если делать не через анус - достаточно надежно.Если вы не заметили, что-то в этом духе и происходит в последнее время.
>Микроядерная архитектура имеет свое предназначение, да не стоит его пихать везде и
>всюдуВот.Золотые слова.Своя ниша у микроядер есть.И давно.И там они живут и наверное и дальше будут жить.Только эта ниша - не десктопы и даже не сервера.Как минимум - обычные.
>(что кстати делают с монолитом),
Кстати да, иногда выходит достаточно забавно.Вплоть до замены специфичным линухом VxWorks-ов.
>и денег на подобные вещи выделяют, выделяли и будут выделять.
Все вы правильно говорите ;)
>и ктому же есть системы в которых есть требование - при
>отказе 2/3 ОС она должна работать, монолит при отказе любой подсистемы
>свалится, грамотное микроядро нет.Вот только майнстримом это не будет.Простите, в большей части железок даже просто оперативка - без ECC.При этом для начала, проблемы просто обнаружить - нелегко.Ну а далее недостоверные данные будут сохранены и - пошло-поехало, никакие микроядра не спасут.
>Другое дело то что микроядерный системы в разработке на порядки сложнее
Скорее, сложно - достичь хорошей производительности при не слишком изрядном засирании дизайна.
> и трудозатраты гораздо больше, проще пихнуть готовый или полуготовый
> монолит и доработать,Именно так.Хорошо говорите.Жизненно.Без фанатизма.
>чем серьезно подойти к вопросу, если эти ребята сделают что то
>стоящее, то вполне это может занять свою нишу.Свою нишу - бесспорно занять может.Вот только эта ниша будет совсем не тем чем грезят прыщавые пионеры да фанаты системных архитектур в своих мечтах.Ну, примерно как RTOSы - они есть и используются.Но обычно их почти никто не видит.
>Более того - оно и просто бизнесу никуда не впилось.Просер производительности есть
>а преимущества - в основном теоретические, а это на хлеб не
>намажешь и в кошелек не положишь.А вот на более мощные сервераТы инженер или кто? Прочти QNX Neutrino 6.*. Системная архитектура. Если тебя это не впечатлит, тогда я смирюсь. Это совсем другой мир. Там внутрення работа похожа на работу сети. Вообщем это и есть сеть из процессов. И, чтобы понять какие преимущества на многопроцессорных машинах от микроядерных ОС, нужно хорошенько вообразить в целом систему процессоры-процессы и IPC, как связка всего этого. Пока большинство думают по-старому и ничего кроме защиты процессов друг от друга в микроядерных ОС не видят, а там совсем другая идеология. Вирт, без относительно к ядрам, сказал: исходный текст не нужен, если вы сделаете хороший интерфейс и документацию к нему. Вот как надо думать! Продуманные открытые протоколы взаимодействия функционально завершённых сервисов, а не исходники модулей с раскладкой внутренних системных структур.
>Вирт, без относительно к ядрам, сказал: исходный
>текст не нужен, если вы сделаете хороший интерфейс и документацию к
>нему. Вот как надо думать! Продуманные открытые протоколы взаимодействия функционально завершённых
>сервисов, а не исходники модулей с раскладкой внутренних системных структур.Ну так JCP.org все интерфейсы опубликовало в JSR'ах. ;)
>Ты инженер или кто? Прочти QNX Neutrino 6.*. Системная архитектура. Если тебя
>это не впечатлит, тогда я смирюсь. Это совсем другой мир. Там
>внутрення работа похожа на работу сети. Вообщем это и есть сеть
>из процессов. И, чтобы понять какие преимущества на многопроцессорных машинах от
>микроядерных ОС, нужно хорошенько вообразить в целом систему процессоры-процессы и IPC,
>как связка всего этого.Да я понимаю о чем вы - да, можно сделать систему намного красивее.Продуманно, стройно.
Но в конечном итоге - то же самое делают иначе.Да, кривее.Да, на том что есть.Но тем не менее, оно после всего этого - работает.И черт возьми занимает бОльшую часть из списка топ500 суперкомпьютеров, поэтому у вас будут определенные проблемы с доказательством тезиса насчет лучшей масштабируемости.Неэстетично?Возможно.А кто сказал что лучшие с точки зрения красоты дизайны побеждают?И почему тогда много хорошего и правильного железа подохло в угоду уродцу х86 с архитектурой не сильно моложе тех же *никсов?Знаете что мне это напоминает?Это напоминает ворчание архитектора который недовольно ругается: вот дескать сволочи!Застроили город как попало!Уроды!А ведь можно было сделать намного лучше!Особенно если с нуля спроектировать все и вся.Прекрасно, но вот только мы, жители города, знаем его таким и он нам нравится.И не обязательно вовсе чтобы он был строго по линейке вымерян и по проекту слеплен.Он вот такой какой получился за свое время существования.И пусть таким и будет.С системами - зачастую аналогично.А так - знаете, систему команд процессора и все что связано с ним тоже можно было переработать намного лучше чем уродливый х86 с его легаси костылями.Ну и где они, хорошие и правильные?В реальной жизни конкуренцию не осилили? :E
Интересно а почему:
"Basically we're don't try to implement a general purpose OS, first goal is a high-band routers and real-time industrial units. But it doesn't mean..."
Складывается такое ощущение, что ядра это вовсе не проблема в среде СПО. Нужны дрова, гамесы, CADы и проч., но только не ядра
> ...., гамесы, CADы и проч., но только не ядраЗачем?
Гамесы? а работать кто будет? и так отупели все от игр
дык к сожалению работать на линуксах сейчас могут только айтишники =)
>Интересно а почему:
>"Basically we're don't try to implement a general purpose OS, first goal
>is a high-band routers and real-time industrial units. But it doesn't
>mean..."Они видят, что все разработчики прикладного ПО засели в Linux/*BSD/Solaris и не желают смотреть на микроядра (наверно ждут когда Лайнус скомандует :).
>Они видят, что все разработчики прикладного ПО засели в Linux/*BSD/Solaris и не
>желают смотреть на микроядра (наверно ждут когда Лайнус скомандует :).А ему нечего командовать, он делает свою работу. Создавать стабильные интерфейсы для сервисов в userspace - это и сейчас можно делать. Технически, всё уже давно есть, для тех кто хочет конечно. Можно взять и переделать fuse, внести её в ядро. Потом сделать userspace реализацию btrfs допустим, и все будут рады(в том случае если оно будет работать лучше ядерного). То же касается и других подсистем, технических проблем с этим в свободных вёдрах нету, было бы желание.
>А ему нечего командовать, он делает свою работу. Создавать стабильные интерфейсы для
>сервисов в userspace - это и сейчас можно делать. Технически, всёДа я не об этом. Где найти столько энтузиастов портировать туда всё то ПРИКЛАДНОЕ ПО, средства разработки, которое сейчас написали для Linux/BSD/Solaris? Меня это удручает. Я ещё лет много назад пробовал начать двигать QNX или что-нибудь типа Hard. Фиг кого сагитируешь, все на Linux'ах.
А ничего также не мешает реализовать полную совместимость api поверх qnx. Поверх hurd это уже сделано давно, ну если конечно принимать во внимание крайнюю сырость проекта и учесть что сам он работоспособен не сильно. Создать слой совместимости и ПО не придётся портировать.
Вообще заметно пока лиш одно, нет желающих делать полный слой совместимости для микроядерных осей или наоборот - делать из монолитных ядер гибридные или микроядерные. То есть не в том дело что кто-то что-то кому-то ограничивает, а банально нет потребности в этом. Вся соль в том, что большинство программистов просто не видит разницы между микроядерными и монолитными ядрами настолько, чтобы начать возится с другой системой. Тот же Линус, будучи удовлетворён работой над linux не имел ни одного аргумента за теорию Таненбаума. А мифами как известно сыт не будеш.
>Потом сделать userspace реализацию btrfs допустим,А оно, простите, зачем?Если кто-то надеется что я буду использовать драйвер ФС который падает - он, простите, что-то не понял и настолько застрял в высоких концепциях что забыл - а зачем собственно ФС нужны.И если вспомнить что от ФС нужна скорость, надежность, стабильность и отсутствие потерь данных - всем кто не тормоз понятно, что при выполнении этих требований нет никакой проблемы что ФС живет в ядре(а скорость от этого выигрывает).Если ФС надежная, стабильная и не теряет данные - ее и изолировать не надо.А если у нее падать драйвер будет - она никому не нужна будет.Ни в ядре, ни в юзерспейсе, ни где там блин еще.
Я конешно понимаю, что только начинают, но изначально пихать
printf в ядро, как-то не кошерно,иль
static int always_inline imin(int x, int y)
{
return (x < y) ? x : y;
}Ну на кой нужна отдельная функция, хоть и inline???
Чудненько #define imin(x,y) (x < y) ? x : y
printf в ядре для отладки, если внимательно смотреть, причем он прозрачно вывод свлй шлет, либо в vga, либо в serial.в юзерспейсе printf вообще очень отдельная история.
>Я конешно понимаю, что только начинают, но изначально пихать
>printf в ядро, как-то не кошерно,я там написал,
>[оверквотинг удален]
>иль
>
>static int always_inline imin(int x, int y)
>{
> return (x < y) ? x : y;
>}
>
>Ну на кой нужна отдельная функция, хоть и inline???
>
>Чудненько #define imin(x,y) (x < y) ? x : yа какая разница ? компилятор при оптимизации с inline как с макросом и поступит - это уже дело вкуса я считаю.
>а какая разница ? компилятор при оптимизации с inline как с макросом
>и поступит - это уже дело вкуса я считаю.скорее дело безвкусия. директивы ломают однородность кода
я за авторский вариант
> Чудненько #define imin(x,y) (x < y) ? x : yЭто детский сад тридцатилетней давности.
imin(i++, j++);
imin(atoi(argv[1]),10);
Макросы для вычисления выражений плохо изначально.
Описываю на примере. Вот ваш макрос:
#define imin(x,y) (x < y) ? x : yКакой будет результат для выражения?:
imin(InX++, InY)А ведь тот кто пишет код использующий вашу функцию-макрос вполне возможно не посмотрит, что это функция или все таки макрос.
А что насчет этого скажете? :)#define min(x, y) ({ \
typeof(x) _min1 = (x); \
typeof(y) _min2 = (y); \
(void) (&_min1 == &_min2); \
_min1 < _min2 ? _min1 : _min2; })#define max(x, y) ({ \
typeof(x) _max1 = (x); \
typeof(y) _max2 = (y); \
(void) (&_max1 == &_max2); \
_max1 > _max2 ? _max1 : _max2; })
>А что насчет этого скажете? :)Затейливо.
Смысл пассажа "(void) (&_max1 == &_max2);" ускользает :)
gcc 3.4.5 с опцией -O2 в простейшем примере сгенерировал одинаковый код для макроса и inline фунции.Но мне кажется, что для понимания и написания inline функция проще.
>Затейливо.Это же наша Родина... Гм, не то. Это же "современный" Си, коллега. Ж)
Короче, они у линукса :) "плохому научились".>Смысл пассажа "(void) (&_max1 == &_max2);" ускользает :)
Проверка типов аргументов макроса...
>одинаковый код для макроса и inline фунции.
...во время компиляции. Или около того? Читал где-то. Ссылки нет - плохо, что гугль :) по Си-выражениям и/или символам-не-буквоцифрам не ищет.
Возможно, ещё на то, что оба аргумента - lvalue.
> Смысл пассажа "(void) (&_max1 == &_max2);" ускользает :)http://mail.nl.linux.org/kernelnewbies/2003-12/msg00007.html
> Но мне кажется, что для понимания и написания inline функция проще.
Для понимания - возможно. Но вам придется писать свою инлайн функцию для каждого сравниваемого типа.
Спасибо за ссылочку.
>[оверквотинг удален]
> typeof(x) _min1 = (x); \
> typeof(y) _min2 = (y); \
> (void) (&_min1 == &_min2); \
> _min1 < _min2 ? _min1 : _min2; })
>
>#define max(x, y) ({ \
> typeof(x) _max1 = (x); \
> typeof(y) _max2 = (y); \
> (void) (&_max1 == &_max2); \
> _max1 > _max2 ? _max1 : _max2; })Вау, здорово.... расскажи по строчками плиз...
>[оверквотинг удален]
>> (void) (&_min1 == &_min2); \
>> _min1 < _min2 ? _min1 : _min2; })
>>
>>#define max(x, y) ({ \
>> typeof(x) _max1 = (x); \
>> typeof(y) _max2 = (y); \
>> (void) (&_max1 == &_max2); \
>> _max1 > _max2 ? _max1 : _max2; })
>
>Вау, здорово.... расскажи по строчками плиз...http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Statement-Exprs....
http://gcc.gnu.org/onlinedocs/gcc-3.3.1/gcc/Typeof.html
http://mail.nl.linux.org/kernelnewbies/2003-12/msg00007.html
а можно обьяснить в чем смысл такого извращения?я всегда получал удовлетворительный результат следующим образом:
#define MIN(x,y) (((x) < (y)) ? (x) : (y))
>а можно обьяснить вНет, нельзя.
Учитесь читать. Учитесь не писать уже написанный вопрос.
>я всегда
Учитесь принимать непознанное и, да - ужас!, учитывать своё незнание.
Успехов в!
> Чудненько #define imin(x,y) (x < y) ? x : yв дополнение к критике товарищей добавлю -
во что развернётся imin(a=b,c), imin(a|b,c), imin(a,b)*2 ?так что inline рулит :)
>> Чудненько #define imin(x,y) (x < y) ? x : y
>
>в дополнение к критике товарищей добавлю -
>во что развернётся imin(a=b,c), imin(a|b,c), imin(a,b)*2 ?Так на первом курсе дефчонки на паскале пишуть,
надо раздельно, и для себя и для другихimin(a=b,c) => a = b; imin(a, c)
imin(a|b,c) => a |= b; imin(a,c);
imin(a,b)*2 => 2 * imin(a,b)
> Чудненько #define imin(x,y) (x < y) ? x : yint a=2; b=3;
imin(a++ ,b);
printf("a=%d\n", a);Что будет на выходе?
А для inline функции a++ выполнится 1 (один) раз после выполнения кода этой функции. Вот поэтому - функция, а не макрос.
Объясните мне - зачем к inline ставить static, какой в этом сакральный смысл?
ak молоток :)
Помню как все это обсуждали в irc на форестнете :)
>Объясните мне - зачем к inline ставить static, какой в этом сакральный
>смысл?Что бы сделать некий аналог private, тобишь она видна только в пределах своего об
ектного файла.
>Объясните мне - зачем к inline ставить static, какой в этом сакральный
>смысл?обычно сужение области видимости этого символа до одного объектного файла
>Объясните мне - зачем к inline ставить static, какой в этом сакральный
>смысл?http://gcc.gnu.org/onlinedocs/gcc/Inline.html
When a function is both inline and static, if all calls to the function are integrated into the caller, and the function's address is never used, then the function's own assembler code is never referenced. In this case, GCC does not actually output assembler code for the function, unless you specify the option -fkeep-inline-functions.
В этом случае функция вычисляется на этапе компиляции и код для нее не генерируется. Короче, это - костыль, чтобы не пользоваться макросами.
VBox всё ещё не поддерживается?
Стоит только для этой операционки реализовать спецификации JavaSE и JavaEE и линуксу будет капец в энтерпрайзе.
>Стоит только для этой операционки реализовать спецификации JavaSE и JavaEE и линуксу
>будет капец в энтерпрайзе.Ты столько цифр не выговоришь. Ну хотя если только в таком же бреду, в котором ты сочинил свой пост. =)
>>Стоит только для этой операционки реализовать спецификации JavaSE и JavaEE и линуксу
>>будет капец в энтерпрайзе.
>
>Ты столько цифр не выговоришь. Ну хотя если только в таком же
>бреду, в котором ты сочинил свой пост. =)Цифр, на самом деле, не так уж и много - 10 всего (в десятеричной системе счисления)!
А Вы какую систему счисления имели ввиду?
Грозилась синица море поджечь... ;)
Когда-то, не совсем давно, так говорили и о, тогда совсем неизвестной, ОС Linux...
Так что не нужно задирать нос в гордыне...
Все возможно!
>так говорили и о, тогда совсем неизвестной, ОС Linux...нет такой "OC Linux"
есть свалка си-кода как ведро к юникс-клону
> Так что не нужно задирать нос в гордыне...Понимаете, я не верю в идиотские теоретизмы от господ типа iХРЕН.Вот когда он сможет внятно ответить на простые вопросы:
1) Кто напишет для этой штуки ДРАЙВЕРА под всякие энтерпрайзные фенечки коих много и разных?
2) Что будет со СКОРОСТЬЮ РАБОТЫ из-за выноса кучи всео в user-mode сервисы?Вот тогда и будет разговор.И когда на эти вопросы появится внятный вменяемый ответ который устроит тех кто нынче юзает пингвинуксы - я поверю в перспективы иной ОС.Все просто, как видите ;)
А что до ОС для high-bandwidth роутеров - например на NAG.RU (вроде нормальный ресурс по части всякой high-bandwidth хренотени?) фрукты рапортуют выигрыш в 2-3 раза от вноса PPTP в ядро (замена тормозного user-mode PPTP на ядерный вариант aka Accel) под тяжелыми нагрузками.Я что-то не думаю что корпоративщики резко побегут юзать более тормозные системы.Они наверняка и так счастливы дикими затратами на покупку мощных серваков под жава-байду и есть резонные сомнения что они побегут покупать еще более мощные сервера с радостными воплями.Особенно сейчас, когда кризис всех придавливает и хрен бы его знает, сколько он еще всем будет икаться.
Самое главное преимущество микроядра - надёжность, если она решает, люди будут платить. А она решает.
>Самое главное преимущество микроядра - надёжность, если она решает, люди будут платить.
>А она решает.Надёжность, как уже не однократно обсуждалось везде, где появлялось слово микрояд:), достигается не только за счёт операционной системы. Если во встраиваемых миниатюрных системах дублирование аппаратуры применяется, но не слишком. То в этом самом пресловутом ынтерпрайзе редко бывает одинарное или даже двойное дублирование. В случае когда у вас парк серверов, по которым плавно размазана нагрузка, вы уж простите - но срать можно на одну тысячную шанса отказа ядра операционки одного из серверов. Не говоря уже о том, что линукс часто также там работает под гипервизором. В общем это к тому, что чем больше затрат на инфраструктуру, тем больше средств минимизировать отказы.
Платить будут только в том случае, если надёжность достигается дешевле, вот тогда да, будут платить.
В воображаемом мире Таненбаума все устройства на всех системах подвержены перезапуску, отключению, подключению и замене - в реальном времени. В реальных системах, где всё это есть - существуют и другие средства по обеспечению надёжности, кроме запуска поверх железа микроядерной оси.
>В случае когда у вас парк серверов, по которым плавно размазана нагрузка,
>вы уж простите - но срать можно на одну тысячную шанса отказа ядра
>операционки одного из серверов.отсюда все проблемы. крупным игрокам надо продать _много_ железа.
посмотрите на ту же макось, она сцуко работает и работает, в единственном экземпляре.>В воображаемом мире Таненбаума все устройства на всех системах подвержены перезапуску,
>отключению, подключению и замене - в реальном времени.состояние устройства не обязано меняться при реинкарнации.
>В реальных системах, где всё это есть - существуют и другие средства по обеспечению
>надёжности, кроме запуска поверх железа микроядерной оси.таким образом применение сильно ограничивается
In addition, в суперкомпьютерах обычно сервисы linux работают над над каким либо микроядром.
>In addition, в суперкомпьютерах обычно сервисы linux работают над над каким либо
>микроядром.Вспоминаем производительность :) Да да конеткст свитчи и прочее, очень быстро, главное что микроядро конечно тормознее, потому что микроядро.
Проблема в том, что пишушие тут люди в лучшем случае занимались писульками вроде драйвера фейкового девайса под линукс, а вот дизайном не занимались, ну не получилось.
>Вспоминаем производительность :) Да да конеткст свитчи и прочее, очень быстро,Внимание, вопрос: а почему же тогда accel внесенный в ядро делает в 2-3 раза PoPToP в юзермоде?Уж не из-за экономии ли на этих "очень быстрых" переключениях контекста и т.п.?
> посмотрите на ту же макось, она сцуко работает и работает, в единственном экземпляре.Вот скажите, положа руку на сердце, часто вы видите рестарты или взвисы линуха на исправном железе?Особенно всяких там серверах, etc.Я вот видел у перца сервак с аптаймом в несколько лет(ну да, не апдейтил перец ядро).Вопрос: кому и напуркуа при этом нужны микроядра кроме эстетов которые ими бредят уже не первый десяток лет?А воз и нынче там.Как было у компов свойство тормозить, так и осталось, потому никого не прет идея еще притормозить ради какой-то чисто-теоретической выгоды.Тем кому практика нужна - ставят распределенные структуры, это и от сбоев железа защищает, и что бы там макофилы не пели, а если вы купите миллион железок, сколько-то их через год умрет.А значит, даже если железка одна, есть ненулевой шанс что она сдохнет.И при этом уже пофиг, микро там ядро или нет.А что до микроядер - некоторые гипервизоры так сделаны, но они - совсем уж микро.Вот в таком виде и с поддержкой этого процами на уровне железа оно даже поживет.Просто это будет называться гипервизором и не будет ОСью в привычном понимании.
>Вот скажите, положа руку на сердце, часто вы видите рестарты или взвисы линуха на исправном железе?Да.
>Я вот видел у перца сервак с аптаймом в несколько лет(ну да, не апдейтил перец ядро).
Я тоже видел мейнфрейм с дизельным генератором и маленьким юниксом.
>Вопрос: кому и напуркуа при этом нужны микроядра кроме эстетов которые ими бредят уже не первый десяток лет?
Тем кому нужна гибкость и масштабируемость на уровне ОС, а не ынтырпрайз джава поделий.
>А значит, даже если железка одна, есть ненулевой шанс что она сдохнет.
Если все в одном адрессном пространстве есть ненулевой шанс что оно сдохнет быстрее чем железка на несколько порядков.
>И при этом уже пофиг, микро там ядро или нет.
И при этом уже не пофиг, перезапускать всю систему теряя данные и время, или перезапустить драйвер.
>Просто это будет называться гипервизором и не будет ОСью в привычном понимании.
Гипервизор + куча монолитов == микроядро + куча сервисов, по производительности конечно, по остальным параметрам второе лучше, или вам совсем ничего не понятно ?
>ставят распределенные структуры, это и от сбоев железа защищает,
Нет, далеко не во всех случаях, можно поставить на монолитиках такое распределенное чудо, что оно во первых не будет обеспечивать нормальную масштабируемость, а во вторых тормозить будет покруче чем микроядерная ОС.
Воз и ныне там изза таких бездельников и неучей как ты, которые ковыряются и ноют изза того что не дано таким как ты что либо серьезное разрабатывать, кишка тонка. Было б больше грамотных людей и времени больше, давно бы на распределенных системах микроядерные и мультисервисные ОС вытеснили монолиты. Да монолиты останутся - для своих задач, где важна производительность, т.е. всякие дисковые массивы, application based системы и прочее - туда где микроядерная ОС имеет одни минусы.
>Да.Что, правда?И с какой же причиной это происходит?Неужели отказ драйверов помеченных как стабильные в выпущенном ядре?Может быть, тогда назовете проблемные драйвера?Так, ради интереса?
>Я тоже видел мейнфрейм с дизельным генератором и маленьким юниксом.
Ну, вы молодец.Возьмите с полки пирожок.А я еще кучку серверов на пингвине вижу.Почему-то они работают и не падают.Вот незадача то.
>Тем кому нужна гибкость и масштабируемость на уровне ОС,
Под масштабируемостью наверное имеются в виду накладные расходы на переключение контекстов и межпроцессные коммуникации, которые при нужде сделать это часто и много ставят все колом :).Если это не так, то какого хрена в пингвине pptp от вноса в ядро выигрывает в 2-3 раза?Вот как раз внос его в ядро приветствуют те кому оно надо.По части масштабируемости.Провы, бэть.
>а не ынтырпрайз джава поделий.
Ну хорошо, а куча PPTP серверов у провадеров?Почему-то прововские пиплы радостно взвыли узрев accel.Который на тех же серверах позволяет в 2-3 раза больше выжать.За счет вноса PPTPшного добра в ядро вместо user-mode демона.Внимание, вопрос - а на чем еще кроме переключения контекстов и т.п. оно может сэкономить столько?И, кстати, как вы понимаете - когда оно многим надо - технология быстро отлаживается до непадучего состояния.Да, раньше были мессаги о паниках от этой штуки.Нынче прекратились вроде.
Чисто для себя - я бы хотел видеть ОС с *работающими* драйверами.Которые не глючат и просто работают.А не которые могут (если повезет) отскрестись при глюках и продолжить работу.Стало быть при этом пофиг микро там ядро или нет.Драйвера работать должны.А не глючить.Глюк драйвера в любом случае означает потенциальные потери данных или железо в непредсказуемом состоянии. А если посмотреть на обычное писючное железо которое в массе своей продается для ALL - да там пофиг микро ядро или нет.Говно с чипами на пределе возможностей технологий, без ECC в оперативе и прочая глючить БУДЕТ.И с микро ядром и с обычным.За счет говняности железа например.И вагона глюков в оном.Правильное железо?Это круто.А оно где?Это вон то которое все позагибалось т.к. из-за правильности стоило немеряно? :\
>Если все в одном адрессном пространстве есть ненулевой шанс что оно сдохнет
>быстрее чем железка на несколько порядков.Ну, если дрова пишут индусы - тогда да.Только вот как по мне - возможность рекавери после сбоя драйвера даст индусам разгуляться и писать дрова будут менее квалифицированные перцы.А значит они натурально будут падать.Теряя юзерские данные, ставя железо раком и так далее.Будет ли лучше?Хз, не факт.А вот тормознее - будет однозначно.
>И при этом уже не пофиг, перезапускать всю систему теряя данные и
>время, или перезапустить драйвер.Ага, при этом 1 хрен потеряются какие-то данные, а то и вовсе железяка в промежуточном состоянии встанет колом.Как по мне - так драйвер *работать* должен.А не падать.
>Гипервизор + куча монолитов == микроядро + куча сервисов,
В общем то примерно так и есть, просто современные процы отрастили себе еще 1 кольцо по сути.На 1 ниже чем Ring0.Сделав на аппаратном уровне возможным нечто подобное.Хоть и не в том виде в каком сватали это теоретики.
>по производительности конечно, по остальным параметрам второе лучше,
>или вам совсем ничего не понятно?Да нет, почему же, понятно, только вот красота архитектуры - одно.А рабочие качества системы на практике - другое.И одно часто другому мешает.Побеждают в этом споре ессно не теоретики а практики.Потому что ALLу как правило нужна хорошо работающая на практике система, а не красивая в теории.Ну и в итоге обычно получается кучка красивых артефактов.Безусловно, "на подрочить" для системщиков - вещь.А на практике... хм, даже MS разрабатывавший NT с нуля и с какими-то мотивами микроядерности разработал в итоге франкенштейна.У которого нынче этак мегов 6 ядерного кода.Если не больше.Микроядром оно ну никак при этом не является.И дрова все-таки не сервисы.Какой-то хитрый гибрид.Сервисы - есть.Но драйверными вопросами - не занимаются.По причине скорости работы, елки.
>>ставят распределенные структуры, это и от сбоев железа защищает,
>Нет, далеко не во всех случаях, можно поставить на монолитиках такое распределенное
>чудо, что оно во первых не будет обеспечивать нормальную масштабируемость, а
>во вторых тормозить будет покруче чем микроядерная ОС.Да, а вот суперкомпьютеры - собирают.С тыщами и тыщами процов.Куда уж масштабнее?!И ведь блин, большинство на монолитном линухе.Где там ваши заявы про масштабируемость то?И почему список TOP 500 не коррелирует с вашим бухтежом?Т.е. большинство суперкомпов внаглую именно под монолитами.Может вы и здесь ваши сказки из пальца высосали?Как и байки про постоянные падения драйверов, которых я не наблюдаю.
P.S. как известно, в теории шмель летать не должен, поскольку слишком большой а крылья слишком маленькие.Но шмель об этом не знает и поэтому летает :).Вот и пингвины - так же походу :)
>Воз и ныне там изза таких бездельников и неучей как ты, которые
>ковыряются и ноют изза того что не дано таким как ты что либо серьезное
>разрабатывать, кишка тонка.Ух ты.Наезды начались.Стоит ли это понимать как окончание аргументов ака "нечем крыть"?
>Было б больше грамотных людей и времени больше, давно бы на распределенных
>системах микроядерные и мультисервисные ОС вытеснили монолиты.Дык кто не дает то?MS вон в своей NT что-то такое напоминающее пытался сделать.В итоге пришло все 1 хрен к какому-то франкенштейну с кучей кода ядра и дровами в ядре.
>Да монолиты останутся - для своих задач, где важна производительность,
>т.е. всякие дисковые массивы, application based системы и прочее
>- туда где микроядерная ОС имеет одни минусы.Осталось только найти где не нужна производительность, похрен энергопотребление и бОльшие накладные расходы, когда потоки данных растут и растут.Как 20 лет назад у компьютеров было свойство - тормозить, так и сейчас оно в общем то осталось.Потому что с ростом мощности и падением цен находятся все новые и новые задачи для компьютеров и вообще микропроцессорных систем.И чем лучше производительность на ватт - тем больше новых горизонтов можно открыть.А виртуализация например появилась потому что дает простые и понятные преимущества, которые многим нужны.А не потому что видите ли с теоретической точки зрения красивее.Кстати там еще вопрос что окажется лучше - монолит с виртуализатором или микроядро-гипервизор.Пока что оба подхода сосуществуют и кто в итоге победит - не особо понятно.Может и никто - будут жить на пару, как +R и -R в случае DVD до тех пор пока нечто принципиально иное все это не заменит.
>>Самое главное преимущество микроядра - надёжность, если она решает, люди будут платить.
>>А она решает.
>
>Надёжность, как уже не однократно обсуждалось везде, где появлялось слово микрояд:), достигается
>не только за счёт операционной системы. Если во встраиваемых миниатюрных системах
>дублирование аппаратуры применяется, но не слишком. То в этом самом пресловутом
>ынтерпрайзе редко бывает одинарное или даже двойное дублирование. В случае когдаДа, в случае когда кусок ОС, а именно файловая система, похерив метаданные обрушивает всю систему, а другая пытается это исправить, то да, ынтырпрайз решает, все остальные начинают дико тупить и искать дядю из Чикаго, который решил такое поставить.
>у вас парк серверов, по которым плавно размазана нагрузка, вы уж
>простите - но срать можно на одну тысячную шанса отказа ядра
>операционки одного из серверов. Не говоря уже о том, что линуксТочно, в ооо "рашбизнесничегодел" можно и насрать.
>часто также там работает под гипервизором. В общем это к тому,Так, пациент уже уточняет, так что лучше нативная ОС с теми же задержаким что и монолит или куча монолитов ?
>что чем больше затрат на инфраструктуру, тем больше средств минимизировать отказы.Судя по всему вы вообще представления не имеете об вашем "ынтырпрайзе"
>
>Платить будут только в том случае, если надёжность достигается дешевле, вот тогда
>да, будут платить.А я не знал.
>В воображаемом мире Таненбаума все устройства на всех системах подвержены перезапуску, отключению,Дак так и есть, он то поумнее вас будет.
>подключению и замене - в реальном времени. В реальных системах, где
>всё это есть - существуют и другие средства по обеспечению надёжности,Конечно, все есть, за ваши деньги и буклетики цветные и define другой поставят.
>кроме запуска поверх железа микроядерной оси.Да согласен, микроядра пихать везде не стоит, как и монолит, всему свое место.
>Дак так и есть, он то поумнее вас будет.А толку то?Где его супер-правильные ос?Что?Аж в универе, для обучения студентиков "как (не) надо писать ОС"?Это, бесспорно, крутое достижение в теории.И полный ноль результата на практике.Вот и кукует умный Таненбаум со своей ос.Никому нафиг не нужный.
кому то нужный, раз инвестировали в его проект
>кому то нужный, раз инвестировали в его проектНу вот где-то оно и будет.Qnx вон уж давно "где-то есть".Вам с этого факта сильно полегчало?
Есть iso image?
Respect!Ждём когда будет портирована с amd64 на х86
:)