В статье же написано совсем про другое

Ты так искренне удивляешься

Анонимусы начали говорить между собой. Значит, наелись... :-)

скучно просто тебя всё время гавном кормить - иногда хочется с умным человеком пообщаться.

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

То есть, понять про ущербность автоопределения отдельного расположения /usr анонимусы тоже не в состоянии. В общем, потребность общения с себе подобными понятна. Общайтесь. :-)

так, а где ламерчук? как-бы старого «нетрадиционного специалиста» удар с такой новости не хватил, переживаю прямо.

12 страниц. Никогда не понимал отчего такое внимание к systemd?

Да...

... былоб за что.

так, а где ламерчук? как-бы старого «нетрадиционного специалиста» удар с такой новости не хватил, переживаю прямо.

Геолог же, выкопает себе что-нибудь.

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

Объясняю, как ребёнку, в последний раз на пальцах: эта опция не имеет ничего общего с тем, является ли /usr отдельным разделом или нет. Эта опция имеет отношение лишь к тому, перенесены ли бинарники из уровня корня в уровень /usr, независимо от того, является ли последний отдельным разделом или нет.

В статье просто написано «не виноватая я !!». И попытки отвертеться.

И снова бездоказательное утверждение. Где хоть одна аргументированная критика этой статьи?

P. S. Судя по уровню аргументации большинства противников systemd, Леннарту надо было писать не статьи и техническую документацию, а комиксы. (Хотя вопрос о том, а надо ли вообще что-то объяснять таким людям остаётся открытым.)

а! костыли в терминах systemd называются helper-ы!

отчего такое внимание к systemd

потому что он - грубейшее нарушение UNIX-way

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

Секунду, что там с логами? Надеюсь у сисямдэ - циклический (rolling, да?) лог?

ЗЫ раминь!

потому что он - грубейшее нарушение UNIX-way

Как проект GNU, Linux, X11, любой браузер или vim/emacs?

Это лишь точка зрения, которую, как показывает практика, не разделяют дистростроители. Отсюда истерика консервативно настроенных пользователей.

Умеет

На "нет" и...

... суда нет.

Я прямо разбежался читать столько неотфильтрованных страниц.

Я просто не хочу повторяться.

Сообщения ранней стадии загрузки не ограничиваются dmesg.

Увы и ах, но всё что мне хочет сказать ядро, оно может сказать только через printk/vprintk. Альтернатив, кроме libastral нет. Сообщения ранней стадии загрузки могут содержаться во внутреннем буфере ядра, они будут выведены в лог по мере возможности. Но для особо редких случаев ядро конфигурируется с поддержкой earlyprintk:

This is useful for kernel debugging when your machine crashes very early before the console code is initialized. For normal operation it is not recommended because it looks ugly and doesn't cooperate with klogd/syslogd or the X server. You should normally N here, unless you want to debug such a crash.

Да, эту возможность использовать для обычной жизни не рекомендуется. И да, это для случая когда всё крайне плохо. И речи о «стабильной работе» тут и близко не идёт — крэш ядра на самой ранней стадии. Однако я рекомендую обратить внимание на klogd/syslogd. Ни на какие мысли не наталкивает?

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

I/O redirections && logger это решения для... например bash-скриптов. Питонисты ещё этим балуются. Во всех остальных случаях, объяснять программистам, пусть даже полностью и хронически прикладникам, что для них, козлов, сделаны вещи типа syslog.h, Log4j, log4c++, это да, это не смешно. Использование выше означенных вещей избавляет от фантазий на ровном месте и заставляет писать значимую информацию не в какие-то там слегка контуженные текстовые файлы, а в нормальную годами использования отточенную систему протоколирования, которую любой вменяемый «одмин» должен наизусть знать как конфигурировать и анализировать.

Про «общую функциональность». Какую конкретно? До продолжения диспута рекомендую Вам посмотреть как пишутся сервисы в systemd. И, о! Кстати! Рассмотреть случай, когда сервис был написан с ошибкой или не полностью. В качестве второго примера (я в том топике так же уже задавал это вопрос) я рекомендую рассмотреть запуск сетевого демона в OpenRC, например. Вопрос заключается в следующем — будет ли запущен демон и будет ли он обрабатывать входящие соединения, если недописан сервис (файл, определяющий как именно process controlled and supervised by systemd). Успехов.

Не говоря уже об элементарной фильтрации

man syslog's severity levels. Если на уровне записи лога нужно фильтровать что пишем. Если на уровне анализа, то man grep||egrep и, в самых тяжких случаях, man perl. Если система создана для централизации обработки и хранения логов, то поиск по сконвертированным в СУБД логам занимает ровно столько времени (и усилий), сколько их нужно для SELECT по СУБД. Так же ни чего сложного. Если нужна возможно более быстрая реакция на отказ в системе, то в упомянутом топике я уже писал как делается пре-анализ. Повторяться не буду.

всякой дополнительной информации

Какой? Что ещё придумать изволите?

не говоря уже про перенаправление.

