ОК, если systemd такой хороший, то на кой чёрт бинарные логи и собственный HTTP сервер?

ну не загружай тогда демона HTTP-сервера [сам ведь он не будет загружаться!]. кто заставляет чтоль тебя? :) . его сделали а ты — хочешь пользуй, хочешь не используй :) ..

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

спасибо.. ато я уж испугался :)

Вот как религия заставляет делать бессмысленные вещи.

точно!

Зачем тратить вычислительные и умственные ресурсы на изобретение какой-то хрени, чтобы потом опять же тратить вычислительные ресурсы на её выпиливание?

Я всё-никак не могу даже представить, зачем нужны бинарные логи.

Зачем тратить вычислительные и умственные ресурсы на изобретение какой-то хрени, чтобы потом опять же тратить вычислительные ресурсы на её выпиливание?

hate driven development

Я всё-никак не могу даже представить, зачем нужны бинарные логи.

это уже обсуждалось здесь кучу раз.

хрен редьки слаще.
me свалил с арча на генту )))

Пользуясь случаем, хочу спросить. А что это у меня udev не обновляется? Что ему нужно?

athlon64x2 zenitur # emerge -av udev

These are the packages that would be merged, in order:

Calculating dependencies
... done!


[nomerge       ] sys-fs/udev-196-r1 [164-r1] USE="acl%* kmod%* openrc%* -doc% -gudev% -hwdb% -introspection% -keymap% (-selinux) -static-libs% (-extras%*) (-test%)"
[ebuild  N     ]  sys-fs/udev-init-scripts-18  5 kB
[ebuild  N     ]   virtual/udev-196  USE="-gudev -hwdb -introspection -keymap (-selinux) -static-libs" 0 kB
[ebuild     U  ]    sys-fs/udev-196-r1 [164-r1] USE="acl%* kmod%* openrc%* -doc% -gudev% -hwdb% -introspection% -keymap% (-selinux) -static-libs% (-extras%*) (-test%)" 1,923 kB
[nomerge       ] kde-base/kdialog-3.5.10:3.5::kde-sunset  USE="kdehiddenvisibility -debug"
[nomerge       ]  virtual/eject-0
[ebuild     U  ]   sys-apps/util-linux-2.22.2 [2.18-r1] USE="cramfs crypt ncurses%* nls perl udev%* unicode -ddate% -old-linux (-selinux) -slang -static-libs% (-loop-aes%) (-uclibc%)" 3,029 kB

Total: 4 packages (2 upgrades, 2 new), Size of downloads: 4,956 kB

 * Error: circular dependencies:

(sys-fs/udev-196-r1::gentoo, ebuild scheduled for merge) depends on
 (sys-fs/udev-init-scripts-18::gentoo, ebuild scheduled for merge) (runtime)
  (virtual/udev-196::gentoo, ebuild scheduled for merge) (runtime)
   (sys-fs/udev-196-r1::gentoo, ebuild scheduled for merge) (runtime)

It might be possible to break this cycle
by applying the following change:
- sys-fs/udev-196-r1 (Change USE: -openrc)

Note that this change can be reverted, once the package has been installed.

Note that the dependency graph contains a lot of cycles.
Several changes might be required to resolve all cycles.
Temporarily changing some use flag for all packages might be the better option.

!!! Multiple package instances within a single package slot have been pulled
!!! into the dependency graph, resulting in a slot conflict:

sys-fs/udev:0

  (sys-fs/udev-196-r1::gentoo, ebuild scheduled for merge) pulled in by
    >=sys-fs/udev-196-r1[gudev?,hwdb?,introspection?,keymap?,selinux?,static-libs?] required by (virtual/udev-196::gentoo, ebuild scheduled for merge)

  (sys-fs/udev-164-r1::gentoo, installed) pulled in by
    >=sys-fs/udev-145[extras] required by (gnome-base/gvfs-1.6.6::gentoo, installed)
    >=sys-fs/udev-145[extras] required by (net-print/hplip-3.9.12-r1::__unknown__, installed)
    >=sys-fs/udev-151[extras] required by (sys-power/upower-0.9.7::gentoo, installed)
    >=sys-fs/udev-145[extras] required by (net-misc/networkmanager-0.8.2-r2::gentoo, installed)
    >=sys-fs/udev-146[extras] required by (net-wireless/bluez-4.82::gentoo, installed)
    >=sys-fs/udev-147[extras] required by (sys-fs/udisks-1.0.2::gentoo, installed)
    >=sys-fs/udev-145[extras] required by (net-misc/modemmanager-0.4_p20101211::gentoo, installed)


