Из состава минималистичного набора стандартных unix-утилит BusyBox исключён (http://git.busybox.net/busybox/commit/?id=accd9eeb719916da97...) код для обеспечения поддержки системного менеджера systemd. Изменения внесены Денисом Власенко (http://busybox.net/~vda/resume/denys_vlasenko.htm), мэйнтейнером проекта. В комментарии к коммиту указано, что разработчики systemd не идут на взаимодействие с остальным миром, поэтому остальной мир не имеет оснований для продолжения работы с разработчиками systemd.
URL: https://www.reddit.com/r/linux/comments/3qvchs/busybox_remov.../
Новость: http://www.opennet.me/opennews/art.shtml?num=43229
Молоцы!
Поттеринг ещё не написал в G+ слезливый пост, какие все в сообществе злые и плохие? А то он любитель.
Ленарт все правильно пишет, он один из лучших программистов который двигает и развивает опенсорс остальные только ноют и тянут одеяло на себя.
Ты подсчитывал вклад каждого OS программиста, или просто смотрел кто больше языком треплет?
Он сверх инициативный идиот. Никто ещё не нанёс "опенсорсу" такого урона как он.
Урон опенсорсу - ты подсчитываешь в количестве подopванныx пyкaнoв? Какое они отношение имеют к опенсорсу кроме потpeб лядcтвa? Выгоду от системд получили те, на кого она была ориентирована - мейнтейнеры дистрибутивов. Остальные ныли за компанию, поскольку не имели собственного мнения.
Леонид, залогиньтесь.
Он идиот, который выскомерно клал на всех, %username%. И даже на Торвальдса пробовал, но был послан. Все помнят параметр debug?
Не смеши. Есть люди, сделавшие гораздо больший вклад в твой опенсорс. Но мы о них не знаем, по причине того, что другим они не мешают.
> Ленарт все правильно пишет, он один из лучших программистовСлышали про такого Ули Дреппера? А он неплохой программист, между прочим. Только нарцисс и социопат ещё покруче молодого Леннарта.
Это который бывший мейнтейнер glibc? Кто ж его не знает. И тоже RedHat, кстати. ))
Был RH. И чувак, тем не менее, технически вполне адекватный, в отличие от.
>> Ленарт все правильно пишет, он один из лучших программистов
> Слышали про такого Ули Дреппера? А он неплохой программист, между прочим.
> Только нарцисс и социопат ещё покруче молодого Леннарта.Вы ещё старину Ганса Рейзера вспомните
Для Вас, Михаил, он Ульрих.
> Для Вас, Михаил, он Ульрих.Для меня он вообще-то Дреппер.
Так толсто что уже тонко! :)))
двигает, и сильно. только вот направление движения нравится не всем.
Зачем ему писать такой пост? Я думаю, он прагматик, и понимает, что если люди просто не хотят - они не пользуются его поделкой. В отличие от многих других, фанатиков и хейтеров. Долгой леты, BusyBox! Конкуренция рулит. А Дебиан - слабаки
Ага - вон в Debian не хотели ... так их раком поставили и systemd таки ввели :)
Busybox-ы увидев такое - сразу же и явно положили в джинсы сковородку :)))Правда надолго их это не спасёт :( Красношляпы до-давят ...
>их раком поставили и systemd таки ввелиПруф можно? А то ты выглядишь озабоченным в противном случае.
>>их раком поставили и systemd таки ввели
> Пруф можно? А то ты выглядишь озабоченным в противном случае.любитель homevideo?
Голосовали до тех пор пока не проголосовали правильно.
Это нашенские знаменитые 146% кроет как динозавр птенчика :-\
> Долгой леты, BusyBox! Конкуренция рулит. А Дебиан - слабакикакой ещё долгой?
не делать совместимость с мэйнстримом -- быстро загонит BusyBox в список исторических программ.
initramfs уже варят без BusyBox. из других мест (гаджеты?) BusyBox тоже исчезнет.
отключили сокет-активацию: http://git.busybox.net/busybox/commit/?id=accd9eeb719916da97...
ну просто сами себе в тапки насрали -- так как системе systemd хуже от этого не станет -- а вот busybox-syslogd уже потеряет в количестве своих фишек (в случае работы поверх systemd) :)
> initramfs уже делают без BusyBox. из других мест (гаджеты?) тоже исчезнет.А я вот делаю десктопы с busybox и без initramfs ;)
> ну просто сами себе в тапки насрали -- так как системе systemd
> хуже от этого не станет -- а вот syslogd уже потеряет
> в количестве своих фишек (работая поверх systemd) :)Вообще изначально было не понятно - зачем какая либо интеграция busybox и systemd: выбирающие busybox не будут использовать systemd и наоборот.
> Поттеринг ещё не написал в G+ слезливый пост, какие все в сообществе злые и плохие? А то он любитель.Ему некогда, он запиливает для systemd новый модуль - busyboxd.
> Ему некогда, он запиливает для systemd новый модуль - busyboxd.Пока она пишет, за него может Кай попилить. =)
Блин, что-то мне уведомления на мыло об ответах на мой коммент не приходят. =(
Интересно, что же всё-таки не поделили?
На Реддите написали, что там разрабы - известные хейтеры.
Ты так говоришь как будто слово хейтер не является пустым обзывательством, а что-то реально объясняет. Может это Поттеринг хейтер?
В нашем случае хейтер получаешься ты. И хейтер не обзывательство, а лишь сухая констатация.
> В нашем случае хейтер получаешься ты.
> И хейтер не обзывательство, а лишь сухая констатация.Констатируем: пришёл безымянный и, возненавидев человека, безосновательно назвал его хейтером.
Вас зеркалом лечить надо, небольные.
> безосновательноБезосновательной была лишь демагогия в посте, дорогие мои резонеры.
И да, слово хейтер не является пустым обзывательством, а что-то реально объясняет.
* в том посте
https://www.reddit.com/r/linux/comments/3qvchs/busybox_remov...
> Hardly a surprising move since several busybox developers really, really hate systemd.Это крутой источник, да!
А вот на https://bugs.freedesktop.org/show_bug.cgi?id=76935#c24
> Linus explained it well already:
> Kay and Lennart: please just go away, disappear from the FOSS community,
> we don't need you and your crap.Что фанаты теперь-то делать будут?
Кстати: вы хейтер кед или гнома, дебиана или федоры? Ведь если не пользуешься чем-то, то значит, почти наверняка ненавидишь!
>Ведь если не пользуешься чем-то, то значит, почти наверняка ненавидишь!Так я получается вообще хейтер тех миллионов программ, которые у меня не установлены. //Откинулся на стул по грузом своей значимости.
> И хейтер не обзывательство, а лишь сухая констатация.Чистой воды коннотационная калька. Без определения, без смысла, без ценности.
А если на Реддите напишут, что ты дурак?
> На Реддите написали, что там разрабы - известные хейтеры.звучит как "на заборе написали"
> Интересно, что же всё-таки не поделили?Деньги. О чём бы ни шла речь - она всегда о деньгах.
>> Интересно, что же всё-таки не поделили?
> Деньги. О чём бы ни шла речь - она всегда о деньгах.Когда я был в твоём возрасте поговорка звучала как: ... * всегда о бабах!
Не туда мир поехал :(
Ну вот хотя бы какие то разработчики поняли что системд не нужно :-)Главное, чтоб то же самое поняли еще почти все. Или многие во всяком случае
> Ну вот хотя бы какие то разработчики поняли что системд не нужно
> :-)
> Главное, чтоб то же самое поняли еще почти все. Или многие во
> всяком случае"а сегодня в завтрашний день не все могут смотреть... Вернее смотреть могут не только лишь все, мало кто может это делать" (С) квв
азазаза, ты сделал мой день )
А я то же самое слышал от одного спортсмена. Тоже опеннет читает, наверное.
> А я то же самое слышал от одного спортсмена.Все от него слышали. Этож теперь в форсунках! Боксёр жгЁтьЪ ! :)))
все от него слышали, но вернее, слышать могли не только лишь все, мало кто мог это сделать.
"systemd people are not willing to play nice with the rest of the world."Оказывается, бизибокс — зэ рест оф зэ ворлд. Вот оно как.
Тем временем, на Reddit в контексте этой новости пишут:
"Actually the embedded market are increasingly using systemd: from Jolla smartphones to Samsung smartv's. More or less the entire car industry (IVI) are backing systemd and kdbus too for their embedded systems too."
Привет обиженкам из бизибокса, чо.
да ну? вот openwrt и куча сего основного на нем - не пытается даже использовать systemd..
>openwrt и куча сего основного на немну-ну :D што именно? лол
> ну-ну :D што именно? лолFON
https://corp.fon.com/en
https://maps.fon.com/mapContent?zm=1freifunk
http://www.freifunk-karte.de/не, не слышал ...
они запилили альтернативу systemd что еще надо для счастья.
Если посчитать, то как раз таки Поттеринг и является "остальным" миром для основной линуксовой install-base. А там systemd ненужен от слова совсем.KDBUS это конечно замечательно, только вот к busybox ни малейшего отношения не имеет.
> KDBUS это конечно замечательноВы-таки не слышали??
прокудин, толсто же
твой пост полон обиды фаната за свой фетиш
раньше были дистрофаны, и тулкитофобы, теперь к ним добавились инитодрочеры
> твой пост полон обиды фаната за свой фетишСкажу по большому секрету, только вам персонально: мне глубоко пофиг, что у меня грузит систему. Жил на инитскриптах в альте, жил на апстарте в убунте, проживу как-нибудь и на системд в федоре. А вы страдайте, страдайте за правду. Страданиями душа очищается :)
Пришло время переустановить федору. Федора сама не переустановится.
А зачем её переустанавливать?
Хотя б затем, что с 20 на 22 она может и не обновиться толком. И возможная причина будет как раз в systemd, точнее в его куске — logind.
> Хотя б затем, что с 20 на 22 она может и не
> обновиться толком. И возможная причина будет как раз в systemd, точнее
> в его куске — logind.А с 20 на 21, а затем - на 22?
Не пробовал.
Обычно Федора более-менее сносно обновляется через версию, иногда в полуавтоматическом режиме — с пинками и матом, но обновляется. Но иногда изменений настолько много, а обновление протестировано натолько плохо, что проще переустановить систему, чем выяснять, что и как там обновилось.
К тому же я обычно клонирую систему с диска на диск, а уж потом обновляю, т.е. рабочая система всегда есть. Вот клон до 22-й обновился неудачно, пожал плечами, прибил и установил свежую систему на купленную по случаю ssd-шку.
А вы максимальную тоже накатываете начиная с 2000й?
Ну может с 20 на 22 и возникнут проблемы, но если идти последовательно, то федора прекрасно обновляется. Я без проблем обновляю уже с 16 до 22.
> А зачем её переустанавливать?Это троллинг на тему 12309
Ставь роллинг-релиз.
Если тебе глубоко пофиг тогда какого черта ты имеешь наглость высказывать тут по этому поводу свое запредельно ценное мнение? Нам не пофиг - systemd должен умереть!
> Если тебе глубоко пофиг тогда какого черта ты имеешь наглость высказывать тут по этому поводуЧтобы у вас, фриков, вот так адово бомбило. Зачем же ещё? :)
>Чтобы у вас, фриков, вот так адово бомбило. Зачем же ещё? :)Если ты в таком возрасте тратишь время чтобы у кого то бомбило, то у меня для тебя плохие новости сынок! Походу ты просто моральный уродец
Вообще-то это была шутка. А так — да, не вижу ничего дурного в том, чтобы немного позлить хейтеров. Иначе они будут думать, что энторнеты принадлежат исключительно им, а все остальные должны заткнуться и свалить куда-нибудь.
По-вашему сообществу СПО не хватает озлобленных хейтеров?
> По-вашему сообществу СПО не хватает озлобленных хейтеров?Не мне судить.
> Чтобы у вас, фриков, вот так адово бомбило. Зачем же ещё? :)Хе-хе-хе. Между прочим, Фрик -- это я. И меня твоё мнение, знаешь ли, ни чуточки не волнует. Однако ты прав, лишать тебя права высказать своё мнение не может никто. Как и нам никто не может запретить считать твоё мнение не правильным. Тебя просто обманули, и systemd есть будущий вендор-лок, от которого сообщество разработчиков СПО может не скоро оправиться. Вполне возможно, что когда эта простая истина дойдёт до сообщества поклонников Поттеринга, ты, как человек адекватный и дальновидный, будешь одним из первых в рядах борцов за справедливость. А пока, ты можешь просто принять к сведенью, что есть на твой горячо любимый инит и другая точка зрения, и другое понимание вопроса.
> раньше были дистрофаны, и тулкитофобы, теперь к ним добавились инитодрочерыРаньше всего были редакторофанатики.
(Кстати, имэкс и вим — одно и то же фуфло. Юзайте акмэ, сэм или хотя бы эд.)
> акмэ, сэмудивительной неудобности редакторы: всё время дёргать руку с клавиатуры на мышь — это только Пайк мог так пошутить.
>> акмэ, сэм
> удивительной неудобности редакторы: всё время дёргать руку с клавиатуры на мышь —
> это только Пайк мог так пошутить.он на этом не остановился, и приложил руку к Go.
да, поразительной жирности трололо.
Пора бы уж открыть для себя trackpoint.
> Пора бы уж открыть для себя trackpoint.пора бы уже избавиться от идеи, что я должен под технику подстраиваться, а не техника под меня. этим вашим трэкпоинтом в Brutal DooM играть неудобно.
Разным задачам - разные инструменты.
> Разным задачам - разные инструменты.ну, если серьёзно, то ни мышь, ни её заменители всё равно не катят: клавиатурное управление при редактировании удобней. во‐первых, руки *уже* на клавиатуре, а во‐вторых, щёлкать по кнопкам указателем мыши вслепую не очень удобно.
так что идея «все команды редактора выносим во внешний софт» — она интересная. а реализация с мышью — неинтересная.
> во‐первых, руки *уже* на клавиатуреМне опять кажется что трекпойнт вам стоило бы для себя открыть. При его использовании руки с клавиатуры убирать не нужно.
пальцы двигать нужно. я тут несколько неверно выразился — имел в виду: «на кнопках с буквами».
Пальцы и так двигаются. Над кнопками с буквами. Что с трекпойнтом, что без - в этом смысле разницы никакой.
разница огромная. другие движения, другие усилия, сбой ритма, ужас и ненависть.
Что интересно, на многих источниках и в комментариях(например на хабре) часто мелькает, что в среднем программист в день пишет ~150 строк кода. А такой холивар по оптимизации процесса ввода текста.
Ну офигеть embedded: восьмиядерные процессоры, мощные графические ускорители, гигабайты оперативки. Мой первый десктоп был в разы слабее. Конечно туда можно хоть десять systemd запихнуть. А вот там где каждая сотня килобайт на счёту, где как раз и используется BusyBox, никто в здравом уме не будет использовать systemd.
А есть ещё и мирное сосуществование BusyBox'а и systemd в современных embedded: BusyBox живёт в initrd и в recovery, а сама система запускается с помощью systemd. И тут дело не в мощности процессора, а в маленьком boot-разделе, куда полноценные утилиты могут и не влезть.
Ясен пень, после проталкивания UsrMove исчезла возможность восстановить систему штатными средствами. Вот и приходится бедным нехейтерам всякие левые костыли прикручивать.
Хотел бы я посмотреть на тех наркоманов что в ембедеде отдельный /usr делали.
Android? Конечно не совсем /usr и не совсем embedded, но все же.
>Хотел бы я посмотреть на тех наркоманов что в ембедеде отдельный /usr делали.Не знаю про ембедедед, но наркоманы, ставящие busybox на дексктоп, в этом треде имеются. А всё как раз из-за невозможности сделать отдельный загрузочный отдел с systemd.
embedded market это далеко не только Jolla/Samsung. Телефоны это уже почти полноценные компьютеры, а embedded может быть на каком-нибудь 8-битном AVR и свои задачи оно вполне решает. Правда там и busybox тоже не будет, просто забавны эти размышления про systemd и embedded.
> Тем временем, на Reddit в контексте этой новости пишут:так там такой же пенек с глазками как ты напИсал
> from Jolla smartphones to Samsung smartv's
теперь прикинь - сколько десятых процента эти устройства составляют по сравнению с андроедными
> More or less the entire car industry (IVI)
бгг, там вообще QNX доминирует
>> More or less the entire car industry (IVI)
> бгг, там вообще QNX доминируетЭто по данным какого года? В мультимедийных системах автомобилей (In Vehicle Infotainment) чего сейчас только ни встретишь. Покажите мне тех, кто, например, видео на встроенном телевизоре на QNX крутит.
>>> More or less the entire car industry (IVI)
>> бгг, там вообще QNX доминирует
> Это по данным какого года? В мультимедийных системах автомобилей (In Vehicle Infotainment)
> чего сейчас только ни встретишь. Покажите мне тех, кто, например, видео
> на встроенном телевизоре на QNX крутит.дададад, дримлайнер тож на линупсе летает - там пассажирские кресла с ембеддед андроидом.
Да уж точно не на FreeBDSM :)
ахаха
> Это по данным какого года?Например 2013
http://linuxgizmos.com/linux-based-in-vehicle-infotainment-o.../
> чего сейчас только ни встретишь
в лучшем случае ~20% на линуксе
> видео на встроенном телевизоре
патефоны еще забыли
> в лучшем случае ~20% на линуксеЭто, всё-таки, уже не десятые процента. И, я думаю, доля линукса будет только расти. Вместо того, чтобы тратить многие годы на написание компактного кода уже гораздо дешевле поставить процессор помощнее, и использовать линукс (GNU/Linux для принципиальных). Что такое стоимость ARM'овского SoC'а по сравнению со стоимостью авто?
Да!
>Actually the embedded market are increasingly using systemd: from Jolla smartphones to Samsung smartv's.My dick is so big if I put it on the keyboard it goes from A to Z!
реддит, етот баш современности
(посмотрел на клавиатуру, задумался)
> (посмотрел на клавиатуру, задумался)тонкая ирония про размер рынка Jolla+Tizen
> (посмотрел на клавиатуру, задумался)Возможно, у него dvorak
малю-ю-ю-ю-сенькое такое примечаньице: из фразы> "systemd people are not willing to play nice with the rest of the world."
вовсе не следует что
> бизибокс — зэ рест оф зэ ворлд.
С чего вы взяли что они под "рест оф зе ворлд" имели ввиду только исключительно себя?
Даже безотносительно к "systemd people", busybox и прочему подобному: лично я вполне понимаю людей, которые не хотят иметь дела с теми кто откровенно гадит на других, даже если на них лично никто [ещё пока] не гадил.
> малю-ю-ю-ю-сенькое такое примечаньице: из фразы
>> "systemd people are not willing to play nice with the rest of the world."
> вовсе не следует что
>> бизибокс — зэ рест оф зэ ворлд.
> С чего вы взяли что они под "рест оф зе ворлд" имели
> ввиду только исключительно себя?The rest of the world не давал автору патча права говорить за других. У Власенко нет бумажки, где написано, что он может от лица других нести всякую отсебятину. Если б он был порядочным человеком, он бы написал что-то типа «Системд нам не подходит по техническим соображениям, поэтому мы выкидываем его поддержку». Вместо этого он повёл себя как истеричка с раздутым ЧСВ.
>[оверквотинг удален]
>> вовсе не следует что
>>> бизибокс — зэ рест оф зэ ворлд.
>> С чего вы взяли что они под "рест оф зе ворлд" имели
>> ввиду только исключительно себя?
> The rest of the world не давал автору патча права говорить за
> других. У Власенко нет бумажки, где написано, что он может от
> лица других нести всякую отсебятину. Если б он был порядочным человеком,
> он бы написал что-то типа «Системд нам не подходит по техническим
> соображениям, поэтому мы выкидываем его поддержку». Вместо этого он повёл себя
> как истеричка с раздутым ЧСВ.Что то уж Вы слишком категоричны. Вам бы с "Терминаторами" со "сдутым" ЧСВ работать. И как Вы резко человека из порядочных в безпорядочные перевели. Может Вы думаете, Вы так ему помогли?
Кто такие «терминаторы» и почему у них сдуто ЧСВ?
> Кто такие «терминаторы» и почему у них сдуто ЧСВ?Терминаторы - это такие роботы, созданные человеком разумным. Для чего они созданы, это отдельный вопрос. А сдуто ЧСВ у них, для того что бы они своим раздутим ЧСВ не придавили своих создателей.
Это все шуточки ;) Но в каждой шутке, ...
> Это все шуточки ;) Но в каждой шутке, ...Извините, но я не вижу никакой связи между терминаторами и раздутым ЧСВ у Власенко, который взялся говорить за «весь остальной мир».
>> Это все шуточки ;) Но в каждой шутке, ...
> Извините, но я не вижу никакой связи между терминаторами и раздутым ЧСВ
> у Власенко, который взялся говорить за «весь остальной мир».Прошу прощения, что отвлек Вас от ваших мыслей. И давайте действительно, оставим в покое теминатовров, Власенко и весь остальной мир. Тем более, что между ними "уж точно" нет никакой связи ;) Да и наверняка, они все вместе и по отдельности посмотрят на меня как на... (то есть с большим недоумением, чего это я без оплаты решил взятся за их обучение ;)
> Тем временем, на Reddit в контексте этой новости пишутВы такие смешные, если сайт на английском, то это сразу же авторитетный источник. А там ведь такие же клоуны как и в Толксах сидят. А иногда это даже одни и те же люди.
> Оказывается, бизибокс — зэ рест оф зэ ворлд. Вот оно как.Ты ещё замечаешь, когда передёргиваешь, или уже нет?
> Ты ещё замечаешь, когда передёргиваешь, или уже нет?Это ты, Миша, передёргиваешь. А у меня подруга есть.
>> Ты ещё замечаешь, когда передёргиваешь, или уже нет?
> Это ты, Миша, передёргиваешь. А у меня подруга есть.видать хреновая подруга, раз переклинивает
>> Ты ещё замечаешь, когда передёргиваешь, или уже нет?
> Это ты, Миша, передёргиваешь. А у меня подруга есть.Сегодня правая? Или незнакомка -- левая?
>> Ты ещё замечаешь, когда передёргиваешь, или уже нет?
> Это ты, Миша, передёргиваешь.То есть уже не лечится.
Саш, пошёл-ка в.
Забанил его?
Мне вот лично наплевать на срач systemd vs rest_of_the_world. Вот есть проект, пусть кто-то считает его плохим, кто-то иначе. И пока разработчики пилят в этом проекте все что хотят, получают какое-то финансирование и интерес со стороны определенных проектов, другие исходятся на дерьмо, причем жидко, с пеной у рта доказывают что проект ... что?
1. Технически плох? Если это так, то с этими доводами вам лучше к меинтейнеру вашего дистрибутива пойти.
2. Не поддерживает религиозные концепции unix? Тогда надо к Батюшке.
3. Заговор. Его пропихивают везде при помощи бабла корпорации? Тогда к психиатру.
...
Гетзефактсы, короче, очередные. Пофигу.
Но вот главный вопрос: что мешает оппонентам проекта сохранять лицо, что мешает им быть цивилизованными людьми? Я вот Вас спрашиваю, Михаил!
А что он там вообще поддерживал?
Вся поддержка сводится к сокетной активации syslogd. И всё.
Так что остаётся непонятным, что там можно было не поделить.
Оному Денису Власенко таблеточек бы от мании величия, что бы больше не выдавал себя за весь мир.
> Оному Денису Власенко таблеточек бы от мании величия, что бы больше не
> выдавал себя за весь мир.это можно только поттерингу?
> Оному Денису Власенко таблеточек бы от мании величия, что бы больше не
> выдавал себя за весь мир.Неа, в твоем случае клизьмование должно помочь
> Оному Денису Власенко таблеточек бы от мании величия, что бы больше не
> выдавал себя за весь мир.отсюда: http://busybox.net/~vda/resume/denys_vlasenko.htm
01/2008 - present: Red Hat Czech Republic
Senior Software EngineerПолучается они с Поттерингом в одной компании работают?
> Оному Денису Власенко таблеточек бы от мании величия, что бы больше не
> выдавал себя за Леннарта Великого и Единственного.не благодари
И так "остальной мир" узнал о существовании BusyBox?
> И так "остальной мир" узнал о существовании BusyBox?Остальной-то мир давно знал о BusyBox'е, но так делать некрасиво.
> Остальной-то мир давно знал о BusyBox'е, но так делать некрасиво.значит есть причины
Так огласите.
> но так делать некрасивону кто же виноват, что лёня — мурло с расчёсаным чсв?
Интересно, что ему начальство на это скажет. ;-)
может, его не отпускают, вот он и затеял небольшую провокацию чтобы ускорить процесс ухода
Да-а. Такая трагедия, целую одну(!) функцию выкинули.
Я думал этот трэд будет захвачен радостно потирающими руки хейтерами ))
> Я думал этот трэд будет захвачен радостно потирающими руки хейтерами ))Та ну, ну какие из инитодрочеров хейтеры?
Ну правильно, этот тред вскрыл множество бусибоксо-хейторов, которые только критиковать могут, а сами в жизни не строчки кода не написали, но уже мнят себя экспертами.
А бусибоксо-хейтеры могут и дальше ныть, лаять, визжать и истерить, но профессионалы приняли решение и на хейтеров которые сами ни на что не способны им плевать.
Хм, так недолга (sic!) и до форка.
toybox, toolbox
tinybox
Отлично!
Все правильно сделали.
Выкинули поддержку этого "не нужно".С другой стороны теперь поцтеринга вроде и не обвинить - зачем он будет в свой адский комбайн запиливать замену :)))
Крипота :)
До кучи:
KDBUS Is Being Removed From Fedora, Could Be A While Before Being MainlinedWith now coming to the point of re-thinking some design decisions, it's good that it didn't land as originally planned for Linux 4.1 and it hasn't ended up being proposed since then.
http://www.phoronix.com/scan.php?page=news_item&px=Fedora-Dr...
Поэкспериментировали в Rawhide и обнаружили лажу. Пользовательские ветки тут не при чём!
> Поэкспериментировали в Rawhide и обнаружили лажу.Нет. Лажу обнаружил Линус, когда ЭТО попытались влить в основную ветку ядра.
> Нет. Лажу обнаружил Линус, когда ЭТО попытались влить в основную ветку ядра.Самое забавное, что после трех неудачных попыток пропихнуть kdbus в ядро, разработчики удивили таки "фатальный недостаток" и возрадовались, что у них не получилось пропихнуть первоначальный вариант и есть возможность провести полноценный redesign.
пройдутся sed'ом по исходникам?
"нашла, дура, чем гордиться" // анекдот
Вы просто поймите что один из аргументов в пользу преимущества systemd является развитая многопоточность. Но дело в том, что сегодня все процессоры уже на физическом уровне многоядерные и каждое ядро поддерживает HT!!! Производители процессоров и сторонние разрабы уже предлагают варианты библиотек которые отслеживают многопоточность и объединяют лишние потоки в один!!! Простую вещь уясните и тогда у вас наступит мир и покой!
> Вы просто поймите что один из аргументов в пользу преимущества systemd является
> развитая многопоточность. Но дело в том, что сегодня все процессоры уже
> на физическом уровне многоядерные и каждое ядро поддерживает HT!!! Производители процессоров
> и сторонние разрабы уже предлагают варианты библиотек которые отслеживают многопоточность
> и объединяют лишние потоки в один!!! Простую вещь уясните и тогда
> у вас наступит мир и покой!иногда лучше жевать - это твой случай
>> Вы просто поймите что один из аргументов в пользу преимущества systemd является
>> развитая многопоточность.
> иногда лучше жевать - это твой случайСтоит пояснять, почему: человек не в состоянии понять разницу между наличием ресурсов и их потреблением различными компонентами итоговой системы.
Автор #55, у нас в детстве было такое страшное проклятие -- "шоб ты в туалет по компасу ходил". Так вот, наличие в доме компаса к этому не обязывает.
А вместо повторения того, что не понимаете _вообще_, лучше книжки умные почитайте да сами попробуйте что-нить хоть маленькое, но полезное изобразить.
Какая разница, сколько ядер в процессоре, если софтина написана без учета многопоточности? Эта конкретная софтина выгоды от многоядерности процессора не получит. Операционная система в целом - получит, поскольку сможет раскидать разные процессы по ядрам. Пойми это. Впрочем, у меня подозрение, что ты троллишь. На опеннете этой публики отчего-то особенно много.
> На опеннете этой публики отчего-то особенно много.Очевидно же почему - нет барьера в виде регистрации.
>> На опеннете этой публики отчего-то особенно много.
> Очевидно же почему - нет барьера в виде регистрации.барьер так барьер.
Если софтина написана и скомпилирована без соответствующих библиотек, то многоядерные процессоры с HT на себя берут заботу о распределении вычислительных ресурсов. Другой вопрос в том что современные софт в котором слишком активно используют многопоточность сам себе вредит тем что на управление этими многочисленными потоками процессор тратит много вычеслительных ресурсов! Т.е. чем больше потоков, тем больше процессор тратит на них свои драгоценные ресурсы.
Если это не троллинг, то вы глубоко заблуждаетесь. Процессор с HT не может сам распараллелить задачу. Наоборот: для полной загрузки одного ядра процессора с HT нужно минимум два потока.
Может мне надо освежить инфу в этой сфере. Был уверен что я прав.
Суть HT - одно реальное ядро для системы выглядит как два виртуальных. Что бы полностью нагрузить такой процессор, нужно дать нагрузку на все виртуальные ядра.Процессоры с HT имеют очень длинный конвейер (много блоков передающих информацию друг другу последовательно) и если их нагружать в один поток, то часть блоков процессора будет просто простаивать, ожидая завершения работы всего конвейера. Чтобы это исключить, на освободившихся блоках начинается запуск второго потока еще до окончания работы всего конвейера.
https://ru.wikipedia.org/wiki/Hyper-threading
http://www.thg.ru/cpu/intel_core_i7-980x_hyper-threadng/onep...
http://habrahabr.ru/post/182002/
> Вы просто поймите что один из аргументов в пользу преимущества systemd
> и сторонние разрабы уже предлагают варианты библиотек которые отслеживают многопоточность
> у вас наступит мир и покой!Прочитай техническое описание http://blog.darknedgy.net/technology/2015/10/11/0/ потрохов system-d. Обязательно целиком -- это ПРОСТО! И уясни, что тебя кто-то обманул. Учительница Марьванна в школе, наверное.
выдыхай, бобёр!
Истерички.
Ты просто хейтер. Они профессионалы и знают что делают. А ты только критиковать можешь, сначала сделай что-то своё, жалкий ничтожный хейтер.
Уровень 5-Б класса. Ты хоть поинтересовался, может он сделал в 100500 раз больше чем ты и "профессионалы"?
> Уровень 5-Б класса. Ты хоть поинтересовался, может он сделал в 100500 раз
> больше чем ты и "профессионалы"?Я не помню, чтоб персонаж с ником Fracta1L хоть раз показывал свой код. И, судя по остальным его комментариям, вряд ли это изменится -- соотношение безграмотность/самомнение зашкаливает :(
>> не идут на взаимодействие с остальным миромЭто BusyBox остальной мир? Да этот Власенко обладает немерянным ЧСВ
Кончай истерить, хейтер.
Хейтер чего? Ты нормальный? Хотя судя по всему, нет. И ты часом не Власенко?
Ты сейчас свой голос в голове допросил?
Тред заполнили бусибоксо-хейтеры.
Слыш, хейтеры, презде чем критиковать решения команды бусибокса, сперва-добейтесь того же чего они. Напишите сначала хотя бы один набор стандартных unix-утилит, а потом кукарекайте.
Критиковать то все горазды, сначала сделайте что-то своё.
Я полностью поддерживаю решение разботчиков бусибокса, они профессионалы и знают что делают, а хейтеры-поттерингоманы пусть дальше лают и визжат.
Ну почему сразу хейтеры. ИМХО, любое такое решение, мотивированное политическими, а не техническими причинами -- не есть гуд.А так получается -- "смотрите, как я ненавижу systemd" -- "апплодисменты opennetа". Кому этот код мешал -- не ясно.
Сначала сделай свой системд, а потом выкидывай его поддержу. Умник.
Сначала выкинь поддержку системд, а потом запили свой. Дятел.
> Слыш, хейтеры, презде чем критиковать решения команды бусибокса, сперва-добейтесь
> того же чего они. Напишите сначала хотя бы один набор стандартных unix-утилитНе-не, не так. Хотя бы один набор стандартных утилит, разошедшийся тиражом для начала пусть в полмиллиона экземпляров.
А так да, кто к нам с чем -- тот от того и того. :}
> кто к нам с чем -- тот от того и тогоКто к нам с чем _зачем_ — тот от того и того. )
> сперва-добейтесь того
> кукарекайте.
> хейтеры-поттерингоманы пусть дальше лают и визжат.Уже привычный непревзодённо высокий уровень аргументации на опеннете.
Сашеньки то видней. Он здесь то логичные, железные аргументы выкладывает, то код по которому можно учиться, то утилиты которые с радостью во все дистры разбирают. Не человек а просто светоч мысли.
Это ты про передёргивание и наличие подруги, аргументатор доморощенный?
> Это ты про передёргиваниеИ про него тоже.
детский сад
> детский садДа! Лёнок такой пупсичек. И вокруг него столько розовощёких карасав. И во главе этой песочнницы Марьванна Кроа-Хартман переписывает кдбас-барабас, обливается горючими и переписывает, и переписывает.
Каждый считает себя центром мира. Как банально.
Ничтяк!!! Респект и уважуха парням!
Денис Власенко ты молоток! Терпения тебе! Поверь systemd ненавидит огромное количество народу! Надеюсь мы доживем до человеческой альтернативы этой поделки!
> Денис Власенко ты молоток! Терпения тебе! Поверь systemd ненавидит огромное количество
> народу! Надеюсь мы доживем до человеческой альтернативы этой поделки!У психиатра давно были?
Удалили аж целых 76 строк кода! Те, кому по какой-то невероятной причине нужна поддержка связки busybox+systemd ни за что не смогут вернуть этот функционал самостоятельно!
Это было с самого начала разработки системд. Людям пожелавшим участвовать в разработке указали на дверь: «это наша корова, и мы её доим».Мне не нравится действия красношапки. Значит как получить кучу тестеров, так включила нужных людей. А как сотрудничать, так сил нет, желания нет, причины всякие появляются у разрабов. Ну, их право. В конце концов, если сообщество станет самостоятельнее, децентрализованнее от влияния отдельных личностей, самоорганизованнее, то даже в плюс.
Плюс systemd хотя бы в том, что он позволил раскачать болото и усилить конкуренцию. Я не думаю, что производители наиболее известных дистрибутивов полные идиоты, и будут цепляться за systemd, если будет альтернатива лучше.Вместо того, чтобы просто критиковать, не устраивает systemd -- взяли, и написали свой. Github бесплатный. (Ну, или присоединились к конкурирующему проекту.)
А что касается поддержки systemd в busybox'е, интересно было бы узнать, где же такое использовалось. Обычно, когда на диск влезает systemd, то и для coreutils место найдётся.
> А что касается поддержки systemd в busybox'е, интересно было бы узнать, где
> же такое использовалось. Обычно, когда на диск влезает systemd, то и
> для coreutils место найдётся.Прозреваю, что ты даже не в курсе, что systemd может просто не загрузиться, если какой-нибудь раздел не примонтируется. Вот и приходится людям ставить запасной минидистрибутив для восстановления.
можно сказать веселее. собираешь ядро без cgroups - и опа.. у тебя не система а кирпич..
- Доктор, когда я делаю вот так у меня болит
- А вы ВОТ ТАК не делайте.
> - Доктор, когда я делаю вот так у меня болит
> - А вы ВОТ ТАК не делайте.типичный диалог в багтрекере системд.
> - Доктор, когда я делаю вот так у меня болит
> - А вы ВОТ ТАК не делайте.- Но раньше всегда так делал и не болело.
- Зато теперь всегда будет.
> можно сказать веселее. собираешь ядро без cgroups - и опа.. у тебя
> не система а кирпич..Собираешь ядро без поддержки ext2/3/4 - и опа... у тебя кирпич.
C-группы полезны и для учёта ресурсов (собственно, для чего они и были сделаны).
> Собираешь ядро без поддержки ext2/3/4 - и опа... у тебя кирпич.Не факт. Система может быть построена на другой ФС или вообще быть целиком в озу. Так что делать ext4 обязательным элементом системы также не обоснованно как и с cgroups.
> C-группы полезны и для учёта ресурсов (собственно, для чего они и были
> сделаны).Противогаз тоже очень полезен для контроля качества воздуха, но вы ведь не хотите чтобы его применение в повседневной жизни стало обязательным?
Я уже две операционные системы перевёл на systemd, так что в курсе. ;-)
> Я уже две операционные системы перевёл на systemd, так что в курсе. ;-)Операционные системы или инсталяции операционных систем?
PS: к слову о сегфолтах -- про этот в systemd'шном telinit уже и забыл: https://bugzilla.altlinux.org/show_bug.cgi?id=27666#c12
Нет мыслей почему в некоторых странах руль в бардачке а в большинстве мира с левой? А почему некоторые прогрессивные страны используют дюймовую систему а не метрическую?
> прогрессивные страны используют дюймовую системуподелил на ноль.
> А почему некоторые прогрессивные страны используют дюймовую систему а не метрическую?Что, обе?
> полные идиоты, и будут цепляться
> Вместо того, чтобы просто критиковать, не устраивает systemd -- взяли, и написали свой. Github бесплатный. (Ну, или присоединились к конкурирующему проекту.)Кличко отдыхвает. Правильно считают, что systemd нравится в основном школоте, причём самой её безмозглой части.
>Я не думаю, что производители наиболее известных дистрибутивов полные идиоты, и будут цепляться за systemd, если будет альтернатива лучше.Правильнее сказать, что идиотов там меньше 95%. Но большинство все равно идиоты.
Дистрибутивы в которых решения принимают не идиоты, не приняли systemd, или добавили как одну из альтернатив.
Плюс systemd в том, что теперь мы знаем эти дистрибутивы, а от остальных будем держаться подальше.
В этом итт треде у фанбоев бомбит от ненужности их фетиша.
> В этом итт тредедвощ там ->
вылезай из криокамеры, его давно нет
> Удалили 76 строк кода
> Опеннет ликует
> Новость оценили на +94
>> Удалили 76 строк кодаИногда лучше немного удалить, чем притянуть в проект кучу ненужного мусора.
>> Опеннет ликует
Так как заслуженно уважаемый проект открыто заявил, "что разработчики systemd не идут на взаимодействие с остальным миром, поэтому остальной мир не имеет оснований для продолжения работы с разработчиками systemd."
>> Новость оценили на +94
После раскола сообщества СПО, внесенного Поттерингом, очень приятно видеть opennet опять объединившемся.
Просто нормальным людям надоело дискутировать с идиотами. Можете единодушно ликовать.
рано ещё. вот когда идиоты во главе с лёней сядут на корабль и утонут — вот тогда.
Интересно, кто нибудь представляет вообще, в чем эта самая поддержка заключалась?
И вообще, нафига она бизибоксу была нужна изначально?
Поддержка заключалась в сокетной активации syslogd. Были ещё другие планы, но они не осуществились.
Кстати, интересная альтернатива ConsoleKit, systemd-logind и LoginKit - vdev http://judecnelson.blogspot.ru/2015/01/introducing-vdev.html
никогда я эту страсть у людей не пойму: делать ненужную альтернативу тому, что ненужно.
> containers have introduced a new requirement for these facilities: controlling access to devices on a per-process basis
>> containers have introduced a new requirement for these facilities: controlling access to devices on a per-process basisя и говорю: ненужная фигня. подобная гранулярность излишня, и замахаешься настраивать. вполне достаточно механизма UGO, и рассаживания нужных процессов по нужным группам.
> ненужная фигня. подобная гранулярность излишняВ каких-то случаях - да, в каких-то - совсем нет.
И было бы лучше (для гармоничности мироздания) если бы те, кому это надо, пилили и использовали бы вместо systemd-logind и прочих несуразностей этот vdev.
я не сказал, что ей нельзя найти применений: в принципе, применение всему найти можно. но я считаю, что лучше не искать и не делать: плюшки не окупают общее усложнение системы. то есть, не заниматься созданием «альтернативы», а просто всё вместе выкинуть.
> я не сказал, что ей нельзя найти примененийНикто и не предлагал специально искать применений, лишь бы найти.
> просто всё вместе выкинуть
Вместе с задачами, условиями и обстоятельствами, где подобная гранулярность удобна, уместна и эффективна?
>> просто всё вместе выкинуть
> Вместе с задачами, условиями и обстоятельствами, где подобная гранулярность удобна, уместна
> и эффективна?Выкинуть из системы by default. А уж те, "где подобная гранулярность удобна, уместна и эффективна", установят сами наиболее подходящие варианты решения проблемы.
> Вместе с задачами, условиями и обстоятельствами, где подобная гранулярность удобна, уместна
> и эффективна?именно. как сказал Михаил — нафиг из «обычной системы». это очень специализированная штука — пусть она и будет как специализированный софт. а не тащить её везде.
Какое в комментариях гoвно- критикуют тех, кто получил больше доли, чем ваши прыщавые дескопные дистрибутивы вместе взятые. Он добился большего и справедливо сделал - нашел мужество и отказался от RH-поделки.
На самом деле с хейтерами systemd картина печальная. Большинство из них не имеют никакой конструктивной критики, а просто не хотят изучать новое из-за кажущейся сложности.Каждый инструмент имеет свою область применимости. И умение профессионала и состоит в том, чтобы разобраться, когда и какой инструмент лучше использовать. Профессионал должен уметь пользоваться всем.
И мало ли, кому и что не нравится. Мне, вон, может grub2 и dracut не нравятся. Вспомните, как просто было всё во времена lilo. Но я их изучил, и теперь спокойно использую.
В общем, удивляет, насколько непрофессиональное у нас сообщество. Всем лишь бы покидать ... на вентилятор.
Отчасти, это понятно. Всем охота Один раз в жизни изучить некоторый набор технологий, и использовать их. Но, к сожалению, так не выйдет. Постоянно появляется что-то новое, и постоянно приходится это изучать. Выживает не приспособившийся, а приспосабливающийся.
Но даже в этой ситуации есть плюсы. Мне, умеющему настраивать systemd, больше работы и больше денег достанется. А вы, да, продалжайте критиковать, не изучая. ;-) Вы пока меня минусуйте, а я пойду ещё какой-нибудь мануал почитаю. ;-) У меня есть в резюме строчка systemd, а у вас нет. ;-)
> Вспомните, как просто было всё во времена liloLI
молодёжь не поймёт шутку.
И такое было. :-)
> На самом деле с хейтерами systemd картина печальная. Большинство из них не
> имеют никакой конструктивной критики, а просто не хотят изучать новое из-за
> кажущейся сложности.Вы можете точно рассказать, какие действия и в какой последовательности происходят при загрузке вышей системы? Как если бы вы загрузились с init=/bin/sh и набрали все вручную.
> Каждый инструмент имеет свою область применимости.
Естественно и применять его надо только тогда когда это реально обоснованно.
> И умение профессионала и состоит в
> том, чтобы разобраться, когда и какой инструмент лучше использовать.Согласен.
> Профессионал должен уметь пользоваться всем.
Вы умеете настраивать все системы инициализации? Профессионал должен быть способен изучить новый инструмент в разумный срок, но не как не уметь пользоваться всем.
> И мало ли, кому и что не нравится. Мне, вон, может grub2
> и dracut не нравятся. Вспомните, как просто было всё во времена
> lilo. Но я их изучил, и теперь спокойно использую.А мне вот grub2 совсем не понравился. У lilo тоже хватало причуд. Использую syslinux (extlinux) и вполне доволен.
> В общем, удивляет, насколько непрофессиональное у нас сообщество. Всем лишь бы покидать
> ... на вентилятор.
> Отчасти, это понятно. Всем охота Один раз в жизни изучить некоторый набор
> технологий, и использовать их.Нет. Я с интересом слежу за новыми проектами, которые могут помочь мне лучше выполнить имеющиеся задачи. Более того, я готов вникать в суть работы системы и патчить ее для достижения поставленных целей.
> Но, к сожалению, так не выйдет. Постоянно
> появляется что-то новое, и постоянно приходится это изучать. Выживает не приспособившийся,
> а приспосабливающийся.Изучать новое есть смысл только тогда, когда оно помогает решить текущие задачи лучше, чем уже изученные и настроенные решения.
> Но даже в этой ситуации есть плюсы. Мне, умеющему настраивать systemd, больше
> работы и больше денег достанется. А вы, да, продалжайте критиковать, не
> изучая. ;-) Вы пока меня минусуйте, а я пойду ещё какой-нибудь
> мануал почитаю. ;-) У меня есть в резюме строчка systemd, а
> у вас нет. ;-)Каждому своя дорога. Я предпочитаю понимать как работает моя система, а не ограничиваться возможностями одной прослойки.
> Вы можете точно рассказать, какие действия и в какой последовательности происходят при
> загрузке вышей системы? Как если бы вы загрузились с init=/bin/sh и
> набрали все вручную.Конечно, могу. Достаточно в /etc/systemd/systemd.conf поставить LogLevel=debug, а также убрать опцию quiet из командной строки ядра, и вы прекрасно всё увидите в журнале, какие сервисы и в какой последовательности стартанули.
> Изучать новое есть смысл только тогда, когда оно помогает решить текущие задачи лучше, чем уже изученные и настроенные решения.
В моём случае systemd позволил существенно ускорить загрузку системы, что весьма важно для мобильных решений. А также существенно упростился анализ зависимостей сервисов.
Опечатался. Правильно: /etc/systemd/system.conf
> Конечно, могу. Достаточно в /etc/systemd/systemd.conf поставить LogLevel=debug, а также
> убрать опцию quiet из командной строки ядра, и вы прекрасно всё
> увидите в журнале, какие сервисы и в какой последовательности стартанули.Очень интересно было бы на это посмотреть, если не сложно - выложите лог.
>> Изучать новое есть смысл только тогда, когда оно помогает решить текущие задачи лучше, чем уже изученные и настроенные решения.
> В моём случае systemd позволил существенно ускорить загрузку системы, что весьма важно
> для мобильных решений.Сомневаюсь, что с systemd система будет грузится быстрее, чем с хорошо продуманным инитом под конкретную систему, который по факту может уложится в 20-30 команд.
У меня есть стары ноутбук (1.66Mhzx2) который грузится за 7 секунд, выключается за 1-2 секунды.> А также существенно упростился анализ зависимостей сервисов.
Сколько, каких (и зачем) сервисов у вас запущенно, что для них нужен анализ зависимостей?
Вот, например, журнал загрузки виртуалки с openSUSE 13.2: http://pastebin.com/shju9AeT
Здесь, правда, есть такой момент, что systemd стартует два раза: один раз в initrd, сгенерированном dracut'ом, а второй, непосредственно, с корневой файловой системы.Вся сложность понимания работы systemd состоит в том, что сервисы стартуют параллельно согласно графу зависимостей. В тоже время, для сервиса легко понять, от кого он зависит, и кто зависит от него. При этом есть инструменты, показывающие критический путь при загрузке -- узкое место, разобравшись с которым можно ускорить загрузку системы (systemd-analyze, bootchart).
Быстрая скорость загрузки достигается именно за счёт параллельного запуска сервисов, что трудно организовать, используя классический SysV init.
Анализ зависимостей сервисов требуется для ускорения загрузки, когда пытаетесь понять, действительно ли сервис A должен стартовать после сервиса B, и можно ли сделать так, чтобы они стартовали параллельно. Правда, в случае с мобильными телефонами может оказаться не всё так просто, и если стартовать все сервисы одновременно, загрузка системы может стать даже медленнее, чем если разбить все сервисы на несколько групп (с разумным пареллелизмом), а группы стартовать последовательно.
Под сервисами я подразумеваю различные службы и приложения. Посмотрите, сколько у вас процессов на мобильном телефоне работает -- а, ведь, все их кто-то должен запустить. И systemd -- один из способов запустить их максимально быстро.
К тому же удобно управлять сервисами: включать/выключать/запрещать. И нет проблем с зависимостями, типа, что mysql остановили, а apache с сайтом, который может к нему обращаться, ещё работает -- забыли остановить в первую очередь.
В случае с вашим ноутбуком ответ можно вполне точно прикинуть, можно ли ускорить загрузку. Есть инструменты (типа того же bootchart'а), которые записывают загрузку CPU и дисковой подсистемы во время старта системы. И если у вас всё загружено под завязку, то, да, улучшить не получится. А если что-то простаивает, то есть шанс, что можно что-то переупорядочить, и, тем самым, ускорить загрузку.
> Вот, например, журнал загрузки виртуалки с openSUSE 13.2: http://pastebin.com/shju9AeTСпасибо.
> Здесь, правда, есть такой момент, что systemd стартует два раза: один раз
> в initrd, сгенерированном dracut'ом, а второй, непосредственно, с корневой файловой системы.Это не главное. Вы уверены, что из этого лога вы понимаете как стартует система? Я например не увидел в нем многих основополагающих вещей. Например в какой момент монтируется /sys /proc /tmp, в какой последовательности и с какими параметрами?
> Вся сложность понимания работы systemd состоит в том, что сервисы стартуют параллельно
> согласно графу зависимостей. В тоже время, для сервиса легко понять, от
> кого он зависит, и кто зависит от него. При этом есть
> инструменты, показывающие критический путь при загрузке -- узкое место, разобравшись с
> которым можно ускорить загрузку системы (systemd-analyze, bootchart).
> Быстрая скорость загрузки достигается именно за счёт параллельного запуска сервисов, что
> трудно организовать, используя классический SysV init.Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать. Действительно ли вам нужны все эти сервисы, что бы потом строить зависимости и думать как их параллельно запустить? Озвучите ваши задачи и необходимые для них сервисы и на чем основан их выбор.
> Под сервисами я подразумеваю различные службы и приложения. Посмотрите, сколько у вас
> процессов на мобильном телефоне работает -- а, ведь, все их кто-то
> должен запустить. И systemd -- один из способов запустить их максимально
> быстро.Телефон (android) - это показатель как не нужно делать. Количество сервисов там раздуто выше всякой меры.
> К тому же удобно управлять сервисами: включать/выключать/запрещать. И нет проблем с зависимостями,
> типа, что mysql остановили, а apache с сайтом, который может к
> нему обращаться, ещё работает -- забыли остановить в первую очередь.Согласен. Но подобное нужно далеко не везде.
> В случае с вашим ноутбуком ответ можно вполне точно прикинуть, можно ли
> ускорить загрузку. Есть инструменты (типа того же bootchart'а), которые записывают загрузку
> CPU и дисковой подсистемы во время старта системы. И если у
> вас всё загружено под завязку, то, да, улучшить не получится. А
> если что-то простаивает, то есть шанс, что можно что-то переупорядочить, и,
> тем самым, ускорить загрузку.Там особо вариантов нет. Да и systemd, запускающий сотни команд, тянущий cgroups/d-bus/ udev/etc по определению не может быть быстрее 20-30 команд шела.
> Это не главное. Вы уверены, что из этого лога вы понимаете как
> стартует система? Я например не увидел в нем многих основополагающих вещей.
> Например в какой момент монтируется /sys /proc /tmp, в какой последовательности
> и с какими параметрами?Данные файловые системы монтирует сам systemd, так как уже сложно представить себе систему, где данные файловые системы не монтируются или монтируются не туда (или с другими параметрами).
> Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать. Действительно ли вам
> нужны все эти сервисы, что бы потом строить зависимости и думать
> как их параллельно запустить? Озвучите ваши задачи и необходимые для них
> сервисы и на чем основан их выбор.
> Телефон (android) - это показатель как не нужно делать. Количество сервисов там
> раздуто выше всякой меры.А я и не об Андроиде говорил. Есть ещё Tizen и Sailfish. Количество разных сервисов/демонов достигает нескольких десятков, и иногда переваливает за сотню. В телефоне много подсистем, нуждаюзихся в своих сервисах -- сенсоры, модем, GPS, аудио, WiFi...
> Там особо вариантов нет. Да и systemd, запускающий сотни команд, тянущий cgroups/d-bus/
> udev/etc по определению не может быть быстрее 20-30 команд шела.Как раз systemd и позволяет не запускать сотни команд. Init-скрипты плохи тем, что для каждого скрипта инстанциируется свой процесс bash'а (ну, или какой шелл в системе стоит). А это тоже занимает времени. В случае же с systemd есть возможность, вообще, не запускать shell-процессы, ограничившись короткими ini-файлами, и запускать, непосредственно, процессы сервисов.
Судя по тому, что -1 стоит уже у каждого моего сообщения, какому-то хейтеру очень сильно не понравилось, что я пишу, и он решил из вредности заминусовать все мои сообщения. Детский сад, честное слово. ;-)
>> Это не главное. Вы уверены, что из этого лога вы понимаете как
>> стартует система? Я например не увидел в нем многих основополагающих вещей.
>> Например в какой момент монтируется /sys /proc /tmp, в какой последовательности
>> и с какими параметрами?
> Данные файловые системы монтирует сам systemd, так как уже сложно представить себе
> систему, где данные файловые системы не монтируются или монтируются не туда
> (или с другими параметрами).В этом и проблема. Как например произвести необходимые действия до монтирования этих fs?
У меня например есть модуль звуковой платы (emu1212m) который очень долго грузится - там fpga программируется при каждой загрузке. Я хочу чтобы первым действием инита была его загрузка в отдельном процессе.>> Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать. Действительно ли вам
>> нужны все эти сервисы, что бы потом строить зависимости и думать
>> как их параллельно запустить? Озвучите ваши задачи и необходимые для них
>> сервисы и на чем основан их выбор.
>> Телефон (android) - это показатель как не нужно делать. Количество сервисов там
>> раздуто выше всякой меры.
> А я и не об Андроиде говорил. Есть ещё Tizen и Sailfish.
> Количество разных сервисов/демонов достигает нескольких десятков, и иногда переваливает
> за сотню. В телефоне много подсистем, нуждаюзихся в своих сервисах --
> сенсоры, модем, GPS, аудио, WiFi...Вы считаете этот подход правильным? Почему под gnu/linux можно обойтись минимумом демонов и при этом будут и сенсоры и куча другой периферии?
>> Там особо вариантов нет. Да и systemd, запускающий сотни команд, тянущий cgroups/d-bus/
>> udev/etc по определению не может быть быстрее 20-30 команд шела.
> Как раз systemd и позволяет не запускать сотни команд. Init-скрипты плохи тем,
> что для каждого скрипта инстанциируется свой процесс bash'а (ну, или какой
> шелл в системе стоит). А это тоже занимает времени.Сколько занимает, учитывая, что в системе инициализации обычно используется ash/dash? Да и ни кто не заставляет запускать скрипты десятками. У меня например четыре скрипта.
> В случае
> же с systemd есть возможность, вообще, не запускать shell-процессы, ограничившись короткими
> ini-файлами, и запускать, непосредственно, процессы сервисов.Вы просто гляньте выложенный вами лог и скажите сколько процессов будет порождено пока система загрузится. Даже проще - напишите ps сразу по завершению загрузки и назовите pid последнего процесса.
> В этом и проблема. Как например произвести необходимые действия до монтирования этих fs?
> У меня например есть модуль звуковой платы (emu1212m) который очень долго грузится - там fpga программируется при каждой загрузке.
> Я хочу чтобы первым действием инита была его загрузка в отдельном процессе.А как связана загрузка модуля с монтированием /proc, /sys и /tmp. Данные монтирования -- это всего-лишь три системных вызова, и происходят мгновенно. А далее, можно и ваш модуль параллельно грузить.
> Вы считаете этот подход правильным? Почему под gnu/linux можно обойтись минимумом демонов и при этом будут и сенсоры и куча другой периферии?
Насчёт правильности не уверен. Здесь архитектуру нужно обсуждать более детально. Модульность часто позволяет экономить память, когда какой-нибудь ненужный демон может быть остановлен, если соответствующий функционал не используется, вместо использования монолитного демона, который будет в памяти висеть всегда.
При разработке мобильных решений применяются другие критерии, нежели при разработке десктопных дистрибутивов. На первое место вылезают потребление CPU, памяти и питания. К тому же, иногда бывают решения, навязанные производителем данного конкретного SoC'а -- вот, есть предоставленные сервисные демоны, которые делают то-то, а других нету.
А, вообще, тут нужно более конкретно обсуждать. Брать какую-то подсисистему на десктопе и в мобильнике, и сравнивать.
А что касается номера последнего PID'а, то это некорректное сравнение. Нужно, как минимум, брать две системы с одинаковым набором сервисов -- одну на SysV init'е (или на чём пожелаете), а вторую на systemd. Ну, или хотя бы два десктопных дистрибутива.
В openSUSE 1107 после загрузки. Замечу, что одних ядерных потоков сейчас запущено 97. Так что это мало о чём говорит.
В случае с systemd процессов будет запущено однозначно меньше, чем в случае с init'ом, так как не надо запускать bash на каждый скрипт, и не надо запускать всякие ls, grep, sed, find, wc, awk и прочие утилиты, а можно просто задавать опции в unit-файле.
>> В этом и проблема. Как например произвести необходимые действия до монтирования этих fs?
>> У меня например есть модуль звуковой платы (emu1212m) который очень долго грузится - там fpga программируется при каждой загрузке.
>> Я хочу чтобы первым действием инита была его загрузка в отдельном процессе.
> А как связана загрузка модуля с монтированием /proc, /sys и /tmp. Данные
> монтирования -- это всего-лишь три системных вызова, и происходят мгновенно. А
> далее, можно и ваш модуль параллельно грузить.Допустим. Но как вы решите поставленную мной задачу в systemd? Сколько пройдет команд до того как будет загружен этот модуль?
> Модульность часто позволяет экономить память, когда какой-нибудь ненужный демон может быть остановлен, если соответствующий функционал не используется, вместо использования монолитного демона, который будет в памяти висеть всегда.
Речь о другом: gnu/linux позволяет работать с датчиками и прочим железом без демонов. Есть конечно исключения типа wpa_suplicant, но обычно софт может обратится к устройству или sysfs напрямую.
> При разработке мобильных решений применяются другие критерии, нежели при разработке десктопных
> дистрибутивов. На первое место вылезают потребление CPU, памяти и питания.К сожалению - сейчас нет. Там сплошной блоатваре, сжирающий память и cpu, а заодно и батарейку. Гляньте на rockbox - может работать на 1mb (для всех функций нужно 4mb) ram и 30-40MHz древнего arm. Потребление питания при програмном декодировании музыки 12-13ma.
Емкость аккумулятора современных телефонов доходит до 3000-4000mAh. То есть телефон (с отключенным модулем связи) под управлением rockbox смог бы играть музыку в течении 250-300 часов!> А что касается номера последнего PID'а, то это некорректное сравнение. Нужно, как
> минимум, брать две системы с одинаковым набором сервисов -- одну на
> SysV init'е (или на чём пожелаете), а вторую на systemd. Ну,
> или хотя бы два десктопных дистрибутива.Моя позиция иная сперва нужно выкинуть ненужное, а затем уж смотреть нужна ли столь сложная система инициализации.
Упомянутый мной ноутбук и десктоп с такой же системой используются для программирования (включая avr и arm), работы с 2d/3d графикой и работы со звуком. При этом gnu utils заменены на busybox, udev заменен mdev. d-bus/pa и прочие подобные вещи не использую.
> В случае с systemd процессов будет запущено однозначно меньше, чем в случае
> с init'ом, так как не надо запускать bash на каждый скрипт,
> и не надо запускать всякие ls, grep, sed, find, wc, awkДопустим. Встречный вопрос: сможет ли systemd запустить десктоп систему (включая Xorg) за простых 20-30 команд?
> Допустим. Но как вы решите поставленную мной задачу в systemd? Сколько пройдет
> команд до того как будет загружен этот модуль?Как вариант, если, уж, нужно Очень рано стартовать, напишут unit-файл с минимальными зависимостями, что позволит systemd запустить его первым или одним из первых. И всего-лишь с одной командой Exec=/sbin/modprobe ... Это, конечно, отчасти, хак, но если очень надо, то сделать можно.
> Речь о другом: gnu/linux позволяет работать с датчиками и прочим железом без
> демонов. Есть конечно исключения типа wpa_suplicant, но обычно софт может обратится
> к устройству или sysfs напрямую.Ну, вот, с этим "обычно" и нужно разбираться более детально. С
> К сожалению - сейчас нет. Там сплошной блоатваре, сжирающий память и cpu,
> а заодно и батарейку. Гляньте на rockbox - может работать на
> 1mb (для всех функций нужно 4mb) ram и 30-40MHz древнего arm.
> Потребление питания при програмном декодировании музыки 12-13ma.
> Емкость аккумулятора современных телефонов доходит до 3000-4000mAh. То есть телефон (с
> отключенным модулем связи) под управлением rockbox смог бы играть музыку в
> течении 250-300 часов!Вообще, первое место по потреблению энергии в сотовых сейчас занимает экран. При выключенном экране сотовый живёт в разы дольше. А ещё энергию жрёт GSM-модем. Поэтому сравнивать телефон с MP3-плеером не совсем корректно.
Насчёт блоатвари, вопрос спорный. Попробуйте предложить другую архитектуру мобильной операционной системы: и чтобы у приложений был удобный доступ к сенсорам и т.п. (чтобы каждому приложению не надо было линковаться с низкоуровневыми библиотеками, а можно было использовать высокоуровневый API), и чтобы, при этом с безопасностью было всё в порядке, чтобы не позволять всем приложениям обращаться ко всему. Вот тут-то и повылезают демоны, являющиеся прослойкой между железом и непривилегированными приложениями.
Если же вы про кучу ненужного предустановленного софта, то с этим согласен. Но это мало имеет отношения к systemd -- что поставили, то и запускает.
> Допустим. Встречный вопрос: сможет ли systemd запустить десктоп систему (включая Xorg)
> за простых 20-30 команд?В systemd нет команд. Там есть unit-файлы с ini-подобным синтаксисом. Если для загрузки вашей системы требуется всего-лишь 20-30 команд, то, несомненно, их можно и в небольшое количество unit-файлов перенести.
> Вообще, первое место по потреблению энергии в сотовых сейчас занимает экран. При
> выключенном экране сотовый живёт в разы дольше. А ещё энергию жрёт
> GSM-модем. Поэтому сравнивать телефон с MP3-плеером не совсем корректно.Предлагаю эксперимент: зарядите полностью телефон, переведите в режим "в самолете" и оставьте на ночь играть музыку, а утром посмотрите сколько останется заряда батареи.
> Насчёт блоатвари, вопрос спорный. Попробуйте предложить другую архитектуру мобильной
> операционной системы: и чтобы у приложений был удобный доступ к сенсорам
> и т.п. (чтобы каждому приложению не надо было линковаться с низкоуровневыми
> библиотеками, а можно было использовать высокоуровневый API), и чтобы, при этом
> с безопасностью было всё в порядке, чтобы не позволять всем приложениям
> обращаться ко всему. Вот тут-то и повылезают демоны, являющиеся прослойкой между
> железом и непривилегированными приложениями.gnu/linux и отказ от сомнительных маркетов/приложений?
> Если же вы про кучу ненужного предустановленного софта, то с этим согласен.
> Но это мало имеет отношения к systemd -- что поставили, то
> и запускает.Нет, именно о системе и куче демонов без реальной на то надобности.
>> Допустим. Встречный вопрос: сможет ли systemd запустить десктоп систему (включая Xorg)
>> за простых 20-30 команд?
> В systemd нет команд. Там есть unit-файлы с ini-подобным синтаксисом.Естественно. Но его действия можно представить аналогичным эквивалентом обычных команд. И их там будет существенно больше.
> Если для
> загрузки вашей системы требуется всего-лишь 20-30 команд, то, несомненно, их можно
> и в небольшое количество unit-файлов перенести.В чем тогда смысл? Усложнить систему введя новую прослойку? Да и команд понадобится существенно больше, так как притянутся cgroups/udev/dbus.
>> В systemd нет команд. Там есть unit-файлы с ini-подобным синтаксисом.
> Естественно. Но его действия можно представить аналогичным эквивалентом обычных команд.
> И их там будет существенно больше.Считать, на мой взгляд, стоит не команды, а системные вызовы. Сколько системных вызовов происходит, пока запускается bash, чтобы исполнить Одну команду? В случае с systemd, это будет всего-лишь парочка системных вызовов.
>> Если для
>> загрузки вашей системы требуется всего-лишь 20-30 команд, то, несомненно, их можно
>> и в небольшое количество unit-файлов перенести.
> В чем тогда смысл? Усложнить систему введя новую прослойку? Да и команд
> понадобится существенно больше, так как притянутся cgroups/udev/dbus.Не понимаю, при чём тут cgroup'пы. Ну, да, запускаемые сервисы systemd распихивает по cgroup'пам для удобства менеджмента (в частности, чтобы можно было при остановке демона убить всех его дважды-трижды-форкнувшихся потомков -- от systemd не сбежишь). Что касается udev, то вы вольны оставить только нужные вам правила, и тогда не будет никаких ненужных команд.
> Считать, на мой взгляд, стоит не команды, а системные вызовы. Сколько системных
> вызовов происходит, пока запускается bash, чтобы исполнить Одну команду? В случае
> с systemd, это будет всего-лишь парочка системных вызовов.OK. Но не bash, а dash/ash. И в одном случае мы имеем интерпретатор в виде шела, в другом в виде systemd. Мы можем из одного шела запустить все нужные команды.
Сделайте strace для unit'a, а я сделаю для шела и можем посчитать системные вызовы.
> Не понимаю, при чём тут cgroup'пы. Ну, да, запускаемые сервисы systemd распихивает
> по cgroup'пам для удобства менеджмента (в частности, чтобы можно было при
> остановке демона убить всех его дважды-трижды-форкнувшихся потомков -- от systemd не
> сбежишь).Что бы распихивать процессы по ц-группам вызовы не нужны? Я так понимаю, что systemd может проделывать и другие подобные манипуляции над каждым запускаемым процессом, даже если это реально ненужно.
> Что касается udev, то вы вольны оставить только нужные вам
> правила, и тогда не будет никаких ненужных команд.Я могу не запускать udev совсем или заменить его mdev или чем еще?
> OK. Но не bash, а dash/ash. И в одном случае мы имеем
> интерпретатор в виде шела, в другом в виде systemd. Мы можем
> из одного шела запустить все нужные команды.
> Сделайте strace для unit'a, а я сделаю для шела и можем посчитать
> системные вызовы.Не совсем так. systemd при старте сразу считывает все unit-файлы, и строит у себя в голове граф зависимостей. Далее, когда требуется запустить какой-то процесс, ему не нужно больше никаких скриптов исполнять. Он знает, что sshd запускается с помощью такого-то бинарника. Все системные вызовы, которые тут нужны -- всего лишь, чтобы форкнуться, настроить нужные права (при необходимости), и сделать exec на запускаемый бинарник. И никакой shell-магии.
> Что бы распихивать процессы по ц-группам вызовы не нужны? Я так понимаю,
> что systemd может проделывать и другие подобные манипуляции над каждым запускаемым
> процессом, даже если это реально ненужно.Когда это реально не нужно, будет проделан минимум работы. Если вы не используете ограничения по памяти или CPU, то как я понимаю, работа с cgroup'пами будет минимальна -- только для контроля за тем, какие процессы какому сервису принадлежат (помещаем первый процесс сервиса в группу, потомки будут там же).
> Я могу не запускать udev совсем или заменить его mdev или чем
> еще?Насчёт не запускать, не уверен. Но вы можете выкинуть ненужные правила.
Вы же не сможете спорить, что программа на компилируемом языке всегда быстрее, чем на интерпретируемом, и что запуск процессов влечёт за собой накладные расходы, и при прочих равных условиях, чем меньше процессов, тем лучше?systemd выигрывает за счёт двух вещей:
1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в виде параметров, а не в виде результатов работы внешних команд)
2) ПараллельностьНо, как я уже говорил, настроить криво можно что угодно.
Я не верю, что при пряморукой настройке systemd может быть медленнее, чем куча shell-скриптов.
> Вы же не сможете спорить, что программа на компилируемом языке всегда быстрее,
> чем на интерпретируемом, и что запуск процессов влечёт за собой накладные
> расходы, и при прочих равных условиях, чем меньше процессов, тем лучше?Да, но:
1. systemd тоже разбирает конфиги.
2. в 90% случаев вся интерпретация в шеле сводится к запуску конкретного бинарника
> systemd выигрывает за счёт двух вещей:
> 1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в
> виде параметров, а не в виде результатов работы внешних команд)Но по факту он должен производить те же манипуляции, что и shell команды. В теории он может иметь выигрыш за счет меньшего количества процессов, но у него есть и собственные накладные расходы в виде cgroups/dbus и Поттеринг знает еще чего.
> 2) Параллельность
У меня это решается так:
nice -n 19 /etc/init.d/background &
> Да, но:
> 1. systemd тоже разбирает конфиги.
> 2. в 90% случаев вся интерпретация в шеле сводится к запуску конкретного
> бинарникаsystemd не надо интерпретировать команды. Соответственно, ему не надо в голове иметь интерпретатор / виртуальную машину. Формат unit-файла чётко специфицирован. В нём могут встречаться только определённые ключевые слова и только в определённом месте. В результате есть возможность при старте системы прочитать все значения параметров, сохранить их в структуру, и больше не заниматься парсингом и т.п.
>> systemd выигрывает за счёт двух вещей:
>> 1) Отсутствие или сведённое к миниумму количество shell-скриптов (всё в unit-файлах в
>> виде параметров, а не в виде результатов работы внешних команд)
> Но по факту он должен производить те же манипуляции, что и shell
> команды. В теории он может иметь выигрыш за счет меньшего количества
> процессов, но у него есть и собственные накладные расходы в виде
> cgroups/dbus и Поттеринг знает еще чего.systemd не нужно, например, по десять раз инициализировать разделяемые библиотеки, что происходит при запуске шелла. Напшите ldd /bin/ваш-любимый-шелл. Сколько разделяемых библиотек могут захотеть проинициализироваться при старте процесса?
>> 2) Параллельность
> У меня это решается так:
> nice -n 19 /etc/init.d/background &Это выглядит более похоже на костыль, чем на решение. Как вы определяете зависимости между сервисами? Как избегаете race condition'ов? На глаз? В случае с systemd можно прописать зависимости декларативно.
У systemd есть ещё плюс -- активация сервиса через сокет (socket based activation). Например, вы можете настроить систему так, чтобы sshd не запускался до первого соединения (нечто похожее на inetd).
> systemd не надо интерпретировать команды. Соответственно, ему не надо в голове иметь
> интерпретатор / виртуальную машину. Формат unit-файла чётко специфицирован. В нём могут
> встречаться только определённые ключевые слова и только в определённом месте. В
> результате есть возможность при старте системы прочитать все значения параметров, сохранить
> их в структуру, и больше не заниматься парсингом и т.п.В теории красиво. Перейдем к практике.
Интерпретация в ash сводится к трем функциям. Первая читает из файла слова. Вторая используя switch ищет подходящий вариант спецсимвола. Третья используя все тот же switch ищет ключевое слово. Если слово не является спецсимволом или ключевым словом, то оно считается внешней командой и происходит попытка запуска. Всего 219 строк кода.Интерпретация systemd: поиск unit файлов по всем закоулкам с привлечением dbus. Где оно точно парсит я так и не нашел, ибо размазано там все так, как ... Нашел функцию устанавливающую свойства - там каждый раз тоже активно используется dbus, если верно понял рассылает уведомления о изменении состояния свойства. Запуск тоже нашел - там ряд проверок, а вдруг unit уже запущен, а вдруг ему что мешает или не хватает и т.д. В общем там исполняются десятки тысяч строк кода (не считая dbus) дабы запустить один unit.
> systemd не нужно, например, по десять раз инициализировать разделяемые библиотеки, что
> происходит при запуске шелла.Зато у него на каждый чих - обращение к dbus ;)
> Напшите ldd /bin/ваш-любимый-шелл. Сколько разделяемых
> библиотек могут захотеть проинициализироваться при старте процесса?ldd ash
linux-gate.so.1 (0xb77a1000)
libc.so.6 => /lib/libc.so.6 (0xb760e000)
/lib/ld-linux.so.2 (0xb77a2000)>>> 2) Параллельность
>> У меня это решается так:
>> nice -n 19 /etc/init.d/background &
> Это выглядит более похоже на костыль, чем на решение. Как вы определяете
> зависимости между сервисами?Смотрю порядок исполнения в файле.
> Как избегаете race condition'ов? На глаз? В случае
> с systemd можно прописать зависимости декларативно.Я предпочитаю не доводить систему до такого состояния :)
Сейчас в системе реально есть только один случай - нужно запускать графические программы только после того как загрузится xorg-server. Использую waitforx (исходник - 16 строк на c). Как кстати systemd определяет что xorg-server уже запустился?> У systemd есть ещё плюс -- активация сервиса через сокет (socket based
> activation). Например, вы можете настроить систему так, чтобы sshd не запускался
> до первого соединения (нечто похожее на inetd).А чем плох initd?
> (нечто похожее на inetd).
> А чем плох inetd?Слишком долго уже просто работает, очевидно.
> У меня это решается так:
> nice -n 19 /etc/init.d/background &Есть ещё ionice -c3, порой полезно (нынче умолчательный приоритет ввода-вывода связан и с nice, помнится, но в idle отодвинуть куда заметней).
> Есть ещё ionice -c3, порой полезно (нынче умолчательный приоритет ввода-вывода связан и
> с nice, помнится, но в idle отодвинуть куда заметней).Да есть такой, раньше использовал для rtorrent, дабы уменьшить проявления 12309. Потом железо сменил, от свопа отказался и больше не сталкивался. Примирительно к инит системе не пробовал, возможно стоит. Пробовал e4rat, но существенной разницы не намерил. В любом случае, на данный момент самым тормозным местом является bios.
кстати, вопрос оффтопиком, но по ядру. опосля перехода на 4.2 и наращивания памяти до 8Gb получился странный конфуз: отчего‐то дисковые кэши на запись работают нормально только пока вся память не забивается кэшем чтения. после чего йок.попробую пояснить «на пальцах»: сбрасываем кэши:
echo 3 >/proc/sys/vm/drop_caches
запускаем софтину, которая делает активные write(), часто и разные.
ядро, как и полагается, оные записи кэширует, всё летает.
работаем пол‐дня (или как получается).
запускаем ту же самую софтину.
ТОРМОЗААААААААА.
снова делаем echo.
запускаем ту же самую софтину.
летает.то бишь, впечатление, что ядро забивает всю память кэшем чтения и дальше сидит на нём, замещая его только другими *прочитанными* данными, но не вытесняя его для записи.
дёргать ядерные параметры кэширования пробовал (так‐то они у меня в умолчаниях стоят), ничего кардинально не меняется. вообще.
так вот, вопрос: как пояснить ядру, что при прочих равных кэшированию записи надо отдавать приоритет, а не кэшированию чтения? а то даже простой git rebase тормозит нещадно. ;-)
> кстати, вопрос оффтопиком, но по ядруПисал бы сразу в "Linux 4.3", а то и в lkml с воспроизводилкой?
> Писал бы сразу в "Linux 4.3", а то и в lkml с
> воспроизводилкой?у мене 4.2. и решение, я сильно подозреваю, в том, что я тупо забыл подкрутить какой‐то ядерный параметр. потому спрашиваю тут — вдруг меня сразу носом ткнут, была у кого‐то такая же проблема, например. не ткнут — будем дальше копать. с воспроизводилкой тоже сложно: как воспроизвести «активно работать на моей дисковой конфигурации пол‐дня/день»? к тому же я обычно в целевые места хожу с уже готовыми решениями.
> дёргать ядерные параметры кэширования пробовал (так‐то они у меня в умолчаниях стоят),
> ничего кардинально не меняется. вообще.А что происходит с Dirty и Writeback в /proc/meminfo смотрел?
Сейчас попробовал на своей системе (4gb) копировать большой файл (3gb) - MemFree становится 116mb, Dirty + Writeback = около 100mb.
Сделал "echo 30 > /proc/sys/vm/dirty_background_ratio" (было 10). Ничего не изменилось.
Сделал "echo 60 > /proc/sys/vm/dirty_ratio" (было 20). Dirty + Writeback = около 300mb.
Непонятно почему при таких больших значениях используется так мало памяти. Так что никому не доверяй и все проверяй ;)Если еще не читал, то может будет полезно:
http://www.westnet.com/~gsmith/content/linux-pdflush.htm
> А что происходит с Dirty и Writeback в /proc/meminfo смотрел?неа. отчего‐то запамятовал.
> Сейчас попробовал на своей системе (4gb) копировать большой файл (3gb) - MemFree
> становится 116mb, Dirty + Writeback = около 100mb.смешно то, что если просто кидать большой файл — всё более‐менее нормально. с ума оно сходит именно после длительной активной работы, разной‐всякой. а раньше не сходило. поэтому с воспроизведением беда, увы. к тому же это не та штука, которую сразу замечаешь, чтобы поймать моменты для мониторинга «ещё терпимо»-«уже ужасно». будем стараться дальше. сделаю логгер вообще, пусть периодически значения сохраняет, потом посмотрю на динамику.
> Сделал "echo 30 > /proc/sys/vm/dirty_background_ratio" (было 10). Ничего не изменилось.
> Сделал "echo 60 > /proc/sys/vm/dirty_ratio" (было 20). Dirty + Writeback = около
> 300mb.
> Непонятно почему при таких больших значениях используется так мало памяти. Так что
> никому не доверяй и все проверяй ;)ну, видать, или быстро протухает, или как‐то догадывается, что не надо сильно стараться. ;-)
> Если еще не читал, то может будет полезно:
> http://www.westnet.com/~gsmith/content/linux-pdflush.htmчитал, но всё равно спасибо. как я уже писал, беда в том, что невозможно быстро воспроизвести, поэтому процесс ооооочень медленный. поменял, пол‐дня работаешь, забыл уже, опять тормозит, вспомнил, проверил, поменял… короче, таким макаром оно может на годы затянуться. %-)
> ну, видать, или быстро протухает,Для это есть отдельные параметры.
> или как‐то догадывается, что не надо сильно
> стараться. ;-)Тогда бы результат при поднятии параметров в три раза вызывал бы меньший рост. ИМХО оно как-то очень хитро считает и уж точно не на прямую от объема памяти.
> читал, но всё равно спасибо. как я уже писал, беда в том,
> что невозможно быстро воспроизвести, поэтому процесс ооооочень медленный. поменял, пол‐дня
> работаешь, забыл уже, опять тормозит, вспомнил, проверил, поменял… короче, таким
> макаром оно может на годы затянуться. %-)Я бы в такой ситуации поставил эти два параметра в 3-4 раза больше исходных и ждал. Если все равно будет тормозить - то ловить момент и смотреть /proc/meminfo.
P.S Ты перешел на 64 бита, и я тут последний на 32 битах остался ? ;)
> Я бы в такой ситуации поставил эти два параметра в 3-4 раза
> больше исходных и ждал. Если все равно будет тормозить - то
> ловить момент и смотреть /proc/meminfo.да пробовал, вроде, но как‐то потом забыл. сейчас опять подкрутил немного, жду, когда начнёт тормозить.
> P.S Ты перешел на 64 бита, и я тут последний на 32
> битах остался ? ;)неа, я всё там же, x86. просто по причине кота‐электромонтёра пришлось поменять технику, и в новой технике торчит 8Gb. ну, не выкидывать же теперь. ;-) заодно и ядро обновил — и вот такая вот ерунда началась.
если вдруг кому интересно: я фиг знает, но после нижеследующего шаманства, похоже, ядро пришло в себя:vm.dirty_ratio=40
vm.swappiness=5don't even ask me. нет, я действительно не понимаю, где связь. но дисковые тормоза на записи пропали.
> vm.swappiness=5А от свопа отказаться совсем не пробовал? ИМХО от него больше вреда, чем пользы.
> А от свопа отказаться совсем не пробовал? ИМХО от него больше вреда,
> чем пользы.туда гибернатор гадит. а раз уж оно всё равно есть — пусть и будет, чо.
>> Допустим. Но как вы решите поставленную мной задачу в systemd? Сколько пройдет
>> команд до того как будет загружен этот модуль?
> Как вариант, если, уж, нужно Очень рано стартовать, напишут unit-файл с минимальными
> зависимостями, что позволит systemd запустить его первым или одним из первых.
> И всего-лишь с одной командой Exec=/sbin/modprobe ... Это, конечно, отчасти, хак,
> но если очень надо, то сделать можно.Когда именно? Перед монтированием procfs/sysfs/tmpfs или после? Или вообще после монтирования всех разделов и прогона fsck? А может еще после dbus и udev?
> Когда именно? Перед монтированием procfs/sysfs/tmpfs или после? Или вообще после монтирования
> всех разделов и прогона fsck? А может еще после dbus и
> udev?sys/proc/tmp монтируются практически сразу после запуска systemd. Раньше только initrd.
Но уже после, при желании, можно и запустить что-нибудь.
> sys/proc/tmp монтируются практически сразу после запуска systemd. Раньше только initrd.
> Но уже после, при желании, можно и запустить что-нибудь.А переведенный вами пример загрузки говорит об обратном:
https://lizards.opensuse.org/wp-content/uploads/2012/07/plot...Или я что-то не понял?
P.S. initrd на реальном среднем железе тоже 8 секунд грузится? Если так, то о какой скорости загрузки вообще можно говорить? Как я уже сказал, на старом ноуте к этому времени уже Xorg/dwm/st/mc/conky загрузятся.
> А переведенный вами пример загрузки говорит об обратном:
> https://lizards.opensuse.org/wp-content/uploads/2012/07/plot...
> Или я что-то не понял?Не говорит. На приведённом примере показан запуск сервисов. Монтирование /sys захардкожено в systemd. Приведённая картинка -- всего-лишь пример работы systemd-analyze -- инструмента, дуступного "из коробки" (в отличие от SysV init). Я не утверждал, что картинка соответствует оптимально настроенной системе. Криво настроить можно что угодно -- хоть systemd, хоть init.
Если хотите примеров быстрой загрузки, то, например, вот: https://www.youtube.com/watch?v=Xni2eIZdtrE
> Не говорит. На приведённом примере показан запуск сервисов. Монтирование /sys захардкожено
> в systemd.А монтирование остальных fs и fsck не захардкожены?
> Приведённая картинка -- всего-лишь пример работы systemd-analyze -- инструмента,
> дуступного "из коробки" (в отличие от SysV init).Так развейте мои сомнения, покажите аналогичный скрин с запуском пользовательской команды сразу после sysfs.
> А монтирование остальных fs и fsck не захардкожены?Нет. Монтирование остальных файловых систем и fsck происходит согласно тому, что написано в unit-файлах.
> Так развейте мои сомнения, покажите аналогичный скрин с запуском пользовательской команды
> сразу после sysfs.Не хочу в час ночи, когда уже полусонный, курочить систему. Такое лучше на свежую голову.
В systemd всё чётко по зависимостям. Если корневая файловая система у вас уже примонтирована, то вы можете запускать любой бинарник. В конце концов, fsck же как-то запусается? Никто не мешает вам сделать unit-файл, который будет запускать вашу команду.
> Не хочу в час ночи, когда уже полусонный, курочить систему. Такое лучше
> на свежую голову.А в обычном ините - просто одну строку в самое начало файла вставить и ничего курочить не надо :)
> А в обычном ините - просто одну строку в самое начало файла
> вставить и ничего курочить не надо :)А здесь всего-лищь короткий unit-файл. :-) Просто, чтобы сгенерировать bootchart, придётся перегружаться.
> Вместо того, чтобы лечить болезнь, ее просто пытаются спрятать.Это же redhat. Они и usrmove учинили вместо того, чтоб починить кривую линковку своего барахла из /sbin с библиотеками из /usr и оторвать руки как раз таки Леннарту, у которого pulseaudio хотело слазить в /usr/share за usb.ids непременно на ранней стадии своей инициализации.
Вместо разгребания авгиевых конюшен строят рядом ещё бОльшие...
> Быстрая скорость загрузки достигается именно за счёт параллельного запуска сервисов,
> что трудно организовать, используя классический SysV init.Ага, расскажите. Альт, SSD, i7, sysvinit. Впрочем, у грамотного человека может возникнуть искушение не читать дальше словосочетания "быстрая скорость".
> Анализ зависимостей сервисов требуется для ускорения загрузки
Скажите, пожалуйста, а зачем нужны затыки на загрузке? И особенно -- на выключении?
> Под сервисами я подразумеваю различные службы и приложения. Посмотрите,
> сколько у вас процессов на мобильном телефоне работает -- а, ведь, все их кто-то
> должен запустить. И systemd -- один из способов запустить их максимально быстро.Если бы Вы хоть немного понимали в том, что записали бездумно себе в резюму -- то сообразили бы, что "максимально быстро" и сколь-нибудь надёжно -- это всяко не в рантайме с графом разбираться, а фиксировать заведомо непротиворечивое состояние до выключения.
> К тому же удобно управлять сервисами: включать/выключать/запрещать.
Тридцать лет было удобно -- и наконец-то стало удобно.
Вот, например, вывод от systemd-analyze: https://lizards.opensuse.org/wp-content/uploads/2012/07/plot...А вот вывод от bootchart'а, который показывает, насколько загружен процессор в тот или иной момент: http://git.fenrus.org/tmp/bootchart-20120512-1036.svg
>> Профессионал должен уметь пользоваться всем.
> Вы умеете настраивать все системы инициализации? Профессионал должен быть способен изучить
> новый инструмент в разумный срок, но не как не уметь пользоваться
> всем.Согласен. Ваша формулировка точнее.
Я имел в виду всем, чем требуется для оптимального решения текущей задачи. А не ставить по-детски руки в боки: "Не хочу изучать поделку Поттеринга/RedHat'а!"
>На самом деле с хейтерами systemd картина печальная. Большинство из них не имеют никакой конструктивной критики, а просто не хотят изучать новое из-за кажущейся сложности.Вот достаточно конструктивная критика http://suckless.org/sucks/systemd
Конструктивно, от автора vdev - http://judecnelson.blogspot.ru/2014/09/systemd-biggest-falla...
> На самом деле с хейтерами systemd картина печальная. Большинство из них не имеют никакой конструктивной критики, а просто не хотят изучать новое из-за кажущейся сложности.На самом деле с фанатами системд картина еще печальнее. На любую критику у них одна реакция, типичная дя женских форумов - "тебе просто бабы не дают!".
Мысль о том, что критиковать могут и изучившие, для фанатов запредельна.>Каждый инструмент имеет свою область применимости. И умение профессионала и состоит в том, чтобы разобраться, когда и какой инструмент лучше использовать. Профессионал должен уметь пользоваться всем.
Можно совет от настоящего профессионала? На какой инструмент можно заменить инструмент systemd например в редхате?
>Но даже в этой ситуации есть плюсы. Мне, умеющему настраивать systemd, больше работы и больше денег достанется. А вы, да, продалжайте критиковать, не изучая. ;-) Вы пока меня минусуйте, а я пойду ещё какой-нибудь мануал почитаю. ;-) У меня есть в резюме строчка systemd, а у вас нет. ;-)
Как гласит надпись на писсуаром - "Не льсти себе. Подойди ближе."
>У меня есть в резюме строчка systemd, а у вас нет. ;-)Чувак да теперь весь мир у твоих ног че!
Фанат systemd суть дурак. Нам проще детектировать вас придурков и фильтровать.
> И мало ли, кому и что не нравится. Мне, вон, может grub2
> и dracut не нравятся. Вспомните, как просто было всё во времена
> lilo. Но я их изучил, и теперь спокойно использую.Лол. Ты используешь то, что тебе не нравится только потому, что ты это изучил? Я не столь принципиален, мне пришлось в прошлом изучить MSO и работать с ним, но когда необходимость отпала я перестал им пользоваться. И не собираюсь им пользоваться в дальнейшем, какими бы продвинутыми навыками использования MSO я не обладал бы.
100 лайков? Это типа "эй, проекты! Отказывайтесь от Systemd, всем нравится". А на самом деле столько лайков соберут только первые 5 проектов, а начиная с 10-го никто не будет обращать внимания на новость "Эй! Мы такие крутые, от Systemd отказались!"
> 100 лайков? Это типа "эй, проекты! Отказывайтесь от Systemd, всем нравится". А
> на самом деле столько лайков соберут только первые 5 проектов, а
> начиная с 10-го никто не будет обращать внимания на новость "Эй!
> Мы такие крутые, от Systemd отказались!"Да, согласен. Отказ от systemd должен быть рядовым обыденным решением. Как поход в туалет.
