I love Poettering .. :-)

марк недавно сказал что будут пилить, на что леннарт разразился в стиле «ну и пили свое г.. в воем стойле, мы все равно будем впереди» :-) У федорчука было

В убунтоидов пилили свой зуд - upstart (ради понтов? и шото я не слышал на лор новостей о нем, или фапа на него)

Дык оно вроде не пытается включить в себя udev, syslog, менеджер сеансов и т.п, и не пытается втулить себя в качестве зависимости для Гнома. Под него даже не надо переписывать FHS. Чего о нем особо распространяться? Тем паче (не устану повторять), что его РедХет Ынтырпрайз Линукс использует - значит штука, как минимум, работоспособная. А что Леннарту и работодателям что-то мешает использовать NIH-софт и дальше и участвовать в его развитии, так бубунта тут не причем.

Может, всё-таки «I like Pottering»?

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

да-да-да. Если это це, то поимеем бинарь, для которого надо читать и компилять его исходник, вместо того, что видно прямо по месту и, что там же по месту привится. Причем, на языке допускающем массу возможностей прострелить себе ногу. Самое обидное, что придется применять це, вместо более подходящих языков. И эти люди будут говорить нам про свободу... А потом дойдем, что для того, чтоб ты и Поттеринг не мучались надо выбросить все остальные языки, /etc, сделать диски c, d...

Наоборот, я сказал, что Гислер молодец, что до такого не догадался.

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

Ты уверен, что дело в баше или так, предположил? Как ты искал бутылочное горлышко?

Нет.

А все остальное - от лукавого.

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

если что-то надежно годами работает, то вполне приемлемо. За столько времени могли много где родить. И, наверняка - рождали.

Ещё как меняется.

В системе загрузки есть перевод? Но тут ты таки прав, если есть привязка к локализации вполне вероятны проблемы. Но кто мешает запускать процесс с английской локализацией?

А я об основных разработчиках прикладного софта.

Пишущие исключительно на ЦЕ - может быть. Короче поживем-увидим.

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

Я испытываю гораздо больший ужас, от мысли, что там, где идеален скриптовый язык, будет неадекватный задаче инструмент и все станет гораздо сложнее, чем есть. Плюс надо гарантировать, что то, что в исходнике соответствует скомпилированному бинарнику, плюс дополнительные усилия на компиляцию.
Но в чем-то ты прав. С С++ я не имел дела с года, кажется, 2000. И надеюсь, больше не придется. А с С последний раз работал лет 4 или 5 назад. По причине того, что для моих задач существуют более целесообразные инструменты к этим инструментам я лишний раз обращаться не намерен.

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

Не всегда верен принцип «все что новое то плохое» зато всегда полно тех, кто по разным причинам держится за старое :-) Я например вряд ли увижу его поделие в своей слаке :-)), по крайней мере пока патрик ее пилит, но сами принципы, положенные в ее основу, мне откровенно нравятся. Вопрос лишь в технической реализации Сумеет леннарт со своими амбициями сделать по уму, пирожок ему с полки, сделает вторую пульсу, ну сам виноват, если мозгов хватает только на хорошие идеи а реализация получается как ..

почему это? вполне можно заюзать,unixway это переносимость под разные платформы в первую очередь,userspace и одна задача,одна утилита это общее для всех осей. Комбайны начали появляться только под винду и то в году 2000 что ли.

понтовые дистры, типа

Fedora(development distro(c))

полигон бесплатных альфачей^Wальфатестеров

OpenSUSE

полутруп

Мандривочники

дважды труп советского союза

И в чём понты?

unixway это переносимость под разные платформы в первую очередь

В цитатник :-)

ну ты же у нас такой учёный и историю знаешь. *сарказм*

alsa умеет почти всё

Умеет ли alsa a) без плясок с бубном регулировать звук отдельно каждого приложения б) подключать «на лету» звуковую карту с перенаправлением вывода на нее (и, соответственно, возвращать вывод на первую после отключения)?

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

В убунтоидов пилили свой зуд - upstart

Вроде до недавнего времени upstart был быстрее, чем systemd, не?

