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

регэкспа - плейнтекста.

если в плейнтексте пару строчек удалить - никто ничего не заметит.

если не задастся целью.

В системд-логе такой трюк не удастся.

удастся, обсуждали с intelfx'ом.

Там реально столько инфы хранится

эт да, больше весят, оверхэд на этапах шифровки/расшифровки лога.

удастся, обсуждали с intelfx'ом.

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

Реально надежно хранить логи можно только на удаленном компьютере. Это уже обсуждалось.

эт да, больше весят, оверхэд на этапах шифровки/расшифровки лога.

Тут кде тянет за собой sql-сервер, а вы о разнице в пол килобайта печетесь.
Если ваша машина настолько слаба, что на нее влияет оферхэд от логов - сомневаюсь, что ее можно использовать как сервер. Да и как десктоп.
Может ты мне пришлешь ссылку на бенчмарк системд лога?

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

приведи пример.

Реально надежно хранить логи можно только на удаленном компьютере. Это уже обсуждалось.

разумеется. вот и пришли к тому, с чего всё начиналось: нахрена козе баян?

Тут кде тянет за собой sql-сервер, а вы о разнице в пол килобайта печетесь.

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

Может ты мне пришлешь ссылку на бенчмарк системд лога?

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

но эмпирический тест: ты берёшь, шифруешь лог, расшифровываешь, а я ничего не делаю, и у тебя больше времени это занимает чем у меня, не так ли?

Естественно, так, но причем здесь systemd? Он шифрует логи?

говори уже, не тяни :-P

приведи пример.

Жесткий перезапуск без fsync?

разумеется. вот и пришли к тому, с чего всё начиналось: нахрена козе баян?

Блин, давал-же ссылку на то, какая инфа хранится в логах. Многое из этого реально нужно. И если все это впихнуть в плейнтекст - то у тебя получится очень жирный, нечитабельный плейнтекст с парсерами, которые на каждый чих будут течь памятью. Вспомни xml - как раз такого рода плейнтекст. До сих пор уязвимости в парсерах находят.
И только не надо нытья по типу: «Деды в плейнтексте были, и мы будем.» Деды, на каком-то этапе и лучиной комнату освещали.

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

Вот как раз в плане шифрования ты в лужу сел. Вот:
http://www.thg.ru/cpu/aes_clarkdale/
Там про интель, но по факту, уже где только нет аппаратного крипто.
При аппаратном шифровании/дешифровании разница по скорости будет нулевая.
Это один из примеров.

говори уже, не тяни :-P

Нет, это ты говори, какое отношение предложенный тобой тест имеет к systemd.

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

В Оренбург гугль завезли? Ведь еще вчера ты им пользоваться совершенно не умел. Интересно, ты по глупости своей приписал мне то, чего я не говорил или просто пытаешься выглядеть умным за чужой счёт? Я даже оказался в некотором замешательстве после прочтения твоих опусов - ты вообще в курсе что такое операционная система и из чего она состоит, что такое ядро в частности?

почему тогда такие крупные игроки как Yahoo! и Hotmail совершенно с Вашем Админством не согласны и используют целые кластеры на FreeBSD?

Это ты это-чтоль не говорил?

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

Жесткий перезапуск без fsync?

https://bugzilla.redhat.com/show_bug.cgi?id=1057883

И если все это впихнуть в плейнтекст - то у тебя получится очень жирный, нечитабельный плейнтекст

читабельнее во много раз чем бинарь, или сравнивать уже будем не сам формат, а утилиты?

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

системде претендует на безбажность? :-D

Деды, на каком-то этапе и лучиной комнату освещали.

прогресс гойловного моска?

Вот как раз в плане шифрования ты в лужу сел. Вот:

http://www.thg.ru/cpu/aes_clarkdale/

nehalem... спасибо, поржаль) и это для фичи которая бесполезна на практике.

nehalem... спасибо, поржаль) и это для фичи которая бесполезна на практике.

Таки системд не шифрует логи. Максимум хеши делает.

системде претендует на безбажность? :-D

Таки да. Стабильные ветки более чем стабилны. Или ты сейчас будешь рассказывать про жирный PID1?

читабельнее во много раз чем бинарь, или сравнивать уже будем не сам формат, а утилиты?

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

Таки системд не шифрует логи. Максимум хеши делает.

шифрует, хэширует, когда надо при№%@ться...

Таки да.

таки видали, да.

Или ты сейчас будешь рассказывать про жирный PID1?

