если следить за пид и писать все в БД то будет ровно та же фигня

если - то да. Надо бы опрос провести, у какого процента лоровских админов на всех серверах настроено непрерывное логирование в БД.

Я правильно понял, что логи в raw виде попадали в БД, а интересные парсились и писались в специализированные таблицы?

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

Разве что, а не напрягает, что именно эта часть делает системд линукс онли?

Нет. Если честно то меня напрягают вещи типа gnome-only или там RedHat-only, а вот Linux-only как-то совсем не мешают :)

Вам ждать этого не нужно, т.к. опенрц, к сожалению фаворитом не будет, если только чудо не случится, а так оно в 0.12 в Генте, некритичные баги были, часть исправлено, часть вскоре будет. Основная проблема, что я этим занимаюсь где-то час в месяц и в том что изменения медленно проверяются главным разработчиком..

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

если - то да.

Кстати сделать по простому (т.е. не треьуя какой либо настпойки сервисов) в syslog-ng сделать логгирование каждого сервиса в отдельный файл из коробки я так и не придумал, а журналд умеет..

Если честно то меня напрягают вещи типа gnome-only или там RedHat-only,

Много такого? (Что именно завязано, а не не портировано, т.к. все заинтересованные и так рхелом пользуются). В Генте напр. нету многих классных штук т.к. девелоперы не пользуются данным софтом, а юзеры не просят, что в общем то может быть печально для генты на серверах. Про linux-only, моё личное (а потому не компетентные мнение), что наличие POSIX совместимого решения, или fallback-а в таковое определяет здравость архитектуры программы. напр. мне кажется что излишнее использование цгруп не оправдано (если верить документации ядра) в итоге цгруппы будут менять под системд, хотя тут надо бы разработчиков пнуть, может я что-то неверно понимаю.

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

Да никто с этим особо не спорит, действительно инновации в системы поставлены на новый уровень и если смотреть по функциональности, то выбор дебиана очевиден (процесс конечно немного печален). Печалит то, что реализация.. странная.. Вот например, там новые изменения в сокет активейшене и том когда сервис считается готовым (нужно пинать сокет системд специально подготовленным удп пакетом) т.к. несмотря на все уверения что сокет активейшн спасёт всех оказалось что ситуация сложнее. Хотя форсинг подобного решения это круто:)

Много такого? (Что именно завязано, а не не портировано, т.к. все заинтересованные и так рхелом пользуются)

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

Печалит то, что реализация.. странная.. Вот например, там новые изменения в сокет активейшене и том когда сервис считается готовым (нужно пинать сокет системд специально подготовленным удп пакетом) т.к. несмотря на все уверения что сокет активейшн спасёт всех оказалось что ситуация сложнее. Хотя форсинг подобного решения это круто:)

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

только ручками писать гораздо больше приходится.

this. Чем больше кода, тем больше багов.

Ну например.

У моего знакомого есть майнер. Он впихнул пять карточек с двумя гпу на каждой (одна палёная, но один гпу работает) в копьютер. Т.е. всего 9 гпу должно быть. Запускает он цгмайнер, а он и говорит, так мол и так, нашёл 9 гпу, но из-за драйвера можно использовать только 8мь.

Делаю ставку на то, что драйвер написан на с и там, вместо сделать по нормальному и хранить всё в списке, хранят всё в каком-нибудь dev_t devices[8].

Такого говнокода я уже много видел, поверь. И когда так пишут важный системный компонент (пид1?), умирает один котик.

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

Хотелось бы надеяться.

Ух ты какая активность!

Умею я поднимать животрепещущие темы )))

это ты упоролся считать буферизированную запись скоростью винта.

BTW, все винты этой серии - AF.

Ты о какой из серий?

this. Чем больше кода, тем больше багов.

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

это ты упоролся считать буферизированную запись скоростью винта.

Ты вот оказывается еще и другого не понимаешь: буфер маленький, сколько там у 14 барракуд, 32 или 64 метра, и по заполнению его оно быстрее скорости записи винта писать не может. Но записывая большими кусками, нивелируется проблема позиционирования. То, что ты делаешь - приводит к тому, что голова по четыре раза на один сектор дергается, ибо винт - AF, по 4 килобайта сектора у него. Почитай спеки, темнота.

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