It may be possible to solve this problem by using package.mask to
prevent one of those packages from being selected. However, it is also
possible that conflicting dependencies exist such that they are
impossible to satisfy simultaneously.  If such a conflict exists in
the dependencies of two different packages, then those packages can
not be installed simultaneously.

For more information, see MASKED PACKAGES section in the emerge man
page or refer to the Gentoo Handbook.


!!! The following installed packages are masked:
- app-pda/libopensync-0.36-r1::gentoo (masked by: package.mask)
/usr/portage/profiles/package.mask:
# Ryan Hill <dirtyepic@gentoo.org> (30 Mar 2011)
# Masked indefinitely (until 0.40 is released).
# http://bugs.gentoo.org/354423

For more information, see the MASKED PACKAGES section in the emerge
man page or refer to the Gentoo Handbook.

Я не хочу удалять openrc, зачем?!

я НИЧЕГО не знаю о функциональном программировании, я даже боюсь самой мысли попробовать изучить эти ЯП

лишь знаю что некоторые языки являются мульти-парадигменными, похоже те что используются в nix - таковыми не являются

и опять же - я полный НОЛЬ в ФП

но ради пакетного менеджера GNU/Guix и nix я бы озаботился изучением...

И ещё хочу спросить. USE-флаг «hal» удалён из ebuild'ов, перечисленных на этой странице в строке Depends on. Сразу после этого удалён и сам HAL (в оверлее kde-sunset остался). А как теперь с Gentoo/kFreeBSD? Всё, больше не существует? Ведь udev в нём нет! Или всё-таки есть оверлей с этими же ebuild'ами, но с USE-флагом «hal»?

Пользуясь случаем, хочу спросить. А что это у меня udev не обновляется? Что ему нужно?

По-моему, у меня эта проблема вылезла ещё месяца 3 назад. Но я сидел на ~amd64.

Я не хочу удалять openrc, зачем?!

Оно предлагает временно сделать USE="-openrc" для udev, чтобы разрулить циклическую зависимость, а не удалять openrc.

Если я правильно помню, это не поможет (у меня и так был USE="-openrc"), и вылезет конфликт файлов, когда будет устанавливаться udev-init-scripts, а udev ещё не обновился (часть файлов из пакета udev перенесли в udev-init-scripts). Я у себя решил это, удалив руками эти файлы (список даст emerge), далее установил udev-init-scripts, потом обновил udev. Возможно, есть более чистое решение. Может быть, это другая проблема.

и опять же - я полный НОЛЬ в ФП но ради пакетного менеджера GNU/Guix и nix я бы озаботился изучением...

nixos — чистой воды идиотизм академизм в худшем смысле этого слова

если хочешь его изучить — почитай пейперы; они написаны вполне доступно (без греческих букв) и там есть местами интересная и справедливая критика нынешних пакетных систем/менеджеров, однако как *практический* путь решения этих проблем nixos не годится

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

В арчике у меня openrc. Работает отлично. Для полного щасья не хватало только форка udev'а, а то у меня замаскирован с версии 182-4.

Спасибо, это я и хотел услышать. Этой информации достаточно. Если к утру никто не напишет совета лучше (а гентушников сегодня здесь много), я так и сделаю!

однако как *практический* путь решения этих проблем nixos не годится

Почему?

Зачем тратить вычислительные и умственные ресурсы на изобретение какой-то хрени, ...

ну предположим кому-то (из разработчиков) — это показалось полезным..

бывает такое? :)

... чтобы потом опять же тратить вычислительные ресурсы на её выпиливание?

тыг я же и не говорю что НЕ надо тратить силы на вЫпиливание HTTP-сервера . просто не нажимай кнопку «вкЫл» :) . сам HTTP-сервер не начнёт свою работу.

лежит себе на жёстком диске [отдельными бинарным файлом] и никому не мешается! :-)

Я всё-никак не могу даже представить, зачем нужны бинарные логи.

