>> И не система от Танненбаума - потому что он профессор остался на 20 лет в прошлом.

>Поясните пожалуйста вашу мысль. Вы его судите по возрасту, или говорите про какие-то конкретные идеи/мысли?

Я сужу по идеям, реализованным в Minix3 - я обо всех них читал лет 15 назад, во время микроядерного бума. Ни одна из известных проблем микроядер не решена, некоторые - усугублены. А если привести список идей, которые в Minix3 _не реализованы_ (типа страничной виртуальной памяти 8)) - становится просто непонятно, о чем вообще речь в проекте Minix3.

> Но ссылки приветствуются

Начни со статей в википедии и флейма "Linux is obsolete".

Я не удивлен. Тесты из параллельной вселенной.

>а в жизни именно линукс уделывает фрю...

примеры какие будут? или как всегда?

> монолитную тушку Linux еще попинают пару десятков лет

Фигасе, ещё 20 лет пинать и так почти 20-летний софт - это, определённо, успех...

FreeBSD это, между прочим, UNIX, а его пытаются пинать с начала 70-х, и, пока, безуспешно...

> А если привести список идей, которые в Minix3 _не реализованы_ (типа страничной виртуальной памяти 8)) - становится просто непонятно, о чем вообще речь в проекте Minix3.

Если они в нем не реализованы, это не значит, что их нельзя реализовать в принципе. Сдается мне, что их просто некому реализовывать.

Я не защищаю миникс, но Linux - это давным давно не поделие Торвальдса. Над ним трудятся тысячи людей. С этой точки зрения просто смешно сравнивать функционал линукса и конкретной реализации концепции микроядра - миникс3, которую сделал один профессор и пара его студентов. Естественно, он не юзабелен. Но когда лет через 10 ядро линукса будет весить терабайты и его невозможно будет дальше развивать, то куда потянутся толпы программеров? Пусть не к миникс, но, скорее всего, все таки к микроядру. И вот тогда за очень короткое время будут реализованы и страничная виртуальная память, и решены те "проблемы" микроядер.

Конечно, я гиперболизирую. Ничего с линуксом не сделается. Скорее всего будут предприняты меры по его "децентрализации". Но всё же. Я только хотел сказать, что концепции Таненбаума на мой взгляд отнюдь не устарели и еще пригодятся.

> Если они в нем не реализованы, это не значит, что их нельзя реализовать в принципе.

Почитай статьи на minix3.org - Танненбаум просто отрицает существование некоторых проблем (в драйверах Minix3 каждое обращение к порту - это ситемный вызов o_O)

> Сдается мне, что их просто некому реализовывать.

Именно так - потому что это никому не нужно. Но профессор делает хорошую мину при плохой игре :)

> Но когда лет через 10 ядро линукса будет весить терабайты и его невозможно будет дальше развивать, то куда потянутся толпы программеров? Пусть не к миникс, но, скорее всего, все таки к микроядру

16 лет назад примерно это было высказано Танненбаумом в флейме с Линусом. Лет 8-9 назад примерно то же было озвучено Джеффом Мерки (он не настолько известен, как профессор, но человек крайне опытный).

> Я только хотел сказать, что концепции Таненбаума на мой взгляд отнюдь не устарели и еще пригодятся.

Вряд ли. Я еще поверю в экзоядро. или Nooks, или EROS/CoyotOS, или (скорее всего) в ОС-как-набор-VM, но не в микроядро образца Minix - просто потому, что значительного выигрыша в решении практических задач оно не предоставляет.

> Вряд ли. Я еще поверю в экзоядро. или Nooks, или EROS/CoyotOS, или (скорее всего) в ОС-как-набор-VM, но не в микроядро образца Minix - просто потому, что значительного выигрыша в решении практических задач оно не предоставляет.

Хорошо. Может быть ты и прав. Подождем еще чуть-чуть =)

>Вопрос к специалистам: неужели этот jemalloc никак нельзя адаптировать для работы с линукс?

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

А че там HARD? Тоже вроде микроядро малевали.

Кажись флейм развивается... и кажить tailgunner может чего интересного сказать.

> Почитай статьи на minix3.org - Танненбаум просто отрицает существование некоторых проблем (в драйверах Minix3 каждое обращение к порту - это ситемный вызов o_O)

1. Какие проблемы он отрицает (список плиз)

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

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

