И много среди них живых?

GNU/Hurt

Тонко.

Они что, за полтора года сделали только это???

Велосипеды на семействе L4.

Хм. Ты хочешь сказать, что эти велосипеды _чрезвычайно_ распространены в реальных встроенных системах (не в тематических исследованиях)?

The MINIX project now uses git as its version-control system

minix использует торвальдсоподелие для разработки???

Весьма дотошно выполнял тесты в свое время. gcc 4.5.3 выигрывал по скорости выполнения скомпилированных программ у всех других четвертых версий gcc, clang и icc. Это что касается процессора atom. Как с другими не знаю. Вручную было перебрано огромное количество достаточно удачных комбинаций ключей. Прирост производительности порою заметен даже на глаз.

Вот ключи для gcc 4.5.3, которые мне пока не удалось перебить по производительности ни на одном другом компиляторе на платформе атома:

для програм

"-O3 -march=native -mtune=native -fomit-frame-pointer -pipe --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=256 -msahf -mcx16 -mmmx -msse -msse2 -msse3 -mssse3 -mfpmath=both -fexcess-precision=fast -fmerge-all-constants -fno-gcse -funroll-all-loops -g0 -Wno-all -fvect-cost-model -ftree-loop-linear --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216"

"-O3 -march=native -mtune=native -fomit-frame-pointer -pipe --param l1-cache-line-size=64 --param l1-cache-size=32 --param l2-cache-size=256 -msahf -mcx16 -fexcess-precision=fast -fmerge-all-constants -fno-gcse -funroll-all-loops -g0 -Wno-all -fvect-cost-model -ftree-loop-linear --param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216"

В gcc 4.6+ чуть более удачно реализованы sse оптимизации, но... регресс по другим оптимизационным ключам не дает возможности вырваться этим версиям вперед. clang же держится на уровне -O2 оптимизаций gcc. icc где-то сливает, а где-то на уровне gcc. Оптимизации с использованием автоматического распараллеливания программ не применялись в силу их эфемерности - где-то выигрыш в небольшие проценты, но где-то серьезный слив производительности скомпилированных приложений. При серьезном увеличении времени компиляции программ. Для каждого из компиляторов подбирались наиболее производительные комбинации ключей для оптимизации приложений на процессоре атом. Автоматическое профилирование (1 раз компилируем для профилирования, гоняем программу, потом компилируем с использованием накомпленной статистики) на gcc выдавало часто результат не лучший чем с ключом -O2 и никогда даже не прилижалось к ключу -O3. Хотя это может только я такой счастливчик.

P.S.

Сорри за здоровый офтоп.

Это мои сугубо личные изыскания. Выполнял персонально для себя. Частью результатов делился на Лоре, а частью на сайте calculate-linux. Лучших ключей оптимизации для атома еще не встречал.

"--param max-unroll-times=4 --param max-unrolled-insns=72 --param max-average-unrolled-insns=216" были подобраны исходя из того, чтобы собирались все используемые мною пакеты, но с минимальной потерей профита от дальнейшего разворота циклов. К примеру ядро не соберется, если несжатый образ будет, если не ошибаюсь по памяти, более 10 Мб, а если убрать проверку в исходниках и все же компильнуть его с приличным разворотом циклов, то оно стопорится при загрузке. Дальше с ним не разбирался.

Нет, Minux дерьмо! Когда рухнет Linux люди спрыгнут на Haiku & DragonFlyBSD...

+1.

Linux нужен лишь корпоративщикам на серверах, когда он рухнет под тяжестью мегафич, которые не нужны на десктопе (но придают дополнительных тормозов и сложностей в развитии и сопровождении) и никакой анестезиолог не сможет оживить этот труп заменой шедулера, то народ поймет, что для десктопа и серверов нужны разные операционки. К этому времени Haiku будет рулить на десктопе, а DragonFly на серверах (ну, а Android на смартфончиках и планшетиках). А Linux и сами знаете кто займут свое место в истории IT (занимая в сумме пресловутый 1%).

P.S. Haiku уже сейчас поддерживает Qt. В том числе и экспериментальную 5-ю ветку.

Minix - экспериментальный проект. Изолированность драйверов можно достигнуть и в Linux, такие разработки уже были (гуглить по «linux drivers in userspace» или «Gelato project»). А вот сделать в Minix операцию open, например, файла с жесткого диска без тучи переключений контекста (что приводит к тормозам), на существующем железе не судьба.