Куда именно перенаправление?

В качестве сухого остатка я хочу заметить что Вам, для сравнения технологий было бы не худо предметно ознакомиться с обеими. Применить на практике. Пока от Вас я не вижу ни одного более-менее конкретного (не на уровне «blah-blah-blah») замечания. «Маркетинговый бред» про то, что systemd просто лучше в части протоколирования, не соответствует действительности.

GNU-Is Not UNIX. Да и вся эта устаревшая философия из 80-х уже не нужна никому и мало вписывается в современные реалии.

Фигассе...

... «истерика». Например, вот -> http://patrakov.blogspot.ru/2011/01/writing-systemd-service-files.html Человек проделал работу по конвертации гентушного инитскрипта в service. Рекомендую оценить объём работы.

Проблема решается юнит-тестами и функциональными тестами. Canonical их практикует, кстати, в отличии от разработчиков wayland или kwin.

Правильно гооворить «проблема теоретически решается...».

А практически нет, не решается, к сожалению.

Последние оплоты борьбы с systemd — слакварь, Gentoo и Dragora.

Ну не знаю насчёт генты....

«It is supported in Gentoo as an alternate init system.»

Что-то не понятно?

загрузка шустрее и вообще удобно.

По сравнению с чем и в чем удобство?

это не предел :)

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

А массовый переход на systemd уж очень наглядно показывает, что в мире GNU/Linux имеет значения лишь техническое превосходство.

Недоумкам показали что как они были обычными пользователями на винде, так и в линуксе ими остались. Отсюда и эпический баттхёрт :)

и не платить за неё!

Объясняю, как ребёнку, в последний раз на пальцах

Объясняю, как идиоту, на пальцах. И, тоже, в последний раз.

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

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

Такого выбора вообще не надо было делать. Как и вообще думать о переносе /bin и /sbin в /usr.

А массовый переход на systemd уж очень наглядно показывает,

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

А практически нет, не решается, к сожалению.

То-то для организации БД внутри приложения по дефолту выбирается SQLite, покрытый тестами на 146%. Юнит-тесты, бенчмарки, нагрузочные тесты, стресс-тесты для выявления проблем с многопоточностью, функциональные тесты по заданным сценариям или записанным макросам — всё это в сумме может выявить кучу проблем.

К сожалению, разработка многих системных опенсорсных проектов идёт по принципам RAD, где тестов либо нет, либо объём кода тестов составляет пару процентов общего объёма кода, а не больше половины, как надо бы в идеале.

Молодец он. И да, цитатка:

This simplification occurs because service files specify what should be done, not how it should be done.

Это общий тренд. Декларативность.

Угу...

... «молодец»... Ежли он молодец, так и свинья не красавица. :)

Раньше у меня похапе вызывал рвотный рефлекс, ибо всё через зад. Но, похоже, systemd таки установил новый рекорд. :) Впрочем, скорее всего, будет как с пульсой. Со временем причешут. Но это всё на долго. И это несколько огорчает.

Ну да, жалкий и невежественный народец. В то время как непризнанные гении бьются за объективную и единственную истину на страницах форумов ЛОРа.

Главный баг Systemd - вызов демона срача с наивысшим приоритетом.
«Былинный отказ» всей оси, когда такая програмулька требует такого внимания в написании и продвижении. Это же всего лишь демон инициализации!

«Былинный отказ» всей оси...

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

Пруф можно?

Я просто не хочу повторяться.

Ссылки на нужное сообщение вполне достаточно.

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

Ещё раз: между загрузкой ядра и запуском syslog происходит ещё много что. Где мне посмотреть предупреждения, выдаваемые udev, mount, ifup?

Однако я рекомендую обратить внимание на klogd/syslogd. Ни на какие мысли не наталкивает?

Это наталкивает меня на воспоминания о том, как я в ASPLinux 10 настраивал уровень вывода сообщений ядра на консоль, чтобы ошибки чтения потёртых CD не колбасили интерфейс MC :).

Во всех остальных случаях, объяснять программистам, пусть даже полностью и хронически прикладникам, что для них, козлов, сделаны вещи типа syslog.h, Log4j, log4c++, это да, это не смешно.

Пошли отговорки в стиле «каждая программа должна сама уметь выводить в syslog». Конечно, в идеальном мире так и есть, наверное. В жестокой реальности же возможность направить stderr в журнал вместо /dev/null весьма полезна.

До продолжения диспута рекомендую Вам посмотреть как пишутся сервисы в systemd.

Посмеялся. Ты мне будешь рассказывать, ага :-D.

Вопрос заключается в следующем — будет ли запущен демон и будет ли он обрабатывать входящие соединения, если недописан сервис (файл, определяющий как именно process controlled and supervised by systemd).

Пример недописанного сервиса приведи сначала.

Если на уровне анализа, то man grep||egrep и, в самых тяжких случаях, man perl.

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

Какой? Что ещё придумать изволите?

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

Куда именно перенаправление?

Куда изволите. Вы же начали про I/O redirection.

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