Я лично согласен за это платить 10% от проца. И может даже 20%.

>> Но когда лет через 10 ядро линукса будет весить терабайты и его невозможно будет дальше развивать, то куда потянутся толпы программеров?

> 16 лет назад примерно это было высказано Танненбаумом в флейме с Линусом.

Я считаю "терабайты" явно надуманной проблемой.

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

Дааа, дайте нам ищщо гетзефактов, да побольше!!!

А по делу - ну что мне с этих графиков? Будь бздя хоть в 1000 раз быстрее Линукс, всё равно не смогу пересесть на неё из за хилой поддержки нового оборудования. Представте такие же графики, где будет указано количество поддерживаемого оборудования в зависимости от: версии ядра(для Линукс)/версии системы(для БСД). СЛАБО, ДА??!!112233

> (в драйверах Minix3 каждое обращение к порту - это ситемный вызов)

Те драйверы, которым нужно мало обращений к порту, как-нибудь переживут. А для тех, кому нужно много, есть SYS_VDEVIO -- process vectior with multiple (port IO) requests -- пусть объединяют реквесты, все равно в реальной жизни больше 1000 сисколлов в секунду не нужно (пусть драйвера объединяюнт обращения, глядишь еще и дисциплину какую введут, там elevator algorithm)

Вон видяха все равно больше 200 кадров в секунду не потянет, и диск тоже бесполезно чаще 1 мс дергать.

> которые в Minix3 _не реализованы_ (типа страничной виртуальной памяти 8))

Где об этом почитать?

> количество поддерживаемого оборудования в зависимости от: версии ядра(для Линукс)/версии системы(для БСД).

Потому и сижу под линухом, ибо любое железо держит :-)

> А че там HARD? Тоже вроде микроядро малевали.

К логопеду, дыбло.

ЗЫ: Надеюсь, он Вам разъяснит, почему правильно писать не "HARD", а GNU/Hurd.

---
С Уважением,

> И это будет не Minix3 - потому что он родился мертвым

s/мертвым/учебным/

Нам бы в училище родить такое -- я бы с ума сошел от счастья.

>К логопеду, дыбло.

>С Уважением,

Я один здесь вижу противоречие? :)

> список идей, которые в Minix3 _не реализованы_ (типа страничной виртуальной памяти 8))

а никто не поинтересовался КАК они реализованы в линуксе??? может напомнить про рутовый эксплойт vmsplice??? и кажись он не первый???

я так склонен обходиться без аналогов ZERO_COPY, но и без эксплойтов тоже. сплошные рутовые эксплойты блин.

уж извините за тон.

> А если привести список идей, которые в Minix3 _не реализованы_ (типа страничной виртуальной памяти 8)) - становится просто непонятно, о чем вообще речь в проекте Minix3.

Скажем, у нас лабы по проектированию ОС - загрузчик на ассемблере и переключение задач на нем же. А так можно давать лабу "добавление страничной виртуальной памяти в Minix3" (или что там тебе угодно). Сделать ее до конца видимо невозможно (оно и к лучшему, следующему году списывать будет нечего ;). Но хоть на асме столько писать не придется.

Исходить надо из того, что Т. - профессор/писатель.

>К логопеду,

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

>он Вам разъяснит, почему правильно писать не

Цепляетесь за форму, Уважаемый? У Вас еще небось и compiz стоит. Явно тяга к вычурной форме и фанатичное поклонение материальным предметам, доходящее до мании. Вам не к логопеду, Вам к другому специалисту.

И все-таки, почему именно minix3, а не GNU/Hurd?

Лично я больше верю в экзоядра... TitanOS?

Интересно. Меня только смутили две фразы:

1) "...1MB is a threshold allocation size beyond which jemalloc begins to involve the kernel in memory management" - ядро по определению делает эту работу, поскольку любой malloc должен либо периодически звать либо brk, либо mmap. Подозреваю, что имеется ввиду "при каждом выделениии >= 1Mb jemalloc делает по крайней мере один системный вызов".

2) "It is unknown whether the glibc malloc can be tuned at runtime to provide better performance" - вообще-то если человек не знает, зачем нужна функция mallopt, ему не стоит заниматься сравнением mallloc() ов.

второй график показывает суть "теста" :) Когда на графике проигравшая сторона в одном варианте, а выйгравшую тюнят и показывают в трёх вариантах - всё понятно :)