регулировать звук отдельно каждого приложения

у приложения нет своего регулятора?

подключать «на лету» звуковую карту с перенаправлением вывода на нее

udev(я же полагаю карта usb-шная?)+asoundrc

Что мешает growisofs, mplayer и остальным сделать номальные библиотеки для доступа к функциям и давать фронтендам работать через них?

Это мелочи. Всё можно организовать так, чтобы не приходилось забивать себе голову. Заинклюдишь нужный заголовочный файл и всё. Основной задачей так и останется реализация логики работы.

Ты предполагаешь, что все все будут делать правильно с твоей или Поттеринга точек зрения? Если это так, то тебя разочарую. Никто этого делать не будет, т.к. нафиг никому не вперлось. Никто не будет отказываться от используемых языков и трубопровода только потому, что это поссорит их с systemd и поттерлогом.

Вот реально. Тебе лишь бы поспорить? Ну грохну я пачку с дисками на пол - результат тоже будет один.

ты утверждал, что диски потрит используемый в k3b трубопровод. Я утверждаю, что диски портятся и там, где трубопровода нет. Т.е. без дополнительного разбирательства, кто виноват неправильно парсящий вывод трубопровода k3b, growisofs, производитель диска или пишущего девайса я бы выводов не делал. Нет точных данных для утверждений.

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

Прелесть отдельного API в том, что все данные передаются в удобном программисту формате

В разных языках разные структуры данных. Или ты предлагаешь везде и всюду использовать С? Трубопровод потому и используется, что более универсальной структуры данных, чем голый текст, еще не придумали.

Ты путаешь ЯП и систему, для которой писать на нём. Хватит тупить.

туплю. По-идее, системе пофиг, на каком языке для нее пишут.

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

С верами, надеждами и любвями - к попам. А к инженерам с точными данными. Ты утверждал, что будет работать лучше если не будет тысяч прослоек и все будет завязано на бинарную монолитную systemd. Притом, ты даже не представил критериев лучшести. ИМХО, максимум, что добъетесь с таким подходом - это некоторого, непринципиального, ускорения системы. Но проиграете в прозрачности, модульности и, как следствие - большей кустомизабельности. Потому как попробуй что-то сделать со скомпилированным бинарем. Где, что и почему упало - хрен его знает, дебажить - сложно. В итоге проблему не решить.

Но на фоне общей тормознутости Eclipse, уже просто не хочется говорить о работе с stdin/out в его расширениях. Одно ясно: под категорию качественного софта, работающим с stdin/out, по моим меркам он не подходит. И объяснил, почему.

А о других IDE, где вовсю stdin/out используется хочешь? Годный QTCreator stdin/out, думаешь, не использует?

А я об основных разработчиках прикладного софта. Они только рады будут

Разработчики прикладного софта пишут далеко не только на С/С++. Так что очень большой вопрос, захотят ли отказываться от трубопровода. Особенно, если в проекте несколько языков задействованно.

Они там тоже подробные. Но не юзабельные. Вот это предлагают и тут.

С херали они неюзабельные? Там есть гибкая возможность делать запросы из GUI, они неплохо структурированы в отличии от зоопарка логов в линуксе, из cli с ними работать также одно удовольствие.

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

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

да где ж вы такие беретесь то, а? вам скорость загрузки десктопа важнее его работы? у меня загрузка системы занимает наверное меньше 0,1% от времени работы

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

Структура очень четко и ясно описана

В винде тоже. Но что произошло не понять.

это значит, что все логи которые писались syslog'ом ... прекрасно лягут в новую систему логов

И потребуют дополнительных усилий на их извлечение.

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

Гибкие запросы к бинарю? Не верю.

вы учитываете, что оригинального предложенного Поттерингом journald уже нет, а он пилится (проектируется) совместно разрабами и других syslog систем?

Оригинальный вариант был *кхм* плохим, хотя и содержал некоторые правильные идеи.

В них пишут кто и когда что-то натворил. Но что именно произошло не пишут.

Все зависит от приложения

В винде тоже. Но что произошло не понять.

