LINUX.ORG.RU

Отчёт о развитии GNU/HURD за 2010 год

 , , ,


0

1

Hurd всё ещё не подходит для ежедневного использования, но тем не менее продолжает совершенствоваться, и 2010 год не стал исключением. Давайте посмотрим на прогресс в развитии за прошедший год.

  • Добавлена поддержка Xen domU для ядра GNU Mach, которая делает возможным запуск GNU/Hurd как гостевой системы Xen.
  • Зенг Да (Zheng Da) разработал новый стек драйверов, который работает на Dresden L4 (Fiasco) и позволяет запускать современные драйвера из Linux как пользовательские процессы. Множество сетевых карт теперь работают.
  • Как и в прошлом году, разработчики участвовали в Google Summer of Code 2010.
  • Джереми Коэниг (Jérémie Koenig) портировал современную версию инстяллятора Debian.
  • Эмилио Позуэло Монфорт (Emilio Pozuelo Monfort) нашёл специфичные проблемы в совместимости, которые были обнаружены благодаря тестовым комплектам в некоторых программах. Так как ошибки касались базовой системы, то улучшилась общая стабильность продукта.
  • Джереми Коэниг создал новую реализацию транслятора procfs. Инструменты типа top теперь могут быть использованы без проблем.
  • Вдобавок, общая стабильность, совместимость и переносимость были улучшены, над этим работают несколько людей. Так, для Debian GNU/Hurd доступно около 68% всех пакетов Debian.
  • Вместе с другими разработчиками Майкл Уокер (Michael Walker) начал создавать дистрибутив Arch Hurd. В очень небольшой срок они получили работающую систему как для установки, так и в виде Live CD.

>>> Подробности

за развитием слежу с интересном, но зачем в XXI веке нужен HURD/Mach не представляю

jtootf ★★★★★ ()
Ответ на: комментарий от geekless

Давненько я не видел столь смелого и жизнеутверждающего деления на 0.

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

jtootf ★★★★★ ()
Ответ на: комментарий от geekless

Особенно QNX вся такая костыльная, ну-ну.

костыльный там слой POSIX-совместимости вместе со всем портированным софтом (одни иксы чего стоят), всё остальное - образец элегантной архитектуры

jtootf ★★★★★ ()
Ответ на: комментарий от vold

>Если за него возьмётся кто-нибудь большой, например Гугель, то допилят.

Надо только придумать Брину экономическое обоснование. Qui prodest? - как говорится. По-русски - нафига? («Меня как бухгалтера интересует, во что это выльется?» (с))

slackwarrior ★★★★★ ()

>Hurd всё ещё не подходит для ежедневного использования, но тем не менее продолжает совершенствоваться
Жив, курилка.
Кстати, любопытно — под какой он версией GPL?

Nanodesu ()
Ответ на: комментарий от anonymous

А я то всё думаю, почему на таких же железках у apple ОС показывает куда большую производительность...

former_hokum ()
Ответ на: комментарий от jtootf

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

Еще один непониматель того, что кругло-вакуумного РВ не бывает в природе?

geekless ★★ ()
Ответ на: комментарий от Quasar

Вот не надо тут QNX приводить в пример

Это специфичная ОС для специфичных целей.

Напомню, в ответ на что именно это было сказано:

У микроядра в теории всё красиво. Но на практике - костыль на костыле сидит и костылём погоняет.

Особенно QNX вся такая костыльная, ну-ну.

Ты возьмешься доказывать, что микроядро пригодно только для «специфичных целей» и костыльно на десктопе? Если нет — то что ты вообще хотел сказать?

geekless ★★ ()
Ответ на: комментарий от Umberto

Как бе больше половины всех дистрибутивов на нём.такие дела.

Ubuntu1104 ()

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

Marisa ()

фигасе анимаешников развелось

anonymous ()
Ответ на: комментарий от DNA_Seq

>>Особенно QNX вся такая костыльная, ну-ну.

Она во первых тормозная


Дискетка с демой на iDX2-66 не тормозила

madcore ★★★★★ ()
Ответ на: комментарий от DNA_Seq

Представь очередь к ЛОРу. Традиционный вариант - пациент сидит пока сам не захочет уйти. Это кооперативная многозадачность. Сейчас таких систем не осталось, это виндус 3.1, макось до 9й включительно и тд. Что будет если там застрянет глухая бабушка всем понятно. Чуть более продвинутый вариант - если пациент сидит более часа то он выходит из кабинета и опять садится в общую очередь. Это вытесняющая многозадачность. Практически все современные ОС.

Вот до этого места аналогии ещё неплохие.

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

han ()
Ответ на: комментарий от geekless

>Ты возьмешься доказывать, что микроядро пригодно только для «специфичных целей» и костыльно на десктопе?

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от han

Тебе надеюсь не стоит напоминать что процедурный кабинет настроен строго на одну операцию? ;)

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от han

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