А ваш glibc можно так затюнить?

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

вопрос снят. Размер чанка пропустил.

> Интересно одно, что Фря везде лучше линукса на синтетических тестах, а в жизни именно линукс уделывает фрю... Где правда, брат ?

Правда там, где ты берёшь прогу, заточенную под линукс, и пытаешься поставить на фрю. Затем, потерев ушибленное место, сносишь к чертям фрю и спокойно живёшь под ЛЮБЫМ линухом. :)

> Со временем миникс3 уделает линукс...

Не вижу в этом ничего невозможного. Я был бы рад, если глиняную Линукзиллу заменят чем-то более вразумительным. Да и POSIX на Minix3 соблюдается - считай, 90% кода можно спокойно переносить.

> Какие проблемы он отрицает (список плиз)

Все :) Если серьезно, я не читал ничего по Minix3 уже с год, так что не могу дать подробный Minix3-специфичный отчет. Проблем с микроядрами вообще две (осноные): скорость (ибо обращения к системным службам стоят дорого из-за переключения контекстов и передачи сообщений) и переусложненный (и тоже медленный) интерфейс между системными компонентами вроде ядра, пейджера и ФС. А Таненненбаум говорит, что этих проблем нет вообще, что современное железо уже достаточно быстро, _но_ сравнения приводит с Minix2 (типа @Minix3 всего на 10% медленнее Minix3, поэтому все заявления о медленности микроядер неверны". И это при том, что в Minix3 еще нет виртуалной памяти, на которой предыдущие поколения микроядер отгребали проблемы.

> Мне так кажется что обращение к порту как сис.вызов можно вполне терпеть, и это не тормознет сильно.

*shrug* Ну работать оно будет, доказано. А сколько производительности ты потеряешь - Танненбаум не говорит, его измерения производительности сформулированы так, что накладные расходы в них не фигурируют. Но, скажем, QNX по слухам обладает довольно медленным TCP-стеком.

> Обмен с дисками может идти через дма

Поправьте меня кто-нить, если я ошибаюсь, но в Minix3 _нет_ DMA 8)

> Я думаю тормоза от сис.вызова вполне компенсируют надежность -- можно пускать чужие пропраетарные и/или падучие дрова, и не боятся.

Скажу как ветеран драйверопейсания - драйвер может завесить систему даже через системные вызовы обращения к портам :D А уж через DMA на современных архитектурах - лехко. Когда IOMMU будут на каждом компе - тогда может быть.

> пока линуксу везет, ибо его драйверы неожиданно стабильны.

К везению это не имеет отношения - эторезультат работы. Так что это не прекратится внезапно.

> если случится мощный наплыв железа и падуче-кривые драйверы под линукс? Под миниксом этои драйверы кое-как будут хромать

Во-первых, неизвестно как они будут хромать по Minix3 - глючащий драйвер диска сделает систему неюзабельной. Во-вторых, usermode-драйверы были сделаны и для Линукса, так что при нужде их воскресят (ИМХО, usermode-драйверы - это самый разумный компромисс между микроядром и монолитом).

> кому нужно много, есть SYS_VDEVIO -- process vectior with multiple (port IO) requests -- пусть объединяют реквесты,

Не уверен, что это нормальный выход.

> все равно в реальной жизни больше 1000 сисколлов в секунду не нужно

"640К хватит для всех" (c)

>> И это будет не Minix3 - потому что он родился мертвым

> s/мертвым/учебным/

А вот извините-подвиньтесь. Учебными были Minix1 и Minix2, а речь о Minix3.

> А так можно давать лабу "добавление страничной виртуальной памяти в Minix3"

Ну так за чем дело стало?

> Исходить надо из того, что Т. - профессор/писатель.

Minix3 позиционируется как ОС для практических применений.

ничего плохого для ни linux, ни для freebsd не вижу... и linux, и bsd нужна здоровая конкуренция, иначе они оба загнутся...

зы. iZEN просто на java пишет и под bsd сидит, это такая бешеная смесь получается... и у него все посты провокационные, вот почему не знаю...

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

> Зря, теперь оно еще быстрее течь будет :-/

Зря, но не в смысле утечек, у меня, к примеру, FFox с ним просто глючил. А в плане антифрага памяти, на мой взгляд, до сих пор самый оптимальный тот, что кто-то вытащил с OpenBSD.