Изобилие свободных операционок - это хорошо или плохо? Я что-то не пойму.

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

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

Прирост производительности порою заметен даже на глаз.

Мсьё, да Вы знаток!!!

Haiku пока очень далеко до linux по производительности. Но признаюсь в свое время был поражен красотой и скоростью BeOS по сравнению с операционками того времени. На пентиум про BeOS грузился секунд за 7 и автоматом поддерживал до 8 процессоров (у меня была 2-процессорная версия материнки).

Ext2 support (contributed by Evgeniy Ivanov)

FUSE support (GSOC project by Evgeniy Ivanov)

Это, кстати, powerfox

А всего-то надо было с ЛОРа уйти.

Клево, так и сделаю.

Они опаздывают лет так на 20.

Вас не приглашали обсуждать мой ответ на заданный лично мне вопрос. Когда с мое повозитесь с компиляторами тогда посмотрим чего стоите лично Вы.

Вот прям-таки «чрезвычайно»? Назови что-нибудь, кроме QNX.

Ну вы даете - практически все RTOS, я кроме LynxOS не могу вспомнить хоть одну которая не на микроядре http://en.wikipedia.org/wiki/ThreadX http://en.wikipedia.org/wiki/Nucleus_RTOS http://en.wikipedia.org/wiki/MQX http://en.wikipedia.org/wiki/Integrity_(operating_system) http://en.wikipedia.org/wiki/ChorusOS

Самую главную чуть не забыл :) http://en.wikipedia.org/wiki/Vxworks

Вот прям-таки «чрезвычайно»? Назови что-нибудь, кроме QNX.

Ну вы даете - практически все RTOS, я кроме LynxOS не могу вспомнить хоть одну которая не на микроядре

Я спрашивал о _чрезвычайно распространенных_ во встроенных системах микроядерных ОС.

http://en.wikipedia.org/wiki/MQX

По-моеему, это еще одно ядро для микроконтроллеров, которое кто-то спутал с микроядром.

http://en.wikipedia.org/wiki/ChorusOS

Скупая слеза ностальгии сползла по небритой щеке...

«searches on the Internet beyond that site show no trace of actual activity around the ChorusOS/VirtualLogix C5 microkernel - the microkernel is actually not mentionned anywhere on Red Bend's site. The source repository on SourceForge also shows zero sign of activity since July 2007».

Nice reading, thx.

Да даже практически мертвый GNU/Hurt работает с бОльшим количеством софта.

Угу, только он Hurd.

И ещё для Кэнона 3010!

народ поймет, что для десктопа и серверов нужны разные операционки.

Степан Бальмеров, залогиньтесь уже.

Прелестно, просто прелестно.

Малчык, дэвочка — Франку Ромчуку какая разница?

Я спрашивал о _чрезвычайно распространенных_ во встроенных системах микроядерных ОС.

Я и привел примеры самых распространенных

По-моеему, это еще одно ядро для микроконтроллеров, которое кто-то спутал с микроядром.

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

Кэнон хорошая фирма, она везде свои продукты поддерживает

Отличная шутка.

Кажется кто-то путает аж 3 понятия. Микроядро, rtos и «ось» для микроконтроллеров. Это три большие разницы.

Кажется кто-то путает аж 3 понятия.

пля - еще один умник, прочитай сначала, подумай - потом пеши.

Linux нужен лишь корпоративщикам на серверах, когда он рухнет под тяжестью мегафич, которые не нужны на десктопе (но придают дополнительных тормозов и сложностей в развитии и сопровождении)

Ничто не мешает вырезать ненужное и оставить легкий и быстрый дистрибутив (что многие и делают).

К этому времени Haiku будет рулить на десктопе

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

Вам надо inferno:

Supported Architectures : Intel x86 (386 & higher); Intel XScale; IBM PowerPC; ARM StrongARM (ARM & Thumb); Sun SPARC

Clang is the default compiler (GCC is also supported)

Ядро линукса уже можно clang'ом собрать?

Можешь объяснить, для чего тебе так необходимы разделяемые библиотеки? Особенно в контексте предназначения minix.

