LINUX.ORG.RU

Разработчики FreeBSD планируют создать аналог systemd

 ,


2

2

На конференции MeetBSD California 2014 основатель FreeBSD (и, по совместительству, разработчик системы портов) обрисовал планы проекта на ближайшее десятилетие, в том числе:

  • создание унифицированного интерфейса для конфигурирования системы и всех сервисов
  • разработка централизованной системы уведомлений о событиях
  • улучшение механизма запуска сервисов и разрешения их конфликтов

Особое внимание привлекает последний пункт. Предполагается полностью переделать /etc/rc.d, чтобы он обрёл возможности управления сервисами наподобие того, как это реализовано в systemd.

Леннарт Поттеринг, создатель systemd, положительно отозвался о презентации.

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

anonymous

Проверено: maxcom ()

Ответ на: комментарий от i1atf

Кто не взлетел? Ты в глаза что ли долбишься? Или под мажорными дистрами ты подразумеваешь слаку?

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

Он срёт либо в syslog, либо в файл, либо в консоль. Всё. И это нормально. Если я хочу в консоль, то я не хочу, чтобы systemd это перехватил, не так ли?

Если ты хочешь, что бы демон срал в консоль, то либо ты его запускаешь с консоли (тогда сисдемд тут вообще параллелен) либо ты запускаешь демон из системд так: my-daemon-name >> /var/log/my-daemon-name.log 2> /var/log/my-daemon-name.err
В таком случае, с точки зрения системд - в stdout/stderr пусто. И системд ничего не перехватывает.

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

Ну, как девелопер, ты можешь в файл и так писать. А вот по поводу консоли интересно - если ты девелопер, то стоило бы задуматься о том, как опсы будут читать твой выхлоп, если ты опс - то должен понимать, что толку от таких логов чуть более, чем нифига. Впрочем, journald может и в консоль все форвардить (правда, емнип, без селекта по демонам).

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

По скорости как раз сопоставимо будет. В конкретную защиту от модификаций ткни.

Первое ... достигается не только за счет уменьшения размера

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

сколько за счет индексации. Которая кривореализуема

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

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от cab

В конкретную защиту от модификаций ткни.

некорректно выразился, скорее не защита, а верификация.

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

А ты в курсе, например, что на hdd с initrd упакованным в xz система грузится быстрее, чем с gz? =) (На ssd, увы, разницу не видел.) Понимаешь, да к чему я клоню?

плейнтекст чудесно индексируется (собственно индексом на чтение у тебя будет время записи), а так она небесплатна и тебе придется расплачиваться временем записи по сравнению с плейн-текстом.

Я возможно скажу херню, но текстовая индексация будет дороже по ресурсам, разве нет? Я не знаю, мб на P2+128M будет видно, но на конфигурации лайк допотопная целка + 1024M тормозов на записи (включая потерю логов при экстренной перезагрузке) не видел. Хотя, конечно, моя выборка нерепрезентативна

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

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

Процы всегда быстрее дискового IO. Все тормоза начинаются при нехватки оперативки и, как следствие, своппинга на жесткий диск.

И если ты уперся в производительность проца, то те копейки, которые добавляются journald не сделают погоды. На фоне драйвера фс, к примеру.

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

Бинарник что бы все это разбирать. Иначе нафига вам мусор в тексте?

A-234 ★★★★★ ()
Ответ на: комментарий от Alsvartr

Бред у вас, и даже не предлагайте мне то что вы там юзаете.

A-234 ★★★★★ ()
Ответ на: комментарий от arcanis

Какие препятствия для верификации создает плейнтекстовый формат?

А ты в курсе, например, что на hdd с initrd упакованным в xz система грузится быстрее, чем с gz?

а степень сжатия какая?

Я возможно скажу херню, но текстовая индексация будет дороже по ресурсам, разве нет?

В каком именно случае?

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 2)
Ответ на: комментарий от cab

Бинарный лог - мелочи и ерунда. Так как systemd универсальная пускалка всего, то разумно иметь общий конфиг на всё, бинарный, чтобы исключить возможность подмены к примеру. Ну и вывод в консоль тоже устарел - графический режим давно не самая жручая часть системы, а читабельность у него выше

frost_ii ★★★★★ ()
Последнее исправление: frost_ii (всего исправлений: 1)
Ответ на: комментарий от kir2yar

Все тормоза начинаются при нехватки оперативки и, как следствие, своппинга на жесткий диск.

тормоза из-за IO вообще предсказуемая ситуация. Так нахрена увеличивать время записи в такой ситуации?

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

Бинарный лог - мелочи и ерунда. Так как systemd универсальная пускалка всего

Обсуждать это у меня времени не хватит.

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

тормоза из-за IO вообще предсказуемая ситуация. Так нахрена увеличивать время записи в такой ситуации?

