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

Какие?

инитскрипты писать проще

И поддерживать под 10 дистров их тоже проще.

И таки, может ты почитаешь формат записей? Там толком и ломаться-то нечему.

Так нахрена было делать его в таком случае не плейнтекстовым? journalctl вполне можно сделать на основе плейнтекста при тех же трудозатратах?

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

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

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

В своё время занимался нечто подобным. Плюс тут на ЛОРе кто-то хотел такое запилить (я ещё давал какие-то рекомендации). Коротко: проблема курицы и яйца. С технической точки зрения проблемы нет, т.к. в этом вопросе все более-менее стандартизировано: INI, json, yaml, XML, etc. Что получится (и что нужно сделать): монстр, который умеет читать, парсить и генерировать файлы в этих форматах. Успехов ребятам, надеюсь сделают либой под MIT/BSD лицензией, чтобы можно было портировать её куда угодно (по большей части embedded).

разработка централизованной системы уведомлений о событиях

Тоже полезно, хотя работы там дофига. Успехов.

улучшение механизма запуска сервисов и разрешения их конфликтов

Хорошо, что есть свои мысли на этот счёт, без тупого клонирования/костыляния systemd. Посмотрим, что выйдет. И ещё раз, успехов.

Я же говорил, что они потратят 1 000 000$ с пользой.

Да вообще-то бинарь проще парсить в автоматическом режиме.

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

они уже свалили с винды. многие свалили с убунты. твоё мнение ошибочно.

большинство из них можно проиграть частями

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

Вот до чего ненависть к systemd доводит. Назло маме отморожу уши.

Там свои плюшки, ага.

может что-то путное выйдет. а systemd закопают — первый блин комом.

Зачем создавать аналог, если уже есть оригинал? Лицензия и религия?

Родное сердце, ты прям как будто впервые про бздунов услышал :)

Само собой - «лицензия и религия!» это практически их неофициальный девиз. Вполне в духе «слабоумие и отвага» :-D

А если серьёзно, то чуваки, которые «платят и танцуют» бздунов делают это исключительно из-за идиосинкразии на GPL, которая не позволяет закрывать (чужой) код. Возможность проприетарщикам невозбранно закрывать код это единственная причина, гальванизирующая трупы *BSD - всё остальное это сказки для умственно-отсталых детей.

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

С точки зрения взломщика - 100% стала лучше.

изза этого говна закапывают реализации получше, тот же апстарт.

Это ты верно подметил, говна в апстарте много, потому он и пахнуть начал раньше, чем сдох.

s/BSD-шники так не сделают/BSD-шники не сделают/

fixed.

ато эти угрожающие возглосы «я уйду от вас на FreeBSD» — меня уже почти начали нервировать :-)

Говорят, во время презентации бздунов сейсмологи зафиксировали толчок силой 3,14 баллов по шкале Рихтера в результате синхронной детонации пердаков массы systemd-хейтеров. Полиция ищет тело (или то, что от него осталось) Яна Джексона после сообщения о взрыве сило 1,5 калотонны в подвале его дома, страным образом совпавшее с вышеупомянутой презентацией.

В воздухе слышится запах OpenBSD

Тонко, но справедливо :)

Лям-катализатор.

Круто, чё. Может, внезапно, сделают что-нибудь человеческое, а не клон systemd.

Я уже высказывал свое мнение, выскажу еще раз

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

Недостатки systemd - объективны.
I-Love-Microsoft

Get the facts.

Я попытался, а потом начал копировать файл. Оказалось что при копировании файла я с трудом могу запустить что-либо с диска. Даже браузер не запустился ЛОР почитать.

Слез.

Основные претензии с моей стороны, что это монолит и бинарный лог.

ды чёрт-возьми! что же за высосанная из пальца проблема? :-)

systemctl enable rsyslog
systemctl start rsyslog

...и наслаждайся текстовыми логами :-)

это монолит

там не монолит.

systemd — это набор слабосвязанных утилит

Почитай, там достаточно хорошо все разжевано.

Я это уже читал. Ты все равно поимеешь больше потерянной информации, чем с плейнтекста. А ломаться есть чему, по крайней мере гугл по запросу «journald corruption» выдает много ссылок. Лор тоже нашел Битые логи с systemd-journald

С точки зрения взломщика - 100% стала лучше.

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

против взломщиков есть специальные инструменты.