Еще раз повторю. Вызовы не изменились. События будут столь же ясными (или неясными) как в случае классических syslog. Но при желании приложение может использовать и расширенные возможности без совместимости c syslog - это уже решать разработчику приложения. Прочитай наконец подробности реализации.

И потребуют дополнительных усилий на их извлечение.

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

Гибкие запросы к бинарю? Не верю.

Ты очень огорчаешь базы данных.

вы учитываете, что оригинального предложенного Поттерингом journald уже нет, а он пилится (проектируется) совместно разрабами и других syslog систем?

Нет, давно не интересовался темой. Где можно почитать?

Ты очень огорчаешь базы данных.

Их использование очень небесплатно. Особенно для гигабайтных объемов одной только таблички. И ujksq grep гораздо мощнее like.

если снова найду скину. История вкратце: началось в критики (анализа) от авторов rsyslog, после этого RH «усадила» всех за стол переговоров в итоге пришли к консенсусу.

Спасибо, не знал, попробую тоже нагуглить

Их использование очень небесплатно. Особенно для гигабайтных объемов одной только таблички. И ujksq grep гораздо мощнее like.

Только для кривых запросов. Тот же самый полнотекстовый поиск будет работать потенциально на порядки быстрее (зависит от объемов, но уже на мегабайтовых очевидна разница - больше объем - быстрее) чем grep, если ограничить выборку дополнительными условиями, например по времени, дате, статусу, etc. Снизить нагрузку на io с grep можно исключительно утилитами подобными head и tail, что как сам понимаешь возможно в очень редких либо искусственных случаях.

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

С херали они неюзабельные? Там есть гибкая возможность делать запросы из GUI, они неплохо структурированы

А без GUI?

из cli с ними работать также одно удовольствие.

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

Структура отнюдь не произвольная.

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