Эм. Где там время записи увеличивается? Что в бинарнике одна строчка за одну операцию диска запишется, что в текстовом. Оно-ведь, по любому меньше размера сектора и/или буфера.

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

А индексы и прочую служебную информацию считать и писать не надо?

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

А индексы и прочую служебную информацию считать и писать не надо?

Что быстрее запишется на жесткий диск? 100байт или 200байт?
Будем надеяться, что тебе известно, хотя бы в общих чертах, как вообще происходит запись на блочные устройства.

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

Надеюсь тебе знакомы проседания по перфомансу при insert в индексируемые таблицы?

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

Строго говоря, вопрос нетривиальный. Но, учитывая, что используется вежливый и правоверный mmap и держится совсем немного открытых лог файлов (2 в нормальном режиме с одной пользовательской сессией) против десятка в который пишет syslog, даже с учетом fsync journald выигрыш запросто может быть на его стороне.

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

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

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

Пройдёт время и найдётся. Теперь это только вопрос времени, и думаю, что весьма небольшого

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

Руководитель и основатель systemd неоднократно и демонстративно объявляет, что это система инициализации работающая быстрее sysV

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

А стандартный вариант с syslog + logrotate требует не забыть реализовать какой-нибудь endpoint в приложении для ротации (например, trap SIGHUP'а).

syslog как раз и нужен, чтобы в приложении не реализовывать SIGHUP.

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

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

10 страниц уже топику. Они че реально собрались портировать systemd не пойму

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

Надеюсь тебе знакомы проседания по перфомансу при insert в индексируемые таблицы?

sdшный лог растет только в длину. Те, там запись только в конец файла. Плюс - он индексируется при чтении, если мне память не изменяет.

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

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

То-же самое говорят и создатели OpenSSH. Что не мешает существованию кросплатформенной ветки OpenSSH.

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

Ну, я и не спорю про нетривиальность.
ИМХО, если вашей системе мешают логи в плане производительности - логируйте на удаленный компьютер.

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

ИМХО, если вашему танцору мешают

fixed

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

Он превращает твои демоны в поделку для одной ОС.

А ты думал в сказку попал где разработчики будут выполнять капризы каждого недоумка? Закинь ему бабла - с почасовой оплатой наверняка поддержка любой ОС появится. Но ты ж ведь нищеброд и жлоб - ты ж удавишься скорее, чем хоть 5 рублей пожертвуешь, и при этом свято уверен, что все вокруг тебе должны обеспечивать и поддерживать твои полумёртые ОС за свой счёт. Как только ещё задницу сам подтирать умудряешься...

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

Линукс с этим справляется на нормальном уровне. Хуже, но не настолько, что бы приходилось чесаться.

Ой заврался... неужто от бздунов этой дряни подцепил? Ты с ними аккуратнее, кто подолгу с мертвечиной возится сам пахнут начинает ;-)

В GNU/Linux что сетевой стек и связанные с ним утилиты, что контейнеризация на десятилетия опережают бздю. Где хотя-бы какой-то аналог CRIU?

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

И подбирать платформу под задачу, а не извращать задачу под платформу.

Тебе тупому уже вторую страницу подряд пытаются объяснить, что сейчас просто нет технических задач, под которые можно выбрать бздю. Куда ни ткнись - везде GNU/Linux либо сравним (что редкость), либо значительно превосходит бздю. Есть единственная задача, где бздя заруливает - задача проприетарщикам закрывать чужой код. Собственно, это и есть единственна причина, по которой бздя не загнулась окончательно, несмотря на впечатляющее техническое отставание от линукса. Но это не техническое «преимущество».

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

А то я вижу...

С какого перепугу ты решил, что посторонние люди могут трактовать твои галлюцинации? Ты ведь в поддержку своего бреда ни единой ссылки не привёл. Одно слово - бздун.

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

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

Ради такого проекта, который изначально не задумывается, как многоплатформенный ? Разумеется.

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

Где он взлетел то? Его в мажорных дистрах толком ещё не запилили.

О, ещё один примороженный... иди погрейся, после криокамеры всегда тупишь поначалу :-D

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

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

В конкретную защиту от модификаций ткни.

Сам гугли secure forward sealing - я по понедельникам интеллектуально-необеспеченным милостыни не подаю.

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

Ради такого проекта, который изначально не задумывается, как многоплатформенный ? Разумеется.

Дык какие претензии тогда? Соси молча, что серьёзные люди позволяют.

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

Сказал пустоголовый ссыкуль, который что в линуксе, что в bsd - ни рыбы, ни мяса...

alex-w ★★★★★ ()
Последнее исправление: alex-w (всего исправлений: 2)
Ответ на: комментарий от anonymous

Соси молча, что серьёзные люди позволяют.

Пока удаётся воздержаться.

AS ★★★★★ ()
Ответ на: комментарий от alex-w

