Darwin

Гибридное же. На Вашем месте я бы лучше вспоминал QNX и BeOS

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

- Прослойку драйверов Linux, о которой где-то в их дев-рассылках заикались N лет назад - сделали, или нет? Если нет - будут ли делать и, если да - то когда?

- Как обстоят дела с портами на MIPS и ARM?

- Реп софта, и вообще совместимость окружения с POSIX - оно есть? Полноценное? Или его нет?

Гибридное же. На Вашем месте я бы лучше вспоминал QNX и BeOS

Гибридное, но на базе микроядра же. По популярности дарвин, я думаю, где-то между BSD и Linux, так что о нем первом и вспомнилось.

Гайка тоже вроде как живая (BeOS fork), новости о напилинге проекта выходят регулярно, как я вижу. Сам БеОС мне когда-то нравился, а вот кунникс - нет. Издох - туда ему и дорога. 8)

Хорошие вопросы, особенно про прослойку драйверов Linux. Не заметил (быть может читал невнимательно), иначе уже во всю трубили-бы о совместимости с драйверами. Да и работа эта нетривиальна, как может показаться.

Да и работа эта нетривиальна, как может показаться.

Мне и не кажется, что эта работа - тривиальна, более того - я себе представляю, как надо поднатужиться, чтобы это сделать. Встречал в их рассылке обсуждение этого вопроса несколько лет назад - потому и спросил - сдвинулось ли? Не следил за ними - занят линуксом. Видимо - не сдвинулось, а жаль. Очень жаль. Потому как это позволило бы Hurd'у выскочить на аппаратный уровень Linux за счёт заимствования драйверов, а там уже - «кто кого». Я бы, например, попробовал бы Hurd использовать в работе. А без этого... «пичалька, горюшко и гневик»...

Согласен. Всё печально. Возможно что у L4 больше потенциал и есть применения, загуглить несложно, тот-же Genode. Но как будет с производительностью на серверах например. Опять-же везде проблемы с поддержкой оборудования. Быть может «каждому своё» в областях применения? Цитата отсюда https://ru.wikipedia.org/wiki/L4_(микроядро) : " Йохеном Лидтке хотел проверить, возможно ли добиться высокой производительности компонента IPC, если выбрать для ядра подходящую архитектуру и в реализации использовать особенности аппаратной платформы. Реализация механизма IPC оказалась удачной (по сравнению со сложной реализацией IPC в микроядре Mach). Позднее был реализован механизм изоляции областей памяти процессов, работающих в пространстве пользователя. "

(BeOS fork)

Haiku не fork а remake.

а вот кунникс - нет. Издох - туда ему и дорога. 8)

Не сдох, да и не сдохнет. КПДА - единственная достойная ОС в войсках.

Гибридное, но на базе микроядра же.

Если бабушке прицепить фалоиммитатор, она будет похожа на дедушку.

Haiku не fork а remake.

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

КПДА

Эт нейтрино-то - достойная? Ты с ней-то работал, или так - где-то услышал? 8) Я обоснованно полагаю, что второе. И знаешь, - почему? Потому что «нейтрино» - это эхолоты, радары и ракеты. И оооочень редко - какие-нибудь некритичные антенные комплексы. И это, - ты когда про войска говоришь с умным видом - сперва матчасть освой... 8) ...Помню, как мне пришлось пилить однажды математику... военную... на Win95... Один генерал мне тогда так и сказал - «ничего лучше у нас в войсках нет». :-D

Возможно что у L4 больше потенциал и есть применения

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

Да есть, применяют, есть пара коммерческих и открытых систем на базе L4, но как-то оно выглядит (для меня) странно. Hurd выглядит... ну привычнее, классичнее, что-ли. Хотя он еще сырее всех сырых.

Ты с ней-то работал, или так - где-то услышал?

ну да не не работал :) так развлекался.

Serial Number: 904058-00307617 Date Delivered: 8-Aug-2008

илить однажды математику... военную... на Win95.

Без комментариев.