May 16 08:11:02 asm3 anacron[1225]: Job `cron.daily' terminated (mailing output)
May 16 08:11:02 asm3 anacron[1225]: Normal exit (1 job run)
May 16 08:11:02 asm3 postfix/pickup[1833]: 4FD248C0CD: uid=0 from=<root>
May 16 08:11:02 asm3 postfix/cleanup[2710]: 4FD248C0CD: message-id=<20120516051102.4FD248C0CD@asm3>
May 16 08:11:02 asm3 postfix/qmgr[1834]: 4FD248C0CD: from=<root@asm3>, size=1853, nrcpt=1 (queue active)
May 16 08:11:02 asm3 postfix/local[2712]: 4FD248C0CD: to=<miha@asm3>, orig_to=<root>, relay=local, delay=0.3, delays=0.07/0.2/0/0.02, dsn=2.0.0, status=sent (delivered to mailbox)
May 16 08:11:02 asm3 postfix/qmgr[1834]: 4FD248C0CD: removed
May 16 08:11:22 asm3 hddtemp[1661]: /dev/sg0: WDC WD800JD-00MSA1: 35 C
May 16 08:11:22 asm3 hddtemp[1661]: /dev/sg1: WDC WD2500AAJB-00J3A0: 40 C

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

Жду описания утилей для манипулирования всем этим делом.

Тут бинарный лог снова вне конкуренции

В ua.csv небольшая таблица из одной базенки.

$du -sh tmp/ua.csv
31M tmp/ua.csv
$ cat tmp/ua.csv | wc -l
162476
time cat tmp/ua.csv |tr '[:lower:]' '[:upper:]'| grep USERS |awk '{print $ 1 $ 2}'
2269462;0;01.02.201209:26;UPDATE
2271691;0;03.02.201209:20;UPDATE
2271692;0;03.02.201209:20;UPDATE
2271693;0;03.02.201209:20;DELETE
2271696;0;03.02.201209:20;UPDATE
2271697;0;03.02.201209:21;UPDATE
2274255;0;10.02.201208:35;UPDATE
2274259;0;10.02.201208:41;UPDATE
2275251;108;13.02.201214:13;UPDATE

real 0m0.124s
user 0m0.060s
sys 0m0.112s

------ Performance info ------
Prepare time = 323ms
Execute time = 591ms
Avg fetch time = 65,67 ms

А без GUI?

Можно, там и пример. Но толку все равно мало.

На VisualBasic? Орлангорчег отличный пример того, что нарктоики - зло.

таки cmd.exe => можно засунуть в bat-ник.

cscript //h:cscript //s //nologo
eventquery /fi "Type eq Error" /l application

таки cmd.exe => можно засунуть в bat-ник.

Если он умеет гонять скрипты на VB - это уже не cmd.exe. Всё равно, что в случае Linux сказать «а у Python есть классный модуль разбора логов». Проблема в том, что самого Python может не оказаться.

у приложения нет своего регулятора?

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

Проблема в том, что самого Python может не оказаться.

Специально сходил посмотреть на коллегином ХР. Те 2 строчки работают, так что все на месте. Правда, на виндовую консоль медленно выводят, гораздо быстрее все в их гуй грузится.

Специально сходил посмотреть на коллегином ХР. Те 2 строчки работают, так что все на месте

В полной и работоспособной инсталляции XP? Конечно, на месте. У меня на рабочем месте в Linux тоже есть работоспособный Python с тоннами библиотек. Вопрос в том, что делать, когда возникают проблемы, особенно на каких0нибудь минимальных инсталляциях.

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

Ок, вот тебе несколько усложненный пример

Get-EventLog -log system -source "Windows Update Agent" -entry Error -after 01.01.2012 | 
	Where {$_.Message -Match "Ошибка подключения"} | 
		Select TimeGenerated, Message |
			ConvertTo-Html > "\\foo\bar\{0}.txt" -f (gc env:computername)

В полной и работоспособной инсталляции XP? Конечно, на месте. У меня на рабочем месте в Linux тоже есть работоспособный Python с тоннами библиотек. Вопрос в том, что делать, когда возникают проблемы, особенно на каких0нибудь минимальных инсталляциях.

В самых минимальных инсталляциях десктопных win-систем есть GUI, если же серверная винда поставлена без gui, то там обязательно есть PS.

зачем плимут, если он == хелловорд(wayland)

Блин, вот решил, что таки «игнор - для слабаков» и убрал ТС из фильтра.

Добавлю обратно - черезчур фанатично.

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

выставляем нужный ALSA_PCM_DEVICE в окружении для приложений-калек. Девайс, естественно, нужно описать в ~/.asoundrc (если использовать equal плагин, можно будет даже alsamixer-ом рулить в реалтайме)

также есть чуть более костыльные, но тоже рабочие способы.

В общем, не повод. Единственное чего не может alsa - сеть, но для сети я лучше jack заюзаю (хотя, опять же, ни разу не пригождалось)

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

lol ok. datetime, user, source, message

В ua.csv небольшая таблица из одной базенки. blablabla

Запрос без условий? Условия позволят неплохо сэкономить

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

I love Poettering .. :-) (комментарий)
Обрати внимание на используемый дистр в части фанатизма :-)

Дестопам компы не исчерпываются

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

Есть еще и ноуты и нетбуки, для которых на линупсе suspend это пляски с бубном

GDM таки требует OGL, или нет?

Нуу, ldd /usr/bin/gnome-session не показывает...

Там надо смотреть зависимости gnome-shell (если он установлен и система его тянет, то GDM запускается в нём). А он зависит от mutter (потому что GS — плагин для него), тот в свою очередь тянет clutter. И вот у clutter'а уже в зависимостях стоит cogl: «An object oriented GL/GLES Abstraction/Utility Layer»

Ни cogl ни clutter на 12.04 у меня нет. На старой системе (10.10) стоят. И gnome-shell на 12.04 нету, если судить по dpkg -l. Но, конечно, утвержать наверняка что gl для входа в систему я не возьмусь - я в десктопном софте ничего не понимаю.

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

lol ok. datetime, user, source, message

Меня интересует раскладывание в кошерную структуру message, иначе никакого профита от новой структуры нет.

Запрос без условий?

Конечно с условиями.

where upper(my_field) like '%USERS%'