ситуацию когда посыпался лог?

это как понять «посыпался лог» ? почему он должен посыпаться?

P.S.: возможно с GNU/Hurd будет больше желаний чем в FreeBSD.

У кого? У полутора разработчиков, финансируемых с помощью милостыни, и одного стуента на гугловсие бабки раз в пару лет? Желания мало - нужна возможность делать, а для этого нужно бабло, которое без реализованных возможностей не дадут. Замкнутый круг, перекошенная харя капитализма, вот это всё :(

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

Я тоже знаю, что именно нужно делать для победы над раком и колонизации Марса. И меня тоже, как это ни странно, забыли спросить.

надеюсь сделают либой под MIT/BSD лицензией, чтобы можно было портировать её куда угодно

Сразу видно идиота. Это видимо из-за «непортируемости» GPL GNU/Linux давно обогнал все бзди вместе взятые по количеству поддерживаемых архитектур.

systemctl enable rsyslog

Я знаю, и рассматриваю как вариант. Однако при этом syslog будет работать поверх systemd. Отсюда потенциальная потеря данных в случае сбоя systemd.

systemd — это набор слабосвязанных утилит

Если бы это был набор слабосвязанных утилит, то я бы сделал apt-get remove --purge journald; apt-get install rsyslog и был бы не в претензии.

Что вы так фапаете на эту cgroups?

Тебя в детстве линуксоиды обидели?

В винде этой фиче 15 лет - никто не пользовался.

А в systemd сего помощью разделяются группы процессов сервисов, поэтому без этой фичи systemd превращается в еще-один-обычный-init.

И да, раз ты специалист - чем он вообще хорош, этот мутный dbus?

По мне - так он почти всем плох, но именно его использует большинство.

systemd монолитен настолько же, насколько монолитно ядро Linux

apt-get remove --purge

Дикарь!

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

Ежики плакали, кололись но продолжали грызть кактус

По мне - так он почти всем плох, но именно его использует большинство.

А какие в Линуксе альтернативы для работы с pluggable-устройствами?

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

Так настрой его отдельно.

А системные логи должны быть бинарными с защитой от подмены.

> systemd — это набор слабосвязанных утилит

Если бы это был набор слабосвязанных утилит, то я бы сделал apt-get remove --purge journald; apt-get install rsyslog и был бы не в претензии.

сделай sudo rm /usr/bin/journalctl и наслаждайся :)

раз уж ты такой извращениц

при этом syslog будет работать поверх systemd. Отсюда потенциальная потеря данных в случае сбоя systemd.

и по какой же причине systemd должен сбойнуть?

syslog будет работать поверх systemd

не поверх systemd, а брать данные у systemd.

и это логично, так как systemd запускает демоны, и берёт у них stderr-каналы.

И да, предоставь нам уже доказательсьва немодульности systemd.

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

монолитно ядро Linux

1) это не повод плодить монолитности

2) там это оправдано, иначе писать очень сложно и к тому же очень неэффективно с точки зрения производительности

Могли бы просто попросить launchd у Apple под BSD-лицензией.

Эм. Минимальный комплект поствки s-d состоит из s-d, удава и журнала. Бинарный лог, который не викинуть - мы уже обсуждали. Либо у вас есть отдельный лог-сервер, либо по факту вам насрать на целостность и адекватность логов. Вне зависимость от того, в каком типе файлов вы храните эти логи.
Почему? При резком перезапуске сервера последние записи могут не попасть на жесткий диск (что в текстовом логе, что в бинарном). Хакер, поимемвший систему, может отредактировать лог (текстовый запросто, бинарный сложнее), сдохшая ФС одинаково хорошо убивает и текстовые логи и бинарные.
Если вас и правда волнуют логи - вы храните их на отдельной машине. Если не волнуют - то вы просто кукарекаете по поводу бинарных логов.
Куча вещей - таки можно эту кучу обрезать до запуска и инициализации сервисов. Но эта куча вещей часто оказывается нужна. Особенно в нестандартных ситуациях.
Жырный размер... По факту он меньше чем init + busybox | (bash + grep + awk)

Так настрой его отдельно.

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

не поверх systemd, а брать данные у systemd.

не в лоб, так по лбу

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

Насчет ынтэрпрайза :)

Очевидно, имелось ввиду рабочая система. А не разработка.

А что не так с systemd?