Помню, как мне пришлось пилить однажды математику... военную... на
Win95... Один генерал мне тогда так и сказал - «ничего лучше у нас в
войсках нет». :-D

В комплексе «кольчуга» была 95-я винда на пульте и софт. Не твой? ) По-серьёзному критичные вещи делают аппаратными, насколько это возможно.

Date Delivered: 8-Aug-2008

«Codename: Georgia Defeated»... бугага ;)

Ковырялся я с этим шлаком из ОТТАВЫ. Шлак и есть. И да, кунникс для всяких медиков на западе действительно пока еще теплится. BB от него отказались. Для наших шизо - нууу... поскольку кунникс пришел к нам в 2007-м, как только они исходники начали открывать, и поскольку он был спроектирован значительно лучше, чем «дот», «комбат» или «биос», эта ОСРВ и была принята на вооружение, но очень осторожно и очень избирательно. Я в 2007-2008 и ковырялся с ней. Как раз - «комплекс эхолоцирования для некритичного применения». Коллеги в разных местах получили другие заказы, все - подобного же уровня. Ни одному не понравилось. Сейчас заказов от ВВ на кунникс нет, но есть заказы на другую ОСРВ... 8)

...А насчет Win95 - это не шутка была. Реальный факт, начало двухтысячных.

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

Эта «другая ОСРВ» написана с нуля? И чем _особенно_ не понравился QNX? Если объяснять долго ткни, сам почитаю. Интересно

Эммм... ну тайны, я надеюсь, не открою - есть заказы на «багет».

QnX не понравился всем, в том числе - совершенной его непредсказуемостью. Например - я никогда (до знакомства с кунниксом) не видел, чтобы система уходила в разнос при банальном конфликте IP-адресов... Допускаю, что это уже исправили, но послевкусие от подобных «мелких багов» остаётся надолго и вызывает стойкое отвращение.

Как ни смешно

Менее маргинален как ни смешно

Изобрести новый язык вместо использования существующего это теперь называется «менее маргинален»?

у nix/nixpkgs/nixos больше разработчиков/пользователей/контрибуторов.

Каким образом вы это измерили?

спасибо. А то я думал что только у «них» ВхВоркс.

Изобрести новый язык вместо использования существующего это теперь называется «менее маргинален»?

Ну там не было сверхзадачи использовать схему и 10 лишних зависимостей в замыкании с nix. И еще потому что nix — ленивый язык.

Опять же повторюсь --- проблема там в gpl3 на дерево пакетов, и абсолютная идиосинкразия к non-free. То есть никакой продукт на его базе не построишь.

Как кстати сборочные скрипты в guix участвуют в формировании хеша пакета? (та часть, что на схеме)

PS Я NixOS полтора года использую на десктопе, поэтому более-менее представляю живость коммюнити, и активность разработчиков

Ленивый контрибьютор

И еще потому что nix — ленивый язык.

Во-первых, давайте использовать устоявшийся термин nixlang, так понятнее. Во-вторых, а это важно что он ленивый? Что это даёт? Небольшое сокращение времени работы nix'а? Scheme тоже частично ленивый:

Haskell is well recognized as a programming language that totally adopts lazy evaluation. Scheme also adopts it (even the adoption is partially).

Опять же повторюсь --- проблема там в gpl3 на дерево пакетов

А вот чем это плохо и какие от этого могут быть последствия я даже не представляю. Какой смысл форкать и закрывать репозитарий nix'а, если он не имеет смысла без всяких свободных программ типа GCC? Продавать кастомные сборки OpenSSH? Для этого можно просто делать бинарные пакеты типа какого-нибудь Skype'а, при этом сценарий установки его может быть открытым.

абсолютная идиосинкразия к non-free.

Если честно, то я сам жду, что кто-нибудь форкнет GuixSD и начнёт развивать более грязетерпимый дистрибутив. Я сам пользуюсь ядром с бинарными блобами для Radeon'а и WiFi (хотя следующий ноутбук скорее всего будет с Intel и постараюсь купить со свободным WiFi). Возможно даже, что однажды я сам усилю стремление к увеличению намерения форкнуть GuixSD. Но сейчас несвободных программ для GNU/Linux'а исчезающе мало.