Потоки еще ладно, и то без них вполне можно жить - сколько лет их не было в unix (причем сознательно не хотели добавлять). А питонисты и сейчас вполне обходятся.

А кого надо?

В первую очередь системных программистов. Потом грамотных прикладников. А под кутешниками подразумевались те, кто кричит «там нет кутэ, мы все умрем!».

Спасибо! А что-то я не вижу готовых исошников, чтобы погонять их на спарке. Или оно только поверх соляры умеет? Тогда это как-то не совсем ОС.

А вот интересно: можно ли запустить Minix в Javascript PC Emulator (http://bellard.org/jslinux/faq.html) ?

В теории никаких препятствий не вижу.

Если честно сам не знаю где качать, но оно действительно умеет натив, из википедии например:

Native ports include: x86, MIPS, ARM, PowerPC, SPARC.

Написано-то оно и на заборе. :)

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

Потоки еще ладно, и то без них вполне можно жить

Изобретать IPC/RPC вместо нормального общего адресного пространства - это очень эффективно, да. А современная Unix-like ОС все-таки должна реализовывать POSIX, в котором как раз потоки предусмотрены.

А питонисты и сейчас вполне обходятся.

API для потоков там есть, и его даже используют. Это так называемые green threads.

Можешь объяснить, для чего тебе так необходимы разделяемые библиотеки? Особенно в контексте предназначения minix.

Для этого нужно определиться с контекстом предназначения Minix. Если обсуждать в контексте десктопа, то представь, сколько занимали бы на диске статически собранные гномокеды (и соответственно столько же они жрали бы памяти). А из мест, где без разделяемых библиотек ну совсем никак - например, Python, Ruby, Lua и прочие, ведь без разделяемых библиотек у нас не останется пути делать C-расширения.

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

IPC/RPC вместо нормального общего адресного пространства

shared memory? При этом «нормальное общее адресное пространство» слишком часто приводит к замечательным неуловимым багам. Я понимаю, что надо руки выпрямлять и т. д., но по факту сложность растет, а надежность падает. Не случайно ведь многопоточность долго не хотели добавлять в POSIX - если не ошибаюсь, это одна из главных причин.

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

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

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

Я бы вообще предложил в юзерспейсе делать упор на управляемый код и скрипты. ИМХО, хорошо вписывается в концепцию сверхнадежной системы. А скорости от нее и так не ждут.

Так что пока те же Perl/Python, они там есть. Про расширения на C пока не знаю - не применял.

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

Ну, не стоит заглядывать _настолько_ далеко в будущее что линукса, что миникса. :)

Может и не шутка

хм..., вот: http://www.canon-europe.com/Support/Consumer_Products/products/printers/Laser...

появился, а пару дней назад не было.

Может и не шутка

Потоки в питоне, конечно, есть, но местные питонисты говорили, что из-за GIL лучше пользоваться многопроцессностью

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

Я спрашивал о _чрезвычайно распространенных_ во встроенных системах микроядерных ОС.

Я и привел примеры самых распространенных

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

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

Я не берусь говорить о загадочном «ком-то», но ты точно путаешь маленькие ядра с микроядрами. Речь об ротсуствии защиты памяти особенно умилительна в контексте разговора о Minix3. Ну и формальная верификация...

возможна его формальная верификация.

Понт засчитан. Реально распространенные микроядра (Mach, Neutrino) очень далеки от формальной верификации и не создавались для нее (и вряд ли она возможна для этих микроядер). Хотя, конечно, формальная верификация рулит.

Насколько чрезвычайно не могу сказать, но с реальными встроенными системами на этой базе работать приходилось. Так что «тематические исследования» немного не в тему.

Смотри ответ выше tailgunner'у. Живые есть точно.

модель обработки, основанную на передаче сообщений

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

Я так понимаю, к этому вообще сейчас стремятся новые языки и фреймворки

А Хоар говорил еще в 1985-м!!11

Но ведь на процессах это реализуется не хуже, чем на потоках

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

Допилили бы лучше NetBSD

Насчет разделяемых библиотек - как я понимаю, minix в первую очередь для embedded

o_O в продаже уже есть платформы под миникс?

sam логичней vim'a

а отцы основатели демонстративно считают что раскаска синтаксиса ересь (они на телетайпах же ed юзали) так что Томсон по стилю командует а не редактирует.