Представлен (http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hur...) релиз Debian GNU/Hurd 2013, редакции дистрибутива Debian 7.0 "Wheezy", сочетающей программное окружение Debian c ядром GNU/Hurd (http://www.gnu.org/software/hurd/). GNU Hurd выступает в роли замены ядра Unix, оформленной в виде набора серверов, работающих поверх микроядра GNU Mach и реализующих различные системные сервисы, такие как файловые системы, сетевой стек, система управления доступом к файлам. Микроядро GNU Mach предоставляет IPC-механизм для организации взаимодействия, используемый для организации взаимодействия компонентов GNU Hurd и построения распределённой мультисерверной архитектуры.
После Debian GNU/KFreeBSD сборка Debian GNU/Hurd является второй платформой Debian, созданной на базе ядра, отличного от Linux. Платформа GNU/Hurd не вошла в число официально поддерживаемых архитектур Debian 7, поэтому релиз Debian GNU/Hurd 2013 выпущен по инициативе команды разработчиков данного проекта и является неофициальным выпуском Debian.Готовые сборки (http://ftp.debian-ports.org/debian-cd/hurd-i386/current/), снабжённые специально созданным графическим инсталлятором, и пакеты в настоящее время доступны только для архитектуры i386. Подготовлены как установочные образы NETINST, CD и DVD, так и предустановленный системный образ для запуска гостевых систем. В репозитории доступно более 10 тысяч пакетов, что составляет примерно 75% от общего размера архива Debian (для сравнения в Debian GNU/kFreeBSD число работающих пакетов составляет примерно 90%).
Для того, чтобы опробовать новую систему в виртуальном окружении KVM или VirtualBox можно использовать следующие команды:<font color="#461b7e">
wget http://ftp.debian-ports.org/debian-cd/hurd-i386/current/debi...
kvm -no-kvm-irqchip -drive file=debian-hurd*.img,cache=writeback -m 1G
или
VBoxManage convertfromraw debian-hurd.img debian-hurd.vdi --format vdi<font color="#461b7e">
URL: http://www.gnu.org/software/hurd/news/2013-05-debian_gnu_hur...
Новость: http://www.opennet.me/opennews/art.shtml?num=36990
Надо полагать, на современном железе не взлетит? Где-нибудь HCL водится?
> пакеты в настоящее время доступны только для архитектуры i386Как замена linux, в котором выпилили поддержку i386
>> пакеты в настоящее время доступны только для архитектуры i386
> Как замена linux, в котором выпилили поддержкуВ линуксах, в наиболее используемых дистрибутивах давно уже i386 не поддерживается!
А в тех дистрах в которых есть поддержка, значит кому-то это надо.
>> пакеты в настоящее время доступны только для архитектуры i386
> Как замена linux, в котором выпилили поддержку i386феноменальная замена!
ЮСБ нет, АМД-НВИДИА - нет.
2д-3д ускорения в далеких планах.
про остальное железо только мечтать...
Можно сделать взломоустойчивый сервер. В том плане, что никто не станет писать эксплойты под это дело.
> Можно сделать взломоустойчивый сервер. В том плане, что никто не станет писать
> эксплойты под это дело.Только программы работать на нем будут через раз. А количество феерических ошибок из-за не полного соответствия Linux может просто зашкаливать. Или приложения уже начали официально поддерживать Hrud (наличие тест сервера с нужной ОС и ядром)?
PS где то между "не нужно" для корпорация и "пусть развлекаются" для тех, кто ее пилит.
;-)
> Или приложения уже
> начали официально поддерживать HrudВот тут у вас ошибочка. Приложения под ядро почти не пишут, разве что те же эксплойты. Тот набор пакетов, который сейчас идёт с Debian/Hurd, уже наверняка включает в себя всё необходимое для построения файл/веб/прочее сервера. И большинство пакетов, скорее всего, собрано без каких-то особых hurd-специфичных патчей.
> уже навернякаНе наверняка, а именно так и есть )
> И большинство пакетов, скорее всего, собрано без каких-то особых hurd-специфичных патчей.
А это - увы.
Ознакомьтесь, что умеет Hurd из нынче актуального
http://packages.debian.org/experimental/hurd-i386/web/
http://packages.debian.org/experimental/hurd-i386/net/
Пардон, закрывающие слэши отразились.
packages.debian.org/experimental/hurd-i386/web/
packages.debian.org/experimental/hurd-i386/net/
Размер списка удивил. Но состав... Не вижу ни одного завалящего http-сервера.
Похоже на какой-то глюк, а вообще - вот он, как раз завалящий
http://packages.debian.org/experimental/hurd-i386/apache2/fi...
>Похоже на какой-то глюкне там просто смотрите, надо packages.debian.org/experimental/httpd/
> Можно сделать взломоустойчивый сервер. В том плане, что никто не станет писать
> эксплойты под это дело.- А давайте его разыграем и вместо лимонада ему в стакан водки нальем!
- А давайте лучше меня так разыграем!
Уже есть OpenBSD. Который более взломоустойчивый сервер, by design.
> Который более взломоустойчивый серверИ чем же конкретно ты намерЯл это? А Linux он, конечно, менее взломоустойчивый, да? )
> by design
Как раз в этом самом by design-то имеются кой-какие сомнения... Если, конечно, они не переписали втихоря ядро.
> И чем же конкретно ты намерЯл это?В том, что в отличие от Hurd он практичен, он реален и он регулярно светится в нмапах известных ресурсов. А его особенности -
> А Linux он, конечно, менее взломоустойчивый, да? )Linux - это фруктовый микс. Как в "двух до пяти" - "я понял, рай это компот". Те же защиты от популярного переполнения стека где-то собираются, где-то - нет, где-то дистрибутивы используют одни фичи, где-то - другие. Теоретически, можно собрать и безопасный, но практически у конкретного пользователя на это времени не хватит.
> Как раз в этом самом by design-то имеются кой-какие сомнения...У таких, как вы, вечно сомнения. Но это только от общего непонимания и неумения смотреть в нужном направлении. Вас слушать - себя не уважать.
> И чем же конкретно ты намерЯл это?
>> В том, что в отличие от Hurd он практичен, он реален и он регулярно светится в нмапах известных ресурсов.Да ладно?! оО
> Теоретически, можно собрать и безопасный, но практически у конкретного пользователя на это времени не хватит.
У какого ещё конкретного пользователя (мои тапочки уже похатывают из-под дивана)? Ты область применения там часом за утренней опохмелкой не попутал, свидетель интерпрайза?
> Вас слушать - себя не уважать.
Ну конечно, как слушать - так сразу не уважать, а как отвечать - так эт пожалуйста, все пальчики до дланей с удовольствием протрёшь )
> А его особенности -И какие там особенности для защиты от взлома? Чур, на неуловимого Джо не кивать.
> - другие. Теоретически, можно собрать и безопасный, но практически у конкретного
> пользователя на это времени не хватит.Поэтому проще всего просто распилить относительно мощный хост виртуализатором на отдельные виртуалки и ограничить последствия от взлома некоего сервиса сугубо этим сервисом. Сделав примерно то что микроядерщики и хотели, только уже существующими и хорошо работающими средствами. Рутование виртуалки при этом мало кому и что даст, все-равно там ничего ценного нет. Собственно, это одно из применений виртуализации: изоляция почти как если бы это были отдельные железные машины, без нужды платить за эти самые отдельные железные машины. Реально конечно это чуть похуже - в гипервизоре могут баги найтись, но это в целом существенно повышает требования к атаке, дыры в гипервизорах - штука довольно редкая.
>> Как раз в этом самом by design-то имеются кой-какие сомнения...
> У таких, как вы, вечно сомнения. Но это только от общего непониманияЕсли понимание все-таки включить, опенбзда - обычная операционка. Самый обычный такой монолит. Тезисы о том что там более качественный код требуют как минимум внятное большое исследование качества этого кода, доказывающее этот тезис. А без этого - это маркетинговый буллшит или неуловимый Джо, в зависимости от (не)сознательности вашего очковтирательства.
> проще всего просто распилить относительно мощный хост виртуализатором на
> отдельные виртуалки и ограничить последствия от взлома некоего сервиса сугубо
> этим сервисом.А если мой сервер и есть виртуалный на железном сервере хостера?! Меня, по большому счёту, не волнует, какими средствами мне хостер организовал виртуалку, а вот чтобы мой сервер жил и не падал - меня очень даже волнует. Виртуализация в данном случае только ускоряет перезагрузку моего сервера в случае падения моего же ядра.
> дыры в гипервизорах - штука довольно редкая.
Гипервизор, например в Linux'е, разве не имеет те же проблемы, что и обычное ядро, если обнаруживается уязвимость, допустим, в iptables? Или SSH... его тоже на гипервизорной машине пользуют, а в SSH, пусть и редко, но дырки тоже находят.
... на что-нибудь менее монолитное.
> В том плане, что никто не станет писать эксплойты под это дело.Боевые технологии неуловимого Джо.
А на 80386 DX/SX USB вообще были? А видео там на ISAшных карточках, в лучшем случае, VLB. Так что никакого аппаратного 2D-3D там в помине не было.
USB появился в 1996'ом, во времена первых пней.
> феноменальная замена!
> ЮСБ нет, АМД-НВИДИА - нет.
> 2д-3д ускорения в далеких планах.
> про остальное железо только мечтать...BSD какое-то, прямо.
Тоже самое писали про linux 20 лет назад.
Тока Linux за 20 лет ускакал довольно далеко. А Hurd, практически его ровесник, "и ныне там".
> Тоже самое писали про linux 20 лет назад.Между прочим, когда Торвальдс стал писать Linux, Hurd уже существовал. А то что его написание потребовало намного больше времени, а результат намного хуже - проекту явно не в плюс, вам так не кажется?
Вообще, у Торвальдса как руководителя проекта есть могучий плюс: он не страдает концептодр@черством, желанием максимально красиво все отполировать и прочая. Он желает чтобы это работало и работало хорошо. И это приносит свои результаты: в отличие от кучи полунаколенных поделок с высокими концепциями, пингвином уже даже пользоваться для решения своих задач можно. И оно даже работать будет. Не на сферическом железе в вакууме и какой-то там виртуалке, а здесь и сейчас, на вот этом вот оборудовании, которое выпускается по состоянию "на данный момент времени".
> Как замена linux, в котором выпилили поддержку i386В линуксе выпилили процессор 80386 а не архитектуру 386
> Как замена linux, в котором выпилили поддержку i386Уточним, 80386 доисторического, которые нынче остались только у коллекционеров антиквариата и на полочках музеев :)
ну что-же... будем посмотреть 8) а то совсем от них ни слуху-духу :)
Оно ipv6 умеет?
Да.
Осталось дело за малым - написать драйвера для большинства современных устройств. В линуксе это, кстати, половина кода.
> Осталось дело за малым - написать драйвера для большинства современных устройств. В
> линуксе это, кстати, половина кода.А набрать отзывы от end-users и пофиксать проявившиеся проблемы - это 90% работы.
> Осталось дело за малым - написать драйвера для большинства современных устройств. В
> линуксе это, кстати, половина кода.Если в первую очередь сделают полноценную поддержку в гостевых системах для виртуального оборудования (Xen, KVM, VirtualBox и т.п.), то это даст хороший толчок в развитии проекта, т.к. можно будет особо требовательные сервисы начинать переводить на HURD.
> линуксе это, кстати, половина кода.Это уже более половины кода и основная порция изменений - именно об этом.
А без этого только и останется что запускать систему на виртуалочке. Все-равно на реальном оборудовании без этого не будет работать или будет работать так, что лучше бы совсем не работало - одно расстройство только.
>> линуксе это, кстати, половина кода.
> Это уже более половины кода и основная порция изменений - именно об
> этом.
> А без этого только и останется что запускать систему на виртуалочке. Все-равно
> на реальном оборудовании без этого не будет работать или будет работать
> так, что лучше бы совсем не работало - одно расстройство только.Подозреваю, что очень скоро в виртуалках будет жить львиная доля хостинга, ибо сплошные удобства. Поэтому, если Hurd начнёт наступление именно с виртуального фронта, то явно не прогадает.
> Подозреваю, что очень скоро в виртуалках будет жить львиная доля хостинга,Вот только виртуалочки крутятся на железном серваке :). И чтобы все это закрутилось - нужна операционка, которая будет работать с оборудованием сервера и предоставит драйвера оборудования. Без этого - "кина не будет". А если там уже стоит линь, логично на гуесты линь того же типа по дефолту и ставить, т.к. однотипное окружение админить проще чем разнотипное. Для внутренних нужд ынтыpпрайзов - особенно. На продажу - ну да, там ресурсы продают. Тем не менее, для нормальной работы с виртуализатором для ОС требуются кастомные акселерированные драйвера под конкретный гипервизор. Иначе работать будет так, что никому такое будет не нато. В лине то для линевых гипервизоров такие драйвера априори будут. А вот то что в hurd с его темпами развития все это сделают за разумное время - не факт.
Вообще, имхо, микроядра - в пролете. То что они собирались делать (тyпoй арбитраж ресурсов с повышенным уровнем изоляции) взяли на себя эти самые гипервизоры как раз. По поводу чего микроядрам осталось разве что отправиться вслед за летающими танками и такими же подводными лодками :). Т.е. как бы в принципе это возможные, но непрактичные в большинстве приименений конструкции, интересующие только тонких ценителей всяких извращений.> сплошные удобства. Поэтому, если Hurd начнёт наступление именно с виртуального фронта,
> то явно не прогадает.ReactOS уже вон начинал - в bochs его лет 15 назад показывали. Ну и где его победное шествие? На десктопах? Хостингах? Или хоть там где?
>Тем не менее, для нормальной работы с виртуализатором
> для ОС требуются кастомные акселерированные драйвера под конкретный гипервизор.
> Иначе работать будет так, что никому такое будет не нато. В лине
> то для линевых гипервизоров такие драйвера априори будут. А вот то
> что в hurd с его темпами развития все это сделают за
> разумное время - не факт.Ну вот это как раз самое интересное - проверить теорию на практике. Погодим чутка, может и получится.
>> сплошные удобства. Поэтому, если Hurd начнёт наступление именно с виртуального
>> фронта, то явно не прогадает.
> ReactOS уже вон начинал - в bochs его лет 15 назад показывали.
> Ну и где его победное шествие? На десктопах? Хостингах? Или хоть
> там где?Видимо там же, где и WINE: в отдельно взятых аудиториях. ReactOS - тёмная лошадка со всё более увядающей ценностью, а вот Hurd'ом в Debian'е давно занимаются (пусть и не очень живенько, но не забросили же!). У Debian'а принципы и подходы к созданию дистрибутива весьма серьёзные. Видать не с проста Hurd'ом занимаются.
На настоящем (и новом) железе это можно запустить?
> На настоящем (и новом) железе это можно запустить?Походу только на виртуальном железе ))) Зато сколько понтов ;)))
каких понтов? ;)))
> каких понтов? ;)))Виртуальных.
> На настоящем (и новом) железе это можно запустить?А оно надо? Стаду Hurd самое место в виртуальных фермах - обеспечивать там 24 на 7.
> А оно надо? Стаду Hurd самое место в виртуальных фермах - обеспечивать там 24 на 7.Что именно он там будет обеспечивать 24x7, если не секрет?
>> А оно надо? Стаду Hurd самое место в виртуальных фермах - обеспечивать там 24 на 7.
> Что именно он там будет обеспечивать 24x7, если не секрет?Да хоть сервера для DNS, HTTP, FTP, SMTP, POP3, IMAP, да мониторинг типа Nagios - уже дело будет.
Или хоть особо надёжный syslogd для кучи хостов. Для мониторинга, например, надёжность важней супер-быстрого отклика при просмотре отчётов через web-интерфейс.
Тут главное - начать. Возросшая популярность добавит внимания к HURD и со стороны разработчиков, и со стороны мэнтейнеров.
Так глядишь и до ip-телефонии на базе HURD рукой подать будет.
> Да хоть сервера для DNS, HTTP, FTP, SMTP, POP3, IMAP, да мониторинг
> типа Nagios - уже дело будет.Это уже там обеспечивают другие. В режиме 24х7. Уже много лет.
>> Да хоть сервера для DNS, HTTP, FTP, SMTP, POP3, IMAP, да мониторинг
>> типа Nagios - уже дело будет.
> Это уже там обеспечивают другие. В режиме 24х7. Уже много лет."Этим" и пригодится "там" Hurd. Чтобы спать спокойней.
Теперь к этим другим ещё один добавился, дальше что? )
> Теперь к этим другим ещё один добавился, дальше что? )Пока у Debian "всего" три ядра:
Linux
FreeBSD
Hurd
Пока мучиться с выбором не придётся :-)А вообще, Debian конечно крут! У какого ещё дистрибутива ядро является заменяемым компонентом?! Тут правда нужно заметить, что управление сетевыми и другими настройками всё-таки желательно привести к унифицированному виду. Иначе это будут разные Дебианы.
>> А оно надо? Стаду Hurd самое место в виртуальных фермах - обеспечивать там 24 на 7.
> Что именно он там будет обеспечивать 24x7, если не секрет?Пока в самом деле очень не многое: имеется Апач с работающим ПыХом (правда, без единой нативной БД), полноценная Самба, полноценный ДНС-сервер, какой-никакой VPN-сервер, годные SOCKS- и IRC-сервер... Tor, кстати.
А шо же вы за Twisted-то молчите?
Судя по примерам команд: мир еще не готов к этому =)
Норм команды, мы, BSD-шники, всегда все руками делаем.
> Норм команды, мы, BSD-шники, всегда все руками делаем.BSDшники всё через rc.conf делают. Чтобы после перезагрузки работало. А Вы похоже чудаки.
А как ваши BSDшники изменения rc.conf на лету применяют? Или они изменяют настройки с помощью перезагрузки?
> А как ваши BSDшники изменения rc.conf на лету применяют? Или они изменяют
> настройки с помощью перезагрузки?Нормальный юниксвей. Не то, что всякие виндоподобные пингвиньи комбайны, которые все на лету меняют.
для сарказма - тупо, для "всерьёз" - тупо. что это было?
Настройки чего в rc.conf? Сети? Тогда /etc/rc.d/netif restart. PostgreSQL, Apache, Postfix и т.д.? /usr/local/etc/rc.d/pgsql[httpd|postfix] restart.
> А как ваши BSDшники изменения rc.conf на лету применяют? Или они изменяют настройки с помощью перезагрузки?[/usr/local]/etc/rc.d/something [start|stop|restart]
Оно лезет в rc.conf посмотреть запускаться или нет.Красивая абстракция: разделение декларативной и императивной частей. В одном месте пишем, что надо сделать, в другом - как этого достичь. Помимо красивости почти даже работает. У меня проблемы возникали только с порядком подъема сетевых интерфейсов (когда, например, туннель надо поднять после DHCP, а в промежутке прописать роуты) - вот тут красота концепции натыкается на уродливую правду жизни и приходится писать все в императивном стиле.
Дак да, пихаешь все по порядку в скрипт и копируешь его в /usr/local/etc/rc.d/ Более того, можно в $PREFIX/etc/rc.d/ сделать что-нить типа такого:$PREFIX/etc/rc.d/00dhcp.sh
$PREFIX/etc/rc.d/01routing.sh
$PREFIX/etc/rc.d/02tunnel.shи всё будет ништяк
Можно еще красивей - комментарии REQUIRE и PROVIDE в сами скрипты. rcorder их понимает и пускает в нужном порядке не требуя циферок в имени. Но красота концепции все равно потеряна: захоти я, например, поменять очередность DHCP и туннеля - надо лезть в сами скрипты вместо rc.conf. Печаль.
> Красивая абстракция: разделение декларативной и императивной частей. В одном месте пишем,
> что надо сделать, в другом - как этого достичь.Это, простите, системДЭ какое-то. Еще скажите, что все это и документировать надо.
В настоящем юниксе конфигурация и код должны быть неделимы. Хочешь поменять настройки - правь код. Хочешь понять, что это за хрень вообще и зачем - читай код.
>> Красивая абстракция: разделение декларативной и императивной частей.
> Это, простите, системДЭ какое-то. Еще скажите, что все это и документировать надо.Да все более-менее задокументировано man rc, man rcorder.
> В настоящем юниксе конфигурация и код должны быть неделимы. Хочешь поменять настройки - правь код. Хочешь понять, что это за хрень вообще и зачем - читай код.
Значит мне не нужен настоящий (он же, наверное, правильный?) юникс. Мне больше нравится такой, где "хочешь поменять настройки - правь настройки".
> BSDшники всё через rc.conf делают.А, так вот как это теперь называется...
В бсдях и то синтаксис не такой страшный вроде. Да и имена команд хоть на что-то намекают
> В бсдях и то синтаксис не такой страшный вроде. Да и имена команд хоть на что-то намекаютАга-ага.
route add -net 10.175.0.0/16 10.114.1.3
vs
ip route add 10.175.0.0/16 via 10.114.1.3Первая команда сразу намекает, где тут подсеть, а где шлюз. А из второй ничего не понятно.
> route add -net 10.175.0.0/16 10.114.1.3
> vs
> ip route add 10.175.0.0/16 via 10.114.1.3
> Первая команда сразу намекает,а мне маска намекает. короче обе конструкции предельно понятны. не понимаю в чём затык.
Блин, я все понимаю - микро-ядро... то-се... Но команды управления сетью зачем было менять?! Кому iproute2 мешал-то? Что-к-чему....
>iproute2Он, внезапно, является интерфейсом для сетевой подсистемы Linux. Вас ведь не смущает, что под FreeBSD его тоже нет?
> Вас ведь не смущает, что под FreeBSD его тоже нет?Смущает. Вообще-то я считаю это несколько неправильным;).... Но вы меня уговорили - остаюсь на Линуксе!))))
>>iproute2
> Он, внезапно, является интерфейсом для сетевой подсистемы Linux. Вас ведь не смущает,
> что под FreeBSD его тоже нет?Конечно смущает. Давно пора производителям разных ОС и "железяк" определиться со стандартными сетевыми утилитами.
Кстати, вот тут http://ru.wikipedia.org/wiki/Iproute2 написано:
>iproute2 предлагает унифицированный синтаксис для управления самыми разными
>аспектами сетевых интерфейсов. Этот синтаксис во многом проще и логичнее, чем
>синтаксис наследованных *nix утилит, и подобен синтаксису операционной системы
>Cisco IOS.Не знаю насколько это правда, но идея мне нравится.
> Блин, я все понимаю - микро-ядро... то-се... Но команды управления сетью зачем
> было менять?! Кому iproute2 мешал-то? Что-к-чему....iproute2 исключительно Linux-специфичная комманда, так что это вопрос к Linux-деятелям скорее, зачем им нужно было менять комманды управления сетью.
Ради удобства, очевидно же.
dladm/ipadm - наше всё
> зачем им нужно было менять комманды управления сетью.Затем что стандартных команд на все то что умеет пингвин - немножечко не хватало.
Что-то Hurd пилят, пилят и никак не допилят. Когда уже он будет готов к промышленному применению? С одной стороны - это будущее всех ОС(микро-ядро и сопутствующие плюшки), а с другой - до сих пор не ясно допилят ли его в обозримом будущем. Или его место займёт другое микро-ядерное подделие. Что-бы не писать все драйвера с нуля, разработчики могут реализовать необходимую прослойку для работы с драйверами Linux и NetBSD.
>С одной стороны - это будущее всех ОС(микро-ядро и сопутствующие плюшки)Если эту мантру очень долго повторять, то правдой данное утверждение не станет.
>>С одной стороны - это будущее всех ОС(микро-ядро и сопутствующие плюшки)
> Если эту мантру очень долго повторять, то правдой данное утверждение не станет.Значит это не мантра :-)
Genode
> GenodeМожно еще на выбор Minix, ReactOS, и прочие haiku. При том во всех из них проблема будет одинаковой: "драйверов нет, б-ть!"
Неожиданное решение команды Столлмана отказаться от разработки Emacs OS в пользу более легковесного решения на базе GNU/Hurd
> Неожиданное решение команды Столлмана отказаться от разработки Emacs OS в пользу более
> легковесного решения на базе GNU/HurdEmacs - это DE для ОС GNU/Hurd.
Прогресс есть, ещё недавно, нужно было для запуска хурда компилировать на Линуксе или NetBSD. Есть есть система с кучей пакетов, установщиком итд. Это не может не радовать. Другое дело преимущества, которые даёт Хурд большей частью пока не используются
Посмотрите в несколько ином ракурсе: есть свободная микроядерная, УЖЕ работающая система! Со свободной лицензией! С перспективой относительно несложного портирования ДАВНО отполированных пакетов! Разве это всё не вдохновляет?
Этих микроядерных как блох на собаке, уже лет хренадцать как. Только оно так по большому счету никому не надо в general purpose применениях. Космическая ракета - это круто и технологично. Но в соседний магазин на ней летать - ужасно непрактично. Вот они и остаются штучным товаром.
> Этих микроядерных как блох на собаке, уже лет хренадцать как.Minix, раз. Однако, стесняюсь даже спросить, какие у остальных-то блох лицензии?
> Только оно так по большому счету никому не надо в general purpose применениях.
GNU Hurd имеет двух именитых дистрибьюторов на настоящий момент: Debian и Arch. Выходит, кому-то всё же надо )
> Космическая ракета - это круто и технологично. Но в соседний магазин на ней летать - ужасно непрактично.
Если до ближайшего пара тысяч км, могут повылезти неожиданные бонусы. Хотя по большому счёту Вы правы...