То есть никакой продукт на его базе не построишь.

В чём проблема? Бери и строй.

>> Опять же повторюсь --- проблема там в gpl3 на дерево пакетов

А вот чем это плохо и какие от этого могут быть последствия я даже
не представляю. Какой смысл форкать и закрывать репозитарий
nix'а, если он не имеет смысла без всяких свободных программ типа
GCC? Продавать кастомные сборки OpenSSH? Для этого можно
просто делать бинарные пакеты типа какого-нибудь Skype'а, при
этом сценарий установки его может быть открытым.

А никто не говорит «форкать и закрывать», работа по кастомному дереву для корпоративного заказчика уже подпадает под GPL3 ограничения.

По поводу форка — ну форкнете вы его, и что дальше — располовините и без того малую базу разработчиков и активных пользователей?

Не надо свободность доводить до крайностей типа «голый == свободный от одежды пошитой злым капиталистом». radeon с открытыми драйверами от xorg/mesa это нормально, а на микрокод всем плевать.

PS И я не знаю где nixlang устоявшийся термин, видимо где то не в коммьюнити разработчиков nix

Разъясняйте

А никто не говорит «форкать и закрывать», работа по кастомному дереву для корпоративного заказчика уже подпадает под GPL3 ограничения.

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

По поводу форка — ну форкнете вы его, и что дальше — располовините и без того малую базу разработчиков и активных пользователей?

Ubuntu располовинила базу пользователей и разработчиков Debian'а? «Форкнуть» не значит «разосраться и наложить анафему».

Не надо свободность доводить до крайностей типа «голый == свободный от одежды пошитой злым капиталистом». radeon с открытыми драйверами от xorg/mesa это нормально, а на микрокод всем плевать.

Не надо свободность доводить до крайностей типа «голый == свободный от одежды пошитой злым капиталистом». Однако, к моему глубокому сожалению, в linux-libre нет микрокода Radeon'а.

Однако, к моему глубокому сожалению, в linux-libre нет микрокода Radeon'а.

вот это и есть доведение до абсурда.

Что за «кастомное дерево копротивного заказчика», зачем оно
нужно, что вы продаёте?

К примеру какое-то облачное решение. Это не столь важно, мне работодателю/заказчику проще пальцем показать что там BSD, и его это заведомо устроит. А с gpl нужно будет толпу юристов звать, чтобы выяснять упираемся мы в какие-то ограничения, или нет.

PS И на вопрос про участие схемного кода в формировании хешей вы мне так и не ответили

Схемный кеш

вот это и есть доведение до абсурда.

Так в чём у вас проблема-то? Да, мне не подходит linux-libre, мне хочется чтобы GuixSD использовал linux. Да, я не хочу ходить голым без одежды от копирастов. Вопрос-то у вас какой?

К примеру какое-то облачное решение. Это не столь важно, мне работодателю/заказчику проще пальцем показать что там BSD, и его это заведомо устроит. А с gpl нужно будет толпу юристов звать, чтобы выяснять упираемся мы в какие-то ограничения, или нет.

Какой-то пальцесосный аргумент. Шо облачное решение, шо заказчик, шо работодатель — если описание рецепта сборки не передаётся, то это всё не имеет никакого значения. В какой бизнес-модели вы собираетесь зарабатывать на передаче именно рецептов, а не результатов работы этих рецептов?

PS И на вопрос про участие схемного кода в формировании хешей вы мне так и не ответили

Отвечаю прямо, прямее некуда: не знаю. А что? Какое значение имеет участие схемного кода в формировании хешей? Не знаю как они сейчас формируются, но проблемы в этой области нет. Как-то формируются, и это всё работает.

Guix for Hurd

И таки скажите, вы согласны, что Guix на Hurd'е будет полезен, или Hurd'у ничем не помочь?

Так в чём у вас проблема-то? Да, мне не подходит linux-libre, мне
хочется чтобы GuixSD использовал linux.