я скинул ссылку на багзиллу, лучший рассказчик.

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

а у меня еще проще: брать инфу, не пользуясь для этого многообещающим, но неработающим костылём ака системде.

я скинул ссылку на багзиллу, лучший рассказчик.

Баги в багзиле системд - это хорошо. Оно-же пока в разработке.
Кроме того, куда валятся баги в init-скриптах? В отдельные багзилы дистров?
Когда убунтовский апстарт тормозил загрузку системы на полторы минуты, если в сети нет dhcp. Забавно, да?
Или когда были баги в инит-скрипте sshd генты? https://bugs.gentoo.org/show_bug.cgi?id=89684

Каждый чинит свой велик. Своим способом. Не подходящим больше никому. Багрепорты размазаны по всему интернету.
Нет уж. Пусть все чинят в одном месте, а не как сейчас.

а у меня еще проще: брать инфу, не пользуясь для этого многообещающим, но неработающим костылём ака системде.

Не работающий? Таки работает. В редхате, федоре, дебиане.
Костыль? Системд, наоборот, выбросило кучу ваших любимых костылей.
Что вообще такое инит-скрипт? Это костыль, который используются из-за того, что система инициализации вообще не может самостоятельно правильным способом запустить демона. Поэтому ей нужна подпорка в виде простыни на башатине.

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

1) Я нигде не говорил, что journalctl не нужен. Я говорил, что его сделать не на бинарной основе вполне возможно. Существование анализаторов syslog это подтверждает.
2) таки grep -E '^Oct (2[0-9]|30) ' /var/log/syslog прямо таки непосильная задача для админа.

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

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

Удачи в чтении регэкспа, в случае развала ФС.

В случае текстового лога есть 3 сценария его потери: поломка железа, поломка ФС, удаление лога. В случае бинарного лога к этим добавляются еще потенциальные ошибки, связанные с некорректной интерпретацией бинаря.

В системд-логе такой трюк не удастся.

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

Там реально столько инфы хранится, что если хранить ее плейнтекстом то один фиг

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

2) таки grep -E '^Oct (2[0-9]|30) ' /var/log/syslog прямо таки непосильная задача для админа.

Логи разбросаны по разным файлам и некоторые пожаты gz.
Иногда нужна немного более сложная выборка.

Какой бы он надежный ни был есть ряд сценариев, при которых утилита не сможет корректно обработать свой же файл.

В таком случае, можно и воспользоваться strings {лог-файл} | grep «message=» и будет тебе счастье. Вообще - это решение уже раз 20 тут написали.

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

И какой логпарсер идет из коробки в большинстве дистров?
Я сам использую грейлог2 и заббикс. Но от изкоробочного решения я не откажусь.

Нужно больше клонов венды!

Иногда нужна немного более сложная выборка.

Будем решать проблемы по мере их поступления.

В таком случае, можно и воспользоваться strings

и получим мусор в виде служебной информации. И тут еще пара проблем может быть:
- если запортилось служебное поле, выдаст ли journactl сам лог?
- мы можем не узнать, что у нас битый лог и не воспользоваться strings?

И какой логпарсер идет из коробки в большинстве дистров?

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

и получим мусор в виде служебной информации. И тут еще пара проблем может быть:

И чем этот мусор меня должен напугать? С учетом того, что он отрезается тем-же грепом.

- если запортилось служебное поле, выдаст ли journactl сам лог?

Да, весь лог, кроме той записи, чье поле запоролась.

- мы можем не узнать, что у нас битый лог и не воспользоваться strings?

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

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

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

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

А вот то, что systemd реально взялся и начал унифицировать кучу вещей, которая традиционно в каждом дистрибутиве решалась через свою жопу...
Рассматривайте systemd как кару за велосипедосексуализм.
Примитивная задача «на каком я дистре запущен», для автора программы превращается в геморой.
http://www.computerhope.com/issues/ch001106.htm
Те, простая вещь, вроде информации о дистрибутиве и его версии может находиться где угодно.
Имя компьютера? http://forum.sources.ru/index.php?showtopic=47828
Или линукс весь за свободу выбора в каком фале хранить имя и версию дистрибутива?
И так в каждой мелкой ситуации.
Это - жопа.

И чем этот мусор меня должен напугать?

Тем, что grep еще надо научить правильно отсеивать мусор от лога

И читаешь их не грепом

Я его анализирую грепом и прочим шеллом.

Если у тебя десктоп