разработка на C, имхо, требует куда меньше работы головой

Мде… напиши драйвер. Просто напиши драйвер.

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

Вся проблема с драйвером - нужна величайшая аккуратность и внимательность. Ничего принципиально сложного. Я писал довольно большие драйвера для BSD-подобного ядра XNU. Знаю как это отлаживается. Отладка плюсового кода с кучей шаблонов и мета-программирования - на порядки сложнее.

dk-, ты ведь далеко не первый раз поднимаешь темы, суть который сводится к «Эй, я не понимаю, почему вас волнует %something%?».

Это целенаправленно или действительно такая наивность? :)

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

Называй этих людей... энтузиастами. Да, ведь действительно есть такое прекрасное слово, которое сейчас редко упоминают, но которое очень хорошо передает суть и мотивацию.

Вся проблема с драйвером - нужна величайшая аккуратность и внимательность.

Спасибо. Именно это я и говорил в самом начале. Только вот проблема в том, что ни один человек никогда без ошибок ничего не напишет. Отсюда следует очень простое и очевидное правило - чем меньше кода, тем меньше багов.

Отладка плюсового кода с кучей шаблонов и мета-программирования - на порядки сложнее.

Вот не надо вот! Когда чуваки на сях приводять какие-то там структуры в void * а потом обратно, компилятор это хавает и чихать хотел на ошибки приведения. А вот в спп когда чуваки у шаблона тип указали явно, компилятор выдаёт ворнинг о том, что чуваки страдают хернёй (если они действительно сделали херню). Когда чуваки на сях скормили неправильный энум ф-ии, компилятор на это чихать хотел. А в спп чуваков пошлют (имею ввиду enum class или namespace). Дальше ещё куча примеров, которые мне лень описывать.

И да. Использование const char * & str***() вместо std::string офигительно делает програмирование на сях простым и понятным.

драйвера для BSD-подобного ядра XNU

Я так понимаю это было выше mach или как? А как там отладка делается? Сам дебагер в bsd ядре работает или как отдельный процесс для mach? Просто интересно. Я не в теме если что, только для линукса дрова писал.

я ващето про буфер ОСи, а не винта. Именно это подразумевается под буферизированной записью обычно.

Но спорить с тобой я не буду что линейная скорость записи на хороших удачных винтах может и правда достигать сотки (вероятно и выше) при условии рисутствии другого ИО. Тут я погорячился про 50Мбайт/с, признаю.

Однако в реалиях софт не пишет блоками по мегабайту(тем более логи). Да и линейности ты никогда не получишь на живом сервере, т.к. ИО обычно впоряде. Так что в общем и целом мои изначальные слова всеравно верны, а ты решил просто придраться к фразе в отрыве от контекста дискуссии.

на живом сервере

там давно enterprise-grade ssd :)

Так что в общем и целом мои изначальные слова всеравно верны

Нет, не верны, потому что суть чушь.

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

экономически не целесообразно, за редким исключением.

экономически не целесообразно, за редким исключением.

Да ладно, те же SM843T продаются по три копейки.

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

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

Выше mach. Дебаг там двумя путями - gdb по сети либо core dump по сети-же, на другую машину. Насколько я понимаю устройство, дебагер там встроен в BSD часть ядра, но т.к. по большому счету - оно довольно монолитное с Mach / I/O Kit, то отлаживать подобным образом можно много чего, но не все. Драйвер тот был NKE расширением - Network Kernel Extension, и в ряде случаев оно портило внутренние буфера сетевые, так что gdb и remote core dump - нагибались тазом ;) (с учетом того, что последние секунд 5-10 dmesg-а в файл лога не попадали, отлаживались подобные баги только одним способом - вдумчивым взглядом в код, медленно, но впрочем вполне успешно)

Вообще это, на самом деле, давно очень было, еще во времена OS X 10.3/10.4, с тех пор много чего могло поменяться.