Это в очень специфичных ОСРВ, в более простых та же очередь но есть один или несколько особых пациентов, которые ждут до определенного момента, потом смотрят на часы - все, времени ждать нет - у меня сейчас аудиенция у Медведева, он втсает заходит в кабинет, там может лежать простой пациент которому уже вскрыли грудную клетку - пофигу, перекладывают его в соседний кабинет чтобы не орал сильно и начинают делать особому пациенту маникюр.

anonymous ()
Ответ на: комментарий от DNA_Seq

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

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

han ()
Ответ на: комментарий от DNA_Seq

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

L4 - исключение, оно подходит для всего, это самое быстрое микроядро, производительность его выше чем у QNX, у него очень быстрое и гибкое IPC и очень малое время переключения контекста. На OKL4 (Pistachio) на ARM есть очень оригинальное решение по быстрому переключению контекста - все потоки там могут работать в одном адресном пространстве а защита памяти основана на доменах (это обеспечивается аппаратно MMU) в результате не нужны дилтельные операции по очистке и инвалидации кешей, но область ограничивается встраиваемыми системами - так как виртуальное адресное пространство общее и ограничено 4 GB на всех, например скорость переключения контекста в такой связке на паравиртуализованном Linux в результате увеличиавется в десятки раз.

anonymous ()
Ответ на: комментарий от anonymous

>L4 - исключение, оно подходит для всего

но используется только в качестве прослойки для гибридного ядра. Странно, да?

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от han

>А ели всё это не свести к примитивам и заранее не просчитать каждый шаг - то никакого ЖРВ и не будет.

Так у микроядер та же фигня, не случайно микроядро и реалтайм братья навек.

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

>но используется только в качестве прослойки для гибридного ядра. Странно, да?

Ничего странного - просто шустрые ребята быстро сообразили что можно срубить капусты по-быстрому, так появилась OKL4 c мобильной виртуализацией. ОС на базе L4 есть, но ими занимаются университеты (см. например TUDOS, откуда хурдовцы позаимствовали DDE), как будут готовы, найдутся другие шустрые ребята и так далее, пока L4 не схавает этот мир :)

anonymous ()
Ответ на: комментарий от anonymous

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от DNA_Seq

>А может все было наоборот?

Что наоборот ? L4 изначально было закрытым и написано на ассемблере для x86, уже после смерти отца-основателя в 2001 г. появились свободные реализации L4 api на C/C++ для различных архитектур.

anonymous ()
Ответ на: комментарий от DNA_Seq

> Веселье начинается когда пытаются писать для микроядер драйвера.

Ну расскажи про это веселье. Я тебя внимательно слушаю. Надеюсь, ты будешь так же отжигать, как вчера про РВ.

geekless ★★ ()
Ответ на: комментарий от anonymous

>Что наоборот ?

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

DNA_Seq ★★☆☆☆ ()
Ответ на: комментарий от han

> А ели всё это не свести к примитивам и заранее не просчитать каждый шаг - то никакого ЖРВ и не будет. В жесткой РТ системе, РТ реакция тоже на ограниченный круг событий гарантируется, как и виды этой реакции. Неужто всерьёз есть мнение, что на РТ-системе даже аська в РТ работать будет?

Бесполезно — до него не доходит. Пациент глух к голосу разума.

geekless ★★ ()
Ответ на: комментарий от DNA_Seq

>А ели всё это не свести к примитивам и заранее не просчитать каждый шаг - то никакого ЖРВ и не будет.

Так у микроядер та же фигня

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

geekless ★★ ()
Ответ на: комментарий от DNA_Seq

>Читать учись.

Дурачек - я то хоть умею читать и интересуюсь из первоисточников, а у тебя одни фантазии.

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


L4 и виртуализация очень тесно связаны изначально, Лидтке раньше работал в IBM - у пионеров в этой области, а ядро писал для виртуальной среды своего ЯП.

anonymous ()
Ответ на: комментарий от anonymous

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

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

и начинают делать особому пациенту маникюр

А в этой части либо маникюр будет в режиме описанном для процедурного кабинета (с принудительным съёмом штанов), либо это будет система без ЖРВ, т.к. нет гарантии что клиент за фиксированное время соизволит пройти всю процедуру.

han ()
Ответ на: комментарий от geekless

Еще один непониматель того, что кругло-вакуумного РВ не бывает в природе?

по существу есть чего сказать?

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

> реальное время, производительность и отзывчивость - выбрать можно одно из трёх

И получится реальное время без отзывчивости? O_o

tailgunner ★★★★★ ()
Ответ на: комментарий от DNA_Seq

Веселье начинается когда пытаются писать для микроядер драйвера.

в чём заключается веселье? драйвер (менеджер ресурсов) в том же QNX - это обычное приложение пользовательского уровня, реализующее некоторый интерфейс (read, write, ioctl)

jtootf ★★★★★ ()
Ответ на: комментарий от tailgunner

И получится реальное время без отзывчивости? O_o

