В рамках проекта NextBSD (http://www.nextbsd.org/) группой энтузиастов началось (http://www.nextbsd.org/clarifying-near-term-expectations/) развитие BSD-системы нового поколения. В качестве основы задействовано (https://drive.google.com/file/d/0B1CTSkgkHoaccjJLM0NnWGRVdEE... актуальное ядро и базовое программное окружение FreeBSD-CURRENT, а также компоненты, портированные из проекта Darwin. Таким образом NextBSD сочетает свежие наработки FreeBSD с низкоуровневыми технологиями OS X.Ядро FreeBSD дополнено механизмом межпроцессного взаимодействия на базе микроядра Mach (https://ru.wikipedia.org/wiki/Mach). Для инициализации, управления сервисами, выполнения периодических заданий, активации обработчиков сетевых соединений и слежения за работоспособностью служб задействован системный менеджер launchd (http://www.opennet.dev/opennews/art.shtml?num=38692), который дополнен прослойкой для обеспечения совместимости с классической системой rc-скриптов. Демон launchd объединяет в себе функции процесса init, системы стартовых скриптов rc.d и init.d, демонов inetd, atd, crond, и watchdogd. Файлы конфигурации launchd хранятся в формате JSON.
Ведение логов осуществляется при помощи системы ASL (https://developer.apple.com/library/prerelease/mac/documenta... (Apple System Log). Для отслеживания и обработки событий, а также для доставки уведомлений, применяется сервер notifyd (https://developer.apple.com/library/mac/documentation/Darwin.... Диспетчеризация выполнения задач и потоков осуществляется с привлечением libdispatch.
<center><a href='https://drive.google.com/file/d/0B1CTSkgkHoaccjJLM0NnWGRVdEE...'><img src="http://www.opennet.dev/opennews/pics_base/0_1440748870.png" style="border-style: solid; border-color: #e9ead6; border-width: 15px;max-width:100%;" title="" border=0></a></center>
Код проекта развивается (https://github.com/NextBSD/NextBSD) на GitHub. В настоящее время уже реализованы базовые возможности
launchd, notifyd, asld и libdispatch. Для установки NextBSD предлагается в существующем окружении FreeBSD 10.x или -CURRENT клонировать репозиторий с GitHub, пересоборать ядро и систему в конфигурации MACHTEST и переустановить компоненты базовой системы. Установочные ISO-образы пока не готовы из-за необходимости интеграции launchd с установщиком FreeBSD. До середины сентября планируется представить рабочий инсталлятор.URL: http://www.nextbsd.org/clarifying-near-term-expectations/
Новость: http://www.opennet.dev/opennews/art.shtml?num=42864
Наконец то уберется куча rc скриптов.P.S.
Еще бы syslogd в него засунуть.
>Еще бы syslogd в него засунуть...и переименовать в systemd
systemd слизали как раз с этого, но работает конечно же как и всё остальное в линуксе - через жопу.
Объясните мне почему он работает через 444? На мой взгляд строить граф зависимостей и запускать процессы в рамках systemd великолепная идея не пойму почему тысячи польщзоватлей выступают за зоопарко неконтролируемых сценариев на bash?
Потому что в винде так уже сделали. Не понравилось.
Идея хорошая, но вот реализация не соответствует простым и понятным принципам KISS (journald) и UNIX-way (systemd это комбайн!). Значит на выходе получаем даже не unix-like. Как правильно было подмечено чуть ранее "Не понравилось".
четам может понравиться то?? Сижу вот на 10.8 OSX, вот болееменее близко к posix.. 10.10 это …здец...
СЦУКОЛИНУКС… СЦУКо системд
Хотя надо отдать должное - launchd это xml пипец - но РАБОТАЕТ всегда
Судя по несвязному и очень тупому бреду - ты бояздэшник, сам выписавший себе диагноз.
А с посикс-совместимостью в макоси всегда были проблемы, притом намного более серьёзные.
linux это комбайн. Не соответствуюет kiss и unix-way. Значит на выходе получается даже не unix-like.
А tar + gzip соответствует unix-way. И на выходе получается необходимость распоковывать многогигабайтный архив целеком чтоб получить список файлов.
> А tar + gzip соответствует unix-way.А подводная лодка - это такой транспорт, да. Но по суше не очень могет. Из чего делаем вывод: все эти новомодные средства передвижения - фигня!
> И на выходе получается необходимость распоковывать
> многогигабайтный архив целеком чтоб получить список файлов.А использовать DAR - религия не позволяет!1
> А подводная лодка - это такой транспорт, да. Но по суше не очень могет.Это которая в степях украины, погибла в неравном воздушном бою?
> Из чего делаем вывод: все эти новомодные средства передвижения - фигня!
Транспортное средство из подводных лодок, действительно, "не очень". Это в основном боевые машины. Иногда исследовательские аппараты. А как транспорт всерьез используется разве что наркокартелями, и то - очень местами.
> А использовать DAR - религия не позволяет!1
Так не юниксвейно же! Юниксвейно - это пайп из вывода ленточного архиватора в отдельную стадию компрессора. Вот так и получается что иногда юниксвей может выглядеть по дypaцки. Если например надо вынуть 10 файлов из середины 100-гигабайтного архива на диске.
> Так не юниксвейно же! Юниксвейно - это пайп из вывода ленточного архиватора
> в отдельную стадию компрессора.А, ну если речь о юниксвейности, существующей в головах отдельных личностей, тогда да.
А так, использование неподходящей тулзы при наличии альтернатив - это упорин-вей, но никак не юникс :)
Так безмозглому зилоту скажи "юникс-вэй" - он и лоб себе расшибет. Вот хейтеры системды в массе своей будут корячиться с распаковкой 100Гб архива до середины. Ради юниксвейности. Ну и что, что юзерье свой бэкап получит через полдня, а не через 2 минуты? Зато расово верно.
> Так безмозглому зилоту скажи "юникс-вэй" - он и лоб себе расшибет. Вот
> хейтеры системды в массе своей будут корячиться с распаковкой 100Гб архива
> до середины. Ради юниксвейности. Ну и что, что юзерье свой бэкап
> получит через полдня, а не через 2 минуты? Зато расово верно.А, это такой намек на systemd-(re)tard или причем здесь опять этот мега-комбайн?
> На мой взгляд строить граф зависимостей и запускать процессы в рамках systemd
> великолепная идеяЦиклы проходили?
Михаил, а собственно, к чему вопрос? Он вроде пишет граф, а не дерево. =)
> Михаил, а собственно, к чему вопрос? Он вроде пишет граф, а не дерево. =)Михаил всегда пытается испугать всех графами, но забывает уточнить что альтернативой - Тюринг-полная программа, которая с точки зрения теоретического описания намного хуже. Общение с MSSP и единоросами не прошло даром: подтасовки фактов и подмены понятий у Михаила стали получаться намного филиграннее. И он даже научился говорить не всю правду. Совсем как корпорация майкрософт.
Я не сумел осмыслить первое предложение. Прошу меня простить.
>> Михаил, а собственно, к чему вопрос? Он вроде пишет граф, а не дерево. =)
> Михаил всегда пытается испугать всех графами, но забывает уточнить что альтернативой -
> Тюринг-полная программа, которая с точки зрения теоретического описания намного хуже.Со второго раза осмыслил.
Тьюринг-полная программа вообще не поддастся в этом плане теоретическому описанию. Но хуже ли это - вопрос спорный. Я бы взялся утверждать, что такой подход как минимум удобен.
если бы системд был бы просто системой иницилизации вопросов бы не было. Это было просто плохое (или хорошее решение), решение которого принимали бы дистростроители. Например мучатся на сисв скриптах, апстарте или системд. Но системд пошел дальше они впихнули свою системы журналд который хз как работает, logind и udev. Вроде бы не так страшно, звучит, просто кто то навелосипедил, а нет. Одно без другого не работает. теряется модульность. А это по мне имеет свои последствия.
Если из разработчиков одного модуля даст ебу, примет неадекватное решение, с которым сообщество не будет согласно, то его просто форкнут и будутразвивать один модуль отдельно. в этам прелесть опенсорсного сообщества. а тут придется или форкать связку программ, или развиваться учитывая особенности разработки системд.
По мне идеально со своей задачей справлялся upstart он был просто и понятен.
После пользования системд у меня сложилось впечатление что я работал с виндоконсолью
Потому что если баш скрипт не работает, очень просто понять проблему, а если это systemd юнит, то хер вы поймете где вы очепятались, а это чудо-поделие поттеринга тихой сапой пропускает неверный синтаксис и все равно стартует процесс, вместо того чтобы выдать ошибку. Еще хуже если баг будет в самом systemd.
> Потому что если баш скрипт не работает, очень просто понять проблему,Ну да, конечно.
Тебе сложно понять где ошибка в шелл-скрипте?
Ее муторно и долго искать, особенно в чужом б-коде
В коде на C от Лёни её искать определённо быстрее.
> В коде на C от Лёни её искать определённо быстрее.А там ошибки чаще всего приходится искать только Лене и его шайке. А в куда как более типовой ситуации вида "сервис что-то не стартует" - системд выдает вменяемую диагностику. Без костылирования. В отличие от скриптопростынок.
Делаться просто должны 99% случаев. А в 1% так и быть я покопаюсь. У поттера так и получается. А в скриптопростынках - наоборот.
В том и беда что само systemd корявая, и местами падает через раз, особенно если что то пытаешься нестандартное сделать, шаг в право, шаг в лево, сегфолт.
Гордый пользователь бояздэ на десктопе? Рассказывай, что тебе не нравится в неосиленной тобой системе.
> Гордый пользователь бояздэ на десктопе? Рассказывай, что тебе не нравится в неосиленной
> тобой системе.Гордый пользователь не-LFS? Рассказывай, что тебе не правится в неосиленной тобой системе.
А с чего ты решил,что я не осилил лфс? Были сборки под конкретные задачи, и не только под х86.
А с чего ты решил, что мир состоит из бсд и линукса?
Ну, аиксом и зулярисом я тоже пользовался, но слишком мало их сегодня осталось. Ещё когда-то приходилось ковырнуть чпукс.
> Были сборкиТ.е. на десктопе не осилил ...
Осилил. И бездисковые десктопы(тонкие клиенты) тоже были.
> Осилил. И бездисковые десктопы(тонкие клиенты) тоже были.Итак:
новость о "NextBSD", "развитие BSD-системы нового поколения".
Очередной Анонимный Свидетель Ядра гордо вещает "Я осилил ЛФС! Даже на тонких клиентах!"
Эпично :)
>>Еще бы syslogd в него засунуть
> ...и переименовать в systemdSystemXD тогда уж.
Дада, их заменят прекрасные читабельные XMLки 4х разных местах
чтоб совсем как в OSX
> Дада, их заменят прекрасные читабельные XMLки 4х разных местах
> чтоб совсем как в OSXНет, формат конфигов будет совместим с библиотекой libucl, которая уже с 10-STABLE находится в базовой системе.
Если Вы следите за планами развития FreeBSD, то должны знать, что ведутся работы по переводу всех конфигурационных файлов в формат, совместимый с libucl.
> работы по переводу всех конфигурационных файлов в формат, совместимый с libucl.А как же совместимость с проприетарными патронами?!
>> работы по переводу всех конфигурационных файлов в формат, совместимый с libucl.
> А как же совместимость с проприетарными патронами?!А тут никого не волнует, с чем ваша бубунта не совместима ...
> Еще бы syslogd в него засунуть.Так там какие-то заявы про apple log. Бздюки не были бы бздюками если бы не подмахнули лишний раз кому-то из проприетарных "друзей".
Внезапно, выглядит очень годно
Название не очень удачное, имхо. Перекликается с NetBSD.
Я сначала как NetBSD и прочитал. Долго не мог понять, о чём новость.
Команда NetBSD должна в отместку выпустить дистр FreexBSD :D
>NextBSD AKA FreeBSD XЧот хихикаю. У ребят с фантазией совсем неахти
Next Generation FreeBSD?
Neon Genesis FreeBSDion
Neonius Genesium FreeBSDition
> Neon Genes FreeBSD ОБЧР-Editionfixed
>>NextBSD AKA FreeBSD XФрибздыкс это прекрасно.
Фотошопу на FreeBSD быть раньше че на линус
В треде работает снайпе
Кэндлджек тоже был зде
CS6, под вайном. Работает нормально, но мне привычнее гимп. Думаю, и на бзде он заработал примерно в то же время.
> Предлагаю создать проект RIPBSD.Routing Information Protocol в бздах уже давно есть.
Уберите упоминание OS X из новости. Оно ж действует на фанатиков как красная тряпка на быка.
Не беги на красную тряпку, анон. Сдерживайся.
Это как systemd под него Linux переделывали. Разработчики NetBSD не отставать от тенденции и тоже занялись коллективным созданием будущего.
Немножко критики launchd применительно ко FreBSD: http://blog.darknedgy.net/technology/2015/08/26/0/
> Немножко критики launchd применительно ко FreBSD: http://blog.darknedgy.net/technology/2015/08/26/0/В отличие от systemd, launchd будет делать сообщество, а не один человек. Поэтому, думаю, найдут компромиссное решение, как сделать новое лучше, не поломав старое.
этот один человек только в твитер херню постит, а потом называет напосченное документацией, а разрабатывают его работники редхета на ставке
> этот один человек только в твитер херню постит, а потом называет напосченное
> документацией, а разрабатывают его работники редхета на ставкеНу не знаю. По крайней мере я думаю, что разработчики провели большую работу, прежде чем объявлять что-то. Сначала обкатали libucl, libxo, libdispatch, а только теперь, на их основе, делают надстройку.
Надеюсь, что в сабже результат будет лучше чем в линуксе
> Надеюсь, что в сабже результат будет лучше чем в линуксеИ чем это сабжу поможет?
ничем, честно говоря
Где они их "обкатали"? На своих локалхостах? В астрале? Это, блджад, хипстероподелия из гитхабчика, которые до продакшена доберутся через несколько лет, если не сдохнут по дороге, что весьма вероятно.
> Где они их "обкатали"? На своих локалхостах? В астрале? Это, блджад, хипстероподелия
> из гитхабчика, которые до продакшена доберутся через несколько лет, если не
> сдохнут по дороге, что весьма вероятно.У Вас есть какие-то сведения об этом ?
Все вышеперечисленные библиотеки давно уже работают в продакшене на миллионах инсталляций.
Если Вас смущает цифра "миллион", воспользуйтесь google, для того, чтобы узнать, что это за библиотеки и где они применяются.
Вот нашел libucl у себя в продакшен FreeBSD 10.1 на ванильном ядре:
# uname -a
FreeBSD ...... 10.1-RELEASE-p10 FreeBSD 10.1-RELEASE-p10 #0:
# find /usr/lib -name libucl\* -type f
/usr/lib/private/libucl.so.1
/usr/lib/private/libucl.a
/usr/lib/private/libucl_p.a
libucl уже использует pkgng.
libxo открыли разработчики Juniper.
libdispatch разработан Apple и давненько используется приложениями для Mac OS X и iOS.
Вот и славно, тогда будет + в карму BSD
> В отличие от systemd, launchd будет делать сообщество, а не один человек.
> Поэтому, думаю, найдут компромиссное решение, как сделать новое лучше, не поломав старое.Такое явление у буржуев называется "Designed by comittee", прозрачно намекая на то что результат может запросто получиться гибридом танка, самолета и подводной лодки. На примере UFS vs generic слой журналирования отлично видно что можно убить массу времени с нулевым результатом.
давно смотрю на nosh. И надеюсь, что его все-таки заметят в BSD'ях.
> давно смотрю на nosh. И надеюсь, что его все-таки заметят в BSD'ях.Он таки используется в PC-BSD и даже были мысли использовать его, либо OpenRC во FreeBSD
> Немножко критики launchd применительно ко FreBSD: http://blog.darknedgy.net/technology/2015/08/26/0/так NextBSD - это не launchd на FreeBSD, люди хотят изменить FreeBSD так, чтобы она стала таким конструктором лего, из которого можно было бы слепить даже вариант для работы на смартфонах (и чтоб это был хороший, энергоэффективный вариант, который будет правильно работать с постоянно отключаемыми-включаемыми модулями (например, радио-), так и в постоянно меняющейся среде [изменился хостнейм, изменилась конфигурация сети и т.п.]).
В той статье автор прям в начале же говорит, что эта статья только про то, что не стоит тащить launchd во FreeBSD, а как ветка - пускай себе живёт, глядишь хороший proof of concept выйдет.
> так, чтобы она стала таким конструктором лего, из которого можно было
> бы слепить даже вариант для работы на смартфонахНу в общем они хотят Linux, с systemd. И чтоб зажимать можно было. Вот только в отличие от линуха - им никто драйвера для SoC не напишет.
> модулями (например, радио-), так и в постоянно меняющейся среде [изменился хостнейм,
> изменилась конфигурация сети и т.п.]).Это вы хотите нам рассказать зачем в линухе d-bus сделали и зачем когорта Поттеринга с sd-bus возится? И почему в ядро хотят включить kdbus? Ок!
еще один мертворожденный проект?
>еще один мертворожденный проект?капитан?
а НекстСтеп, Кокаинум, Кварц или хотя бы Вайленд там будут? Если нет - то не взлетит.
> а НекстСтеп, Кокаинум, Кварц или хотя бы Вайленд там будут? Если нет
> - то не взлетит.Wayland работает как бы, libinput еще надо портировать, чтобы наверняка, да.
Надо было линуксячье ядро брать.
И топить в ртуте.
> Надо было линуксячье ядро брать.надо было его писать не под вирусной лицензией (:
> надо было его писать не под вирусной лицензией (:Тогда из него вышел бы очередной недомерок по типу бойздэ, который стая корпоративных акул как обычно разодрала бы на куски. И зачем он такой был бы нужен?
Конфиги в JSON - стильно, модно, молодежно. Правда, там нет комментариев и неубираемый "нулевой" уровень вложенности, но это мелочи, да? Спасибо, что не XML.
> Конфиги в JSON - стильно, модно, молодежно. Правда, там нет комментариев и
> неубираемый "нулевой" уровень вложенности, но это мелочи, да? Спасибо, что не
> XML.Казалось бы, причём здесь libucl ...
И до BSD хипстеры добрались ...
>нового поколенияНе понятно, что в ней принципиально нового?
Шум бро, так все щас делают
>>нового поколения
> Не понятно, что в ней принципиально нового?нового для фрибсд :)
фрибсд застряла в том тысячелетии, а люди хотят её за уши притащить в это тысячелетие, вплоть до мобильников.
> Не понятно, что в ней принципиально нового?Ну как, передрали идеи из линуха и системды под бояздэлицензией.
как же не готовы установочные образы?
а это что? http://www.optimcloud.com/disc1.iso
Оно пока поломано.
я просто без комментариев приведу init-файл для launchd:<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
<key>Label</key>
<string>#{plist_name}</string>
<key>RunAtLoad</key>
<true/>
<key>KeepAlive</key>
<true/>
<key>ProgramArguments</key>
<array>
<string>#{opt_bin}/polipo</string>
</array>
<!-- Set `ulimit -n 20480`. The default OS X limit is 256, that's
not enough for Polipo (displays 'too many files open' errors).
It seems like you have no reason to lower this limit
(and unlikely will want to raise it). -->
<key>SoftResourceLimits</key>
<dict>
<key>NumberOfFiles</key>
<integer>20480</integer>
</dict>
</dict>
</plist>
зачем? сказать-то что хотели?
что новость не читал и осуждает, очевидно же :)
> зачем? сказать-то что хотели?Ну... попробуй сравнить с юнитом для системд. Для разнообразия ощущений.
Я тебя удивлю но plist отлично читаються и редактируються, и да если ты будешь вбивасать это все в nano или голом vi, то это неудобно, но прикрутив плагины к виму или посмотри как это выглядит в plistedit pro и ты сразу познаешь дзен про сравнению с юнитами от systemd
> отлично читаютьсяFAIL!
> и редактируються,
Срочно разыскивается рота граматеев-опричников!
> если ты будешь вбивасать это все в nano или голом vi,
> то это неудобно, но прикрутив плагины к виму или посмотри как
> это выглядит в plistedit pro и ты сразу познаешь дзен про
> сравнению с юнитами от systemdДзен состоит в том, что для того чтобы прописать сервис в запуск теперь требуется мега-IDE, за отдельные деньги? А может ну бы его нафиг такой дзынь? До такого маразма не допер даже Поттеринг. Не говоря о том что ini-style конфиги умеет подсвечивать любой уважающий себя "продвинутый редактор". А более ide-подобные типа geany - умеют и всякий там folding, только вот все это даром не упало в конфиге на 10 строк. Да-да, юнит системд можно накидать любым самым тривиальным текстовым редактором.
> Дзен состоит в том, что для того чтобы прописать сервис в запуск
> теперь требуется мега-IDE, за отдельные деньги? А может ну бы его
> нафиг такой дзынь?Новость не читай! Лучше сразу что-то с кем-то обсуждай!
Вместо древнего микроядра Mach можно было бы взять последнее поколение L4: seL4, OKL4, Nova, Fiasco.OS
> Вместо древнего микроядра Mach можно было бы взять последнее поколение L4: seL4,
> OKL4, Nova, Fiasco.OSА кто мешал предложить им это год назад? У них в идеях вовсе висит Solaris Doors.
if (stat("/AppleInternal", &sb) == 0 && stat("/var/db/disableAppleInternal", &sb) == -1) {
_launchctl_apple_internal = true;
}они так и будут тащить всё эпловское?:)
Они будут тащить хорошие зарекомендовавшие себя решения, которые можно утащить.На презентации об этом было открыто сказано и лично я не вижу ничего плохого в этом.
> Они будут тащить хорошие зарекомендовавшие себя решения, которые можно утащить.А хорошее это в смысле "удачно подмахнули эпплу"? :)
>пересоборать ядро и систему в конфигурации MACHTESTЭтот конфиг для виртуалок же, можно взять GENERIC и добавить строчку mach_load="YES" в файл /boot/loader.conf.
А так пока что все это дело глючит, падает и тормозит, в общем ждем стабильного релиза.
В реактосе стабильный релиз вон 17 лет ждут. Там, правда, фанаты виндов. Но у макосников нет никаих причин для того чтобы не повторить это достижение. Они же тоже будут развлекаться запуском на виртуалочке, а девелопать в макоси...
я сомневаюсь что FreeNAS и PC-BSD они будут в виртуалочке...
Еще вопрос, launchd в ответе за монтирование устройств и devd с libdevq идут на выброс?
> launchd в ответе за монтирование устройств и devd с libdevq идут на выброс?Они друг-другу не должны мешать. У devd задача - занимается приемом событий из ведра с последующей записью их в юзерлендный сокет. А кто в юзерленде будет их разгребать - ему фиолетово.
Это может быть сам devd (дергать скрипты после прохода регекспами по событиям). Может libdevq - выделять события по подключению мышей и скармливать их клиенту - x-серверу. Ничто не мешает launchd становиться еще одним обработчиком, сидящим поверх devd и слушающим сокет.
Пилили бы без оглядки на совместимость уже. Всё-равно тем, кому нужна классика, это вот не нужно. А так очередная "принципиально новая, нескучная" система-компропис между ежом и колючей проволкой...