ну если ответить быстрым ответом — то это:

1. более безопасно (от подмены).

2. более удобное поиск/фильтрация в логе.

3. более широкие возможности для запоминания внутри лога всякой маловажной фигни.

4. более стандартизированно (относительно различных программ).

Из других новостей...

Официально стартовал форк eudev от Yahoo - проект получил название yahoo_eudev.

Сколько человек будет над ним работать?

важно не столько количество разрабов, сколько количество и продвинутость тестировщиков

точно так же как миллион обезьян не заменит одного $your_favorit_author, так и миллион хомячков, пускающих сладкие слюни на systemd, не заменит одного профессионального админа или программиста на с/с++ в деле отлова редкого бага

еще учтем, что в *dev функциональность добавлять не особо нужно — нужен скорее саппорт того что уже есть и адаптация к (небольшим) изменениям в ядре линукса, а с этим может справиться и небольшая группа разрабов

Почему?

краткий ответ: потому, что основная проблема неповторяемости — в измении данных пост-инсталл скриптами

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

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

краткий ответ: потому, что основная проблема неповторяемости — в измении данных пост-инсталл скриптами

Возможность держать в системе любой точный набор версий пакетов ты пропустил или эта возможность тебя не интересует?

вот еще есть http://lists.debian.org/debian-devel/2008/12/msg01027.html хотя немного лишнего специфично для дебиана, но подробно

вместо nix подошел бы, возможно, хитрый менеджер транзакций, который должны были бы учитывать инсталл-скрипты, и/или фс со снапшотами и дедубликацией данных — это было бы реалистично

Возможность держать в системе любой точный набор версий пакетов ты пропустил или эта возможность тебя не интересует?