Вы это мне или себе?

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

Угу, собрал раздолбай, а виноват systemd.

Такого выбора вообще не надо было делать. Как и вообще думать о переносе /bin и /sbin в /usr.

Не делать выбора поддержки Fedora, в которой было принято решение о переносе, которое к systemd не имеет прямого отношения?

Ну и начал ты с /usr отдельным разделом, а сейчас уже говоришь о переносе /bin и /sbin в /usr. Дошло наконец, значит, в чём разница.

Вот только аргументированной критики статьи про /usr отдельным разделом я таки не дождался. Не то что бы я надеялся, правда.

Это сильно, они разве не пилили свой вариант?

Ну и начал ты с /usr отдельным разделом, а сейчас уже
говоришь о переносе /bin и /sbin в /usr. Дошло наконец,
значит, в чём разница.

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

Не делать выбора поддержки Fedora, в которой было принято решение о переносе

Это следовало решать другими способами. И проблема переноса - это тоже проблема RH.

Это сильно, они разве не пилили свой вариант?

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

Подозреваю, я это знал до твоего рождения.

Как забавно аська вертится - как ужик на скородке :-D

Можно, разрешаю.

Mark Shuttleworth сделал хитрый ход. Все потуги RH с systemd провалились.

Да с той же убунтой. Вопрос «Где и когда?» посоветую задать поисковой системе по вкусу.

то есть фактов не будет?

Но апстарт - просто система инициализации, и не самая паршивая, кстати. И никто никуда ее не толкал, как происходит сейчас с systemd. Есть суслик - ну и хрен с ним

а разве кто то толкает? каждый дистр сам для себя решает

Red Hat монополизирует мир GNU/Linux, это плохо.

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

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

Поясню, что имею в виду. Шатлврот занимается мошенничеством. Вы слышали что такое черный SEO? А теперь пройдитесь в вики, и почитайте списко «дистрибутивов linux». Там вы найдете и xubuntu, и gubuntu, и lubuntu. Что это такое? Это мошенническая поисковая выдача. Шатвлрот увеличивает свою долю в списке таким вот подлым методом. Как он еще не додумался пилить «форки» на основании различных обоев? Хотя этим и без него нашлось кому заняться. Так же мы видим, что крайняя агрессивность пропаганды бубунты выражается и в коньке ее рекламной компании: она подается не больше и не меньше, как «единственная альтернатива windows в мире linux». - Такой дословно формулировки вы нигде не встретите. Но смысловая нагрузка именно такова. Остальные дистрибутивы «подразумеваются» как сложные для осовоения и недружественные.

Другими словами, шатлврот с одной стороны ПАРАЗИТИРУЕТ на чужих наработках в мире линукс, позволяющим его дистирбутиву (как и многим другим) считаться десктопным, и позиционироваться как юзерофильный, но при этом он ЭКСПЛУАТИРУЕТ и поощряет давно устаревшие стереотипы о том, что линукс-де остается такой же осью для гиков, как и 25 лет назад, и только одна бубунта, - на переднем краю прогресса.

Возвращаясь к благославенному делу Поттера. Стандартизация же технологий как бы ничего плохого не обещает. Уже кто-то пытался на Xfree86 в рай выехать, сделав его несколько менее свободным. Мы помним, что из этого вышло.

в чем глупость? у меня тоже самое и что?

Стандартизация же технологий как бы

Вот эти «как бы» - сразу говорят о том что ты выродок, ты не можешь изъясняться четко и по делу, так что вали-ка ты нахуй :) В формировании стандартов в нормальном мире участвуют десятки заинтересованных компаний, RH единолично решает что будет стандартом в Linux - вот это самое хреновое в этой истории, фактически RH это уже второй MS. А Марк никому ничего не навязывает.

RH единолично решает что будет стандартом в Linux

Бред сивого анонимуса. Не приняли бы дистростроители systemd, никуда бы он продвинулся. Вот тебе и десятки заинтересованных компаний, некоторые - весьма коммерческие.

Когда systemd, наконец, встроят в Debian и Ubuntu о нём все дружно забудут и от нынешнего батхёрта останутся только эти 12 страниц срача...

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

Польщен. Белое каление ануса говорит о том, что мои слова проникли в глубины твоего сердца. Высшая похвала, предельная оценка внятности и доступности ^_^

RH единолично решает что будет стандартом в Linux - вот это самое хреновое в этой истории, фактически RH это уже второй MS. А Марк никому ничего не навязывает.

На эти «навязанные» стандарты, - очень много судей. И судей достаточно... Паргматичных. И мнения их достаточно объективны.

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

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

Разуемеется, он не рискует ни в коем случае столкнуться с тем явлением, что я назвал «имунитетом». Напротив, усиленно избегает обнаружения своих намерений и целей.

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

Не приняли бы дистростроители systemd, никуда бы он продвинулся.

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

Ты когда-нибудь пробовал формировать новую моду, или новые стандартны?

Нет - давай тебя послушаю, ты же у нас ко-ко шинель :)