форумы  помощь  поиск  регистрация  майллист  вход/выход  слежка

Вариант для распечатки		Пред. тема | След. тема
Форум Разговоры, обсуждение новостей
Изначальное сообщение		[ Отслеживать ]

"Разработчики systemd представили Journal, замену системе syslog"	+/–
Сообщение от opennews (ok) on 19-Ноя-11, 00:16
Леннарт Поттеринг (Lennart Poettering) представил (http://0pointer.de/blog/projects/the-journal.html) в своём блоге Journal (https://docs.google.com/document/pub?id=1IC9yOXj7j6cdLLxWEBA...), дополнение к системному менеджеру systemd, призванное заменить собой службу syslog и другие сопутствующие сервисы журналирования событий. Разработка пока находится на начальной стадии, прототип с реализацией базовой функциональности  можно найти (http://cgit.freedesktop.org/systemd/log/?h=journal) в Git-репозитории (http://cgit.freedesktop.org/systemd) systemd. Первую экспериментальную реализацию Journal планируется интегрировать в дистрибутив Fedora 17. Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Как правило, первым делом после взлома злоумышленники пытаются замести следы и почистить выдающие их активность записи из системных логов. Используемые в настоящее время ре... URL: http://0pointer.de/blog/projects/the-journal.html Новость: http://www.opennet.dev/opennews/art.shtml?num=32347
Ответить | Правка | Cообщить модератору

Сообщения по теме

[Сортировка по времени | RSS]

1. "Разработчики systemd представили Journal, замену системе sys..."	+/–
Сообщение от emg81 (ok) on 19-Ноя-11, 00:16
написано красиво, но, вспоминая systemd... чтобы это чудо полноценно работало, опять надо будет вносить тотальные изменения? может, теперь /boot/ не будет рекомендоваться держать на отдельном разделе или ещё чего? P.S. сам не программист, но анализируя отзывы о Л.Поттеринге и кол-во проблем при реализации его изобретений, что-то скептически отношусь к такому нововведению
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	9. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 00:36
	вы про это — http://www.freedesktop.org/wiki/Software/systemd/separate-us... ?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	254. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:07
	> вы про это — http://www.freedesktop.org/wiki/Software/systemd/separate-us... ? Тссс, не палите контору. Сейчас виндотролли, не знающие матчасти, легко вычисляются по крикам "systemd не поддерживает /usr на отдельном разделе!!1". Нет, я, конечно, понимаю, что большинство из них никогда не читает ничего по теме обсуждения, но все-таки такие прямые ссылки давать рискованно. Вот начитается кто-нибудь, и перестанет талдычить эту глупость. Будет казаться умнее, но по факту - умнее не станет.
	Ответить | Правка | ^ к родителю #9 | Наверх | Cообщить модератору

	16. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 00:52
	>но, вспоминая systemd... А что systemd? У меня в новой opensuse он **очень** быстро грузит систему, например.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	25. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 01:16
	>>но, вспоминая systemd... > А что systemd? У меня в новой opensuse он **очень** быстро грузит > систему, например. везёт. у меня раньше стояла opensuse 11.4 некоторое время. время с запуска в GRUB до появления KDE-шного окошка незначительно отличалось от того, что было в Gentoo c openRC. 1-2 сек буквально, в пределах погрешности. сейчас абсолютно такая же дефолтная openSUSE (что в тот, что в этот раз добавил в автозагрузку только pppoe), только уже с systemd грузит систему на 7 сек. дольше, чем рядом стоящая Gentoo. внимание, вопрос: нафига такие хороводы? ну, может, там что-то ещё "подоптимизировать" надо, включить мозг тут советуют. только почему-то Gentoo с openRC с кучей сервисов в автозагрузке почему-то грузится быстрее. измерял только что. gentoo с момента старта из GRUB до KDE-шного окошка по центру грузит за 22 секунды, openSUSE 12.1 дефолтная - за 29 секунд. погрешность измерений +-1 секунда.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	41. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:55
	/me пожимает плечами УМВР. Правда.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	51. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 02:33
	так и у меня ВР. сейчас пишу из openSUSE, где этот самый systemd только как пользователь, от хвалёной systemd проку не вижу, когда это новая супероптимизированная наноразработка проигрывает криво настроенной моими руками openRC (я ман по опенрц не отворял и мигрэйшн гайд не дочитал. сделал как-то, всё работает. а правильно - неправильно, мир с ней - ошибок не сыпет, да и ладно) - то, логично, возникает вопрос, а зачем оно нужно? вот ещё не знаю, из-за systemd или нет, но при загрузке ОС прогресс-бара нету :(
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	89. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:17
	> только как пользователь, от хвалёной systemd проку не вижу, когда это новая > супероптимизированная наноразработка проигрывает криво настроенной моими руками openRC А ты точно уверен, что разные дистрибутивы у тебя запускают один и тот же набор сервисов? Или ты думаешь, что systemd это единственная разница между генту и зюзей?
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	135. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 12:39
	> А ты точно уверен, что разные дистрибутивы у тебя запускают один и > тот же набор сервисов? > Или ты думаешь, что systemd это единственная разница между генту и зюзей? конечно, нет. я потому и написал, что суся дефолтная, лишь pppoe добавил. а в генте куча всего накопленного автогрузится + всякие нужные модули для виртуалбоксов и т.п.
	Ответить | Правка | ^ к родителю #89 | Наверх | Cообщить модератору

	189. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:28
	> я потому и написал, что суся дефолтная, лишь pppoe добавил. а в > генте куча всего накопленного автогрузится + всякие нужные модули для виртуалбоксов > и т.п. Ну а вы сравнивали список загружаемого? А то может в сусе больше хлама по дефолту? Как бы сравнивать надо в одинаковых условиях, а то меряется неизвестно что. В идеале так: Делается тестовый линукс. Не гента и не суся, а что-то самопальное типа LFS. Бутявится по очереди systemd и чем там еще. Результаты сравниваются.
	Ответить | Правка | ^ к родителю #135 | Наверх | Cообщить модератору

	231. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от lucentcode (ok) on 19-Ноя-11, 19:42
	А зачем тестовый? Берёте нормальный Arch и по очереди устанавливаете системы инициализации, сравниваете и получаете результат. поминая systemd... А что systemd? У меня в новой opensuse он **очень** быстро грузит систему, например.
	Ответить | Правка | ^ к родителю #189 | Наверх | Cообщить модератору

	330. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 21-Ноя-11, 04:57
	> А зачем тестовый? Берёте нормальный Arch и по очереди устанавливаете системы > инициализации, В нормальной системе придется больше геморроиться с подгонкой кучи сервисов и конфигов систем инициализации чтобы грузился идентичный набор сервисов. > сравниваете и получаете результат. Сравнивать с умом надо. А в арче что, во всех пакетах для всех сервисов прописаны несколько вариантов старта? Как то скриптики - для init, конфиги - для systemd, ну и так далее? > поминая systemd...А что systemd? У меня в новой opensuse он **очень** быстро грузит > систему, например. Да собственно я не вижу чему там так уж тормозить. Скорее, претензии сводятся к тому что опять мистер Поттеринг выкатил свой велосипед с квадратными колесами под который надо ломом и лопатами дорогу "ровнять". В том плане что сразу вылезла куча проблем которые до этого почему-то никому особо не мешали. Что для творений Поттеринга вообще характерно.
	Ответить | Правка | ^ к родителю #231 | Наверх | Cообщить модератору

	379. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Yuriy (??) on 22-Ноя-11, 14:11
	На глаза хамелеона смотри
	Ответить | Правка | ^ к родителю #51 | Наверх | Cообщить модератору

	103. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:45
	> /me пожимает плечами > УМВР. Правда. а что такое УМВР?
	Ответить | Правка | ^ к родителю #41 | Наверх | Cообщить модератору

	153. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 13:16
	Луркай. У Меня Все Работает. Акроним.
	Ответить | Правка | ^ к родителю #103 | Наверх | Cообщить модератору

	44. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Buy (??) on 19-Ноя-11, 02:00
	> gentoo с момента старта из GRUB до KDE-шного окошка по центру грузит за 22 секунды, openSUSE 12.1 дефолтная - за 29 секунд. Это конечно мое имхо, но стоил ли вообще тратить столько ресурсов и сил ради столь не занчительного выиграша? Новая система инициализации все-таки не быдло скриптик на на тридцать строк, плюс отладка, оптимизация, устранение ошибок... Не важно что там быстрее грузится, важна незначительная разница. Хотя, если нравиться пусть пишут.
	Ответить | Правка | ^ к родителю #25 | Наверх | Cообщить модератору

	47. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 02:13
	я Gentoo вообще перезагружаю редко и openRC не оптимизировал совсем. ну, разве что после установки выставил в конфиге параллельную загрузку сервисов. и всё. лично я никаких сил не тратил особых. > Не важно что там быстрее грузится, важна незначительная разница. у меня случился stack overflow после неоднократного прочтения и перепрочтения этой фразы в попытках её понять. > Хотя, если нравиться пусть пишут. конечно. лишь бы насильно не пихали во все дистрибутивы. одна из причин, почему как познакомился с Linux вообще, сразу ушёл на "конструкторы" (Arch / Gentoo) - возможность выбирать. а в таких, как Ubuntu и т.п. понапихают всего новомодного, в итоге просто пользоваться системой неудобно. зато найдутся ярые фанаты нововведений, всех захамят консерваторами / нежелающими развиваться и т.д.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	61. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
	Сообщение от Клыкастый (ok) on 19-Ноя-11, 03:47
	а то ещё есть которых зверскими побоями в детском саду заставляли переводить на бумаге C в машинный код. ети при слове "компилятор" начинают биться в истерике, нанося дополнительные повреждения верней части туловища...
	Ответить | Правка | ^ к родителю #47 | Наверх | Cообщить модератору

	115. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 09:59
	> а то ещё есть которых зверскими побоями в детском саду заставляли переводить > на бумаге C в машинный код. ети при слове "компилятор" начинают > биться в истерике, нанося дополнительные повреждения верней части туловища... То, что происходит при переходе на поделки поттеринга - прямая конвертация бинарников из одной архитектуры в другую с последующим дизассемблированием и переводом этого дела на Си.
	Ответить | Правка | ^ к родителю #61 | Наверх | Cообщить модератору

	411. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 23-Ноя-11, 15:04
	Откуда такие упоротые лезут? Вы хоть раз в жизни пробовали вообще системам типа systemd конфиг накатать для своего сервиса? Ничего что это в 10 раз проще и быстрее чем эквивалентные костыли на шелскриптах изображать?
	Ответить | Правка | ^ к родителю #115 | Наверх | Cообщить модератору

	192. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:33
	> Не важно что там быстрее грузится, важна незначительная разница. Хотя, если > нравиться пусть пишут. Не скажу за systemd но с upstart конфиг на 5-7 строк делает больше и умнее нежели традиционная портянка на 2 страницы. Что определенно добавляет радости когда надо прописать пяток своих сервисов для их автостарта. Пока вы на шеллскриптах изобразите авторестарт сервиса (на случай если ему стало плохо) с лимитированием числа перезапусков в некий интервал (чтобы не положить хост в случае если сервису стало совсем уж плохо), возможностью поставить недефолтный приоритет и так далее - вы будете геморроиться довольно долго, а в результате у вас получится простынка на 2 страницы. Вместо 5 строчек в конфиг-файлике более вменяемого запускача. Которые кстати не отменяют запуск шеллскриптов если это стало нужно, прсото в 99% случаев можно и без них обойтись, заменив 2 страницы г-нокода на 5-7 строк конфига, очевидных как топор.
	Ответить | Правка | ^ к родителю #44 | Наверх | Cообщить модератору

	195. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 16:37
	> Пока вы на шеллскриптах изобразите авторестарт сервиса (на случай если ему стало > плохо) с лимитированием числа перезапусков в некий интервал (чтобы не положить > хост в случае если сервису стало совсем уж плохо), возможностью поставить > недефолтный приоритет и так далее - вы будете геморроиться довольно долго, > а в результате у вас получится простынка на 2 страницы. Для этого давным-давно есть monit. :) check process crond with pidfile /var/run/crond.pid         group daemons         group cron         start program = "/sbin/service crond start"         stop  program = "/sbin/service crond stop"         if 5 restarts with 5 cycles then timeout         depend cron_bin         depend cron_spool check file cron_bin with path /usr/sbin/crond         group cron         include /etc/monitrc.d/templates/rootbin check directory cron_spool with path /var/spool/cron         group cron         if failed permission 3730 then unmonitor         if failed uid root        then unmonitor         if failed gid crontab     then unmonitor Это штатный /etc/monitrc.d/EXAMPLES/crond в используемом дистрибутиве -- а можно и смотрелку за памятью, и реакцию на подходящее к концу свободное место на разделе прикрутить.
	Ответить | Правка | ^ к родителю #192 | Наверх | Cообщить модератору

	240. "Разработчики systemd представили Journal, замену системе sys..."	–3 +/–
	Сообщение от seidu on 19-Ноя-11, 21:03
	Если вам приходится использовать плюшки типа monit значит система у вас настроена неправильно, либо вы не можете ее настроить но упорно используете линукс. Monit это костыль. Хотя в общем идеология линукса в отличие от именно такая, что ты сам можешь придумать себе пачку граблей, а потом расставлять флажки по периметру чтоб не наступать на них.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	310. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от myhand on 20-Ноя-11, 13:10
	> Если вам приходится использовать плюшки типа monit значит система у вас настроена неправильно Да Вы телепат.  Я использую monit.  Пожалуйста, перечислите по пунктам что в системе у меня "настроено неправильно". > в общем идеология линукса в отличие от От чего?
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	318. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Michael Shigorin (ok) on 20-Ноя-11, 20:18
	> Если вам приходится использовать плюшки типа monit значит система у вас настроена > неправильно, либо вы не можете ее настроить но упорно используете линукс. > Monit это костыль. То-то там патчи то для соляриса, то для *bsd приносят.  Из самых разных мест -- Orange сходу вспомнился. Вообще-то если бы Ваш вывод был верен, то за раз настроенной системой никогда бы не требовалось наблюдение и человека тоже.  Это бывает, но такие системы скорее напоминают "замкнутые" и их применимость заведомо сильно ограничена. А в остальном monit вполне способен подсказать, когда закончилось место на диске, или вовремя успеть уложить потенциально ненамеренно DoS'ящий хост сервис (сейчас менее актуально, а вот когда один Duron 800/512M тащил вагон всего -- очень даже было), чтоб хоть получилось добраться и принять меры, а не гадать на кофейной гуще и звонить хостеру дёрнуть питание... Ещё к нему в пару очень хорош collectd.  Хотя Вы и его костылём назовёте, наверное -- денно и нощно просиживая глаза об надцать top'ов. Хотя вообще-то компьютеры -- тоже костыли, конечно.  Мир несовершенен, c'est la vie. 2 develop7: можете пальчиком указать, в каком месте monitrc есть Turing complete?
	Ответить | Правка | ^ к родителю #240 | Наверх | Cообщить модератору

	422. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 20:32
	> его костылём назовёте, наверное -- денно и нощно просиживая глаза об > надцать top'ов. По логике вещей надо вас за него обругать. Как тут ругаются на поттеринговский журнал. А то как это, он умеет хранить данные в бинарной базе данных rrdtool-а, например?! И предлагать унифицированный интерфейс для типовых операций сбора статистики?! Вы чо, опухли?! Правильный вариант - только и исключительно парсинг многочисленных логов всех мастей шеллскриптами. А collectd - ересь и не юниксвей!!!111.
	Ответить | Правка | ^ к родителю #318 | Наверх | Cообщить модератору

	281. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 20-Ноя-11, 01:36
	> Для этого давным-давно есть monit. :) полный по тьюрингу конфиг vs ini-style конфиг + инитскрипт на C. Я за последнее. Оно а) быстрее и б) проще. Извините.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	311. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от myhand on 20-Ноя-11, 13:28
	> полный по тьюрингу конфиг vs ini-style конфиг + инитскрипт на C. Я > за последнее. Оно а) быстрее и б) проще. Извините. Ага.  А еще оно: в) бесполезнее.  Или я что-то пропустил и у systemd умеет что-то помимо "я смотрю на процесс с данным pid и перезапущу его если оно помрет"? Он умеет ходить на порт сервиса по нужному протоколу?  Провести произвольную серию тестов и выполнить в зависимости от - определенное действие (рестарт, к примеру)? Помним, что мы в реальном мире живем - программы ведут себя плохо, ломаются, не всегда есть возможность статически ограничить их потребление ресурсов.  И т.д. и т.п.  Ждать пока сервис отсегфолтится или еще как помрет - нет никакой возможности... Так что как замена monit - поделие этого клоуна (см. http://ftp.halifax.rwth-aachen.de/CCC/27C3/mp4-h264-512x288-...) и рядом не лежало...  Хорошие ребята - делают полезный и качественный продукт.  Кроссплатформенный.  Без истерик "я весь зашибись и вы получили это бесплатно".
	Ответить | Правка | ^ к родителю #281 | Наверх | Cообщить модератору

	410. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 15:02
	> Он умеет ходить на порт сервиса по нужному протоколу?  Провести произвольную > серию тестов и выполнить в зависимости от - определенное действие (рестарт, к > примеру)? В идеале система запуска сервисов должна сие уметь, хотя-бы в простом виде. Как то сконектиться на порт, посмотреть что отвечают. Ну или внешний чекер (програма/скрипт/плагин) для сильно навернутых тестов. Потому что действительно типовая задача.
	Ответить | Правка | ^ к родителю #311 | Наверх | Cообщить модератору

	441. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand (ok) on 25-Ноя-11, 14:16
	> В идеале система запуска сервисов должна сие уметь, хотя-бы в простом виде. Как то сконектиться на порт, посмотреть что отвечают. Что именно "сие" - полный список озвучьте, пожалуйста?  Накой черт нужен "простой вид", когда нужно либо _все_ - либо _ничего_.  Полмониторинга - хуже чем его отсутствие. > Ну или внешний чекер (програма/скрипт/плагин) для сильно навернутых тестов. Ну да.  Просто - нормальная система мониторинга.  Пусть каждый занимается своим делом - init стартует все в заданном порядке, а другие программы - следят за сервисами.  Так и происходит сейчас.
	Ответить | Правка | ^ к родителю #410 | Наверх | Cообщить модератору

	332. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 05:11
	> Для этого давным-давно есть monit. :) Ага, в силу кривости инита - добавим ему костыль. Который к тому же делает все через внешние команды. А при всяких там жестких out of memory и прочих чревато EPIC FAIL-ом, когда не удастся выделить память на запуск +1 интерпретера и скриптов в нем, например. С другой стороны upstart для простых действий вообще без внешних скриптов может обойтись. А поскольку сам он целиком в памяти висит т.к. заменяет init, сие как-то более убедительно выглядит с точки зрения надежности всего этого. В целом он не так уж плох, просто он костылирует систему инициализации. Логичнее просто пхнуть в нее сразу. Тем более что быстрый старт системы всем по вкусу обычно. [del] > Это штатный /etc/monitrc.d/EXAMPLES/crond в используемом дистрибутиве -- а можно > и смотрелку за памятью, и реакцию на подходящее к концу свободное > место на разделе прикрутить. Можно. Но по большому счету вот за это я и не жалую классический инит. Он не отвечает требованиям времени и его приходится густо окостыливать, выруливая как умеешь. Monit - один из вариантов, конечно. Но выбирая между 2 костылями и 1 прямым решением - я за прямое.
	Ответить | Правка | ^ к родителю #195 | Наверх | Cообщить модератору

	361. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand on 21-Ноя-11, 15:06
	> Ага, в силу кривости инита - добавим ему костыль. Который к тому же делает все через внешние команды. "Все" - это что именно? > А при всяких там жестких out of memory и прочих чревато EPIC FAIL-ом, когда не удастся выделить память на запуск +1 интерпретера и скриптов в нем, например. До такого бардака - можно и _нужно_ систему не доводить.  Для чего давным давно есть механизмы. >Но по большому счету вот за это я и не жалую классический инит. Он не отвечает требованиям времени и его приходится густо окостыливать, выруливая как умеешь. В чем здесь костыль для init?  Последний вполне справляется со своей задачей - запускалка сервисов. Замените init на systemd - необходимость в monit никуда не испарится.
	Ответить | Правка | ^ к родителю #332 | Наверх | Cообщить модератору

	381. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 22-Ноя-11, 15:25
	>> Ага, в силу кривости инита - добавим ему костыль. Который к тому же делает все через внешние команды. > "Все" - это что именно? Да почти все. Старт/стоп сервисов например. Хотя логичнее делать простейший запуск через сисколы вместо дергания на каждий пук шелла. Тупо пинать шелл на 800к для старта 20к демона если для этого достаточно сделать 1 сискол. > До такого бардака - можно и _нужно_ систему не доводить.  Для > чего давным давно есть механизмы. А мне вот нужна нажежная и предсказуемая система без лишнего геморроя. И затыкать все классические болячки своими фирменными костылями - может и подзадолбать. >>Но по большому счету вот за это я и не жалую классический инит. Он не отвечает >>требованиям времени и его приходится густо окостыливать, выруливая как умеешь. > В чем здесь костыль для init?  Последний вполне справляется со своей > задачей - запускалка сервисов. Да, только вот там простыни мутного кода на 2 страницы делают то же самое что в нормальной системе инициализации делает конфиг на 5-7 строк. И даже меньше. Из того что я могу отметить: 1) Init не поставит сервису нужный приоритет по простому. Хотя вися под рутом - мог бы и дернуть ОДИН СИСКОЛ, елки. Закостылить можно, но 1 строчка в конфиге нормальной запускалки в 20 раз проще и очевиднее. И запускалка заведомо висящая под рутом уж всяко могла бы сискол для меня пнуть. Дошло! Не прошло и полувека! 2) А если нам надо запустить сетевой демон не раньше чем законектится вон тот сетевой и-фейс, потому что мы например хотим на именно него забиндиться, или что-то подобное, с зависимостями - в случае инита это превращается в сплошную академическую греблю вместо, простите, запускания сервиса. Нет, конечно можно родить турбомегакостыль, просто его создание потребует больше времени чем конфигурежка самого сервиса, бэть. 3) Кому как не запускалке виднее всех что сервис внезапно нае..лся когда его не просили об этом?! Нет, конечно и автоматический рестарт сервиса можно закостылить, только учтя что это для каждого первого сервиса хорошо бы - логично это объявить стандартной фичой. 4) А вот если сервису стало ну совсем плохо, не надо перезапускать его 100 раз в секунду, чтобы не создавать сильную нагрузку на хост тупым рестартом без перспектив! Если сервис не взлетел за несколько попыток - забить на это (+админу выслать сообшение о проблемах в идеале). Как минимум лимитирование рестартов современный вариант инита должен уметь. Т.к. логичное следствие хотелок 1) и 3) и просто подстраховка от EPIC FAIL`ов. > Замените init на systemd - необходимость в monit никуда не испарится. Да вообще-то, если современный запускач реализован _нормально_, делая ВСЕ что от него надо, monit должен стать всего лишь костылем с повторным функционалом. Monit решает вполне стандартные проблемы администрежки. Они настолько типовые что почти все из этого списка по уму должен уметь сам init. Или на кой он нужен если ничего не умеет?
	Ответить | Правка | ^ к родителю #361 | Наверх | Cообщить модератору

	388. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand on 22-Ноя-11, 17:15
	> Старт/стоп сервисов например. Хотя логичнее делать простейший запуск через сисколы вместо дергания на каждий пук шелла. Это гибкое решение.  В шелле можно вызвать утилиты, для последующего ограничения процесса.  И не ждать, покуда наш Песатель соизволит к systemd прикрутить соответствующие крутилки или сам сервис получит соответствующие ключи для командной строки... > Тупо пинать шелл на 800к для старта 20к демона если для этого достаточно сделать 1 сискол. Где Вы видели шелл на 800k?  Даже если и так - это накладные расходы на старт, который один раз происходит, а не ежеминутно.   > А мне вот нужна нажежная и предсказуемая система без лишнего геморроя. А в чем, собственно, "геморой"?  Ах, я забыл Вам рассказать о том, _какие именно_ есть механизмы...  Ну, rlimits, да те же самые cgroups. Учиться надо, вот оно в чем проблема-то. > Да, только вот там простыни мутного кода на 2 страницы делают то же самое что в нормальной системе инициализации делает конфиг на 5-7 строк. И даже меньше. Покажите этот мутный код в Debian, пожалуйста.  Постараемся поправить, если он действительно "мутный".  А вот "то же самое за 5 строг" - фиг сделаете.  Откройте, пожалуйста, инит-скрипт apache2 и расскажите как реализовать тамошнюю логику на 5 строк. > 1) Init не поставит сервису нужный приоритет по простому. Для этого и есть скрипты.  Ставьте, пожалуйста.  Хоть для процесса сервера - хоть для всех процессов из сценария. > 2) А если нам надо запустить сетевой демон не раньше чем законектится вон тот сетевой и-фейс Для этого есть порядок последовательности запуска скриптов.  И давно есть зависимости в заголовке LSB-совместимого сценария, чтобы все это было просто настроить. > 3) Кому как не запускалке виднее всех что сервис внезапно нае..лся когда его не просили об этом?! "Запускалке" видно только то, что процесс с данным PID - умер.  Или что больше в этой cgroups нету процессов.  Увы, сервис может быть запросто в состоянии "нае...лся" и при этом не сегфолтиться и не завершаться. И сценарии решения этой проблемы могут быть сложнее "убить и перезапустить" - вот почему и есть monit.  Возможно, нужно логи почистить, возможно запуститить какой-то анти-ddos скрипт.  Или - отладчик подключить.  Все это - не задачи для простой пускалки сервисов init. > 4) А вот если сервису стало ну совсем плохо, не надо перезапускать его 100 раз в секунду, чтобы не создавать сильную нагрузку на хост тупым рестартом без перспектив! Если сервис не взлетел за несколько попыток - забить на это (+админу выслать сообшение о проблемах в идеале). Вот и я написал о том, что "не надо".  Только и "забить" - не обязательно лучшее решение.  Еще парочку я набросал выше.  Поймите одно: Единственно Верной (тм) политики разрешения таких проблем - нет и быть не может.  Это задача для гибко конфигурируемой системы мониторинга (monit), а не для init и любой его альтернативы. > Да вообще-то, если современный запускач реализован _нормально_, делая ВСЕ что от него надо, monit должен стать всего лишь костылем с повторным функционалом. Monit решает вполне стандартные проблемы администрежки. Они настолько типовые что почти все из этого списка по уму должен уметь сам init. Или на кой он нужен если ничего не умеет? sysv init умеет: стартовать сервисы в нужной (определяемой их зависимостями) последовательности.  Все.  Вы хотите из init сделать систему мониторинга?  Она должна поддерживать тесты кучи протоколов, да еще и настраиваться автомагически?  Накой тащить функционал, единственной разумной настройкой по-умолчанию которого будет - "отключить нафиг". Поймите, что нет универсального способа настроить ПО типа monit.  Например, действие по-умолчанию для apache может быть "перезапустить n раз и потом забить" - толку от ПО с таким умением будет 0, исключая сегфолтящиеся поделки Поттеринга.  Нормальный тест сервиса должен включать проверку работы бизнес-логики приложения, возможно с оглядкой на другие процессы или ресурсы в системе.
	Ответить | Правка | ^ к родителю #381 | Наверх | Cообщить модератору

	396. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 20:16
	>> Старт/стоп сервисов например. Хотя логичнее делать простейший запуск через сисколы >> вместо дергания на каждий пук шелла. > Это гибкое решение.  В шелле можно вызвать утилиты, ВНЕЗАПНО, если мне не хватило фич системы инициализации - вот тогда я из нее и буду звать скрипт-хелпера, который докостылит до нужной кондиции. Но хотелось бы чтобы в 99.9% случаев этого не требовалось. А оставшийся 0.1% я так и быть докостылю. Желательно чтобы такое случалось после дождичка в четверг, после того как рак на горе даст 3 зеленых свистка вверх. > для последующего ограничения процесса.   Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно костылить все _стандартные_ типовые случаи. Нахрена мне гибкость резинового фаллоимитатора в случае если я хочу гвоздь забить? Молоток должен быть удобным и должен хорошо забивать гвозди. А то что его в узел видите ли нельзя завязать - может и хрен с ним?! > И не ждать, покуда наш Песатель соизволит к systemd прикрутить соответствующие > крутилки или сам сервис получит соответствующие ключи для командной строки... Я вообще апстарт предпочитаю пока. Оно just works. Вот только знаете, когда конфиг на 5 строк писаный за пару минут делает все ето же что раньше делала пачка костылей и подпорок на 5 кило шеллскрипта, а как бонус система стартует вместо полутора минут 20 секунд, я констатирую EPIC WIN. >> Тупо пинать шелл на 800к для старта 20к демона если для этого достаточно сделать 1 сискол. > Где Вы видели шелл на 800k?   Bash стандартный весит как раз столько. Если не больше. > Даже если и так - это накладные расходы на старт, который один раз происходит, Это с хрена ли 1 раз? Он происходит на каждый старт каждого сервиса. Надо запустить 800К бинарь, распарсить скрипт на 2 страницы, отинтерпретировать, и вот тогда... хм... и все это ради того что делается 1 сисколом? А если посчитать сколько раз за это время сискол выполнится и бинарь запустится, обидно не станет? > а не ежеминутно. А это уже зависит от природы сервисов. >> А мне вот нужна нажежная и предсказуемая система без лишнего геморроя. > А в чем, собственно, "геморой"?  Ах, я забыл Вам рассказать о > том, _какие именно_ есть механизмы...  Ну, rlimits, да те же самые cgroups. Они для начала не решают проблему с мониторингом упавшего сервиса вообще. Они скорее дополняют картину. Кстати поттеринг вроде как и cgroups грозился прикрутить. Вообще, логично - если уж фичи есть прямо в ядре, стартер имеет полное право пинать виртуалки и контейнеры, очевидно. Стартить их откуда-то сбоку при старте системы? Хм, опять костыли... на задачи которые опять же уже стали типовыми. Знаете, типовые сценарии пользования системой все-таки не должны напоминать борьбу с ветряными мельницами. > Учиться надо, вот оно в чем проблема-то. Нет, проблема не в том. Проблема в том что затыкать самолично все типовые грабли - не очень прикольно. Хорошо что это стало до некоторых допирать наконец. А то как тут кто-то верно заметил - мы бы так и бегали за мамонтами с топорами. Ну может быть мы бы заменили камень на титановый сплав, а ручка была бы углепластиковой. Но врядли процесс охоты стал бы сильно безопаснее и эффективнее. >> Да, только вот там простыни мутного кода на 2 страницы делают то же самое что в >> нормальной системе инициализации делает конфиг на 5-7 строк. И даже меньше. > Покажите этот мутный код в Debian, пожалуйста.   Дебианщики вроде как раз на похожий по смыслу апстарт и собирались (а потом может и на systemd). У меня к апстарту нет никаких претензий. Хотя если вы про обычные скрипты для инита - там даже простейший скрипт бывает _страницей_ текста, для совершенно шаблонных рутинных операций. На самом деле достаточно просто попробовать написать стартовый скрипт для какого-то своего сервиса. И подивиться насколько проще и быстрее это получится с хоть тем же апстартом. Попутно можно настроить плюшки которые в стандартном ините приходится густо окостыливать. Нет даже устаканившегося метода приоритет задать, каждый свой костыль депит если приперло. > Постараемся поправить, если он действительно "мутный".   Что, вот прямо так во всех пакетах? 8-\ А вы какой пакет майнтайните в дебиане? Насчет всех и сразу не поверю - там майнтайнеры указаны разные. > А вот "то же самое за 5 строг" - фиг сделаете.   Это почему же? Я как раз сделаю за 5 строк типовые операции, а в случае если надо что-то совсем уж из ряда вон - там и будем звать уже хелпера в виде скрипта. Насколько часто такое будет надо - см. выше. > Откройте, пожалуйста, инит-скрипт apache2 и расскажите как > реализовать тамошнюю логику на 5 строк. Внезапно, 1) Я не люблю опаче за общую монструозность. Его скрипты - вполне в духе опача. 2) Это ж надо, из того же апстарта можно и шеллскрипты пинать, если надо. 3) Он даже умеет эмулировать из себя античный init, притворяясь шлангом для как раз таких бакланов которые никак не могут свои каменные топоры выбросить уже наконец. В отместку конечно скорость (ре)старта проседает, но врядли это юзеров монстров типа опача вообще интересует. >> 1) Init не поставит сервису нужный приоритет по простому. > Для этого и есть скрипты.  Ставьте, пожалуйста.  Хоть для процесса > сервера - хоть для всех процессов из сценария. Нахрен надо - 1 строка в конфига апстарта. В сто раз проще и быстрее написания самолично скриптокостылей. И работает. Без дерга на это огромного интерпретера и что там еще, которые в сумме работают дольше чем стартует сервис. >> 2) А если нам надо запустить сетевой демон не раньше чем законектится вон тот сетевой и-фейс > Для этого есть порядок последовательности запуска скриптов.   А также, если меня не подводит склероз, в этом случае было "очень умное" ничегонеделание системы пока всякие там сетевки раздупляются, получая айпишники по дхцп. Хотя по логике можно бы запускать тех кому сеть вообще не сдалась или конкретная сетевка не требуется. Но конечно же неандертальцам это недоступно. Зачем же геморроиться с выплавкой стали, если можно лианой камень к палке примотать?! > И давно есть зависимости в заголовке LSB-совместимого сценария, чтобы все это > было просто настроить. Понятия о простоте у всех разные. Как по мне - 1 строка в конфиге апстарта это проще некуда. Попробуйте переплюнуть. Глядя на простынки текста в кило весом и больше - да ну его такое нафиг. >> 3) Кому как не запускалке виднее всех что сервис внезапно нае..лся когда его не просили об этом?! > "Запускалке" видно только то, что процесс с данным PID - умер.   А что еще она должна видеть? Именно это от нее и надо. И на скриптах конечно такое родить можно. И даже делают такое. Только геморно. Как зубилом письмо на каменной табличке долбить примерно. > Или что больше в этой cgroups нету процессов.  Увы, сервис > может быть запросто в состоянии "нае...лся" и при этом не сегфолтиться > и не завершаться. В принципе - может. Поэтому неплохо бы еще и простую валидацию в духе monit. Типа сделать соединение по тцп. Отвечает - ок, не отвечает - дыщ, рестарт. В апстарте такого пока еще нет и такое все-таки придется закостылить. В systemd вроде как что-то такое значилось в планах. Правда вот это Поттеринг, чьи программы отличаются неоднозначностью. У него бывают здравые идеи, но вот их реализация оставляет неоднозначные впечатления. > И сценарии решения этой проблемы могут быть сложнее "убить и перезапустить" - > вот почему и есть monit.   Остается только вопрос нахрен при этом нужен init который ничего не умеет. > Возможно, нужно логи почистить, возможно запуститить какой-то анти-ddos скрипт. Запуск программы по расписанию - по большому счету разновидность запуска программ. Поэтому, если не ошибаюсь, авторы апстарта и/или системд и на кроны зубы точат, что довольно логично :) > Или - отладчик подключить.  Все это - не задачи для простой пускалки сервисов init. Да у инита вообще нет задач. И хрен бы с ними с наворотами типа антиддосов, а вот всякие выставления приоритетов, рестарт упавших и взлет в правильный момент времени когда система к этому уже готова - хотелось бы видеть. В инит всего этого нет а в 100500й раз втыкать стандартный костыль - ни разу не прикольно. >> 4) А вот если сервису стало ну совсем плохо, не надо перезапускать его 100 раз в секунду, чтобы не создавать сильную нагрузку на хост тупым рестартом без перспектив! ... > Вот и я написал о том, что "не надо".  Только и > "забить" - не обязательно лучшее решение.  Еще парочку я набросал > выше.  Поймите одно: Единственно Верной (тм) политики разрешения таких проблем > - нет и быть не может.   Так я не спорю что для особо хитровы...тых случаев скрипты или внешние мониторы не лишние. Но для типовых случаев хотелось бы менее костылированных решений. > Это задача для гибко конфигурируемой системы мониторинга (monit), а не для init > и любой его альтернативы. А я вот другого мнения. О monit знаю. Но честно говоря предпочту написать за 2 минуты простой конфиг с базовым рестартом и выставлением приоритета чем полдня сношаться с реализацией этого на шелскриптах и прикручиванию потом к этой куче monit. >> Да вообще-то, если современный запускач реализован _нормально_, делая ВСЕ что от него надо, monit должен стать всего лишь костылем с повторным функционалом. Monit решает вполне стандартные проблемы администрежки. Они настолько типовые что почти все из этого списка по уму должен уметь сам init. Или на кой он нужен если ничего не умеет? > sysv init умеет: стартовать сервисы в нужной (определяемой их зависимостями) последовательности. А каменным топором в принципе можно зарубить мамонта. Но я все-таки предпочитаю не рубать мамонтов каменными топорами. Хоть это и можно, да. >  Все.  Вы хотите из init сделать систему мониторинга?   Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса. Как раз чтобы не изобретать свой велик (зато с турбонаддувом) на стандартную задачу. > Она должна поддерживать тесты кучи протоколов, да еще и настраиваться автомагически? По минимуму хватило бы простой проверки ответа сервиса на порту. Чуть получше: уметь посылать заданный набор байтов и проверять что в ответ приехал ожидаемый ответ. Просто сделать, много веса не добавит. А вот в 90% случаев разгрузит человека от работы по рутинному костылингу стандартных проблем. >  Накой тащить функционал, единственной разумной настройкой по-умолчанию которого будет > - "отключить нафиг". Для вас разумны одни дефолты. Для других - другие. > Поймите, что нет универсального способа настроить ПО типа monit.  Например, действие > по-умолчанию для apache может быть "перезапустить n раз и потом забить" Ну так апстарт умеет делать не более чем эн рестартов за эм секунд. Если больше - считаем что сервис окончательно одурел и забиваем на это чтобы не нагружать хост тщетными потугами его застартить. > - толку от ПО с таким умением будет 0, исключая сегфолтящиеся поделки Поттеринга. Как минимум апстарт мне вполне доставил. Нафиг-нафиг писать портянки в 2 страницы когда можно накидать конфиг в 5 строк, справляющийся не хуже. А если вдруг надо что-то совсем из ряда вон - ну вот тогда и будем пинать скрипт-хелпер. Только сие надо после дождика в четверг. Что ведет к уменьшению геморроя у админа. > Нормальный тест сервиса должен включать проверку работы бизнес-логики > приложения, возможно с оглядкой на другие процессы или ресурсы в системе. Нет, я конечно понимаю что можно дойти вплоть до написания юнит-тестов для апача, но это будет слегонца перебор, потому что в конечном итоге сбои в бизнес логике - это уже явно не в компетенции администратора и лечить сие должны програмеры :)))
	Ответить | Правка | ^ к родителю #388 | Наверх | Cообщить модератору

	398. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 20:25
	> Это с хрена ли 1 раз? Он происходит на каждый старт каждого > сервиса. Надо запустить 800К бинарь, распарсить скрипт на 2 страницы, отинтерпретировать, > и вот тогда… хм… и все это ради того что делается > 1 сисколом? А если посчитать сколько раз за это время сискол > выполнится и бинарь запустится, обидно не станет? вот это — квинтэссенция. винда in all it's glory. потому что остальным совершенно по барабану, пол-минуты или три минуты стартует система, ибо происходит это… ну, раз в месяц максимум, а то и реже.
	Ответить | Правка | ^ к родителю #396 | Наверх | Cообщить модератору

	409. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от develop7 (ok) on 23-Ноя-11, 14:45
	> вот это — квинтэссенция. винда in all it's glory. потому что остальным совершенно по барабану, пол-минуты или три минуты стартует система, ибо происходит это… ну, раз в месяц максимум, а то и реже. Как пинать убунту за «медленно грузится» и похвастать «16 сек до десктопа», так в очередь выстраиваются, а как systemd говном полить — так «не нужно». Фанатики, что с них взять.
	Ответить | Правка | ^ к родителю #398 | Наверх | Cообщить модератору

	430. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 24-Ноя-11, 08:42
	цитаты, где я пинал бубунту за «медленно грузится». тебе же не сложно будет их найти, правда? ну, раз ты мне про это написал.
	Ответить | Правка | ^ к родителю #409 | Наверх | Cообщить модератору

	412. "Разработчики systemd представили Journal, замену системе..."	+1 +/–
	Сообщение от Аноним (??) on 23-Ноя-11, 15:43
	> вот это — квинтэссенция. винда in all it's glory. Да ну брось. У винды все как обычно. То-есть, где-то в глубине - концепция может и была не столь уж и гумно. А вот фактическая реализация - люто-бешеный звездец. Все как обычно у MS. Например ядро нт архитектурно не так уж и плохо, потому что архитектили это мозгастые парни из VMS. Но что с ним сделали маркетолухи и индусы - нет слов. Пройдусь по сервисам, т.к. пришлось как-то разок влезть в эти г@вна. Фичи запуска сервисов в винде: 1) Гиморный в редактировании реестр. 2) С совершенно невнятными параметрами. 3) Не допускающий хранения рядом с ними коментариев, в отличие от конфиг-файлов. Встроенного хелпа у сервисов нет, ибо мс не ищет просых путей - см. 5). Манов тоже нет, ибо система ориентирована на даунов. Поэтому два часа траха^W гуглинга по мсдн/течнетам на предмет того какие у сервиса вообще есть параметры - "just in case" просто обеспечены. 4) Приоритеты SCM задавать не может. А оно наверное вообще невозможно в людском виде. Ибо см. пункт 5). 5) Пудаки из микрософта почему-то решили что сервис должен быть ... не, не программой! А дллкой. Видимо ничего умнее они не придумали. В результате есть 1 процесс-стартер и куча гов^W простите, длл "сервисов" висящих в памяти 1 процесса. Ну а мониторить их, особенно на предмет кто сколько ресурсов отожрет - да блин, проблемы негров шерифа Баллмера не волнуют. 6) Рестарт тоже сделан довольно топорно и имбецильно. Лимитироавния числа рестартов не замечено. Или настолько хорошо недокументировано. А если сервис откажется стопаться - он может попасть в состояние "ни вперед ни назад". Убить его как процесс опять же не выйдет. Потому что см. пункт 5). Майкрософт обдурил своим дизайном всех. Даже самих себя. Итого: по совокупности параметров более уе...ской системы старта сервисов я больше вообще нигде, никогда и ни у кого не видел. > потому что остальным совершенно по барабану, пол-минуты или три минуты > стартует система, Ага. Расскажи это допустим системе видеонаблюдения. Которую вполне можно делать на линуксе. Я вижу некую разницу в том стартанет (линуксное ессно) фирмваре камеры за 5 секунд или за 2 минуты. > ибо происходит это… ну, раз в месяц максимум, а то и реже. Даже в этом случае время старта всякой там эмбеддовки например может роялить. Ждать 3 минуты загрузки стиральной машины и прочих холодильников может и подзадолбать. Это не нужно говорите вы? А от и хрен вам отвечаем мы. Компьютеры теперь везде. Они бывают даже вот такие: http://www.opennet.dev/opennews/art.shtml?num=32368 - и для подобной штуки вполне себе роялит, буду я ждать ее загрузки 20 секунд или 3 минуты. Хотя лично меня напрягает даже не столько само по себе время старта сколько нужда закостыливать каждый раз стандартные типовые операции. Все-таки поскольку это не MS, хотелось бы чтобы на проблемы админов не клался бы болт целыми десятилетиями, да.
	Ответить | Правка | ^ к родителю #398 | Наверх | Cообщить модератору

	432. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 24-Ноя-11, 09:12
	> Например ядро нт архитектурно не так уж и плохо, потому что > архитектили это мозгастые парни из VMS. Но что с ним сделали > маркетолухи и индусы — нет слов. нормальное ядро. то, что сверху наложили win32 — это уже другой разговор. равно как то, что ядро NT изначально не было предназначено для x86, его в режиме «щабыстрапартиравать» туда перетащили. > Пройдусь по сервисам, т.к. пришлось как-то разок влезть в эти г@вна. ты эта… немножко не работал с SCM. то, что оно дурацкое — это один разговор. но не настолько, как ты пытаешься показать, ты частности растягиваешь на общее. > Ага. Расскажи это допустим системе видеонаблюдения. Которую вполне можно делать на линуксе. внизапна! при чём тут это? давай ещё притащим сюда эмбеды на 51-м и скажем, что там с линуксом проблемы, ага? > всякой там эмбеддовки ничего, что я про «десктопы» говорил, не? понимаешь, реальные недостатки везде можно найти. для этого не надо из рукава тузы тащить. такие дела.
	Ответить | Правка | ^ к родителю #412 | Наверх | Cообщить модератору

	446. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от Аноним (??) on 29-Ноя-11, 03:57
	>> маркетолухи и индусы — нет слов. > нормальное ядро. то, что сверху наложили win32 — это уже другой разговор. А еще всякие там "микро" драйвера, типа win32k.sys на 2 Мб кода, в котором при таком весе находят баги, что логично. А поскольку оно выводит графику, а графика в каждой дыре - часто получаются всякие приколы вплоть до влета ремотного анимированного курсора из браузера прямо в кернелмод. > равно как то, что ядро NT изначально не было предназначено для > x86, его в режиме «щабыстрапартиравать» туда перетащили. Вообще, оно по изначальному дизайну было задумано платформенно нейтральным, всякие HAL и прочие должны были бы этому помогать. По иронии судьбы, пингвин которого по изначальному дизайну пиляли на i386-only намного портабельнее. Я могу взять с полочки платку на ARM, MIPS, PPC или что там у вас еще и запустить линя. А винду вот не могу. Как обычно, теория пошла лесом при встречей с практикой. >> Пройдусь по сервисам, т.к. пришлось как-то разок влезть в эти г@вна. > ты эта… немножко не работал с SCM. Не, я просто охренел насколько там ж и как-то не горел желанием много, хорошо и долго с ним работать. Ну не враг я себе, да. > то, что оно дурацкое — это один разговор. но не настолько, как ты пытаешься > показать, ты частности растягиваешь на общее. Лично мне не нравится когда сервис стал раком отказавшись стопориться а пристрелить можно только процесс-стартер на котором висит пачка критичных системных сервисов, при том если это все-таки удастся сделать (==хватит прав) - в даун отвалится вообще вся система. Это совершенно не доставляет, особенно при экспериментах. Аналогично кстати и с драйверами. Обалдеть, модульный монолит более динамично грузит модули чем хрень где динамическая загрузка "почти длл" ака дров штатно задумана. Во всяком случае, в лине можно вгрузить свежескомпиленый модуль новой ФС, подмаунтить диск, поработать с этой ФС, отмаунтить, выгрузить нахрен модуль обратно. В особо правильном NTвом ядре что-то так не катит, да? >> Ага. Расскажи это допустим системе видеонаблюдения. Которую вполне можно делать на линуксе. > внизапна! при чём тут это? давай ещё притащим сюда эмбеды на 51-м > и скажем, что там с линуксом проблемы, ага? При том что линь как ни странно на этих эмбедах используется сотнями миллионов. Хорошо когда система масштабируется. А 51-е уже мало кто использует, только сильно некоторые старперы да те кто готов за каждый цент убиться, используя любое г-но если оно хоть на цент дешевле, т.к. тираж 100500 миллионов при ультранизкой цене и нулевом требовании к вычислениям от девайса (всякие там пульты управления унитазом). Только знаешь, система способная запустить линь в сборе со всей обвязкой уже запросто стоит около $25-30. И хорошо если она взлетит за 5 секунд а не за 120. Мало ли что она там делает. >> всякой там эмбеддовки > ничего, что я про «десктопы» говорил, не? А линукс как бы не является жестко прибитым к десктопу. Его успешно пользуют на околоэмбедднутых железках. Всякие дебианы и убунты - на довольно мелких даже. > понимаешь, реальные недостатки везде можно найти. для этого не надо из рукава > тузы тащить. такие дела. Можно. Ну так кому надо - тот пусть и трахается с инитом из его 70-х. А мне это не надо, извини. Я буду использовать то что мне удобнее и то что обладает более хорошими параметрами и минимизирует мой гемор по костылестроению.
	Ответить | Правка | ^ к родителю #432 | Наверх | Cообщить модератору

	447. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 29-Ноя-11, 09:05
	> А еще всякие там «микро» драйвера, типа win32k.sys на 2 Мб кода а что было делать? иначе графика нещадно тормозила. на то время было кривое, но решение. а потом уже переделывать не стали, это бизнес. > Вообще, оно по изначальному дизайну было задумано платформенно нейтральным теория — это хорошо. а практика такова, что из-за архитектуры оно опять тормозило и пришлось окостыливать. > Не, я просто охренел насколько там ж и как-то не горел желанием > много, хорошо и долго с ним работать. Ну не враг я > себе, да. ну и что там за «ж»? таки интересно узнать. то, что для некоторых сервисов есть один мегабинарь — это не проблема SCM, это фэйл реализации конкретных сервисов. а с самим SCM-то что не так? > Лично мне не нравится когда сервис стал раком отказавшись стопориться а пристрелить > можно только процесс-стартер на котором висит пачка критичных системных сервисов, вот ни разу не приходилось. но опять же: это не проблема SCM. > Это совершенно не доставляет, особенно при экспериментах. а никто и не обещал, что «эксперименты» будут удобны. > Аналогично кстати и с драйверами. Обалдеть, модульный монолит более динамично грузит > модули чем хрень где динамическая загрузка «почти длл» ака дров штатно > задумана. Во всяком случае, в лине можно вгрузить свежескомпиленый модуль новой > ФС, подмаунтить диск, поработать с этой ФС, отмаунтить, выгрузить нахрен модуль > обратно. В особо правильном NTвом ядре что-то так не катит, да? про драйвера FS я не в курсе, не знаю. а некоторые другие драйвера можно динамически грузить. хотя странно оно там, да. > При том что линь как ни странно на этих эмбедах используется сотнями > … > за 120. Мало ли что она там делает. отличный был спич. жаль, что на мой вопрос он не отвечает. > А линукс как бы не является жестко прибитым к десктопу. Его успешно > пользуют на околоэмбедднутых железках. Всякие дебианы и убунты — на довольно > мелких даже. и что? я для тебя расшифрую: в контексте разговора мне совершенно наплевать на эмбедовки. ещё раз повторю: не надо из рукава тузы тащить. > Можно. Ну так кому надо — тот пусть и трахается с инитом > из его 70-х. А мне это не надо, извини. Я буду > использовать то что мне удобнее и то что обладает более хорошими > параметрами и минимизирует мой гемор по костылестроению. да трахайся со свомими новомодными перделками, кто же тебе запрещает? собственно, тебе скоро и выбора особого не оставят, насильно запихав какую-нибудь «стартап-систему». а я пешком постою, благодарствую. направлений для улучшения ещё много, но вот init-система — точно не одно из них.
	Ответить | Правка | ^ к родителю #446 | Наверх | Cообщить модератору

	442. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от myhand (ok) on 25-Ноя-11, 14:25
	>> потому что остальным совершенно по барабану, пол-минуты или три минуты >> стартует система, > Ага. Расскажи это допустим системе видеонаблюдения. Которую вполне можно делать на линуксе. > Я вижу некую разницу в том стартанет (линуксное ессно) фирмваре камеры > за 5 секунд или за 2 минуты. И у Вас проблема сделать это на sysvinit за 5 секунд?!  Интересная логика, почему systemd сумеет выполнить задачу на порядок быстрее более мелкой и простой программы? Да, те же самые скрипты, что для общецелевого дистрибутива - для embedded-системы не всегда сгодятся.  Но там много чего еще "не годится" - для того и делают специализированные дистрибутивы. > Хотя лично меня напрягает даже не столько само по себе время старта > сколько нужда закостыливать каждый раз стандартные типовые операции. Какие?
	Ответить | Правка | ^ к родителю #412 | Наверх | Cообщить модератору

	405. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand on 22-Ноя-11, 23:13
	> ВНЕЗАПНО, если мне не хватило фич системы инициализации - вот тогда я из нее и буду звать скрипт-хелпера, который докостылит до нужной кондиции. Но хотелось бы чтобы в 99.9% случаев этого не требовалось. Ну тогда - добро пожаловать в Дахау.  Стройте всех разработчиков и читайте им лекцию на тему того, какие действия ихний демон должон сделать при старте и сколько гемороя на С ради этого они должны тащить. Эффект предсказуем. > Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно костылить все _стандартные_ типовые случаи. Что в точности вкладывается Вами в понятие "_стандартного_ типового случая"? > Я вообще апстарт предпочитаю пока. Оно just works. Вот только знаете, когда конфиг на 5 строк писаный за пару минут делает все ето же что раньше делала пачка костылей и подпорок на 5 кило шеллскрипта, а как бонус система стартует вместо полутора минут 20 секунд, я констатирую EPIC WIN. Делает что?  Как выглядит оный для апача? Кроме того, сколько стартует система - лично меня мало интересует.  Этот старт происходит раз в полгода. > Bash стандартный весит как раз столько. Если не больше. Кто-ж виноват, что Вы bash используете в init-скриптах? > Это с хрена ли 1 раз? Он происходит на каждый старт каждого сервиса. Надо запустить 800К бинарь, распарсить скрипт на 2 страницы, отинтерпретировать, и вот тогда... хм... и все это ради того что делается 1 сисколом? А если посчитать сколько раз за это время сискол выполнится и бинарь запустится, обидно не станет? Для талантливых, повторю: запуск каждого сервиса происходит _один раз_ при старте системы.  При остановке - происходит обратный процесс.  Это типичный сценарий (все чуть сложнее, есть разные runlevel).  А система может работать годами. И, извините, Вы опять врете.  Помимо exec* - Вам может понадобиться приоритеты выставить, лимиты и проч.  Так что даже в Вашей радужной сказке - там отнюдь не один сисколл. >> А в чем, собственно, "геморой"?  Ах, я забыл Вам рассказать о >> том, _какие именно_ есть механизмы...  Ну, rlimits, да те же самые cgroups. > > Они для начала не решают проблему с мониторингом упавшего сервиса вообще. Они для этого и не предназначены.  Это статические ограничения.   Мониторингом занимаются специальные программы. > Дебианщики вроде как раз на похожий по смыслу апстарт и собирались (а потом может и на systemd). Вранье.  Есть эти пакеты в дистрибутиве.  Ничего более.  Приоритет extra - nuff said. >> Постараемся поправить, если он действительно "мутный".   > >Что, вот прямо так во всех пакетах? 8-\ А вы какой пакет майнтайните в дебиане? Насчет всех и сразу не поверю - там майнтайнеры указаны разные. Вы, главное, не переживайте.  Я не поправлю - сделаете баг и другие поправят.  Главное, что Вы блудословие прекратите и приведете пример реальной проблемы. > Внезапно, > 1) Я не люблю опаче за общую монструозность. Его скрипты - вполне в духе опача. Не асилил?  Ну вот вам и контингент пользователей systemd... Такой гибкой архитектуры, как у апача - еще поискать надо. Что "шеллы пинать" возможность есть - эт хорошо, конечно.  Но не лучше ли сразу признать, что никому кроме десктопов эти ноухау нафиг не сдались?  Как что-то полезное запустить, не из поделок Песателя - так вон сразу и шеллы приходится... > В принципе - может. Поэтому неплохо бы еще и простую валидацию в духе monit. Типа сделать соединение по тцп. Отвечает - ок, не отвечает - дыщ, рестарт. В апстарте такого пока еще нет и такое все-таки придется закостылить. В systemd вроде как что-то такое значилось в планах. Совать такое в аналог init - тупо.  Либо получите монстра, там где была простенькая программа с ясным поведением.  Либо получите недомониторинг, который при более-менее серьезном применении нужно просто выключить. > А что еще она должна видеть? Именно это от нее и надо. Повторяю, "именно это" - надо только сегфолтящимся приблудам для десктопа.  Нормальному мониторингу это будет только под ногами мешаться. > Остается только вопрос нахрен при этом нужен init который ничего не умеет. Он умеет.  Запустить программы в заданном порядке при переходе с уровня на уровень.  Очень простой, понятный и логичный функционал.  Это unix.   Другие программы - делают разные другие полезные вещи. > Запуск программы по расписанию - по большому счету разновидность запуска программ. Поэтому, если не ошибаюсь, авторы апстарта и/или системд и на кроны зубы точат, что довольно логично :) Ну, шелл - тоже умеет программы запускать.  Его еще нет в планах? > Да у инита вообще нет задач. И хрен бы с ними с наворотами типа антиддосов, а вот всякие выставления приоритетов, рестарт упавших и взлет в правильный момент времени когда система к этому уже готова - хотелось бы видеть. В инит всего этого нет а в 100500й раз втыкать стандартный костыль - ни разу не прикольно. Задачи init я Вам уже пару раз описал.  Повторяться уже лень. "Выставления приоритетов" (и многое другое для статического ограничения ресурсов) - делаются в init-скриптах.  Один раз.  При настройке системы.  Это задача администратора.  Для того init-скрипты в любом дистрибутиве представляют собой конфигурационные файлы.   И upstart/systemd за Вас данную задачу не решит магически. > Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса. Ее настраивать надо.  Это _сложно_ и ровно нет никакой возможности настроить подобное автоматически.  99% функционала отключено нафиг по-умолчанию. > По минимуму хватило бы простой проверки ответа сервиса на порту. > Чуть получше: уметь посылать заданный набор байтов и проверять что в ответ приехал ожидаемый ответ. Просто сделать, много веса не добавит. А вот в 90% случаев разгрузит человека от работы по рутинному костылингу стандартных проблем. В 90% процентах - это лишний спам в ящике.  Нету телепатии - до эры AI подобные вещи будут настраиваються людьми.  Примите это как факт.  Вот почему в любом дистрибутиве - есть только _примеры_ для скриптов/конфигурации систем мониторинга. > Для вас разумны одни дефолты. Для других - другие. Вот в этом и проблема.  Для десктопа манагера Васи - придется точно также отключить по-умолчанию весь вумный "мониторинг", равно как и для сервера "админа" Коли. Единственный разумный вариант по-умолчанию: если упало - значит что-то не так, пусть админ посмотрит и разберется.   Падать - не должно.  Сообразите где это умолчание реализовано? ;) > Ну так апстарт умеет делать не более чем эн рестартов за эм секунд. Если больше - считаем что сервис окончательно одурел "эм" - это не число.  Это буковки.  Сколько это в цифирь?  Какому сервису какую цифирь выставить?  Не получит ли мейнтейнер пакета по мордасам за то, что выставит эти цифирки? > Нет, я конечно понимаю что можно дойти вплоть до написания юнит-тестов для апача, но это будет слегонца перебор, потому что в конечном итоге сбои в бизнес логике - это уже явно не в компетенции администратора и лечить сие должны програмеры :))) Речь быле не о юнит-тестах.  Апач может быть жив-живехонек, а скриптам отказано в каких-то ресурсах.  Причем, проявиться это может не на главной странице, которая из кеша какого-нить достается, а когда клиент веб-магазина насобирает себе корзину и нажмет кнопку "я хочу дать Вам за это бабло"...
	Ответить | Правка | ^ к родителю #396 | Наверх | Cообщить модератору

	413. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 23-Ноя-11, 15:52
	>> ВНЕЗАПНО, если мне не хватило фич системы инициализации - вот тогда я из нее и буду звать скрипт-хелпера, который докостылит до нужной кондиции. Но хотелось бы чтобы в 99.9% случаев этого не требовалось. > Ну тогда - добро пожаловать в Дахау.  Стройте всех разработчиков и читайте им лекцию на тему того, какие действия ихний демон должон сделать при старте и сколько гемороя на С ради этого они должны тащить. Максимум — руками написать лаунчер, который будет следить за всеми процессами демона и докладывать systemd, есличо? В 90% случаев — хватит systemdшного ini-файла. >> Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно костылить все _стандартные_ типовые случаи. > Что в точности вкладывается Вами в понятие "_стандартного_ типового случая"? 90% демонов. deluged, transmissiond, incrond, ntpd — тысячи их. их запускаешь и они работают. сколько это строк конфига systemd — одна, две? %  wc -l /etc/init.d/ntp 92 /etc/init.d/ntp И 6 (шесть) аналогичного конфига systemd — http://en.gentoo-wiki.com/wiki/Systemd#ntpd Вот ещё пример — конфиг sshd: http://en.gentoo-wiki.com/wiki/Systemd#sshd.socket_.28socket... (тоже шесть строк) Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет. Само собой, %  wc -l /etc/init.d/ssh 181 >> Я вообще апстарт предпочитаю пока. Оно just works. Вот только знаете, когда конфиг на 5 строк писаный за пару минут делает все ето же что раньше делала пачка костылей и подпорок на 5 кило шеллскрипта, а как бонус система стартует вместо полутора минут 20 секунд, я констатирую EPIC WIN. > Делает что?  Как выглядит оный для апача? Вот примерно так — http://www.linux.uz/forum/index.php?topic=2703.0#msg34308 14 (четырнадцать) строк против 282 у меня в системе. Где-то 20кратная разница. > И, извините, Вы опять врете.  Помимо exec* - Вам может понадобиться приоритеты выставить, лимиты и проч.  Так что даже в Вашей радужной сказке - там отнюдь не один сисколл. Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете?
	Ответить | Правка | ^ к родителю #405 | Наверх | Cообщить модератору

	417. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand (ok) on 23-Ноя-11, 18:46
	>> Что в точности вкладывается Вами в понятие "_стандартного_ типового случая"? > 90% демонов. deluged, transmissiond, incrond, ntpd — тысячи их. их запускаешь и они работают. сколько это строк конфига systemd — одна, две? Бессмысленно сравнивать "в строках", пока Вы не учли - что эти строки в sysvinit 1) на высокоуровневом языке 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки) 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_) 4) ExecStartPre/Post + весь с этим связанный код учли? Взамен получена туча строк на C, причем используемых только в одном месте... Без ясного представления автора о том: 1)  какие именно проблемы sysvinit новая система будет решать 2) что мы ей _будем_ делать 3) что мы ей _не будем_ делать Реализация у него идет впереди проектирования.  С системным ПО это не катит. Итог: bloatware будет расти, тащить с собой все новые либы с багами, помимо собственных.  Будет Вам в init и splash, и крон...  И в конце-концов какой-нибудь полноценный скриптовый язык, вместо расширяющегося до бесконечности декларативного INI-говна. > Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет. В чем именно бонус - в экономии на спичках?  Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается.  Зашибись. Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях.  И это надо будет _отключать_, чтобы не мешать работе нормального мониторинга. > "И 6 (шесть) аналогичного конфига systemd — http://en.gentoo-wiki.com/wiki/Systemd#ntpd" "Error 503 Service Unavailable".  Ну, см. на ответ на Ваше первое замечание про "строки". Берите скрипт ssh init скрипт из Debian и показывайте как переписать его.  Там нет указанных выше Ваших проблем с доступностью аргументов (идем на packages.debian.org и смотрим исходный код). > Вот примерно так — http://www.linux.uz/forum/index.php?topic=2703.0#msg34308 > 14 (четырнадцать) строк против 282 у меня в системе. Где-то 20кратная разница. За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian.  Выкинута логика с htcacheclean, выкинута поддержка нескольких экземпляров апача.  Такое и с init можно соорудить.  Сделать шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart.  В init-скрипте Вы выставите просто все эти переменные и подключите шаблон.  Одна строчка. Просто некоторые люди понимают бессмысленность такой "экономии".  Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п.  А вовсе не тупые "case" с вызовами start-stop-daemon. > Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете? Без понятия.  Десятки.  Еще обработка зависимостей, dbus всякие - чего там только нет. Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел.  Сильно подозреваю, что копейки.
	Ответить | Правка | ^ к родителю #413 | Наверх | Cообщить модератору

	427. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 23-Ноя-11, 22:14
	> Бессмысленно сравнивать "в строках", пока Вы не учли - что эти строки в sysvinit > 1) на высокоуровневом языке Зачем? пример systemd наглядно показывает, что без этого можно обойтись. > 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки) Адовый оверхед. > 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_) угу, а 100500 exec()'ов grep/tr — это не bloatware, ага. а boilerplate, который даже закэшировать нормально невозможно — это тоже не bloatware. > 4) ExecStartPre/Post + весь с этим связанный код учли? На каком основании? > Взамен получена туча строк на C, причем используемых только в одном месте... а) вероятнее всего, не в одном б) машинного кода, вообще-то > Без ясного представления автора о том: > 1)  какие именно проблемы sysvinit новая система будет решать г-носкрипты, главным образом > 2) что мы ей _будем_ делать запускать системные сервисы > 3) что мы ей _не будем_ делать известные мне сведения о фичах systemd меня устраивают. ничего лишнего вроде как не наблюдается. > Реализация у него идет впереди проектирования.  С системным ПО это не катит. бла-бла-бла > Итог: bloatware будет расти, тащить с собой все новые либы с багами, помимо собственных.  Будет Вам в init и splash, и крон... С чего бы? plymouth уже есть сервисом. Крон в ините не нужен, хватит сервиса. > И в конце-концов какой-нибудь полноценный скриптовый язык, вместо расширяющегося до бесконечности декларативного INI-говна. Всё лучше, чем шеллскрипты + grep/tr/прочийшлак. Я молчу насколько это маловероятно. >> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет. > В чем именно бонус - в экономии на спичках?  Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается.  Зашибись. а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим ondemand? б) во-первых, это может быть произвольный демон. Вроде mongodb или redis, которыми я практически не пользуюсь. Во-вторых, это отличное решение для реализации диагностической консоли в каком-нить встраиваемом девайсе. > Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях. Вы тупой или нарочно игнорируете факт, что авторестарт прописывается *явно*? Это вопрос, да. Нет, я не уверен. >  И это надо будет _отключать_, чтобы не мешать работе нормального мониторинга. Отключать не надо. *Можно* *включать*. Разберитесь уже там в предмете обсуждения или прекращайте спекулировать, не? >> "И 6 (шесть) аналогичного конфига systemd — http://en.gentoo-wiki.com/wiki/Systemd#ntpd" > "Error 503 Service Unavailable".  Ну, см. на ответ на Ваше первое замечание про "строки". ну сокет-то слушает, не? значит работает. остальное — в конфиги опача. > Берите скрипт ssh init скрипт из Debian и показывайте как переписать его. Чьто, внезапно пример с ntp некорректен? А почему? >> Вот примерно так — http://www.linux.uz/forum/index.php?topic=2703.0#msg34308 >> 14 (четырнадцать) строк против 282 у меня в системе. Где-то 20кратная разница. > За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian.  Выкинута логика с htcacheclean, выкинута поддержка нескольких  экземпляров апача.  Такое и с init можно соорудить.  Сделать  шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart.  В init-скрипте Вы выставите просто все эти переменные и подключите шаблон.  Одна строчка. одна строка + boilerplate, который повторяется в *каждом* скрипте. Меньше значимого текста — меньше ошибок. Всё элементарно. > Просто некоторые люди понимают бессмысленность такой "экономии".  Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п.  А вовсе не тупые "case" с вызовами start-stop-daemon. Так пусть это делает скрипт на сишечьке, только в 100500 раз быстрее и нормально написанный на нормальном ЯП. >> Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете? > Без понятия.  Десятки.  Еще обработка зависимостей, dbus всякие - чего там только нет. Это машинный код, понимаете? Неужели вам нужно объяснять, насколько он быстрее? > Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел.  Сильно подозреваю, что копейки. http://elinux.org/images/b/b3/Elce11_koen.pdf как бы заливисто смеётся вам в лицо. Давайте, продолжайте обмазываться своими шеллскриптами.
	Ответить | Правка | ^ к родителю #417 | Наверх | Cообщить модератору

	429. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand (ok) on 23-Ноя-11, 23:29
	>> Бессмысленно сравнивать "в строках", пока Вы не учли - что эти строки в sysvinit >> 1) на высокоуровневом языке > Зачем? пример systemd наглядно показывает, что без этого можно обойтись. Да.  Наплодив уникального (он только для systemd, в отличие от grep и mount) кода на С.  Можно только _верить_, что в этой _новой_ куче С кода, выполняющегося далеко не от простого пользователя, нет пропорционального количества багов.  Блажен кто верует. >> 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки) > Адовый оверхед. Зато отлаженный и работающий код.  Каждая утилита - делает что-то свое, вместо комбайна, функционал которого непонятно чем ограничен. >> 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_) > угу, а 100500 exec()'ов grep/tr — это не bloatware, ага. а boilerplate, > который даже закэшировать нормально невозможно — это тоже не bloatware. Что там закешировать нельзя?  Десяток бинарников? >> 4) ExecStartPre/Post + весь с этим связанный код учли? > На каком основании? На том, что код шелл-скриптов Вы учли весь.  А эти ExecStartPre/Post - будут указывать как раз на куски старых init-файлов, грубо говоря. >> Взамен получена туча строк на C, причем используемых только в одном месте... > а) вероятнее всего, не в одном б) машинного кода, вообще-то а) Невероятно.  Иначе - соответствующий код вынесли бы в библиотеки. b) в первую очередь - это строки C кода.  Со всеми прелестями разработки на этом низкоуровневом языке. >> Без ясного представления автора о том: >> 1)  какие именно проблемы sysvinit новая система будет решать > г-носкрипты, главным образом Смотрю в /etc/init.d/* - покажите, пожалуйста, пальцем "г-носкрипт".  Эти скрипты - ровно никуда не денутся.  Шаблонная часть вида case "$1" start) ... stop) - может быть уложена в одну строчку и без systemd.  Рассказать как? А все остальное - никуда не денется.  Любой сложный сервис (апач, постфикс) - потребует ExecStartPre/Post и Ваших нелюбимых "г-носкриптов" там. >> 2) что мы ей _будем_ делать > запускать системные сервисы Что Вы вкладываете в это понятие?  Это пресс-релиз какой-то, а не техническое задание.  Расшифруйте.  *Как* запускать? Что при этом делать, а что - не делать и оставить для других утилит. >> 3) что мы ей _не будем_ делать > известные мне сведения о фичах systemd меня устраивают. ничего лишнего вроде как > не наблюдается. Зачем Вам понадобился dbus?  Как выставление всяческих rlimit-ов, приоритетов IO-шедулера и проч. относится к старту сервиса?  Вот, появятся у linux новые крутилки ресурсов - Леннарт добавит параметр в соответствующую секцию?  И так - до бесконечности? Где граница того, что "архитектор" этой приблуды скажет "хватит - делаем exec shell-скрипта и пусть там админ сам вызывает утилиты для настройки соответствующих параметров". >> Реализация у него идет впереди проектирования.  С системным ПО это не катит. > бла-бла-бла Покажите спецификацию systemd.  Как я уже просил, в духе _полного_ списка решаемых задач.  А не списка "фич", который выглядит потенциально неограниченым сверху. >>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет. >> В чем именно бонус - в экономии на спичках?  Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается.  Зашибись. > а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим > ondemand? А что мешает потом его поломать? > б) Во-вторых, это отличное решение для реализации диагностической > консоли в каком-нить встраиваемом девайсе. Это в первую очередь - "отличное решение", чтобы получить проблему не в четко известное время (при старте сервисов), а хрен знает когда. Поймите, я не просто ругаю.  Мне непонятно - абсолютно-ли необходима эта "фича" Вашей "запускалке для сервисов".  Может, лучше ее было бы выкинуть - а сервис, который потребует такого счастья запускать через специальную обертку? >> Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях. > Вы тупой или нарочно игнорируете факт, что авторестарт прописывается *явно*? Это вопрос, > да. Нет, я не уверен. Из документации systemd.service - не очевидно.  Ткните, где четко сказано про такое умолчание. Буду рад, если ошибся. >> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его. > Чьто, внезапно пример с ntp некорректен? А почему? Вы не поняли? Вот почему: "Error 503 Service Unavailable".   >> За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian.  Выкинута логика с htcacheclean, выкинута поддержка нескольких  экземпляров апача.  Такое и с init можно соорудить.  Сделать  шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart.  В init-скрипте Вы выставите просто все эти переменные и подключите шаблон.  Одна строчка. > одна строка + boilerplate, который повторяется в *каждом* скрипте. Меньше значимого текста > — меньше ошибок. Всё элементарно. Вы не поняли.  Одной строкой - можно запросто описать один сервис.  При желании.  Конечно, только достаточно простой.  Т.е. вся логика "case $1 start) ... stop) ..." - может быть вынесена в одну строчку. А вот остальной "boilerplate" - повторяется как раз не в каждом скрипте.  И ровно никуда в systemd - не денется - он просто перекочует в ExecStartPre/Post. >> Просто некоторые люди понимают бессмысленность такой "экономии".  Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п.  А вовсе не тупые "case" с вызовами start-stop-daemon. > Так пусть это делает скрипт на сишечьке, только в 100500 раз быстрее > и нормально написанный на нормальном ЯП. Зашибись.  Будем плодить ошибки и дырки в работе со строками, только чтобы не использовать высокоуровневые инструменты.  Как раз предназначеные для автоматизации системных задач. Откуда число 100500?  "От фонаря" ведь - никаких реальных цифр у Вас нет. >>> Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете? >> Без понятия.  Десятки.  Еще обработка зависимостей, dbus всякие - чего там только нет. > Это машинный код, понимаете? Неужели вам нужно объяснять, насколько он быстрее? Объясняйте, конечно.  Может появятся таки цифры от Вас - а может кому-то "объяснение" даст повод улыбнуться ;) >> Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел.  Сильно подозреваю, что копейки. > http://elinux.org/images/b/b3/Elce11_koen.pdf как бы заливисто смеётся вам в лицо. Давайте, > продолжайте обмазываться своими шеллскриптами. Что с чем сравнивалось - ежа с ужом?  Там до systemd была реализованна полноценная поддержка LSB-совместимых скриптов?  Или запуск был последовательным?  Такая "прИзентация" - смеется в лицо прежде всего своему автору, фанату "рокзвезд".  Да и Вам заодно.
	Ответить | Правка | ^ к родителю #427 | Наверх | Cообщить модератору

	437. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 24-Ноя-11, 13:58
	> Да.  Наплодив уникального (он только для systemd, в отличие от grep и mount) кода на С.  Можно только _верить_, что в этой _новой_ куче С кода, выполняющегося далеко не от простого пользователя, нет пропорционального количества багов.  Блажен кто верует. Ох мать. Теперь мы с багами боремся. А апелляция к вере вообще абсурдна. Предпочитаю оперировать фактами. Извините. Вот факты — https://bugs.freedesktop.org/buglist.cgi?product=systemd&com...--- И да, как по-вашему, что быстрее и проще — preg_match() или grep? /usr/bin/mount или mount()? >>> 2) используют кучу общесистемных утилит (сделанных не только для обеспечения загрузки) >> Адовый оверхед. > Зато отлаженный и работающий код.  Каждая утилита - делает что-то свое, вместо комбайна, функционал которого непонятно чем ограничен. А systemd запускает сервисы согласно их описанию в конфигах. Всё. чем не «что-то своё»? >>> 3) не учли код самого bloatware (~50k, без учета кучи библиотек), в сравнении с простым sysvinit (~8k _весь_ код, в т.ч. всякие telinit, _без_) >> угу, а 100500 exec()'ов grep/tr — это не bloatware, ага. а boilerplate, который даже закэшировать нормально невозможно — это тоже не bloatware. > Что там закешировать нельзя?  Десяток бинарников? байткод повторяющихся кусков, из которых оные г-носкрипты состоят чуть менее, чем полностью. >>> 4) ExecStartPre/Post + весь с этим связанный код учли? >> На каком основании? > На том, что код шелл-скриптов Вы учли весь.  А эти ExecStartPre/Post - будут указывать как раз на куски старых init-файлов, грубо говоря. Ну не обязательно же. Зачем всю дорогу передёргивать? systemd в этих местах делает самый обычный exec(). что в нём — забота maintainerа. >>> Взамен получена туча строк на C, причем используемых только в одном месте... >> а) вероятнее всего, не в одном б) машинного кода, вообще-то > а) Невероятно.  Иначе - соответствующий код вынесли бы в библиотеки. Исходники доступны, доказывайте. > b) в первую очередь - это строки C кода.  Со всеми прелестями разработки на этом низкоуровневом языке. это C-то низкоуровневый? Это вы ещё на асме и машкодах не писали. >>> Без ясного представления автора о том: >>> 1)  какие именно проблемы sysvinit новая система будет решать >> г-носкрипты, главным образом > Смотрю в /etc/init.d/* - покажите, пожалуйста, пальцем "г-носкрипт".  Эти скрипты - ровно никуда не денутся.  Шаблонная часть вида case "$1" start) ... stop) - может быть уложена в одну строчку и без systemd.  Рассказать как? start-stop-daemon? > А все остальное - никуда не денется.  Любой сложный сервис (апач, постфикс) - потребует ExecStartPre/Post и Ваших нелюбимых "г-носкриптов" там. которые внезапно запросто можно реализовать в виде маленьких элегантных бинарников. ну или г-носкриптов — на любителя. >>> 2) что мы ей _будем_ делать >> запускать системные сервисы > Что Вы вкладываете в это понятие?  Это пресс-релиз какой-то, а не техническое задание.  Расшифруйте.  *Как* запускать? Что при этом делать, а что - не делать и оставить для  других утилит. То есть на sysvinit ТЗ не нужно, а на systemd — обязательно, так? >>> 3) что мы ей _не будем_ делать >> известные мне сведения о фичах systemd меня устраивают. ничего лишнего вроде как не наблюдается. > Зачем Вам понадобился dbus? Зачем и всем — слать типизированные сообщения кому попало, не заморачиваясь необходимостью проверять, запущен ли этот самый кто попало. Нет, сигналы для этого непригодны. >  Как выставление всяческих rlimit-ов, приоритетов IO-шедулера и проч. относится к старту сервиса? Вот, появятся у linux новые крутилки ресурсов - Леннарт добавит параметр в соответствующую секцию?  И так - до бесконечности? То есть как в initскрипте прописать ionice — так нормально и правильно, а как systemd сказать, чтобы выставил нужный приоритет — так ненужно и нерелевантно. Двоемыслие во все поля, да. Ну и да, добавлять — не убирать. BC не ломает. > Где граница того, что "архитектор" этой приблуды скажет "хватит - делаем exec shell-скрипта и пусть там админ сам вызывает утилиты для настройки соответствующих параметров". Это можно делать уже сейчас — sh -c в любом из Exec*'ов. А Леннарту (я убеждён) вообще пофиг, как это используется. >>> Реализация у него идет впереди проектирования.  С системным ПО это не катит. >> бла-бла-бла > Покажите спецификацию systemd.  Как я уже просил, в духе _полного_ списка решаемых задач.  А не списка "фич", который выглядит потенциально неограниченым сверху. Беглый гуглёж не нашёл спеки на sysvinit. Двойные стандарты во все поля. >>>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет. >>> В чем именно бонус - в экономии на спичках?  Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается.  Зашибись. >> а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим ondemand? > А что мешает потом его поломать? Напомните-ка, зачем-зачем нужно ломать то, что работает? >> б) Во-вторых, это отличное решение для реализации диагностической консоли в каком-нить встраиваемом девайсе. > Это в первую очередь - "отличное решение", чтобы получить проблему не в четко известное время (при старте сервисов), а хрен знает когда. Тестируется на раз. Поэтому мимо. > Поймите, я не просто ругаю.  Мне непонятно - абсолютно-ли необходима эта "фича" Вашей "запускалке для сервисов".  Может, лучше ее было бы выкинуть - а сервис, который потребует такого счастья запускать через специальную обертку? Эта фича — просто приятный бонус. Не более. >>> Отдельный бонус - эта тварь будет пытаться отрестартить сервис при известных условиях. >> Вы тупой или нарочно игнорируете факт, что авторестарт прописывается *явно*? Это вопрос, да. Нет, я не уверен. > Из документации systemd.service - не очевидно.  Ткните, где четко сказано про такое умолчание. Буду рад, если ошибся. Элементарно — http://cgit.freedesktop.org/systemd/tree/man/systemd.service... Нашлось за 5 минут. >>> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его. >> Чьто, внезапно пример с ntp некорректен? А почему? > Вы не поняли? Вот почему: "Error 503 Service Unavailable". error 503? у ntpd? Брысь обратно в свою параллельную вселенную. >>> За исключением того, что Вы выкинули большую часть функционала init-скрипта апача в том же Debian.  Выкинута логика с htcacheclean, выкинута поддержка нескольких  экземпляров апача.  Такое и с init можно соорудить.  Сделать  шаблон с именем сервиса, строкой вызова сервиса и стандартным параметром start/stop/restart.  В init-скрипте Вы выставите просто все эти переменные и подключите шаблон.  Одна строчка. >> одна строка + boilerplate, который повторяется в *каждом* скрипте. Меньше значимого текста — меньше ошибок. Всё элементарно. > Вы не поняли.  Одной строкой - можно запросто описать один сервис. При желании.  Конечно, только достаточно простой.  Т.е. вся логика "case $1 start) ... stop) ..." - может быть вынесена в одну строчку. Но не выносится. Чуть менее, чем везде — https://gist.github.com/6af2f58c87cd97e1ec08 > А вот остальной "boilerplate" - повторяется как раз не в каждом скрипте. И ровно никуда в systemd - не денется - он просто перекочует в ExecStartPre/Post. Это решать maintainerу, systemd тут ничего не навязывает. Хотя я бы предпочёл маленькие бинарнички. >>> Просто некоторые люди понимают бессмысленность такой "экономии".  Большая часть кода init-скрипта в Debian - обработка опций из /etc/default, разрешение конфликтов конфигурации (админ конфиги не обновил, использует старые параметры в default и т.п.), организация chroot для сервиса и т.п.  А вовсе не тупые "case" с вызовами start-stop-daemon. >> Так пусть это делает скрипт на сишечьке, только в 100500 раз быстрее и нормально написанный на нормальном ЯП. > Зашибись.  Будем плодить ошибки и дырки в работе со строками, только чтобы не использовать высокоуровневые инструменты.  Как раз предназначеные для автоматизации системных задач. Can't into getopt и stdlib? > Откуда число 100500?  "От фонаря" ведь - никаких реальных цифр у Вас нет. Предположение, да. Бенчить лень. >>>> Три? Пять? Во сколько раз это меньше кол-ва сисколлов sh/grep/sed/tr/прочего шлака, сами посчитаете? >>> Без понятия.  Десятки.  Еще обработка зависимостей, dbus всякие - чего там только нет. >> Это машинный код, понимаете? Неужели вам нужно объяснять, насколько он быстрее? > Объясняйте, конечно.  Может появятся таки цифры от Вас - а может кому-то "объяснение" даст повод улыбнуться ;) Да вы и сами добудете эти цифры. Года через три. >>> Во сколько выражается разница в скорости загрузки - на реалистичном случае (LSB-совместимая система загрузки, как в Debian vs systemd тамже) я так и не увидел.  Сильно подозреваю, что копейки. >> http://elinux.org/images/b/b3/Elce11_koen.pdf как бы заливисто смеётся вам в лицо. Давайте, продолжайте обмазываться своими шеллскриптами. > Что с чем сравнивалось - ежа с ужом?  Там до systemd была реализованна полноценная поддержка LSB-совместимых скриптов?  Или запуск был последовательным? Такая "прИзентация" - смеется в лицо прежде всего своему автору, фанату "рокзвезд".  Да и Вам заодно. Теперь вы показываете, как userspace грузится за аналогичное время, но на sysvinit. Вот тогда мы и похохочем.
	Ответить | Правка | ^ к родителю #429 | Наверх | Cообщить модератору

	438. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand (ok) on 24-Ноя-11, 16:13
	>>>> Берите скрипт ssh init скрипт из Debian и показывайте как переписать его. >>> Чьто, внезапно пример с ntp некорректен? А почему? >> Вы не поняли? Вот почему: "Error 503 Service Unavailable". > >error 503? у ntpd? Брысь обратно в свою параллельную вселенную. Нет, тупица.  У цитированного сайта генты.  Он был недоступен, причем оба раза - когда я отвечал. > Предпочитаю оперировать фактами. Извините. Вот факты — https://bugs.freedesktop.org/buglist.cgi?product=systemd&com... Это _известные_ баги.  И покуда systemd никому (кроме федоры) нафиг не упал. А факты Вам - пожалуйста.  Берем init-скрипты Debian, шерстим там на предмет всевозможных бинарников, идем в багтрекер и смотрим на количество багов в этих бинарниках.  Шаг второй: идем на родные странички проектов и добавляем баги из upstream.  Не забывайте в "Closed" состоянии добавить. Можете смело ограничиться ошибками работы с памятью.  Если Поттеринг не волшебный суперасс - почему у него в коде багов на эту тему будет меньше, чем в сопоставимой по размеру базе C кода? > байткод повторяющихся кусков, из которых оные г-носкрипты состоят чуть менее, чем полностью. "Не читал, но осуждаю" (с)  Приведите "повторяющиеся куски" и их отношение к уникальным на конкретном примере init-скриптов - раз.  Два - объясните, почему их нельзя закешировать. >> На том, что код шелл-скриптов Вы учли весь.  А эти ExecStartPre/Post - будут указывать как раз на куски старых init-файлов, грубо говоря. > > Ну не обязательно же. Зачем всю дорогу передёргивать? systemd в этих местах делает самый обычный exec(). что в нём — забота maintainerа. Но разве не Вы хвалились, что _все_ в каждом скрипте из /etc/init.d/* будет сведено к паре строк в конфиге systemd.  Ну так вот - не будет, для мало-мальски сложного сервиса.  Примеры я приводил.  Так что скрипты в ExecStartPre/Post - извольте учитывать. >>>> Взамен получена туча строк на C, причем используемых только в одном месте... >>> а) вероятнее всего, не в одном б) машинного кода, вообще-то >> а) Невероятно.  Иначе - соответствующий код вынесли бы в библиотеки. > > Исходники доступны, доказывайте. Пожалуйста.  Смотрите на пакет в Debian - никаких либ из исходников systemd не собирается, кроме интерфейсов для взаимодействия с ним (libsystemd-daemon0, libsystemd-login0).  Там даже на 5% не наберется.  Все остальное - systemd-only. >> b) в первую очередь - это строки C кода.  Со всеми прелестями разработки на этом низкоуровневом языке. > это C-то низкоуровневый? Это вы ещё на асме и машкодах не писали. Да. C - низкоуровневый язык.  "Переносимый ассемблер".  На чем я не писал - можешь дальше фантазировать. >> Смотрю в /etc/init.d/* - покажите, пожалуйста, пальцем "г-носкрипт".  Эти скрипты - ровно никуда не денутся.  Шаблонная часть вида case "$1" start) ... stop) - может быть уложена в одну строчку и без systemd.  Рассказать как? > start-stop-daemon? start-stop-daemon, да.  Но он и без того там есть.  Просто при желании можно достаточно стандартный кусок "case $1 start) ... stop) ..." c вызовами start-stop-daemon - оформить как функцию.  И просто ее вызывать.  Будет строчка или две - в духе ExecStart & Description.  Просто кто-то понимает, что смысла в подобном рукоблудстве нуль - а кто-то нет. >> А все остальное - никуда не денется.  Любой сложный сервис (апач, постфикс) - потребует ExecStartPre/Post и Ваших нелюбимых "г-носкриптов" там. > которые внезапно запросто можно реализовать в виде маленьких элегантных бинарников. ну или г-носкриптов — на любителя. Да.  _Можно_.  Но делать никто не будет.  Останутся скрипты - как и было.  Люди не любят экономить на спичках в ущерб своему удобству. Так и запишем: "Shell-free bootup" - полная лажа.  Ничего подобного systemd, вообще говоря, не обеспечивает.  Кроме специализированных/игрушечных ситуаций.  Кстати, при желании - подобное может и sysvinit.  man inittab >> Что Вы вкладываете в это понятие?  Это пресс-релиз какой-то, а не техническое задание.  Расшифруйте.  *Как* запускать? Что при этом делать, а что - не делать и оставить для  других утилит. > То есть на sysvinit ТЗ не нужно, а на systemd — обязательно, так? Для sysvinit давно уже есть стандарты (см. man, спецификации LSB) и стабильная реализация. >>  Как выставление всяческих rlimit-ов, приоритетов IO-шедулера и проч. относится к старту сервиса? Вот, появятся у linux новые крутилки ресурсов - Леннарт добавит параметр в соответствующую секцию?  И так - до бесконечности? > То есть как в initскрипте прописать ionice — так нормально и правильно, а как systemd сказать, чтобы выставил нужный приоритет — так ненужно и нерелевантно. Двоемыслие во все поля, да. "Прописать в init-скрипте" - никак не относится к функционалу init.  Есть утилиты или интерфейсы ядра типа /sys - можно "прописать".  Появятся новые крутилки в ядре - init никак не изменится.  А что будет с systemd?  Не вижу двоемыслия - есть банальная неопределенность в том, какие задачи будет решать systemd и какие _не будет_.  Имеем bloatware by design. >> Где граница того, что "архитектор" этой приблуды скажет "хватит - делаем exec shell-скрипта и пусть там админ сам вызывает утилиты для настройки соответствующих параметров". > Это можно делать уже сейчас — sh -c в любом из Exec*'ов. А Леннарту (я убеждён) вообще пофиг, как это используется. Вот и я про то, что ему "пофиг".  Эта "фича" крутая - давай прикрутим.  Вот на таком уровне все "проектирование". > Беглый гуглёж не нашёл спеки на sysvinit. Двойные стандарты во все поля. Если Вы "гуглите" man-страницы или LSB - мне Вас жаль... >>>>> Отдельным бонусом идёт старт сервиса не при загрузке, а при первом стуке в сокет. >>>> В чем именно бонус - в экономии на спичках?  Сисадмин узнает, что с sshd что-то не так (конфиг кривой, к примеру) - не на этапе загрузки, а когда кто-то залогиниться попытается.  Зашибись. >>> а) Что-то мешает отладить конфиг обычным порядком и потом переключить в режим ondemand? >> А что мешает потом его поломать? > > Напомните-ка, зачем-зачем нужно ломать то, что работает? Затем, что люди делают ошибки.  Например - могут ошибиться при очередном изменении конфигурации демона. >>> б) Во-вторых, это отличное решение для реализации диагностической консоли в каком-нить встраиваемом девайсе. >> Это в первую очередь - "отличное решение", чтобы получить проблему не в четко известное время (при старте сервисов), а хрен знает когда. > > Тестируется на раз. Поэтому мимо. Это как?  При любом рестарте - лезть сразу на сервис, только чтобы убедиться в его работоспособности?  Нет другого способа - испорченный конфиг только один источник проблемы при последующем старте on-demand....   В чем тогда смысл "фичи"? >> Поймите, я не просто ругаю.  Мне непонятно - абсолютно-ли необходима эта "фича" Вашей "запускалке для сервисов".  Может, лучше ее было бы выкинуть - а сервис, который потребует такого счастья запускать через специальную обертку? > Эта фича — просто приятный бонус. Не более. И таких вагон.  Грамотно спроектированное системное приложение - имеет четко очерченный функционал.   Без всяких "бонусов", приятных или нет. >> Из документации systemd.service - не очевидно.  Ткните, где четко сказано про такое умолчание. Буду рад, если ошибся. > Элементарно — http://cgit.freedesktop.org/systemd/tree/man/systemd.service... Нашлось за 5 минут. Клоун, я уже упомянул этот документ: "из документации systemd.service - не очевидно".  Покажите мне где там очевидным образом указаны умолчания для Restart.  Эта директива вообще - опциональна или нет?  Какие вообще директивы в описании сервиса _не опциональны_? И сравните с форматом inittab для контраста.  В последнем - явно указано, что поле action _не является_ опциональным.  И, в частности, respawn там должен быть прописан явно. > Но не выносится. Чуть менее, чем везде — https://gist.github.com/6af2f58c87cd97e1ec08 Потому что люди не видят в этом проблему. >> А вот остальной "boilerplate" - повторяется как раз не в каждом скрипте. И ровно никуда в systemd - не денется - он просто перекочует в ExecStartPre/Post. > Это решать maintainerу, systemd тут ничего не навязывает. Хотя я бы предпочёл маленькие бинарнички. Мда, тяжелый случай.  Сколько Вам лет, если не секрет? :)  Сможете ответить на этот вопрос честно? Вы действительно так и не поняли, с учетом всех моих объяснений и примеров, почему эти "маленькие бинарничики" - не появятся _никогда_? >> Откуда число 100500?  "От фонаря" ведь - никаких реальных цифр у Вас нет. > Предположение, да. Бенчить лень. >> Объясняйте, конечно.  Может появятся таки цифры от Вас - а может кому-то "объяснение" даст повод улыбнуться ;) > Да вы и сами добудете эти цифры. Года через три. Ну, вот и кончен разговор про "машинный код" и прочую лабуду от Вас.  Кстати, "года через три" - будет wheezy и в планах там даже отдаленно systemd не значится.  Не все какашки поттеринга суют куда не попадя... > Теперь вы показываете, как userspace грузится за аналогичное время, но на sysvinit. Вот тогда мы и похохочем. У меня десктоп грузится за ~< 5 сек (точнее не измерял, т.к. на уровне "на глаз не заметно").  Организуете мне такую же как  в статье железку для тестов и оплатите мое время - покажу как и что можно сделать на sysvinit.
	Ответить | Правка | ^ к родителю #437 | Наверх | Cообщить модератору

	418. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 19:58
	[del] > Ну тогда - добро пожаловать в Дахау.  Стройте всех разработчиков и > читайте им лекцию на тему того, какие действия ихний демон должон сделать при старте Я никого строить не собираюсь, время само выпилит мамонтов в пользу млекопитающих. [del] > и сколько гемороя на С ради этого они должны тащить. Демоны один хрен пишутся на си. И никакого геморроя в этом нет. Вот колупать простынки весом в полсырца демона чтобы только запустить его так как надо - это геморрой, да. > Эффект предсказуем. Я уже на себе ощутил его. С апстартом. То что раньше я делал за 2 часа копания в кривых и глюкавых скриптах писаных какими-то лабухами на коленке да еще с хардкодом имени сервиса и прочих радостей прямо в скрипте в середине оного, теперь делает конфиг на 5-7 строк который набрасывается за 5 минут из первой же нагугленой болванки (можно даже ман не читать, все и так очевидно). С точки зрения администрирования - небо и земля. >> Я не сомневаюсь что можно прошибить все стены своим лбом. Но слегка утомительно >> костылить все _стандартные_ типовые случаи. > Что в точности вкладывается Вами в понятие "_стандартного_ типового случая"? Например, собрал я некую прогу. Которой в репах нет. Демона, ессно. Что еще на серверах кроме них водится? Надо стало быть запустить. А вот тут опа. Потому что стартового скрипта обычно или нет совсем, или он кривой до ужаса. Никакого вам мониторинга состояния демона не умеет. Или это делается адски криво (вплоть до прописывания в крон скрипта-чекера который раз в несколько минут ищет pid и перезапускает демон если pid не найден). > Делает что?  Как выглядит оный для апача? Без понятия: не пользуюсь (апачем, за тормознутость). Да и для апача - какой-нибудь скрипт или конфиг рабочий всяко будет в пакете, поэтому мне с его написанием геморроиться не придется. А вот для чего-то отсутствующего в репах (или даже самописного) - этого быть ни разу не обязано. И это запросто может стать именно _моей_ проблемой. А я получаюсь шкурно заинтересован чтобы такая вполне типовая проблема решалась просто и быстро. > Кроме того, сколько стартует система - лично меня мало интересует.  Этот > старт происходит раз в полгода. Меня для начала волнует мое удобство. Многокилобайтные простыни которые не обеспечивают даже элементарного рестарта сервиса при откровенном его падении - как-то не сильно удобно и требует кучи костылирования. >> Bash стандартный весит как раз столько. Если не больше. > Кто-ж виноват, что Вы bash используете в init-скриптах? Не, давайте я еще буду разучивать языки 100500 разных интерпретаторов. Вот всю жизнь мечтал изучить все существующие на планете интерпретеры, аж два раза (для надежности). > Для талантливых, повторю: запуск каждого сервиса происходит _один раз_ при старте системы. Вообще-то это ниоткуда не следует. Вообще, есть еще всякие шедуленые мероприятия, изменения состояний системы и прочая. >  При остановке - происходит обратный процесс.  Это типичный сценарий > (все чуть сложнее, есть разные runlevel).  А система может работать годами. Может работать. А может не работать. А еще надо б мониторить что сдохло. А еще надо б по расписанию гонять задания. А еще неплохо б отслеживать различные события. И так далее. > И, извините, Вы опять врете.  Помимо exec* - Вам может понадобиться > приоритеты выставить, лимиты и проч.  Так что даже в Вашей > радужной сказке - там отнюдь не один сисколл. В простейшем случает один. Ну пусть даже пяток, с лимитами и приоритетом. По факту получается 5-7 строчек конфига. Что намного лучше тех мегарпостыней где г-но размазано по простыне на 2 страницы в меру дури ее автора, где в середине порой захардкожено имя сервиса и прочее. Всякие там приоритеты и лимиты авторы скриптов вообще не реализуют - это мне самому предлагается докостылить. Самым простым докостылингом выглядит дописать пару строк в мизерный конфиг, а не лопатить простыню на 2 экрана, извините. >> Они для начала не решают проблему с мониторингом упавшего сервиса вообще. > Они для этого и не предназначены.  Это статические ограничения.   > Мониторингом занимаются специальные программы. Угу. А инит вообще непонятно чем занимается. Висит в памяти все время работы ситемы. Больше он нихрена не умеет. Поэтому докостыливать всякие там расстановки приоритетов/лимитов/перезапуски и прочее приходится самолично. Вот радости то, каждый раз делать одну и ту же мартышкину работу в не сильно удобном виде. > Вранье.  Есть эти пакеты в дистрибутиве.  Ничего более.  Приоритет extra - nuff said. А потом удивляются когда википедики всякие валят на убунты, а не дебиан. Ну вот админы - тоже люди. И чем удобнее и быстрее с системой управляться - тем лучше. Особенно если серверов много а админов мало. >>> Постараемся поправить, если он действительно "мутный".   >>Что, вот прямо так во всех пакетах? 8-\ А вы какой пакет майнтайните в дебиане? >>Насчет всех и сразу не поверю - там майнтайнеры указаны разные. > Вы, главное, не переживайте.  Я не поправлю - сделаете баг и другие поправят.   Я и не переживаю: при наличии целой кучи дистров можно просто выбрать тот в котором наиболее удобно. Так, на подумаь: в серверной убунте менее архаичный софт, более удобная система инициализации и есть на выбор LTS ветка для тех кому стабильность, и обычная для тех кому свежак. Поэтому ее юзеж на сервере в общем случае для меня менее геморроен. А апстарт - мелкая, но довольно приятная фича. Вносящая свою капельку веса при складывании разных дистров на разные чаши весов и принятии решения "а чего же мне все-таки использовать из всего этого великолепия у себя?" > Главное, что Вы блудословие прекратите и приведете пример реальной проблемы. Реальная проблема: сервис которого нет в репах. Самосборный или еще не попавший в оные. Мне написать ему конфиг для апстарта в 10 раз проще и быстрее чем возиться с скриптошитом на несколько страниц, которые сделает то же самое, но с куда большей возней и хучшим результатом. >> Внезапно, >> 1) Я не люблю опаче за общую монструозность. Его скрипты - вполне в духе опача. > Не асилил?   Нет, просто открыл для себя nginx и lighttpd и узнал что серверу совсем не обязательно быть 16-ядерным монстром с 128Гб оперативки чтобы выдерживать целую толпу народа. Кстати верно замечено: у меня нет цели "осилить именно апач и никак иначе". Я совершенно иными целями оперирую. Вот "показ юзеру странички форума" или там "отдача файла", желательно подешевле и пооптимальнее - это да, годная цель. А "асилить" и "понтануться" - это видимо что-то такое "для риальных пасанов на раене", с такими целями - не ко мне. > Ну вот вам и контингент пользователей systemd... Ну вообще-то апстарта в основном, но это не мешает признавать что systemd местами задуман неплохо. Вот правда реализует это Поттеринг, что как-то стремновато, увы. > Такой гибкой архитектуры, как у апача - еще поискать надо. Такой жуткой архитектуры и реализации как у апача - еще поискать надо. Получился огромный и тормозной ресурсожоркий переросток, благодаря которому некоторые искренне полагают что машины с менее 16 ядер и 128 гиг памяти сервировать в принципе не способны, даже 10 человек. > Что "шеллы пинать" возможность есть - эт хорошо, конечно.  Но не > лучше ли сразу признать, что никому кроме десктопов эти ноухау нафиг не сдались? Да я как-то и на сервере не дурак попользоваться апстартом. Потому что мне тупо удобнее и куда быстрее прописать 5-7 строк конфига чем ворочать многокилобайтные портянки, зело непохожие друг на друга и очень разные по качеству кода в них. > Как что-то полезное запустить, не из поделок Песателя > - так вон сразу и шеллы приходится... Да вообще-то я несколько нужных лично мне демонов недавно на серваке запустил через апстарт. Доставило. Это оказалось намного проще и быстрее чем, простите, то же самое на шеллскриптах городить через инит. Вот напрасно я боялся этого апстарта, наслушавшись всяких козлов, что там все извратно и сложно. Оказалось что просто как топор, пример конфига гуглится за 5 минут и вообще намного проще чем колупать портянки на 2 экрана весьма различные по конструкции (или отсутствующие) у разных авторов софта. >> пока еще нет и такое все-таки придется закостылить. >> В systemd вроде как что-то такое значилось в планах. > Совать такое в аналог init - тупо.  Либо получите монстра, там > где была простенькая программа с ясным поведением.   И в каком месте тот же monit монстр? По сути это почти инит, только сделанный менее через задницу и куда более соответствующий жизненным реалиям. Остается только вопрос - а нахрен инит место в списке процессов тогда занимает, ась? Бесполезный балласт. > Либо получите недомониторинг, который при более-менее серьезном применении > нужно просто выключить. Нормальные программы имеют свойство быть модульными и допускать внешние компоненты. Тот же monit не такой уж и монструоный в общем то. >> А что еще она должна видеть? Именно это от нее и надо. > Повторяю, "именно это" - надо только сегфолтящимся приблудам для десктопа.  Нормальному > мониторингу это будет только под ногами мешаться. Это скорее инит с его обрубками будет под ногами мешаться. Нифига не умеет но почему-то за главного. Нафиг-нафиг, за столько лет уже можно наконец сделать выводы о типовых граблях из жизни демонов и разгрузить админов от костылинга этого самолично. >> Остается только вопрос нахрен при этом нужен init который ничего не умеет. > Он умеет.  Запустить программы в заданном порядке при переходе с уровня > на уровень.  Очень простой, понятный и логичный функционал.   Да, просто немного не соответствует современным требованиям, а так сущая ерунда. > Это unix.   Другие программы - делают разные другие полезные вещи. Linux к счастью не юникс. Поэтому те кто хочет орудовать каменным топором, 1970-х годов разработки - в своем праве. А я вот пришел к выводу что на основе опыта хорошо бы делать выводы. > Ну, шелл - тоже умеет программы запускать.   И еще много кто. Чем шелл лучше них? > Его еще нет в планах? Не думаю. Чем шелл лучше остальных? И не вижу особых проблем от запуска внешнего шелла. > Задачи init я Вам уже пару раз описал.  Повторяться уже лень. Если честно - мне глубоко пополам на какие-то там "задачи init". А это кто такое и почему это меня должно интересовать? Мне не пополам на _мои_ задачи и насколько много геморроя у меня будет. Вы прикиньте? :))) > "Выставления приоритетов" (и многое другое для статического ограничения ресурсов) - > делаются в init-скриптах.   А в апстарте такое делается тупо в конфиге оного. Что проще и быстрее. > Один раз.   Что, благородный дон замуровывает сервера в стену? А я вот иногда могу возжелать доуствноить какой-то еще сервис, если полагаю что это надо. > При настройке системы.   Уй, надо еще добавить что 640 кило хватит всем. Чтобы уж наверняка. > Это задача администратора. И я шкурно заинтересован чтобы мне было просто и удобно разруливать мои задачи. Внеазпно. > Для того init-скрипты в любом дистрибутиве представляют собой > конфигурационные файлы.   Обычно они являют собой месиво из г-нокода, констант распиханых по всему файлу а порой и имен сервисов захардкоженых где-то в середине скрипта. Особенно хорошо когда нужного сервиса нет в пакетах, поэтому где я возьму скрипты - резко превращается в мою проблему. При этом узнаешь много нового о качестве кода, г-нокоде, месиве и что где захардкожено, когда пытаешься взять за болванку чье-то готовое от соседнего демона, казалось бы достаточно похожего по смыслу. В такой ситуации ака "старт с нуля" как-то оказалось что проще всего накатать конфиг апстарту, а вовсе не городить многоэтажные макароны из кучи шеллскриптов. > И upstart/systemd за Вас данную задачу не решит магически. Конечно. Что так что сяк мне придется в одном случае писать конфиг, в втором писать или дорабатывать скрипты. Первое получается намного проще и быстрее и потом результат куда приятнее для глаз. Как бонус еще и система быстрее стартует. >> Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости >>сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса. > Ее настраивать надо.  Это _сложно_ и ровно нет никакой возможности настроить > подобное автоматически.   Да чего там сложного? Самый тривиальный и действенный метод верификации демона сводится к всего 3 кусочкам в конфиге. 1) Что и куда послать, по какому протоколу, etc. 2) Что и за какой таймаут должно приехать в ответ. На основании подобной логики вполне  можно делать вывод о живости типовых сетевых демонов и их работе. Анализ всякой бизнес-логики уже не дело мониторинга, пожалуй. Там все-равно програмеры смогут накосячить кучей методов неуловимых автоматически. Иначе б автотесты давно уже привели бы к искоренению багов как таковых. Чего как-то не наблюдается. > 99% функционала отключено нафиг по-умолчанию. См. выше чего хотел бы видеть в такой штуке лично я. Это позволит чекать кучу сервисов от хттп сервера до почтаря вполне адекватно проверяя их живость и способность ответить за таймаут. По минимуму около 2-3 строк конфига выходит. Всякий совсем ынтерпрайз конечно пихать туда ни к чему (хотя если кому надо и они напищут себе отдельный плагин, врядли кто будет отбиваться ногами). >> По минимуму хватило бы простой проверки ответа сервиса на порту. >> Чуть получше: уметь посылать заданный набор байтов и проверять что в ответ приехал >> ожидаемый ответ. Просто сделать, много веса не добавит. А вот в 90% случаев разгрузит >> человека от работы по рутинному костылингу стандартных проблем. > В 90% процентах - это лишний спам в ящике.   Какой спам? В какой ящике? Кто и зачем будет спамить? > Нету телепатии - до эры AI подобные вещи будут настраиваються людьми.  Примите > это как факт.  Вот почему в любом дистрибутиве - есть только _примеры_ > для скриптов/конфигурации систем мониторинга. Опять же, настраивать ынтырпрайзный мониторинг чтобы чекать аж почтарь, хытытыпы и какойнить там днс на мелком сервачке - явный оверкилл и подобное вполне мог бы делать и тот кто их запускает. Нехай станет не только запускачем но и супервизором работы, пусть не самым забористым но покрывающим 90-95% простых случаев и осваиваемый за 2 минуты. Геморроиться с расстановкой костылей для этого лично - не очень охота. Доставать ынтырпрайзные махины для проверки того что хттп сервак не сдох - тоже. >> Для вас разумны одни дефолты. Для других - другие. > Вот в этом и проблема.  Для десктопа манагера Васи - придется  точно также > отключить по-умолчанию весь вумный "мониторинг", равно как и для сервера "админа" Коли. Что значит - отключать? Включаться он должен только если я изъявил желание чтобы сервис мониторился на живость. Куда-то по соседству с настройками рестартов и их допустимого количества. > Единственный разумный вариант по-умолчанию: если упало - значит что-то не так, пусть > админ посмотрит и разберется.   Падать - не должно.   Падать не должно. Но если это какой-то автомат стоящий в чистом поле за тридевядь земель, посмотреть и разобраться может означать поездку за сотни километров в какую-то ж-у мира чтобы какой-то хренов демон поднять. Особенно весело будет если это по причине типа "из космоса прилетела частица с высокой энергией и перевернула таки битик в нужный момент". > Сообразите где это умолчание реализовано? ;) У меня немного другой взгляд на проблему. Фэйл должен быть залогген и я должен бы получить о нем уведомление, но вот караулить постоянно как цербер? Лично? Окарауливайте, я не против. Вахтер тоже человек. >> Ну так апстарт умеет делать не более чем эн рестартов за эм секунд. Если больше - >> считаем что сервис окончательно одурел > "эм" - это не число.  Это буковки.  Сколько это в цифирь?   По вкусу и здравому смыслу. Я например полагаю что если сервис умер более 5 раз за минуту - тут что-то капитально не так и он сломался окончательно, так что дальнейшие попытки подъема чреваты только лишней нагрузкой и шансами пригрузить систему постоянными рестартами процессов, с шансами усложнить алмину ремотный вход. Но поскольку параметр настраиваемый, каждый сам решает сколько вешать в граммах. > Какому сервису какую цифирь выставить?   На усмотрение админа, имхо. Что использую я в типовом случае я написал. Для каких-то сильно монструозных или специальных применений цифры наверное могут быть и иные. Если сервис только взлетает минуту, вероятно окно мониторинга стоит сделать в несколько минут минимум чтобы успешно ловить циклические рестарты чреватые большой нагрузкой на систему.В моем случае минута - с большим запасом, а 5 - порог моей толерантности к частоте падений сервисов после которого я начинаю всерьез полагать что "легче пристрелить чем прокормить". > Не получит ли мейнтейнер пакета по мордасам за то, что выставит эти цифирки? Не думаю. А за что? В дефолтах все-равно на всех не угодишь, а какие-то прописывать надо. По вашей логике все майнтайнеры должны дружно ходить с синей рожей. А то параметров много разных. И дефолтов для них. Безотносительно к upstart/systemd/прочим, в те или иные дефолты что-то приходится прописывать. [del] >> это будет слегонца перебор, потому что в конечном итоге сбои в бизнес логике - это уже >> явно не в компетенции администратора и лечить сие должны програмеры :))) > Речь быле не о юнит-тестах.  Апач может быть жив-живехонек, а скриптам > отказано в каких-то ресурсах.   Может. Однако _все_ ошибки такого класса вы _никакими_ мыслимыми тестами не поймаете. Это не я придумал. Есть такая теорема что одна программа никогда не сможет полностью и достоверно выдать заключение о том как работает другая произвольная програма. Вы хотите делать то что невозможно даже теоретически? :) А с простым вариантом справится и простой монитор: 1) Шлем на адрес:порт вот это, это и это. Пусть "это" будет запросом к скрипту с ожидаемым результатом. 2) Проверяем что за таймаут приехал ответ ожидаемого содержания. Это базовая проверка что демон не сдох и работает. Остальное уже явно выходит за компетенцию запускалки. Хотя-бы потому что всякие там обломы прав доступа и прочие багоглюки рестартом сервиса вообще не лечатся. > Причем, проявиться это может не на главной странице, которая из кеша > какого-нить достается, а когда клиент веб-магазина насобирает себе корзину > и нажмет кнопку "я хочу дать Вам за это бабло"... Это на грани невозможного (анализ поведения одной программой другой произвольной программы). Как бы вы ни изгалялись, а такой шанс останется всегда. Транзакции не от хорошей жизни придумали. А как раз чтобы минимизировать вред от факапов когда все навернулось в именно такой вот момент. И в любом случае это уже не компетенция запускалки: если у вас скажем место закончилось и не удается лог записать, то сколько ни перезапускай сервис, ничего не изменится. Что монитор может сделать? rm -rf / разве что? Единственный универсальный патч от всех бед :)
	Ответить | Правка | ^ к родителю #405 | Наверх | Cообщить модератору

	428. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand (ok) on 23-Ноя-11, 22:19
	> Я никого строить не собираюсь, время само выпилит мамонтов в пользу млекопитающих. Мамонты - тоже млекопитающие ;)  Кто кого еще выпилит. > Я уже на себе ощутил его. С апстартом. То что раньше я делал за 2 часа копания в кривых и глюкавых скриптах писаных какими-то лабухами на коленке да еще с хардкодом имени сервиса и прочих радостей прямо в скрипте в середине оного, теперь делает конфиг на 5-7 строк который набрасывается за 5 минут из первой же нагугленой болванки (можно даже ман не читать, все и так очевидно). С точки зрения администрирования - небо и земля. Можно пример Вашего "делания", ради чего Вы 2 часа копались?  И бага в дистрибутиве, где Вы "хардкод имени сервиса в середине" заметили. > Например, собрал я некую прогу. Которой в репах нет. Демона, ессно. Что еще на серверах кроме них водится? Надо стало быть запустить. А вот тут опа. Потому что стартового скрипта обычно или нет совсем, или он кривой до ужаса. Никакого вам мониторинга состояния демона не умеет. 1) Написать init-скрипт - дело на несколько минут.  Обычно любая уважающая себя "прога" содержит один из вариантов такового. 2) Никакого "мониторинга состояния демона" в init-скрипте и не надо.  Почему - уже объяснял. > Нет, просто открыл для себя nginx и lighttpd и узнал что серверу совсем не обязательно быть 16-ядерным монстром с 128Гб оперативки чтобы выдерживать целую толпу народа. Апач тут непричем.  Просто кто-то некомпетентен, не удосужившись прочитать его документацию, вместо хавту по говноблогам про установку nginx... > Кстати верно замечено: у меня нет цели "осилить именно апач и никак иначе". Я совершенно иными целями оперирую. Вот "показ юзеру странички форума" или там "отдача файла", желательно подешевле и пооптимальнее - это да, годная цель. Хорошая цель.  Вот и узнайте как это умеет делать апач, прежде чем его хаять.  Да, ради этого придется и в его документацию заглянуть.  Познакомиться с тем что представляет собой схема фронтенд+бакенд, в чем ее приемущества, какие mpm удобно где использовать. Не нужно думать, что 90% нагруженых сайтов (и как минимум - половина на апаче) _не использующих_ nginx (по статистике на сайте автора) - имеют тупоголовых админов. > Такой жуткой архитектуры и реализации как у апача - еще поискать надо. Получился огромный и тормозной ресурсожоркий переросток Думаю, в подобном тоне дальнейший разговор бессмысленный.  Ваше образование явно оставляет желать лучшего.  Хотите продолжить - сбавьте тон в "критике" того, о чем не имеете ни малейшего понятия. nginx хорош, для определенных ролей и определенных типов нагрузки.  Это не значит, что разработчики апача глупы и не знают как писать сервисы.  До гибкости апача, продуманной архитектуры - nginx еще пилить и пилить. >>> пока еще нет и такое все-таки придется закостылить. >>> В systemd вроде как что-то такое значилось в планах. >> Совать такое в аналог init - тупо.  Либо получите монстра, там >> где была простенькая программа с ясным поведением.   > > И в каком месте тот же monit монстр? По сути это почти инит, только сделанный менее через задницу и куда более соответствующий жизненным реалиям. Остается только вопрос - а нахрен инит место в списке процессов тогда занимает, ась? Бесполезный балласт. Для задачи _запуска сервисов в заданном порядке_ monit - это монстр.  Тут не нужны произвольные проверки по TCP/UDP, проверки по протоколам прикладного уровня и прочая.  В частности и _необходимость_ для администратора его конфигурации в каждом отдельном случае. > Нормальные программы имеют свойство быть модульными и допускать внешние компоненты. Тот же monit не такой уж и монструоный в общем то. Один такой уже "надопускал" внешних компонент в pulseaudio.  Процесс с PID 1 - очень важная программа, работающая с привелегиями администратора и крайне важно держать его функционал в четко определенных рамках, не обвешивая плагинами по-уши. > Многокилобайтные простыни которые не обеспечивают даже элементарного рестарта сервиса при откровенном его падении - как-то не сильно удобно и требует кучи костылирования. 1) sysvinit это умеет.  man inittab 2) не хотите простого - настройте нормальный мониторинг (в котором "простыни", кстати, как раз пригодятся для рестарта сервиса) >> Для того init-скрипты в любом дистрибутиве представляют собой >> конфигурационные файлы.   > Обычно они являют собой месиво из г-нокода, констант распиханых по всему файлу а порой и имен сервисов захардкоженых где-то в середине скрипта. Я смотрю в /etc/init.d/ и не вижу особого говнокода.  Конкретно, проблем описанных Вами.  Пожалуйста, прекратите быть голословным.  Инит-скрипты сервисов в Debian - доступны.  Либо Вы приводите пример - либо прекращаете этот словесный понос. >> И upstart/systemd за Вас данную задачу не решит магически. > > Конечно. Что так что сяк мне придется в одном случае писать конфиг, в втором писать или дорабатывать скрипты. Первое получается намного проще и быстрее и потом результат куда приятнее для глаз. Как бонус еще и система быстрее стартует. Это _для Вас_ "проще и быстрее".  Вы настраиваете для сервиса chroot?  Очищаете дисковый кеш для mod_cache_disk, как делает init-скрипт апача? Именно подобные вещи - нетривиальны в init-скриптах.  Остальное - при желании можно шаблонизировать.  Просто никто, кроме Вас, свои проблемы в строчках шаблонного кода не измеряет. >>> Я бы хотел там видеть в том числе и какую-то базовую систему мониторинга живости >>>сервисов которые он же и запускает, чуть больше чем просто отслеживание падения процесса. >> Ее настраивать надо.  Это _сложно_ и ровно нет никакой возможности настроить >> подобное автоматически.   > >Да чего там сложного? Самый тривиальный и действенный метод верификации демона сводится к всего 3 кусочкам в конфиге. >1) Что и куда послать, по какому протоколу, etc. >2) Что и за какой таймаут должно приехать в ответ. > >На основании подобной логики вполне  можно делать вывод о живости типовых сетевых демонов и их работе. Анализ всякой бизнес-логики уже не дело мониторинга, пожалуй. Т.е. "пациент скорее жив, чем мертв", а работает ли что на самом деле у клиента - не наша забота.  Клиент сам позвонит и вежливо расскажет? Ну и какими должны быть "строчки в конфиге"?  Напомню, они там _должны_ быть и _иметь смысл по-умолчанию_.  Не предъявите их - мой тезис о необходимости конфигурации мониторинга остается в силе. > Какой спам? В какой ящике? Кто и зачем будет спамить? Ваш мониторинг.  При каждом рестарте сервиса, как минимум.  Или волшебная конфигурация по-умолчанию подразумевает, что письма Вы отправите в /dev/null? > Опять же, настраивать ынтырпрайзный мониторинг чтобы чекать аж почтарь, хытытыпы и какойнить там днс на мелком сервачке - явный оверкилл и подобное вполне мог бы делать и тот кто их запускает. Нехай станет не только запускачем но и супервизором работы, пусть не самым забористым но покрывающим 90-95% простых случаев и осваиваемый за 2 минуты. А отключать это счастье сколько минут Вы будете, чтобы нормальный мониторинг настроить? > Что значит - отключать? Включаться он должен только если я изъявил желание чтобы сервис мониторился на живость. Вроде systemd и upstart уже делают это _по-умолчанию_, нет? > Падать не должно. Но если это какой-то автомат стоящий в чистом поле за тридевядь земель... Тогда Вам нужно установить мониторинг.  Не для всех эта задача актуальна, поймите.  Кому-то - достаточно чтобы система просто запустила определенные скрипты при старте. > У меня немного другой взгляд на проблему. Фэйл должен быть залогген и я должен бы получить о нем уведомление, но вот караулить постоянно как цербер? Тогда Вам нужен полноценный мониторинг.  Какой смысл получать уведомления только о _части_ потенциальных проблем? >> "эм" - это не число.  Это буковки.  Сколько это в цифирь?   > По вкусу и здравому смыслу. >> Какому сервису какую цифирь выставить?   > На усмотрение админа, имхо. Ну вот видите.  Мониторинг _требует_ конфигурации.  Причем - локального админа.  Мейнтейнеру пакета для сколь-либо сложного сервиса - цифирки расставить, скорее всего, не получится. >> Не получит ли мейнтейнер пакета по мордасам за то, что выставит эти цифирки? > Не думаю. А за что? В дефолтах все-равно на всех не угодишь, а какие-то прописывать надо. Отключить нафиг.  Вот такой дефолт и выставят.  Может завершим блудословие и Вы циферки нарисуете?  Вы мейнтейнер пакета nginx.  Че пропишем?  Какой таймаут, как часто и куда ходить? > Это на грани невозможного (анализ поведения одной программой другой произвольной программы). Как бы вы ни изгалялись, а такой шанс останется всегда. Это не анализ - а элементарный тест работы приложения.  "Шанс" остается всегда - просто разумные люди стремятся узнать пораньше о наличии проблем и исправить их, по-возможности автоматически.  Штатная задача системы мониторинга. > И в любом случае это уже не компетенция запускалки Вот именно.  Итак, что произойдет с "функционалом мониторинга" этой запускалки - его отключат ради нормального.  Ну и нафига он тогда нужен?  Пусть запускалка - запускает и больше под ногами не мешается.  Это и делает sysvinit. > если у вас скажем место закончилось и не удается лог записать, то сколько ни перезапускай сервис, ничего не изменится. Что монитор может сделать? rm -rf / разве что? В случае нормального мониторинга: "То, что настроит локальный админ".  Это может быть и очистка логов, и остановка каких-то сервисов.
	Ответить | Правка | ^ к родителю #418 | Наверх | Cообщить модератору

	439. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от kpykcb (ok) on 24-Ноя-11, 21:23
	> Это гибкое решение.  В шелле можно вызвать утилиты, для последующего ограничения > процесса.  И не ждать, покуда наш Песатель соизволит к systemd > прикрутить соответствующие крутилки или сам сервис получит соответствующие ключи для командной > строки... Для тех, кто сам дажее пробовал инетересоваться, systemd совместим с классическим init это раз и я вообще не вижу сложности научить какую либо программу запускать шелл-скриты (точнее запускать интерпретатор, кот. их выполнит). Потому не плачьте, ваши костыли останутся при вас.
	Ответить | Правка | ^ к родителю #388 | Наверх | Cообщить модератору

	440. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от myhand (ok) on 24-Ноя-11, 21:44
	>> Это гибкое решение.  В шелле можно вызвать утилиты, для последующего ограничения >> процесса.  И не ждать, покуда наш Песатель соизволит к systemd >> прикрутить соответствующие крутилки или сам сервис получит соответствующие ключи для командной >> строки... > >Для тех, кто сам дажее пробовал инетересоваться, systemd совместим с классическим init это раз и я вообще не вижу сложности научить какую либо программу запускать шелл-скриты (точнее запускать интерпретатор, кот. их выполнит). Да мы как раз и не плачем...  Если бы они поломали совместимость совсем (а они таки немного поломали) - эта поделка никому бы не сдалась вообще. Другое дело, что необходимость в этих скриптах остается в реальности.  Так что Поттеринг, строго говоря, тупо врет про "Shell-free bootup".  Они перекочуют в ExecStartPre/Post.   Идите, расскажите как Вы для постфикса сделаете chroot без запуска скриптов (не путать это с заданием RootDirectory)... Во-вторых, как я уже писал - к чему вообще эти тонны LimitDATA и проч. крутилок в конфиге сервиса systemd?  Поттеринг когда-нибудь остановится?  Или с выходом _каждой_ новой возможности ограничивать процессы в новом релизе ядра - будут добавляться новый параметр в ублюдочный INI-конфиг? В sysvinit все четко: вот это мы делаем, а вот все остальное - нет.  А здесь - bloatware на C без четко очерченного функционала.
	Ответить | Правка | ^ к родителю #439 | Наверх | Cообщить модератору

	394. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Andrew Kolchoogin on 22-Ноя-11, 19:12
	> Или на кой он нужен если ничего не умеет? Э, стоять! А svc.startd и svc.admind кто пускать будет, я, что ли?! :)))
	Ответить | Правка | ^ к родителю #381 | Наверх | Cообщить модератору

	397. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 20:22
	> А svc.startd и svc.admind кто пускать будет, я, что ли?! Первую программу запускает кёрнел. Вот только ниоткуда не следует что это должен быть sys v init с его каменными топорами.
	Ответить | Правка | ^ к родителю #394 | Наверх | Cообщить модератору

	273. "Разработчики systemd представили Journal, замену системе sys..."	–2 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:11
	> А что systemd? У меня в новой opensuse он **очень** быстро грузит систему, например. Да пофигу, с какой скоростью он систему грузит! Эта штуковина более-менее красиво решает хренову тучу наболевших админских проблем, которые до этого кое-как прикрывались костылями. Ее стоило бы ставить, даже если бы она не давала никакого ускорения.
	Ответить | Правка | ^ к родителю #16 | Наверх | Cообщить модератору

	287. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от kpykcb (ok) on 20-Ноя-11, 02:07
	>> А что systemd? У меня в новой opensuse он **очень** быстро грузит систему, например. > Да пофигу, с какой скоростью он систему грузит! > Эта штуковина более-менее красиво решает хренову тучу наболевших админских проблем, которые > до этого кое-как прикрывались костылями. Ее стоило бы ставить, даже если > бы она не давала никакого ускорения. +1. Поставил бы больше, но нельзя :). Если я правильно помню оригинальную статью. Упор делается на _управление сервисами_ на базе возможностей linux cgroups, а простой способ конфигурации и ускорение загрузки за счет избавления от триллиона форков при запуске и предварительного создания сокетов и т.д., что выливается в ускорение загрузки. И это ускорение загрузки просто доп. плюшка, на которую и обратит внимание десктопный пользователь, когда сгинет последний инит шелл-скрипт :). Но конечная скорость загрузки отдельно взятой машины величина все равно случайная, зависящая например от конкретного набора сервисов и т.д.
	Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

	356. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от anonymous (??) on 21-Ноя-11, 13:14
	> Да пофигу, с какой скоростью он систему грузит! > Эта штуковина более-менее красиво решает хренову тучу наболевших админских проблем, которые > до этого кое-как прикрывались костылями. Ее стоило бы ставить, даже если > бы она не давала никакого ускорения. А insserv благородному дону не подойдёт?
	Ответить | Правка | ^ к родителю #273 | Наверх | Cообщить модератору

	382. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 15:26
	> А insserv благородному дону не подойдёт? Приведите пожалуйста его плюсы в студию. Для благородных донов.
	Ответить | Правка | ^ к родителю #356 | Наверх | Cообщить модератору

	18. "Разработчики systemd представили Journal, замену системе sys..."	–2 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 00:59
	> P.S. сам не программист, но анализируя отзывы о Л.Поттеринге и кол-во проблем при реализации его изобретений, что-то скептически отношусь к такому нововведению > анализируя отзывы > отзывы вам не приходило в голову, что те, кого systemd/pulseaudio/networkmanager устраивают, не пишут о них _ничего_? А что половина (если не 95%) хаятелей — просто безмозглые хомячки, заучившие наизусть мантры и откладывающие кирпичи потому, что приходится (оужас) напрягать мозг?
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	22. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 01:10
	за ссылку выше - спасибо, почитаем. за остальное - неспасибо. хамство и заочное "охомячивание" людей, высказывающих иную точку зрения всегда неприятно. с напряжением мозга даже и комментировать не хочется. опеннетовские аналитики решили, что каждый пользователь должен взять и во всём всенепременно разобраться, ага. кстати, NM - то ещё поделие, не всегда работающее. PulseAudio - так себе. когда работает - не замечаешь. но когда не работает или работает не так - черпануть придётся немало. насчёт systemd - ну стоит он у меня в новой opensuse и чего? вижу только, что загружаться дольше стало. при дефолтных настройках. хотя, может и не конкретно systemd вина
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	108. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 09:03
	> за остальное - неспасибо. хамство и заочное "охомячивание" людей, высказывающих иную точку зрения всегда неприятно. Извините, но 95% даже не утруждаются хотя бы какой-нибудь аргументацией. Для меня их высказывания являются информационным шумом. Не хомячки, нет? > с напряжением мозга даже и комментировать не хочется. опеннетовские аналитики решили, что каждый пользователь должен взять и во всём всенепременно разобраться, ага. Нуачо, взялся судить что-то — изволь в этом разобраться, да. Чтобы потом не макали лицом в собственную лужу например (как с «бинарными службами» или «конфигами в XML») > кстати, NM - то ещё поделие, не всегда работающее. report a bug > PulseAudio - так себе. когда работает - не замечаешь. но когда не работает или работает не так - черпануть придётся немало. ALSA — так себе. когда работает — не замечаешь, но когда не работает или работает не так — черпануть придётся немало. > насчёт systemd - ну стоит он у меня в новой opensuse и чего? вижу только, что загружаться дольше стало. при дефолтных настройках. > хотя, может и не конкретно systemd вина главное — заявить, что *не* работает
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	139. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 12:46
	> Извините, но 95% даже не утруждаются хотя бы какой-нибудь аргументацией. Для меня > их высказывания являются информационным шумом. Не хомячки, нет? хомячки - это животные. и да, хватит уже округлять всё до 95%. у многих такая тяга - себя в 5% умных, интеллектуальных и обычных вносить, а всех остальных (т.е. несогласных или отличающихся чем-то) - в 95% "обычных" людей. > Нуачо, взялся судить что-то — изволь в этом разобраться, да. Чтобы потом > не макали лицом в собственную лужу например (как с «бинарными службами» > или «конфигами в XML») я про бинарные службы ничего не говорил, не ко мне. > report a bug стараюсь не использовать NM. а когда что-то не работает, то репорты уже, как правило, есть. > ALSA — так себе. когда работает — не замечаешь, но когда не > работает или работает не так — черпануть придётся немало. смешное передразнивание. оценил, да. > главное — заявить, что *не* работает читать умеем? я не говорил, что "*не* работает". я говорил, что работает. но не так, как хотелось бы.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	181. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 15:23
	> хомячки - это животные. > и да, хватит уже округлять всё до 95%. > у многих такая тяга - себя в 5% умных, интеллектуальных и обычных вносить, а всех остальных (т.е. несогласных или отличающихся чем-то) - в 95% "обычных" людей. есть что по существу сказать? подавляющее большинство поттерингоненавистников itt не утруждают себя аргументацией, отделываясь общими фразами. Так что нет, это не те 95%. И да, к животным они ближе, т.к. не пользуются мозгом. >> Нуачо, взялся судить что-то — изволь в этом разобраться, да. Чтобы потом не макали лицом в собственную лужу например (как с «бинарными службами» или «конфигами в XML») > я про бинарные службы ничего не говорил, не ко мне. Это просто пример. По сути возражения есть? Полагаю, что таки нет. >> ALSA — так себе. когда работает — не замечаешь, но когда не работает или работает не так — черпануть придётся немало. > смешное передразнивание. оценил, да. Чьто не так? разве в ALSA не магия под капотом? Просто глючит реже.
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	221. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от bootforce on 19-Ноя-11, 18:11
	а нахрена мне приходится использовать свой мозг (а точнее тратить время) на разбор принципов работы с новым велосипедом? причем зачастую велосипеды именно что имеют новый интерфейс или тонкости настройки, но при этом заметных новых фич не прибавляют. мне приходится поддерживать продукт на куче разных линуксовых дистров и вот на разбор федоркиных экспериментов зачастую больше всего времени уходит.
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	291. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 20-Ноя-11, 02:50
	> а нахрена мне приходится использовать свой мозг (а точнее тратить время) на разбор принципов работы с новым велосипедом? причем зачастую велосипеды именно что имеют новый интерфейс или тонкости настройки, но при этом заметных новых фич не прибавляют. да прямо-таки и не прибавляют? http://www.opennet.dev/opennews/art.shtml?num=30412
	Ответить | Правка | ^ к родителю #221 | Наверх | Cообщить модератору

	393. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Andrew Kolchoogin on 22-Ноя-11, 19:07
	> Просто глючит реже. Чаще. Заметно чаще. У меня мой приятель "с нуля" на libalsa пытался кое-что писать для Maemo. Вы знаете, я выучил инвективную лексику финского языка. ;)
	Ответить | Правка | ^ к родителю #181 | Наверх | Cообщить модератору

	395. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 19:15
	> Заметно чаще. У меня мой приятель "с нуля" на libalsa пытался кое-что > писать для Maemo. > Вы знаете, я выучил инвективную лексику финского языка. ;) sudo umount /dev/hands ; sudo mount /dev/hands /mnt/shoulders
	Ответить | Правка | ^ к родителю #393 | Наверх | Cообщить модератору

	194. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от zerot (ok) on 19-Ноя-11, 16:37
	человек в принципе высокоразумное и высокодуховное животное (и то в потенциале), ничего унизительного вроде в этом нет - записывать "в быдло" не разделяющих ваши взгляды - нормальный психологический приём. оне вам жить мешают своим существованием и поддержкой потока чужих понятий. если бы их не было - разделяющие ваши понятия не тратились бы на сосуществование с ЭТИМ, и жить было бы приятнее и удобнее. только не забывайте вежливо общаться с ЭТИМ, всех не перестреляешь - а про поделия - на мой взгляд старые "намоленные" init.d и syslog вполне качественны и вписываются в юникс вэй. Другое дело, что править там особо нечего - они "просто работают", вот и появляются персонажи, желающие прославится изобретение сложного велосипеда там, где востребованы простые - Вот например чудо-криптография вполне замещается выделенным сервером логгирования в сети, с выносом на ленты или болванки. У меня в своё время DVD болванка забивалась архивированными логами за два дня
	Ответить | Правка | ^ к родителю #139 | Наверх | Cообщить модератору

	374. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Aleks Revo on 22-Ноя-11, 07:30
	> Вот например чудо-криптография вполне замещается выделенным сервером логгирования в сети, с выносом на ленты или болванки Ё? Типа нет данных в компе - лучшая защита данных от воровства и подделки? ))) А как же быть, когда они нужны для анализа? Заново распаковывать, занимать место где-то на дисках? Народ вот свои костыли пишет, логи в базу гонит для анализа. А специализированная база может оказаться во многих случаях круче и дешевле для этих задач, причём "искаропки".
	Ответить | Правка | ^ к родителю #194 | Наверх | Cообщить модератору

	392. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 19:06
	> Ё? Типа нет данных в компе — лучшая защита данных от воровства > и подделки? ))) ты не поверишь, но… > А как же быть, когда они нужны для анализа? а так и быть: анализировать. > Заново распаковывать, занимать место где-то на дисках? понимать так, что journal хранится в астрале и место не занимает? > Народ вот свои костыли пишет, логи в базу гонит для анализа. ага. по *своим* алгоритмам. и ровно то же самое будет делать с journal, только матерясь, потому что обычная текстовая обработка накрылась слонячей пилоткой. > специализированная база может оказаться во многих случаях круче и дешевле для > этих задач, причём «искаропки». для задач перегона логов в свои базы по своим алгоритмам? ни разу не круче.
	Ответить | Правка | ^ к родителю #374 | Наверх | Cообщить модератору

	165. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от Прохожий (??) on 19-Ноя-11, 14:12
	А через что по вашему pulseaudio работает? Pulseaudio это только сервер, на который подаются звуковые потоки от разных приложений, а вывод осуществляется через alsa, с которой обычно нет проблем, проблемы заключаются только в том, что поддерживает ли alsa данную звуковую карту, есть ли модуль (драйвер) или нет, а с pulseaudio проблем куда больше.
	Ответить | Правка | ^ к родителю #108 | Наверх | Cообщить модератору

	357. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 13:38
	SystemD, NM, PulseAudio - это все системное ПО. Если хомячок думает, что сможет так же лихо управляться с ним, как и со своим любимым браузером, то он сильно заблуждается, и это его личные проблемы. Жаловаться в сети на неосиляторство системных сервисов глупо.
	Ответить | Правка | ^ к родителю #22 | Наверх | Cообщить модератору

	367. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от emg81 (ok) on 21-Ноя-11, 18:34
	> SystemD, NM, PulseAudio - это все системное ПО. Если хомячок думает, что > сможет так же лихо управляться с ним, как и со своим > любимым браузером, то он сильно заблуждается, и это его личные проблемы. > Жаловаться в сети на неосиляторство системных сервисов глупо. угу. когда через NM, например, невозможно залогиниться никак - это "хомячок" сразу. логин с паролем ведь так сложно ввести. а альтернативными методами (консольно настроить и поднять) работает сразу, как же так? а так, что NM - глючное тупое поделие. вообще, странные анонимы пошли. неужто кто-то думает, что с Gentoo, настройкой и сборкой ядра, USE-флагами и кучей конфигов в /etc/ человек смог (хоть и не так сложно, как кажется, но всё же это не "ОК" и "Далее" нажимать в любом случае), а вот, с NM например, НЕОЖИДАННО не справился *по своей вине*? логика где?
	Ответить | Правка | ^ к родителю #357 | Наверх | Cообщить модератору

	371. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 00:52
	s/системное/костыльное/
	Ответить | Правка | ^ к родителю #357 | Наверх | Cообщить модератору

	52. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 02:38
	Значит так: - PulseAudio снес, после того как выяснилось что без GDM (или KDM) он работать не будет, - именно они обеспечивают ему "дырку" в системе для работы от имени рута, - я же пользуюсь slim. Пришлось сильноооо напрячься что бы эту гадость убрать из системы, но я не жалаю об этом. - NeywokManger - ничего не скажу - работает и работает. Едиственно смущает его завязка на Polkit, но пака это мне не мешает - Systemd. Не ставил и НЕ буду ставить. Никогда. Резко отрицательно отношусь к идее делать бинарные сервисы. Я скорее сделаю свою загрузку на питоне (и да - с мультипроцессной поддержкой), чем буду юзать то, от чего убегал из винды лет десять назад. По сабжу: - "Journal будет частью systemd и не сможет использоваться обособленно" Это уже глюк и нарушает ключевой девиз "Каждый инструмент выполняет хорошо свою задачу сам. Из иструментов формируем связки (конвееры)" - "Все логи будут проиндексированы и хранится в бинарных файлах, к которым к сожалению будут неприменимы стандартные утилиты обработки текстовых данных, например, grep" Тут же хочется спросиь: а почему это сохранение целостности и введение подписей (что само по себе и не плохо) потребовало ухода от техстового формата?! Это что такое обязательное условие. Короче, резюме по сабжу: какашка
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	62. "Разработчики systemd представили Journal, замену системе sys..."	–2 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 03:51
	Срочно пиши резюме в RedHat. Такого шустряка возьмут сразу и без вопросов. Тупого производителя какашек выкинут. Ты главное, нас не забывай, когда будешь всякие Лондонские биржи тюнинговать, притырь пару мильярдов, от них не убудет а нам в помощь.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	100. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:38
	когда RedHat интересовало что думают пользователи? Они сами тебе расскажут что ты должен думать и сколько денег им за это дать.
	Ответить | Правка | ^ к родителю #62 | Наверх | Cообщить модератору

	109. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 09:04
	> Они сами тебе расскажут что ты должен думать и сколько денег им за это дать. мне не рассказали, ЧЯДНТ?
	Ответить | Правка | ^ к родителю #100 | Наверх | Cообщить модератору

	264. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от me (??) on 20-Ноя-11, 00:42
	> Срочно пиши резюме в RedHat. .... > мне не рассказали, ЧЯДНТ? ты не написал резюме в redhat.
	Ответить | Правка | ^ к родителю #109 | Наверх | Cообщить модератору

	73. "Разработчики systemd представили Journal, замену системе sys..."	+6 +/–
	Сообщение от humpty dumpty on 19-Ноя-11, 04:12
	Как всегда - новость большая, дочитать не удалось? А ведь там подробно объяснено, почему БИНАРНЫЕ, почему не SYSLOG и т.д. Кстати, lastlog и wtmp имеют вполне себе бинарный формат. PulseAudio не завязан на gdm/kdm и отлично запускается без них. Про питон и стартап скрипты - в PythonOS плиз. "Бинарные сервисы" - wtf? Кроме того, наблюдаю непонимание схем работы авторизации в современных дисрибутивах: "...смущает его завязка на Polkit" - PolKit не голая девочка/мальчик, не надо смущаться. Короче, резюме по автору сообщения: %?*%*():!
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	79. "Разработчики systemd представили Journal, замену системе sys..."	–2 +/–
	Сообщение от prokoudine (??) on 19-Ноя-11, 05:01
	> PulseAudio снес, после того как выяснилось что без GDM (или KDM) он работать не будет Удивительно глубокие познания. Действительно, ну какая разница — GDM или KDM. Это же практически одно и то же :) Только вот беда — в убунте есть и lightdm, и pulseaudio. И нет ни gdm, ни kdm. Мистика, правда? :) Все твои прочие рассуждения примерно на том же уровне владения темой.
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	193. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:36
	> Только вот беда — в убунте есть и lightdm, и pulseaudio. Только вот беда, половина сплойтов повышающих привилегии радостно пользовались этим пульсом. Вот это - беда. Что новенького и приятного нам еще этот Гаррий Поттеринг заготови?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	252. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 23:58
	> Только вот беда, половина сплойтов повышающих привилегии радостно пользовались этим пульсом. Не хочу вас огорчать, но зав всю историю линукса таких сплойтов было больше двух. Поэтому указанная вами доля на половину никак не тянет. И даже на тысячную долю процента.
	Ответить | Правка | ^ к родителю #193 | Наверх | Cообщить модератору

	242. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от nmorozov (ok) on 19-Ноя-11, 21:19
	> Удивительно глубокие познания Он не одинок, судя по тому сколько ему поставили + а тебе - PS. Первый раз я АБСОЛЮТНО согласен с Прокудиным :)
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	263. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:42
	>  Он не одинок, судя по тому сколько ему поставили + а тебе - А кто сказал, что это разные люди? Походу, это какой-то фанатик сидит и методично на плюсики себе жамкает :) Типичный борцун с Поттерингом в вакууме - написать фигню и понаставить себе плюсов, типа народ поддерживает. Ничего не напоминает?
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	399. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 20:25
	> Типичный борцун с Поттерингом в вакууме - написать фигню и понаставить себе > плюсов, типа народ поддерживает. Ничего не напоминает? Типичный му...к в вакууме: наставляет себе плюсы и считает что все вокруг такие же му...ки :)
	Ответить | Правка | ^ к родителю #263 | Наверх | Cообщить модератору

	298. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от prokoudine (??) on 20-Ноя-11, 07:30
	Я даже не обращаю внимание на минусы, да и сам ими не пользуюсь (только плюсами) :) Истеричек на опеннете стало многовато.
	Ответить | Правка | ^ к родителю #242 | Наверх | Cообщить модератору

	326. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Пр0х0жий (??) on 21-Ноя-11, 02:55
	>> PulseAudio снес, после того как выяснилось что без GDM (или KDM) он работать не будет > Удивительно глубокие познания. Действительно, ну какая разница — GDM или KDM. > Это же практически одно и то же :) ... > Все твои прочие рассуждения примерно на том же уровне владения темой. А вот не суть КАК высказался человек, - важна суть сказанного. Смысл. Вы или  не поняли или не желаете понимать, ЧТО ИМЕННО вам говорят по косякам и багам pulseaudio: # init 5 $ mplayer ./revolution_os.3gp ... AO: [alsa] 32000Hz 1ch s16le (2 bytes per sample) Starting playback... ... Exiting... (Quit) # init 2 $ mplayer ./revolution_os.3gp ... [AO_ALSA] Playback open error: В соединении отказано Failed to initialize audio driver 'alsa' [AO OSS] audio_setup: Can't open audio device /dev/dsp: Нет такого файла или каталога Failed to initialize audio driver 'oss' [AO SDL] Samplerate: 32000Hz Channels: Mono Format s16le socket(): Семейство адресов не поддерживается протоколом socket(): Семейство адресов не поддерживается протоколом waitpid(): Нет дочерних процессов [AO_ALSA] alsa-lib: pulse.c:229:(pulse_connect) PulseAudio: Unable to connect: Внутренняя ошибка [AO SDL] Unable to open audio: No available audio device Failed to initialize audio driver 'sdl' socket(): Семейство адресов не поддерживается протоколом waitpid(): Нет дочерних процессов AO: [pulse] Init failed: Внутренняя ошибка Failed to initialize audio driver 'pulse' AO: [null] 32000Hz 1ch s16le (2 bytes per sample) Starting playback... ... Exiting... (Quit) Плоха не идея пульсаудио, а импульсивность Леннарта и столь же быстрое угасание интереса к инициированному им проекту, в результате чего настолько очевидные баги, которые даже не требуют багрепортов, в силу своей очевидности, болтаются годами. Теперь Леннарта пробило на systemd. Замечу при забытом pulseaudio. Поглядывая левым глазом на pulseaudio и слом FHS, задаю себе вопрос, интересно, а чем оно всё закончится в конце-концов?
	Ответить | Правка | ^ к родителю #79 | Наверх | Cообщить модератору

	328. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 21-Ноя-11, 04:43
	> интересно, а чем оно всё закончится в конце-концов? бедняги с федориным горем будут бегать и доказывать всем, что поттеринг придумал обалденно крутые фичи. все остальные ещё немного помучаются и перестанут на поттеринга вообще внимание обращать: «есть там, дескать, такой клоун-энтузиаст — ну и ладно.»
	Ответить | Правка | ^ к родителю #326 | Наверх | Cообщить модератору

	423. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 20:59
	> бедняги с федориным горем будут бегать и доказывать всем, что поттеринг придумал > обалденно крутые фичи. Справедливости ради я все-таки потроллю на тему того что невозможность использования alsa в runlevel 2 это конечно столь лютый баг, вызывающий попаболь у толпы народа, что вообще решительно непонятно как же это еще до сих пор не починили то?
	Ответить | Правка | ^ к родителю #328 | Наверх | Cообщить модератору

	358. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от prokoudine (??) on 21-Ноя-11, 13:43
	> Теперь Леннарта пробило на systemd. Замечу при забытом pulseaudio. Настолько забытом, что в сентябре была выпущена 1.0, а через месяц — 1.1. "Ты ври, да не завирайся" (с) :)
	Ответить | Правка | ^ к родителю #326 | Наверх | Cообщить модератору

	363. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Пр0х0жий (??) on 21-Ноя-11, 16:31
	>> Теперь Леннарта пробило на systemd. Замечу при забытом pulseaudio. > Настолько забытом, что в сентябре была выпущена 1.0, а через месяц — > 1.1. > "Ты ври, да не завирайся" (с) > :) Фиксрепорт в студию о том, что в runlevel 2 PA не выносит, и о том, что при Front mute, Headphone не отправляет туда же. Или прямой линк на фиксрепорт. Иначе это мысли в воздух. И вдумчиво соображаем, в alsa это просто работает. Тут уж кому что: Кому цифири версий нравится считать, а кому функционал...
	Ответить | Правка | ^ к родителю #358 | Наверх | Cообщить модератору

	375. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Aleks Revo on 22-Ноя-11, 07:43
	>[оверквотинг удален] >> Настолько забытом, что в сентябре была выпущена 1.0, а через месяц — >> 1.1. >> "Ты ври, да не завирайся" (с) >> :) > Фиксрепорт в студию о том, что в runlevel 2 PA не выносит, > и о том, что при Front mute, Headphone не отправляет туда > же. Или прямой линк на фиксрепорт. Иначе это мысли в воздух. > И вдумчиво соображаем, в alsa это просто работает. > Тут уж кому что: > Кому цифири версий нравится считать, а кому функционал... А никогда не приходило в голову посмотреть, чего же автоматом в гноме и прочая запускается, да ещё с правами пользователя, отнюдь не рута? Ба! Он, родимый, PA! И каким только боком GDM/KDM вылезли к нему? И не нужен он в init #2, так же как туда, "почему-то" и jack не пхают. Они прекрасно работают в пользовательском пространстве. А уж ежели научился в консольке mplayer запускать, ну, учись и пульс.
	Ответить | Правка | ^ к родителю #363 | Наверх | Cообщить модератору

	376. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Пр0х0жий (??) on 22-Ноя-11, 10:35
	> А никогда не приходило в голову посмотреть, чего же автоматом в гноме > и прочая запускается, да ещё с правами пользователя, отнюдь не рута? > Ба! Он, родимый, PA! И каким только боком GDM/KDM вылезли к > нему? В google и grep -rl 'pulseaudio' /etc/ > И не нужен он в init #2, так же как туда, "почему-то" > и jack не пхают. Они прекрасно работают в пользовательском пространстве. Т.е. аудиосервер от юзерспейс абстрагировать не нужно и вредно?
	Ответить | Правка | ^ к родителю #375 | Наверх | Cообщить модератору

	377. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 11:27
	> А уж ежели научился в консольке mplayer запускать, ну, учись и пульс. есть решение намного лучше.
	Ответить | Правка | ^ к родителю #375 | Наверх | Cообщить модератору

	255. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:16
	> - Systemd. Не ставил и НЕ буду ставить. Никогда. "Я академиев не кончал, но высшее образование вам даду"© > Резко отрицательно отношусь к идее делать бинарные сервисы. Чего? Идите убейте у себя сислог, он сервис и он бинарный. :D > Я скорее сделаю свою загрузку на питоне (и да - с мультипроцессной поддержкой), чем буду юзать то, от чего убегал из винды лет десять назад. Юниксвейничать - так юниксвейничать. Зачем питон, делайте сразу на Mono. > нарушает ключевой девиз "Каждый инструмент выполняет хорошо свою задачу сам. Из иструментов формируем связки (конвееры)" Ну разделите grep на два инструмента (gr и ep). Потомки вас не забудут :) Если серьезно: в качестве прослойки под Journal, systemd сейчас не имеет альтернатив просто потому, что не существует проектов, сравнимых с ним по фичастости. > - "Все логи будут проиндексированы и хранится в бинарных файлах, к которым > к сожалению будут неприменимы стандартные утилиты обработки текстовых данных, например, > grep" Тут же хочется спросиь: а почему это сохранение целостности и > введение подписей (что само по себе и не плохо) потребовало ухода > от техстового формата?! Это что такое обязательное условие. Там называлась не только безопасность, но еще и прозрачность, и простота анализа. Поиск по структурированной БД куда удобнее, чем грепанье по куче файлов с текстовым месивом произвольного формата (regexp hell). Да и универсальность, опять же (можно прямо в лог-записи коредампы добавлять). > Короче, резюме по сабжу: какашка Нам очень важно ваше мнение, оставайтесь на линии!
	Ответить | Правка | ^ к родителю #52 | Наверх | Cообщить модератору

	116. "Разработчики systemd представили Journal, замену системе sys..."	+10 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 10:18
	>> P.S. сам не программист, но анализируя отзывы о Л.Поттеринге и кол-во проблем при реализации его изобретений, что-то скептически отношусь к такому нововведению >> анализируя отзывы >> отзывы > вам не приходило в голову, что те, кого systemd/pulseaudio/networkmanager устраивают, > не пишут о них _ничего_? А что половина (если не 95%) > хаятелей — просто безмозглые хомячки, заучившие наизусть мантры и откладывающие > кирпичи потому, что приходится (оужас) напрягать мозг? Вы не поверите... "Всё работало идеально!". Но пришёл наглый тип Поттеринг и сказал: "Вот эта моя самая лучшая поделка завтра будет стандартом. Пофигу, что сырая и малость не работает - перепилим половину иерархии под неё, чтобы работало. Мне пофиг, что у вас всё работало до этого и так лет десять или двадцать." Самое плохое в этом - это то, что он не думает о тех, кто ничего менять не собирается, потому что и так всё работает. Пофигу на тех, кто использует дистрибутивы - но я заметил его влияние даже в LFS (появилось отделение /run в связи с принятием нового FHS). Если у вас работает systemd/PA/NM, и работает хорошо, вы его настроили как вам надо - я рад за вас. Но зачем мучать остальных ненужными движениями? Сегодня systemd (несоответствующий философии UNIX), завтра аналог какого-нибудь eventlog вместо текстовых логов, послезавтра - реестр? Вот честно - после этой новости я не удивлюсь. Не нужно делать из линукса мак или винду. Но всё к тому и движется, поэтому остаётся только собирать всё самому. А теперь можете облить этот пост помоями, я знаю, что вы так и сделаете.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	119. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 10:45
	> Вы не поверите... > "Всё работало идеально!". Но пришёл наглый тип Поттеринг и сказал: "Вот эта моя самая лучшая поделка завтра будет стандартом. Пофигу, что сырая и малость не работает - перепилим половину иерархии под неё, чтобы работало. Мне пофиг, что у вас всё работало до этого и так лет десять или двадцать." Не вижу проблемы. Хотите и дальше пребывать в своём уютном мирке с KOI8, OSS и X11/Motif — валяйте. Не апгрейдьтесь. Всё. Надо апгрейдиться? Пилите софт. Не в состоянии пилить? Заплатите тому, кто запилит. Не в состоянии заплатить? Используйте дистр, который заботливо поддерживается на протяжении 100500 лет. Ну или требуйте деньги взад. Никто Никому (по умолчанию) Ничего Не Должен. Зарубите это себе на носу наконец. Поттеринг не обязан заботиться об Одептах Порядка И Стабильности. Ментейнеры Fedora не обязаны заботиться о них же (как-никак, экспериментальный дистр). И так далее. > перепилим половину иерархии под неё, чтобы работало кстати, вы не владеете матчастью. как раз именно systemd вообще пофиг на иерархию. > Самое плохое в этом - это то, что он не думает о тех, кто ничего менять не собирается, потому что и так всё работает. Пофигу на тех, кто использует дистрибутивы - но я заметил его влияние даже в LFS (появилось отделение /run в связи с принятием нового FHS). Заплатите тому, кто думает и делает так, как нужно вам. Если сами не в состоянии. > Если у вас работает systemd/PA/NM, и работает хорошо, вы его настроили как вам надо - я рад за вас. Но зачем мучать остальных ненужными движениями? У меня systemd пока нет, но я бы не против. А PA/NM я не настраивал. Ни одной минуты (кстати, я хочу systemd и поэтому тоже). И всё равно они работают. Наверное, у меня кривые руки, да. > Сегодня systemd (несоответствующий философии UNIX), завтра аналог какого-нибудь eventlog вместо текстовых логов, послезавтра - реестр? Вот честно - после этой новости я не удивлюсь. > systemd (несоответствующий философии UNIX) Ну почему же. Оно делает хорошо одну вещь — запускает службы. Причём делает это настолько хорошо, что даже самые упоротые противники до сих не в состоянии аргументированно опровергнуть этот тезис. journald > eventlog. если вы полностью читали пост и имеете представление о возможностях eventlog, конечно. > Не нужно делать из линукса мак или винду. Но всё к тому и движется, поэтому остаётся только собирать всё самому. Голословные блаблабла > А теперь можете облить этот пост помоями, я знаю, что вы так и сделаете. Вы себе льстите. Не надо строить из себя мученика — я почти уверен, что вы в лучшем случае заблуждаетесь.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	233. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 20:00
	>> Оно делает хорошо одну вещь — запускает службы. Причём делает это настолько хорошо, что даже самые упоротые противники до сих не в состоянии аргументированно опровергнуть этот тезис. Поттеринга тянет делать в принципе хорошие вещи через жопу - потому и опасен. http://lists.debian.org/debian-devel/2011/07/msg00269.html
	Ответить | Правка | ^ к родителю #119 | Наверх | Cообщить модератору

	256. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:19
	> http://lists.debian.org/debian-devel/2011/07/msg00269.html Сочный и эмоциональный наброс. Но, к сожалению, совершенно безграмотный в техническом плане. Автор, похоже, знает о systemd только понаслышке.
	Ответить | Правка | ^ к родителю #233 | Наверх | Cообщить модератору

	128. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 11:38
	> Самое плохое в этом - это то, что он не думает о тех, кто ничего менять не собирается, > потому что и так всё работает. Не знаю, как сейчас -- года три тому по крайней мере на себе проверял: https://bugzilla.redhat.com/show_bug.cgi?id=464216#c0 Такое впечатление, что обречённо сдался.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	257. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:26
	> Вы не поверите... > "Всё работало идеально!". Но пришёл наглый тип Поттеринг и сказал: "Вот эта > моя самая лучшая поделка завтра будет стандартом. Пофигу, что сырая и > малость не работает - перепилим половину иерархии под неё, чтобы работало. > Мне пофиг, что у вас всё работало до этого и так > лет десять или двадцать." Если бы действительно все было так, как вы говорите - никогда бы его "поделки" не пробились бы в стандарты. Но, по факту - Поттеринг предлагает красивые решения наболевших проблем (вместо существующих груд костылей), и эти решения работают хорошо. Поэтому и становятся стандартами. > Самое плохое в этом - это то, что он не думает о тех, кто ничего менять не собирается, потому что и так всё работает. Ну так не меняйте. Просто не обновляйте софт, это же полностью совпадает с вашими целями. > Сегодня systemd (несоответствующий философии UNIX) Смотря что понимать под "философией UNIX". Вы, похоже, понимаете под этим примерно то же самое, что Гейтс понимает под "философией Шindoшs" (проблема? нет, не будем устранять ее причину, лучше костылик поставим). Да, такой "философии" systemd не соответствует, как ни крути.
	Ответить | Правка | ^ к родителю #116 | Наверх | Cообщить модератору

	329. "Разработчики systemd представили Journal, замену системе..."	+1 +/–
	Сообщение от arisu (ok) on 21-Ноя-11, 04:48
	> Если бы действительно все было так, как вы говорите — никогда бы > его «поделки» не пробились бы в стандарты. ты, видимо, пребываешь в распространнёном заблуждении: «в стандарты попадает самое хорошее и удобное». обычно это проходит с накоплением опыта, когда становится видно, что стандарты на самом деле местами шибко кривучие. > Но, по факту — Поттеринг предлагает красивые решения наболевших проблем а у меня эти «проблемы» не болят. ЧЯДНТ? > Ну так не меняйте. Просто не обновляйте софт, это же полностью совпадает > с вашими целями. нет, не совпадает. а вот менять с очередным апдейтом вполне рабочий инит неизвестно на что — нет, не хочу. > (проблема? нет, не будем устранять ее причину, лучше костылик поставим) проблема? как это «у нас нет проблем»?! у вас есть проблемы, мы лучше знаем. поэтому сделали вам решение, от которого вы не сможете отказаться, даже если захотите. точно, m$ way.
	Ответить | Правка | ^ к родителю #257 | Наверх | Cообщить модератору

	324. "Разработчики systemd представили Journal, замену системе..."	+1 +/–
	Сообщение от arisu (ok) on 21-Ноя-11, 00:17
	а тебе не приходило в голову, что те, кого поделия поттеринга устраивают — хомячки, готовые сожрать всё, что дадут? потому что как раз ничего не понимают. а те, кто более-менее ковырялся в продуктах жизнедеятельности упомянутого товарища, остались недовольны и высказались.
	Ответить | Правка | ^ к родителю #18 | Наверх | Cообщить модератору

	87. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 07:14
	Советую посмотреть это видео с Chaos Communication Congress http://ftp.halifax.rwth-aachen.de/CCC/27C3/mp4-h264-512x288-... Ну чтобы примерно понять кто такой Поттеринг, и что обычно из себя представляют люди, которые его критикуют.
	Ответить | Правка | ^ к родителю #1 | Наверх | Cообщить модератору

	104. "Разработчики systemd представили Journal, замену системе sys..."	+5 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:48
	> Советую посмотреть это видео с Chaos Communication Congress http://ftp.halifax.rwth-aachen.de/CCC/27C3/mp4-h264-512x288-... > Ну чтобы примерно понять кто такой Поттеринг, и что обычно из себя > представляют люди, которые его критикуют. Патрик это человек который - в PulseAudio сломал совместимость с OSS и сказал я чинить не буду, а благодаря политике RH это поделие пихали куда угодно, и типовым решением тех времен было "а давайте отключим pulseaudio". Потом народ подтянулся и от безнадеги стал использовать native api - оно хоть как-то стало работать. Как? я наблюдаю как каждый голосовой митинг плющит людей сидящих под linux. - который не раз заявлял что писать платформено независимый код это плохой стиль, и вообще все остальные OS задерживают развитие Linux. Неожиданно правда ? вот QT не мешает, GTK не мешает - а ему мешают другие OS. Может этот ламерок других просто не знает ? - каждый раз когда он делает какой-то вброс - выясняется что система ему мешает и надо бы переделать ее. Знаете поговорку про танцора и яйца? Вот и сейчас - вместо того что бы добавить функциональность защиты логов в syslog. право дело это делается значительно проще чем городить новый не счем не совместимый Journal который заметь? будет использовать только systemd а остальные где ? в пролете? PS, задачу сохранения логов можно сделать проще - просто пересылать syslog сообщения на отдельный комп по сети. Но патрику это в голову не приходит
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	359. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 13:44
	> вместо того что бы добавить функциональность защиты логов в syslog. Как вы это себе представляете без слома обратной совместимости и без изменения в архитектуре и протоколе сислога?
	Ответить | Правка | ^ к родителю #104 | Наверх | Cообщить модератору

	107. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 09:01
	Это Поттеринг... ужас. Ситуация намного хуже чем полагал. Сознательно испортил всю лекцию про его недоделок, завладел трибуну чтобы объявить всем свое имя, желторотый колежанин скакает "Use it or not use it! But you get it for free! you get it for free!" спасибо за ссылку
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	145. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 12:57
	> Советую посмотреть это видео с Chaos Communication Congress http://ftp.halifax.rwth-aachen.de/CCC/27C3/mp4-h264-512x288-... > Ну чтобы примерно понять кто такой Поттеринг, и что обычно из себя > представляют люди, которые его критикуют. спасибо за линк, глянем-с
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	253. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Анонимкус on 20-Ноя-11, 00:06
	> Советую посмотреть это видео с Chaos Communication Congress http://ftp.halifax.rwth-aachen.de/CCC/27C3/mp4-h264-512x288-... > Ну чтобы примерно понять кто такой Поттеринг, и что обычно из себя > представляют люди, которые его критикуют. +1. У меня просто слезы на глаза навернулись при просмотре. Какое необъятное чувство сочувствия возникло у меня когда Вася за трибуной на 25:10 спросил "знаете ли вы что такое шелл-скрипты?" у Леннарта. Я представляю себе мысли последнего, в этот момент. НУ ЧТО ЭТОМУ ВАСЕ ДОКАЖЕШЬ, ОН ВЕДЬ ВСЕ РАВНО НЕ ИМЕЕТ НЕОБХОДИМОГО УРОВНЯ ЗНАНИЙ, ЧТОБ ПОНЯТЬ %0! Реально разговор деревенского плотника и инженера ;). (на тему влияния неравножесткости подвеса динамически настраиваемого гироскопа на его дрейф)
	Ответить | Правка | ^ к родителю #87 | Наверх | Cообщить модератору

	286. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Ytch on 20-Ноя-11, 01:55
	> когда Вася за трибуной на 25:10 спросил "знаете ли вы что такое шелл-скрипты?" у Леннарта. Знаете ли вы что такое ирония? > ОН ВЕДЬ ВСЕ РАВНО НЕ ИМЕЕТ НЕОБХОДИМОГО УРОВНЯ ЗНАНИЙ, ЧТОБ ПОНЯТЬ А заодно и все сидящие в зале, смотрящие видео, да и вообще, пожалуй, все люди во всем мире. > Реально разговор деревенского плотника и инженера Вы ведь Леннарта имели ввиду под словом "инженер" в этой фразе, да?
	Ответить | Правка | ^ к родителю #253 | Наверх | Cообщить модератору

	290. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от kpykcb (ok) on 20-Ноя-11, 02:42
	> Знаете ли вы что такое ирония? Да, но было крайне тупо отвечать иронией, на описание причинно-следственной связи необходимости запускать урезанную сессию с gdm. Необходимость такая была по-моему понятно объяснена. А отмазки, мне это не нужно, это мммм... наверное именно потому, работа с кириллицей еще 5-10 лет назад была очень через жопу. Кому-то ведь это не нужно, а раз не нужно, то кули голову ломать? > А заодно и все сидящие в зале, смотрящие видео, да и вообще, > пожалуй, все люди во всем мире. А вы телепат и прочитали мысли всех и каждого и все думали, что Леннарт тупица и не знает, что такое шелл-скрипт и юникс-вей? Кстати то, что там сидит кто-то и то что это **с3 не означает, что там исключительно гуру перфокарт собрались. Туда и детей пускают, по сниженому тарифу. > Вы ведь Леннарта имели ввиду под словом "инженер" в этой фразе, да? Явно не того парня который за трибуной стоял, он на сколько я понял - физик. Т.е. специальных знаний в программной инженерии/computer science/ мог не получить. Во всяком случае, кажется, он верит, что все можно решить sh-сценарием.
	Ответить | Правка | ^ к родителю #286 | Наверх | Cообщить модератору

	331. "Разработчики systemd представили Journal, замену системе..."	+1 +/–
	Сообщение от arisu (ok) on 21-Ноя-11, 04:58
	> необходимости запускать урезанную сессию с gdm …тупо не существует. а если какому-то поттерингу это надо — пусть себе ночью под одеялом запускает. > работа с кириллицей еще 5–10 лет назад была очень через жопу э… что-то как-то я помню, что году эдак в 2000-м у меня всё работало совсем не через жопу. может, просто не надо жопой систему настраивать, и всё работать будет нормально? > А вы телепат и прочитали мысли всех и каждого и все думали, > что Леннарт тупица и не знает, что такое шелл-скрипт и юникс-вей? он ведёт себя так, что подобное предположение не является невероятным. > Во всяком случае, кажется, он верит, что все можно решить sh-сценарием. нет, он знает, что проблемы доблестных китайских комсомольцев давно решены на 95%.
	Ответить | Правка | ^ к родителю #290 | Наверх | Cообщить модератору

	339. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от kpykcb (ok) on 21-Ноя-11, 06:12
	>> необходимости запускать урезанную сессию с gdm > …тупо не существует. а если какому-то поттерингу это надо — пусть себе > ночью под одеялом запускает. думаю скорее это вам прийдется делать. Потому как это он сейчас занят тем, что пишет софт который станет мейнстримом, а вам прийдется делать то, что вам нравиться самостоятельно. >> работа с кириллицей еще 5–10 лет назад была очень через жопу > э… что-то как-то я помню, что году эдак в 2000-м у меня > всё работало совсем не через жопу. может, просто не надо жопой > систему настраивать, и всё работать будет нормально? И наверно настолько все было прекрасно, что вы до сих пор не обновляетесь и юникода боитесь как огня? И вообще пол-десятка кодировок использовать вам в кайф я так понял? > он ведёт себя так, что подобное предположение не является невероятным. Это вообще какое-то необоснованное высказывание, небось каждый день вы сами того не осознавая результатами его труда пользуетесь. > нет, он знает, что проблемы доблестных китайских комсомольцев давно решены на 95%. Он ничего такого знать не может, т.к. ему "это не нужно".
	Ответить | Правка | ^ к родителю #331 | Наверх | Cообщить модератору

	368. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 21-Ноя-11, 20:17
	> Потому как это он сейчас занят тем, что пишет > софт который станет мейнстримом, а вам прийдется делать то, что вам нравиться > самостоятельно. мэйнстрим — это винда. я согласен, он пишет такое же костылегробище, как винда. tnx, не надо, я знаю, где купить настоящую винду, если вдруг сойду с ума. > И наверно настолько все было прекрасно, что вы до сих пор не > обновляетесь и юникода боитесь как огня? И вообще пол-десятка кодировок использовать > вам в кайф я так понял? а зачем мне «пол-десятка кодировок»? да, у меня в консоли до сих пор koi-8. и что характерно — всё отлично работает, русский есть, проблем нет. ЧЯДНТ? не пользуюсь китайским и корейским? какая досада! (ц) > Это вообще какое-то необоснованное высказывание, небось каждый день вы сами того не > осознавая результатами его труда пользуетесь. не пользуюсь. > Он ничего такого знать не может, т.к. ему «это не нужно». да, он не может и не хочет знать про проблемы поттеринга. если у поттеринга проблемы — пусть он их решает. но не надо считать, что проблемы поттеринга автоматически появляются у всех, это не так.
	Ответить | Правка | ^ к родителю #339 | Наверх | Cообщить модератору

2. "Разработчики systemd представили Journal, замену системе sys..."	+5 +/–
Сообщение от sdog (ok) on 19-Ноя-11, 00:20
всё бы хороо, кроме того что эти логи нужны для просмотра и поиска из командной строки, стандартными средствами.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	10. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 00:40
	> всё бы хороо, кроме того что эти логи нужны для просмотра и поиска из командной строки, стандартными средствами. grep щтототам /var/log/щтототам/* станет journal-viewer --service=httpd | grep щтототам. не надо считать всех людей тупее и/или ленивее себя, это вредно и некрасиво.
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	23. "Разработчики systemd представили Journal, замену системе sys..."	+5 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:11
	Текстовый файл - это суть Юникса, его можно открыть чем угодно, даже из голого busybox из initramfs, даже если остальная система убита нафиг. Поэтом Юникс неубиваем и надёжен (был когда-то). А сабжевый товарищ - диверсант похуже Мигеля. Такими темпами раскол неизбежен, и вместо OS Linux будут несовместимые между собой Red Hat OS, Ubuntu OS, Novell OS... Ну, туда им и дорога, а мы будем юзать свой Debian GNU/Linux, туда психов пока не пускают вроде.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	56. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от ononom on 19-Ноя-11, 03:12
	ты логи для чего открываешь? просто ради самого факта? логи открывают либо для поиска нужной информации (теперь будут эффективные инструменты), либо для он-лайн просмотра с фильтрацией ( аналогично). "текстовый файл" - писанная торба... мир меняется, юникс меняется. задача, которой задались авторы проекта, актуальна. и условия её выполнения выбраны верно - подобные инструменты должны быть центральной частью среды ос. а скулёж - от страха перемен и общей ограниченности
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	118. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 10:37
	> ты логи для чего открываешь? просто ради самого факта? логи открывают либо > для поиска нужной информации (теперь будут эффективные инструменты), либо для он-лайн > просмотра с фильтрацией ( аналогично). "текстовый файл" - писанная торба... мир > меняется, юникс меняется. задача, которой задались авторы проекта, актуальна. и условия > её выполнения выбраны верно - подобные инструменты должны быть центральной частью > среды ос. а скулёж - от страха перемен и общей ограниченности Система обвалилась (мало ли что бывает). Вы в базовой системе, допустим, или с LiveCD. Логи бинарные, systemd не запущен. Ваши действия?
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	120. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 10:47
	> Система обвалилась (мало ли что бывает). Вы в базовой системе, допустим, или с LiveCD. Логи бинарные, systemd не запущен. Ваши действия? а кто сказал, что jview зависит от systemd?
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	220. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 18:11
	> а кто сказал, что jview зависит от systemd? Отлично, только теперь для того, чтобы из своей программы прочитать логи, мне придется не просто открывать текстовый файл и читать его стандартными системными вызовами, а запускать отдельным процессом jview и озадачиваться IPC с ним - оно мне надо?
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	302. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 20-Ноя-11, 11:37
	>> а кто сказал, что jview зависит от systemd? > Отлично, только теперь для того, чтобы из своей программы прочитать логи, мне придется не просто открывать текстовый файл и читать его стандартными системными вызовами, а запускать отдельным процессом jview и озадачиваться IPC с ним - оно мне надо? Шота ШИНДОШС-way какой-то. Хорошо, что journald пишет Поттеринг, а не вы. Я бы на месте jview выдавал записи из лога тупо в stdout. И делайте с ними, что хотите.
	Ответить | Правка | ^ к родителю #220 | Наверх | Cообщить модератору

	237. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 20:33
	>> Система обвалилась (мало ли что бывает). Вы в базовой системе, допустим, или с LiveCD. Логи бинарные, systemd не запущен. Ваши действия? > а кто сказал, что jview зависит от systemd? which: no jview in (...) "g jview": 1. Docs for class JView ... 6. Jview.exe (jview) is a tool used to execute Java applications from the command line. "g jview systemd": 1. Welcome to OneView Systems ... "g jview site:0pointer.de": Не найдено ни одного документа, соответствующего запросу jview site:0pointer.de. Внимание, вопрос. Кто такой jview, и почему я не могу использовать обычные, ПРИВЫЧНЫЕ для меня (да и для многих) инструменты типа less, cat, tail, head, *grep, *sh ??
	Ответить | Правка | ^ к родителю #120 | Наверх | Cообщить модератору

	275. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 20-Ноя-11, 01:17
	>>> Система обвалилась (мало ли что бывает). Вы в базовой системе, допустим, или с LiveCD. Логи бинарные, systemd не запущен. Ваши действия? >> а кто сказал, что jview зависит от systemd? > Внимание, вопрос. Кто такой jview, и почему я не могу использовать обычные, ПРИВЫЧНЫЕ для меня (да и для многих) инструменты типа less, cat, tail, head, *grep, *sh ?? деточка, я в душе нии^Wбеспонятия, как будет называться автономная смотрелка логов journald. Но вот в том, что она будет, я уверен на 100500%, пушо наличие автономной смотрелки логов — одно из фундаментальных требований к journald.
	Ответить | Правка | ^ к родителю #237 | Наверх | Cообщить модератору

	137. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 12:40
	Новость не читаем да? Сразу срем в комантах? ))) "Возможность анализа лога должна быть доступна без необходимости запуска демона журналирования, обслуживающего БД с логами"
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	238. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 20:35
	> Новость не читаем да? Сразу срем в комантах? ))) > "Возможность анализа лога должна быть доступна без необходимости запуска демона журналирования, > обслуживающего БД с логами" ага, это же так прикольно))))))))))00 Должна быть, но по факту - пустые слова. Где мой grep. Или мне на логи strings уже нужно натравить?
	Ответить | Правка | ^ к родителю #137 | Наверх | Cообщить модератору

	262. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:39
	> Должна быть, но по факту - пустые слова. Где мой grep. Или > мне на логи strings уже нужно натравить? Наука и образование - пустые слова. Где мой каменный топор. Как мне убить мамонта?"
	Ответить | Правка | ^ к родителю #238 | Наверх | Cообщить модератору

	312. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от prokoudine (??) on 20-Ноя-11, 13:32
	Два чая этому гражданину :))))))))))
	Ответить | Правка | ^ к родителю #262 | Наверх | Cообщить модератору

	196. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:39
	> Система обвалилась (мало ли что бывает). Вы в базовой системе, допустим, или > с LiveCD. Логи бинарные, systemd не запущен. Ваши действия? Ну так я загружусь с ливцд той же системы. Значит он будет стартавать с systemd и логи будут читабельны. А так - знаете, даже для чтения текстовых логов нужна какая-нибудь программа. Хотя-бы реализующая команду cat. Потому что вы сами не сможете голыми руками проинстркутировать систему сделать сискол типа open() и read() и вывести результат на экран. Бинарные ли логи или текстовые в этом плане совершенно монопенисуально. Ну будет не cat а jcat допустим. Какая нахрен разница? zcat же например есть и никого не смущает что сжатые данные - типа бинарные.
	Ответить | Правка | ^ к родителю #118 | Наверх | Cообщить модератору

	204. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 16:51
	> zcat же например есть и никого не смущает что сжатые данные - типа бинарные. zcat всё-таки интересует только то, чтоб данные были сжаты GZIP -- сравнение не совсем честное.
	Ответить | Правка | ^ к родителю #196 | Наверх | Cообщить модератору

	333. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 05:17
	> zcat всё-таки интересует только то, чтоб данные были сжаты GZIP -- сравнение > не совсем честное. А утилиту просмотра журнала интересует только то чтобы это был формат журнала. Какая разница, потребовать "формат gzip" или "формат журнала"? За что гзип следует посчитать более хорошим форматом чем все остальные?
	Ответить | Правка | ^ к родителю #204 | Наверх | Cообщить модератору

	130. "Разработчики systemd представили Journal, замену системе sys..."	+5 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 11:53
	1. У меня уже есть инструменты grep, less и tail, которые меня полностью устраивают, и моя система отлично работает. 2. Человек, который хочет в моей системе сломать то, что отлично работает - диверсант.
	Ответить | Правка | ^ к родителю #56 | Наверх | Cообщить модератору

	197. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:40
	> 1. У меня уже есть инструменты grep, less и tail, которые меня > полностью устраивают, и моя система отлично работает. > 2. Человек, который хочет в моей системе сломать то, что отлично работает > - диверсант. А против zcat вы что-то имеете? А то он понимаешь переводит сжатые бинарные данные обратно в текст путем их распаковки. Не понятно что мешает сделать такой же утиль и для этого формата логов.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	222. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 18:13
	> А против zcat вы что-то имеете? А то он понимаешь переводит сжатые бинарные данные обратно в текст путем их распаковки. Не понятно что мешает сделать такой же утиль и для этого формата логов. А против zcat мы ичего не имеем, потому что без него легко прожить при помощи gunzip -c
	Ответить | Правка | ^ к родителю #197 | Наверх | Cообщить модератору

	334. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 05:19
	> А против zcat мы ичего не имеем, потому что без него легко > прожить при помощи gunzip -c Ну дык думается и для этого формата файлов будет средство перегона в текстовики. А чему это противоречит? Вон у git база данных бинарная, а сорцы на диске - текстовые. И ничего, работает же. И никто не пиндит "ой, а если гит накроется, как же я свои сорцы то получу?!"
	Ответить | Правка | ^ к родителю #222 | Наверх | Cообщить модератору

	313. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от prokoudine (??) on 20-Ноя-11, 13:33
	> 1. У меня уже есть инструменты grep, less и tail, которые меня > полностью устраивают, и моя система отлично работает. > 2. Человек, который хочет в моей системе сломать то, что отлично работает > - диверсант. Диверсантом является идиот, который лезет обновлять систему, в которой всё работает.
	Ответить | Правка | ^ к родителю #130 | Наверх | Cообщить модератору

	383. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 15:54
	> Диверсантом является идиот, который лезет обновлять систему, в которой всё работает. Это было бы правдой, если б не тот момент что не обновляемая система станет мишенью для хакеров и совсем не бесконечный период майнтенанса установленной системы майнтайнерами.
	Ответить | Правка | ^ к родителю #313 | Наверх | Cообщить модератору

	88. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:14
	То есть именно поэтому wtmp/utmp храняться в бинарном виде, да?
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	117. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 10:35
	> То есть именно поэтому wtmp/utmp храняться в бинарном виде, да? А как часто вы их читаете и как редко читаете собственно логи?
	Ответить | Правка | ^ к родителю #88 | Наверх | Cообщить модератору

	424. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 21:05
	> Текстовый файл - это суть Юникса, его можно открыть чем угодно, даже > из голого busybox из initramfs, даже если остальная система убита нафиг. Что помешает туда же класть вьюшку этого формата? > Поэтом Юникс неубиваем и надёжен (был когда-то). Мамонтов, говорят, тоже геморно и опасно было валить. Но поскольку хотелось жрать, а других вариантов еще не придумали - приходилось вот.
	Ответить | Правка | ^ к родителю #23 | Наверх | Cообщить модератору

	55. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
	Сообщение от XoRe (ok) on 19-Ноя-11, 03:04
	>> всё бы хороо, кроме того что эти логи нужны для просмотра и поиска из командной строки, стандартными средствами. > grep щтототам /var/log/щтототам/* станет journal-viewer --service=httpd | grep > щтототам. Разница начнется, когда: # journal-viewer --service=httpd | grep щтототам failed: journal index corrupted > не надо считать всех людей тупее и/или ленивее себя, это вредно и > некрасиво. Тогда нужно быть последовательным в этом деле - не надо считать предыдущие поколения админов и разработчиков тупее себя. Подсистемы сбора и хранения логов тестировались в боевых условиях десятилетиями. Если логи важны, то их можно передавать по сети на отдельный сервер логов. А сами файлы логов - архивировать и подписывать gpg. Просто со стороны смотрится так: Раунд 1: systemd Приходит человек. Объявляет существующий _работающий_ механизм устаревшим и неэффективным. Пишет альфа-версию новой системы. Обещает, что она решит все проблемы человечества. Делает бета версию. "внезнапно" узнает, что бета версия имеет массу недостатков. Раунд 2: usr Приходит человек. Объявляет существующий _работающий_ механизм устаревшим и неэффективным. Предлагает решение, которое ломает существующие договоренности, но поможет решить проблемы первого раунда. Раунд 3: journal Приходит человек. Объявляет существующий _работающий_ механизм устаревшим и неэффективным. Пишет альфа-версию новой системы так, что она завязана на первый раунд (systemd). ИЧСХ, обещает, что она решит все проблемы человечества. И, *ля, ему все верят! Кроме данного человека, я знаю только одного товарища, который решал свои проблемы за счет проблем остального человечества - Билл Гейтс.
	Ответить | Правка | ^ к родителю #10 | Наверх | Cообщить модератору

	77. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Avator (ok) on 19-Ноя-11, 04:50
	> Тогда нужно быть последовательным в этом деле - не надо считать предыдущие поколения админов и разработчиков тупее себя. Почему сразу тупее. То, что было раньше проектировалось в совершенно других условиях и _в тот момент времени_ видимо было лучшим вариантом решения поставленной задачи. За последние десятелетия мир слегка изменился, знаете ли. Изменились не только подходы к разработке ПО, количество ресурсов доступные для решения текущих задач, но и сами задачи были сильно скорректированы изменившейся действительностью. И, о ужас, существующее в данный момент решение перестало быть оптимальным. Или вы у нас живете в вакууме, в котором нифига не меняется вокруг? > А сами файлы логов - архивировать и подписывать gpg. В какой момент? И решит ли это _все_ поставленные задачи, включая то, что совершенно левое приложение может сделать вид, что оно например httpd?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	132. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от kem on 19-Ноя-11, 11:59
	как уже верно заметили Аутентификация источника сообщения и цифровая подпись самого сообщения в логе не требуют такого кардинального пересмотра архитектуры. Everything is file + KISS на практике отлично работает. Никто и сейчас не мешает хранить логи в SqlDB если такая неоходимость есть. А если логи писать сразу на Syslog Server то и большая часть проблем с подменость тоже уходит. С другой стороны стандартизация формата сообщения и надежная доставка вещи полезные, но зачем для этого ВСЕ переписывать с нуля не понимаю
	Ответить | Правка | ^ к родителю #77 | Наверх | Cообщить модератору

	279. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:29
	> зачем для этого ВСЕ переписывать с нуля не понимаю Перечитайте сабж еще раз. Там подробно, для маленьких, разъяснен весь спектр проблем современного syslog. Ну попробуйте решить их без пересмотра архитектуры. А если у вас это получится - пересчитайте костыли в своем решении. И попытайтесь не сбиться со счета :)
	Ответить | Правка | ^ к родителю #132 | Наверх | Cообщить модератору

	293. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Ytch on 20-Ноя-11, 02:58
	>> зачем для этого ВСЕ переписывать с нуля не понимаю > Перечитайте сабж еще раз. Там подробно, для маленьких, разъяснен весь спектр проблем > современного syslog. Что ж вы как передёргиваете-то неуклюже... Не разъяснен там никакой "весь спектр проблем современного syslog". Там перечислено то, что именно Леннарт считает проблемами syslog (это все-таки не одно и то же). Большую часть из этого (не всё) можно охарактеризовать примерно так: есть тривиальный workaround, а для подавляющего большинства пользователей и применений даже workaround не нужен, так как неактуально.
	Ответить | Правка | ^ к родителю #279 | Наверх | Cообщить модератору

	78. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Avator (ok) on 19-Ноя-11, 04:51
	> Кроме данного человека, я знаю только одного товарища, который решал свои проблемы > за счет проблем остального человечества - Билл Гейтс. Глубина ваших познаний в истории ИТ поражает воображение.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	81. "Разработчики systemd представили Journal, замену системе sys..."	–8 +/–
	Сообщение от prokoudine (??) on 19-Ноя-11, 05:04
	> Просто со стороны смотрится так: > Раунд 1: systemd > Приходит человек. ... > Обещает, что она решит все проблемы человечества. Чисто из любопытства, твоя склонность к преувеличениям — это случайный литературный приём или таки истерическая натура?
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	90. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:21
	> Раунд 2: usr > Приходит человек. > Объявляет существующий _работающий_ механизм устаревшим и неэффективным. > Предлагает решение, которое ломает существующие договоренности, но поможет решить проблемы > первого раунда. Если бы у тебя был мозг, то ты бы прочитал текст по ссылке в начале обсуждения, и понял, что проблема с отдельно-стоящим /usr к самому systemd не относится вообще никак: это проблема кривых сервисов, не учитывающих возможность наличия отдельного раздела. Единственное что делает systemd - это честно сообщает о данной проблеме, и позволяет использовать отдельный раздел для /usr на свой страх и риск.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	125. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 19-Ноя-11, 11:09
	>Если бы у тебя был мозг, то ты бы прочитал текст по ссылке в начале обсуждения, и понял, что проблема с отдельно-стоящим /usr к самому systemd не относится вообще никак: это проблема кривых сервисов, не учитывающих возможность наличия отдельного раздела. Странно, у меня sysVinit, отдельный /usr и никаких кривых сервисов. Перед тем как копипастить Поттеринга, хоть бы разобрался, почему везде, кроме systemd это возможно.
	Ответить | Правка | ^ к родителю #90 | Наверх | Cообщить модератору

	133. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 12:02
	> Странно, у меня sysVinit, отдельный /usr и никаких кривых сервисов. Перед тем как копипастить Поттеринга, хоть бы разобрался, почему везде, кроме systemd это возможно. Вы для начала повесьте отдельный /usr на autofs (или как там её), чтобы монтировался не при загрузке, а при первом обращении к, вот тогда и поговорим.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	156. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 13:25
	>Вы для начала повесьте отдельный /usr на autofs (или как там её), чтобы монтировался не при загрузке, а при первом обращении к, вот тогда и поговорим. Назови мне хоть одну причину необходимости делать это. Я про монтирование /usr при первом обращении, если что.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	265. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от develop7 (ok) on 20-Ноя-11, 00:43
	>>Вы для начала повесьте отдельный /usr на autofs (или как там её), чтобы монтировался не при загрузке, а при первом обращении к, вот тогда и поговорим. > Назови мне хоть одну причину необходимости делать это. Я про монтирование /usr при первом обращении, если что. Ну вот, опять стандартное НЕНУЖНО!!!111. Затем, чтобы система грузилась быстрее например? Или это тоже ненужно!!!111©
	Ответить | Правка | ^ к родителю #156 | Наверх | Cообщить модератору

	402. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 21:47
	> Затем, чтобы система грузилась быстрее например? КАК ты умудрился тормознуть монтирование раздела? ну вот КАК? напиши статью, мне действительно интересно.
	Ответить | Правка | ^ к родителю #265 | Наверх | Cообщить модератору

	184. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 15:56
	наверно ты единственный кто задумался что /usr можно монтировать при первом обращении. Другим это в голову не приходит - и используют монтирование в процессе загрузки из fstab. PS голову надо иметь - а не верить всяким потерингам - которые рады сделать все для счастья RH а не для счастья всех.
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	203. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от гость on 19-Ноя-11, 16:50
	> Вы для начала повесьте отдельный /usr на autofs (или как там её), > чтобы монтировался не при загрузке, а при первом обращении к, вот > тогда и поговорим. Это.. Гениально! Какого ещё софта надо понаставить и что надо ещё перекроить что бы тупо загрузить ОС? А главное - зачем?? Прогресс ради прогресса?
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	225. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 18:27
	> Вы для начала повесьте отдельный /usr на autofs (или как там её), чтобы монтировался не при загрузке, а при первом обращении к, вот тогда и поговорим. Друх, выстрелив себе в ногу из ружья - ты удивишься: пойдет кровь и будет больно! Но виновато ли ружье в том, что у тебя нет мозгов? Может стоит задуматься, почему до поттернговых поделок ни у кого никаких проблем не возникало, но с этим новым "д'Артаньяном" постоянно что-то работает не так, как надо? может проблема с /usr возникла из-за того, что сервис взялся делать не то, что ему следовало бы?
	Ответить | Правка | ^ к родителю #133 | Наверх | Cообщить модератору

	274. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:13
	> Друх, выстрелив себе в ногу из ружья - ты удивишься: пойдет кровь и будет больно! Так зачем стрелять себе в ногу (т.е. выносить /usr на отдельный раздел)?
	Ответить | Правка | ^ к родителю #225 | Наверх | Cообщить модератору

	355. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от _m1ke_ (ok) on 21-Ноя-11, 12:45
	Ситуации бывают разные, все может в жизни понадобиться. А тут решения определенных товарищей начинают создавать проблемы там, где их до этого небыло. Та может этим товарищам стоит задуматься, что что-то они делают не так?
	Ответить | Правка | ^ к родителю #274 | Наверх | Cообщить модератору

	142. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 12:52
	> Странно, у меня sysVinit, отдельный /usr и никаких кривых сервисов. Перед тем > как копипастить Поттеринга, хоть бы разобрался, почему везде, кроме systemd это > возможно. Всё-таки дурак. Жаль. Попробуем ещё раз, для тупых: проблемы с /usr это не проблемы системы инициализации - так что если у тебя всё работает на sysVinit, то отлично будет работать и на systemd.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	147. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 13:00
	Так, предлагаю обоим вместо стучания лбами почитать http://www.freedesktop.org/wiki/Software/systemd/separate-us... и http://lwn.net/Articles/431111/ (каждому). > Попробуем ещё раз, для тупых: проблемы с /usr это не проблемы системы > инициализации Прежде чем называть остроконечников тупыми, тупоконечникам положено подумать о том, что они на этом островке не одни. И если это не проблемы системы инициализации, то незачем системе инициализации верещать.  Если нет сил бороться с кривыми апстримами (хотя здесь есть лукавство, поскольку ведущая -- пролинкованная на вики -- часть этих самых кривых апстримов есть своя же разработка), то нечего лезть messenger'ом в загрузку, сделайте в своей федоре предупреждение в своей анаконде и успокойтесь.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	151. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 13:12
	> Так, предлагаю обоим вместо стучания лбами почитать http://www.freedesktop.org/wiki/Software/systemd/separate-us... > и http://lwn.net/Articles/431111/ (каждому). Я-то это давно прочитал. > И если это не проблемы системы инициализации, то незачем системе инициализации верещать. Попробуй сам прочитать - там внятно объяснено, почему именно выводится предупреждение.
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	159. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 13:31
	>> Так, предлагаю обоим вместо стучания лбами почитать >> http://www.freedesktop.org/wiki/Software/systemd/separate-us... >> и http://lwn.net/Articles/431111/ (каждому). > Я-то это давно прочитал. Обе ссылки? >> И если это не проблемы системы инициализации, то незачем системе инициализации верещать. > Попробуй сам прочитать - там внятно объяснено, почему именно выводится предупреждение. Внятно объяснено, скажем, в https://bugzilla.redhat.com/show_bug.cgi?id=643640 -- а тут именно что "в каждую дырку затычкой" и переваливание ощущаемых проблем федоры на тех, кому предлагается данная разработка. PS: агрессивное "сам дурак" в отношении обсуждающих по существу (даже если и ошибающихся) приведёт только к удалению провокаций и флейма; пожалуйста, постарайтесь держать себя в руках и если уж тратить время на изложение своего несогласия с чьей-либо позицией -- то так, чтобы был смысл задуматься над Вашими словами.  Не заливайте ложку мёда ведром дёгтя.
	Ответить | Правка | ^ к родителю #151 | Наверх | Cообщить модератору

	266. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:47
	> И если это не проблемы системы инициализации, то незачем системе инициализации верещать. Есть одно "но": всегда найдется много желающих объявить эту проблему - проблемой системы инициализации. "У меня система не запускается/глючит при запуске - Это все systemd, поганая поделка!!!1"
	Ответить | Правка | ^ к родителю #147 | Наверх | Cообщить модератору

	157. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 13:29
	>> Странно, у меня sysVinit, отдельный /usr и никаких кривых сервисов. Перед тем >> как копипастить Поттеринга, хоть бы разобрался, почему везде, кроме systemd это >> возможно. > Всё-таки дурак. Жаль. > Попробуем ещё раз, для тупых: проблемы с /usr это не проблемы системы > инициализации - так что если у тебя всё работает на sysVinit, > то отлично будет работать и на systemd. Ты называешь это "отлично"? Тогда ты себя точно охарактеризовал.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	278. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:26
	> Ты называешь это "отлично"? Тогда ты себя точно охарактеризовал. Да, в глазах суровых виндузятников, все и всегда делающих через костыли, этот человек навсегда заработал репутацию поганого читера.
	Ответить | Правка | ^ к родителю #157 | Наверх | Cообщить модератору

	219. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от RRV on 19-Ноя-11, 18:04
	> Всё-таки дурак. Жаль. Это Вы о себе? > Попробуем ещё раз, для тупых: проблемы с /usr это не проблемы системы > инициализации - так что если у тебя всё работает на sysVinit, > то отлично будет работать и на systemd. Тогда может быть "ґуру" объяснит необъяснимое: в процессе обновления development-ветки дистрибутива N (в принципе, какая разница какого именно) sysvinit был заменен на systemd автоматически. Перезагрузка - и облом. Ни сообщений об ошибках, ничего. Машина (хорошо, что тестовая) просто висит. Чего-то ждет, очевидно. Но чего - об этом мне неизвесно. Гружусь LiveCD, восстанавливаю sysvinit - грузится нормально. И так несколько раз. Пришлось отказаться от этого systemd. Считаю его пока не готовым к эксплуатации.
	Ответить | Правка | ^ к родителю #142 | Наверх | Cообщить модератору

	258. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:29
	> Странно, у меня sysVinit, отдельный /usr и никаких кривых сервисов. Перед тем > как копипастить Поттеринга, хоть бы разобрался, почему везде, кроме systemd это > возможно. Странно, у меня systemd, отдельный /usr и никаких кривых init-скриптов. Перед тем, как копипастить коллег-виндотроллей, разобрался бы, что к чему.
	Ответить | Правка | ^ к родителю #125 | Наверх | Cообщить модератору

	341. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 07:29
	>> Странно, у меня sysVinit, отдельный /usr и никаких кривых сервисов. Перед тем >> как копипастить Поттеринга, хоть бы разобрался, почему везде, кроме systemd это >> возможно. > Странно, у меня systemd, отдельный /usr и никаких кривых init-скриптов. Перед тем, > как копипастить коллег-виндотроллей, разобрался бы, что к чему. Все тут боятся каких-то мифических вендотроллей. Тем временем кому-то из арчей уже неповезло: http://comments.gmane.org/gmane.linux.arch.general/37167 Вот так вот. Обновился ты по привычке, и на следующее утро тебе вот просто влепили: "/usr is not mounted. This is not supported.". И в ответ знакомая ссылка про separate-usr-is-broken-bla-bla-bla.
	Ответить | Правка | ^ к родителю #258 | Наверх | Cообщить модератору

	385. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 16:12
	> Все тут боятся каких-то мифических вендотроллей. Тем временем кому-то из арчей уже > неповезло: http://comments.gmane.org/gmane.linux.arch.general/37167 М-да, арчеводы доорались со своей пригодностью к продакшну и вкусили прелести от мистера Поттеринга... > Вот так вот. Обновился ты по привычке, и на следующее утро тебе > вот просто влепили: "/usr is not mounted. This is not supported.". > И в ответ знакомая ссылка про separate-usr-is-broken-bla-bla-bla. Роллинг релиз такой роллинг. А у гентуйцев бывали например смешные отъезды версий питона до состояния когда не работает emerge. По поводу чего они выдавали на гора немало кирпичей.
	Ответить | Правка | ^ к родителю #341 | Наверх | Cообщить модератору

	187. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:26
	> И, *ля, ему все верят! Это меня больше всего удивляет. Сумел таки убедить RH в нужности своих велосипедов. Талант! Перевести бы его из программеров в маркетологи. А чего? Пишет хреново, хорошо впаривает. Вот пускай и займется последним.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	190. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 16:29
	> Пишет хреново, хорошо впаривает. Пишет он неплохо (по крайней мере читанное несколько лет тому), да и без освещения сколько легендарных проектов загнулось.  Тут IMHO скорее вопрос в том, человек уже убеждён в том, что именно он д'Артаньян, или ещё слушает других и умеет жать на тормоза вовремя.  Хотя рад бы и в этом ошибиться...
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	317. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от XoRe (ok) on 20-Ноя-11, 20:18
	>> Пишет хреново, хорошо впаривает. > Пишет он неплохо (по крайней мере читанное несколько лет тому), да и > без освещения сколько легендарных проектов загнулось.  Тут IMHO скорее вопрос > в том, человек уже убеждён в том, что именно он д'Артаньян, > или ещё слушает других и умеет жать на тормоза вовремя.   > Хотя рад бы и в этом ошибиться... Пишет - смысле код)
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	386. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 16:14
	> в том, человек уже убеждён в том, что именно он д'Артаньян, > или ещё слушает других и умеет жать на тормоза вовремя.   А это у редхатчиков наследственное. Ульрих у них такой же, даже в более клинической форме. На том же форониксе была новость что кто-то из федористов этому не рад, да только думается что всяким Ульрихам и Поттерингам все это сильно пофиг.
	Ответить | Правка | ^ к родителю #190 | Наверх | Cообщить модератору

	267. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:49
	> Это меня больше всего удивляет. Сумел таки убедить RH в нужности своих велосипедов. Открою вам страшную тайну: его велосипеды - с круглыми колесами - выгодно смотрятся на фоне использовавшихся до него велосипедов с квадратными колесами.
	Ответить | Правка | ^ к родителю #187 | Наверх | Cообщить модератору

	319. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от XoRe (ok) on 20-Ноя-11, 20:19
	>> Это меня больше всего удивляет. Сумел таки убедить RH в нужности своих велосипедов. > Открою вам страшную тайну: его велосипеды - с круглыми колесами - выгодно > смотрятся на фоне использовавшихся до него велосипедов с квадратными колесами. Т.е. десятилетиями *nix дураки делали, и только сейчас пришел один умный человек?
	Ответить | Правка | ^ к родителю #267 | Наверх | Cообщить модератору

	338. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от kpykcb (ok) on 21-Ноя-11, 05:58
	>>> Это меня больше всего удивляет. Сумел таки убедить RH в нужности своих велосипедов. >> Открою вам страшную тайну: его велосипеды - с круглыми колесами - выгодно >> смотрятся на фоне использовавшихся до него велосипедов с квадратными колесами. > Т.е. десятилетиями *nix дураки делали, и только сейчас пришел один умный человек? Радиосвязь тоже не дураки придумали, но это не повод ограничивать себя выстукиванием морзянки, если есть способы передать большие объемы данных и быстрее. И перфокарты, тоже люди гениальные придумали, но что по этому поводу, закрыть галаза на необходимость носить при себе большое количество данных иналичие флеш памяти? Время поменялось, и требования тоже.
	Ответить | Правка | ^ к родителю #319 | Наверх | Cообщить модератору

	198. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:42
	> Разница начнется, когда: > # journal-viewer --service=httpd | grep щтототам > failed: journal index corrupted Т.к. записи идут последовательно - их можно и без индекса хапнуть, и вообще там озвучена цель что truncate не должен вызывать проблем. Просто без индекса будет тормознее.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	226. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 18:33
	> Т.к. записи идут последовательно - их можно и без индекса хапнуть, и вообще там озвучена цель что truncate не должен вызывать проблем. Просто без индекса будет тормознее. А теперь подумай еще раз - этот чудик предлагает возможность сохранять в логах блобы - о какой последовательности может идти речь вообще? все записи разной длинны, разделителя нет т.к. любой символ может быть в блобе - ты не сможешь точно отделить одно от другого.
	Ответить | Правка | ^ к родителю #198 | Наверх | Cообщить модератору

	268. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:52
	> А теперь подумай еще раз - этот чудик предлагает возможность сохранять в > логах блобы - о какой последовательности может идти речь вообще? все > записи разной длинны, разделителя нет т.к. любой символ может быть в > блобе - ты не сможешь точно отделить одно от другого. Это сами решили, что будет блоб без разделителей? Хочу вас огорчить: _ваша_ реализация Journal обречена на провал. Что ж, вы не Поттеринг. Бросьте кодинг и админство, займитесь чем-нибудь более подходящим по вашим способностям.
	Ответить | Правка | ^ к родителю #226 | Наверх | Cообщить модератору

	305. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 20-Ноя-11, 11:56
	> Это сами решили, что будет блоб без разделителей? > Хочу вас огорчить: _ваша_ реализация Journal обречена на провал. > Что ж, вы не Поттеринг. Бросьте кодинг и админство, займитесь чем-нибудь более > подходящим по вашим способностям. Чукча не читатель? Ну обрисуй мне формат лога, позволяющего сохранять в себе фрагменты бинарных данных произвольного размера и при этом имеющий фиксированные размеры записей самого лога.
	Ответить | Правка | ^ к родителю #268 | Наверх | Cообщить модератору

	320. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от XoRe (ok) on 20-Ноя-11, 20:20
	>> Это сами решили, что будет блоб без разделителей? >> Хочу вас огорчить: _ваша_ реализация Journal обречена на провал. >> Что ж, вы не Поттеринг. Бросьте кодинг и админство, займитесь чем-нибудь более >> подходящим по вашим способностям. > Чукча не читатель? Ну обрисуй мне формат лога, позволяющего сохранять в себе > фрагменты бинарных данных произвольного размера и при этом имеющий фиксированные размеры > записей самого лога. Можно сделать, как в файловых системах - отдельно список записей, отдельно записи.
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	340. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 21-Ноя-11, 06:27
	> Можно сделать, как в файловых системах - отдельно список записей, отдельно записи. Вот и поперли костыли. Если в логах не хранить бинарные данные - зачем сами логи делать бинарными? Тем более с фиксированным размером записи. P.S. Если бы этот укурыш взялся стандартизировать форматы логфайлов, да так, чтобы их можно было не с помощью регекспов парсить, а простым `cut -d: -f 3-4 ` - многие ему бы спасибо сказали.
	Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

	387. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 17:15
	> Вот и поперли костыли. Если в логах не хранить бинарные данные - А иногда как бы и бинарные данные не лишние. Тот же дамп смарта, кордамп, подозрительный зарпос в вебсерванте или там что еще. В виде текста не всегда возможно это сохранить без потерь, а теми методами которыми возможно - оно распухает в 2-3 раза и потом малопонятно на глаз. Какая разница - увидите вы байт 0xFC в хексэдиторе глядя на блоб "как есть" или его преобразованный в текст вид типа %7C/0x7C/.... И в данный момент если какой-то пудак выпендрился и попробовал использовать нестандартные символы в логине/нике/урле/что там кто логгит - залоггить это в корректном виде может не получаться. Т.е. админ может не получить возможность даже просто узреть проблему в ее первозданном виде. А если можно записать запрос как блоб, содержащий все байты от 0 до FF - проблема отпадает как класс.
	Ответить | Правка | ^ к родителю #340 | Наверх | Cообщить модератору

	403. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 21:50
	> Можно сделать, как в файловых системах - отдельно список записей, отдельно записи. после чего список загнулся, и карета превратилась в тыкву. гениальное у тебя решение, точно в стиле поттеринга.
	Ответить | Правка | ^ к родителю #320 | Наверх | Cообщить модератору

	400. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 20:29
	> фрагменты бинарных данных произвольного размера и при этом имеющий фиксированные размеры > записей самого лога. А где благородный дон узрел в текстовике фиксированные размеры записей?
	Ответить | Правка | ^ к родителю #305 | Наверх | Cообщить модератору

	224. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 18:21
	а ведь был еще нулевой раунд - тот же человек взялся писать звуковой сервер (кстати, тоже обещал глобальное счастье), написал некий сырой отстой и пошел писать новый проект. Мавр сделал свое дело и гордо удалился. А остальные остались разгребать его какашки. Сдается мне также будет и с этим systemd - накидают прототип, который сможет запуститься хотя бы на некоторых системах. и скинут дальше на других людей, которым придется допинывать его до вменяемого состояния - ведь толпы "продвинутых пользователей" верят, что оптимизация скорости загрузки - самое главное в системе! и нельзя старперам давать задушить такой "важный" проект!
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	261. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:37
	> Разница начнется, когда: > # journal-viewer --service=httpd | grep щтототам > failed: journal index corrupted Ну, если бы реализацией этой идеи занимался не Поттеринг, а вы, то оно, может, так и было. Но, к счастью, нам это не грозит. > Тогда нужно быть последовательным в этом деле - не надо считать предыдущие > поколения админов и разработчиков тупее себя. > Подсистемы сбора и хранения логов тестировались в боевых условиях десятилетиями. > Если логи важны, то их можно передавать по сети на отдельный сервер > логов. > А сами файлы логов - архивировать и подписывать gpg. Правильно, нефиг считать предков глупее себя. Каменные топоры тестировались в условиях охоты на мамонтов сотни тысяч лет. Достаточно хорошо заточить каменный топор, и из него получится отличный инструмент для изготовления микросхем! > Пишет альфа-версию новой системы. > Обещает, что она решит все проблемы человечества. > Делает бета версию. > "внезнапно" узнает, что бета версия имеет массу недостатков. ... Выпускает релиз, в котором недостатки таки устранены и проблемы человечества решаются. > Раунд 2: usr > Приходит человек. > Объявляет существующий _работающий_ механизм устаревшим и неэффективным. > Предлагает решение, которое ломает существующие договоренности, но поможет решить проблемы > первого раунда. А, еще один виндузятник, не знающий матчасти :)
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	306. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 20-Ноя-11, 12:00
	>> Раунд 2: usr >> Приходит человек. >> Объявляет существующий _работающий_ механизм устаревшим и неэффективным. >> Предлагает решение, которое ломает существующие договоренности, но поможет решить проблемы >> первого раунда. > А, еще один виндузятник, не знающий матчасти :) Видимо, это не всё-таки вендузятник, раз считает этот подход неправильным.
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	321. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от XoRe (ok) on 20-Ноя-11, 20:31
	>> Разница начнется, когда: >> # journal-viewer --service=httpd | grep щтототам >> failed: journal index corrupted > Ну, если бы реализацией этой идеи занимался не Поттеринг, а вы, то > оно, может, так и было. > Но, к счастью, нам это не грозит. Переход на личности? Хорошо. Значит контр-аргументов по теме у вас нет. >> Раунд 2: usr >> Приходит человек. >> Объявляет существующий _работающий_ механизм устаревшим и неэффективным. >> Предлагает решение, которое ломает существующие договоренности, но поможет решить проблемы >> первого раунда. > А, еще один виндузятник, не знающий матчасти :) Попробуйте перенести роль контроллера домена с одного сервера на другой. Узнаете много нового, интересного, но неочевидного. А потом попробуйте перенести роль сервера ldap-авторизации. Казалось бы, одна и та же технология - и там ldap, и там ldap. Но есть нюанс)
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	404. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 22-Ноя-11, 21:52
	> Выпускает релиз, в котором недостатки таки устранены и проблемы человечества решаются. неужели пульсаудио наконец-то стал состоять из одного скрипта: выкорчёвывания этой мерзости из системы нафиг?
	Ответить | Правка | ^ к родителю #261 | Наверх | Cообщить модератору

	272. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:08
	> Разница начнется, когда: > # journal-viewer --service=httpd | grep щтототам > failed: journal index corrupted Система хранения логов в Journal будет строиться по аналогии с Git. А последний что-то не знаменит такими проблемами. Программистами уровня Торвальдса и Поттеринга таких глупых ошибок, как правило, не допускают.
	Ответить | Правка | ^ к родителю #55 | Наверх | Cообщить модератору

	322. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от XoRe (ok) on 20-Ноя-11, 20:33
	>> Разница начнется, когда: >> # journal-viewer --service=httpd | grep щтототам >> failed: journal index corrupted > Система хранения логов в Journal будет строиться по аналогии с Git. А > последний что-то не знаменит такими проблемами. > Программистами уровня Торвальдса и Поттеринга таких глупых ошибок, как правило, не допускают. git - уже есть в природе. journal - есть пока на словах. Нужно подождать, пока он появится в природе. Тогда можно будет сказать, что он может.
	Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

	348. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от а on 21-Ноя-11, 11:40
	>> # journal-viewer --service=httpd | grep щтототам >> failed: journal index corrupted > Система хранения логов в Journal будет строиться по аналогии с Git. А последний что-то не знаменит такими проблемами. Это потому что git обычно не обновляет свою базу во время аварии, а система хранения логов  работающая во время аварии — это как раз повсеместное её состояние.
	Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

	380. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Scytale on 22-Ноя-11, 15:21
	>>Программистами уровня Торвальдса и Поттеринга таких глупых ошибок, как правило, не допускают. как минимум некорректно и оскорбительно приравнивать "уровень Поттеринга" к "уровню Торвальдса"
	Ответить | Правка | ^ к родителю #272 | Наверх | Cообщить модератору

	12. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 00:40
	> всё бы хороо, кроме того что эти логи нужны для просмотра и > поиска из командной строки, стандартными средствами. А какая разница писать "zcat log.*.bz2|grep key" или "jview -a log |grep key" или "jgrep log 'key=aaa'" ?
	Ответить | Правка | ^ к родителю #2 | Наверх | Cообщить модератору

	53. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
	Сообщение от XoRe (ok) on 19-Ноя-11, 02:52
	>> всё бы хороо, кроме того что эти логи нужны для просмотра и >> поиска из командной строки, стандартными средствами. > А какая разница писать "zcat log.*.bz2|grep key" или "jview -a log |grep > key" или "jgrep log 'key=aaa'" ? Разница начнется, когда: # jview -a log |grep key failed: index corrupted
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	57. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ononom on 19-Ноя-11, 03:18
	>>> всё бы хороо, кроме того что эти логи нужны для просмотра и >>> поиска из командной строки, стандартными средствами. >> А какая разница писать "zcat log.*.bz2|grep key" или "jview -a log |grep >> key" или "jgrep log 'key=aaa'" ? > Разница начнется, когда: > # jview -a log |grep key > failed: index corrupted иди кури, как строятся/перестраиваются поисковые индексы для append-only баз данных, одмин локалхоста
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	199. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:43
	> failed: index corrupted А что помешает прочитать записи последовательно без использования индекса? Это будет тормознее но что помешает отпарсить это по цепочке - не понятно.
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	271. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:05
	> Разница начнется, когда: > # jview -a log |grep key > failed: index corrupted Так и запишем: юзера XoRe к разработке Journal не допускать, т.к. он непременно попытается завязать все на индексы, которые легко повредить. P.S. Как часто вы видите такое сообщение при работе с Git?
	Ответить | Правка | ^ к родителю #53 | Наверх | Cообщить модератору

	349. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от а on 21-Ноя-11, 11:46
	>> Разница начнется, когда: >> # jview -a log |grep key >> failed: index corrupted > Так и запишем: юзера XoRe к разработке Journal не допускать, т.к. он > непременно попытается завязать все на индексы, которые легко повредить. > P.S. Как часто вы видите такое сообщение при работе с Git? Как часто у Вас рушиться сервер во время работы git?
	Ответить | Правка | ^ к родителю #271 | Наверх | Cообщить модератору

	54. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 02:57
	такая, что zcat есть практически в любом как-то связанном с unix дистрибутиве. хоть с live-cd бородатого года подключайся, если модули для ФС есть - логи прочитаешь. а jview ещё не факт, что везде будет вообще. это я рассматриваю случаи, когда система умерла и логи лежат, а прочитать их можно лишь извне. текстовый файл откроешь легко и непринуждённо. а с этим Journal, скорее всего, поматериться придётся немало.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	58. "Разработчики systemd представили Journal, замену системе sys..."	–5 +/–
	Сообщение от ononom on 19-Ноя-11, 03:21
	> такая, что zcat есть практически в любом как-то связанном с unix дистрибутиве. > хоть с live-cd бородатого года подключайся, если модули для ФС есть > - логи прочитаешь. > а jview ещё не факт, что везде будет вообще. > это я рассматриваю случаи, когда система умерла и логи лежат, а прочитать > их можно лишь извне. текстовый файл откроешь легко и непринуждённо. а > с этим Journal, скорее всего, поматериться придётся немало. т.е. grep тебе не нужен, глазами собрался искать? или grep (от которого ты, о боже, зависишь!) все-таки есть?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	63. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 03:54
	сам как думаешь?
	Ответить | Правка | ^ к родителю #58 | Наверх | Cообщить модератору

	200. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:44
	> а jview ещё не факт, что везде будет вообще. То же самое было когда-то верно и для zcat. Как вы им тогда пользуетесь?
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	216. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 17:22
	zcat - всего лишь синтаксический сахар для gzip + cat, и то и другое есть абсолютно везде.
	Ответить | Правка | ^ к родителю #200 | Наверх | Cообщить модератору

	389. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 17:21
	> zcat - всего лишь синтаксический сахар для gzip + cat, и то > и другое есть абсолютно везде. Этот синтаксический сахар разбирает синтаксис бинарного потока, состоящего из лемпел-зива и хаффмана. Вы мозгом тронетесь такой поток парсить без спецпрограммы. И если у вас нет в системе программ способных распаковывать deflate - черта с два вы такой бинарный мусор прочитаете. Но ведь двойные стандарты - это ж здорово, да? :)
	Ответить | Правка | ^ к родителю #216 | Наверх | Cообщить модератору

	276. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:19
	> а jview ещё не факт, что везде будет вообще. Думаю, через пару лет это будет во всех более-менее современных дистрибутивах. А использовать для восстановления системы софт столетней давности... вы еще попробуйте с 32-битного лайва чрутнуться в 64-битную систему. И обругайте x86_64 с ее идиотскими и ненужными фичами, типа поддержки больших объемов оперативки.
	Ответить | Правка | ^ к родителю #54 | Наверх | Cообщить модератору

	345. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 21-Ноя-11, 08:47
	Ты бы еще в PPC систему из x86 предложил чрутиться, чудак.
	Ответить | Правка | ^ к родителю #276 | Наверх | Cообщить модератору

	390. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 22-Ноя-11, 17:23
	> Ты бы еще в PPC систему из x86 предложил чрутиться, чудак. Давайте я вам лучше предложу парсить гзипованый поток без спецпрограмм. Zcat же может и не быть в какой-то системе, да и zlib в принципе тоже. Поэтому давайте вы попробуете строить деревья хаффмана прямо в голове по этому поводу? :)
	Ответить | Правка | ^ к родителю #345 | Наверх | Cообщить модератору

	406. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 04:45
	> Поэтому давайте вы попробуете строить деревья хаффмана прямо в голове Хаффман это архив, а не живой текущий файл журнала. В архиве храните в чём Вам угодно, хоть в RAR.
	Ответить | Правка | ^ к родителю #390 | Наверх | Cообщить модератору

	419. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 20:18
	> Хаффман это архив, а не живой текущий файл журнала. И что? Может, архив был сделан 5 минут назад и стал нужен? Так что предлагаю для симметрии выдать архиваторам :)
	Ответить | Правка | ^ к родителю #406 | Наверх | Cообщить модератору

	228. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 18:46
	> А какая разница писать "zcat log.*.bz2|grep key" или "jview -a log |grep key" или "jgrep log 'key=aaa'" ? Да с чего все привязались к архивированию файлов? это делает syslog? нет, этим занимаются совершенно отдельные приложения. Поэтому в простейшем случае мне достаточно сделать less или grep на файл лога. и никаких вариантов с повреждением индексов, развалившимся блобом или прочим геморроем, заботливо уготованным нам товаришем поттерингом!
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

	239. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 20:45
	>> всё бы хороо, кроме того что эти логи нужны для просмотра и >> поиска из командной строки, стандартными средствами. > А какая разница писать "zcat log.*.bz2|grep key" или "jview -a log |grep > key" или "jgrep log 'key=aaa'" ? Лишняя сущность.
	Ответить | Правка | ^ к родителю #12 | Наверх | Cообщить модератору

3. "Разработчики systemd представили Journal, замену системе sys..."	+6 +/–
Сообщение от arka on 19-Ноя-11, 00:20
Иногда для упрощения бросаю через LOG_DEBUG всякие данные вместо полноценного дебага. Судя по новости (уход от "читаемого" формата) - хочется, чтобы это не попало в FreeBSD
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	277. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:24
	> Судя по новости (уход от "читаемого" формата) Судя по новости, они как раз собираются от нечитаемого формата перейти к читаемому (ну в самом деле, анализ кучи слабо связанных текстовых файлов с произвольной формой записи информации по сравнению с выборкой из структурированной БД выглядит весьма запутанным квестом). > хочется, чтобы это не попало в FreeBSD Такими темпами фря всегда будет остающей-догоняющей :(
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

	350. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 11:50
	>> Судя по новости (уход от "читаемого" формата) > Судя по новости, они как раз собираются от нечитаемого формата перейти к > читаемому (ну в самом деле, анализ кучи слабо связанных текстовых файлов > с произвольной формой записи информации по сравнению с выборкой из структурированной > БД выглядит весьма запутанным квестом). Современные syslog позволяют писать в БД. Зачем нужен Journal?
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	425. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 21:07
	> Современные syslog позволяют писать в БД. БД не обеспечиавет защиту от подделки + подразумевает усилия на администрировние.
	Ответить | Правка | ^ к родителю #350 | Наверх | Cообщить модератору

	351. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 11:56
	>> Судя по новости (уход от "читаемого" формата) > Судя по новости, они как раз собираются от нечитаемого формата перейти к > читаемому (ну в самом деле, анализ кучи слабо связанных текстовых файлов > с произвольной формой записи информации по сравнению с выборкой из структурированной > БД выглядит весьма запутанным квестом). Да и что Вы собрались структурировать? В syslog три поля которые легко выделяются в начале каждой строки, всё остальное - это текст из программы, не предлагаете же Вы переписать ВСЕ программы пишущие в syslog? Что бы они писали не текст, а что, бинарную структуру? Весь этот Journal гордиться чтобы выделить дату, PID и имя процесса в отдельные поля в бинарных файлах? Жесть...
	Ответить | Правка | ^ к родителю #277 | Наверх | Cообщить модератору

	426. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 21:10
	> Весь этот Journal гордиться чтобы выделить дату, PID и имя процесса в > отдельные поля в бинарных файлах? Жесть... Жесть - это когда каждый козел пишет дату в разном формате в меру своей дурости. М поэтому приходится для каждого лога переделывать парсеры, бл. В особо продвинутом случае требуется скилл по типу "декодирование unix time в мозгу". И да, парсить в анализаторе логов фиксированные структуры с оговоренным содержимым - явно проще и быстрее.
	Ответить | Правка | ^ к родителю #351 | Наверх | Cообщить модератору

	431. "Разработчики systemd представили Journal, замену системе..."	+/–
	Сообщение от arisu (ok) on 24-Ноя-11, 08:44
	а ничего, что сислог само умеет даты писать? и никто даты не пишет, потому что полагается на сислог? впрочем, с кем это я? ты же сислог видел максимум в пакете «оно поставилось».
	Ответить | Правка | ^ к родителю #426 | Наверх | Cообщить модератору

	292. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от SomeUser on 20-Ноя-11, 02:57
	Видел я такой "кодинг". Спасибо, не нужно ни во фре, ну в других осях... и пишите нормальные логи...
	Ответить | Правка | ^ к родителю #3 | Наверх | Cообщить модератору

6. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 00:32
как это спасет от простого cat > ./crypted.log ?  да, видно что лог удалили, но что это меняет ?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	80. "Разработчики systemd представили Journal, замену системе sys..."	+18 +/–
	Сообщение от Andrew Kolchoogin on 19-Ноя-11, 05:02
	+100500! :) Никак не спасёт. Поттеринг просто немного перегрелся. Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога на отдельный, недоступный из Интернета сервер. Всё. Вообще, у Поттеринга, как и у любого другого человека, есть идеи удачные, и не очень. Небольшой debriefing лично от меня, как от человека, администрирующего Юникс последние лет 15 (или больше уже?): I. systemd. В принципе, идея верная, но это reinvention of wheel. Был же launchd от Apple, чем плох? Ах, да, лицензия, как же, как же... Но init, действительно, давно и безнадёжно устарел. В старые добрые времена особенно много зависимостей сервисов друг от друга сделать было просто физически невозможно: машинки были слабыми. Как правило, на одной физической машине работал Apache, на другой -- SQL, на третьей -- почтовка, ну и так далее. Поэтому, по большому счёту, всё равно, что там, как и когда запускалось. Не работает -- саппорт машину перезагрузит по звонку админа, и дело с концом. Другие сервисы не пострадают (они на другом физическом железе), а этот и так упал. Но времена изменились, и теперь на одном физическом хосте можно собрать всё вместе и сразу. Нет, конечно, это не очень правильно -- правильно сделать облако, виртуалки на нём и т.д. Но в 70-80% случаев оверхед от администрирования облачной инфраструктуры будет сравним с затратами на администрирование того, что на этой инфраструктуре крутится. Кто его оплатит? Теоретики "облачности"? Сомневаюсь. Так что интеллектуальный пускач-следилка по сути. Но, опять-таки, systemd -- это изобретение колеса. II. Сломанная загрузка без /usr. Не стреляйте в Поттеринга -- это не его рук дело. Дело в корявых софтоархитекторах. Директории /sbin и /usr/sbin имеют буковку "s" в своём названии не зря -- они имеют оную буковку потому, что подразумевалось, что все бинарники в них -- STATICALLY linked. Тот, кто это сломал -- сломал и загрузку без /usr. Да, можно вынести часть библиотек в /lib, без проблем, но библиотеки написаны так, что без /usr/share половина из них не работает. Ну и так далее. III. PulseAudio. Ну, опять-таки, reinvention of wheel. Был NAS. Он СПЕЦИАЛЬНО был сделан для ремотного проброса аудио. Использует аутентификацию X'ов. Но лих же, нет! Надо было своё, с шахматами и поэтессами, придумать! А те, кто кричит, что звуковой сервер в UNIX'е не нужен, идут в сад. Тривиальности про Terminal Server мы опустим сразу, тут и так всё понятно. Вот смотрите: у вас есть, к примеру, Asterisk. Стоит он чёрт-те где, за семью замками, за семью дверями, рядом с SDH'ным барахлом ГТС. Ходят к нему абоненты. Через SIP. И начинают вам жаловаться, что у них-де "плохо слышно". Как проверить? Правильно, встать столом на линию абонен... Ой, про что это я? Ах, да. Позвонить абоненту со станции, вот. Да-да, "console dial ...". И как вы это будете без звукового сервера слушать? За семь замков, за семь дверей пешком пойдёте? Идея подключиться к станции SIP-клиентом и позвонить порочна по сути. Ну услышите вы, что плохо слышно. Это у вас SIP-клиент кривой, или у абонента? IV. Логгер. Ну, тут всё вообще хорошо. Во-первых, msyslog тыщщу лет как умеет криптографически логи подписывать. Во-вторых, для того, чтобы что-то подписывать, совершенно необязательно перетаскивать всё это в бинарный формат. В третьих, "каждый процесс может представиться Apache с PID 4321" -- ну да. Вы от remote logging'а откажетесь, или по сети будете проверять? Ну и таки да -- от "cat /dev/null > /var/log/whatever" это всё равно не спасёт. :)
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	91. "Разработчики systemd представили Journal, замену системе sys..."	–4 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:25
	> Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога > на отдельный, недоступный из Интернета сервер. Всё. Ты даже русский толком не знаешь, а пытаешься иностранными словами щегольнуть. Tampering - это как раз "подделка\изменение" логов и криптография от него отлично спасает. А простое удаление это wiping, который заметен сразу.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	148. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Andrew Kolchoogin on 19-Ноя-11, 13:01
	> Ты даже русский толком не знаешь, а пытаешься иностранными словами щегольнуть. Учителя русского языка так не считают. > Tampering - это как раз "подделка\изменение" логов и криптография от него отлично спасает. Вообще говоря, "tampering" -- это любая манипуляция. Фальсификация в частности. > А простое удаление это wiping, который заметен сразу. Если буквоедствовать, то "cat /dev/null >" -- это не удаление. Короче, Онанизмус как всегда. ;)
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	150. "Разработчики systemd представили Journal, замену системе sys..."	–3 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 13:10
	Как я предполагал - облажался и стал буквоедствовать. Если действительно "никакая криптография не спасёт от подделки", то подделай логи для Поттеринговской реализации и выложи proof-of-concept. Впрочем, тебе не просто слабо - ты даже не знаешь с какой стороны взяться за подобное.
	Ответить | Правка | ^ к родителю #148 | Наверх | Cообщить модератору

	155. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 13:24
	> Как я предполагал - облажался и стал буквоедствовать. Вы бы ротик-то скотчем заклеили, что ли.  Несёте общие фразы, большая часть которых наводит на мысль, что сами о том, что советуете, имеете только туманное представление -- иначе бы составляли их чуточку иначе.  Согласитесь, глупо буквоедствуя наезжать на буквоедствование, при этом допуская элементарные ошибки _ровно_ в той области, по которой наезжаете. to wipe можно как файл, так и данные.  Это различные операции и к tampering относятся обе, хотя обычно последний термин применяют, говоря о модификации, а не уничтожении тех же логов. > Если действительно "никакая криптография не спасёт от подделки", то подделай логи > для Поттеринговской реализации и выложи proof-of-concept. Я чуть ли не каждый день пользуюсь git rebase и пока не с чем сверять снаружи -- такую "подделку" можно обнаружить разве что до git prune (или git gc через пару недель с дефолтным таймаутом, если уж докапываться). > Впрочем, тебе не просто слабо - ты даже не знаешь с какой > стороны взяться за подобное. Слушайте, а давайте-ка *Вы* предъявите общественности плоды своего понимания криптографии и обсуждаемого, набросав PoC для переписи истории таких логов при условии возможности поправить и лежащий локально начальный хэш.  А мы дружно посыпем головы пеплом и извинимся, что не разглядели в трамвайном хаме хотя бы специалиста.
	Ответить | Правка | ^ к родителю #150 | Наверх | Cообщить модератору

	167. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 14:14
	>> Если действительно "никакая криптография не спасёт от подделки", то подделай логи >> для Поттеринговской реализации и выложи proof-of-concept. > Я чуть ли не каждый день пользуюсь git rebase и пока не > с чем сверять снаружи -- такую "подделку" можно обнаружить разве что > до git prune (или git gc через пару недель с дефолтным > таймаутом, если уж докапываться). Ну что, можно засчитывать слив? :) 1. Есть тупое утверждение, что "никакая криптография не спасёт от подмены логов". 2. Есть разумное предположение, что криптография очень даже может предотвратить изменение логов. Для утверждения №2 есть предварительная реализация Поттеринга, описанная в новости. Для утверждения №1 есть только потрясающе "умная" аргументация как кто-то "использовал git rebase", не имеющий к исходному вопросу вообще никакого отношения. Ещё есть вопросы, почему я считаю утверждение №1 тупым?
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	174. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 14:26
	> Ну что, можно засчитывать слив? :) Уже засчитали. > 1. Есть тупое утверждение, что "никакая криптография не спасёт от подмены логов". Это утверждение не тупое, хотя в некоторых случаях неверное -- в данном (подписывание, не шифрование) верное. > 2. Есть разумное предположение, что криптография очень даже может предотвратить > изменение логов. Это предположение в данном случае является неверным, насколько могу судить. > Ещё есть вопросы, почему я считаю утверждение №1 тупым? У меня к Вам вопросов нет, поскольку Вы продемонстрировали неспособность отличить предотвращение от обнаружения.  Пожалуйста, успокойтесь. PS: коллеги схожий метод применяли на одном объекте ещё чуть ли не десяток лет тому, и их потом действительно попытались подставить, так что морока была не зря...
	Ответить | Правка | ^ к родителю #167 | Наверх | Cообщить модератору

	201. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:45
	> Я чуть ли не каждый день пользуюсь git rebase и пока не > с чем сверять снаружи -- такую "подделку" можно обнаружить разве что > до git prune (или git gc через пару недель с дефолтным > таймаутом, если уж докапываться). А тут будет базовый хеш от которого танцы, недоступный хаксору в идеале. С помощью которого можно проверить - надули нас или нет.
	Ответить | Правка | ^ к родителю #155 | Наверх | Cообщить модератору

	210. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 16:57
	> А тут будет базовый хеш от которого танцы Не-не, сама идея понятна и уместна. >> и пока не с чем сверять снаружи > недоступный хаксору в идеале. Это меняет объём информации, которую _необходимо_ держать снаружи для возможности _обнаружить_ подлог -- но если заниматься априори распределённым логгингом (даже если вне хоста держать только хэш), то видится полный смысл озадачиться и лог-сервером, чтоб не опасаться уничтожения локальных логов что злонамеренным кодом/человеком, что аппаратным сбоем.  Несколько раз выручало при диагностике, когда нужные строчки просто не смогли бы долететь до локальных блинов...
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	215. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 17:07
	Базовый хэш нужен для проверки логов, следовательно логи придется все равно тащить логи на доверенный сервер, чтобы там проверить подпись.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	401. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 20:45
	> Базовый хэш нужен для проверки логов, следовательно логи придется все равно тащить > логи на доверенный сервер, чтобы там проверить подпись. А что если я загружусь с ливфлешки на которой хеш есть и с нее проверю достоверность логов? Как вариант можно кстати сеть отрубить, оставив хаксора без шансов к спиранию этого самого хеша.
	Ответить | Правка | ^ к родителю #215 | Наверх | Cообщить модератору

	295. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от vi on 20-Ноя-11, 03:46
	>> Я чуть ли не каждый день пользуюсь git rebase и пока не >> с чем сверять снаружи -- такую "подделку" можно обнаружить разве что >> до git prune (или git gc через пару недель с дефолтным >> таймаутом, если уж докапываться). > А тут будет базовый хеш от которого танцы, недоступный хаксору в идеале. > С помощью которого можно проверить - надули нас или нет. Простите, бедного, слепого и прочего необученного (за глупые вопросы). Если мы можем: >Ну и таки да -- от "cat /dev/null > /var/log/whatever" это всё равно не спасёт. :) то разве мы не можем cat /dev/mem | grep "базовый хеш" ? или полюбовно договорится с новоявленной поделкой, ну например о том, что логгировать, а что нет? Спасибо.
	Ответить | Правка | ^ к родителю #201 | Наверх | Cообщить модератору

	218. "Разработчики systemd представили Journal, замену системе sys..."	+6 +/–
	Сообщение от гость on 19-Ноя-11, 17:29
	>> Никакая криптография и проч. не спасает от тамперинга логов. Только вынос лога >> на отдельный, недоступный из Интернета сервер. Всё. > Ты даже русский толком не знаешь, а пытаешься иностранными словами щегольнуть. И вообще, разве нас может интересовать мнение человека лысого, с таким носом? Пусть сначала исправит нос, отрастит волосы, а потом и выскажется. (с) Жванецкий Знает он русский толком или нет, но говорит правильную вещь, которую почему-то большинство в обсуждении игнорируют, а меньшинство не озвучивает: если хост скомпрометирован, то мы больше не можем ему доверять. Как следствие, мы не можем доверять логам хоста. Даже если там адски защищенная система логирования. Давайте посмотрим, что нам вообще дает среднестатистическая система защиты логов  криптографией в вакууме. - Она гарантирует целостность уже записанных данных? Да. - Она гарантирует аутентификацию процесса (именно нужный процесс записал в лог)? Нет. - Она гарантирует сохранность уже записанных данных? Нет. Между тем, причина всех воплей в этом обсуждении - обычные страхи. Главный страх, что весь этот сомнительный креатив (а его функционал до релиза остается сомнительным) окажется в майнстриме. Дистроклепатели уже проворачивали подобное, вот люди и переживают за стабильность своих систем. Ещё люди боятся излишнего усложения систем там, где это не требуется, что добавит новые векторы атак на их системы. И, наконец, люди вполне здраво опасаются товарищей, которые хотят "весь мир до основания разрушить и новый мир построить", благо товарищ уже показал себя способным создать "универсальное решение" которое создает больше проблем, чем решает.
	Ответить | Правка | ^ к родителю #91 | Наверх | Cообщить модератору

	407. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonimous on 23-Ноя-11, 08:34
	> - Она гарантирует целостность уже записанных данных? Да. Не совсем. Поскольку всё --- локально доступно, то есть возможность создать фальшивую историю и подписать её. Данные будут целостными, но фальшивыми.
	Ответить | Правка | ^ к родителю #218 | Наверх | Cообщить модератору

	269. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:58
	> Был же launchd от Apple, чем плох? Ах, да, лицензия, как же, как же... systemd пофичастее будет. Да и к технологиям линукса поближе (вряд ли в апстрим lanuchd добавят механизмы на основе fanotify, autofs4 и т.д.) Каждому свое. > В третьих, "каждый процесс может представиться Apache с PID 4321" -- ну да. Вы от remote logging'а откажетесь, или по сети будете проверять? Привязка источника к сообщению гарантируется службой журналирования отправляющего хоста, которую еще надо взломать. В отличие от syslog, который даже взламывать не надо - он уже by design работает на злоумышленника.
	Ответить | Правка | ^ к родителю #80 | Наверх | Cообщить модератору

	86. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 05:45
	> как это спасет от простого cat > ./crypted.log ?  да, видно > что лог удалили, но что это меняет ? Сразу видно что лог подделан/заменен. Сигнал о том что в системе шарится взломщик. Идея здравая, только вот это Поттеринг, у которого "хотели как лучше, а получилось как всегда".
	Ответить | Правка | ^ к родителю #6 | Наверх | Cообщить модератору

	223. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 18:20
	> Сразу видно что лог подделан/заменен. А если включить фантазию? dd if=/dev/urandom of=./crypted.log bs=1 count=1 seek=32 conv=notrunc Как оперативно узнать о его порче? Что теперь можно прочитать из лога? Что можно сказать о причинах порчи?
	Ответить | Правка | ^ к родителю #86 | Наверх | Cообщить модератору

	391. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 17:30
	> А если включить фантазию? > dd if=/dev/urandom of=./crypted.log bs=1 count=1 seek=32 conv=notrunc > Как оперативно узнать о его порче? Думается демон заметит проблемы быстро. Формат не совпадет, хеши не сойдутся -> у нас проблемы. А в текстовике вообще не проверишь это никак. Кроме анализа сисадмином лично. Никто никакие хеши на ходу не считает поэтому даже несойтись чексумм не сможет и оперативно узнать о порче текстовика - вообще никак. Машина не сможет это сама обнаружить. Да, если что - машины работают оперативнее человеков, ВНЕЗАПНО. > Что теперь можно прочитать из лога? То же самое что и из бывшего текстового лога подвергнутого такой же процедуре. Только текстарь безмолвно схавается всеми программами с любым мусором. Половина конечно будет жестоко глюкавить т.к. не ожидает полный набор байтов в "якобы текстовике", но надежно отличить осмысленный текст от рандома - не самая тривиальная задача. > Что можно сказать о причинах порчи? То же что и в случае текстовых логов. Примерно однохренственно, получите вы мусор в бинаре или в текстовике.
	Ответить | Правка | ^ к родителю #223 | Наверх | Cообщить модератору

	434. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 24-Ноя-11, 13:07
	> Формат не совпадет, хеши не сойдутся -> > у нас проблемы. Хеши чего, бинарных логов? Т.е. надо ещё где-то ещё держать хеши и пересчитывать раз после каждой записи? Уже вырисовываются уязвимости в подмене хешей и race condition во время чтение лога. С другой сторны не понятно что мешает считать хеши для текстового лога. Нам же по-хорошему надо его целостность проверить, а не зашифровать, да? ;) > А в текстовике вообще не проверишь это никак. А текстовик не обещает целостности данных в отличие от. > Кроме анализа сисадмином лично. Никто никакие хеши на ходу не считает > поэтому даже несойтись чексумм не сможет и оперативно узнать о порче > текстовика - вообще никак. Ой ли? А через сравнение с репликой на другом хосте? > Машина не сможет это сама обнаружить. Да, > если что - машины работают оперативнее человеков, ВНЕЗАПНО. Сам-то понял что хотел сказать? Внезапно, машина ничего не проверяет, проверяет софт. А софту на порученой машине доверять нельзя. >> Что теперь можно прочитать из лога? > То же самое что и из бывшего текстового лога подвергнутого такой же > процедуре. Только текстарь безмолвно схавается всеми программами с любым мусором. Почему же тоже самое, меньше. Данные шифруются блоками, вы об этом не знали? При расшифровке будут алерты о нечитаемости блоков. >> Что можно сказать о причинах порчи? > То же что и в случае текстовых логов. Примерно однохренственно, получите вы > мусор в бинаре или в текстовике. Вообще вопрос был как узнать что стало причиной порчи лога. Но раз однохренственно, то зачем городить огород?
	Ответить | Правка | ^ к родителю #391 | Наверх | Cообщить модератору

	435. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 24-Ноя-11, 13:15
	Про алерт о нечитаемости - не факт что это будет сделано, но это логично сделать для отлова ситуации с порчей лога, когда алгоритм смог дешифровать блок, но внутри мусор, иначе как мы узнаем что лог испорчен. Для диагностики придется вносить в криптоблок метку для опознания и сальт не помешало бы для криптостойкости. :)
	Ответить | Правка | ^ к родителю #391 | Наверх | Cообщить модератору

7. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
Сообщение от anonimous on 19-Ноя-11, 00:35
В добавление к registry Поттеринг тащит Event Log + Event Log Viewer. Скоро: ... представил новую систему Windows, призванную заменить устаревшую систему Linux. Только под новой системой вы сможете оценить все преимущества systemd и Journal.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	85. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 05:43
	> В добавление к registry Поттеринг тащит Event Log + Event Log Viewer. А хде registry?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	160. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 13:34
	>> В добавление к registry Поттеринг тащит Event Log + Event Log Viewer. > А хде registry? Более строго говоря, реестр тащил IBM (elektra, не помню, как в девичестве звалось).  Забросили.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	161. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 19-Ноя-11, 13:34
	>> В добавление к registry Поттеринг тащит Event Log + Event Log Viewer. > А хде registry? dconf же. Сейчас его тащит gnome3, а скоро будет и Qt5. Так что всё впереди.
	Ответить | Правка | ^ к родителю #85 | Наверх | Cообщить модератору

	280. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:33
	> ... представил новую систему Windows, призванную заменить устаревшую систему Linux. Только под новой системой вы сможете оценить все преимущества systemd и Journal. Скорее наоборот. В свое время, очень похожий на Поттеринга (и тоже ненавидимый вашими коллегами) человек по фамилии Торвальдс представил новое ядро, призванное заменить MS-DOS.
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	294. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Dmitry Nezhevenko on 20-Ноя-11, 03:17
	> Скорее наоборот. В свое время, очень похожий на Поттеринга (и тоже ненавидимый вашими коллегами) человек по фамилии Торвальдс представил новое ядро, призванное заменить MS-DOS. Только совсем не MS-DOS...
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	335. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 05:25
	> MS-DOS. Minix не хотите?
	Ответить | Правка | ^ к родителю #280 | Наверх | Cообщить модератору

	282. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:36
	> В добавление к registry Поттеринг тащит Event Log + Event Log Viewer. Что, друзья-виндузятнички, припекло, что эти мерзкие пингвины сокращают последние отставания по фичам от вашей распрекрасной винды?
	Ответить | Правка | ^ к родителю #7 | Наверх | Cообщить модератору

	301. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 11:21
	Не, мы не беспокоимся. Линуксу до венды еще деградировать и деградировать. Хотя работы в данном направлении Поттеринг ведет уже давно.
	Ответить | Правка | ^ к родителю #282 | Наверх | Cообщить модератору

8. "Разработчики systemd представили Journal, замену системе sys..."	+/–
Сообщение от Аноним (??) on 19-Ноя-11, 00:35
>> файлы с логами не должны зависеть от типа системы и CPU. Например, лог созданных на встраиваемом устройстве на базе архитектуры ARM должен быть просмотрен и на обычном ПК; теперь что, логи от cpu зависят? потеринг опасен т.к. научился писать менеджерообразным языком а в конце концов у него одни недоделки. пусть все копируется и в обычных логов - а кто хочет пусть изпользует его криптированного нечитабельного реджистри
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	14. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 00:45
	RTFM http://ru.wikipedia.org/wiki/%D0%9F%D0%B...
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

	30. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:24
	пусть пишут обычные логи в UTF + BOM, зачем в бинарный формат все засовывать
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	32. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:27
	С каких пор в plaint text порядок байт стал зависеть от архитектуры?
	Ответить | Правка | ^ к родителю #14 | Наверх | Cообщить модератору

	202. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:47
	> С каких пор в plaint text порядок байт стал зависеть от архитектуры? В utf'ном тексте - очень даже может, приколитесь? Как только буквы стали многобайтовыми, так и...
	Ответить | Правка | ^ к родителю #32 | Наверх | Cообщить модератору

	247. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 23:19
	не надо путать utf-16 и utf-8. utf-8 пофиг на порядок байтов на машине.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	336. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 05:26
	> utf-8 пофиг на порядок байтов на машине. Если записывать безбашенно то в принципе можно и облажаться. Правда по этому поводу родили пачку библ избавляющих нерюхов от стрельбы по пяткам :)
	Ответить | Правка | ^ к родителю #247 | Наверх | Cообщить модератору

	251. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Yakov Markovitch on 19-Ноя-11, 23:49
	А кто заставляет писать в UTF16/UTF32? В UTF8 не зависит, а *nix-систем, пишущих по-другому (коль уж вообще пишут в уникоде) я пока не встречал.
	Ответить | Правка | ^ к родителю #202 | Наверх | Cообщить модератору

	372. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 22-Ноя-11, 02:55
	В странах с не-иероглифической письменностью? Никто не заставляет. А вот китайцы с японцами пользуются UTF-16 по дефолту везде где можно.
	Ответить | Правка | ^ к родителю #251 | Наверх | Cообщить модератору

	436. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 24-Ноя-11, 13:20
	>>> файлы с логами не должны зависеть от типа системы и CPU. Например, лог созданных на встраиваемом устройстве на базе архитектуры ARM должен быть просмотрен и на обычном ПК; Он ещё не раз удивится как его софт зависит от CPU во время записи access.log нагруженного сервера. Предлагаю ему об этом не говорить, пока он занят этой диверсией, у него нет времени на другие диверсии против unix.
	Ответить | Правка | ^ к родителю #8 | Наверх | Cообщить модератору

11. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
Сообщение от pavlinux (ok) on 19-Ноя-11, 00:40
Как хорошо работать РедХат, суетится в Федоре и генерить бредовые идеи. При этом боты его воспринимают всерьёз.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

15. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 00:48
ну, человеку осталось заменить /etc на блоб, и получится жалкое подобие левой руки аикса.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	19. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Dmytro on 19-Ноя-11, 01:01
	Читать ваши коменты както страшно. Такое чувство что развиваться уже некуда не хотите. Вот научились наконец разгребать старые логи и все, кто решить разшевелить эту идилию тупой и больной. А слово "новый" у вас всех вызывает чувство страха. Так забейтесь в угол и пирдите там пока не уйдете вместе со своими старымы проверенымы ... Fedora - позыционируеться как иновационный дистр, и те кто его использует не лохи и бараны. А если вы его не хотите использовать (тестировать новые, не всегда горошие и генеальные нововведения) так не используйте, и нех тут срат попусту.
	Ответить | Правка | ^ к родителю #15 | Наверх | Cообщить модератору

	26. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от eve on 19-Ноя-11, 01:16
	Никогда не слышал "лучшее - враг хорошего"?
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

	33. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от pavlinux (ok) on 19-Ноя-11, 01:30
	Первой задачей при внедрении новшеств, является ПОЛНАЯ СОВМЕСТИМОСТЬ со старым частями системы. Ну нельзя выпускать танк с калибром и типом оружия, для которого надо заново строить или переоборудовать цеха для производства своих уникальных снарядов. Хочется что-то внедрить новое, так сделай патч для syslog, кто захочет подключит. Понравиться - сами перейдут. > Данные сообщений не аутентифицированы. Например, любой локальный процесс > может указать что он Apache с PID 4321, а syslog поверит этому и сохранит > сведения в лог; Опа, в Linux уже setpid() придумали?
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	93. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:28
	> Первой задачей при внедрении новшеств, является ПОЛНАЯ СОВМЕСТИМОСТЬ со старым частями > системы. павлинчик, ты чтение-то когда освоишь уже? Полная совместимость с syslog как раз одна из первичных целей journal.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	230. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 19:13
	Где мой "grep -R 'failed' /var/log", я тебя спрашиваю?!
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	285. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:51
	> Где мой "grep -R 'failed' /var/log", я тебя спрашиваю?! Вам действительно нужна команда, которая проворонивает половину сообщений об ошибках/падениях, просто потому, что они сформулированы без использования слова "failed"? Хм, боюсь, что средствами Journal сделать такое будет сложно. А вот простое и логичное - "хочу все сообщения об ошибках таких-то компонентов за указанный период времени" - на раз-два. Но это вас, как я понял, не интересует.
	Ответить | Правка | ^ к родителю #230 | Наверх | Cообщить модератору

	327. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Deffic on 21-Ноя-11, 04:32
	syslog в DB?
	Ответить | Правка | ^ к родителю #285 | Наверх | Cообщить модератору

	354. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 12:16
	> А вот простое и логичное - "хочу все сообщения об ошибках таких-то > компонентов за указанный период времени" - на раз-два. Но это вас, > как я понял, не интересует. Откуда они там появятся если все программы пишут в журнал простую текстовую строку? Предлагаете все программы переписать два раза, на Journal и на «все остальные *nix с syslog»? Если же вы про приоритет, то сообщения по приоритетам и сейчас прекрасно в _разные файлы_ пишутся.
	Ответить | Правка | ^ к родителю #285 | Наверх | Cообщить модератору

	448. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от XoRe (ok) on 01-Дек-11, 04:06
	>> Первой задачей при внедрении новшеств, является ПОЛНАЯ СОВМЕСТИМОСТЬ со старым частями >> системы. > павлинчик, ты чтение-то когда освоишь уже? > Полная совместимость с syslog как раз одна из первичных целей journal. Можете ткнуть туда, где такое написано?
	Ответить | Правка | ^ к родителю #93 | Наверх | Cообщить модератору

	138. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ffirefox on 19-Ноя-11, 12:42
	>Ну нельзя выпускать танк с калибром и типом оружия, для которого надо заново строить или переоборудовать цеха для производства своих уникальных снарядов Так вот и представил танки, которые для совместимости, стреляют каменными ядрами. Прямо прогресс по сколковски.
	Ответить | Правка | ^ к родителю #33 | Наверх | Cообщить модератору

	244. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от pavlinux (ok) on 19-Ноя-11, 21:36
	>>Ну нельзя выпускать танк с калибром и типом оружия, для которого надо заново > строить или переоборудовать цеха для производства своих уникальных снарядов > Так вот и представил танки, которые для совместимости, стреляют каменными ядрами. Не утрируй. В данном случае это выглядит как впихивание в танк 8 стволов по периметру башни, новая система подачи снарядов, но снаряды должны быть с квадратной гильзой. А для совместимости оставили пулемёт, чтоб в случае нападения можно было отстреливаться.
	Ответить | Правка | ^ к родителю #138 | Наверх | Cообщить модератору

	82. "Разработчики systemd представили Journal, замену системе sys..."	–3 +/–
	Сообщение от prokoudine (??) on 19-Ноя-11, 05:06
	> Никогда не слышал "лучшее - враг хорошего"? А как же — от староверов, которые землю на лошадях пашут и без электричества живут.
	Ответить | Правка | ^ к родителю #26 | Наверх | Cообщить модератору

	296. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от vi on 20-Ноя-11, 03:58
	>> Никогда не слышал "лучшее - враг хорошего"? > А как же — от староверов, которые землю на лошадях пашут и > без электричества живут. До изобретения электрической лампочки люди в среднем спали по 10 часов. ... После победы "Терминаторов", вас не стало (вот теперь и отдохнете ;). Заметьте, прогресс остановить невозможно. Можно только сойти с поезда. Да, и еще, надо жить (счастливо ;) !
	Ответить | Правка | ^ к родителю #82 | Наверх | Cообщить модератору

	241. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 21:07
	> Такое чувство что развиваться уже некуда не > хотите. Громождение новых, ни с чем не совместимых и непереносимых костылей? Развитие ради регресса? Мда... > Так забейтесь в угол и пирдите там пока не уйдете вместе со > своими старымы проверенымы ... Только после того, как ты сядешь за парту и подучишь немного грамматику. > Читать ваши коменты както страшно. ...
	Ответить | Правка | ^ к родителю #19 | Наверх | Cообщить модератору

17. "Разработчики systemd представили Journal, замену системе sys..."	+14 +/–
Сообщение от pavlinux (ok) on 19-Ноя-11, 00:54
Можно я погенерю идей: Новая система инициализации и устройство Linux. 1. В ядро впаивается SQL-клиент. 2. Первой и единственной службой стартует sqlinit. 3. Конфиг для sqlinit - статическая таблица в базе MAIN.      В этом конфиге прописаны:          - вся конфигурация железа;      - порядок запуска служб и их параметры, 4. Вся конфигурация, логи, данные пользователей, пользовательские конфиги,...    хранится в SQL базе, бинарники, там же - в BLOB типе. 5. И того на диске хранится 3 файла vmlinuz, sqlinit и SYSTEM.SQL :) 6. На уровне ядра все системные вызовы переписываются в SQL запросы,    так read()/write() будут представляться как SELECT/INSERT 7. Для сохранения работы предыдущих поколений делаются алиасы совместимости,    так команда grep вызванная из скрипта, алиасится на grepsql, ls в lssql    mysql в mysqlsql (ах да, это вы должны сделать сами, не барское это дело) Вы спросите, - а зачем нужна прокладка в виде SQL?! Дык, профит и прогресс очевиден - мне надо повыё..ться и оставить след на этой ничтожной планете... ХА-ХА-ХА. ЖАЛКИЕ ЛЮДИШКИ!!! %)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	24. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Шредер on 19-Ноя-11, 01:11
	и куча фиксов от избавления фрагментации данных из-за паралельных записей логов в СуперМегаСекурную базу ;)
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	27. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от pavlinux (ok) on 19-Ноя-11, 01:17
	> и куча фиксов от избавления фрагментации данных из-за паралельных записей логов в > СуперМегаСекурную базу ;) Фрагментация решается методом линейного копирования данных в новую базу и удалением старой :)
	Ответить | Правка | ^ к родителю #24 | Наверх | Cообщить модератору

	308. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 12:50
	Фрагментация решается экстентной организацией хранения и правильными структурами метаданных, для которых фрагментация не принципиальна. В приличных БД такое есть бай дизайн.
	Ответить | Правка | ^ к родителю #27 | Наверх | Cообщить модератору

	347. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от pavlinux (ok) on 21-Ноя-11, 11:27
	> Фрагментация решается экстентной организацией хранения и правильными структурами > метаданных, для которых фрагментация не принципиальна. В приличных БД такое есть > бай дизайн. То есть операция передвига головки HDD, с 1001 сектора на 12123462433653, решается через бай дизайн и благодаря экстентной организацией, последующий сектор - всегда  соседний. :)
	Ответить | Правка | ^ к родителю #308 | Наверх | Cообщить модератору

	106. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:50
	> Можно я погенерю идей: Нельзя. Поттеринг не просто генерит идеи: он предоставляёт чёткое описание того, какие именно проблемы решают его идеи и реализацию его идей. Вот когда ты освоишь программирование хотя бы настолько, чтобы сделать PoC реализацию своего бреда - вот тогда тебя и будут слушать как Поттеринга. А пока ты просто очередной скучный тролль с баттхёртом.
	Ответить | Правка | ^ к родителю #17 | Наверх | Cообщить модератору

	186. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:24
	> Поттеринг не просто генерит идеи: он предоставляёт чёткое описание того, какие именно проблемы решают его идеи и реализацию его идей. Да да. А как же его слова что писать переносимый код это торможение Linux ? Сдается мне что у этого ламерка очень узкое понимание проблемы. Или вы о другой поделке под названием PulseAudio? Какие проблемы оно решало ? А вот проблему совместимости с OSS он не решил ?
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

	246. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от pavlinux (ok) on 19-Ноя-11, 21:43
	>> Можно я погенерю идей: > Нельзя. Поттеринг не просто генерит идеи: он предоставляёт чёткое описание того Ах да, забыл, извиняй, вам надо же мозг промывать. Желательно побольше слов, и желательно малознакомых. --- Предлагаю инициализировать массив энтропии генератора псевдослучайных чисел, в ядре операционной системы Linux, через витковый регистр сдвига с обобщённой отдачей. Что избавит от корреляция между последовательными значениями в выходной последовательности. Вы даже не представляете, как вы ставили под угрозу свои персАнальные данные, используя энтропию от шума устройств. Так как все детали компьютера являются дискретными устройствами, то и шум имеет не равномерное распределение. Только сейчас, купив в нашем магазине модуль ядра mersen.ko, ВСЕГО за 999.99$ вы почувствуете уверенность в завтрашнем дне, прилив сил и бодрости!!! CALL NOW: 8-800-MERSEN-HELP-ME
	Ответить | Правка | ^ к родителю #106 | Наверх | Cообщить модератору

20. "Разработчики systemd представили Journal, замену системе sys..."	+6 +/–
Сообщение от Шредер on 19-Ноя-11, 01:05
зачем нужен еще один велосипед?! очередная база ключ-значение с шифровкой данных, которую все равно можно будет обойти. Безопасность и учет? Никто не отменял real-time отправку логов на сторонний сервер, а там их сохранять/шифровать/анализировать как только захотят (с этим замечательно справляется сислог) только палки в колеса и лишняя нагружаемость сервера...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	34. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:30
	>Никто не отменял real-time отправку логов на сторонний сервер несекурно же и udp. в овносеточках теряются пакеты, а запилить отдельный менеджмент нет начальство денег на длинки не дает.
	Ответить | Правка | ^ к родителю #20 | Наверх | Cообщить модератору

	36. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от pavlinux (ok) on 19-Ноя-11, 01:36
	>>Никто не отменял real-time отправку логов на сторонний сервер > несекурно же и udp. в овносеточках теряются пакеты, а запилить отдельный менеджмент > нет начальство денег на длинки не дает. openvpn/stunnel
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

	39. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:46
	>>>Никто не отменял real-time отправку логов на сторонний сервер >> несекурно же и udp. в овносеточках теряются пакеты, а запилить отдельный менеджмент >> нет начальство денег на длинки не дает. > openvpn/stunnel чорт, забыл тег <sarcasm> проставить алсо совет с stunnel очень актуален для embedded os :)
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	46. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от pavlinux (ok) on 19-Ноя-11, 02:08
	>>>>Никто не отменял real-time отправку логов на сторонний сервер >>> несекурно же и udp. в овносеточках теряются пакеты, а запилить отдельный менеджмент >>> нет начальство денег на длинки не дает. >> openvpn/stunnel > чорт, забыл тег <sarcasm> проставить > алсо совет с stunnel очень актуален для embedded os :) Более всего для embedded насущна проблема, remote в частности, и syslog ваабще.
	Ответить | Правка | ^ к родителю #39 | Наверх | Cообщить модератору

	206. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:51
	> Более всего для embedded насущна проблема, remote в частности, и syslog ваабще. pwnage некоторых эмбеддед систем ведет к невкусным результатам.
	Ответить | Правка | ^ к родителю #46 | Наверх | Cообщить модератору

	42. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:57
	rsyslog
	Ответить | Правка | ^ к родителю #36 | Наверх | Cообщить модератору

	360. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Xaionaro (ok) on 21-Ноя-11, 14:58
	ipsec?
	Ответить | Правка | ^ к родителю #34 | Наверх | Cообщить модератору

28. "Разработчики systemd представили Journal, замену системе sys..."	–5 +/–
Сообщение от prokoudine (??) on 19-Ноя-11, 01:22
В мире не производится столько попкорна, сколько понадобится при чтении комментов к этой новости. Леннарт — молодец. Безотносительно.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	123. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 10:58
	Молодец был бы, если б продумывал и делал внимательно и не забивая на критику по существу.
	Ответить | Правка | ^ к родителю #28 | Наверх | Cообщить модератору

	124. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от develop7 (ok) on 19-Ноя-11, 11:05
	> Молодец был бы, если б продумывал и делал внимательно и не забивая на критику по существу. > критику по существу Судя по комментам, с этим проблема. Кстати, у вас есть ссылок с примерами забивания?
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	176. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от prokoudine (??) on 19-Ноя-11, 15:01
	Ну да, Шигорина не спросил. Трагедия в двух актах.
	Ответить | Правка | ^ к родителю #123 | Наверх | Cообщить модератору

	180. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Michael Shigorin (ok) on 19-Ноя-11, 15:18
	> Ну да, Шигорина не спросил. Трагедия в двух актах. Саш, не только я не вижу ответа на http://lwn.net/Articles/431215/ -- понятно, что скорее всего тогда Леннарта почтой захлестнуло с головой, но это тоже было предсказуемо.
	Ответить | Правка | ^ к родителю #176 | Наверх | Cообщить модератору

	299. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от prokoudine (??) on 20-Ноя-11, 07:32
	> Саш, не только я не вижу ответа на http://lwn.net/Articles/431215/ Леннат Пёттеринг не ответил на LWN. Интриги, скандалы, расследования!
	Ответить | Правка | ^ к родителю #180 | Наверх | Cообщить модератору

29. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 01:23
а вообще сиволично, конечно. особенно в свете летних предложений Петтеринга сделать systemd зависимостью для гнома. да, давайте. А убунту пусть апстарт пилят, и вместо сислога тож что-нить свое придумают. А суся на моно гипервайзор запилит, чтоб совсем уж зоопарк развести. не жизнь, а малина.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	71. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Клыкастый (ok) on 19-Ноя-11, 04:06
	> свое придумают. А суся на моно гипервайзор запилит, (сожрал половину клавиатуры) это, ты ж такие вещи не говори... эти - МОГУТ. и всенепременно на MONO.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	208. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:54
	> это, ты ж такие вещи не говори... эти - МОГУТ. и всенепременно на MONO. А убунтуйцы видя все это вспомнят про свой ПГМ (питон головного мозга) и напишут на нем. Так что можете доедать оставшееся :D.
	Ответить | Правка | ^ к родителю #71 | Наверх | Cообщить модератору

	169. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 14:17
	> а вообще сиволично, конечно. особенно в свете летних предложений Петтеринга сделать systemd > зависимостью для гнома. пруфлинк или не было.
	Ответить | Правка | ^ к родителю #29 | Наверх | Cообщить модератору

	177. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 15:05
	>> а вообще сиволично, конечно. особенно в свете летних предложений Петтеринга сделать systemd >> зависимостью для гнома. > пруфлинк или не было. гугль подаст. де-то в гномовской рассылке было.
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

	179. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 15:08
	>> а вообще сиволично, конечно. особенно в свете летних предложений Петтеринга сделать systemd >> зависимостью для гнома. > пруфлинк или не было. https://mail.gnome.org/archives/desktop-devel-list/2011-May/...
	Ответить | Правка | ^ к родителю #169 | Наверх | Cообщить модератору

31. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 01:26
Блин, кто этому велосипедисту мешает взять rsyslog и сохранять логи хоть в Оракел, если жопа просит энтерпрайза? Если совсем невмоготу, напиши свой бэкенд и сохраняй свои логи хоть хоть на перфоленту в незгораемом шкафу. Нет жеж, блин, надо всё сломать и сделать по-другому. Ему 17 лет, что ли?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	45. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от eve on 19-Ноя-11, 02:05
	> БЕму 17 лет, что ли? Чуток больше. Некоторые люди и в зрелом возрасте сохраняют разум подростка.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	96. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:33
	> Блин, кто этому велосипедисту мешает взять rsyslog и сохранять логи хоть в > Оракел, если жопа просит энтерпрайза? В тексте новости подробно написано, что именно мешает.
	Ответить | Правка | ^ к родителю #31 | Наверх | Cообщить модератору

	188. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:27
	>> Блин, кто этому велосипедисту мешает взять rsyslog и сохранять логи хоть в >> Оракел, если жопа просит энтерпрайза? > В тексте новости подробно написано, что именно мешает. в новости написано что мальчик не читал man rsyslog и не смотрел как к нему дописываются бэкенды и фронтэнды - ну да, это же не его разработка - зачем ему читать какие-то маны ?
	Ответить | Правка | ^ к родителю #96 | Наверх | Cообщить модератору

	283. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:45
	> в новости написано что мальчик не читал man rsyslog и не смотрел как к нему дописываются бэкенды и фронтэнды Из текста вашего комментария заметно, что прочитать новость вы так и не удосужились. А еще рассуждаете, кто какой ман читал.
	Ответить | Правка | ^ к родителю #188 | Наверх | Cообщить модератору

35. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 01:34
Леннарт Поттеринг - какой-то диверсант и засланый казачок. Он постепенно делает из замечательной, простой и понятной системы какой-то велосипед с ярко выраженными квадратными колесами.Боженька, об одном прошу,только бы мейнтейнерам дебиана тоже вдруг не пришло в голову воплотить и эту его новацию.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	126. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 19-Ноя-11, 11:24
	> Боженька, об одном прошу,только бы мейнтейнерам дебиана тоже вдруг не пришло > в голову воплотить и эту его новацию. Ну так /run там уже появился и systemd присутствует. Скоро всё свалят в /usr/bin, ибо LSB
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	343. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 07:56
	>> Боженька, об одном прошу,только бы мейнтейнерам дебиана тоже вдруг не пришло >> в голову воплотить и эту его новацию. > Ну так /run там уже появился и systemd присутствует. Скоро всё свалят > в /usr/bin, ибо LSB Хуже того, это уже сочится всюду. Udev, к примеру: файл NEWS: >[оверквотинг удален] > Udev logs a warning now if /run is not writable at udevd > startup. It will still fall back to /dev/.udev, but this is > now considered a bug. > > now considered a bug. > now considered a bug. > now considered a bug. > > udev 167 > The udev runtime data moved from /dev/.udev/ to /run/udev/. И действительно, при загрузке udev сматерился о том, что каталога /run не существует, и он будет использовать /dev/.udev. Сегодня udev зависит от /run, завтра - от systemd.
	Ответить | Правка | ^ к родителю #126 | Наверх | Cообщить модератору

	344. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 07:58
	>[оверквотинг удален] >> >> now considered a bug. >> now considered a bug. >> now considered a bug. >> >> udev 167 >> The udev runtime data moved from /dev/.udev/ to /run/udev/. > И действительно, при загрузке udev сматерился о том, что каталога /run не > существует, и он будет использовать /dev/.udev. > Сегодня udev зависит от /run, завтра - от systemd. Хотя я в этом не уверен. Завтра скорее всего Поттеринг выкатит реализацию udev, встроенную в systemd, а этот объявит как устаревший.
	Ответить | Правка | ^ к родителю #343 | Наверх | Cообщить модератору

	229. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 19:00
	> Леннарт Поттеринг - какой-то диверсант и засланый казачок. Он постепенно делает из > замечательной, простой и понятной системы какой-то велосипед с ярко выраженными квадратными > колесами.Боженька, об одном прошу,только бы мейнтейнерам дебиана тоже вдруг не пришло > в голову воплотить и эту его новацию. Объявят стандартом - и все сделают, потому что не захотят огрести несовместимостей. Форкайте FHS 2.3, блин. А ещё лучше - старые версии LFS, на всякий случай.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	284. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 01:47
	> Леннарт Поттеринг - какой-то диверсант и засланый казачок. ... задумчиво заметил виндофан, зашедший потроллить юниксоидов на их форуме.
	Ответить | Правка | ^ к родителю #35 | Наверх | Cообщить модератору

	337. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 05:30
	> ... задумчиво заметил виндофан, зашедший потроллить юниксоидов на их форуме. Даже если у вас паранойя это еще не значит что они за вами не следят.
	Ответить | Правка | ^ к родителю #284 | Наверх | Cообщить модератору

38. "Разработчики systemd представили Journal, замену системе sys..."	–5 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 01:45
Мда....некоторые люди меня просто поражают.Вы понимаете что вы хотите НЕВОЗМОЖНОГО  !Вы хотите современную, защищенную, поддерживающую все новые технологии, и при этом что бы она бала элегантна,проста и понятная,ДА НЕВОЗМОЖНО ЭТО!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	43. "Разработчики systemd представили Journal, замену системе sys..."	+3 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 01:59
	> Мда....некоторые люди меня просто поражают.Вы понимаете что вы хотите НЕВОЗМОЖНОГО  !Вы > хотите современную, защищенную, поддерживающую все новые технологии, и при этом что > бы она бала элегантна,проста и понятная,ДА НЕВОЗМОЖНО ЭТО! Cтранно, почему же она тогда работает и известна как GNU/Linux?
	Ответить | Правка | ^ к родителю #38 | Наверх | Cообщить модератору

	48. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 02:17
	Ну что же хорошо,раз вы такой образованный,тогда сравните сегодняшний Linux с действительно простой и элегантной системой UNIX,вот она действительно проста и понятна, а Linux уже давно не прост и элегантен,особенно в ядре.
	Ответить | Правка | ^ к родителю #43 | Наверх | Cообщить модератору

	72. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Клыкастый (ok) on 19-Ноя-11, 04:09
	> Ну что же хорошо,раз вы такой образованный,тогда сравните сегодняшний Linux с действительно > простой и элегантной системой UNIX,вот она действительно проста и понятна Например System V в которой просто и понятно был открыт chargen порт. Было так забавно телнет к ней и по конвейру на вход телнета на NT, порт 139.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

	209. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:56
	> Linux уже давно не прост и элегантен,особенно в ядре. Действительно, или академподелка, которая в современном мире никому не нужна, или достаточно навороченный агрегат. Никто не виноват что нынче один только спек на видеокарту занимает 900 страниц.
	Ответить | Правка | ^ к родителю #48 | Наверх | Cообщить модератору

69. "Разработчики systemd представили Journal, замену системе sys..."	+7 +/–
Сообщение от solardiz (ok) on 19-Ноя-11, 04:03
> Ключевой особенностью Journal является использование криптографических средств для гарантирования неизменности и целостности накопленных логов. Это было реализовано в ssyslogd от CORE-SDI в конце 90-х, позже дополненным работой с базами данных и названным msyslog: http://oss.coresecurity.com/projects/msyslog.html Оказалось слабо востребовано. > Данные сообщений не аутентифицированы. Например, любой локальный процесс может указать что он Apache с PID 4321, а syslog поверит этому и сохранит сведения в лог Да. Исправлено в Owl небольшим патчем к sysklogd: http://cvsweb.openwall.com/cgi/cvsweb.cgi/Owl/packages/sysklogd/ (см. sysklogd-1.4.2-owl-syslogd-unixcred.diff). Передача по TCP и другие улучшения по одному и в разных сочетаниях также реализованы в разных альтернативных syslogd'ах. В целом, идея переписать syslogd - здравая - хотя сделать это хорошо не просто, да и что такое хорошо - спорно. Вероятно, если это будет сделано в Fedora, оно приживется, несмотря на то что отдельно это была бы лишь еще одна слабо востребованная альтернатива со своими недостатками.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

70. "Разработчики systemd представили Journal, замену системе syslog"	+1 +/–
Сообщение от emg81 (ok) on 19-Ноя-11, 04:05
в любом случае, я вот не понимаю: сейчас /var/log/ даже не везде читать можно (я вот в генте пользователем дефолтно логи не могу увидеть), уж молчу про изменения файлов там. писать можно с правами рута. так если у злоумышленника ЕСТЬ (получены в результате взлома) права рута, что мешает вынести любой Journal за скобки - тупо остановить сервис и снести все фрагменты логов - пусть админ гадает, взлом или нет?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	95. "Разработчики systemd представили Journal, замену системе syslog"	–2 +/–
	Сообщение от anonymous (??) on 19-Ноя-11, 08:33
	> что мешает вынести любой Journal за скобки - тупо остановить сервис и снести все фрагменты логов - пусть админ гадает, взлом или нет? Сказано, что ведь, что эта хрень будет частью systemd. А systemd играет роль init, его не "остановить".
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	143. "Разработчики systemd представили Journal, замену системе syslog"	+/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 12:53
	> Сказано, что ведь, что эта хрень будет частью systemd. А systemd играет > роль init, его не "остановить". нда? я не знал, если честно, что есть сервисы, которые "не остановить". я правильно понял, что имеется в виду, что если раньше процесс с PID=1 был init, то теперь systemd? и что в этот самый процесс будет включена "эта хрень", как Вы говорите?
	Ответить | Правка | ^ к родителю #95 | Наверх | Cообщить модератору

	420. "Разработчики systemd представили Journal, замену системе syslog"	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 20:24
	> я не знал, если честно, что есть сервисы, которые "не остановить". А ты покиль инит? Тебе понравится результат его остановки, я гарантирую это ;)
	Ответить | Правка | ^ к родителю #143 | Наверх | Cообщить модератору

	101. "Разработчики systemd представили Journal, замену системе syslog"	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 08:43
	> так если у злоумышленника ЕСТЬ (получены в результате взлома) права рута, что > мешает вынести любой Journal за скобки - тупо остановить сервис и > снести все фрагменты логов - пусть админ гадает, взлом или нет? У тебя резко пропали нах все логи и ты будешь гадать взлом это или нет?!! Криптозащита позволяет недопустить ИЗМЕНЕНИЯ логов.
	Ответить | Правка | ^ к родителю #70 | Наверх | Cообщить модератору

	113. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от tmx on 19-Ноя-11, 09:58
	значит любой присосавшийся к опенсоурсу кретин будет похабить и так недоделанную до ума систему? а тысячи слабоумных хомячков будут радостно прыгать и визжать от восторга и кричать "ещё! ещё! ещё!". что-бы понять что это вредительство - стоит только посмотреть на пульсаудио.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

	421. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 23-Ноя-11, 20:27
	> что-бы понять что это вредительство - стоит только посмотреть на пульсаудио. А по-моему, надо бы понять что в этом мире вам никто ничег не должен и поэтому будет делать то что хочется ему, а не вам. Если вы считаете что должно быть иначе, что можно лучше и почему-то никто не сделал так - вот вы и делайте.
	Ответить | Правка | ^ к родителю #113 | Наверх | Cообщить модератору

	154. "Разработчики systemd представили Journal, замену системе syslog"	+/–
	Сообщение от emg81 (ok) on 19-Ноя-11, 13:23
	> У тебя резко пропали нах все логи и ты будешь гадать взлом > это или нет?!! Первое, что придёт в голову, что чудо-новинка отвалилась. По моей вине или не совсем. Ну а зачем кому-то ломать мой локалхост? об этом думать тоже надо, но не в первую очередь. > Криптозащита позволяет недопустить ИЗМЕНЕНИЯ логов. ну, если ключ где-то по сети далеко лежит на невзломанной машине, то, наверное. а когда усё локально доступно руту - то не думаю, что это будет невозможно.
	Ответить | Правка | ^ к родителю #101 | Наверх | Cообщить модератору

110. "Разработчики systemd представили Journal, замену системе sys..."	+9 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 09:24
Объясните мне скорбному, как криптография может защитить от подделки логов на локальной машине? В рабочей системе, очевидно, имеется всё необходимое и достаточное для создания записей в логах, ведь как-то эти логи ведутся. А цепочки хэшей лишь гарантируют, что нельзя изменить стараю запись, не затронув более новые записи. Но ничто не мешает злоумышленнику стереть N последних записей и заменить их своими. Как и в git, собственно, можно изменить любую ревизию, изменив все последуюдие. В случае гита спасает то, что у всех есть актуальные копии репозитория, и можно убедиться, что хэш последней ревизии правильный. А в случае службы логов на изолированной машине этот последний хэш хранится где-то на этой же машине. Ваш msyslog примерно так и делает - хранит хэш лога в отдельном файле, по умолчанию /var/ssyslog/.var.log.messages.key. Исключительно в надежде на то, что злоумышленник об этом хэше не знает и не догадается его подделать. В общем, мы приходим к выводу, что единственный доступный способ защиты логов от подделки - хранить контрольный хэш на удалённой машине. А далее приходим к выводу, что один контрольный хэш не спасает от полного уничтожения логов, то есть, лучше на удалённой машине хранить весь лог целиком. Как, собственно, и делается давным-давно. Поздравляем тов. Поттеринга с очередным газопусканием в лужу и желаем ему дальнейших творческих успехов.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	111. "Разработчики systemd представили Journal, замену системе sys..."	–4 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 09:43
	> Объясните мне скорбному, как криптография может защитить от подделки логов на локальной > машине? Да. > В рабочей системе, очевидно, имеется всё необходимое и достаточное для > создания записей в логах, ведь как-то эти логи ведутся. Да. > А цепочки > хэшей лишь гарантируют, что нельзя изменить стараю запись, не затронув более > новые записи. Нет. > Но ничто не мешает злоумышленнику стереть N последних записей > и заменить их своими. Вполне можно сделать так, что изменение N предыдущих записей влияет на параметры защищённого заголовка файла к примеру. Хотя во внутренней архитектуре Journal ещё не разбирался, так что как именно это реализовано Поттерингом не знаю. > Как и в git, собственно, можно изменить > любую ревизию, изменив все последуюдие. В git не ставилась задача неизменности истории ревизий. > А в случае службы логов на изолированной машине > этот последний хэш хранится где-то на этой же машине. Совершенно не факт, что этого будет достаточно для изменения всех записей в логи начиная с произвольного места. > В общем, мы приходим к выводу, что единственный доступный способ защиты логов > от подделки - хранить контрольный хэш на удалённой машине. А мы приходим к выводу, что рассуждения о безопасности архитектуры Journal без её изучения и без знания основ криптографии - бессмысленны. > А далее > приходим к выводу, что один контрольный хэш не спасает от полного > уничтожения логов, то есть, лучше на удалённой машине хранить весь лог > целиком. А далее приходим к выводу, что рассуждения о новости без её вдумчивого чтения это лёгкий способ выставить себя идиотом: journal не ставит задачу защиты логов от уничтожения - только от их модификации. Поздравляем тов. Анонима с очередным газопусканием в лужу и желаем ему дальнейших творческих успехов.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	134. "Разработчики systemd представили Journal, замену системе sys..."	+4 +/–
	Сообщение от Макс (??) on 19-Ноя-11, 12:34
	Хм. Если мы владеем рутом (и следовательно ядром), что мешает нам подцепиться к Journal или вытащить оттуда ключ, и воссоздать зашифрованный лог без компрометирующих нас записей? Я все еще не понимаю. Как-никак, вся история малвари и DRM на венде говорит о том, что локальной машине доверять нельзя, должен быть проверенный контрагент. Насколько я понимаю, как бы оно ни было реализовано, существует только один принципиальный способ это сделать - security through obscurity, со всеми вытекающими.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	146. "Разработчики systemd представили Journal, замену системе sys..."	–2 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 13:00
	> Я все еще не понимаю. > Насколько я понимаю, как бы оно ни было реализовано, существует только один > принципиальный способ это сделать - security through obscurity, со всеми вытекающими. Первое утверждение правильное: ты всё ещё не понимаешь. Более того - без изучения основ криптографии - вряд-ли поймёшь. Начать можешь с википедии, дальше - Applied Cryptography Шнайера. Где-то через месяц понимание придёт. При усердии - уже через неделю.
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	162. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от XPEH on 19-Ноя-11, 13:47
	Ну вы сокровенным знанием-то поделитесь с общественностью, не держите все в себе.
	Ответить | Правка | ^ к родителю #146 | Наверх | Cообщить модератору

	309. "Разработчики systemd представили Journal, замену системе sys..."	–4 +/–
	Сообщение от Аноним (??) on 20-Ноя-11, 12:58
	> Ну вы сокровенным знанием-то поделитесь с общественностью, не держите все в себе. Болван, никто не будет тебе пересказывать тут на пальцах содержание некислого труда, сдобренного адовой математикой. В университете учат. И обычно за бабло немаленькое. Так что сам, сам. Английский подучишь заодно. Продвинешься. И будешь сам ходить босиком по стране и задаром учить недоумков.
	Ответить | Правка | ^ к родителю #162 | Наверх | Cообщить модератору

	211. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:58
	> Хм. Если мы владеем рутом (и следовательно ядром), что мешает нам подцепиться > к Journal или вытащить оттуда ключ, А он там обязан быть? А что если начальный хеш убрали из системы?
	Ответить | Правка | ^ к родителю #134 | Наверх | Cообщить модератору

	213. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 17:01
	Но нам же нужен этот хэш для верификации лога. В таком случае верифицировать логи придется на удаленной системе (не будем же мы его компрометировать на локальной?), что делает все такое шифрование бессмысленным, ибо и так придется логи трансферить на удаленный сервер. Проще уж сразу логить на удаленную систему, как и делается сейчас - какой смысл огород городить?
	Ответить | Правка | ^ к родителю #211 | Наверх | Cообщить модератору

	414. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 16:22
	> так придется логи трансферить на удаленный сервер. Зачем? Можно загрузить например локальный сервер с доверяемого ливцд/флехи в оффлайн режиме и произвести разбор полетов, проверив в том числе и достоверность лога. Это не требует отдельной машины. А вот отдельный сервер имеет недостаток: он баблосов стоит, бэть.
	Ответить | Правка | ^ к родителю #213 | Наверх | Cообщить модератору

	136. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 12:39
	Объясните, что такого надо особенного знать про криптографию? Вот есть приватный ключ, им подписывается лог. Так ведь он находится на уже скомпрометированной системе. Неизвестно, может быть злоумышленник его давно вытащил и переписал логи, подписавшись им. Как иначе можно сделать систему без дополняющего контрольного сервера? А я вам даже скажу - никак. Это невозможно. Так что - > Поздравляем тов. Анонима с очередным газопусканием в лужу и желаем ему дальнейших творческих успехов.
	Ответить | Правка | ^ к родителю #111 | Наверх | Cообщить модератору

	149. "Разработчики systemd представили Journal, замену системе sys..."	–1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 13:04
	> Объясните, что такого надо особенного знать про криптографию? Для начала - систмы с открытым ключом, особенности использования как открытого, так и закрытого ключей. Потом - различные криптопротоколы. Потом - вдумчивое чтение книги Шнайера. > Вот есть приватный ключ, > им подписывается лог. Так ведь он находится на уже скомпрометированной системе. > Неизвестно, может быть злоумышленник его давно вытащил и переписал логи, подписавшись > им. И самое главное - прежде чем рассуждать о безопасности системы - изучить её внутреннюю архитектуру. Начать можно с высокоуровневого описания, затем - поглядеть в исходный код - благо всё доступно. > Как иначе можно сделать систему без дополняющего контрольного сервера? А я вам > даже скажу - никак. До тех пор, пока ты не выполнишь предыдущие пункты - всё, что ты скажешь не имеет ни малейшего смысла.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	408. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonimous on 23-Ноя-11, 08:44
	>> Как иначе можно сделать систему без дополняющего контрольного сервера? А я вам >> даже скажу - никак. > До тех пор, пока ты не выполнишь предыдущие пункты - всё, что > ты скажешь не имеет ни малейшего смысла. В 'предложении' Поттеринга всё должно быть локально доступно --- и для шифрования и для дешифровки. Т.е. при компрометации системы --- всё есть для того, чтобы оставить для изучения fake records.
	Ответить | Правка | ^ к родителю #149 | Наверх | Cообщить модератору

	415. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 16:23
	> В 'предложении' Поттеринга всё должно быть локально доступно --- и для шифрования > и для дешифровки. Он предлагал цепочку хешей. Начальный не обязан быть доступен на локалной системе.
	Ответить | Правка | ^ к родителю #408 | Наверх | Cообщить модератору

	433. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 24-Ноя-11, 11:56
	>> В 'предложении' Поттеринга всё должно быть локально доступно --- и для шифрования >> и для дешифровки. > > Он предлагал цепочку хешей. Начальный не обязан быть доступен на локалной системе. Как бы да, но... либо можно переписать n хвостовых участков (т.е. тех, для которых есть оба ключа), либо нужно депонировать цепочку закрытых ключей на стороне (и тогда решение с remote log-сервером выглядит более адекватным). Ну, и частота смены ключа. Чем реже его менять, тем больше времени для маскировки атаки (хвост-то можно подменить); если чаще --- то remote log-сервер становится предпочтительней. Получается, что для отдельностоящей машины --- решение Поттеринга бессмыссленно. Для машины в составе 'структуры' --- тоже бессмыссленно.
	Ответить | Правка | ^ к родителю #415 | Наверх | Cообщить модератору

	212. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 16:59
	> Неизвестно, может быть злоумышленник его давно вытащил и переписал логи, подписавшись им. Вообще-то вполне можно так сделать что вытаскивать будет нечего.
	Ответить | Правка | ^ к родителю #136 | Наверх | Cообщить модератору

	114. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от tmx on 19-Ноя-11, 09:59
	>Но ничто не мешает злоумышленнику стереть N последних записей и заменить их своими. вот именно.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	164. "Разработчики systemd представили Journal, замену системе sys..."	+2 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 14:12
	Ок, до меня дошло, как оно работает. Мы выбираем некий ключ и записываем его в файл, а также сохраняем где-нибудь в сейфе. При каждом записи в лог считается хэш от (текущий ключ + текущая запись), и полученное значение записывается вместо старого ключа. Для проверки валидности лога мы достаём из сейфа первоначальный ключ и ещё раз проделываем эти операции, последовательно вычисляя хэш от каждой записи и текущего ключа, полученное значение должно совпадать с текущим хэшем на проверяемой системе. При этом удалить записи из лога, подделав хэш, невоможно, т. к. первоначального ключа злоумышленник не знает, и старые значения хэша нигде не сохраняются. Но тогда возникает проблема, например, с ротацией логов. Каждый раз, когда удаляются старые записи, старый ключ перестанет работать, и нужно опять новый ключ сохранять в беопасном месте. Право, лучше уж удалённый лог-сервер.
	Ответить | Правка | ^ к родителю #110 | Наверх | Cообщить модератору

	172. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Аноним (??) on 19-Ноя-11, 14:22
	Более того - при попытке открыть "сейф" на скомпрометированной машине он тоже становится скомпрометированным, так что это надо делать на посторонней машине.
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	235. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от spf (??) on 19-Ноя-11, 20:28
	> и старые значения хэша нигде не сохраняются. А как просмотреть лог с начала и убедиться в корректности данных? Без первоначального ключа невозможно. Каждый раз для viewlog доставать из сейфа?
	Ответить | Правка | ^ к родителю #164 | Наверх | Cообщить модератору

	259. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 00:31
	Лог не зашифрован же, ключ нужен только для проверки целостности
	Ответить | Правка | ^ к родителю #235 | Наверх | Cообщить модератору

	289. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 02:27
	Так а где его проверять-то? На локальной машине? А если там руткит сидит и заставляет проверку завершаться всегда успешно? А если его отдавать на другую машину - чем это отличается от обычного удаленного журналирования?
	Ответить | Правка | ^ к родителю #259 | Наверх | Cообщить модератору

175. "Разработчики systemd представили Journal, замену системе sys..."	+6 +/–
Сообщение от Сочувствующий on 19-Ноя-11, 14:52
> Как правило, первым делом после взлома злоумышленники пытаются замести следы и > вычистить из системных логов записи, выдающие их активность. Используемые в > настоящее время реализации службы syslog беспомощны перед такими действиями. Сомнительное утверждение. Банальная строчка '*.* @some-observer-host' в /etc/*syslog.conf сводит смысл удаления локальных логов на нет. А по теме хочу сказать, что ИМХО идея "комбайнов" никогда ещё до добра не доводила. Уж в области безопасности-то точно, так как проконтролировать несколько связанных между собой несложных и относительно прозрачных подсистем (например, банальный *NIX-овый конвеер) куда проще, чем одну громадную, сложную и "неделимую" систему. Ту же целостность log-записей можно реализовать несложным bash-скриптом, используя, например, gpg. Но да, конечно, этому же учиться ещё надо, а тут всё готовенькое, на тарелочке с золотой коёмочкой. ;)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	178. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 15:06
	> ИМХО идея "комбайнов" никогда ещё до добра не доводила. nginx? Хотя таки да, я понимаю, что это скорее исключение, подтверждающее правило.
	Ответить | Правка | ^ к родителю #175 | Наверх | Cообщить модератору

	183. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Сочувствующий on 19-Ноя-11, 15:55
	> nginx? Хотя таки да, я понимаю, что это скорее исключение, подтверждающее правило. По сравнению c lighttpd или с apache? :) Вопрос: зачем превращать systemd в ОС?
	Ответить | Правка | ^ к родителю #178 | Наверх | Cообщить модератору

	214. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 19-Ноя-11, 17:04
	Ну nginx - это вебсервер и почтовый прокси. То есть комбайн. Причем большинство использует его как веб- (или вообще как веб-кэш). Таки апач имеет одну функцию.
	Ответить | Правка | ^ к родителю #183 | Наверх | Cообщить модератору

	217. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Сочувствующий on 19-Ноя-11, 17:23
	> Ну nginx - это вебсервер и почтовый прокси. Пардон. Не знал о этих его способностях, спасибо. В любом случае, до systemd ему, как до звёзд. :) В общем, как корабль назовёшь, так он и поплывёт. Надеюсь, Lennart Poettering покажет себя как достойный системщик...
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	232. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от ПолныйАнонимус on 19-Ноя-11, 19:50
	> Таки апач имеет одну функцию. Это которую - быть веб-сервером? а mod_proxy превращает его в прокси. а ведь если вспомнить про всякие обвязки к python, php, perl и т.д. - то и до сервера приложений не далеко (упрощенно конечно)
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

	416. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 23-Ноя-11, 16:27
	> Ну nginx - это вебсервер и почтовый прокси. То есть комбайн. Там можно выбрать какие модули вам надо а какие нет. > Причем большинство использует его как веб- (или вообще как веб-кэш). Таки апач > имеет одну функцию. При том выполняет ее хуже нжинкса как правило, особенно при отдаче статики. Замена апача на нжинкс на статике просто видна невооруженным глазом. Статика начинает выстреливаться как из пушки.
	Ответить | Правка | ^ к родителю #214 | Наверх | Cообщить модератору

185. "Разработчики systemd представили Journal, замену системе sys..."	+/–
Сообщение от Аноним (??) on 19-Ноя-11, 16:15
Вы ничего не понимаете. Леннарт Поттер в РедХат это тоже самое что Стив Джобс, просто пока не все это еще поняли. http://www.youtube.com/watch?v=Rgd3WeWG7sY
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	191. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
	Сообщение от Сочувствующий on 19-Ноя-11, 16:29
	> Леннарт Поттер в РедХат это тоже самое что Стив Джобс, просто пока не все это еще поняли. То бишь он там за начальника у них, чтоли? Да, в амбициях ему не занимать, это точно.
	Ответить | Правка | ^ к родителю #185 | Наверх | Cообщить модератору

	245. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 19-Ноя-11, 21:41
	>То бишь он там за начальника у них, чтоли? Так это очевидно. Его проекты практически моментально попадают в апстрим. И решения принимает только он.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

	249. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Vladjmir (ok) on 19-Ноя-11, 23:33
	> То бишь он там за начальника у них, чтоли? Наверное, он у них идеолог. Он человек из поколения, которое выбрало пепси. Эти ребята без принципов и идут напролом, не стесняются ломать старое, а на критику им наплевать.
	Ответить | Правка | ^ к родителю #191 | Наверх | Cообщить модератору

227. "Разработчики systemd представили Journal, замену системе syslog"	+1 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 18:36
Ждём завтра вишлиста от Поттеринга: запретить любой доступ к логам всем исключая PID=1. Во веселья будет-то.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	304. "Разработчики systemd представили Journal, замену системе syslog"	–1 +/–
	Сообщение от anonymous (??) on 20-Ноя-11, 11:52
	> Ждём завтра вишлиста от Поттеринга: запретить любой доступ к логам всем исключая > PID=1. Во веселья будет-то. Вполне логичный следующий шаг.
	Ответить | Правка | ^ к родителю #227 | Наверх | Cообщить модератору

	316. "Разработчики systemd представили Journal, замену системе syslog"	+/–
	Сообщение от Аноним (??) on 20-Ноя-11, 15:19
	>> Ждём завтра вишлиста от Поттеринга: запретить любой доступ к логам всем исключая >> PID=1. Во веселья будет-то. > Вполне логичный следующий шаг. Логичный конечно, но пусть в своей федоре это делает.
	Ответить | Правка | ^ к родителю #304 | Наверх | Cообщить модератору

234. "Разработчики systemd представили Journal, замену системе syslog"	+2 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 20:22
У проекта есть несколько слабых мест, которые сводят всю идею на нет. Предложенная схема использования контрольных сумм гарантирует неизменность записей, но бессильна от вырезания хвоста лога. Атакующий может почистить хвост лога с момента начала атаки и восстановить заново, исключив следы своего присутствия. Все будет логически верно, все хэши сойдутся. Выход только в постоянном копировании слепков хэшей на недоступный для чтение носитель, например, отправляя куда-то по сети. Но это уже не то, с тем же успехом можно контрольные суммы частей текстового лога отправлять. Второе: бинарный формат слишком усложняет всю схему. От логов не требуется структурирования, для этого есть СУБД и специализированные логи (например, лог Apache и postfix имеет жесткую структуру для которой испокон веков есть парсеры). Лог должен быть предельно простым и наглядным. Средства анализа и ведения базы событий - это уже другая тема и для неё должны создаваться отдельные надстройки. В случае kernel.org админ бегло взглянул на лог и аномалия бросилась в глаза, в Journal он бы погряз в обилии информации и её структурирование только бы помешало. Аутентифицированность отправителя тоже миф - имея root, по прежнему можно притвориться кем угодно. Про необходимость индексации и быстроты просмотра ерунда, лог просматривается не так часто, чтобы обращать на это внимание. Но достойных внимания идей в той статье много, есть над чем задуматься. Сохранив изначально текстовый формат логов, но дополнив его индексами, возможностью привязки к записям дополнительных метаданных и другими вкусными вещами про которые говориться в статье, может получиться интересный проект.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

236. "Разработчики systemd представили Journal, замену системе syslog"	+1 +/–
Сообщение от Аноним (??) on 19-Ноя-11, 20:28
>Inspired by git, in the journal all entries are cryptographically hashed along with the hash of the previous entry in the file. This results in a chain of entries, where each entry authenticates all previous ones. If the top-most hash is regularly saved to a secure write-only location, the full chain is authenticated by it. Manipulations by the attacker can hence easily be detected. Огогого! Вот это мегакасталь! :D Т.е. хаксор легко может потереть журнал после последнего сохранения хеша. Следовательно, сохранять надо часто. Итого, имеем запись журнала по сети, вид сбоку.
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

243. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
Сообщение от анон on 19-Ноя-11, 21:35
Охлол, Поттеринг изобрел EventLog! Когда же появится autorun.inf, desktop.ini и mmc?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	250. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от neindog on 19-Ноя-11, 23:35
	как будто это что-то плохое
	Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

	300. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от prokoudine (??) on 20-Ноя-11, 07:35
	> Охлол, Поттеринг изобрел EventLog! Когда же появится autorun.inf, desktop.ini и mmc? У GConf давным-давно есть бэкенд для записи конфигов в формат, схожий с ini. Просто им не пользуются. А ещё есть система конфигов Elektra, которая примерно такой же формат юзает. ну же, давай, начинай священную войну :)
	Ответить | Правка | ^ к родителю #243 | Наверх | Cообщить модератору

	303. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от anonymous (??) on 20-Ноя-11, 11:49
	>У GConf давным-давно есть бэкенд для записи конфигов в формат, схожий с ini. Точнее был. gconf давно заменён на dconf
	Ответить | Правка | ^ к родителю #300 | Наверх | Cообщить модератору

	307. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от prokoudine (??) on 20-Ноя-11, 12:46
	Любопытный образец логики. В софте A есть фича М. Софт А заменили на софт Б. От этого, конечно, фича М в софте А пропадает. Наверное, она обиделась, встала и ушла.
	Ответить | Правка | ^ к родителю #303 | Наверх | Cообщить модератору

248. "Разработчики systemd представили Journal, замену системе sys..."	+/–
Сообщение от Vladjmir (ok) on 19-Ноя-11, 23:28
Если проблема целостности логов является ключевой, то не легче ли их просто архивировать на другую машину и там же сравнивать текущую копию с предыдущей? Данная задача наиболее актуальна для сервера, а есть ли смысл городить огород на рабочей станции?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

297. "Разработчики systemd представили Journal, замену системе sys..."	+/–
Сообщение от vi on 20-Ноя-11, 04:28
Давайте переименуем зголовок статьи в: "Некий дистрибьютер хочет это и то, что бы получить вот это". Оно самое "вот это", самое интересное!
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

315. "Разработчики systemd представили Journal, замену системе sys..."	+1 +/–
Сообщение от myhand on 20-Ноя-11, 14:02
Забавен список "основных проблем syslog".  Автор явно не сделал д/з, так и не узнав про rsyslogd, syslog-ng, dsyslog и проч. Чукча таки хронический "песатель".  Если поднапрячься и узнать про то, что уже давно сделали другие - в списке "проблем", наверное, останется лишь отсуствие логгирования бинарных данных.  Штука спорная, мягко говоря. За вумную "защиту от ddos" - вообще убить мало.  От собственных поделий защита, наверно: -->8--- Nov 19 18:03:29 censored pulseaudio[6126]: ratelimit.c: 6 events suppressed -->8--- Про "контроль целостности", который _в принципе_ не гарантирует от подделки - уже писали. Неужели это попадет в RH?  Куда катится мир...
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

325. "Разработчики systemd представили Journal, замену системе sys..."	+/–
Сообщение от anon8 (ok) on 21-Ноя-11, 01:25
Когда же этого поттеринга уволят? Описанная схема подписи логов - не защищает от затирания хвоста. Остается только сливать логи на удаленный сервер, что все сислоги умеют без поттеринговского гениального изобретения. Еще и бинарные логи? Зачем?
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	342. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от Аноним (??) on 21-Ноя-11, 07:44
	> Когда же этого поттеринга уволят? > Описанная схема подписи логов - не защищает от затирания хвоста. Остается только > сливать логи на удаленный сервер, что все сислоги умеют без поттеринговского > гениального изобретения. > Еще и бинарные логи? Зачем? У местных аналитегов спроси. Всё спорят, кто же там выше своей головы прыгнул. Или от кого лепёшка на асфальте красивее нарисовалась после прыжка с высотки. А кто это делать не хочет - тот лох и тормоз прогресса.
	Ответить | Правка | ^ к родителю #325 | Наверх | Cообщить модератору

	450. "Разработчики systemd представили Journal, замену системе sys..."	+/–
	Сообщение от N on 17-Янв-12, 05:13
	>Когда же этого поттеринга уволят? Да кто-ж его кормильца уволит? Он необходим Red Hat. Из Федоры "инновации" успешно расползаются по остальным Дебианам. Клиент вкусив прелестей творений поттеринга из Федоры, Дебиана и т.д., созревает… и покупает RHEL.
	Ответить | Правка | ^ к родителю #325 | Наверх | Cообщить модератору

352. "Разработчики systemd представили Journal, замену системе syslog"	+2 +/–
Сообщение от Alex (??) on 21-Ноя-11, 12:05
Ждём от Поттеринга внедрения реестра (только с названием другим, ессно)
Ответить | Правка | ^ к родителю #0 | Наверх | Cообщить модератору

	444. "Разработчики systemd представили Journal, замену системе syslog"	+1 +/–
	Сообщение от Аноним (??) on 28-Ноя-11, 04:48
	gconf2 не видели? С gnome-settings-daemon? И, да, его было бы неплохо переделать, сделать нормальный /etc^W /conf на манер /proc. Большинство конфигов разных программ отличаются только синтаксисом, а семантику имеют одну и ту же — key-value пары, иногда раскиданные по категориям. С очень простой системой типов. Добавляем оверлей ($HOME/.config поверх /conf, и — наконец-то — оверрайд настроек per-entry а не per-file), делаем враппер для legacy-софта (FUSE представляет /conf/libao/* в виде /etc/libao.conf), в новом софте чтение конфига делаем не 9001-й реализацией k-v парсера, а простыми сисколлами open/read/write/close, получаем конфетку. Комментарии, контроль версий — это все решаемо, причем без костылей. Единственная реальная беда вендореестра — в том, что это отдельная сущность, оторванная от всего. В остальном, структурированное хранилище лучше, нежели файлы-портянки. Все что ломается — привычки работы. Ну так с /proc и /sys работают и все в порядке. Зато упрощается весь софт — больше не нужно тащить каждому по собственному парсеру собственного синтаксиса.
	Ответить | Правка | ^ к родителю #352 | Наверх | Cообщить модератору

	445. "Разработчики systemd представили Journal, замену системе syslog"	+/–
	Сообщение от Аноним (??) on 28-Ноя-11, 04:54
	А, да, две вещи, которых не хватает для этого. - Транзакции файловой системы (они есть, но очень мутные и толком не вынесены в юзерспейс) - Унификация файлов и директорий в единую сущность, как это было в классических UNIX-системах и как это стало в пост-UNIX. А Linux застрял. Без этого все, впрочем, тоже прекрасно выходит, но уже становится несколько костыльным.
	Ответить | Правка | ^ к родителю #444 | Наверх | Cообщить модератору

Архив | Удалить

Рекомендовать для помещения в FAQ | Индекс форумов | Темы | Пред. тема | След. тема