Вот только в твои утверждения о людях самого разного уровня сводятся на «нет» одним только тем, что опадание кода в апстрим Linux очень жёстко контролируется компетентными людьми с гигантским опытом, компетентность которых многократно подтверждена практикой (впрочем, это не значит, что мозг надо отключать, когда имеешь с ними дело) - чуть что не так, и код не будет принят, сколь бы полезным и важным он ни был (BFS, TuxOnIce, и т.д.). В случае же с systemd и PulseAudio во главе стоит фактически быдлокодер-недоучка. Это не плохо - опыта действительно надо набираться. Плохо то, что этот быдлокодер-недоучка даже не пытается прислушаться к более опытным людям и к пользователям, он всех просто посылает и действует вопреки логике и адекватным инженерным приёмам. Плохо и то, что его поделия пытаются пихнуть куда не надо. И не просто, а агрессивно навязывая (udev и gnome3 - самые известные примеры актов навязывания).

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

RTP> А вот Сан сознательно и корпоративно-методично впилил XML конфиги в инициализацию своей адской ОСи. С тех пор случился бугуртище у всех.

А ничего, что инит у солярки небольшой и уже дальше пускает то, что делает systemd? То бишь, спроектирована система грамотнее.

RTP> С точки зрения пользователя - все усложнили в разы

Сферическому пользователю в вакууме абсолютно пофиг. И в инитскрипты он не лезет. А продвинутому, который туда лезет, совсем не пофиг. Одним нравится то, что прозе стало писать конфиги для запуска сервисов, а другим не нравится за то, что systemd - bloatware, crapware иdefective by design, обуславливающим потерю надёжности.

kernelpanic> Идите в жопу со своим юниксвеем - GNU is Not UNIX.

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

pekmop1024> В systemd всё унифицировано настолько, насколько это технически оправдано.

Нет там унификации. Там сплошная монополизация. А это совсем другое.

Там вполне адекватные аргументы. На одном заострять внимание не стоит.

Просто таких разработчиков, да ещё и стремящихся такое всем пихнуть для пользования, надо лупить тапком.

Мне вот что интересно:

Почему-то при срачах systemd vs everything сторонники systemd первыми начинают читать мантру «Устои, традиции, неукоснительное соблюдение юниксвея, говно мамонта, заменить, кококококококо!!!!!».

Потому что кость болеть (а тем паче — думать) не может!

У тебя все утверждения сводятся на «нет», независимо от их содержания. И вместо них поток ниоткуда взятых штампов.

Я так понимаю это было выше mach или как? А как там отладка делается? Сам дебагер в bsd ядре работает или как отдельный процесс для mach? Просто интересно. Я не в теме если что, только для линукса дрова писал.

BSD и mach там в одном адресном пространстве

Или вы все поголовно шлете патчи и у вас есть вполне адекватные причины к ненависти?

Тут уже давно ни у кого нет адекватных причин ни к чему...

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

эх, теории....

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

P.s. правда с пульсой как-то так не выходит. Не умеет оно того, что заявляет. Например, на shairport прозрачный вывод не запилить.

Я сам из энтузиастов, потому обливания говном тут нет никакого.

Вместе с этим, очевидно большое число «ненужнистов» орет лишь бы поорать.

Еще... я вот чего думаю (может и не прав): поди эти перемены понимающие люди делают и принимают? Или нет?

Что можете сказать через полтора года?

СистемД уже торт?

На Debian testing он просто делает что-то, чтобы система работала, как раньше делали скрипты. Единственное отличие — система стала выключаться быстрее. Всё.

А, да, эта штука называется systemd, все буквы строчные, пишется слитно.

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

Как и ожидалось.

Eddy_Em, а у тебя как?

У него вроде серверов и нет, гыгы.

Обхожу это дерьмище стороной.

GNU против юниксвея
Да весь софт против юниксвея
Поэтому леня делает все правильно
Unix-way - это уже нормальный Unix - *BSD, Solaris и т.д.

Опять некроманты бушуют.

Да что говорить: сам Линус уже не торт ☹

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

Аргументы то есть? У людей просто работает.

Почему не пофигу?

Потому что с этим инструментарием работаю. Начиная от администрирование серверов и домашних десктопов и заканчивая написанием скриптов/юнитов под эти системы инициализации.

P.S. Предпочитаю systemd.