Если у меня десктоп, то я запущу ksystemlog

А вот то, что systemd реально взялся и начал унифицировать кучу вещей, которая традиционно в каждом дистрибутиве решалась через свою жопу... Или линукс весь за свободу выбора в каком фале хранить имя и версию дистрибутива?

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

Рассматривайте systemd как кару за велосипедосексуализм.

Рассматривайте linux как кару за велосипедосексуализм, ведь есть винда.

Тем, что grep еще надо научить правильно отсеивать мусор от лога

# strings /var/log/system.journal | grep -i «message=» | head -5
MESSAGE=Runtime journal is using 6.2M (max allowed 49.7M, trying to leave 74.5M free of 490.7M available
MESSAGE=Initializing cgroup subsys cpuset
MESSAGE=Initializing cgroup subsys cpu
MESSAGE=Initializing cgroup subsys cpuacct
MESSAGE=Linux version 3.17.4-200.fc20.x86_64 (mockbuild@bkernel02.phx2.fedoraproject.org) (gcc version 4.8.3 20140911 (Red Hat 4.8.3-7) (GCC) ) #1 SMP Fri Nov 21 23:26:41 UTC 2014
Много мусора?

Я его анализирую грепом и прочим шеллом.

Огак. Самое разумное и доброе, что можно сделать - текстовый анализ написанный на bash! Это великолепно!
Нахрен все эти велосипеды, когда journalctl умеет все тоже, но лучше.

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

Ога. И для решения этих задач, первым делом нужно начать писать версию дистра в другой файл. И ломать gethostname().
Самому не смешно?

Рассматривайте linux как кару за велосипедосексуализм, ведь есть винда.

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

$ sudo journalctl -n 10
-- Logs begin at Чт 2014-10-09 15:03:22 YEKT, end at Ср 2014-12-03 16:29:10 YEKT. --
дек 03 16:27:56 localhost.localdomain systemd[1]: Starting Fingerprint Authentication Daemon...
дек 03 16:27:56 localhost.localdomain systemd[1]: Started Fingerprint Authentication Daemon.
дек 03 16:27:56 localhost.localdomain fprintd[3022]: Launching FprintObject
дек 03 16:27:56 localhost.localdomain fprintd[3022]: ** Message: D-Bus service launched with name: net.reactivated.Fprint
дек 03 16:27:56 localhost.localdomain fprintd[3022]: ** Message: entering main loop
дек 03 16:27:57 localhost.localdomain sudo[3020]: yar : TTY=pts/2 ; PWD=/var/log/journal/552225b7ce994686871d9958c5da0ec0 ; USER=root ; COMMAND=/bin/journalctl
дек 03 16:28:05 localhost.localdomain sudo[3028]: yar : TTY=pts/2 ; PWD=/var/log/journal/552225b7ce994686871d9958c5da0ec0 ; USER=root ; COMMAND=/bin/journalctl
дек 03 16:28:26 localhost.localdomain fprintd[3022]: ** Message: No devices in use, exit
дек 03 16:28:42 localhost.localdomain sudo[3066]: yar : TTY=pts/2 ; PWD=/var/log/journal/552225b7ce994686871d9958c5da0ec0 ; USER=root ; COMMAND=/bin/journalctl -n 10
дек 03 16:29:10 localhost.localdomain sudo[3069]: yar : TTY=pts/2 ; PWD=/var/log/journal/552225b7ce994686871d9958c5da0ec0 ; USER=root ; COMMAND=/bin/journalctl -n 10

Хоть загрепайся. Видишь, даже о динозаврах подумали.

текстовый анализ написанный на bash! Это великолепно!

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

Этакий уголочек илитариев,

Лично мне элитарность пофиг. А вот юникс-вей таки да, работу сильно упрощает.

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

Ну, как-бы писать это на баше - тот еще изврат. Реально адский изврат.
Что у питона, что у перла, что у сотни других языков есть нормальные и красивые функции по работе с текстом. Их легче отлаживать. Они быстрее работают, чем вязанка пайпов. И больше возможностей дают в конечном итоге.
А вообще, кто мешает сделать тебе что-то вроде:
journalctl --unit={юнит, за которым ты наблюдаешь} --since {дата} --until {дата} | ./bash_script.sh
Или journalctl --unit={юнит, за которым ты наблюдаешь} --since {дата} --until {дата} | ./python_script.py
Вполне скриптабельная тулза.

$ journalctl -u NetworkManager.service --since="-2h"
Выдаст плейнтекстом все, что творилось с нетворкманагером за последние два часа.
В плане скриптописания, подобные фильтры позволяют резко уменьшить объем инфы, которую должны лопатить скрипты.
К, примеру, в традиционном журнале, ты скриптами будешь лопатить все, начиная с прошлой ротации логов. А тут ты можешь задать временные рамки, ограничиться последней загрузкой, ограничиться каким-либо отдельным юнитом...

$ journalctl _SYSTEMD_UNIT=gdm.service выдаст все, что творилось с gdm.
Причем на каждом слове есть интеграция с bash_completion.
Написал journalctl, нажал таб, увидел поля, по которым можно филтровать. Выбрал поле, нажал таб, увидел параметры. К примеру, после _SYSTEMD_UNIT=, я увидел все возможные юниты.

Удобно.

Теперь по поводу «оно бинарное!» Вот выхлоп на одну запись. Будь ласков, упакуй мне это в ЧИТАБЕЛЬНЫЙ текстовый формат. Хранить метаданные отдельно - не предлагать. Ибо оно уже реализовано. Системд по умолчанию пишет и текстовые логи. Так-что к сдшным бинарникам можно относиться как к метаданным.

journalctl -o verbose -n 1

-- Logs begin at Чт 2014-10-09 15:03:22 YEKT, end at Ср 2014-12-03 17:42:06 YEKT. --
Ср 2014-12-03 17:42:06.530956 YEKT
PRIORITY=6
_UID=0
_GID=0
_BOOT_ID=7a699778079d46bba0abe1c3285aef47
_MACHINE_ID=552225b7ce994686871d9958c5da0ec0
_HOSTNAME=localhost.localdomain
SYSLOG_FACILITY=3
SYSLOG_IDENTIFIER=systemd
CODE_FILE=../src/core/job.c
CODE_LINE=732
CODE_FUNCTION=job_log_status_message
MESSAGE_ID=39f53479d3a045ac8e11786248231fbf
RESULT=done
_TRANSPORT=journal
_PID=1
_COMM=systemd
_EXE=/usr/lib/systemd/systemd
_CAP_EFFECTIVE=3fffffffff
_SYSTEMD_CGROUP=/
_CMDLINE=/usr/lib/systemd/systemd --switched-root --system --deserialize 22
_SELINUX_CONTEXT=system_u:system_r:init_t:s0
UNIT=dnf-makecache.service
MESSAGE=Started dnf makecache.
_SOURCE_REALTIME_TIMESTAMP=1417610526530956

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

Системд по умолчанию пишет и текстовые логи.

если я могу получить что-то типа этого:

Dec  3 09:17:01 ubuntu CRON[3925]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  3 10:17:01 ubuntu CRON[4544]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  3 11:17:01 ubuntu CRON[5445]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  3 12:17:01 ubuntu CRON[6200]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  3 12:54:54 ubuntu kernel: [18320.007451] show_signal_msg: 30 callbacks suppressed
Dec  3 12:54:54 ubuntu kernel: [18320.007458] Chrome_ChildThr[11828]: segfault at 0 ip b76ca219 sp b0a349d0 error 6 in libmozalloc.so[b76c9000+2000]
Dec  3 13:17:01 ubuntu CRON[12092]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly)
Dec  3 14:12:18 ubuntu kernel: [22963.374440] [drm:i915_hangcheck_elapsed] *ERROR* Hangcheck timer elapsed... GPU hung
Dec  3 14:12:18 ubuntu kernel: [22963.374448] [drm] capturing error event; look for more information in /debug/dri/0/i915_error_state
Dec  3 14:17:01 ubuntu CRON[12496]: (root) CMD (   cd / && run-parts --report /etc/cron.hourly

Немного некорректно сказано. Я бы сказал так: systemd способен 1) перенаправлять всё в syslog, если таковой есть, и 2) отключать запись своих файлов.