pinning версий пакетов и наличие /var/cache/apt/archives/* — этого тебе мало?

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

Хорошая новость. Прекрасно когда есть выбор.

pinning версий пакетов и наличие /var/cache/apt/archives/* — этого тебе мало?

Просто «мало» не отражает того, насколько это мало.

рассказывай тогда юз-кейс

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

рассказывай тогда юз-кейс

Смешивать версии на одной системе. Поставить в нее несколько версий libc, несколько Firefox, несколько X-серверов.

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

Аж настолько много, что ни один коммерческий *NIX на них не перешел, насколько я знаю :)

Смешивать версии на одной системе. Поставить в нее несколько версий libc, несколько Firefox, несколько X-серверов.

и они тебе сразу засрут те свои конфиги, до которых смогут дотянуться по записи; у меня даже опыт такой есть (правда не под никсом)

тут надежен только chroot+дедубликация, если жалко диска

хотя, впрочем, фф для линукса можно скачать с мозиллы в виде все-свое-тяну-с-собой и поставить в другой /home/$user (вот не знаю насколько он там привередлив к старой или новой системе)

а как же GNU/Guix? ИМХО жизнеспособное решение, перспективное в будущем

вот только сегодня я возился с dependency hell, не мог dev пакеты которые поставить ибо требовали более старую версию пакетов... и всё это из репозитория

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

Я обратил внимание на NixOS только ради ФП и как следствие вместо python+bash на язык nix в сценариях в «ebuid»-ах NixOS, а если оставаться на императивной концепции, то лучше portage ничего нет.

В NixOS есть storage - тот еще аналог dll-hell. Так что бывает, что иногда забывается что-то хорошее и появляются старые болячки снова. Надеюсь что авторы NixOS выпилят storage или сам это сделаю.

бывает такое? :)

Последнее время только такое и бывает.

просто не нажимай кнопку «вкЫл» :)

Это сейчас оно включается, а потом будет как nepomuk в KDE.

По поводу бинарных логов я скажу лишь то, что для их чтения нужна какая-то сторонняя прога. Если раньше прелесть Unix-like систем была в том, что все конфиги это обычный текстовый файл, равно как и логи (которые можно было смотреть чем угодно, как угодно вертеть, перенаправлять, читать, писать и что хочешь делать), то теперь в Linux последние превратились в бинарник, для чтения и редактирования которого отдельный софт и вся фигня. Меня это печалит.

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

а как же GNU/Guix? ИМХО жизнеспособное решение, перспективное в будущем

Guix сравнительно молодая и видимо не шибко отработанная прога, уж лучше тогда nixos

а вот ты попробуй на nixos поставь десяток разных версий фф; затем поставь в древние версии фф древние версии плагинов; затем запусти фф новой версии

и если новый фф у тебя при запуске не деинсталлирует с концами старые плагины (по причине того, что он с ними не совместим и выполняет Трогательную Заботу О Пользователе) из конфига(-ов) старых версий в /home/..., то я, возможно, соизволю поглядеть на nixos, хотя, честно говоря, все равно не вижу смысла подвергаться риску внезапного аналогичного глюка в будущем в обмен на несколько жалких гигабайт на hdd

а как же MoonOS - там всю ФС перелопатили, сделали конфетку

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

кстати, ты имеешь ввиду /nix/store ? там ведь как раз пакеты в разных папках под своими версиями

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

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

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

А systemd был сделан заново

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

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

на кой чёрт бинарные логи и собственный HTTP сервер?

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

ты сам что, systemd не используешь?

а у тебя с ним какие-то проблемы?

Всё правильно сделали.
Непонятно чё такой бугурт у поклонников systemd, особенно у тех кто дженту не использует?

Я всё-никак не могу даже представить, зачем нужны бинарные логи.

ну если ответить быстрым ответом — то это:

1. более безопасно (от подмены).

Ни разу нет. Доводов на LOR приводилась масса.

2. более удобное поиск/фильтрация в логе.

Наличие ОДНОЙ утилиты удобнее, чем наличие over 100500 утилит текстового поиска?

3. более широкие возможности для запоминания внутри лога всякой маловажной фигни.

Это да. Остается только вопрос - а зачем она ТАМ?

4. более стандартизированно (относительно различных программ).

Вы правда считаете, что без-году-неделя-разработка - это БОЛЕЕ стандартизовано, чем формат с более, чем 20-ти летней историей? (К тому-же по новому «стандарту» практически никто не пишет.)

отвечу по пунктам.

2. что мешает сделать journalctl | 100500 утилит? тути функционал не утерян

3. КО: для отладки

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

1. не разбирался в вопросе, подождите другого ответа

2. что мешает сделать journalctl | 100500 утилит? тути функционал не утерян

+ ненужный костыль.
- самостоятельное индексирование только нужного

3. КО: для отладки

/var/log/debug.log и т.д., и т.п.

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

И далеко оно продвинулось от статуса «попытка»?

2. лень написать «journalctl |» - не аргумент. мотивируйте ненужность.

просветите, в journalctl индексы не настраиваемые?

3. для отладки лишней информации не бывает. на какую часть вопроса «зачем оно там?» я не ответил?

4. подскажите единицу измерения - измерим. пока могу дать лишь субъективную оценку: далеко.

Ну форкнули, и ладно. Главное, чтобы удавовские правила расширять не начали. С этим и раньше головная боль была

2. лень написать «journalctl |» - не аргумент. мотивируйте ненужность.

Перегонять из бинарного в текстовый - лишняя загрузка CPU. Не нужно.

просветите, в journalctl индексы не настраиваемые?

Там их пока, по-сути, еще нет толком. А уж как появятся - так и обсуждать будет чего.

4. подскажите единицу измерения - измерим. пока могу дать лишь субъективную оценку: далеко.

Количество программ, использующие новый формат. И сопоставить с использующими старый.

2. а) грепать по текстовым логам - вот оверхед.

б) хрень это все: загрузка имеет значение при работе сервисов, а не при анализе логов.

чем индексируете логи, кстати?

4. еще раз, вы меряете не то, о чем говорил user_id_*. читайте ветку до просветления

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

openlog()/syslog()/closelog() - это каждая по своему? или разбор строки с полями фиксированной длины - вообще непосильная задача, требующая немалых ресурсов и 100500 сторонних либ?

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

Конечно, таких бестолочей в генте нам не надо, так что беги, но всё-таки интересно, чем тебе мешает наличие альтернативы udev в дереве?

Ага...

... И, заодно, кто бы ещё объяснил что теперь, во времена бинарных логов, делать с анализом логов чем-то типа logwatch и и же с ним?

Помнится даже когда-то некий Ларри Стена даже язык Перл написал для удобного анализа логов. Году, этак, в 1987.

А теперь что? Не читать логи? Тогда на фиг они вообще нужны?