с точки зрения пользователя - да. максимальную отзывчивость тебе предоставит complete fair scheduler, который будет одинаково хорошо выделять время любым приложениям; планировщик реального времени - completely unfair, гарантии ты получаешь только для высокоприоритетных потоков

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

> по существу есть чего сказать?

По существу всё уже сказано на предыдущей страницы.

geekless ★★ ()
Ответ на: комментарий от jtootf

> с точки зрения пользователя - да.

Дай непротиворечивое определение «отзывчивости с точки зрения пользователя». Иначе это разговор ни о чем.

максимальную отзывчивость тебе предоставит complete fair scheduler, который будет одинаково хорошо выделять время любым приложениям; планировщик реального времени - completely unfair, гарантии ты получаешь только для высокоприоритетных потоков

А теперь представь, что CFS сам работает как низкоприоритетная СРВ-задача поверх реалтаймового планировщика и разорви себе шаблон.

geekless ★★ ()
Ответ на: комментарий от geekless

По существу всё уже сказано на предыдущей страницы.

у меня 1000 сообщений на странице, и она ещё не закончилась; хочешь делать отсылки - делай их в абсолютных значениях

Дай непротиворечивое определение «отзывчивости с точки зрения пользователя». Иначе это разговор ни о чем.

величина, обратная к суммарной latency при обращении к пользовательским приложениям

представь, что CFS сам работает как низкоприоритетная СРВ-задача поверх реалтаймового планировщика и разорви себе шаблон

не рвётся. ещё раз - по существу тебе есть что сказать, или ты чисто понты покидать пришёл?

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

ещё раз - по существу тебе есть что сказать, или ты чисто понты покидать пришёл?

Еще раз — по существу тебе было что сказать, когда ты стал выражать поддержку вот этому, или ты сюда потроллить заглянул?

величина, обратная к суммарной latency при обращении к пользовательским приложениям

И внезапно с таким определением перед нами оказывается типичная МРВ задача. Грубо говоря: если пользователь печает текст или ждёт окончания применения фильтра в гимпе, можно забить на http-сервер, самбу и crond, и они идут курить бамбук, как только начинают мешать отзывчивости. CFS же в такой постановке вопроса оказывается совсем не при делах, т.к. не гарантирует минимальную отзывчивость вообще, а гарантирует только «справедливое» разделение процессорного времени в соответствии с настройками групп планирования. Т.е. он как раз наоборот, гарантирует, что http-сервер, самба и кронд НЕ идут курить бамбук.

Тут либо одно из двух. Либо чините определение отзывчивости, либо разберитесь уже, чем является и чем не является fair scheduling.

geekless ★★ ()
Ответ на: комментарий от geekless

если пользователь печает текст или ждёт окончания применения фильтра в гимпе, можно забить на http-сервер, самбу и crond, и они идут курить бамбук, как только начинают мешать отзывчивости

только в том случае, если их приоритет ниже, чем у текстового редактора и гимпа. гарантии (отсутствие длительного вытеснения ядром, отсутствие вытеснения низкоприоритетным процессом) выдаются только высокоприоритетным процессам - а тот же HMI (текстовый редактор, гимп) не имеет смысла делать таковыми

выражать поддержку вот этому

меня интересует только техническая сторона; свои разборки оставьте, пожалуйста, при себе

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

>> И получится реальное время без отзывчивости? O_o

с точки зрения пользователя - да. максимальную отзывчивость тебе предоставит complete fair scheduler

Ты смешал всё в кучу.

tailgunner ★★★★★ ()
Ответ на: комментарий от tailgunner

Ты смешал всё в кучу.

я по-прежнему открыт для конструктивного диалога

jtootf ★★★★★ ()
Ответ на: комментарий от jtootf

> меня интересует только техническая сторона; свои разборки оставьте, пожалуйста, при себе

Вот по технической стороне и выскажитесь. DNA_Seq тут в достаточной мере изложил своё видение РВ-систем, чтобы можно было делать выводы.

только в том случае, если их приоритет ниже, чем у текстового редактора и гимпа. гарантии (отсутствие длительного вытеснения ядром, отсутствие вытеснения низкоприоритетным процессом) выдаются только высокоприоритетным процессам - а тот же HMI (текстовый редактор, гимп) не имеет смысла делать таковыми

Т.е. вы предпочтете пропатчить своё определение отзывчивости? Ибо написанное явно противоречит критерию «суммарной latency при обращении к пользовательским приложениям».

И еще. Типичная задача проигрывания музыки на десктопе — по свой сути требует гарантий на доступ к диску и CPU. Не «гарантий» в стиле «я тебе дам какую-нибудь долю IO каждую секунду, и ты даже будешь нормально работать большую часть времени», а вполне конкретных. Торрент может подождать. Проигрыватель — не может. Это к вопросу о нужности мягкого реального времени на десктопе и тормозах, ага.

geekless ★★ ()
Вы не можете добавлять комментарии в эту тему. Тема перемещена в архив.