А в чем проблема, что его туда не принимают в качестве «описание рецепта сборки»? Это иначе как идиосинкразией объяснить нельзя.

В какой бизнес-модели вы собираетесь зарабатывать на передаче
именно рецептов, а не результатов работы этих рецептов?

в той где передается «продукт в целом», а не отдельные компоненты. В том случае где стандартная библиотека языка gpl без linking exception (как у libgcc) — тянет за собой gpl. У гуикса — все его кишки под это попадают.

Какое значение имеет участие схемного кода в формировании хешей?

Прямое.

У nix сборочный «рецепт» — это скрипт-сборщик (в 95% случаев стандартный) и переданый ему environment (в котором на этот самый сборщик указывает переменная builder. Этот же environment и формирует хеш пакета (все участвующие в сборке шельные команды либо в билдере — который путь в хранилище и попадает в хеш через переменную builder, или за счет всяких переменных buildPhase="...кусок-скрипта..." (которые опять же попадают в хещ))

А вот схемные функции из рецепта гуикса — не факт что попадают (по крайней я этого с ходу не увидел). Не факт, что их изменение в дереве рецептов вызовет инвалидаци/пересборку только того, что изменилось.

silver bullet у никса — что он простой как валенок. И его принципы логику можно на пальцах объяснить любому кто знает шелл и юникс.

Юристам в радость

А в чем проблема, что его туда не принимают в качестве «описание рецепта сборки»? Это иначе как идиосинкразией объяснить нельзя.

Так о чём вы со мной спорите? Наш с вами спор ходит вокруг диалога:
 — Да, надо добавить несвободные пакеты.
 — Нет, надо добавить несвободные пакеты.

в той где передается «продукт в целом», а не отдельные компоненты. В том случае где стандартная библиотека языка gpl без linking exception (как у libgcc) — тянет за собой gpl. У гуикса — все его кишки под это попадают.

Вот так сюрприз. Оказывается передавать «продукт в целом» это проблема. А в RedHat'е-то не знали, в Oracle уже волосы на голове рвут, как же дальше жить, в Microsoft Билла Гейтса обратно зовут, говорят при нём такой фигни не было. Во всех юридических отделах сегодня праздник.

Не факт, что их изменение в дереве рецептов вызовет инвалидаци/пересборку только того, что изменилось.

Так и происходит, говорю по личному опыту.

silver bullet у никса — что он простой как валенок. И его принципы логику можно на пальцах объяснить любому кто знает шелл и юникс.

Guix работает точно так же. Все объяснения про работу nix'а подходят и для guix'а, и наоборот.

Так о чём вы со мной спорите? Наш с вами спор ходит вокруг диалога:
— Да, надо добавить несвободные пакеты.
— Нет, надо добавить несвободные пакеты.

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

Так и происходит, говорю по личному опыту.

Мне механизм и удачность его реализации интересны

Guix работает точно так же. Все объяснения про работу nix'а подходят и для guix'а, и наоборот.

для гуикса надо еще и Схему знать на уровне выше среднего.

Но давайте уже поговорим про то, о чем я могу судить: Cравним http://git.savannah.gnu.org/cgit/guix.git/tree/gnu/packages/autotools.scm#n264 и https://github.com/NixOS/nixpkgs/blob/master/pkgs/development/tools/misc/libt...

И что проще и читаемее?

    (propagated-inputs `(("m4" ,m4)))
    (native-inputs `(("m4" ,m4)
                     ("perl" ,perl)
                     ("automake" ,automake)      ;some tests rely on 'aclocal'
                     ("autoconf" ,(autoconf-wrapper)))) ;others on 'autom4te'

  propagatedNativeBuildInputs = [ m4 ];
  nativeBuildInputs = [ perl help2man ];

и потом чтобы в «собирающем» коде вытащить пути

                   ;; Path references to /bin/sh.
                   (let ((bash (assoc-ref inputs "bash")))
                     (substitute* "tests/testsuite"
                       (("/bin/sh")
                        (string-append bash "/bin/bash")))))

