Вышел GNU Hurd 0.6

ну так и пользуйся Plan 9 (если не помешает отсутствие софта для него, бгг. для этого и нужна POSIX-совместимость). меня устраивает ОС GNU, а совместимость с Великим Стандартом POSIX я считаю важнее всяких там «фич».

и которые позволяют обойтись без кучи костылей, которые в линуксе городят последние лет 10

POSIX не при чем, это все потому, что Linux - эмулятор терминала. посмотри ядро Minix или v7x86, красота да и только. там, правда, не полная POSIX-совместимость, особенно у последней, но можно легко допилить без утраты красивостей.

Сейчас софт часто пишется не posix-совместимый, а linux-совместимый.

я вижу завязанные на Linux программы довольно редко, и то это обычно или ненужно (проприетарщина, игры и пр.), или системщина (systemd, udev etc.)

нет там красоты. По-прежнему нужны костыли вида pusleaudio, если я хочу удаленно выводить звук, например. По-прежнему нужна возня с сокетами (а ведь сокет, в отличие от файла, например, фиг пробросишь на другой компьютер с помощью nfs, например), если я хочу программу-сервер для обработки данных, а значит для удаленных клиентов нужны уже TCP/UDP сокеты, а это дополнительная забота о безопасности - не всех же подряд пускать.

Так остальные программы чаще всего завязаны не на posix или linux, а на набор библиотек.

а библиотеки обычно завязаны на POSIX, все путем.

мелочи. я не готов пожертвовать совместимостью с POSIX ради этого.

То-то под hurd (он posix-совместимый) уже есть все необходимое! Ведь почти любая-любая библиотека ни разу не зависит именно от linux, а только от posix.

То-то под hurd (он posix-совместимый) уже есть все необходимое!

как бы да.

every second Debian package has been ported to the GNU/Hurd

https://www.debian.org/ports/hurd/

Ты случаем не в intel работаешь? Они вон в своем x86 до последнего тянули совместимость с костылями 286-го, типа контроллера клавиатуры и A20, дабы не терять совместимость с древним хламом. А POSIX еще более древний, чем 286.

Андроид нифига не posix, это не мешает ему быть успешным.

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

Одно вытекает из другого.

Они вон в своем x86 до последнего тянули совместимость с костылями 286-го, типа контроллера клавиатуры и A20, дабы не терять совместимость с древним хламом.

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

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

Этак ты второе пришествие проспишь.

но ведь таковая совместимость уже давно существует.
/me побежал в церковь причащаться

Я про перезагрузку проца через контроллер клавиатуры. В amd64 ее наконец выпилили в long mode.

Все такие костыли усложняют и удорожают проц. ARM как-то прекрасно без этого справляется, и популярность архитектуры все растет.

Все такие костыли усложняют и удорожают проц.

не проц, а контроллер клавиатуры. и вообще, лично мне эти три копейки не жалко.

Нет, в том числе проц. Почитай повнимательнее про сабж.

Ты не ответил, почему же ARM без этого дерьма мамонта все набирает и набирает популярность?

Нет, в том числе проц. Почитай повнимательнее про сабж.

я-то как раз про сабж читал не на лурке, а в менее желтом источнике. http://wiki.osdev.org/"8042"_PS/2_Controller
можешь сделать контроллер клавиатуры, не поддерживающий ту пару команд (ресет CPU и включение A20, правда последнее лучше не делать, если у тебя больше 16 МиБ памяти). программы использующие их отвалятся (и то не факт), не использующие - будут работать. процессору пофиг, его дело - послать байт в порт.

Ты не ответил, почему же ARM без этого дерьма мамонта все набирает и набирает популярность?

ага-ага, на декстопах. скоро x86 обгонит!

Как раз десктопы вовсю теряют популярность как концепция.

единственно нормальную

неэффективной устаревшей

Вообще, такие фразочки похожи на маркетинговый bullshit. Впрочем, как и «передовых идей».

эмулятор терминала

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

Если что, мне очень нравится проект Hurd, но для того, чтобы он составил серьёзную конкуренцию линуксу, нужны более серьёзные аргументы. При прочих равных микроядерная архитектура сливает монолитной по производительности, хотя, вероятно, позволяет получить выигрыш по предсказуемости.

Вообще, такие фразочки похожи на маркетинговый bullshit. Впрочем, как и «передовых идей».

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

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

• единообразные интерфейсы;
• расширяемость;
• гибкость;
• переносимость;
• надежность;
• поддержка распределенных систем;
• поддержка объектно-ориентированных операционных систем.