Сказал пустоголовый ссыкуль, который что в линуксе, что в bsd - ни рыбы, ни мяса...

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

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

Даже если таблица растет только в длину индексирование чой-то там жрет. Для файрберда 1 индекс садит производительность insert примерно на 3-5% в однопользовательском режиме без интенсивного IO.

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

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

Да нет, пустоголовый ссыкуль это ты, дорогой анонимус. К тому же у тебя непомерное самомнение с замашками на гениальность. Не расскажешь ли (используя полностью ваш стиль наездов), если линукс такой весь из себя продвинутый и хороший... где этот линукс на десктопах? Расскажи, как без плясок с бубном можно развернуть на твоем горячё обожаемом линуксе (ты его вообще видел ли, чудо ты наше перпендикулярновселенское?) полноценное АРМ в гетерогенной среде? Пойдем дальше, ответь ка мне, Великий Админ Локалхоста, если FreeBSD такая плохая и ни к чему не пригодная, то почему тогда такие крупные игроки как Yahoo! и Hotmail совершенно с Вашем Админством не согласны и используют целые кластеры на FreeBSD? Будут ли какие-то технически аргументированные заявления или будут традиционные отсасывания и испражнения со твоей стороны?

alex-w ★★★★★ ()
Ответ на: комментарий от cab

Только в логах не sql а тупо дописывается запись в конец файла.
ИМХО, даже если и есть просадка она компенсируется возможностью сделать так: journalctl -u httpd --since="-4d" --until="-3d"
Как мне это получить из обычных файлов?

kir2yar ()
Ответ на: комментарий от alex-w

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

линукса на десктопах всяко больше, чем бсд

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

И так. На данный момент фрибсдшные ученые нашли фряховское ядро в:
Apple osx, cisco ios, hotmail, playstation4, yahoo!.
Детальная проверка выявила:
Apple osx - darvin
cisco ios старая - самописный монолит без разделения памяти.
cisco ios xr - qnx
hotmail - винда
playstation 4 - модифицированная фряха с закрытыми исходниками.
yahoo! - по состоянию на 2011год - 75%линукс остальное фряха.

Может перестанете врать и подтасовывать факты, которые легко проверяются гуглом?

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

Только в логах не sql

Индексам пофиг на sql. Эта особенность индексов известна еще с не sql-ных баз данных,где " запись тупо дописывается запись в конец файла".

Как мне это получить из обычных файлов?

В общем случае - регекспами. А так тот же journalctl не стал бы хуже от того, что под капотом плейнтекст. По трудозатратам и перфомансу было бы сопоставимо, по надежности работы (ведь по-любому плейнтекст надежней хоть бинаря, хоть и надежного). И гибче, если надо непредсказуемым образом анализировать лог, что тоже очень частая задача.

cab ★★★★ ()
Последнее исправление: cab (всего исправлений: 1)
Ответ на: комментарий от cab

Тебе уж даже формат в деталях разобрали, тесты привели,а ты всё тупишь по поводу тобой же придуманных «ненадёжности» и «тормознутости». Ну нельзя до такой-то степени тормозом быть! Сходи документацию почитай и хоть какой-нить завалящий эксперимент сделай. От того, что ты свою глупость ещё 10 раз повторишь она глупостью быть не перестанет, а вот ты так и будешь выглядеть идиотом.

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

Не звизди, формат в деталях никто не разбирал, только ссылку дали.

тупишь по поводу тобой же придуманных «ненадёжности» и «тормознутости»

Ты отрицаешь очевидное: плейнтекст проще, соответственно надежнее; его генерировать проще, значит быстрей запишется лог; не надо извлекать из базы - значит анализировать можно любыми показавшимися мне удобными средствами и получу его быстрее.
Выше, кстати, были ссылки на проблемы с бинарным логом. Эти-то пофиксили, другие могут вылезти.

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

У меня таких экспериментов было с другими бинарями далеко не один.

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

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

ведь по-любому плейнтекст надежней хоть бинаря

Феерический бред. Или ты можешь предоставить нормально, логически разжеванный пруф, не на уровне пожилая бабка так сказала?
Удачи в чтении регэкспа, в случае развала ФС.
А хекс-редактором я и из системд-логов могу строчки тягать.
Плейнтекст - не панацея.

Я уж молчу про то, что системд время от времени ставит в логи спец-метки, задача которых защитить от изменения записи. К примеру, если в плейнтексте пару строчек удалить - никто ничего не заметит. В системд-логе такой трюк не удастся.
Вообще вот, почитай: http://www.freedesktop.org/wiki/Software/systemd/journal-files/

Там реально столько инфы хранится, что если хранить ее плейнтекстом то один фиг получится нечитабельный плейнтекст на вроде xml. Потому - решили таки отказаться от идеи плейнтекста

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