местным питушкам осталось валить на колибриос

уже лучше.

Однако при использовании journalctl тебе не надо контролировать ротацию логов.
С обычными текстовыми файлами есть нюанс. Они не совсем обычные.
Часть пожата гзипом. Часть сообщений разбросанно по разным файлам. Да и не всегда есть нужда отрабатывать логи с момента большой установки.
Можно, конечно, велосипедить правильную обработку такой ситуации:
dmesg
dmesg.0
dmesg.1.gz
dmesg.2.gz
dmesg.3.gz
dmesg.4.gz
Но тут уже есть готовая тулза, которая все это делает сама. По факту journalctl резко упрощает и автоматическую работу с логами.

да, о этом нюансе я знаю.
да, я не спорю, насчет того, что journalctl полезен.

Баги в багзиле системд - это хорошо.

конечно. везде плохо - тут хорошо.

Кроме того, куда валятся баги в init-скриптах?

ты всё еще про баги в парсерах?

Каждый чинит свой велик. Своим способом. Не подходящим больше никому. Багрепорты размазаны по всему интернету.

Нет уж. Пусть все чинят в одном месте, а не как сейчас.

Да, большую централизацию даёт системде. Например кашу из шелл-скриптов, и дистро-зависимых сервис-файлов, и разные багзиллы.