Использование микроядра предполагает единообразный интерфейс (uniform interface) запросов, генерируемых процессами. Процессам не нужно различать службы, выполняющиеся на уровне ядра и на пользовательском уровне, потому что доступ ко всем этим службам осуществляется только с помощью передачи сообщений. С появлением новых аппаратных устройств или методов программирования любую операционную систему неизбежно нужно будет пополнять новыми свойствами. Архитектура с применением микроядра способствует расширяемости (extensibility) операционных систем, позволяя добавлять в них новые сервисы, а также обеспечивать множественные сервисы в одной и той же функциональной области. Например, можно реализовать несколько различных способов организации хранения файлов на дисках. Далее, вместо того чтобы помещать все эти файловые сервисы в ядро, каждый способ организации хранения можно реализовать в виде процесса на пользовательском уровне. Таким образом, из всего разнообразия сервисов пользователь может выбрать тот, который подходит ему больше других. При добавлении нового свойства в операционную систему с архитектурой микроядра достаточно добавить или модифицировать лишь некоторые из серверов. Влияние новых или измененных серверов распространяется на ограниченное подмножество системы; кроме того, после модификации не нужно будет строить новое ядро.

С расширяемостью архитектуры микроядра тесно связано такое ее свойство, как гибкость (flexibility). В операционную систему можно не только добавлять новые свойства, но и удалять из нее те, которыми она обладает. Иногда это нужно, чтобы получить более компактную и эффективную версию. Операционная система с микроядром не обязательно является маленькой. На самом деле ее структура приспособлена к добавлению разнообразных возможностей. Однако не для всех компонентов системы нужно, чтобы они обладали, например, высоким уровнем безопасности или способностью к распределенным вычислениям. Если свойства, предъявляющие значительные требования к объему памяти, будут необязательными, базовый продукт сможет привлечь более широкий круг пользователей. Почти полная монополия компании Intel на многие комплектующие компьютеров вряд ли будет существовать бесконечно. Таким образом, привлекательным свойством операционной системы становится ее переносимость (portability). В архитектуре с микроядром специально предназначенный для конкретного процессора код, или по крайней мере большая его часть, находится в микроядре. Поэтому изменения, которые потребуются для переноса системы на новый процессор, сводятся к минимуму и имеют тенденцию к размещению в отдельных логических группах. Чем большим объемом обладает программный продукт, тем труднее проверить надежность его работы. Хотя модульность и помогает повысить надежность (reliability) работы системы, архитектура с микроядром дает еще более ощутимые преимущества. Маленькое микроядро можно тщательно протестировать. Использование в нем небольшого количества интерфейсов прикладного программирования повышает шансы на то, что сервисы операционной системы, работающие вне ядра, будут реализованы с помощью качественного кода. Системный программист имеет в своем распоряжении ограниченное количество интерфейсов и ограниченные способы организации взаимодействия, поэтому он не сможет отрицательно повлиять на другие системные компоненты. Микроядро способствует поддержке распределенных систем (distributed systems), к которым относятся кластеры, управляемые распределенными операционными системами. Сообщение, которое пересылается от обслуживаемого процесса обслуживающему, должно содержать в себе идентификатор запрашиваемого сервиса. Если распределенная система (т.е. кластер) сконфигурирована так, что все процессы и сервисы в ней обладают уникальными идентификаторами, то, в сущности, на уровне микроядра образуется единый образ системы. Процесс может отправлять сообщение, не зная, на какой именно машине находится сервис, к которому он обращается. К этому вопросу мы еще вернемся, обсуждая в шестой части книги распределенные системы. Архитектура с микроядром хорошо работает в среде объектно-ориентированных операционных систем (object-oriented operating system). Объектно-ориентированный подход способствует более строгой разработке микроядра и модульных расширений операционной системы. Поэтому многие разработчики прилагают усилия для перехода к объектно-ориентированному конструированию. Одним из многообещающих подходов, в котором сочетаются архитектура с микроядром и принципы объектно-ориентированных операционных систем, является подход с использованием компонентов. Компоненты — это объекты с четко заданными интерфейсами, которые могут соединяться между собой, образуя программы по принципу строительных блоков. Во всех взаимодействиях между компонентами используются их интерфейсы.

Linux перестал быть эмулятором терминала уже через несколько недель после начала разработки. Иначе можно и Windows 8 назвать надстройкой над DOS.

конечно же, перестал, дело не в этом. дело в том, что он был эмулятором терминала. и от этого эмулятора терминала начались пляски, кое-как превратившие Linux в подобие ядра. Linux - ядро, построенное на основе эмулятора терминала. лично я считаю, что ядро должно писаться как ядро, иначе неизбежно скатывание архитектуры в тотальное говно на 100500 строк костылей, в котором никто не может разобраться (привет, X.org!), как это случилось с Linux.
аналогия с Windows неуместна - NT была написана заново, чего не случалось с Linux. но некоторые костыли совместимости тянутся до сих пор, вызывая похожий эффект: 100500² строк кода, в которых совсем уж никто не может разобраться. в результате венда еще более костыльна и архитектурно изувечена, чем Linux.

