Представлен релиз классической системы инициализации SysVinit 3.10, которая широко применялась в дистрибутивах Linux во времена до systemd и upstart, а теперь продолжает использоваться в таких дистрибутивах, как Devuan, Debian GNU/Hurd и antiX. Код написан на языке Си и распространяется под лицензией GPLv2. Версии применяемых в связке с sysvinit утилит insserv и startpar не изменились. Утилита insserv предназначена для организации процесса загрузки с учётом зависимостей между init-скриптами, а startpar применяется для обеспечения параллельного запуска нескольких скриптов в процессе загрузки системы...Подробнее: https://www.opennet.me/opennews/art.shtml?num=61625
> а теперь продолжает использоваться в таких дистрибутивах, как Devuan, Debian GNU/Hurd и antiXА используется ли в *BSD?
> SysVinit 3.10, которая широко применялась в дистрибутивах Linux во времена до systemd и upstart
Мне кажется, upstart работает поверх SysVinit. Могу ошибаться. А если прав, значит, в ChromeOS тоже завезут.
В BSD насколько я знаю своя система инициализации, но если пользователь достаточно опытен,он может попробовать установить openrc. Нет, upstart не зависит от классического init
В старых убунтах можно было использовать традиционные init-скрипты, но сразу возникало уведомление, что надо через upstart. Поэтому и подумал, что традиционный init там оставался.
Апстарт костыльный костыль.
ну апстарт юзает самый популярный десктопный линукс, да и красная шапка себе его на сервера утащила и ничего - пользовались и не жаловались...на самом деле в 10.04 он отлично работал, а вот в 9.х косяки были и приходилось костылями подпирать иногда...
> на самом деле в 10.04 он отлично работал, а вот в 9.х косяки были и приходилось костылями подпирать иногда...Мне он нравился прежде всего тем, что отлично выполнял свою задачу - распараллеливание загрузки. И при этом не пытался лезть, куда не просят.
> Мне он нравился прежде всего тем, что отлично выполнял свою задачу -
> распараллеливание загрузки. И при этом не пытался лезть, куда не просят.Поэтому в нем не было нормального логинга, интеграция с пакетником и зависимости были - никакие, и он сам периодически мог скушать свой же хвост, перетерев вон там админские изменения в конфиг проги от которой depends его сервис - и вот гадай, убабахает обновление загрузку или нет.
Если конечно ставить только программы от сапопикала - ноу проблем. Но как только хочется запустить свой сервис, которого в репах не было - начинается полный капец. Никакого адекватного логинга, никаких гарантий что это переживет апдейты, никакого обзора статусов сервисов в людском виде. Ни-че-го. И в результате наворотили - во, а достоинств - во. А вот вам тут еще cron - никак с этим не интегрированый - с еще полдюжиной дир на изучение. Удачи понять что откуда стартует в произвольно взятой системе. Очень удобно. Аж так удобно что все кто имел к этому отношение и полюбили системду. Ну а пользователей они немного забыли спросить.
> ну апстарт юзает самый популярный десктопный линукс,Вы б еще андроид вспомнили.
> да и красная шапка себе его на сервера утащила и ничего - пользовались и не жаловались...
Только потом системду написала, чтобы не так мучительно как в апстарте.
> на самом деле в 10.04 он отлично работал, а вот в 9.х
> косяки были и приходилось костылями подпирать иногда...Он "отлично работал" - но вписаться стартовать за вот этой БД - чтобы ей потом пользоваться в своем сервисе - ее услугами - можно только отредактировав стартовые конфиги этой БД. А потом гадать на кофейной гуще - прибье пакетник при апдейте базы эти изменения, или таки нет?!
Очень удобная система инициализации этот апстарт, особенно - вот - рюхание стартовых зависимостей. Настолько, что редхат и сделал systemd, с инверсным рюханием зависимостей. Так можно в СВОЕМ юнит-файле дописать от кого оно там depends, и совершенно пофиг перезапишет ли пакетник его конфиг. К тому же у них хватило ума разложить дефолты системы в /usr и админские оверрайды в /etc и пакетник их вообще никогда не трогает - так что уж точно не перезапищет, если они есть. Это был большой шаг вперед в менеджменте ОС. Нормальная интеграция этого всего с пакетниками, при том - любыми, и - вот - возможность зависимости нормально рюхать. А заодно нормальный обзор что откуда стартует и логинг. Убунты на это - не хватило, видимо фаза архитектуры в программировании - это совсем не для них.
х.з. в etc "само" не переписывало и ранее - админ мог переписать, не переписать или посмотреть diff и принять решение после этого.ЗЫ:
но вообще при кривом пакете тебе что хочешь и хоть где перепишет из постинсталл скрипта ;)
> х.з. в etc "само" не переписывало и ранее - админ мог переписать,
> не переписать или посмотреть diff и принять решение после этого.Это прикол такой? Там все стартовые файлы - в /etc лежат. И дефолтовые пакетником приносятся - туда же. Поэтому если поменять чужой кнофиг - вопрос что будет при апдейте той софтины как бы весьма отдельный. И ответ на него сильно зависит от... конфигурации пакетника, дистро, и вообще пакетника. И вот там возможны варианты. Потому что это само по себе - collision.
А когда системные дефолты в /usr а админские оверрайды в /etc - куда более разумно.
> ЗЫ:
> но вообще при кривом пакете тебе что хочешь и хоть где перепишет
> из постинсталл скрипта ;)А вот фиг. На уровне соглашений дизайна системды пакетники в принципе не таскают файлы для системды в /etc - это менеджится исключительно админом. А пакетник таскает их в /usr и это совсем никак не может переписать админские оверрайды.
Просто поттер хоть немного подумал об архитектуре своей штуки, в отличие от сапопикала. И когда автырям апстарта вот это вот в рассылке дебиана выкатили - им было асболютно нечем крыть. Ибо ни рюхание зависимостей ни интеграция с пакетником в таком виде "мелким патчем" не делается, это всю архитектуру надо в ноль разворотить и переделать. А когда тут уже системд с примерно таким и есть - ну, вот, апстарт и повыбросили даже из убунты. А что делать если с архитектурой совсем лажа вышла?
> А вот фигкто же мне запретит залезть из постинсталл скрипта в /etc ?
> Он "отлично работал" - но вписаться стартовать за вот этой БД - чтобы ей потом пользоваться в
> своем сервисе - ее услугами - можно только отредактировав стартовые конфигиа теперь и редактировать нечего. ExecPre=sleep 1000 наше всьо
Потому что внезапно твои "depends" работают совершенно не так как тебе мечтается (они вообще никак не работают, если честно) и изменить это поведение нормальным образом - нельзя.
Отдельно поизучай-ка тонкое отличие requres, after и wants. Не по полстраничке "документации" а как оно на самом деле работает и почему нельзя этим пользоваться вот как раз в твоем случае (для хеловротов иногда работает, но тоже могут быть нюансы).
Есть пара костылей с "condition", но про твою базу они ничего не слышали.
> А потом гадать на кофейной гуще - прибье пакетник при апдейте базы эти изменения, или таки нет?!
потому что твоя квалификация - нулевая. Иначе бы ты не гадал а посмотрел.
Впрочем, если твой гуаносервис не может просто подождать пока база станет доступна вне зависимости от причин - то тебе уже ничего не поможет.
Меняй профессию, сдавать бутылки у тебя должно получиться лучше чем админить сложные системы.
>> своем сервисе - ее услугами - можно только отредактировав стартовые конфиги
> а теперь и редактировать нечего. ExecPre=sleep 1000 наше всьоВо первых, ExecStartPre=, мистер "эксперт". Во вторых, я кажется понимаю почему пох не любит системду. Как говорится - "вы не любите кошек? вы просто не умеете их готовить!" :). Не, sleep 1000 это концептуально неверный подход - из мира ветеранюниксов, которые этот треш практиковали везде и всюду.
А, да, мне еще знакомый девопс мастеркласс дал - запилив на скорость честный startup notification и даже вачдог - за цук 5 минут в вон тот кастомный сервис. Вот это я понимаю, мастеркласс. Не то что твой нудеж.
> Потому что внезапно твои "depends" работают совершенно не так как тебе мечтается
Оно вполне нормально работает - ежели пользоваться нормально. Т.е. читанув ман и используя бошку. И ты уж прости, но это воон та мадам с ранчо без высшего образования - могет. Орудуя серваками как рыба в воде.
> (они вообще никак не работают, если честно) и изменить это поведение
> нормальным образом - нельзя.Нормально оно работает. Просто использование бошки не отменяли.
> пользоваться вот как раз в твоем случае (для хеловротов иногда работает,
> но тоже могут быть нюансы).Там может быть нюанс - если база долго взлетает, в виде когда вон тот уже считает ее стартанувшей, а реально еще нет. Нет, delay это не рюхается. Рюхается либо активацией сокетами, либо стартап нотификациями.
Да, конечно, можно сэкономить немного и нагамнячить с delay в стиле ветранюниксов. Но это то что называется - техдолг. Рафинированый и дистиллированый.
> Есть пара костылей с "condition", но про твою базу они ничего не слышали.
А есть еще пара способов - см выше. Наименее кривой, так то - честная стартап нотификация. Которую сервис должен кидать системде когда он реально готов работать. И чсх так можно сделать. А у сабжа - вообще нет такого понятия. Поэтому как кто засеквенсит такие вещи - да это его проблемы! Стандартных способов нет, каждый дp@4ut впpucядкy как умеет, сам. И получается ессно куда большая фигня в итоге. А когда васян совсем ушел... эээ... потом это знание древних вообще зачастую - утрачивается :))
> потому что твоя квалификация - нулевая. Иначе бы ты не гадал а посмотрел.
Мне нормальные регламенты таких взаимодействий, унифицированные и стандартизированные на всю ораву, как-то больше по вкусу. Когда условились что пакетники выкатывают дефолты в /usr а админ оверрайды в /etc. Это поцтер очень правильно сделал. Не понимаю почему до остальных такая простая вещь как до жирафов и надо цать лет и пинок под ж, чтобы осознать.
> Впрочем, если твой гуаносервис не может просто подождать пока база станет доступна
> вне зависимости от причин - то тебе уже ничего не поможет.Ну как бы это мог быть и не лично мой гуаносервис. Я мог лишь хотеть запилить сервис в систему, при том что его в пакетах штатно нет. И вот тут возможны разные варианты уже.
> Меняй профессию, сдавать бутылки у тебя должно получиться лучше чем админить сложные системы.
...сказал чудик, путающий директивы системды при попытке поумничать на тему :)
А, да, и кто же это потом будет ныть что тем протоколом с нотификациями "на системду все завендорлочили!!!111". Не знаешь? А я вот догадываюсь ;). И не, никакой пощады. Ибо у вон того вообще нет механизма этого. И вот это уже - ващи траблы. Самопальное секвенсирование таких вещей несколько надоело, скажем прямо.
> Во первых, ExecStartPreмне феерично по-й.
> Не, sleep 1000 это концептуально неверный подход -
зато он работает.
А костыли предусмотренные изготовителем - нет.> А, да, мне еще знакомый девопс мастеркласс дал - запилив на скорость честный startup notification
угу, в коде какого-нибудь postgres (речь для мастера передергиваний была о том что у недотепы стартует софт, использующий базу, а база еще занята перебиранием своими внутренностями, и предусмотреть в софте эту ситуацию нельзя, он эту маску же ж на стройке нашел)
Безусловно вот этой вот хренью страдать - гораздо лучше и эффективнее чем какие-то фунимодные баш скрипты - их-то кто угодно может поправить, а поделку твоего девляпса еще поди вообще найди в чужой незнакомой системе.
> А есть еще пара способов - см выше. Наименее кривой, так то - честная стартап нотификация.
разработчики переносимого софта под юникс системы, а не lin00ps only удивленно чешут репы - куда им ее пихать в какой-нибудь фре.
И да, напоминаю что это предлагается делать для поделки, основным уникальным достижением которой было заявлено спасение современных горе-разработчиков не умеющих ни в отсоединение от control terminal, ни в логи отличные от stdout. Это ж очень сложно и непонятно, вот стартап-нотификации мы умеем. Syslog не умеем.
И вот так у вас примерно всё.
OpenRC, хоть и с некоторых пор содержит реализацию init'а (/sbin/openrc-init), обычно используется в связке с чем-то вроде сабжа.
BSD не имеет отношения к sysvinit.Upstart не имеет отношения к sysvinit.
Ты же вроде давно на линуксе, откуда вопросы такого уровня?
У меня 2 компьютера 2 системы, один с Linux, другой с Windows OS. Я на опеннете запиливал новость про проприетарное программное обеспечение. Также, я позволял себе насмешливые высказывания в адрес Свободивцев.
> У меня 2 компьютера 2 системы, один с Linux, другой с Windows OS.Не думаю, что это кому-то интересно. А почему не дуалбут?
> Я на опеннете запиливал новость про проприетарное программное обеспечение.
Чел, у тебя профиль пустой.
> Также, я позволял себе насмешливые высказывания в адрес Свободивцев.
И Монолитовцев!
> У меня 2 компьютера 2 системы, один с Linux, другой с Windows
> OS. Я на опеннете запиливал новость про проприетарное программное обеспечение. Также,
> я позволял себе насмешливые высказывания в адрес Свободивцев.Круто! Виртуально пожимаю руку, особенно за последнее.
А то народ уже в своем фанатизме с катушек сьезжает.
> Круто! Виртуально пожимаю руку, особенно за последнее.
> А то народ уже в своем фанатизме с катушек сьезжает.Пожать руку фэйку зени? Вау, это шикарно было. Вы нашли друг друга. Капец, с такими юзерами проприетари - никакой антирекламы не надо, вы сами ходячая антиреклама.
> У меня 2 компьютера 2 системы, один с Linux, другой с Windows
> OS. Я на опеннете запиливал новость про проприетарное программное обеспечение. Также,
> я позволял себе насмешливые высказывания в адрес Свободивцев.Какой позор. Кто-то не придумал ничего умнее чем косплеить зенитара. Кошмар, куда катится этот мир.
> А используется ли в *BSD?Нет. В современных *BSD используется init, разработанный в NetBSD, там скрипты лежает в /etc/rc.d/.
До этого там был init из BSD4.3
>> а теперь продолжает использоваться в таких дистрибутивах, как Devuan, Debian GNU/Hurd и antiX
> А используется ли в *BSD?
>> SysVinit 3.10, которая широко применялась в дистрибутивах Linux во времена до systemd и upstart
> Мне кажется, upstart работает поверх SysVinit. Могу ошибаться. А если прав, значит,
> в ChromeOS тоже завезут.openrc в зависимостях от sysvinit, поэтому апосредованно также и в Gentoo она используется ;)
> А используется ли в *BSD?В *BSD тоже же инит с runlevels, но он кодово не связан и заточен под ядра конкретной ветки BSD.
HISTORY
An init utility appeared in Version 1 AT&T UNIX.CAVEATS
Systems without sysctl(8) behave as though they have security level -1.Setting the security level above 1 too early in the boot sequence can
prevent fsck(8) from repairing inconsistent file systems. The preferred
location to set the security level is at the end of /etc/rc after all
multi-user startup actions are complete.FreeBSD 13.2-RELEASE-p11 July 22, 2021 FreeBSD 13.2-RELEASE-p11
>> А используется ли в *BSD?
> В *BSD тоже же инит с runlevels, но он кодово не связанПонял, спасибо за ответ. Наверное, в каждой UNIX-like системе используется свой SystemV-like init.
> Понял, спасибо за ответ. Наверное, в каждой UNIX-like системе используется свой SystemV-like
> init.init, будучи вторым краеугольным камнем после ядра, во-первых, был частью концепции, а во-вторых, отражал развитие кодовой базы этих ОС. UNIX-like - это на самом деле только Linux, который был написан с нуля достаточно поздно, а BSD - имеют прямое сродство кодовой базы с UNIX, см. отсылку к AT&T в мануале и семейное древо: https://www.reddit.com/r/linux/comments/huhqrh/unix_family_t...
классический init - это часть религии UNIX. это очень маленькая и надежная кодовая база в районе 2000 строк кода. по сути выстрелил и забыл.
Linux просто копировал этот концепт, они ведь создавали OpenSource UNIX.
Замену такому init с runlevels стали искать только в XXI веке. В Solaris придумали замечательную вещь svcs. Это не замена, а надстройка над init с функцией супервайзера. Это то, что я хотел бы видеть в Linux.
В Mac OS - launched чисто для десктопа. Никогда не будучи поклонником UNIX Поттер спустя 10 лет активно копировал именно это.
А до этого в Linux упражнялись кто во что горазд: upstart, openrc и все прочее, что не полетело. А то, что полетело оказалось еще страшнее... systemd давно перевалил за миллион строк кода. Для меня просто вопрос времени, когда это решение громко рухнет.
BSD же не подпирали требования рынка и они, как пластинки, остались в XX веке. что мне в них и нравится.
Ого, подробный и развёрнутый ответ. Спасибо.> Замену такому init с runlevels стали искать только в XXI веке. В Solaris придумали замечательную вещь svcs. Это не замена, а надстройка над init с функцией супервайзера. Это то, что я хотел бы видеть в Linux.
В треде я так и не получил ответа, базировался ли upstart поверх SysVinit, или полностью его заменял. Если базировался - значит, он и был тем самым супервайзером, позволяющим делать загрузку многопоточной (стало актуально, когда на компах стало более чем 1 ядро процессора).
Насколько я знаю, конец upstart наступил не по причине технических недостатков (хотя они были, и выше в треде о них писали), а по политическим причинам. Во время ссоры между Red Hat и Canonical, первые заявили, что Canonical ничего не делает. Вторые ответили "а как же upstart, процесс no. 1 в вашем RHEL 6?". На что первые признали "таки да, Canonical что-то делает". И тут же начали разработку Systemd.
P.S. Что интересно, в последнем Дебиане на SysVinit (Wheezy) загрузка была многопоточная, а upstart не было. Как они это сделали, не понимаю. Так же в Mageia 1 (первая и последняя версия на SysVinit).
> конец upstart наступилХромоОС удивилась, так как в ней до сих пор используют :) Все же самый популярный десктопный линукс ;)
>> конец upstart наступил
> ХромоОС удивилась, так как в ней до сих пор используют :) Все
> же самый популярный десктопный линукс ;)а кодовая база upstart с 2010 года не обновляется. работает - не трогай?
почему с 2010? Как минимум до 14.04 апстарт активно пилился, да и после патчился как убунтой так и красно-шапкой (ведь у них 6ка на нем была).
Кстати, десктопный 16.04 на легких DE/WM с костыльками мог жить еще на апстарте, так как для серверного применения он в репе был/есть.
https://launchpad.net/ubuntu/xenial/+source/upstart
о, прошу прощения, с 2016 года! это все меняет!
https://chromium.googlesource.com/chromiumos/third_party/ups.../2024 пойдет?
> Ого, подробный и развёрнутый ответ. Спасибо.Да не за что, сам с интересом соображаю) Я всегда думал, что upstart - это просто скрипты поверх, но сейчас вижу, что upstart полностью заменял стандартный инит. Там был полностью свой бинарник с именем init, который внутри имел привязки к dbus.
Историю с RH vs Canonical я тоже помню, RH тогда презрительно ответили: подумаешь какой экзотический пример! Справедливости ради, это решение и правда казалось на уровне тех же openrc, таким же кустарным. Код и сейчас изобилует сокращениями NIH, что говорит о подходе.
А насчет дебиана, я думаю, ты что-то путаешь. Если шла многопоточная загрузка, то это уже был апстарт. Стандартный инит так не может. Видимо, где-то уже подмена стандартного init шла.
> А насчет дебианаМожет, боле того, еще в 2009 мог...
https://lists.debian.org/debian-devel/2009/09/msg00421.html
но тогда это было отключено по дефолту.
Сейчас включено по дефолту.
На простейших конфигах прироста по скорости загрузки не дает, но чем дальше в лес, тем толще партизаны.Сейчас десктопный devuan загружается и выключается не медленнее debian'a с тем же набором пакетов, а если у системди случается ее любимый косяк с 90 секундным таймаутом при включении или при выключении на каком-нибудь демоне, то devuan выигрывает раза так в 4 по скорости загрузки или завершения работы (смотря на какой стадии у системд затыки)...
>> А насчет дебиана
> Может, боле того, еще в 2009 мог...Эта инфа уровня анонимного поста, которым собственно твоя инфа и является. Какой-то скрытый (!) хак в рассылке. Если эта фича есть, где она документирована? Как реализована? Может, кто-то скрипт над инит какой-то наваял и все.
ну да.я взломал рассылку дебиана ради спора, или я украл машину времени и сам написал это сообщение в 2009 году...
> Может,
может стоит тебе не тупить, а посмотреть как это реализовано... вроде не секретная информация...
> Сейчас десктопный devuan загружается и выключается не медленнее debian'a с тем же
> набором пакетов, а если у системди случается ее любимый косяк...то его хотя-бы затраблшутить можно, в отличие от кучки скриптов по сути без логинга, и апстарта который так по жизни был не сильно лучше этого самого. И поскольку код шатдауна там сделан коректно - косяки по крайней мере видно. А не так что мы тут безусловно расстреляем все и вся из реактивного г@вномета, а то что вон там сервис посыпался из-за некорректного грубого вырубания на середине - типа не ваши проблемы. Зато это проблемы тех кто это все эксплуатирует.
Управление системой - это не только про время загрузки. Но и например, ответ на вопрос почему мой кастомный новый сервис в системе - не стартует. Или как например посмотреть а что вообще в вот именно этой системе стартует, и откуда берется. Или, например, глупо не отрезать сервис в отдельные namespace если уж ядро так умеет.
Поэтому с системдой вон тот сетевой сервис, даже если его прошибут, вместо /home увидит - пустоту. А вон те - затарятся всякими ключами ssh при случае, и проч. Такая разница.
> это не только про время загрузкивот тут ты не прав!
для фанбоев это была самая главная фишка - они носились по всем форумам с замерами времени - вот на 3 секунды быстрее - это прорыв - остальное же под капотом и фанбоям было не видно :)
Но массовое применение ssd решало проблему заметно лучше... а сейчас и при загрузке со старых hdd системде хвастаться нечем...
> для фанбоев это была самая главная фишка - они носились по всем
> форумам с замерами времени - вот на 3 секунды быстрее -Ну как бы я тоже вполне оценил время старта всего одноплатника в 5 секунд при том что я ничего особо и не делал специально. Просто довольно шустро стартует за счет параллельного запуска.
Рекордом это ессно не является, init=/your/app наамного круче. Вон там пример как в Qt программу за 0.3 секунды после ресета вваливаться. На ютубе видео есть, прикольно смотрится: после ресета экран немного мигает и на нем сново та же прога. Но. Гибкость такой boot sequence - как у чугуниевой рельсы, это вот реально "фирмвара фотика сони" получается. Т.е. от линуха по сути только ядро.
> это прорыв - остальное же под капотом и фанбоям было не видно :)
Как по мне так оно хорошо общим сочетанием. Много системного гемора с меня разгрузило.
> Но массовое применение ssd решало проблему заметно лучше... а сейчас и при
> загрузке со старых hdd системде хвастаться нечем...Массовое применение ssd никак не влияет на глупый туповэйтинг какого-нибудь DHCP с блокированием того что за ним стартовало например. Апстарт такие вопросы частично решал - но сделал вот именно секвенсирование кто за кем - максимально дурацки. Так что вписаться ЗА вон той прогой - это ЕЕ стартовый конфиг надо ковырять! Без регламентов гарантирующих что пакетник это не вынесет при апдейте той проги нахрен.
> DHCP с блокированием того что за ним стартовало напримерподожди, подожди, ты собрался монтировать по сети через NFS что-то еще до подъема сети? :)
если у тебя десктоп, то конечно, ждать DHCP это уныло - ведь может ты не будешь запускать браузер сразу чтоб котиков смотреть...
но и это надо править не в стартовых конфигах, а внезапно, в настройках сети...
Zenitur, вот еще немного подробностей об ините во FreeBSD. /sbin/init - запускает дерево rc-скриптов, начиная с /etc/rc. В нем в частности выполняется С-утилита /sbin/rcorder, которая ничего больше не умеет, кроме как прочитать скрипты и определить порядок запуска по меткам provides/depends/before/after из них. Может выдать список последовательно, может для параллельной загрузки. Все. Очень элегантно.
> классический init - это часть религии UNIX. это очень маленькая и надежная
> кодовая база в районе 2000 строк кода. по сути выстрелил и забыл.И это хреново. Инженерия не должна становиться религией с верованиями вместо рациональных решений.
> Linux просто копировал этот концепт, они ведь создавали OpenSource UNIX.
Вообще-то GNU расшифровывается как GNU is Not Unix. С самого начала.
> Solaris придумали замечательную вещь svcs. Это не замена, а надстройка над
> init с функцией супервайзера.Они еще помнится SMF сделали. Жуткий монстр с XML и кешированием в скулайт. Видимо только вон того не хватило?
> Это то, что я хотел бы видеть в Linux.
В опенсорсе кто хочет - тот и имплементит. Это же очевидно, не?
> В Mac OS - launched чисто для десктопа. Никогда не будучи поклонником
> UNIX Поттер спустя 10 лет активно копировал именно это.А существование SMF как вписывается в это все? Ну и поклоняться ради фиг знает чего - игноря насущные проблемы и вместо этого продвигая религии ни к чему хорошему не идет. Дело делают прагматики, а не религиозные фанатики.
очередной анонимный ноунейм, если ты мне в ответ на svcs пишешь про SMF, то слова твои не стоят ничего. я с этими технологиями работал, а ты из себя просто эксперта строишь. grow up. возьми на себя труд зарегиться, может, тогда я начну считать тебя чем-то большим, чем пятном на асфальте.
> очередной анонимный ноунейм, если ты мне в ответ на svcs пишешь про
> SMF, то слова твои не стоят ничего. я с этими технологиями
> работал, а ты из себя просто эксперта строишь. grow up. возьми
> на себя труд зарегиться, может, тогда я начну считать тебя чем-то
> большим, чем пятном на асфальте.Многовато пафоса. Но работая с этими технологиями ты почему-то ничего не сказал как тебе XML и кеширование в скулайт.
Есть категория людей которые предпочитают очень избирательный анализ технологий. Игноря неудобные моменты. И уважение этой категории людей мне, в общем то, ни к чему. Моя цель - сделать вас тем пятном на асфальте, в контексте IT. Вы это заслужили. Нет, двойным стандартам, вранью и полуправде - в опенсорсе не место. Мы любим его не за это. А высокомерные выскочки из тех проприетарных *nix вылетели на обочину за характерное соотношение апломба и скилла. Меня интересует уважение совсем других людей, не имеющих ничерта общего с такими как ты.
> В *BSD тоже же инит с runlevels, но он кодово не связанэксперты... даже читать не обучены, некогда-некогда спринтнеждет. Пару букв знакомых увидели, слово до конца дочитывать незачем.
> и заточен под ядра конкретной ветки BSD.
тоже нет. Он примитивен как палка. Как и должен был бы быть нормальный юникс софт.
Запускает /etc/rc и подбирает waitpid'ом бесхозные процессы. Больше ничего нет.
/etc/rc - обычный шелл-скрипт (вернее, это в обычных ситуациях, а так ему все равно, можешь бинарник с таким именем положить туда).> Setting the security level above 1 too
security level не имеет никакого отношения ни к иниту, ни к runlevels.
А кто этим сейчас пользуется из серьезных проектов?
Насколько я помню все значимые переехали на системмд.
> А кто этим сейчас пользуется из серьезных проектов?
> Насколько я помню все значимые переехали на системмд.Т.е. ChromeOS и ведроид теперь на системд? Вот это новости!
Т.е. бабуинту теперь не значимый?
по сравнению даже только с одной хромоосью - абсолютно не значимый.https://cdn.statcdn.com/Infographic/images/normal/24228.jpeg
Не думал что бабуинту стоит виосновном на серверах? Подумай об этом на досуге.
что и куда ставят бабуины от айти не очень интересно.
Держи в курсе.
Эта инфограмика для штатов?
нет это мировая ковидная когда у хромооси пик был. Так как на корпоративных машинках она чувствует себя хреново, то после выхода ковида ее доля просела...
А они на sysvinit когда-то успели переехать?
а причем тут сабж?в них не используют системдю и при этом имеют отличную долю рынка...
а вот системдя, которая должна была прям вот, по мантрам фанбоев, совершить революцию и таки победное шествие устроить...
но в общем и целом шествия не получилось... на серверах, где до системды линукс рулил и сейчас рулит, на десктопе как не было серьезной доли так и нет...а сабж как использовали, так и будут использовать...
Не-не, тут нарушение логики. Исходный вопрос:
"А кто этим сейчас пользуется из серьезных проектов?
Насколько я помню все значимые переехали на системмд."
Ответ про хромось и андроид плюс-минус соответствует второй строке но никак-никак не первой - ни то, ни другое sysvinit не использовало и переехать с него на systemd не могло хотя бы по этому.
Как-то так.
> Ответ про хромось и андроид плюс-минус соответствует второй строке но никак-никак не
> первой - ни то, ни другое sysvinit не использовало и переехатьХромось-то, с ее апстартом как бы, под капотом и пользует сабж.
>> Ответ про хромось и андроид плюс-минус соответствует второй строке но никак-никак не
>> первой - ни то, ни другое sysvinit не использовало и переехать
> Хромось-то, с ее апстартом как бы, под капотом и пользует сабж.У хромоси так то рыночная доля - сливается. А так все хорошо прекрасная маркиза.
рыночная доля сливается только на фоне ее всплеска при домашнем ковидо-сидении, когда ноутбуки с хромоосью покупали как не в себя
> А кто этим сейчас пользуется из серьезных проектов?
> Насколько я помню все значимые переехали на системмд.Весь мейнтсрим, да, переехал, но всякие экзотичные проекты есть не на systemd, и не обязательно только на sysvinit.
>А кто этим сейчас пользуется из серьезных проектов?Slackware Linux.
Подумываю перейти с openrc на systemd, подводные камни?
Никаких, одни преимущества.
systemd намного более сложный и запутанный при отсутствии каких-либо преимуществ.
ДВС тоже намного более запутанный, чем паровой двигатель. Ты всегда можешь это доказать, сделав более эффективный авто на пару. Аналогия понятна?)
Не очевидно что твоя аналогия эквивалентна.
Паровой двигатель сложнее и опасней. Поэтому от них отказались.
Паровой двигатель можно собрать из овна и палок. А современный ДВС сделать сложно. Это тебе так кажется, что он прост.
Давай тогда современную турбину для сравнения.
Сравнивать нужно сопоставимое по времени.
> Давай тогда современную турбину для сравнения.
> Сравнивать нужно сопоставимое по времени.А что в этом сравнении не так?
Инит системы это прошлое поколение. СистемДи это современное поколение.
Был паровой двигатель, сделали ДВС.
ДВС сложней Парового двигателя, это база.
Системда не имеет преимуществ. Сто раз спрашивал - только слова про прогресс и мою ретроградность. Если есть покажи.Паровая машина сложнее двс. Я имею в ввиду юзабельные экземпляры, а не опытные образцы. Простейшие двс тоже вполне примитивны, как для мопеда. Минимум частей, один цилиндр.
> Системда не имеет преимуществ. Сто раз спрашивал - только слова про прогресс
> и мою ретроградность. Если есть покажи.Скорей всего ты тупо не хочешь слышать аргументы.
Попробуй прочитат плюсы.Параллельный запуск сервисов
Управление зависимостями
Службы сокетов и D-Bus
Управление журналами
Управление ресурсами и изоляция процессов
Предоставляет единый формат конфигурации и управления
SystemD может автоматически перезапускать службы в случае их сбоя
Модульность и расширяемость, SystemD разработан как модульная система что позволяет легко добавлять новые функциональные возможности и расширения.В то время как у SysInit
Сервисы запускаются по очереди.
Управление зависимостями занимается администратор.
Запуск сервисов через сокеты и D-Bus не существует.
Для SysInit нормально запустить неиспользуемый сервис.
SysInit использует для логирования службы syslog, rsyslog, или syslog-ng, настроить их надо отдельно. Не настроил, твои проблемы. Настроил криво, твои проблемы.
SysInit не может напрямую управлять ресурсами и не имеет изоляции. Можно организовать через отдельные утилиты. Сделал молодец, не сделал, кто с тебя спросит.
Козырь SysInit это управление через портянки скриптов. Удобно аж жопа горит.
у SysInit нет перезапуск служб, пофигу что с службой, сдохла ну и фиг с ней. Перезапуск делается через левый софт.
SysInit не модульная система.Теперь услышал ретроград?
> Паровая машина сложнее двс. Я имею в ввиду юзабельные экземпляры, а не
> опытные образцы. Простейшие двс тоже вполне примитивны, как для мопеда. Минимум
> частей, один цилиндр.Ты о паровой машине и ДВС вообще ничего не знаешь, если считаешь ДВС простой вещью.
Upstart делал параллельный запуск.
Управление зависимостями не нужно, как и многое другое. Службы для логирования тоже сомнительно преимущество, другие скажут, что это нарушение юникс-вея, когда одна программа для задачи, а не комбайн. Тоже самое и с перезапуском. Скрипты - а в системде разве не нужно что-то аналогичное? Только бинарное?
Короче не убедил.Ты про паровые машины ничего не знаешь, если считаешь простой вещью паровой двигатель. И безопасной. Сколько людей ошпарено до смерти, сколько на куски разорвало при взрывах котлов. И сколько времени нужно чтоб запустить, особенно зимой. И воду желательно специально подготовить чтоб не образовался известковый осадок на стенке котла, вызывая локальное изменение тепловых градиентов, что черевато как раз взрывом. Или промывать надо специальными реагентами после недолгой поездки. А в паровиках замкнутого цикла надо дистиллированную использовать или специальный теплоноситель. Котел тоже не кастрюля, а целая система трубок.Офигенно просто.
https://myskillsconnect.com/poezda/9277-foto-kotel-parovoza-...Ради КПД такая сложность. Сравни с дизелем той же эпохи.
Пилять, ну сравни уже наконец простейший юнит с простейшей баш портянкой инита и прекращай хрень молоть. Хотя ты и сейчас тут на опеннете написал целую бесполезную портянку, прямо как баш в ините
Параллельный запуск - хм, а в чём прикол? любая init-система запускает, ну допустим, 100 юнитов. Есть зависимости - что то требует работающее другое. 90% системных юнитов должны запускаться в определённом порядке. Условно - этапы - R/O, диск, FS, сеть, сетевые сервисы.
эм, продолжим
да, в условиях, когда каждая секунда на счету, параллельный запуск - ну прямо то, что может привлечь на путь замены системы инициализации.>Управление зависимостями vs Управление зависимостями занимается администратор.
Вот не верю, что SysInit запускает всё в алфавитном порядке, а отважный одмин каждый раз зависимости указывает.
>Запуск сервисов через сокеты и D-Bus vs не существует - а зочем это? Что именно вдруг понадобилось запускать именно таким способом? То есть, не-рут процесс вдруг хочет запустить или остановить системный сервис. Почему?
>Для SysInit нормально запустить неиспользуемый сервис.Это как? Либо сервис enabled, тогда он кому-то был нужен, вероятно, автору сборки ОС. А админ не отключил его. Либо disabled, тогда запуск такого сервиса - грубейшая ошибка в системе. Такое уж точно в прод не пошло бы. Или предполагается вариант 'random start'?
>SysInit использует для логирования службы syslog, rsyslog, или syslog-ng, настроить их надо отдельно. Не настроил, твои проблемы. Настроил криво, твои проблемы.
опять отважный одмин должен сам всё настроить. Из коробки, конечно, ни одна из этих служб не настроена.
>Управление журналами
полная противоположность предыдущему :) /sarcasm
Также всё настроено. Только управлением журналами занимается какой нибудь newsyslog вместо system-logrotate или что там вообще>Управление ресурсами и изоляция процессов
Етить-колтоить, а целое ядро операционной системы этим не занимается совсем, да?
>Предоставляет единый формат конфигурации и управления
Как и другие init
>SystemD может автоматически перезапускать службы в случае их сбоя
Вот это полезно, пожалуй.
>Модульность и расширяемость, SystemD разработан как модульная система что позволяет легко добавлять новые функциональные возможности и расширения.
:)))) Модульность и расширяемость, (любой скриптовый инит систем) разработан как модульная система что позволяет легко добавлять новые функциональные возможности и расширения.
Итого, всего два агрумента похожи на правду, остальное - булшит.
>Козырь SysInit это управление через портянки скриптов. Удобно аж жопа горит.
о, кстати, вспомнил...
iptables в одном месте настраивал
ubuntu вроде бы была
все команды на добавление правил добавлялись ... тада ....
в unit-файл systemd-iptables (ЕМНИП так назывался)
Удобно аж жопа горит.
Чел, я тебе начал отвечать, но потом понял, что ты классический пример линуксового проклятия
- Мне не надо, значит это плохо и не нужно.
Да.
Мне не нужен булшит и маркетинг. Из примерно 8 аргументов 2 заслуживают внимания. Остальное шлак. 75% шлака. Вот такое вот проклятие
> Да.
> Мне не нужен булшит и маркетинг. Из примерно 8 аргументов 2 заслуживают
> внимания. Остальное шлак. 75% шлака. Вот такое вот проклятиеТы неадекватный!
Если тебе не нужно, это не значит, что шлак.
Продукт делается для широкого круга задач, а не для тебя.
Блин, неадекватный тут ты.
Я два раза сказал - ваши (systemd-агитаторов) аргументы gov.no. Потому что берёте их из методички и не думаете. Совсем.Пример - ты говоришь о том, что systemd делает параллельный запуск, SysVinit не делает.
Разуй глаза. Прямо в конце первого абзаца новости - "startpar применяется для обеспечения параллельного запуска нескольких скриптов в процессе загрузки системы". То, что это отдельный модуль, а не часть запускатора - шок, да? Это, кстати, "Модульность и расширяемость" :)Пример - я троллю, что сравнение фичи "Управление зависимостями" сформулировано отстойно. Ты ведёшься.
Ты не понимаешь (и не говоришь об этом), что преимуществом systemd является учёт того, что при запуске сервиса, зависящего от другого, тот, другой, действительно запущен. Systemd так делает. Windows service manager так делает. SysVinit так делает? Нет. Он только учитывает последовательность запуска, а не зависимость от статуса.Ну что, я хейтю systemd или <s>хейтю</s> троллю отстойных агитаторов?
> Блин, неадекватный тут ты.Да да, это я тут кричу не нужно потому что цвет фломастера не красивый. У тебя адекватность так и хлещет.
И это все твои аргументы овно.>startpar применяется для обеспечения параллельного запуска нескольких скриптов в процессе загрузки системы". То, что это отдельный модуль, а не часть запускатора - шок, да?
Шок контент то что должно быть из коробки надо админу ставить отдельно и настраивать. Гениально!!!
так то твой обос*аный SysVinit весь состоит из модулей, ну как из модулей, отдельный приложений, где ты должен склеить овном в одно целое и надеется, что оно будет работать.
Это гениально!>Пример - я троллю, что сравнение фичи "Управление зависимостями" сформулировано отстойно. Ты ведёшься.
Я тебе сразу сказал, ты неадекват. Что ты и подтверждаешь! Молодец.
>Ну что, я хейтю systemd или <s>хейтю</s> троллю отстойных агитаторов?
ты забыл штаны снять, обос*ался ты.
> Предоставляет единый формат конфигурации и управленияА еше - логит выхлоп сервисов по дефолту, равно как и дает overview что вообще творится в вот этой системе.
В SysV вы сами чешете репу почему вон тот сервис не стартует - и дописываете логинг проблем старта самолично, just in case. А уж посмотреть что откуда и почему стартует - да щас. А потом еще окажется что есть какая-нибудь лабуда типа крона, и вот вам еще полдюжины дир на обзор, потому что возможно "авторестарт" сервиса сделали - как пинок из крона. А чтоб вам не скучалось, эта пакость еще своей периодикой будет в логи спамить. Даже если и не делала нихрена. За сам факт существования. И тут вдруг оказывается что можно сделать systemd.timers - без всех этих мучений. Да еще легко навесив его в пару вот именно этому сервису.
>[оверквотинг удален]
> В SysV вы сами чешете репу почему вон тот сервис не стартует
> - и дописываете логинг проблем старта самолично, just in case. А
> уж посмотреть что откуда и почему стартует - да щас. А
> потом еще окажется что есть какая-нибудь лабуда типа крона, и вот
> вам еще полдюжины дир на обзор, потому что возможно "авторестарт" сервиса
> сделали - как пинок из крона. А чтоб вам не скучалось,
> эта пакость еще своей периодикой будет в логи спамить. Даже если
> и не делала нихрена. За сам факт существования. И тут вдруг
> оказывается что можно сделать systemd.timers - без всех этих мучений. Да
> еще легко навесив его в пару вот именно этому сервису.тупо плюсую!
Я вот уверен, что большинство хейтеров, никогда такими вещами не занимались. Максимум в интернете читали. Отсюда и весь хейт.
Системг устарело и уйдет за пшпшаудио. Современные иниты это dinit, s6, shepherd.
> Системг устарело и уйдет за пшпшаудио. Современные иниты это dinit, s6, shepherd.Мечтай)
Турбина изначально была придумана как сильно более простой двигатель по сравнению с ДВС, ибо ДВС большой мощности превращается в лютый звездец (компоновка в виде звезды в несколько слоёв, а не то что Вы подумали), но для авиации ещё и тупо упирался в возможности дальнейшего развития. Правда турбина довольно быстро усложнилась, но задачу решила. Оптимальна не для всякого применения, но где то неё никак.То же с SysVinit, по мере увеличения задач, скрипты усложнялись и распухали.
И если для встраиваемого контроллера initd нафиг не сдался, а достаточно upstart, а то и init, то для десктопа уже SysVinit не очень оптимальный выбор.В общем, нужно и то и другое, в зависимости от оптимальности для решаемых задач.
>То же с SysVinit, по мере увеличения задач, скрипты усложнялись и распухали.Фантазёр. SystemD был запилен лишь, как клон загрузочных init-файлов Wondows OS. Леннар Поттеринг поклонник всего виндовозного.
Добро пожаловать в реальный мир!
За что ему было сниспослано жалованье от любимой им мелкомягкой конторы.
> Фантазёр. SystemD был запилен лишь, как клонКлон или не клон. Хотели замену проще в настройке, легкую и удобную. Что могло пойти не так? :)
>>То же с SysVinit, по мере увеличения задач, скрипты усложнялись и распухали.
> Фантазёр. SystemD был запилен лишь, как клон загрузочных init-файлов Wondows OS.Есть только 1 небольшой нюанс: у винды нет "загрузочных инит файлов" как таковых. Есть - реестр и "services control manager" (SCM). У этого извратика сервисы, внезапно, DLLки (shared lib) кстати. Ну так по изначальной задумке. Кто майкрософту сказал что это круто - хрен его знает, но в какой-то момент они заметили что так если падает 1 приблуда то мрет - весь процесс, со всей оравой. Так появился svchost, хост-процесс для "сервиса", чтобы падал только 1 сервис. Не, в линузе до ТАКОГО не доперли. Совсем. И редактируется эта хрень только регэдитом, кривым и неудобным.
В этом смысле читаемые конфиги, редактируемые чем угодно, да еще с маном - EPIC WIN. Не, на ключи реестра вообще описания нет. По памяти хреначьте, или как вам там угодно.
Сделай мне Pratt & Whitney R-4360 или уменьшеный аналог образца начала 1940-х, или Jumo Ju-224, не важно сколько блоков
М501 не предлагать!
Тебе дизель-молота должно быть достачно чтоб понять что паровоз сложнее.
> Сделай мне Pratt & Whitney R-4360 или уменьшеный аналог образца начала 1940-х,
> или Jumo Ju-224, не важно сколько блоков
> М501 не предлагать!Зачем ты мне это пишешь?
Это не паровые двигатели
Забавно, что сравнивать предлагается "паровой двигатель из овна и палок" с СОВРЕМЕННЫМ ДВС :).
Если сравнивать одногодок - то "все не так однозначно"
Не сложнее, чистая гидродинамика. Его собирают из изоленты и кастрюли.
И что он сможет сдвинуть? Мопед или авто?
> Аналогия понятна?Нет, не понятна. Объясните пожалуйста.
Аналогии - они как коммунизм. Красиво звучат в голове автора и абсолютно не работают в реальном мире.
Аналогии всегда ложны. Ваша аналогия тоже ложна.
И где эти ваши эффективные теплоэлектростанции на ДВС?
Тебе какие нужны? ДГУ, газопоршневые или бензиновые? Стационарные или передвижные?
> Тебе какие нужны? ДГУ, газопоршневые или бензиновые? Стационарные или передвижные?У них у ВСЕХ кпд - издевательский. Например, по сравнению с электрическими технологиями. Где КПД двигателя, трансформатора, аккуммуляторов и проч за 90% никого не удивляет.
Подводных камней нет, за исключением того, что с системдой жить станет чуточку скучнее: там всё просто работает, и баш-портянить необходимости не будет. Придется придумывать, на что потратить гигантское количество освободившегося времени.
Как там, нетворкди научилась перебивать сетевой адрес без ребута? Или тот же ссш, пока сокеты не положишь не хочет принимать новые настройки?
Ты кажется путаешь systemd и systemd-networkd. Это два разных продукта.
Из одной коробки.
Из разных пакетов.
networkd - это не совсем systemd, это около.
А в чём проблема-то? Всегда перебивала :D
>Придется придумывать, на что потратить гигантское количество освободившегося времениНа написание и настройку unit портянок
А они декларативные, поэтому легко переносятся между дистрибами и средами. Хоть погуглил бы)
М-м. Берем какой нибудь минимальный desktop. Ставим на базе openrc или sysvinit. Получаем около 20 башпортянок длинной ну строк 50 максимум. Если не 1с там портянка так портянка, но она и в systemd не то чтобы прям так уж короче, просто в отсутствии интерпретатора запихали все параметры в одну строку с командой вместо того чтобы генерить их скриптом. Берем этот же desktop и получаем 50+ юнитов и далеко не все стартуют из /etc. Часть еще из /usr. Ну юниты то проще и очевиднее, просто их дохрена и связи между ними далеко не всегда очевидны. Понадобились даже дополнительные инструменты вроде *ctl.
Переносятся? Три раза ХА. Что-то простое переносилось и так. Умеешь писать bash-портянки нет никакой проблемы написать upstart или openrc или runit ... да хоть bsd портянку. В остальных случаях будешь прибит гвоздями к особенностям дистрибутива:
- этого старая версия systemd;
- у этого старое ядро.
- этот использует параноидальные патчи безопасности.
- этот networkd, тот NetworkManager, а этот netifrc.
- этот timesynkd, chrony, а этот openntpd.
- этот apparmor, этот selinux, а тот уже контейнеры/виртуализацию для каждого приложения использует.
- этот пакетный, тот обновляется атомарно;
- этот все еще на пульсе, а тот уже на pipewire.
А не совпадающие версии системных библиотек?
В итоге мы объявили стандартизацию и променяли шило на мыло. Debian и Ubuntu используют один инит и один пакетный менеджер(не смотря на snap), но сомневаюсь что для большинства хоть сколько либо сложных приложений можно собрать универсальный deb. А если и можно было так ему было пофигу какой init.
На мой взгляд в угоду "стандартизации" принесли в жертву unixway. "Делай одну вещь,но хорошо"
Так что systemd - это такой init для недоучек. Как и все остальные его костыли. Каждый из них не дотягивает по функционалу, до любого другого приложения функции которого взял. Но при этом если ты не особо взыскателен, то можешь использовать этот функционал. Но тогда не надо мне говорить об его универсальности.
Это да. Но. Пойми под лялексом требовался svhost. Сисьд это он. Все остальное побочка.
Опять манипуляции.
Все претензии к СистемДи, ровно ложатся и умножаются кратно в ваших любимых инитах всяких.
Причем ситуацию там усугубляется тем, что несовместимость там даже среди одной мажорной версии. Шаг влево, шаг вправо, иди нафиг, кто ты такой.Но удобно говорить, какой плохой СистемДи, который пытается устроить совместимость. И кстати делает это.
> Опять манипуляции.
> Все претензии к СистемДи, ровно ложатся и умножаются кратно в ваших любимых
> инитах всяких.
> Причем ситуацию там усугубляется тем, что несовместимость там даже среди одной мажорной
> версии. Шаг влево, шаг вправо, иди нафиг, кто ты такой.
> Но удобно говорить, какой плохой СистемДи, который пытается устроить совместимость. И кстати
> делает это.Мои иниты не пытаются везде пролезть без мыла и взять на себя функционал не свойственный
> Мои иниты не пытаются везде пролезть без мыла и взять на себя
> функционал не свойственныйЭто ты так мечтаешь! Как напишешь скрипты так и будет он работать. Никто не мешает написать скрипт взлома пентагона.
Как обычно ретрограды пытаются манипулировать, но как всегда нагадили себе в штаны.
> Мои иниты не пытаются везде пролезть без мыла и взять на себя
> функционал не свойственныйНу я и пользуюсь системдой. Чтобы самому в i++ раз не решать уже давно решенные другими задачи, и вписав пяток строк конфига - заняться чем-то более интересным чем ЭТО.
Нет, вы знаете, написание aux crap скриптов - моим хобби не является. А переизобретение великов, тем более с квадратными колесами - и подавно. И даже апгрейд до треугольных мне как-то так себе.
> Ну я и пользуюсь системдой. Чтобы самому в i++ раз не решать уже давно решенные другими задачи, и вписав пяток строк конфига - заняться чем-то более интересным чем ЭТО.Так а с чего ты взял что твои задачи решены системдой, Вот мне не нравится когда при повреждении системного раздела системда вызывает консоль админа вместо того чтобы тихо починить раздел в соответствии с настройками вродке forcefsck. Нет я конечно понимаю мантейнеры криворуки и все же почему они не додумывались до этого до прихода системГ?
> Так а с чего ты взял что твои задачи решены системдой,С того что я имею свойство тестировать что настряпал - и даже юзаю свои технологии для себя. Чтобы быть в курсе как это РЕАЛЬНО работает вдолгую, и вообще.
> Вот мне не нравится когда при повреждении системного раздела системда вызывает консоль
> админа вместо того чтобы тихо починить раздел в соответствии с настройкамиУ меня на допустим одноплатниках - ничего такого и близко нет. Они вообще никаких вопросов никогда и никому при старте не задают. Потому что некому и некуда. Это с системдой. И?
> вродке forcefsck. Нет я конечно понимаю мантейнеры криворуки и все же
> почему они не додумывались до этого до прихода системГ?У этого моего btrfs - fsck вообще "no-op". И я считаю это жирной фичой. Все рекавери как максимум сводится к отбрасыванию незавершенных записей. На этом рекавери ФС завершается. Это то как должны работать нормальные современные системы. Не, мануально что-то там где-то педалировать в таких вещах я в принципе не собираюсь. Системы должны выходить на режим без участия человека.
>> Мои иниты не пытаются везде пролезть без мыла и взять на себя
>> функционал не свойственный
> Ну я и пользуюсь системдой. Чтобы самому в i++ раз не решать
> уже давно решенные другими задачи, и вписав пяток строк конфига -
> заняться чем-то более интересным чем ЭТО.
> Нет, вы знаете, написание aux crap скриптов - моим хобби не является.
> А переизобретение великов, тем более с квадратными колесами - и подавно.
> И даже апгрейд до треугольных мне как-то так себе.Но все же в моем devuan такого не наблюдается. Сколько бы раз не выключили свет почини раздел и загрузимся мем более что корень на reaid1. А вот про системГ таукого сказать не могу.
> Но все же в моем devuan такого не наблюдается. Сколько бы раз
> не выключили свет почини раздел и загрузимся мем более что корень
> на reaid1. А вот про системГ таукого сказать не могу.А я юзаю btrfs и там вообще нет такого понятия как "починить раздел". В CoW механике это просто не требуется, все что требуется это забыть про недописаный хвост, семантически эквивалентно откату полного журнала в чуть более старое состояние.
Это немного ортогонально системде, системные проблемы можно на разных уровнях решать. И да, просто для понимания - powerloss тесты одноплатника включали в себя 1000 внеплановых ребутов на девайс (конечно, сие автоматизировано вон тем МК дергавшим силовой ключ, не сам же я буду щелкать, право).
> init для недоучектак его за этим и сделали как и гоязык. куча народу с меньшим уровнем образованности, но в жёстких рамках, сделает в итоге больше работы, чем два умнейших человека с развязанными руками. умные и пилят эти жёсткие рамки. а всякие юниты пусть июни набивают - им нужно клавиатуру изучать
>> init для недоучек
> так его за этим и сделали как и гоязык. куча народу с
> меньшим уровнем образованности, но в жёстких рамках, сделает в итоге больше
> работы, чем два умнейших человека с развязанными руками. умные и пилят
> эти жёсткие рамки. а всякие юниты пусть июни набивают - им
> нужно клавиатуру изучатьну я бы тут не стал клеймить ЯП. Для каждого существует ниша. Я пришел в Go после программирования на Shell. Банально это был самый простой и функциональный язык. например на нем можно было без геморроя запрограммировать процедуры выполняющиеся параллельно без всяких import "библиотека для распараллеливания чего либо". Плюс он позволял тогда выпонитть код от Nt4 до win10 много языков пограммируемых или интерпретируемых ты знаешь с таким диапазоном и без установки runtime. Плюс синтаксис C/С++, так что с него проще начать решать задачи, а потом переходить к другим c-подобным языкам, как знать. В случае с системГ я такого не наблюдаю Навыки в написании юнитов не пригодятся в написании init-скриптов, и наоборот навыки в написании init-скриптов пригодятся в написании юнитов.
Хоть попробовал бы "перенести между дистрибутивами".это чудище везде разных версий с разными оторваными частями, да ещё и смотано в клубок декларативных портянок.
Блин, а можно выражаться не в гуманитарном стиле общими словами?
>везде разных версийГде везде? Как версия влияет на юниты?
>с разными оторваными частямиКакими частями?
>смотано в клубокЧто такое клубок? Это технический термин?
>декларативных портянокОксюморон. Портянка - это описание алгоритма. Декларативный синтаксис описывает результат, а не алгоритм.
Баш-портянить? Openrc?
Подвоных камней целое дно, начиная от овер-инжинирнг дизайна, кривого спагетти-кода и всякими ошибками, когда ФС не может отмонтироваться при ребуте
Собственно, у меня и сейчас, если своп был заполнен, не успевает отмонтировать до перезагрузки и сыпет ошибками без особых причин даже когда успевает, а если нет, при загрузке ещё минут 10 на восстановление журналов. Если это невозможно, то ждём час без журнала (ext4). Есть ещё развлекуха, когда драйвер бесперебойника у NUT отваливается, без перезагрузки восстановить сервис квест ещё тот. Использование cgroups несколько костыльно с openrc выглядит (в теории конечно нормально, но не удобно). Кеды очень плачутся, что не могут найти инит.
Замечал что те у кого свап, ноют воообще обо всем.
> Замечал что те у кого свап, ноют воообще обо всем.У меня своп, не ною. Что я делаю не так?)
> У меня своп, не ною. Что я делаю не так?)Учитывая, что свопа нет только у совсем уж инвалидов (ну и тех, кому микрозадержки бд нежелательно и приходится держать весь мусор в памяти), достижение так себе.
>> У меня своп, не ною. Что я делаю не так?)
> Учитывая, что свопа нет только у совсем уж инвалидов (ну и тех,
> кому микрозадержки бд нежелательно и приходится держать весь мусор в памяти),
> достижение так себе.На десктопах своп ненужин, он медленный, оператива всё равно быстрее. А вот инвалиды те, кто не может толком объяснить зачем он нужен на десктопах, когда оперативы вагон, а если не вагон и её не достаточно, то тогда кто тут ещё инвалид, раз пользуется такими костылями и страдает от затупов системы?!
А чего тут объяснять? Вполне успешно обосновывают каждый раз, из того, что я видел. Просто те, кто поумнее, понимают, что отключение свопа сказывается исключительно негативно. Памяти ведь не хватает для ряда редких операций, вот и нужен раз в неделю. И её всегда будет не хватать, независимо от того, сколько вагонов в наличии. Когда памяти достаточно, в нём будут лежать только данные, которые никак не используются и не могут вызывать заметных задержек. И больше ресурсов выделяется под полезные данные, вроде файловых кэшей.Затупы из-за свопинга меня беспокоили только на венде (но у неё любая дисковая активность это затупы), если свопинг на линуксе вызывает ощутимые задержки, вероятно, что-то не так настроено (какой-нибудь bfq включен или что-то подобное). Либо памяти совсем недостаточно: к примеру, какие-нибудь неиспользуемые паки текстур в игрушечке вполне могут полежать и в свопе, но если данные активно используются и модифицируются, задействование свопа может быть сопряжено с определёнными неудобствами.
Конечно, большое значение имеет скорость носителя. Для свопа на ссд обычно приоритет, на быстрых жёстких дисках во вторую очередь размещается, на медленные вообще не стоит. Я использую ссд только когда необходимо "добавить памяти", в остальных случаях своп на магнитных дисках норм. Бонусом, когда веббраузер в очередной раз протекает на тысячи гигабайт, у меня есть время отреагировать и прибить проблемный таб без нарушения работы остальной системы (есть фоновые программы, очень негативно относящиеся к фризам, в частности, это относится к программам, задействующим sqlite). В некоторых случаях oom-killer может так и не прийти, сколько часов его ни жди.
Пример. Пусть есть система с 8ГБ ОЗУ и игра, ну например Скайрим.
ОЗУ 8ГБ ей за глаза хватит, но заработает и на 1ГБ.
Разница в скорости будет приличная, ибо кэши поменьше будут, что то будет часто подгружаться с диска.
Но формально, и 1ГБ ОЗУ хватает. :)
В фоне работают браузер и офис (игра у нас просто как пример приложения).
Браузер тоже работает даже при доступном ОЗУ 1ГБ, хуже чем когда памяти много, но точно работает.
И тут возникает ложное чувство что памяти всем хватает.
А ведь, будь ОЗУ больше, работало бы быстрее.Но когда в своп уходит неиспользуемая память, а активное приложение получает больше физической памяти быстродействие то взлетает.
Еще приложения очень часто запрашивают памяти сильно больше чем используют, ну например выделяют избыточные буфера, что б точно не переполнилось. В случае с ОЗУ эта память пропадает. В случае со свопом она выделяется в свопе, и если приложение её так и не использовало, то туда даже обращения не делаются, а физической памяти для приложений больше остаётся.
Исключение. Если активному приложению, для оптимальной работы, требуется памяти больше есть в системе, то никакой своп не поможет. Своп это не замена ОЗУ.
Мак М1 8/256 тому наглядный пример, на 8ГБ игры в виртуалках люто тупят, несмотря на "быстрый своп", а на моделях с 16ГБ ОЗУ уже летают. :)И конечно, если ОЗУ тупо много, то нужды в своп нет. При наличии 64+ ГБ ОЗУ своп сегодня для десктопных задач не нужен.
Но если в ноутбуке всего 16ГБ ОЗУ, а работают не с офисом, то своп приносит пользу.
На самом деле, у меня есть неплохой пример игры, которой было нужно около 8гб видеопамяти (хотя по виду ей 1гб за глаза и в требованиях зачем-то врут), и если запускать её на карточке с 2гб, она демонстрирует различные интересные спецэффекты при недостатке оперативной памяти (в которую вытесняется видеопамять). Решением было добавить достаточно большой файл на диске (в несколько раз больше ожидаемого), из минусов только загрузка уровня несколько минут, и катсцены в начале уровня подлагивали при 1 запуске.Да и в целом, если все фоновые табы веб-браузера, которые мне не нужны, будут лежать на диске, это только плюс. Я не помню, чтобы загруженные сброшенные на диск табы были проблемой, а ведь это куча памяти (и они протекают, кроме того). "Остановленные" и "спящие" процессы тоже можно выгружать целиком, пока они не будут запущены, это пустая трата памяти.
Своп можно разместить на быстром SSD например, иначе зачем еще нужны эти трюки с SLC кэшем в современных носителях?
Да и при повседневном использовании при отсутствии недостатка памяти в своп вытесняется что-то очень редко используемое, некритично.
> Собственно, у меня и сейчас, если своп был заполнен, не успевает отмонтировать
> до перезагрузки и сыпет ошибками без особых причин даже когда успевает,
> а если нет, при загрузке ещё минут 10 на восстановление журналов.
> Если это невозможно, то ждём час без журнала (ext4). Есть ещё
> развлекуха, когда драйвер бесперебойника у NUT отваливается, без перезагрузки восстановить
> сервис квест ещё тот. Использование cgroups несколько костыльно с openrc выглядит
> (в теории конечно нормально, но не удобно). Кеды очень плачутся, что
> не могут найти инит.Не пробовал своп делать побольше? Ну чисто для эксперимента... или тогда поныть нельзя будет?
Ещё больше, как это поможет? Больше объёма ОЗУ делать нецелесообразно. У меня нет проблем со свопом, у меня есть проблемы с его отмонтированием после линковки браузера.
Но ведь можно не пользоваться браузером.
легче не пользоваться системдой
> Ещё больше, как это поможет? Больше объёма ОЗУ делать нецелесообразно. У меня
> нет проблем со свопом, у меня есть проблемы с его отмонтированием
> после линковки браузера.Своп на десктопе не нужен, шлак от браузера выносишь в tmpfs и радуешься жизни.
Скажем, файрфокс при линковке потребляет около 4-6гб на каждый процесс линкера. Ну и удачи положить 20гб временных файлов в tmpfs без свопа (хотя и с ним затея сомнительная). С хромиумом картина похожая.
с ним бессмыслено говорить - он даже не понимает, что ты говоришь о сборке из сырцов :)
> Ну и удачи положить 20гб временных файлов в tmpfs без свопа (хотя и с ним затея сомнительная).И все-таки, зачем своп?
Делаешь просто рамдиск на 32Гб и все временные файлы складываешь туда.
Это работает только когда у тебя терабайт оперативки и она простаивает.
Проблема: мало оперативы
Твоё решение: забить оперативу ещё сильнее
> Ещё больше, как это поможет?Ты пишешь, что у тебя Своп переполняется. Собственно, сделай своп больше.
>Больше объёма ОЗУ делать нецелесообразно. У меня
нет. Все зависит от задач. Своп используется не только для складировании ОЗУ в него.
> нет проблем со свопом, у меня есть проблемы с его отмонтированием
> после линковки браузера.Не понимаю. Зачем его отмонтировать?
>> Ещё больше, как это поможет?
> Ты пишешь, что у тебя Своп переполняется. Собственно, сделай своп больше.Разве? Где? Наоборот, он слишком большой и не системе хватает времени на graceful завершение.
>>Больше объёма ОЗУ делать нецелесообразно. У меня
> нет. Все зависит от задач. Своп используется не только для складировании ОЗУ
> в него.
>> нет проблем со свопом, у меня есть проблемы с его отмонтированием
>> после линковки браузера.
> Не понимаю. Зачем его отмонтировать?Чтобы перезапустить систему и протёкшие программы с утраченными ресурсами ядра (и обновить его заодно), а точнее, чтобы избежать повреждений ФС при этом. Кроме того, иногда приходится переподключать своп, потому что он будет заполнен, а на деле там 1% размазан. Если он заполнен, то он не может использоваться, и это приводит к лагам и зависаниям.
> Разве? Где? Наоборот, он слишком большой и не системе хватает времени на
> graceful завершение.Я тебя не правильно понял.
> развлекуха, когда драйвер бесперебойника у NUT отваливаетсяУверен, что проблема в systemd а не в кривом драйвере?
Я уверен, что проблема в openrc.
>овер-инжинирнг дизайнаКак пользователь это заметит?
>кривого спагетти-кодаКак пользователь это заметит?
>всякими ошибками, когда ФС не может отмонтироваться при ребутеЯ так понимаю ошибки только у СистемДи?
Кстати у меня все ФС отмонтируются норм. Наверное это блуждающая ошибка, которая появляется не у всех. И если копнуть у всяких Инитов то там подобные ошибки тоже могут быть.З.Ы. Когда из ПО делают религию, это ведет к стигматизации и регрессу в целом.
> Когда из ПО делают религию, это ведет к стигматизации и регрессу в целом.Это хорошо. Склонные к религии должны сходить с хайвея прогресса и регрессировать в придорожной канаве.
>> Когда из ПО делают религию, это ведет к стигматизации и регрессу в целом.
> Это хорошо. Склонные к религии должны сходить с хайвея прогресса и регрессировать
> в придорожной канаве.По хорошему да. Но в реальности они пытаются тормозить прогресс в целом, выдывая свои желания за истину.
- Без бога вы все в огненную гиену попадете!!!
Завязывай. Честно уже пора.
Без системд под видом "прогресса" (выгодного для буржуинов) тоже?
> Без системд под видом "прогресса" (выгодного для буржуинов) тоже?лечится пробуй)
>>гиенуТаки "геена". И это не животное.
И ты сорвался в карьер где корабли ходят. Грамматикфюррер виноват.Очевидно покусал многих и снова транслит не в моде будет.
>>>гиену
> Таки "геена". И это не животное.Точно.
> Подумываю перейти с openrc на systemd, подводные камни?Вопрос (без троллинга, серьезно): что тебе это даст? Тебе как конечному пользователю не один хрен что там под капотом? Или ты системный программист которому это важно в контексте написания какого-то зависимого от этого софта?
Я привык к системам с openrc, но не имею опыта миграции с неё, поэтому и спрашиваю. Это совсем не идеальный инит для пользователей (он построен поверх сабжа из новости), но он вполне отвечает минимальным потребностям. Даст это мне то, что половина компонентов systemd и так используется безальтернативно, что периодически приводит к различным сложностям как при обновлениях, так и при использовании, которых не возникает на системах с systemd. Кроме того, уже много лет весь софт штатно работает только под systemd и скрипты для запуска без него пишутся посторонними (также это означает, что пользователю часто приходится самому портянки мутить, и проще без них).
Анон лови https://davmac.org/projects/dinit/
Ещё слышал тот же runit есть.
А так да сложно без системд но и он тоже такая себе кака**шка , кстати ещё в pisi Linux какая то своя не понятная любопытная поделка инит
Вот есть ещё: https://core.suckless.org/sinit/
> он построен поверх сабжа из новостиОткуда ты это взял? USE="-sysv-utils", только не забудь заранее agetty в openrc настроить и init ядру прописать.
>> он построен поверх сабжа из новости
> Откуда ты это взял? USE="-sysv-utils", только не забудь заранее agetty в openrc
> настроить и init ядру прописать.Не умничай, тебе не к лицу. Экспериментально можно уже заменить зависимость от sysvinit на собственные костыли, но это не штатно. И с юзом ты ошибся.
А чо за вброс?
Не строй себе иллюзий, думать это очень сложно и трудозатратно. Ты вспотеешь!
Лучше скажи, чем openrc неустраивает? Если сможешь, конечно же ;) И кратко, зачем?
И вообще, ИМХО, так поставленный вопрос, это для Алисы.
У меня gentoo, к примеру. А "чем openrc не устраивает" может спросить только тот, кто видел его на картинках.
Да как всегда, будет немного комфортнее. И тебе, и тому, кто ломает твою систему. Из недавнего - xz c трояном как зависимость systemd. И плевать, что ты пользуешься только gzip к примеру, системда паровозом затащит троян к тебе.
> Да как всегда, будет немного комфортнее. И тебе, и тому, кто ломает
> твою систему. Из недавнего - xz c трояном как зависимость systemd.
> И плевать, что ты пользуешься только gzip к примеру, системда паровозом
> затащит троян к тебе.Сейчас от xz довольно много софта зависит так то. Я б еще понял бояться питона, который каждый первый скрипткидис юзает. Вот его отсутствие - кидисов расстраивает сильно.
> Подумываю перейти с openrc на systemd, подводные камни?Во первых, придется все же прочитать ман. А именно man systemd.service, man systemd.exec и man systemd.unit для начала. А поняв как оно - в общем то ничего сложного. На самом деле довольно логичная штука с хоть каким-то подобием архитектуры, а не просто хаотичная свалка скриптов решающая хз какие проблемы.
Во вторых, ну, вот, да, со временем стало довольно много фич, см выше про маны. С другой стороны - их самому имплементить и не надо как раз.
это та которую портянками называют?
Было время писал свою init систему на паскале... just for fun.
22 года использую linux вопросов с сабжу не было...
поэтому продолжаю использовать на devuan и antix и на серверах и на десктопах...
> devuan и antix и на серверахЯ ещё поверил бы, если бы это была виртуалка с фтпшником в локальной сетке.
Сервера, пфф.
Для серверов как раз таки SysVinit заглаза хватит, а если это интранет, то и дистриб может быть любым.
> Для серверов как раз таки SysVinit заглаза хватит, а если это интранет,
> то и дистриб может быть любым.Да, очень удобно когда диагностики на упавший сервис нет, в логах нихрена, а вот это - на том замурованом в стену сервере - вообще хрен его знает откуда запускается, ибо это знание Древних уже давно утрачено - с уходом последнего из могикан^W админов владевшим сакральное знание.
...но вы можете полдня покопаться сами, конечно, может и найдете где этот креативщик запускал вон то. Только чур это - ВАШЕ время будет угрохано на это все.
ой да, вот только что-то успешные админы арчика не могут поднять ситемдю на дебиановском сервере, так как "она очень старая и вообще" и все равно вызванивают магиканина который это ставил...
> ой да, вот только что-то успешные админы арчика не могут поднять ситемдю
> на дебиановском сервере, так как "она очень старая и вообще"Хызы, вооооон на том серваке как раз мадам фанатеющая от арча - зажигает в дебиане. Разницы в именно systemd у них особо нет. А если позарез хочется фичу из вот именно нового системд, внезапно, в backports дебиана этого - есть.
> и все равно вызванивают магиканина который это ставил...
Не знаю кто там кого вызванивает, у меня такой проблемы нет как класса.
> backports дебиана этого - есть.во-первых, "As Debian Backports do not support Long Term Support" (с)
во-вторых, "Backports cannot be tested as extensively as Debian stable, and backports are provided on an as-is basis, with risk of incompatibilities with other components in Debian stable. Use with care!" (с)Но, естественно, установить на сервер васянскую версию комбайна работающего c pid=1 из бэкпортов и остаться без поддрежки, это в стиле "фанатеющая от арча"
Это вам не про "сервер под кроватью", это решения уровня энтерпрайз Одминов Амазона и Гуголя!
ЗЫ: Замечу, что с проблемами системд из backports тебе не помогут ни команда системд (они официально не поддерживают старые версии, для них старое это больше года и в bullseye-backports значит уже ваяется старье) ни в команде дебиана - они же предупредили "Use with care!" и "doesn't follow LTS".
Не надо путать своё нежелание документировать систему и особенности работы того или иного решения.
Если вы принимаете дела просто "для галочки", ничего в этом не понимая, потом не надо тут рыдать про "знание Древних уже давно утрачено".ЛЮБАЯ система нуждается в документировании и вдумчивом подходе. Если это не делается — то уже всё равно что использовать.
Впечатляет как упорно (или упорото?) люди продолжают что-то дописывать в уже практически никому ненужное поделие.
Их бы силы, да в правильное русло...
> Их бы силы, да в правильное русло...Мой многолетний опыт бодания с опенсорсом, говорит о том, что гораздо быстрее и проще создать что-то своё на миллион строк, чем месяцами пытаться пропихнуть патч на 10 строчек в чужой проект.
> пропихнуть патч на 10 строчек в чужой проектэто ты про системдю?
> Мой многолетний опыт бодания с опенсорсом, говорит о том, что гораздо быстрее
> и проще создать что-то своё на миллион строк, чем месяцами пытаться
> пропихнуть патч на 10 строчек в чужой проект.Нормальные люди обычно исследуют оба направления - запустив асинхронно патч на 10 строк, а если туго идет то и свое напрогав. Но в идеале удается сделать 0 дельту от апстрима - чтобы не майнтайнить это самому.
Почему люди должны исспрашивать твоего позволения, куда им применять их силы?
Правильно, зачем что-то дописывать? Пускай лучше всё будет сырое и недописанное. В лучших традициях погромистов (и не только попенсорсеров).
> В новом выпуске SysVinit добавлена обработка сигнала
> SIGRTMIN+4 и инициирование выполнения команды "shutdown -hP
> now" для завершения работы при получении данного сигнала.
> Обработка сигнала SIGRTMIN+4 потребовалась, так как его
> генерирует systemdпростите, а какое отношение имеет какая-то очередная чушь которую генерит системдрянь - к sysvinit?
Честно говоря, уже очень бы хотелось чтобы могикане его пилящие пошли торговать пиццей и оставили проект в покое. Он еще долго проработает, если ничего просто не трогать.