Не работающий?

неа. заявлялась скорость - нету. заявлялась унификация - появилась +1 софтина (и довольно жирная). Заявлялась безопасность журналд - появилось бесполезное хэширование с эффектом плацебо, только в отличие от него не помогает. Что там еще поттеринг заявлял о его поделии?

Таки работает. В редхате, федоре, дебиане.

в таком контексте да.

Что вообще такое инит-скрипт? Это костыль

то-то системде костылищще не может обойтись без инит-скриптов.

Фтопку её. а ещё она ни одну фс не может.

А как же толстый32, 4 гигабайта хватит всем.

Заявлялась безопасность журналд - появилось бесполезное хэширование с эффектом плацебо

Хочешь сказать вот это В Journald добавлена поддержка криптографической защиты журналов не работает?

Чем его проверять? fsck не могёт.

это - реклама? не, она как раз работает :)

Блин, kir2yar жжёт - за всеми этими баттхёртными дегенератами, органически не способными к чтению документации, я уже стал забывать, что на лоре и грамотные чуваки попадаются. Искренняя благодарность перед строем, мужик!

баттхёртными дегенератами, органически не способными к чтению документации

поплачь, поплачь еще на агрессивное сообщество, в обнимку с лёнькой :-D

$ journalctl -u NetworkManager.service --since="-2h" Выдаст плейнтекстом все, что творилось с нетворкманагером за последние два часа.

Тут ещё стоит упомянуть, что так будут показаны не только сообщения самого NetworkManager, но и его дочерних вспомогательных процессов, ибо cgroups. На регулярках такое уже не напишешь без перечисления всех возможных вариантов имён бинарников.

А ведь можно ещё вспомнить возможность запуска нескольких instance'ов сервиса через шаблоны, например, скажем, apache@host1.service и apache@host2.service - journal в такой ситуации позволяет элементарно просмотреть записи самого процесса и всех дочерних, относящиеся к данному конкретному instance'у. Как это проделать с обычным syslog, учитывая, что определить принадлежность произвольного дочернего процесса к конкретному instance'у из доступной в syslog информации невозможно?

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

содержательно. в прошлый раз тоже на личность переходил. это всё потому что я чёр^W агрессивный, да? :-D

Это всё потому что аргументов ты не понимаешь. Да, знаешь, я устал повторять по десять раз одно и то же.

кстати да, часто задумывался как вам не надоедает гнать маркетинговый бред про системде, когда с каждым выходом «суперпупер-фичи» это на тех.форумах достаточно обжевывается. Вы же в который раз, одну и ту же ложь. Либо сами не знаете, либо умышленно лжёте.

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

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

кстати да, часто задумывался как вам не надоедает гнать маркетинговый бред про системде, когда с каждым выходом «суперпупер-фичи» это на тех.форумах достаточно обжевывается. Вы же в который раз, одну и ту же ложь. Либо сами не знаете, либо умышленно лжёте.

Пока врунов я ловил только в вашем лагере.
Давай пруф, на место, где я соврал.
Оу, собачка только тяфкать умеет?

конечно. везде плохо - тут хорошо.

Баги должны быть в багзиле. А не в релизе.

Да, большую централизацию даёт системде. Например кашу из шелл-скриптов, и дистро-зависимых сервис-файлов, и разные багзиллы.

Это ты с апстартом не попутал?
И да, если вы не можете без башатины - системд умеет шел-скрипты запускать.

то-то системде костылищще не может обойтись без инит-скриптов.

Хм, у меня в /etc/init.d/
$ ls /etc/init.d/
functions README
Причем оно тупо для совместимости. Вывод: ты врешь или дурак.

лет через пять о подобном намерении заявит

Ловите телепата! Тео не прогнётся, OpenBSD наше всё!