При прочих равных

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

микроядерная архитектура сливает монолитной по производительности

1. в реальных серверах время на передачу сообщения занимает, наверное, 0,01% от времени выполнения реквеста. потери настолько ничтожны, что ты вряд ли их заметишь.
2. что ты там делаешь? считаешь π до миллиардной цифры? на обычных задачах ты не заметишь вообще никакой потери производительности.
3. микроядра 1-го поколения, вроде CMU Mach, конечно, могут быть немного медленными. проблема решается в GNU Mach, в 1.5 там запилили protected payload, которые позволяют серверу зарегистрировать свои вызовы и миновать длительную стандартную передачу сообщения и в современных микроядрах, таких как L4. там реальных потерь производительности (не наносекундных, а сколько-нибудь ощутимых) вообще нет.

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

Ничего не значащая демагогия. От того времени, когда Линус начинал заменять терминал, там осталось дай бог если несколько десятков строк кода. И неужели ты считаешь, что Линус такой идиот, что не переструктурировал код, когда понял, что пишет уже не терминал, а ОС?

Дай пример. Где конкретно в ядре Linux костыльность, унаследованная именно от «эмулятора терминала»?

вот небольшая паста, рассказывающая об основных достоинствах микроядерной архитектуры

Я это всё читал. И про то, что микроядерность это плюс к гибкости, знаю. Знаю и то, что гибкость можно обеспечить и другими средствами.

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

Вот когда Hurd будет более или менее готов, можно будет сравнить. Я за развитие Hurd обеими руками. Альтернатива должна быть. Но я категорически против того, чтобы признавать концепцию Linux однозначно плохой, а концепцию Hurd - однозначно хорошей на основании подобных заклинаний. Книжку Брукса про серебряную пулю читал?

Все такие костыли усложняют и удорожают проц. ARM как-то прекрасно без этого справляется, и популярность архитектуры все растет.

Я тебе посто скажу - гумно полное твой АРМ.
Дело даже не в архитектуре вообще, и не в софте в частности, а в симбиозе на данный момент и первого и второго.
И скажу не как программер, и не как разработчик железа, а как просто немного более чем обычный юзер-хомячок.
Вопреки желанию производителей и прочих продаванов, на обычную, не самую свежую x86-64 архитектуру я могу установить практически любой современный дистр какой пожелаю.
В случае ARM, такая задача будет просто невыполнима. Если у тебя конечно не чёрный пояс по программированию, или ты совсем даун-хомяк.
В первом случае ты Дартаньян, и можешь взять с полки пирожок, у тебя вагон бесполезного времени можешь скомпилять полностью дистр под свою версию ARM, разбиратся в бутлоадерах, рекавери, систем имадж и прочей хери, но таких как ты один на миллион, и статистика тебя вычёркивает.
А не вычёркивает статистика обычных юзер-хомячков, которые за неимением соотв. навыков поворачиваются к производителю подобающим местом, и он их туда лелеет год-два в зависимости от гарантии/желания/жадности. Дальше, пшёл вон пёс смердящий - готовь денюжку на новую модель.
Пока весь этот развод с ARM выглядит именно так: неплохое ещё по возможностям железо, без практической возможности обновить на нём софт, устранить программные глюки. И решения этому, в обозримом будущем не видно.
Соглашусь с одним. Хомяки всё это хавают, да - создают статистику.

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

QNX. И никто не поручится, что её достоинства вызваны именно микроядерностью

ППКС. Никто не знает, что там под капотом. Думал об этом добрую сотню раз.

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

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

Веселит нынешняя молодежь однако. На любой, не первой свежести x86-64 можно без проблем и твою мега-недоось поставить, и любую другую полноценную о/с по желанию, без проблем вообще.

что ты там делаешь? считаешь π до миллиардной цифры? на обычных задачах ты не заметишь вообще никакой потери производительности.

<br/><br/> Переключения контекстов, например. Когда ты программируешь на ассемблере, ты экономишь каждый push в стек, потому, что он выполняется неимоверно долго. Когда ты переключаешь контексты - у тебя подкачивается/сохраняется неимоверное количество дескрипторов. Вообще, если бы я был зелёным, то запретил бы все эти ваши защищённые режимы. И дело не в том, что таблицы дескрипторов должны загружаться в кеш процессора, просто это требует огромного количества переключений триггеров, и, следовательно, приводит к повышенному потреблению энергии, что в свою очередь, вызывает тепловую эмиссию, подогревая температуру на планете и вызывая таяние ледников.