Вместо "${pkgs.bash}/bin/bash"

Я бы понял, если бы у вас там был s-expr based DSL, который потом транслируется в схему (с интерполяциями и прочими плюшками), но у вас же там закат солнца вручную какой-то.

Кстати, а multiple outputs у вас планируется? Ну и production ready когда (потому что у нас уже по обоим пунктам)

Всё идёт по плану

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

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

для гуикса надо еще и Схему знать на уровне выше среднего.

Я не знаю Scheme, даже на уровне ниже среднего. После этих слов мой ноутбук должен взорваться?

И что проще и читаемее?

Даже не зная Scheme и nixlang я вижу, что эти куски кода не эквивалентны.

Кстати, а multiple outputs у вас планируется? Ну и production ready когда (потому что у нас уже по обоим пунктам)

Давно уже. И что не так с продакшеном? nix самообозвались продакшенреди, и значит админам уже можно ссаться от радости, а Guix поскромничали, значит гроб, гроб, кладбище, даунтайм?

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

И что проще и читаемее?

Даже не зная Scheme и nixlang я вижу, что эти куски кода не эквивалентны.

Это примеры одного и того же пакета (libtool) в двух системах, выдержки из них же.

Под multiple-outputs я имею ввиду автоматическое разделение библиотек в -lib, заголовков в -dev (ну у вас :lib и :dev соотвественно). (на это почти год ушло, прежде чем довели до состояния «можно вливать в мастер»).

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

А вы к сожалению не аргументируете, не приводите примеров, одну демагогию, словоблудие и фанбойство неофита.

Приведите хотя бы одни пример, с ссылками, примерами кода, etc

Берега вы мои берега

Это примеры одного и того же пакета (libtool) в двух системах, выдержки из них же.

Анон, ну ты совсем берега потерял. Это примеры разных сборок одной и той же программы. В них совпадают только слова «m4» и «perl», а слова «help2man», «autoconf» и «automake» не совпадают. Эти рецепты сборки собирают по разном, они делают разные вещи.

Под multiple-outputs я имею ввиду автоматическое разделение библиотек в -lib, заголовков в -dev (ну у вас :lib и :dev соотвественно). (на это почти год ушло, прежде чем довели до состояния «можно вливать в мастер»).

Поздравляю, nix настолько хорош, что его разработчики от безделья занялись совершенно бесполезными вещами. Это зрелость.

Это примеры одного и того же пакета (libtool) в двух системах, выдержки из них же.

Эти рецепты сборки собирают по разном, они делают разные вещи.

Ну приведите же свой, более наглядный пример.

Я в первую очередь хотел показать очевидную синтаксическую корявость вашего решения, хотите показать что оно epic win — выберите пример сами.

Под multiple-outputs я имею ввиду автоматическое разделение библиотек в -lib, заголовков в -dev (ну у вас :lib и :dev соотвественно).

nix настолько хорош, что его разработчики от безделья занялись совершенно бесполезными вещами.

А зачем абсолютно все майнстримные дистрибутивы делают эту совершенно бесполезную вещь? Работу по уменьшению зависимостей замыкания с самм nix вы тоже считаете бесполезной?

Мейнстримная ошибка

Ну приведите же свой, более наглядный пример.

Сходу не могу, а потратить на это время не хочу.

А зачем абсолютно все майнстримные дистрибутивы делают эту совершенно бесполезную вещь?

Все майнстримные это какие? Debian, Ubuntu и Mint? Всегда бесило что они позволяют себе программы разбивать на части, хотя этим должен заниматься автор программ. Из opache-1.4.17.tar.gz должен получаться пакет opache_1.4.17_amd64.deb, а не opache-core, opache-common, opache-utils, opache-dev, opache-libs и opache-doc. Но это наследное убожество dpkg, он по-другому не умеет. Тут правильнее было бы двигаться в сторону аналога USE-флагов из Gentoo. Пакет opache с флагами (+utils -dev -libs +doc) это всё ещё пакет opache, но у него другой хеш по сравнению с opache(+utils +dev +libs -doc).