hoard еще на 5 штатному аллокатору сливал

> Minix3 позиционируется как ОС для практических применений.

MINIX 3 *adds* the new goal of being usable as a serious system on resource-limited and embedded computers and for applications requiring high reliability

The current version of MINIX 3 (3.1.2) is a work in progress. It is nowhere near as mature as FreeBSD or Linux right now.

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

> У Вас еще небось и compiz стоит.

Что это такое и зачем оно нужно? Очередные бирюльки? Вы
некорректного обо мне мнения.


> Но, скажем, QNX по слухам обладает довольно медленным TCP-стеком.

QNX обладает двумя портированными TCP/IP-стеками NetBSD и одним Tiny TCP/IP-стеком.

---
С Уважением,

>Когда на графике проигравшая сторона в одном варианте, а выйгравшую тюнят и показывают в трёх вариантах - всё понятно :)

Ты хочешь сказать, что разработчики linux'а при проведении аналогичных тестов на сравнение скажем с windows или solaris кидаются тюнить windows и solaris в аналогичной ситуации?

> Ты хочешь сказать, что разработчики linux'а при проведении аналогичных тестов на сравнение скажем с windows или solaris кидаются тюнить windows и solaris в аналогичной ситуации?

Какие "разработчики линукса" ? Их много. Кто-то тюнит, кто-то нет. Те, кто тюнят - с переменным успехом, ибо "свою" систему знают лучше. Крис - БСДун, поэтому и результаты такие.

Разумеется, это не есть хорошо, по такой методологии только Get the Fucks можно получить. Правильный бенчмаркер должен обьективно одинаково стараться получить максимальный результат на всех сравниваемых системах и весь свой setup (конфиги и проч.) класть вместе с результатами. Поглядит какой-нибудь гуру и скажет: а если вот тут сделать sysctl sys.kern.megafeature = 1024, то скорость возрастет на 256%. И т.п.

>Хорошо. Может быть ты и прав. Подождем еще чуть-чуть =)

Есть ли смысл в микроядрах, если есть системы паравиртуализации?

Упала одна система - поднялась другая.

>Я лично согласен за это платить 10% от проца. И может даже 20%.

Запусти qemu, выдели свое устройство и хоть обзапускайся.

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

Эти бздуны только и способны что на тесты. На деле же их недосистемка тихо умирает в сторонке. Видимо за счёт этих быдлотестов бздунишки хотят свой самолюбие потешить.

nikolayd> Только почему они не написали, с какой либой линковали под фрей? -lthr или -pthread?

Потому, что по честному они не могут. Если по честному будет, линукс порвёт фрю.

ASM>

>> Писать под BSD -- помогать врагу.

>Пожалуйста, поситите беореактор.

Сам посети, быдло.

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

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

> И вот тогда за очень короткое время будут реализованы и страничная виртуальная память, и решены те "проблемы" микроядер.

Так называемая "страничная виртуальная память" нужна для эффективного свопа данных из оперативной памяти на медленное устройство хранения (жёстий диск) и обратно. Оперативная память подешевела, её объёмы на десктопах исчисляются парой гигабайт, свопирование практически не исользуется (о Windows Vista умолчу). Сейчас виртуальная память нужнее в контексте распределённых вычислений (кластеры), а именно в контексте "общей виртуальной памяти кластеров". Также, функциональный вопрос распределённых приложений решается на уровне самих приложений, высокоуровневыми механизмами — EJB, например.

Так что страничная организация "виртуальной" памяти под вопросом "А так ли она нужна, если подкачка не задействуется вовсе"?

>Так называемая "страничная виртуальная память" нужна для эффективного свопа данных из оперативной памяти на медленное устройство хранения (жёстий диск) и обратно.

Это только одно из возможных ее применений.

>А ваш glibc можно так затюнить?

"мотороллер не мой - я просто разместил объяву" (c) :))) в одном страром проекте помнится у меня сменили пару маллоков ;) http://www.scratchbox.org/documentation/general/tutorials/glibcenv.html может тестировавший товарищь все дебуги и трейсы повключал? ;)))

>Ты хочешь сказать

то что я хотел сказать - я сказал. Это касается любого подобного теста - сразу видно откуда ноги растут и чего автор добивается ;)