Опубликован релиз классической системы инициализации SysVinit 3.14, которая широко применялась в дистрибутивах Linux во времена до systemd и upstart, а теперь продолжает использоваться в таких дистрибутивах, как Devuan, Slackware, Debian GNU/Hurd и antiX. Код написан на языке Си и распространяется под лицензией GPLv2. Версии применяемых в связке с sysvinit утилит insserv и startpar не изменились. Утилита insserv предназначена для организации процесса загрузки с учётом зависимостей между init-скриптами, а startpar применяется для обеспечения параллельного запуска нескольких скриптов в процессе загрузки системы...Подробнее: https://www.opennet.dev/opennews/art.shtml?num=62695
> Раньше длинные строки обрезались по границе допустимого размера и выполнялись, что могло привести к неприятным сбоям. Например, вместо "rm -rf /var/1234" могла выполниться команда "rm -rf /var", если часть команды "/1234" оказалась за границей обрезки.Ой, неприятненько вышло)
А что вышло?) Кто-то умудрился родить команду с rm длиной больше 127 символов в inittab, она обрезалась и удалилось что-то не то?)
Если бы строители строили здания так же, как Си-программисты пишут
программы, первый залетевший дятел разрушил бы цивилизацию.
Они так и строят) Здания рассчитаны на строго определённые ограниченные параметры. Чуть превышение - всё, здание рушится.
Не так уж и чуть, бывает в квартирах несущие стены незаконно переставляют и не рушится
Это называется резервирование. Но и у него есть предел.
В данной ситуции Rust-программисты ни чем бы не отличались.
> Если бы строители строили здания так же, как Си-программисты пишут
> программы, первый залетевший дятел разрушил бы цивилизацию.А что вам не нравится? Японцы, вот, построили на берегу моря АЭС. Ее помыло цунами. С понятным результатом. Видите, строители могут - догнать и перегнать! И первое же достаточно жирное цунами вызывает эвона какой срач.
Так или иначе, такого быть не должно.
Ну вот и исправили, хоть никто не напарывался/не жаловался.
> Кто-то умудрился родить команду с rm длиной больше 127 символов в inittabcmd1 && cmd2 && cmd3 ..... && rm -rf /var/all/HaX
нет товарищ студент вы этого не сделаете, птушо эта строка будет выполнена в форкнутом шелле, какsh -c exec cmd1 && cmd2 && cmd3 ..... && rm -rf /var/all/HaX
PS да, в 3.11 чейнинг наконец добавили. Три месяца назад. А до этого такие кочерги в иниттабе не прокатывали.
Так что придумывайте пример получше.
> PS да, в 3.11 чейнинг наконец добавили. Три месяца назадНу так вот сразу и вылезло.
>А до этого такие кочерги в иниттабе не прокатывали.Это что, в inittab нужно как и в systemd целый юнит строчить?
> Например, вместо "rm -rf /var/1234" могла выполниться
> команда "rm -rf /var", если часть команды "/1234" оказалась
> за границей обрезки."А что, так можно было???" (с)
Ахаха, проверенный инит, написаный дидами, а не вот этими вашими смузехлебами! Сразу видно, что писали проффесианалы!
Не удивительно, что все ломанулись на системду практически сразу, как она появилась.
Никто не ломанулся - в Slackware как не было systemd так и нет.
В проде как не было Slackware так и нет.
Есть. У русских физиков, например.
В том треде, если ты не помнишь, слаку как раз эпично зачмырили.
На Западе Слаку в серверах ставят. Для сервера это отличный дистрибутив. В России Слаку в основном боятяся потому что не любят собирать из Слакбилдов пакеты. Многое, в отличии от других дистрибутивов, автоматически не настроено. Поэтому и наблюдаем такой хейт и неприятие со стороны так называемых не-осиляторов.
>На Западе Слаку в серверах ставят.Позвольте усомниться. На западе ставят убунту на серверы.
Ну вот да, три всадника апокалипсиса на серваках это убунту, дебиан и бесплатные редхатообразные, ну и четвёртый вариант это свой линукс если ты огромная корпа у которой есть ресурсы для разработки, как тот же azure linux или aws linux.
>>На Западе Слаку в серверах ставят.
> Позвольте усомниться. На западе ставят убунту на серверы.Ставят её на арендованные VPS-ки и VDS-ки, и не сами арендаторы, а хостеры в большинстве случаев из соображений "жpите что дают". Далеко не все хостеры дают подгрузить свою ISO-шку и установить кастомный Линукс.
Ну и много кто из хостеров предлагает Ye6анити с преднастроенным веб-сервером, где клиенту достаточно просто загрузить свой контент -- и вуаля, сайт уже работает, и с настройками голова не болит. Для мелкого ЧП-шника или ООО-шки -- самый желанный вариант.
Это вовсе не означает, что Ye6анити-сервер -- хорошая и годная ОС. Просто многим тупо не дают никакого особого выбора. Ну, часто предлагают Дебиан ещё, для конечного пользователя арендованного сервера выглядит как та же Ye6анити, но без свистоперделок, и её ещё настраивать надо.
>Ставят её на арендованные VPS-ки и VDS-ки, и не сами арендаторы, а хостеры в большинстве случаев из соображений "жpите что дают". Далеко не все хостеры дают подгрузить свою ISO-шку и установить кастомный Линукс.Чем они провинились, что их так наказывают?
> Чем они провинились, что их так наказывают?Та ничем, просто найти хорошего и нежадного хостера -- это примерно как найти хорошего и нежадного продавца на Алиэкспресс. Есть добросовестные, есть не очень, есть ещё и ленивые, а бывают просто кидалы и аферисты. Отзывы -- только читать на форумах соответствующей тематики, причём строго по-английски.
Дать клиенту подгрузить свою ISO-шку -- это как минимум выделить ему место для загрузки этой ISO-шки. А её размер может 4 гига быть. Что уже сравнимо с объёмом дискового пространства в минимальной конфигурации у наиболее жадных и бедных хостеров. А клиентов могут быть сотни и тысячи.
А ещё хостеры часто бывают барыгами, то есть занимаются оверселлингом -- продают виртуалок больше, чем у них есть физических ресурсов. В расчёте на то, что каждый клиент не будет нагружать на 100% CPU и RAM в режиме 24х7. А слишком "прожорливых" могут тупо кикнуть без возвращения уплаченых за аренду денег. Границу прожорливости для арендатора устанавливает хостер по желанию своей левой пятки.
Бггггг, ссылку! Ссылку на слаку на серверах в серьезном проде!
slackware.com)
Получать пакеты из убунты dpkg в формате для слаки , одно и то же что разбирать дистрибутив который есть ради прое..я времени как и эрпм
Никто из десяти пользователей Slackware?
https://repology.org
By number of maintainersAUR - 15386
Debian+derivs (Raspbian Testing) - 4208
nix (nixpkgs unstable) - 3913
FreeBSD Ports - 1653
SlackBuilds - 911
Spack - 790
Gentoo (LiGurOS develop) - 781
Void Linux x86_64 - 740
Alpine (Alpine Linux Edge) - 659
MacPorts - 536Конечно, в 15 раз меньше Арчика и Дебиана, но далеко впереди Федоры.
> Конечно, в 15 раз меньше Арчика и Дебиана, но далеко впереди Федоры.Ничего что это "number of maintainers", а не "number of users"?
Пользователей деба на порядкИ больше чем мейнтейнеров деба.
А вот количество мейнтейнеров нельзя снизить ниже какого-то минимума, иначе вообще ничего работать не будет.А в вашем рейтинге SlackBuilds обгоняют Федору, Gentoo и Alpine)))
> А в вашем рейтинге SlackBuilds обгоняют Федору, Gentoo и Alpine)))Ну так упомянутых как раз и стало практически нереально юзать на десктопе или сервере. Что вам не нравится? Первое тестовый полигон редхата. Второе - с современным софтом мучительно без датацентра под билдферму. Третье - набивка контейнеров безблагодатная, а больше я это нигде и не видел.
Логично что майнтайнеров софта - под них не больно дофига. Как и живых юзерей с десктопами, лаптопами и серваками где оно вот именно основной системой.
>> А в вашем рейтинге SlackBuilds обгоняют Федору, Gentoo и Alpine)))
> Ну так упомянутых как раз и стало практически нереально юзать на десктопе
> или сервере. Что вам не нравится? Первое тестовый полигон редхата. Второе
> - с современным софтом мучительно без датацентра под билдферму. Третье -
> набивка контейнеров безблагодатная, а больше я это нигде и не видел.
> Логично что майнтайнеров софта - под них не больно дофига. Как и
> живых юзерей с десктопами, лаптопами и серваками где оно вот именно
> основной системой.Слаку мало юзают не потому что у неё много или мало мейнтейнеров, а потому что по автоматизации рутинных процессов она где-то в 90х и застряла. А это на фоне других дистров адекватным пользователям нафиг не упало. Люди хотят иногда личной жизни время уделять, а не с рутиной руками пердохаться. Отсюда и "популярность" слаки. ¯\_(ツ)_/¯
> Слаку мало юзают не потому что у неё много или мало мейнтейнеров,
> а потому что по автоматизации рутинных процессов она где-то в 90х
> и застряла.Тоже палка о 2 концах. В комплекте с этой автоматизацией - норовят подгрузить какой-нибудь хлам.
> А это на фоне других дистров адекватным пользователям нафиг
> не упало. Люди хотят иногда личной жизни время уделять, а не
> с рутиной руками пердохаться. Отсюда и "популярность" слаки. ¯\_(ツ)_/¯Зато все виденные мной слакварщики были - умные люди, хорошо разбирающиеся в системных аспектах. Вместо всяких горластых бесполезняшек - вполне себе. Поэтому если кто говорит мне что юзает слаку, это сразу определенные ожидания. И еще не было случая чтобы эти ожидания обломались.
>[оверквотинг удален]
> Debian+derivs (Raspbian Testing) - 4208
> nix (nixpkgs unstable) - 3913
> FreeBSD Ports - 1653
> SlackBuilds - 911
> Spack - 790
> Gentoo (LiGurOS develop) - 781
> Void Linux x86_64 - 740
> Alpine (Alpine Linux Edge) - 659
> MacPorts - 536
> Конечно, в 15 раз меньше Арчика и Дебиана, но далеко впереди Федоры.Забавно, что васянов крапающих пакетбилды и нередко их бросающих без обновлений в один ряд с настоящими адекватными мейнтейнерами записали, статистика repology такая статистика. А чего же они мейнтейнеров официальных реп Арчика стыливо в статистике не указали? xD
https://repology.org/repositories/statistics
Arch Linux 11504 11015 8784 80.7% 2080 19.1% 489 4.3% 62 0.5% 95 0.83% ? 981
Количество мейнеторв - неизвестно.
>что все ломанулись на системду практически сразу, как она появилась.Ломанулась федора, которая является тестовым полигоном редхата. Про дебиан, где нонстоп голосовали до получения нужного результата, я вообще промолчу.
> Не удивительно, что все ломанулись на системду практически сразу, как она появилась.Систембзда появилась в 2012 году, и тогда альтернатив ей практически не было. Рунит был ещё очень сырой, Динита вообще ещё не было, остальные по фичам были ненамного лучше SysV, и годились в основном для встроек.
Но сейчас давно пора уже с ней попрощаться.
Пример надуманный. Посмотри, какой там лимит длины строки был, при такой длине ничего подобного произойти не могло.
Ага-ага. Экзотическая ошибка в системде - вой про апокалипсис. Ошибка в ините уровня джуна из Салехарда приводящая к удалению данных - это надуманно. Лицемеры)
Нет у кого ещё эта ошибка к удалению данных не привела. Никто в inittab не пишет команд длиной 127 стмволов, тем более rm-rf.
А, ну значит исправлять не нужно, да? А разрабы исправили, ну они быдлы, ничего не понимают.
> Нет у кого ещё эта ошибка к удалению данных не привела. Никто
> в inittab не пишет команд длиной 127 стмволов, тем более rm-rf.А обнаружили тогда как? :) Может, таки, у кого-то /var улетел на манер bumblebee - и они заморочились - как же так?!
очевидно же, кто-то таки засунул в inittab строку длиннее, чем 127 знаков :)
Да нет, этот баг там на багтрекере висел годами.Добавлен по принципу "ну типа нехорошо иметь такой #define".
На самом деле нехорошо иметь такую логику обработки, когда молча исполняется урезанная строка.А #define - ерунда. Я вон 5 лет работал с кластером, на котором длина имени пользователя была 8 знаков, и никто не жаловался, пока не пришло новое начальство и давай кровати передвигать - приказали удлинить до 255.
> приказали удлинить до 255Фамилия, Имя, отчество, домашний адрес, телефон, блин, у меня лишних 200 знаков осталось! Чо туда писать-то? И кто это будет каждый раз набирать? :)
Тем временем, в случайном докере хостнейм в 13 символов. Так что давно пора было увеличивать
Это из-за вас systemd не хочет грузиться с покорёженным /etc/fstab?
Просто SysVinit не претендует на "мировое господство", это всего лишь система инициализации, не более того. Поэтому с systemd спрос больше. Так что никакого лицемерия - обычный расчёт и логика)
Система инициализации не может на что-то претендовать, это код, у него нет мотиваций.
> Просто SysVinit не претендует на "мировое господство"SysVinit просто не в состоянии ни на что уже претендовать.
А вот до systemd это же был практически стандарт. Ну и бажина еще того времени.Но как только появилось хоть что-то лучше, то SysVinit остался только во всякой маргинальщие.
> SysVinit просто не в состоянии ни на что уже претендоватьПравильно! Это и есть UNIX-way: разделение функций и ортогональность - каждая подсистема выполняет только свою функцию и не претендует на функционал других подсистем. А systemd - это комбайн, который пытается всосать в себя всё, что только можно, поэтому даже незначительная ошибка в нём приведёт к краху или невозможности загрузки всей системы, что неоднократно и наблюдалось.
Самое весёлое, так это искать самому, что там в systemd сломалось.
>каждая подсистема выполняет только свою функцию и не претендует на функционал других подсистем. А systemd - это комбайн, который пытается всосать в себя всё, что только можноЕсли я захочу приблизится по надёжности к функционалу systemd без systemd, то во-первых башпортянки превысят все мыслимые и немыслемые размеры, а во-вторых, мне резко потребуется куча вещей типа докера. Или нужно запускать всё от рута, как диды делали?
> превысят все мыслимые и немыслемые размерыЗначит ты делаешь что-то не так, потому что надёжность - в простоте.
Надёжность, это не тогда, когда чинится отвёрткой, это когда чинить вообще не надо. Попробуйте в sysvinit задать ограничение на размер виртуальной памяти, запуск в отдельном пространстве имён и от определённого пользователя, и не забудьте сюда результат скинуть.
> надёжность - в простоте.Палка-копалка тоже невероятно надежная.
А даже если что-то пошло не так, то просто рядом подбирается новая.
Но что-то использовать их как-то не хочется и все адекватные люди перешли на лопаты.
С SysVinit ситуация такая же.
> во-первых башпортянкиО, ещё один. Привет, зелёненький!
> Ахаха, проверенный инит, написаный дидами, а не вот этими вашими смузехлебами! Сразу
> видно, что писали проффесианалы!https://www.opennet.dev/opennews/art.shtml?num=61403
> Опубликован корректирующий выпуск системного менеджера systemd 256.1, в котором устранена проблема, приводившая к удалению содержимого раздела /home при выполнении команды "systemd-tmpfiles --purge", добавленной в systemd 256 для удаления всех файлов и каталогов, созданных через настройки в tmpfiles.dНу да, смузихлебы и тут дидов обошли!
Впрочем, у них на вендочке, скорее всего, проблем не было.
> Первоначально сообщение об ошибке было отвергнуто Лукой Боккасси (Luca Boccassi), разработчиком systemd из Microsoft
>
> https://www.opennet.dev/opennews/art.shtml?num=61403"В примечании к выпуску systemd 256 и в man-руководстве systemd-tmpfiles было указано, что опция "--purge" удаляет все файлы и каталоги, созданные через настройки tmpfiles.d"
Ну, бывают неосиляторы, которые даже ман не в состоянии прочитать...
А в мане к SysVinit указано что команда просто обрезается?
А бывают идиоты разработчики, оторые вносят в системд новые фичи, забыв, что у них в tmpfiles.d _по_умолчанию_ , прям в пакете системд - лежит файлик home.conf, в котором заботливо прописаноQ /home 0755 - - -
q /srv 0755 - - -Так что не надо на дураков пользователей кивать. Эта ногопушка целиком и полностью на совести разработчиков. Это даже не опечатка, как в bumblebee, это хуже - это ошибка.
Диды старые и до сих пор используют fgets вместо getline.
ДЫдЫ писали для людей у которых мозг есть и больше 80 col строки не пишут. Криворукам никакие бЫзопастные Ызыки не помогут
Диды писали для себя в расчете на здравый смысл. А потом появились смузихлебы и заплакали, что можно убиться с разбегу об стену, и система это допускает.
> Диды писали для себя в расчете на здравый смысл.Я тоже так пишу, когда для себя. char s[1024]; — ну должно хватить… наверняка. Но то для себя, и другим не показываю.
>Я тоже так пишу, когда для себя. char s[1024]; — ну должно хватить… навернякаЭто позор. Память под пользовательский ввод должна выделяться динамически. Если пользователь введёт десять символов, то не нужно на всё остальное тратить. Если введёт больше, то это нужно обработать, хотя-бы сообщение об ошибке написать
Я знаю, что это позор! Поэтому оно и делается для себя, и чтобы никто не видел (для одноразовых личных двадцатистрочников — приемлемо. Ну правда, все же так делают). А тут диды для всех в прод 30 лет вывешивают.
Так зачем так делать? Уже давным давно изобретены языки, где можно так не делать, тот же ocaml или go.
> Это позор. Память под пользовательский ввод должна выделяться динамически. Если пользователь
> введёт десять символов, то не нужно на всё остальное тратить. Если
> введёт больше, то это нужно обработать, хотя-бы сообщение об ошибке написатьОсобенно в init, ога! Остается подумать что будет если динамическая аллокация обломится когда в системе наступит душняк с памятью - и как вам будет такой оборот.
Хинт: если падает init - ядро улетает в панику. И вот тут большой вопрос захочется ли вам именно динамическую аллокацию, именно там. Потому что так можно получить - систему падающую в панику при намеке на душняк с памятью. Круто, а? :)
>Остается подумать что будет если динамическая аллокация обломится когда в системе наступит душняк с памятью - и как вам будет такой оборот.Обработчики ошибок изобретены. Программа пытается выделить память, у неё это не получается - программа пишет - памяти недостаточно, действие такое-то.
>Хинт: если падает init - ядро улетает в панику.Так может стоит инит писать на нормальных языках, а не сишке, которая на ровном месте падает? В нормальных языках будет что-то вроде исключения, которое потом можно будет обработать.
> Обработчики ошибок изобретены. Программа пытается выделить память, у неё это не получается
> - программа пишет - памяти недостаточно, действие такое-то.В случае вот именно init подобные вещи могут быть достаточно фатальны. А есть еще такая штука как overcommit. При том в Linux он активен по дефолту.
В чем прикол? Ошибок динамической аллокации не возвращают! Вместо этого - фактическое выделение памяти из чем-то обеспеченых страниц - когда прога реально удумает их юзать. А если никога не удумает - в этом и профит! Ибо современный софт заказывает сильно больше чем юзает.
Но, конечно, вы можете познакомиться с тем как это все работает и более сложным способом - когда у вас в init случится _ВНЕЗАПНЫЙ_ как пoнoc SIGSEGV. А за ним и kernel panic, разумеется - ибо без init система не живет.
>>Хинт: если падает init - ядро улетает в панику.
> Так может стоит инит писать на нормальных языках, а не сишке, которая
> на ровном месте падает?Так, на минутку, у этих языков дефолтовая реакция при невозможности аллокации памяти - в панику брякнуть программу. А тут - заодно и вся система в панику улетит. Гении системщины. На сишке более-менее можно сие попытаться обработать. Но с оверкомитом и это обломаться может.
> В нормальных языках будет что-то вроде исключения,
> которое потом можно будет обработать.Вот именно модель типа паник и исключений - имеет ломовые проблемы с тем чтобы корректно продолжить работу с места факапа. В этом смысле сишка с его педальностью несколько лучше, может просто retry malloc()'а гонять пока не отхватит свое.
...но оверкомит может внести коррективы в эти планы, внезапно. Ибо этим вашим исключением может оказаться SIGSEGV. Фиг знает где и почему. Т.е. реальная причина - программа попыталась поюзать заказанную страницу, но ее в системе выкроить не удалось. Так что нате вам! Вот токлько в init это - ведет к кончине всей системы вообще.
В общем до того как рассуждать по топику - в нем надо хоть что-то смыслить.
>В случае вот именно init подобные вещи могут быть достаточно фатальныТак не стоит их делать тяп-ляп.
>А есть еще такая штука как overcommit. При том в Linux он активен по дефолту.И как вас это от оверкоммита спасёт? Никак?
>Ошибок динамической аллокации не возвращают!А какую ошибку вернёт строка по примеру выше char s[1024]; ?
>Ибо современный софт заказывает сильно больше чем юзает.А я-то сидел гадал, почему оно так. А вот в чём причина - в том, что сишники настолько хорошо умеют писать код, что лишний раз выделить память боятся
>Так, на минутку, у этих языков дефолтовая реакция при невозможности аллокации памяти - в панику брякнуть программу.Это касается только новомодных типа rust или go. Если вас не устраивают текущие языки, то всегда можно написать свой. Вон, Дрю ДеВолт Hare сделал
>Вот именно модель типа паник и исключений - имеет ломовые проблемы с тем чтобы корректно продолжить работу с места факапа.Хорошо, разрешаю вам взять язык с эффектами. Да хоть си оставляйте, но сделайте как положено.
>...но оверкомит может внести коррективы в эти планы, внезапноВ чём проблема указать ограничение на размер виртуальной памяти? Тогда вам гарантированно будет возвращатся nullptr, если malloc не справился. А если ещё и cgroups взять, то и от oom killer защита будет.
>В общем до того как рассуждать по топику - в нем надо хоть что-то смыслить.Сишники гордятся тем, что могут свой менеджер памяти написать, как раз подходящая задача. Врут значит?
>>В случае вот именно init подобные вещи могут быть достаточно фатальны
> Так не стоит их делать тяп-ляп.Вот и дайте мастеркласс на тему как это надо было. Берете и показываете. Делом. Или о чем мы тут? Что теоретически, на некоторых не очень системных яп, даже можно при помощи трехэтажных костылей эвона как изгальнуться?
Максимум что я видел на эту тему - потуги хрустиков в R4L, которые в итоге родили семейство неведомой фигни try*, с семантикой ... на удивление похожей на сишные конструкции?! Т.е. оно таки может быть null и таки надо проверять что не оно. И чем это было лучше си - я так и не понял. Чем хуже - окей, контринтуитивный брейнфак с сложным синтаксисом, косплеящий версию без try*, так что риск что кодер облажается, поюзав вариант без try по привычке. Есть какие-то идеи лучше? И они все - где?
>>А есть еще такая штука как overcommit. При том в Linux он активен по дефолту.
> И как вас это от оверкоммита спасёт? Никак?У вас парсер сломался. Вы пытаетесь меня зациклить беседовать самого с собой? Так не пойдет. В вот именно сях оверкомит можно и аннулировать. Во первых, это больше актуально для аллокаций heap. Во вторых можно аллокацию и _инициализацию_ явно сделать в самом начале. И тогда страницы таки реально выделятся, и если оно в самом начале прокатило, то потом уже ломаться особо и не должно.
Как вы такую механику будете проворачивать в чем-то более высокоуровнем - и без трехэтажных костылей - возьмите да покажите. С умным видом надувать щеки на форуме - не очень хорошо работает.
>>Ошибок динамической аллокации не возвращают!
> А какую ошибку вернёт строка по примеру выше char s[1024]; ?А никакой, он вообще - на стеке аллоцирован. До известного предела номер катит. Если конечно оборзеть и вкатить какую-нибудь рекурсию и проч - в конечном итоге, конечно, стек может и закончиться, и тогда тому кто так сделал - результат тоже не понравится.
>>Ибо современный софт заказывает сильно больше чем юзает.
> А я-то сидел гадал, почему оно так. А вот в чём причина
> - в том, что сишники настолько хорошо умеют писать код, что
> лишний раз выделить память боятсяНе думаю что это специфично для сей. Можете взять ваш предмет обожания и сравнить как у него будет с разницей VZS и RSS. Видите ли, аллоцировать память мелкими кусочками понемногу - ведет к другим нездоровым эффетам. Во первых оверхед от этого действа. Во вторых фрагментация. Т.е. тоже ничего хорошего.
> Это касается только новомодных типа rust или go. Если вас не устраивают
> текущие языки, то всегда можно написать свой. Вон, Дрю ДеВолт Hare сделалЭта харя тоже - забавный зверек. Я не говорю что это плохо. Но пусть он и покажет как на этом делать вон то - и чем оно лучше, собссно.
> Хорошо, разрешаю вам взять язык с эффектами. Да хоть си оставляйте, но
> сделайте как положено.Ну так в init - вот именно сильно косячить все же будет довольно сложно. Потому что брякнувшийся инит - то же самое что кернелпаник. Способствует относительно разумному подходу. Откуда вон то урезание и следует. Завал 1 команды - лучше чем крах инита. То что это в энных ситуациях может вести к странным вещам, окей, может.
>>...но оверкомит может внести коррективы в эти планы, внезапно
> В чём проблема указать ограничение на размер виртуальной памяти?
> Тогда вам гарантированно будет возвращатся nullptr, если malloc не справился.Если вы отключите overcommit в системе - то сможете запустить в ней СИЛЬНО меньше программ при прочих равных. В проде это стоит денег - на фактическую аллокацию той памяти которая никогда поюзана не будет. Поэтому без оверкоммита живут только сильно некоторые конфиги, с uber-требованиями по надежности.
Тут можно поспорить что это дурацки, и вообще брейнфак, получивщийся из-за жадности и оверселла. Но этот мир не идеален, с этим придется жить, а инит - таки весьма критичная к отвалам штука. Туда же и OOM SCORE ADJUST - по примерно тем же причинам. Ибо убитый по OOM init - таки, самострел.
> А если ещё и cgroups взять, то и от oom killer защита будет.
От него можно защититься и просто OOM SCORE ADJUST, так что будет пристрелено что-то иное.
А пойнт был что вон то - весьма деликатная системная механика, не прощающая ошибок, и там все не так просто как в обычных апликухах. И фичи могут и багами стать.
>>В общем до того как рассуждать по топику - в нем надо хоть что-то смыслить.
> Сишники гордятся тем, что могут свой менеджер памяти написать, как раз подходящая
> задача. Врут значит?Не врут. Но и это - специфичное развлечение. Да, можно заранее выделить и проинициализировать относительно большой регион памяти, на него фактически выделятся страницы, так что "потом" - оно брякнуться по отсутствию страниц все же не сможет, и далее делать оттуда суб-аллокации под нужды проги. Но это тоже специфично, ибо приходит к примерно тому же что и с отклюком оверкомита, т.е. заранее преаллоцировано - независимо от того будут ли потом это юзать. Чтоб не брякнуться по нехватке памяти, если все же - будут.
И да, это вероятно 1 из причин по которым ksmd не делает глобальный общесистемный мерж идентичныз страниц вот так сразу по дефолту, только для виртуалок которые явно отмаркируют свою память как годную для дедупликации. Для системды в принципе есть способ заставить его пускать все процессы с памятью маркированой на дедупликацию ksmd. Нужно ли такую граблю юзать - вопрос довольно забавный.
>Т.е. оно таки может быть null и таки надо проверять что не оно.Традиционно, в сях проверки должны быть чуть ли не на каждой строке, однако на практике мало кто их пишет. И то и дело новости о том, что где-то забыли проверку, а где-то присовили null после вызова free
>Вы пытаетесь меня зациклить беседовать самого с собой?Совершенно верно. По вашему, выделение какого-то массива с захардкоженым размером вам как-то поможет. Но случись рекурсия, например, и ваша программа точно так же упадёт
>Во вторых можно аллокацию и _инициализацию_ явно сделать в самом начале.Это во-первых означает, что часть памяти будет простаивать, а во-вторых, что каждое превышение лимита нужно обнаруживать, иначе оно может просто потерятся. А вот с этим в си всегда проблемы
>Как вы такую механику будете проворачивать в чем-то более высокоуровнем - и без трехэтажных костылей - возьмите да покажитеПроблема в том, что сразу же после этого, придётся заниматься написанием собственного инита/ядра/чего-нибудь ещё, поскольку одной демонстрации не хватит
>Эта харя тоже - забавный зверекПроблема в том, что развитие системного программирования остановилось в семидесятых. Недавно появился раст, но во-первых, у него есть свои проблемы, типа обработки нехватки памяти, а во-вторых, его крайне скептично приняли
>Не думаю что это специфично для сейС учётом того, что интерпретаторы частенько написаны на сях, то в интерпретируемых языках это тоже всплывает
>Можете взять ваш предмет обожания и сравнить как у него будет с разницей VZS и RSS$ ps -eo comm,rss,vsz | grep u[t]op
.utop-wrapped 19100 301508
.utop-wrapped 17352 41640
Первая строка - utop собранный ocaml 5.2.1, вторая - 4.14.2. Utop - это repl для ocaml. При переходе на 5 версию переработали рантайм, не знаю насколько можно было бы ужать потребление, сохранив остальные фичи. Конечно, ~300 Мб виртуальной памяти это не мало, но во-первых, это уже полнофункциональное приложение, а во-вторых у go hello world более 500 Мб со старта берёт. Но, учитывая разрыв в размере виртуальной памяти у go и ocaml, могу сказать, что есть куда стремится.
>Во вторых фрагментацияА фрагментация за счёт чего? И как увеличение размера виртуальной памяти поможет бороться с фрагментацией?
>Завал 1 команды - лучше чем крах инитаМеня в этой ситуации больше удивляет то, что это изначально было сделано молча, без всяких предупреждений.
>Если вы отключите overcommit в системе - то сможете запустить в ней СИЛЬНО меньше программ при прочих равныхРазмер виртуальной памяти можно задать и для конкретного процесса/cgroups, остальным остваить без изменений
>Но и это - специфичное развлечение.Так какой смысл тогда играться со всем этим?
>Не врут. Но и это - специфичное развлечение. Да, можно заранее выделить и проинициализировать относительно большой регион памяти, на него фактически выделятся страницы, так что "потом" - оно брякнуться по отсутствию страниц все же не сможет, и далее делать оттуда суб-аллокации под нужды проги. Но это тоже специфично, ибо приходит к примерно тому же что и с отклюком оверкомита, т.е. заранее преаллоцировано - независимо от того будут ли потом это юзать. Чтоб не брякнуться по нехватке памяти, если все же - будут.Что мешает взять следующую схему: выделяется небольшой регион на рантайм - самый базовый функционал, типа логирования, информации об ошибках и прочие мелочи, включился лимит на виртуальную память, а потом, уже после этого все последующие выделения происходят регионами и лениво - попалась длинная команда - выделился регион, закончилось выполнение - освободился? Или ко всему прочему, си ещё и не позволяет легко провести границу - для этого кода память выделяется в этом регионе, для этого - в другом?
> Традиционно, в сях проверки должны быть чуть ли не на каждой строке,
> однако на практике мало кто их пишет.Такое и правда - бывает. Частично наследие микрооптимизаций использования памяти из времен когда на все было - 4 мега.
Но и когда вожжи отпускают - такое себе. Вон питоны-электроны, мобилки уже стали с кирпич, отрастили акум во всю крышку. Но нет, все равно постоянно все тормозит, акум вечно на нуле, а запустить всего то пару чатов, почтарь, и плеер - что древняя нокия на симбиане могла - уже душняк и едва телепается.
> новости о том, что где-то забыли проверку, а где-то присовили null
> после вызова freeNull после free ничем не плох - это антибаг, вызывающий крах как индикатор что кодер жестко облажался.
> Совершенно верно. По вашему, выделение какого-то массива с захардкоженым размером вам
> как-то поможет.Внезапно, да! Как видите, я разбил вашу рекурсию - и это работает. Если вся память выделена заранее ("static memory allocation") - выделение памяти не может облажаться by design. Высоконадежные программы, типа фирмварей - используют этот паттерн.
> Но случись рекурсия, например, и ваша программа точно так же упадёт
- Доктор, когда я так делаю, мне больно!
- А вы так не делайте.> Это во-первых означает, что часть памяти будет простаивать,
You cant have cookie and eat it. Либо у вас динамическая аллокация и риски облома по ходу дела, либо все заранее преаллоцировано, и тогда обламываться нечему.
Есть гибридные подходы, типа некоторых БД, когда они при обломе выделения ждут энное время и пробуют еще раз, но это имеет свои лимиты. Или в ряде случаев ОК гранулярно завернуть проблемную операцию.
> превышение лимита нужно обнаруживать, иначе оно может просто потерятся. А вот
> с этим в си всегда проблемыВ си как раз все довольно просто и педально чтобы при остром желании брать этот эффект под контроль. А вот у остальных - зависит от.
> Проблема в том, что сразу же после этого, придётся заниматься написанием собственного
> инита/ядра/чего-нибудь ещё, поскольку одной демонстрации не хватитЭто отмазки. Init при желании можно написать существующему ядру.
> Проблема в том, что развитие системного программирования остановилось в семидесятых.
Я согласен что это не айс, но увы, альтернативы какие-то не сказать что эпичные вышли.
> нехватки памяти, а во-вторых, его крайне скептично приняли
Потому что господа чрезмерно рекламились и видимые достижения не соответствовали тому что на практике.
Хруст сделала мозилла. Для движка браузера. Цать лет спустя ТОТ двигун (servo) до сих пор никому не надо. Уж и разработчиков уволили, и мозилла скоро за сервой отправится, а оно все не готово. Вместо этого хтонь с 3-4 яп в 1 проекте. И так много где. И подход "скачайте ночнушку чтобы сбилдить ядро" - очень так себе.
> С учётом того, что интерпретаторы частенько написаны на сях, то в интерпретируемых
> языках это тоже всплываетУ них и без сей много чего всплывает.
> не знаю насколько можно было бы ужать потребление, сохранив остальные фичи.
> Конечно, ~300 Мб виртуальной памяти это не мало, но во-первых,Во первых вы неплохо показали что VSZ != RSS и что там тоже могут заказать - больше чем реально юзануть. При отклюке оверкомита - память будет выделена на ВСЕ что заказано. Сразу. Это означает что вы сможете запустить в РАЗЫ меньше процессов при прочих равных.
Это улучшает надежность - но весьма дорогой ценой. Жаба побежадает, так что по дефолту оверкомит.
> Мб со старта берёт. Но, учитывая разрыв в размере виртуальной памяти
> у go и ocaml, могу сказать, что есть куда стремится.Мой пойнт был в том что VSZ > RSS у практически всего что шевелится, не то чтобы у сишников на это какая-то монополия. И вы же сами кивали на вулны от потуг микроменеджмента памяти и результирующих багов.
> А фрагментация за счёт чего? И как увеличение размера виртуальной памяти поможет
> бороться с фрагментацией?В зависимости от того как и что - бывает разница аллоцировать мелкими кусками или большим. Когда освободили кучу мелких регионов - круто, а как в этом наковырять место на 1 большую непрерывную аллокацию, если ее захотели?
> Меня в этой ситуации больше удивляет то, что это изначально было сделано
> молча, без всяких предупреждений.Насчет предупреждений - пожалуй косяк, да. Но у sysv init с дианостируемостью вообще по жизни - никак. Не было такой цели у авторов походу.
> Размер виртуальной памяти можно задать и для конкретного процесса/cgroups,
> остальным остваить без измененийА оверкомит можно отключать по cgroup? Я помню по глобальную настройку кернела, но там если его отрубить - реальные страницы будут выделены на весь VSZ. Это не прикольно - сразу в разы меньше того что запустится.
>>Но и это - специфичное развлечение.
> Так какой смысл тогда играться со всем этим?Если есть какие-то кастомные требования - на си это можно. Например более-менее гарантировано не вылетать по ауту памяти - статическая аллокация. Или некоторые БД - могут retry аллокации - чтобы выполнить запрос, просто попозже, когда полегчало. Лучше чем завалить запрос или тем более уронить базу. И так далее.
Плотный контроль над окружением и возможность вклина в низкоуровневую механику и отличает системные ЯП от остальных. Там можно пойти и сделать, если надо. Хруст с своим вечным скачайте ночнушку - скепсис вызвал и по этой линии в частности. Не очень системно вышло, если для вских обычных хотелок системщиков постоянно надо переделывать ЯП и тулчейн. Если б си так себя вел им бы в жизни никто не стал пользоваться!
>> Чтоб не брякнуться по нехватке памяти, если все же - будут.
> Что мешает взять следующую схему: выделяется небольшой регион на рантайм - самый
> базовый функционал, типа логирования, информации об ошибках и прочие мелочи,Усложнение программизма всего этого, внезапно. Ну и результирующие баги. Вы примерно это и предъявили коду на сях, особенно олдовому, когда он в примерно этом и лажается.
> Частично наследие микрооптимизаций использования памяти из времен когда на все было - 4 мега.Так памяти вагон уже лет 20 точно.
Думаю они просто ленивые, пишут код по лозунгом "и так сойдет", а сверху, как вишенка, ЧСВ размером с Эверест "да я на СИ пишу 30 лет, я не могу ошибаться".> Но и когда вожжи отпускают - такое себе. ... мобилки уже стали с кирпич ... все тормозит, акум вечно на нуле, а запустить всего то пару чатов, почтарь, и плеер - что древняя нокия на симбиане могла - уже душняк и едва телепается.
Сорян, но ты несешь чушь.
Покажи мне нокию которая сможет показывать ютуб часами, на которой можно играть, чтобы 3-4 мессенджера одновременно работали? А еще какой-то почтовик, гугл-таблицы и тд.
У меня телефон не лопата (72мм шириной). И батарейки в 5к хватает на неделю.> Null после free ничем не плох - это антибаг, вызывающий крах как индикатор что кодер жестко облажался.
Ну... как вариант, но все равно костыльно.
>> Но случись рекурсия, например, и ваша программа точно так же упадёт
> - Доктор, когда я так делаю, мне больно!
> - А вы так не делайте.А потом читаем про падение в рекурсии в машинах тойота)
> Уж и разработчиков уволили,
Не показатель. Может просто директор захотел яхту.
> Вместо этого хтонь с 3-4 яп в 1 проекте. И так много где.
И это нормально. Особенно для браузера.
Потому что писать какой-то парсер или скрипты на си будет только очень странный человек.
И например в андроиде или хроме (одни из самых популярных программ в мире) как раз несколько языков.> И подход "скачайте ночнушку чтобы сбилдить ядро" - очень так себе.
Бредовый бред) Но типичный.
Примерно как в ведро можно зафиксировать с89, так же и версия раст фиксируется.
Про ночнушки может писать человек, который вообще не понимает что такое edition и книжку не читал.
Зато мнение имеет.> Плотный контроль над окружением и возможность вклина в низкоуровневую механику и отличает системные ЯП от остальных. Там можно пойти и сделать, если надо.
Unsafe. Use unsafe Luk!
> Хруст с своим вечным скачайте ночнушку
Ты можешь привести пример, ну хотя бы один - там pull request или доку.
Потому что ты в каждой теме высыраешь эту чушь.Вот пример
https://source.android.com/docs/setup/build/rust/building-ru...
edition defines the Rust edition to use for compiling this code. This is similar to std versions for C and C++. Valid values are 2015 and 2018> - скепсис вызвал и по этой линии в частности.
К счастью твое мнение мало кого волнует)
> Если б си так себя вел им бы в жизни никто не стал пользоваться!
В сишке в зависимости от вендора компилятора и даже его версии у тебя программа может давать разные результаты. Для одно и того же "типа стандарта".
А ты говоришь "никто не стал пользоваться")
> Так памяти вагон уже лет 20 точно.А повадки и унаследованный код - остались, увы и ах.
> пишу 30 лет, я не могу ошибаться".
Такое тоже бывает. Вооон там за маститым дидом - вычистил его чудный out of bounds на левых входных данных. Но это лучше чем самому навороченное и специфичное алго писать. Сделал каке жесткий рефактор и прочекал граничные условия, стало приличнее. И если кто думает что следующие полвека сможет про си забыть - ну пусть и покажет как оно.
> Покажи мне нокию которая сможет показывать ютуб часами,
Ютуба тогда еще не было ессно. Ну или он не особо популярен был.
> на которой можно играть,
Под симбиан были нативные гамесы так то. При том с хардварной клавой управление явно лучше чем с обмылком без кнопок вообще, у которого убогий ввод - это боль. Т.е. даже например в аналог breakout какого на ведроиде поиграть - господи, ну и капец же это!
> чтобы 3-4 мессенджера одновременно работали?
Я спокойно юзал аську, ирку и жаббер. Вот прям на симбианской нокии. Еще и почтарь открыть можно было! Тормозило меньше чем сейчас.
> А еще какой-то почтовик, гугл-таблицы и тд.
При том бесполезный и дико тормощной.
> У меня телефон не лопата (72мм шириной). И батарейки в 5к хватает на неделю.
Не бьется с "смотеть ютуб" - да даже просто в чатиках отвисать. Если его на полочку положить, вырубив сеть - может быть. А у типового хомы загаженый мобильник - качает сотни хлама, вечно горячий и за сутки выдыхается. Они и сидят в обнимку с зарядкой и павербанком. Даже бабки с павербанками бывают! До чего дошел прогресс!
>> вызывающий крах как индикатор что кодер жестко облажался.
> Ну... как вариант, но все равно костыльно.Это индикатор что программа не может продолжить корректную работу, потому что программер сделал что-то не то. Что-то типа assert() по смыслу. Просто - подперто железом: даже если програмер не сделал проверок на null сам, потуга реально сунуться в адрес 0 обычно ведет к хардварному исключению. Это невозможно не заметить. По дефолту - ос убьет программу дефолтным handler'ом, если програмер его не оверрайднул.
> А потом читаем про падение в рекурсии в машинах тойота)
Ну так их и засудили за такой програмизм. И правильно сделали. Если кто берется делать работу, пусть делает ее нормально. Рекурсия в фирмвари ECU на "нормально" не тянет, это грубое нарушение отраслевых практик.
> Не показатель. Может просто директор захотел яхту.
Показатель - то что за ...цать лет оно так нигде и не юзается. Болтается какой-то недоделок. А фокс стало вообще кошмаром билдить в результате. Кода там даже на си больше чем на хрусте, си++ там на их обоих хватит, а еще хруст. И теперь вообще удачи это суперкомбо вообще собрать. Надо половину интернета скачать и пока билд пройдет нормально - семь потов сойдет.
> И это нормально. Особенно для браузера.
Это настолько нормально что...
1) Внешние комитеры практически отвалились.
2) Именно мозилла стремительно двигается к кончине и - бытью шкуркой хромиума.> Потому что писать какой-то парсер или скрипты на си будет только очень
> странный человек.А что, какой-нибудь flex/bison - не катил? Вроде, не такой уж плохой способ парсеры на си делать.
> И например в андроиде или хроме (одни из самых популярных программ в
> мире) как раз несколько языков.И еще 1 пример софта которые никто кроме их хозяина в виде корпорации Туранчокс^W Гугл не девелопает по сути. И вот какое дело мне до того что этот Туранчокс внутри себя делает? Не, работать к ним - я не собираюсь. Хоть там как, видал я эту корпорацию бобра.
>> И подход "скачайте ночнушку чтобы сбилдить ядро" - очень так себе.
> Бредовый бред) Но типичный.Что вижу то и пою. Буквально 1-2 ядра назад господа огребли жесткую отповедь на эту тему.
> Примерно как в ведро можно зафиксировать с89, так же и версия раст
> фиксируется.Они это и делали дофига лет, если вы не заметили! Сейчас на C11 зафиксировали. На минутку, ему 14 лет уже. Поэтому - можно взять дистровский тулчейн любого майнстрим дистра - и просто собрать себе кернел.
...а теперь попробуйте ЭТО с хрустом сделать. И как, хорошо билдуется в каком демьяне, убунте LTS или не самом новом редгаде? Чисто практическая разница.
> Про ночнушки может писать человек, который вообще не понимает что такое edition
> и книжку не читал.
> Зато мнение имеет.Для меня, как одного из тех кто билдит ядра критерий - не книжки и не edition а воооон то.
> Unsafe. Use unsafe Luk!
В принципе даже неплохая идея - но - увы - господа сделали по итогам синтаксис когда C++ кажется не таким уж и плохим, подмахнули маздайцам с своим корп-контролед карго(-культом) и в совете директоров - сладкая парочка^W тройка самых мерзких галер планеты. Не очень эпично имхо.
>> Хруст с своим вечным скачайте ночнушку
> Ты можешь привести пример,Для меня критерий прост как дрова: можно ли отстроить в стоковой версии моей оси стоковыи пакетами кернел. И как вы понимаете, ответ пока - отрицательный. Т.е. на данный момент билд кернела с хрустом это какой-то совершенно левый гемор на ровном месте.
> К счастью твое мнение мало кого волнует)
"Два часа за вами гналась сказать как вы мне безразличны!" :)
>> Если б си так себя вел им бы в жизни никто не стал пользоваться!
> В сишке в зависимости от вендора компилятора и даже его версии у
> тебя программа может давать разные результаты. Для одно и того же
> "типа стандарта".Если дурака не валять то таки все норм работает. И так то есть тулсы типа asan/ubsan если что.
> А ты говоришь "никто не стал пользоваться")
Мне и правда пофиг что там галера имени гугла делает - это траблы ее наймитов. Я не они и никогда не буду одним из.
>Максимум что я видел на эту тему - потуги хрустиков в R4L, которые в итоге родили семейство неведомой фигни try*, с семантикой ... на удивление похожей на сишные конструкции?!Кстати, можно и не писать отдельный язык. Конечно, тогда останутся куча сишных проблем, типа слабой системы типов, но если отказаться от стандартной библиотеки си, и реализовать всё с нуля, те же самые строки реализовать с хранением размеров, без нуль терминатора, а над системными вызовами сделать кучу своих обвёрток, то даже может получится что-то нормальное. Но средний сишник такое явно не осилит
А потом от таких динамических выделений уязвимости лезут. Ага. В 2к25 не западло заранее хоть мегабайт выделить.
На вас памяти не хватит, мегабайт туда, мегабайт сюда. Чинить нужно уязвимости от динамического выделения.
Ну, допустим по мегабайту на программу, при стандартных в 25м году 8гб памяти это получается нужно запустить аж 8000 процессов.
8000 ! Мне вот с трудом такое представляется в реальности, для домашнего пк.
Даже за вычетом ресурсов ос, все равно получается много ресурсов остается, если ядро сконфигурировано жрать пару десятков мб, то для инита те же 10мб памяти не такая уж и проблема отдать.
>Ну, допустим по мегабайту на программу, при стандартных в 25м году 8гб памяти это получается нужно запустить аж 8000 процессов.Во-первых в 1 Гб 1024 Мб. Во-вторых, даже если следовать вашей логике, то вы выделили 8000 буферов. Про выделение памяти под анонимные страницы или файловый кеш вы забыли. Работать такая система не будет. Если предположить, что одному процессу хватит 1 Мб на анонимные страницы + файловый кеш, а 1 на буффер, то уже будет 4096. А с учётом того, что 1 Мб на анонимные страницы не хватит, то у вас будет куда меньше.
>если ядро сконфигурировано жрать пару десятков мбВ реальности потребление будет больше
>то для инита те же 10мб памяти не такая уж и проблема отдатьУчтите, что вам понадобится далеко не один буфер
> Ну, допустим по мегабайту на программу, при стандартных в 25м году 8гб
> памяти это получается нужно запустить аж 8000 процессов.А вы готовы заплатить за это все - в роутере-мыльнице каком? Ну подумаешь, он изначально ВЕСЬ стоил как планка памяти :)
Здравый смысл подсказывает, что в таком случае нужно сообщить пользователю об ошибке, напр. провалидировав файл после изменения и написав "строка N превышает допустимый размер". И тем более не совершать деструктивные действия.Но у дидов альтернативный здравый смысл - "и тааак сойдет". Прям в стиле какиров из 80х.
Наомнячил лишь бы не падало и х-к, х-к и в прод.
Хакер с солонкой, перелогинься.Здравый смысл подсказывает, что решать проблемы следует по мере их возникновения. Вот проблема 127-значных строк 30 лет не возникала, пока какой-то дурак не прошелся по граблям.
"вот как убьют, тогда и приходите"? Это ваш девиз?
к сожалению, в sysvinit нет функций, позволяющих убивать пользователя, прописавшего в inittab строку длиной более 127, а теперь и 253 знака.well... nobody's perfect.
> к сожалению, в sysvinit нет функций, позволяющих убивать пользователя,
> прописавшего в inittab строку длиной более 127, а теперь и 253
> знака.
> well... nobody's perfect."I'm nobody" :))
Нет, это какой-то дурак подложил грабли.
>Вот проблема 127-значных строк 30 лет не возникала, пока какой-то дурак не прошелся по граблям.Проблема не возникала, поскольку все давным давно на systemd сидят. Вот кто-то решил скачать sysvinit, чтобы посмотреть, как диды программировали, а там такое недорозумение.
> проблема 127-значных строк 30 лет не возникалаSysvinit был написан 1983м. 42 года.
>> проблема 127-значных строк 30 лет не возникала
> Sysvinit был написан 1983м. 42 года.копирайты линукс sysvinit c 1991 начинаются.
по любому достаточно взрослый, чтобы пить курить и прочее.
80 символов в строке - это ограничение перфокарты. Ограничивать себя шириной перфокарты в 21-м веке - это верх идиотизма и глупости.
делать текст нечитаемым - вот верх идиотизма и глупости.независимо от века и технических возможностей.
> делать текст нечитаемым - вот верх идиотизма и глупости.Текст вполне читаемый. Если ты конечно не используешь CRT монитор из 80-х.
вопрос не в мониторе, а в том сколько мозг может внимательно "сьесть",не "давай я прочту это бегло", а именно внимательно чтоб увидеть ашипки.
> вопрос не в мониторе, а в том сколько мозг может внимательно "сьесть",
> не "давай я прочту это бегло", а именно внимательно чтоб увидеть ашипки.Да нормально мозг воспример, скажем 120 - 140 символов в строке, к тому же с отступами. То есть реального текста в каждой строке будет явно меньше.
вы никогда не замечали, что газеты печатаются столбцами?и разумеется никогда не задавались вопросом "почему?"
задайтесь )))
> вы никогда не замечали, что газеты печатаются столбцами?вы никогда не замечали, что книги печатают не столбцами?
В книгах ширина листа сильно уже листа газетного и сильно больше шрифт.
> В книгах ширина листа сильно уже листа газетного и сильно больше шрифт.Тем не менее количество символов в строке там больше, чем в газетной колонке.
И тем не менее, всё равно сильно меньше 80.
Газеты очень неудобно читать, так как постоянно приходится прыгать между строчками
Открываете код в терминале на 80 знаков в виме, после чего делаете :set wrapДлинные строки бывают нужны, для тех вещей, которые не нужно разрывать. Например, для файловых путей, переменных или подобных вещей.
Так в ядре, к примеру, Грег давно объявил придерживаться 132 символов в строке.
80 col это ограничение перфокарт,на которых в доисторические времена держали исходники.
В ранних терминалах 80 колонок тоже для совместимости были, как и в текстовых режимах видеокарт.
И от 80 колонок в исходниках начали отказываться еще в прошлом веке, с появлением графических видеорежимов.Конечно, с дури, раздувать строки глупо,
но иногда для повышения читаемости, использую строки и более 300 символов, если это позволяет описать что то в стиле таблицы, и можно легко которую изменять.Для "эстетов" элементарно отформатировать исходник в любой формат. В том числе типа правильный, но не читаемый. А вот в обратно в читаемый вид привести, это как прокрутить котлеты назад в корову.
>иногда для повышения читаемости, использую строки и более 300 символовТы манъяк. Никогда не выкладывай свои исходники, понял!
В XXI веке люди решили, что ширина строк не должна превышать 100 символов.
Поставим вопрос по другому.
Представьте csv файл, тот что таблица разделенная запятыми.
Как оно читаемее, когда строки переносятся или нет?
Вот, и при описании громоздких массивов тоже самое. Можно отформатировать по правилам, но сделать исходник нечитаемым, в которм чорт ногу сломит.
Речи о однострочниках, именно в одну строку нет. ;)> решили, что ширина строк не должна превышать 100 символов.
Да на здоровье. При выкладке, кому как надо и форматируют, и не только ширину строк, но и стиль кода.
Конечно, излишне длинные, за 300 символов строки и меня не радуют.
Но если на рабочем окне редактора влазит около 150-180 симмволов, в чем великий смысл уменьшить ширину окна вдвое? Нескучные обои смотреть? Получать с экрана меньше информации?
Поэтому, то что влезает в видимую на экране строку, именно при работе, просто так не переношу, если это не имеет логического смысла, например банальный длинный вызов функции.
в гугле ты бы долго не задержался :)мониторч там выдают здоровенные, а вот длина строки во всех стайл гайдах ограничена 80 знаками.
задумайся над этим. или почитай сами гугловские гайды, они вроде и на гитхабе доступны.
если совсем на пальцах - длинные строки читаются быстрее, а короткие - внимательнее.
оптимальная ширина печатного текста в 60 знаков тоже не на голом месте выведена.
> а вот длина строки во всех стайл гайдах ограничена 80 знаками.А Фрол как всегда врет с умным видом. Ничего нового...
> или почитай сами гугловские гайды
А сам то читал или не осилил?
Вот только длина строки разная в разных языках для одного и того же гуглас++ - Each line of text in your code should be at most 80 characters long
Что в общем-то логично для прдликов из 80х
google.github.io/styleguide/cppguide.html#Line_Lengthc# - Column limit: 100.
google.github.io/styleguide/csharp-style.html#whitespace-rulesjava - Java code has a column limit of 100 characters.
google.github.io/styleguide/javaguide.html#s4.4-column-limitobjc - The maximum line length for Objective-C files is 100 columns.
google.github.io/styleguide/objcguide.html#line-lengthswift - code has a column limit of 100 characters.
https://google.github.io/swift/#column-limitlisp - You should format source code so that no line is longer than 100 characters.
Даже в лиспе можно 100 символов использовать!
google.github.io/styleguide/lispguide.xml#Line_lengthgo - There is no fixed line length for Go source code
google.github.io/styleguide/go/guide#line-lengthПо остальным гайдм пройдешься сам.
Лол ну значит у них там тоже разброд и шатание.Я ткнулся в си, питончик и яваскрипт с шеллом - везде совет не вылазить за 80 знаков.
про go ты вообще не напоминай, там gofmt форматирует текст табами вместе с пробелами, кушай не обляпайся.
>вот длина строки во всех стайл гайдахЕщё раз, Вы о автоматизированном форматировании исходника точно слышали, или всё ручками делаете?
Да, да, ждём-с "правильный" init на js. С подкачкой статики с cdn-ов. С шифрованными и обфусцированными блобами. На микросервисах с очередями в облаках. И ai-зированными пользователями в контейнерах.
На Электроне хоть? А микротранзакции в нём будут?
Странно что не написали: применялась давным-давно в далёкой-далёкой галактике.
> So while approximately 127 characters has been enough for most people for 30 years, this behaviour was dodgy and needed to be fixed. Now inittab entries can be 253 characters long AND it logs a warning when a line longer than this is found AND it refuses to run a line longer than 253 characters. It doesn't truncate too-long lines anymore, it just drops them.
> I think most people were putting long lines and complex logic in their shell scripts anyway, but this is just additional protection against potential problems.все правильно сказал. если у тебя в inittab строки длиннее 127 символов, you're doing it wrong.
> approximately 127 charactersОго, даже не "точно 127", а "примерно 127"
Они до конца не определились?))> it logs a warning when a line longer than this is found
Понадобилось всего 30 лет чтобы догадаться сообщать пользователю!
ЭТО ПРОСТО НЕВЕРОЯТНО!!!> it refuses to run a line longer than 253 characters.
Ну надо же! Просто офигеть сколько прозрений снизошло на них в один день!
Жалко, что так мало восклицательных знаков. А то местный автобот сожрал бы это очень ценное замечание.
В отличии от systemd в sysvinit не завезли декларативность. Давным давно устарело
Думаешь машинному коду нужна декларативность? Вот и всему остальному не нужна.
Вы пишите сразу в машинных кодах?
Народы, а кто-нить сможет привести реальный пример строки inittab длиной 127 и более знаков? и объяснить зочем?
Linux has a maximum filename length of 255 characters for most filesystems (including EXT4), and a maximum path of 4096 characters.
> кто-нить сможет привести реальный пример строки inittabI Can't Into Reading Comprehension: Achievement Unlocked
дядя, limits.h я и сам могу процитировать
> реальный примерпри MAX_FILENAME_LENGTH - будет урезан
чатгпт уходи
> а кто-нить сможет привести реальный пример строки inittab длиной 127 и более знаков?у чатгопоты с аналогией проблемы, выше сказанное равносильно - "Кто д*рак, пусть поднимет руку".
-- BTRFS = 255 символов ASCII. Но в UTF-8 символах это еще меньше.Проверил файл с названием создается: 85 символов 255 байт.
「ないが」の「が」という訳は、おかしいと感じられるかもしれません。しかし、「流れゆく水は絶えなくて（常なるもの）」と「同じ水ではない（無常なるもの）」という相反する考え方
-- NTFS = 255 символов UTF-16.Венда спокойно создает файл с названием: 243 символов 727 байт.
「ないが」の「が」という訳は、おかしいと感じられるかもしれません。しかし、「流れゆく水は絶えなくて（常なるもの）」と「同じ水ではない（無常なるもの）」という相反する考え方を繋ぐためには、「が」という語を使い、「それでいて」を活かすとよいでしょう。一般的には、「行く川の流れは絶えることなく、それでいて、この瞬間に流れている水はもとの水ではない。」という訳がされます。この世に同じものなど二つと無く、それでいて、流れ自体が絶えないという、仏教の世界観に貫かれた書き出しといえるでしょう。
> -- NTFS = 255 символов UTF-16.
> Венда спокойно создает файл с названием: 243 символов 727 байт.
> 「ないが」の「が」という訳は、おかしいと感じられるかもしれません。しかし、「流れゆく水は絶えなくて（常なるもの）」と「同じ水ではない（無常なるもの）」という相反する考え方を繋ぐためには、「が」という語を使い、「それでいて」を活かすとよいでしょう。一般的には、「行く川の流れは絶えることなく、それでいて、この瞬間に流れている水はもとの水ではない。」という訳がされます。この世に同じものなど二つと無く、それでいて、流れ自体が絶えないという、仏教の世界観に貫かれた書き出しといえるでしょう。Отлично, теперь файлы вообще не нужны! Можно записывать трактаты на японском, или какой это был - прямо в название файла. Мужик создавший архиватор с 100% степенью сжатия - одобряет, меньше файлов 0 размера создавать для распихивания инфы из файлов.
p.s. а если серьезно то хранение такой простыни в file name не выглядит чем-то здоровым.
>Отлично, теперь файлы вообще не нужны! Можно записывать трактаты на японском, или какой это был - прямо в название файла.Как же легко живётся анонимам, которые думают, что одного имени файла хватит всем. Попробуйте контейнер запустить, где будет пробрасываться не однин файл а несколько, с абсолютным путём. Или какой-нибудь софт вроде ffmpeg с кучей опций.
ffmpegв inittab
спасибо, отличный пример.
Вы из всего софта у которого много ключей только ffmpeg видели? Как насчёт autossh того же? Да даже просто укажите ему запускать какую-то команду вместо облочки, и уже символы можно исчерапать.
> Вы из всего софта у которого много ключей только ffmpeg видели? Как
> насчёт autossh того же? Да даже просто укажите ему запускать какую-то
> команду вместо облочки, и уже символы можно исчерапать.А еще можно оракловое окружение попробовать определить при запуске листенера, прямо там же в иниттабе.
или еще чо-нить неординарное отмочить.
И что, в sysvinit всё нужно в отдельный bash скрипт выносить? Или как?
> И что, в sysvinit всё нужно в отдельный bash скрипт выносить? Или
> как?Передёргивание -- плохой аргумент.
Семь бед, один ответ - костыль и велосипед
> Как же легко живётся анонимам, которые думают, что одного имени файла хватит
> всем. Попробуйте контейнер запустить, где будет пробрасываться не однин файл а
> несколько, с абсолютным путём. Или какой-нибудь софт вроде ffmpeg с кучей опций.- А теперь поза - "фантомас в очках на аэроплане"!
- ffmpeg, из sysvinit, с трактатами на японском - в названии файла.(неужто какие-то психи так делают?!)
ну так с таким же успехом это могла быть целая сложная и глубокая иерархия папок на японском, где бедный японец старательно продумал имена для папки каждого уровня, а потом натолкнулся на такую подставу от гайдзинов
ай блин, напутал. Тут же речь про ограничение на длину имени файла, а не пути. Но вообще несправедливо, да. Да и путаница. Раз ограничение N символов, то должно быть пофиг латиница ли это или иероглифы
Нет не напутал. В файловой системе при переходе на новый уровень, лимит сбрасывается. А вот в inittab в sysvinit - копится.
/a/a/a/a/a - ещё символа 254 в имя файла влезет (не помню, нужно нулевой байт считать), а вот в inittab уже 10 байт потратили
>Раз ограничение N символов, то должно быть пофиг латиница ли это или иероглифыБайты. Иероглифы быстрее исчерпают
"Байты. Иероглифы быстрее исчерпают"Я в курсе. И именно эта ориентация на байты мне кажется неправильной. Лучше бы сделали абстракцию которая ко всем относилась по равному. Например, если предподожим в иероглифах де-факто мы можем ввести только 85 символов, то и всем остальным нужно говорить что ограничение в 85 символов, даже если они будут писать латиницей
> Я в курсе. И именно эта ориентация на байты мне кажется неправильной.
> Лучше бы сделали абстракцию которая ко всем относилась по равному. Например,
> если предподожим в иероглифах де-факто мы можем ввести только 85 символов,
> то и всем остальным нужно говорить что ограничение в 85 символов,
> даже если они будут писать латиницейКомпьютеры так изначально - с байтами работают. И намного удобнее оперировать с каким-то фиксированным максимумом в байтах. А абстракции сильно замедлят все файловые операции, особенно если файлов много. Никогда не видели диру с миллионом файлов? А теперь представьте что там еще какие-то абстракции вопрочать. Предлагаю это в винду запихать, пусть у них там саботаж скорости работы ОС и ФС получится.
Возьмите контейнеризацию, не важно docker/bubblewrap и попробуйте запустить контейнер напрямую. Укажите ему несколько сетей, пробросьте десяток другой путей, настройте отображение идентификаторов.
От авторов "Запускайте nginx из-под рута", ага.
Этим как раз таки любители sysvinit отличаются, у них всё от рута, всё без изоляции. Недавно nginx на NixOS настраивал, так он от корня файловой системы изолирован, при необходимости дополнительные файлы пробрасываются. Зато случайно никакой файл в сеть не утечёт.
Опции getty для какого-то хитрого uart вполне могут и превысить. Но это оче тонкая и специфичная штука.
А расскажите как она по сравнению с Runit?
runit параллельно сервисы запускает, если сервис упал или не поднялся по какой-то причине - перезапускает. в sysvinit вроде такой функциональности нет. зависимостей сервисов нету ни в одном, но в рунит можно хак сделать с sv check $service || exit 1
Спасибо. А какае ещё альтернативы систем-де посоветуете?
dinit, shepherd
s6 ещё.Ну и всякие ninit и minit для встроек. При желании их вкорячить и на десктоп можно (но не нужно).
О, s6 прикольная тема. Однажды вдохновился им и сделал свой инит по мотивам, фана ради. Насколько я помню, там тоже перезапуск упавших сервисов есть.
>runit параллельно сервисы запускает, если сервис упал или не поднялся по какой-то причине - перезапускает. в sysvinit вроде такой функциональности нетЛожь.
>Ложьгде?
After the system's one time tasks (stage 1) are done, the system services are started up in parallel. The operating system's process scheduler takes care of having the services available as soon as possible.
On system shutdown, stage 3 uses runsv's control interface to wait until each service daemon is terminated and all logs are written. Again, services are taken down in parallel. As soon as all services are down, system halt or system reboot is initiated.
>где?Тут. <в sysvinit вроде такой функциональности нет>
Где тут ложь? Не распарсил слово «вроде»?
> параллельноесть лет 10 как...
>А расскажите как она по сравнению с Runit?Ранит это урезанный по функционалу sysVinit. Просто создатели Ранита решили, что для счастья достаточно 2 двух режимов: однопользовательский и многопользовательский. Ну и в терминологии разница. У ранита - сервисы, у sysVinit - демоны.
А что посоветуете использовать? Вот мне тут выше про dinit и shepherd рассказали. Может быть хорошая статья со сравнительным анализом всех альтернатив систем-де?
что в твоем дистрибутиве по дефолту
> что в твоем дистрибутиве по дефолтуА если я свою систему из исходников хочу собрать?
busybox init
Я спросил о полноценной системе, а не об игрушке.
>свою систему из исходников хочуигрушка для игрушки, все правильно, что тебя не устраивает? начинают с простого
ну попробуй s6 осилить — в alpine занесешь, люди спасибо скажут, они давно подумывают на него перейти. не забудь тоько потом рассказать о своих особых ощущениях
Почему ты решил, что я собрался делать игрушку? Ты телепат?
потому что вопросы на форуме задаешь, вместо того чтоб документацию читать. поэтому еще раз предлагаю — начать с простого, а то так и не поймешь какие проблемы решает «полноценный инит»ну или бери s6, если упоротый, и пиши свою реализацию на execline :D
> потому что вопросы на форуме задаешь, вместо того чтоб документацию читать. поэтому
> еще раз предлагаю — начать с простого, а то так и
> не поймешь какие проблемы решает «полноценный инит»
> ну или бери s6, если упоротый, и пиши свою реализацию на execline
> :DСкорее всего ты сам упоротый, если простой вопрос так воспринимаешь.
> Почему ты решил, что я собрался делать игрушку?Потому что ты написал "систему из исходников хочу собрать". Либо ты новый Мёрдок и сидишь-пилишь новый дистрибутив общего назначения (что с учётом вопросов -- вряд ли), либо тебе поиграться захотелось.
Попробуйте посмотреть в сторону openrc-init https://github.com/OpenRC/openrc/tree/master
Спасибо. Можете посоветовать статью со сравнительным анализом этого с другими альтернативами?
> Спасибо. Можете посоветовать статью со сравнительным анализом этого с другими альтернативами?К сожалению такая статья мне неизвестна, но у гентушников на сайте есть небольшое табличное сравнение разных init'ов и отсылки к некоторым довольно интересным статьям. Попробуйте что-то почерпнуть там https://wiki.gentoo.org/wiki/Comparison_of_init_systems
По мотивам: https://davmac.wordpress.com/2018/10/26/on-the-vagaries-of-i.../
> А расскажите как она по сравнению с Runit?Когда мы говорим о runit, мы говорим не только про runit как pid1 (собственно сам init), но и про запускаемый им runsvdir-start. Тут надо понимать, что контексте sysv, sysvinit -- это как раз pid1, а процесс инициализации сервисов, запускаемый им -- может быть как бы любым скриптом, и они были в каждом дистрибутиве свои. Так, например, было время, когда рунитовский runsvdir-start запускался посредством sysvinit: сами иниты-то вполне себе взаимознаменяемы.
По части разницы в написании сценариев запуска и принципах их работы -- многого сказать не могу, поскольку конкретно с runit не работал. Но могу сказать, что во времена sysv в Debian он поддерживал параллельный запуск сервисов по зависимостям (а то вам тут выше пишут, что мол, не было этого). Супервайзера же из коробки не было, и упавшие сервисы не рестартовались. Поэтому когда мы делали сценарии запуска энтерпрайзных продуктов, мы приделывали внутри них супервайзинг на базе djb's daemontools.
PS: По поводу супервайзинга... Да, возможно это и имело смысл сделать глобально для всех сервисов, но в те времена их в основном писали так, чтобы они не падали, и мы искренне считали, что супервайзинг -- это чисто "для нашего падучего энтерпрайзного г**на". В целом, добавить супервайзинг в sysv -- не особо сложная задача, и возможно мы бы так и сделали в конце концов, но теперь, когда systemd повсеместно протолкнули как фактический стандарт -- нужды в этом нет.
Удивительно, что никто до сих пор не написал про то, как на баше сложно писать правильный код, со всякими экранированием и прочим.
Я искренне хочу увидеть, как ненависники systemd будут оправдывать абсолюнтное отсутствие даже намёка на гибкость этих самых портянок. И как они их будут патчить, чтобы потом пакетный менеджер затёр плоды их трудов. Но вот беда, ненависники systemd не пишут код на баше, они сидят на винде.
> И как они их будут патчить, чтобы потом пакетный менеджер затёр плоды их трудов.Опять двадцать пять. И этот тезис в каждой новости. Вообще необучаемые люди.
>Вообще необучаемые людиТак ответа то нет. Вернее есть, но "нинужна, на моём локалхосте и так сойдёт". А то, что мир не ограничивается локалхостом - не хотят принять
> Так ответа то нет. Вернее есть, но "нинужна, на моём локалхосте и так сойдёт".Да неужели.
https://www.opennet.dev/openforum/vsluhforumID3/135550.html#192
И это только последнее. Вот уже более 10 лет вам в каждой относящейся к сабжу новости на опеннете пишут что-то подобное.
>Да неужелиПредставьте себе https://archlinux.org.ru/forum/topic/21850/
>В результате, при обновлении пакета с с версий до 6.5 на версию 6.5 и выше, имеющиеся рабочие отредактированные конфиги в /etc/iproute2 переименовываются в *.pacsave и тихо перестают работать.И кто знает, какие ещё сюрпризы преподнесёт очередная система
>Что в rpm-, что в deb-пакетах есть такая вещь, как "конфигурационные файлы"Отлично. Теперь нужно каждый пакет проверять отдельно, ведь кто его знает, как он собран
>И отдельно, чтобы сразу при прочтении имели в виду: файлы в /etc получают эти флаги автоматом.Разумеется, в башпортянках редактирование /etc не ограничивается. Вот один из примеров https://github.com/robertdebock/docker-alpine-openrc/blob/ma... .
>sed -i 's/cgroup_add_service /# cgroup_add_service /g' /lib/rc/sh/openrc-run.sh && \
>sed -i 's/VSERVER/DOCKER/Ig' /lib/rc/sh/init.sh
> https://archlinux.org.ru/forum/topic/21850/
> В версии 6.5 пакета iproute2 было внесено усовершенствование, позволяющее утилитам ip читать конфиги не только из /etc/iproute2/* , но и из /usr/lib/iproute2/*Однако. А это разве камень не в ваш огород?
> Теперь нужно каждый пакет проверять отдельно
Нет. Зачем бы?
>> И отдельно, чтобы сразу при прочтении имели в виду: файлы в /etc получают эти флаги автоматом.
> Разумеется, в башпортянках редактирование /etc не ограничивается. Вот один из примеровДокерфайл? Серьёзно? Как это вообще связано с цитируемым фрагментом?
Давайте честно: вы не хотите учиться. Вы хотите поспорить и поругаться. =)
>Однако. А это разве камень не в ваш огород?Нет. Поведение, что файлы в /etc не перезапишутся молча - не обязательное, даже на мейнстримных дистрибутивах. Может быть, на убунте или на федоре, но если эти дистрибутивы не устраивают, то будут проблемы. И это, не заслуга sysvinit, а заслуга apt. В то время как systemd всё равно, какой пакетный менеджер стоит, там переопределение есть из коробки
>Докерфайл?Чем вам докерфайлы не угодили?
>Серьёзно? Как это вообще связано с цитируемым фрагментом?При том, что в башпортянках нет разделение на конфиг и код, всё смешано воедино. Вот есть /etc/init.d/nginx - это конфиг или код? Раз в /etc лежит, то скорее всего конфиг. Но, если есть желание добавить изоляцию файловой системы, то нужно дописать вызов условного unshare/bwrap/..., то это уже код, и он почему-то всё равно лежит в конфиге. А вот есть /lib/rc/sh/openrc-run.sh, судя по пути это код, но почему-то настройка среды исполнения - хост/контейнер делается в нём, хотя по логике это должно лежать в /etc. Вот в systemd всё просто - systemctl - это код, его при настройке системы не трогают. А /etc/systemd/system/nginx.service - это юнит файл идущий из дистрибутива, а /etc/systemd/system/nginx/service.d/overrides.conf - локальное переопределение.
Ох. Буду честен: я не знаю, как ответить на ваши вопросы. Лучше оставлю это другим людям. =)
В чём проблема гибкости? Берёшь скрипт и правишь, как тебе нужно.
А у меня прикол, я так и не осилил баш, до сих пор на шелле пишу нужное...
> А у меня прикол, я так и не осилил баш, до
> сих пор на шелле пишу нужное...Стартовые скрипты обычно и принято писать - на вот именно posix sh. Так что можете задекларить баг фичой и спать спокойно.
А разве GNU bash не поддерживает стандарт Позикс?
> А разве GNU bash не поддерживает стандарт Позикс?Он поддерживает superset стандарта позикс.
Поэтому с одной стороны, скрипты для именно posix shell - башем, конечно, выполнятся. Но в этой роли - баш довольно тормозной и жирный. И если его юзать для вот именно этого - процесс загрузки весьма ощутимо замедляется. Поэтому в эпоху актуальности топика дистры типа дебиана юзали более лайтовый шелл по типу dash для рюхания скриптов сабжа в роли именно позиксного "sh".
С другой стороны - скрипты для вот именно bash работать в других шеллах не обязаны, ибо могут использовать нестандартные расширения за пределами стандарта posix. Это удобно - но нагибает портабельность. В частности в вышеупомянутом примере, дебианщики бы здорово чертыхались при портировании такого скрипта, например. Сейчас это менее актуально, но все же - есть такие аспекты у этого топика.
> Но в этой роли - баш довольно тормозной и жирный.Ой, и не говори даже, вот то ли дело systemd! =)
>> Но в этой роли - баш довольно тормозной и жирный.
> Ой, и не говори даже, вот то ли дело systemd! =)Сам по себе системд в каких-то особых тормозах не замечен. Процесы оптом он на каждый пшик не форкает, да еще с шелл интерпретером внагрузку. А внутрях довольно эффективная конструкция.
Если у кого склероз, напомню что Debian юзал Dash для вон того во времена актуальности. Именно потому что bash весьма неспешная штука.
И еще, что получается из скриптовой лапши если попробовать подобие системды замутить отлично показал - openwrt.
Ситуация: oom killer вынес прогу. В сервисе с настроеным авторестартом. Чудо-месиво утилиток и скриптиков - вообще не видит проблем! Ежели именно по OOM. Системд к счастью не настолько тупой, и по крайней мере не фэйлит миссию железки в настолько тупом формате. Это так, если сравнить рядом, как разные вэи делают одно и то же.
>> Но в этой роли - баш довольно тормозной и жирный.
>Ой, и не говори даже, вот то ли дело systemd! =)Вот вам ещё немного спецэффектов от баша. https://habr.com/ru/articles/500832/ С systemd такое не прокатит
> https://habr.com/ru/articles/500832/Какая неожиданность-то: при изменении файла смещения связанных с ним дескрипторов не меняются! В общем, поздравляю анонима с открытием Америки. =)
Помимо вопроса о том, что для этого вы должны не просто редактировать скрипт руками, что уже моветон, но вообще говоря редакировать скрипт, который вот прямо сейчас выполняется (это ж каким самому себе злобным буратино надо быть) -- скажите, а вы вообще помните о том, что деды вам говорили что-то вроде "не используйте nano, используйте vim/emacs"? Вы никогда не задумывались, почему?
>Какая неожиданность-то: при изменении файла смещения связанных с ним дескрипторов не меняются! В общем, поздравляю анонима с открытием Америки. =)Удивителен тот факт, что вместо построения синтаксического дерева, и дальнейшей работы уже с ним, bash читает файл посимвольно в момент исполнения.
>Помимо вопроса о том, что для этого вы должны не просто редактировать скрипт рукамиА чем редактировать - ногами?
>это ж каким самому себе злобным буратино надо бытьБуратиной, создавшим Unix.
>но вообще говоря редакировать скрипт, который вот прямо сейчас выполняетсяПосле того, как диды изобрели cron, случится может что угодно. Но диды не будут чинить cron или bash, они просто изобретут заповедь - не добавляй bash в cron, ибо горькими станут дни твои.
>а вы вообще помните о том, что деды вам говорили что-то вродеДиды были религиозны, и придумывали разные обряды.
>Вы никогда не задумывались, почему?Нормальная система не нуждается в обрядах. Нормальная система, это что-то вроде NixOS, где системные файлы остаются неизменяемыми после установки, а замена происходит через атомарное замещение символических ссылок. И система не зависит от редактора или погоды на Марсе.
> Удивителен тот факт, что вместо построения синтаксического дерева, и дальнейшей работы
> уже с ним, bash читает файл посимвольно в момент исполнения.Нисколько не удивителен. Shell должен быть быстрым и потреблять мало памяти. При данных требованиях реализация в виде однопроходного интерпретатора -- вполне естественна.
>Shell должен быть быстрым и потреблять мало памятиК слову "быстрый" нужно добавить кучу оговорок. Начиная с того, что стандартные конструкции нужно заменять на xargs, а так же то, что порождение дочерних процессов вроде sed и grep не сказываются положительно на быстродействии.
В systemd тоже может оказаться что-то своё, очень неожиданное, по сравнению с Bash.
> В systemd тоже может оказаться что-то своё, очень неожиданное, по сравнению с Bash.Ну его позиция заключается в том, что в systemd есть daemon-reload, который единовременно прогружает все юниты, а потом держит в памяти. Это конечно хорошо, это решает гипотетическую проблему конкурентной правки файла скрипта, который одновременно исполняется. А мы на это смотрим прохладно лишь потому, что у нас никогда не было таких проблем: ну просто потому, что инит-скрипты правятся обычно не так уж часто, в основном катятся шаблонизаторами (а они создают сначала новый файл, а потом мувят по таргету), прогоняются одноразово, а супервайзинг вообще реализовывался отдельными утилитами, а не средствами собственно шелла. И естественно у нас нет информации о том, что кто-то попадал в подобную ситуацию, каковую парень описал: потому что если бы этот кто-то был способен отдебажить её, то он бы в ней банально не оказался.
Это довольно скучно. Мы им говорим -- ааа, у вас "0" в предыдущей версии значил одно, а в новой другое. Мы говорим -- ааа, вы пропустили багу из-за которой по дефолту домашние каталоги пользователя удаляются. Мы говорим -- ... а впрочем много чего мы говорим. А они нам в ответ "зато у вас нет гипотетической проблемы, которую мы выдумали". Ну что ж, спасибо им хотя бы за намерения. =)
>> В systemd тоже может оказаться что-то своё, очень неожиданное, по сравнению с Bash.
> Ну его позиция заключается в том, что в systemd есть daemon-reload, который
> единовременно прогружает все юниты, а потом держит в памяти. Это конечно
> хорошо, это решает гипотетическую проблему конкурентной правки файла скрипта, который
> одновременно исполняется.Именно. Файло можно спокойно отрихтовать - а потом сказать daemon-reoload когда готово. Без левых спецэффектов на ровном месте.
>до сих пор на шелле пишу нужное...Значит ты осилил GNU Bash. Так как твой шелл называется "И снова шелл Борна".
"Скажите на милость! Сорок с лишком лет говорю прозой - и
невдомек!" (с)